summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_hdcp.c
AgeCommit message (Collapse)AuthorFilesLines
2020-05-05drm: Fix HDCP failures when SRM fw is missingSean Paul1-1/+7
The SRM cleanup in 79643fddd6eb2 ("drm/hdcp: optimizing the srm handling") inadvertently altered the behavior of HDCP auth when the SRM firmware is missing. Before that patch, missing SRM was interpreted as the device having no revoked keys. With that patch, if the SRM fw file is missing we reject _all_ keys. This patch fixes that regression by returning success if the file cannot be found. It also checks the return value from request_srm such that we won't end up trying to parse the ksv list if there is an error fetching it. Fixes: 79643fddd6eb ("drm/hdcp: optimizing the srm handling") Cc: stable@vger.kernel.org Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Sean Paul <sean@poorly.run> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200414190258.38873-1-sean@poorly.run Changes in v2: -Noticed a couple other things to clean up Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2020-03-04drm/hdcp: optimizing the srm handlingRamalingam C1-99/+59
As we are not using the sysfs infrastructure anymore, link to it is removed. And global srm data and mutex to protect it are removed, with required handling at revocation check function. v2: srm_data is dropped and few more comments are addressed. v3: ptr passing around is fixed with functional testing. v4: fix htmldoc [lkp] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Suggested-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20200212102942.26568-2-ramalingam.c@intel.com
2019-08-06drm/hdcp: reference for srm file formatRamalingam C1-0/+7
In the kernel documentation, HDCP specifications links are shared as a reference for SRM table format. v2: Fixed small nits. [Shashank] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320968/?series=57232&rev=14
2019-08-06drm/hdcp: update content protection property with ueventRamalingam C1-0/+34
drm function is defined and exported to update a connector's content protection property state and to generate a uevent along with it. Pekka have completed the Weston DRM-backend review in https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and the UAPI for HDCP 2.2 looks good. The userspace is accepted in Weston. v2: Update only when state is different from old one. v3: KDoc is added [Daniel] v4: KDoc is extended bit more [pekka] v5: Uevent usage is documented at kdoc of "Content Protection" also [pekka] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320963/?series=57232&rev=14
2019-08-06drm: Add Content protection type propertyRamalingam C1-1/+35
This patch adds a DRM ENUM property to the selected connectors. This property is used for mentioning the protected content's type from userspace to kernel HDCP authentication. Type of the stream is decided by the protected content providers. Type 0 content can be rendered on any HDCP protected display wires. But Type 1 content can be rendered only on HDCP2.2 protected paths. So when a userspace sets this property to Type 1 and starts the HDCP enable, kernel will honour it only if HDCP2.2 authentication is through for type 1. Else HDCP enable will be failed. Pekka have completed the Weston DRM-backend review in https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and the UAPI for HDCP 2.2 looks good. The userspace is accepted in Weston. v2: cp_content_type is replaced with content_protection_type [daniel] check at atomic_set_property is removed [Maarten] v3: %s/content_protection_type/hdcp_content_type [Pekka] v4: property is created for the first requested connector and then reused. [Danvet] v5: kernel doc nits addressed [Daniel] Rebased as part of patch reordering. v6: Kernel docs are modified [pekka] v7: More details in Kernel docs. [pekka] v8: Few more clarification into kernel doc of content type [pekka] v9: Small fixes in coding style. v10: Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14
2019-05-13drm/hdcp: drm_hdcp_request_srm() as staticRamalingam C1-2/+4
Below Sparsh warnings are fixed. Commit: drm: revocation check at drm subsystem +drivers/gpu/drm/drm_hdcp.c:235:6: warning: symbol 'drm_hdcp_request_srm' was not declared. Should it be static? +drivers/gpu/drm/drm_hdcp.c:27:3: warning: symbol 'srm_data' was not declared. Should it be static? +drivers/gpu/drm/drm_hdcp.c:317:5: warning: symbol 'drm_setup_hdcp_srm' was not declared. Should it be static? +drivers/gpu/drm/drm_hdcp.c:327:6: warning: symbol 'drm_teardown_hdcp_srm' was not declared. Should it be static? cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190513133504.18612-1-ramalingam.c@intel.com
2019-05-09drm/hdcp: gathering hdcp related code into drm_hdcp.cRamalingam C1-0/+47
Considering the significant size of hdcp related code in drm, all hdcp related codes are moved into separate file called drm_hdcp.c. v2: Rebased. v2: Rebased. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Suggested-by: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190507162745.25600-7-ramalingam.c@intel.com
2019-05-09drm: revocation check at drm subsystemRamalingam C1-0/+333
On every hdcp revocation check request SRM is read from fw file /lib/firmware/display_hdcp_srm.bin SRM table is parsed and stored at drm_hdcp.c, with functions exported for the services for revocation check from drivers (which implements the HDCP authentication) This patch handles the HDCP1.4 and 2.2 versions of SRM table. v2: moved the uAPI to request_firmware_direct() [Daniel] v3: kdoc added. [Daniel] srm_header unified and bit field definitions are removed. [Daniel] locking improved. [Daniel] vrl length violation is fixed. [Daniel] v4: s/__swab16/be16_to_cpu [Daniel] be24_to_cpu is done through a global func [Daniel] Unused variables are removed. [Daniel] unchecked return values are dropped from static funcs [Daniel] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Satyeshwar Singh <satyeshwar.singh@intel.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190507162745.25600-5-ramalingam.c@intel.com