On Wed, 14 Feb 2018, "Winkler, Tomas" <tomas.winkler@xxxxxxxxx> wrote:
>>
>> This patch defines the hdcp2.2 protocol messages for the
>> HDCP2.2 authentication.
>>
>> Signed-off-by: Ramalingam C <ramalingam.c@xxxxxxxxx>
>> ---
>> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
