Re: [Intel-gfx] [PATCH v5 01/40] drm: hdcp2.2 authentication msg definitions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 27, 2018 at 02:09:50PM +0530, Ramalingam C wrote:
> This patch defines the hdcp2.2 protocol messages for authentication.
> 
> v2:
>   bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
>   prefix HDCP_2_2_ is added to the macros. [Tomas]
> v3:
>   No Changes.
> v4:
>   Style and spellings are fixed [Uma]
> v5:
>   Fix for macros.
> 
> Signed-off-by: Ramalingam C <ramalingam.c@xxxxxxxxx>
> ---
>  include/drm/drm_hdcp.h | 179 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 179 insertions(+)
> 
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index 98e63d870139..3e963c5d04b2 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -38,4 +38,183 @@
>  #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

These don't seem to be related to the patch? 

> +
> +/* Protocol message definition for HDCP2.2 specification */
> +#define HDCP_STREAM_TYPE0			0x00
> +#define HDCP_STREAM_TYPE1			0x01

Why not HDCP_2_2 prefix?

> +
> +/* HDCP2.2 Msg IDs */
> +#define HDCP_2_2_NULL_MSG			1
> +#define HDCP_2_2_AKE_INIT			2
> +#define HDCP_2_2_AKE_SEND_CERT			3
> +#define HDCP_2_2_AKE_NO_STORED_KM		4
> +#define HDCP_2_2_AKE_STORED_KM			5
> +#define HDCP_2_2_AKE_SEND_HPRIME		7
> +#define HDCP_2_2_AKE_SEND_PAIRING_INFO		8
> +#define HDCP_2_2_LC_INIT			9
> +#define HDCP_2_2_LC_SEND_LPRIME			10
> +#define HDCP_2_2_SKE_SEND_EKS			11
> +#define HDCP_2_2_REP_SEND_RECVID_LIST		12
> +#define HDCP_2_2_REP_SEND_ACK			15
> +#define HDCP_2_2_REP_STREAM_MANAGE		16
> +#define HDCP_2_2_REP_STREAM_READY		17
> +#define HDCP_2_2_ERRATA_DP_STREAM_TYPE		50
> +
> +#define HDCP_2_2_RTX_LEN			8
> +#define HDCP_2_2_RRX_LEN			8
> +
> +#define HDCP_2_2_K_PUB_RX_MOD_N_LEN		128
> +#define HDCP_2_2_K_PUB_RX_EXP_E_LEN		3
> +#define HDCP_2_2_K_PUB_RX_LEN			(HDCP_2_2_K_PUB_RX_MOD_N_LEN + \
> +						 HDCP_2_2_K_PUB_RX_EXP_E_LEN)
> +
> +#define HDCP_2_2_DCP_LLC_SIG_LEN		384
> +
> +#define HDCP_2_2_E_KPUB_KM_LEN			128
> +#define HDCP_2_2_E_KH_KM_M_LEN			(16 + 16)
> +#define HDCP_2_2_H_PRIME_LEN			32
> +#define HDCP_2_2_E_KH_KM_LEN			16
> +#define HDCP_2_2_RN_LEN				8
> +#define HDCP_2_2_L_PRIME_LEN			32
> +#define HDCP_2_2_E_DKEY_KS_LEN			16
> +#define HDCP_2_2_RIV_LEN			8
> +#define HDCP_2_2_SEQ_NUM_LEN			3
> +#define HDCP_2_2_LPRIME_HALF_LEN		(HDCP_2_2_L_PRIME_LEN / 2)
> +#define HDCP_2_2_RECEIVER_ID_LEN		DRM_HDCP_KSV_LEN
> +#define HDCP_2_2_MAX_DEVICE_COUNT		31
> +#define HDCP_2_2_RECEIVER_IDS_MAX_LEN		(HDCP_2_2_RECEIVER_ID_LEN * \
> +						 HDCP_2_2_MAX_DEVICE_COUNT)
> +#define HDCP_2_2_MPRIME_LEN			32
> +
> +/* Following Macros take a byte at a time for bit(s) masking */
> +/*
> + * TODO: This has to be changed for DP MST, as multiple stream on
> + * same port is possible.
> + * For HDCP2.2 on HDMI and DP SST this value is always 1.
> + */
> +#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT	1
> +#define HDCP_2_2_TXCAP_MASK_LEN			2
> +#define HDCP_2_2_RXCAPS_LEN			3
> +#define HDCP_2_2_RX_REPEATER(x)			((x) & BIT(0))
> +#define HDCP_2_2_DP_HDCP_CAPABLE(x)		((x) & BIT(1))
> +#define HDCP_2_2_RXINFO_LEN			2
> +
> +/* HDCP1.x compliant device in downstream */
> +#define HDCP_2_2_HDCP1_DEVICE_CONNECTED(x)	((x) & BIT(0))
> +
> +/* HDCP2.0 Compliant repeater in downstream */
> +#define HDCP_2_2_HDCP_2_0_REP_CONNECTED(x)	((x) & BIT(1))
> +#define HDCP_2_2_MAX_CASCADE_EXCEEDED(x)	((x) & BIT(2))
> +#define HDCP_2_2_MAX_DEVS_EXCEEDED(x)		((x) & BIT(3))
> +#define HDCP_2_2_DEV_COUNT_LO(x)		(((x) & (0xF << 4)) >> 4)
> +#define HDCP_2_2_DEV_COUNT_HI(x)		((x) & BIT(0))
> +#define HDCP_2_2_DEPTH(x)			(((x) & (0x7 << 1)) >> 1)
> +
> +struct hdcp2_cert_rx {
> +	uint8_t	receiver_id[HDCP_2_2_RECEIVER_ID_LEN];
> +	uint8_t	kpub_rx[HDCP_2_2_K_PUB_RX_LEN];
> +	uint8_t	reserved[2];
> +	uint8_t	dcp_signature[HDCP_2_2_DCP_LLC_SIG_LEN];
> +} __packed;
> +
> +struct hdcp2_streamid_type {
> +	uint8_t stream_id;
> +	uint8_t stream_type;
> +} __packed;
> +
> +/*
> + * The TxCaps field specified in the HDCP HDMI, DP specs
> + * This field is big endian as specified in the errata.
> + */
> +struct hdcp2_tx_caps {
> +	/* Transmitter must set this to 0x2 */
> +	uint8_t			version;
> +
> +	/* Reserved for HDCP and DP Spec. Read as Zero */
> +	uint8_t			tx_cap_mask[HDCP_2_2_TXCAP_MASK_LEN];
> +} __packed;
> +
> +/* Main structures for HDCP2.2 protocol communication */
> +struct hdcp2_ake_init {
> +	uint8_t			msg_id;
> +	uint8_t			r_tx[HDCP_2_2_RTX_LEN];
> +	struct hdcp2_tx_caps	tx_caps;
> +} __packed;
> +
> +struct hdcp2_ake_send_cert {
> +	uint8_t			msg_id;
> +	struct hdcp2_cert_rx	cert_rx;
> +	uint8_t			r_rx[HDCP_2_2_RRX_LEN];
> +	uint8_t			rx_caps[HDCP_2_2_RXCAPS_LEN];
> +} __packed;
> +
> +struct hdcp2_ake_no_stored_km {
> +	uint8_t			msg_id;
> +	uint8_t			e_kpub_km[HDCP_2_2_E_KPUB_KM_LEN];
> +} __packed;
> +
> +struct hdcp2_ake_stored_km {
> +	uint8_t			msg_id;
> +	uint8_t			e_kh_km_m[HDCP_2_2_E_KH_KM_M_LEN];
> +} __packed;
> +
> +struct hdcp2_ake_send_hprime {
> +	uint8_t			msg_id;
> +	uint8_t			h_prime[HDCP_2_2_H_PRIME_LEN];
> +} __packed;
> +
> +struct hdcp2_ake_send_pairing_info {
> +	uint8_t			msg_id;
> +	uint8_t			e_kh_km[HDCP_2_2_E_KH_KM_LEN];
> +} __packed;
> +
> +struct hdcp2_lc_init {
> +	uint8_t			msg_id;
> +	uint8_t			r_n[HDCP_2_2_RN_LEN];
> +} __packed;
> +
> +struct hdcp2_lc_send_lprime {
> +	uint8_t			msg_id;
> +	uint8_t			l_prime[HDCP_2_2_L_PRIME_LEN];
> +} __packed;
> +
> +struct hdcp2_ske_send_eks {
> +	uint8_t			msg_id;
> +	uint8_t			e_dkey_ks[HDCP_2_2_E_DKEY_KS_LEN];
> +	uint8_t			riv[HDCP_2_2_RIV_LEN];
> +} __packed;
> +
> +struct hdcp2_rep_send_receiverid_list {
> +	uint8_t			msg_id;
> +	uint8_t			rx_info[HDCP_2_2_RXINFO_LEN];
> +	uint8_t			seq_num_v[HDCP_2_2_SEQ_NUM_LEN];
> +	uint8_t			v_prime[HDCP_2_2_LPRIME_HALF_LEN];
> +	uint8_t			receiver_ids[HDCP_2_2_RECEIVER_IDS_MAX_LEN];
> +} __packed;
> +
> +struct hdcp2_rep_send_ack {
> +	uint8_t			msg_id;
> +	uint8_t			v[HDCP_2_2_LPRIME_HALF_LEN];
> +} __packed;
> +
> +struct hdcp2_rep_stream_manage {
> +	uint8_t			msg_id;
> +	uint8_t			seq_num_m[HDCP_2_2_SEQ_NUM_LEN];
> +	__be16			k;
> +	struct hdcp2_streamid_type streams[HDCP_2_2_MAX_CONTENT_STREAMS_CNT];
> +} __packed;
> +
> +struct hdcp2_rep_stream_ready {
> +	uint8_t			msg_id;
> +	uint8_t			m_prime[HDCP_2_2_MPRIME_LEN];
> +} __packed;
> +
> +struct hdcp2_dp_errata_stream_type {
> +	uint8_t			msg_id;
> +	uint8_t			stream_type;
> +} __packed;

Perhaps this has already been asked and answered, but do all of these need to be
__packed? This is kind of the problem with adding a bunch of unused structures
to a patch, it's hard to see what their usage is. In future, these should
probably be introduced when they're being used.

Sean

> +
>  #endif
> -- 
> 2.7.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux