On Wed, 14 Feb 2018, "Winkler, Tomas" <tomas.wink...@intel.com> wrote:
>> 
>> This patch defines the hdcp2.2 protocol messages for the
>> HDCP2.2 authentication.
>> 
>> Signed-off-by: Ramalingam C <ramalinga...@intel.com>
>> ---
>>  include/drm/drm_hdcp.h | 226
>> +++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 226 insertions(+)
>> 
>> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
>> 562fa7df2637..9661c700cebb 100644
>> --- a/include/drm/drm_hdcp.h
>> +++ b/include/drm/drm_hdcp.h
>> @@ -38,4 +38,230 @@
>>  #define DRM_HDCP_DDC_BSTATUS                        0x41
>>  #define DRM_HDCP_DDC_KSV_FIFO                       0x43
>> 
>> +#define DRM_HDCP_1_4_SRM_ID                 0x8
>> +#define DRM_HDCP_1_4_VRL_LENGTH_SIZE                3
>> +#define DRM_HDCP_1_4_DCP_SIG_SIZE           40
>> +
>> +struct cp_srm_header {
>> +    struct {
>> +            uint8_t reserved_hi:4;
>> +            uint8_t srm_id:4;
>> +            uint8_t reserved_lo;
>> +    } spec_indicator;
> Do you really want to work with bit fields?  I mean in all the all structures.

We *can't* use bitfields in drm core for (un)marshalling. They depend on
endianness. (Thanks to folks on #dri-devel for confirming.) We use them
at places in i915 where we can be pretty sure about running on
little-endian machines, but that doesn't hold here.

Packed structs are fine otherwise though, just not bitfields.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to