Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Thu, Dec 20, 2018 at 03:55:27PM +0100, Daniel Vetter wrote:
> On Thu, Dec 20, 2018 at 02:28:55PM +, Winkler, Tomas wrote:
> >
> >
> > > On Wed, 19 Dec 2018, "Winkler, Tomas" wrote:
> > > >>
> > > >> On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
> > > >> > On 12/19/2018 8:05 PM, Daniel Vetter wrote:
> > > >> >> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> > > >> >>> struct intel_hdcp {
> > > >> >>> @@ -414,6 +430,24 @@ struct intel_hdcp {
> > > >> >>> */
> > > >> >>>u8 content_type;
> > > >> >>>struct hdcp_port_data port_data;
> > > >> >>> +
> > > >> >>> + u8 is_paired;
> > > >> >>> + u8 is_repeater;
> > > >> >> Make these two bool, will simplify the code a bunch.
> > > >> >
> > > >> > Seems there is a movement for not to use the bool in structures.
> > > >>
> > > >> No. Please use bools in structs when it makes sense. Avoid bools in
> > > >> structs when you need to care about memory footprint or alignment or
> > > >> packing or the like. This is not one of those cases.
> > > >>
> > > >> > Thats why I have changed these from bool to u8 from v8 onwards.
> > > >> > Checkpatch also complains on this
> > > >>
> > > >> Sorry to say, checkpatch is not the authority although we do send out
> > > >> automated checkpatch results.
> > > >
> > > > I believe it was Linus' call to not use bool in structs at all
> > > > https://lkml.org/lkml/2017/11/21/384
> > >
> > > I don't care. That's a valid judgement in the context referenced, but the
> > > conclusion "no bools in structs at all" isn't. In this case, I think
> > > bools are the
> > > better option, and anything else makes the code worse.
> >
> > The solution was to use bit fields,
> > unsinged int is_paired:1;
> > unsinged int is_repeter:1
>
> This doesn't work with READ_ONCE/WRITE_ONCE, and it generates terrible
> assembly (at least gcc is well known for struggling with these, compared
> to open-coded bitops). So depending upon what you want to do, and where
> youre space/performance tradeoff lies, doing this unconditionally is just
> wrong.
Another annoying downside with non-bool bitfields:
unsigned int foo:1;
foo = 2;
-> foo == 0
So you'll need to remmber to convert everything to
0/1 before the assignment.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Thu, Dec 20, 2018 at 02:28:55PM +, Winkler, Tomas wrote:
>
>
> > On Wed, 19 Dec 2018, "Winkler, Tomas" wrote:
> > >>
> > >> On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
> > >> > On 12/19/2018 8:05 PM, Daniel Vetter wrote:
> > >> >> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> > >> >>> struct intel_hdcp {
> > >> >>> @@ -414,6 +430,24 @@ struct intel_hdcp {
> > >> >>> */
> > >> >>> u8 content_type;
> > >> >>> struct hdcp_port_data port_data;
> > >> >>> +
> > >> >>> +u8 is_paired;
> > >> >>> +u8 is_repeater;
> > >> >> Make these two bool, will simplify the code a bunch.
> > >> >
> > >> > Seems there is a movement for not to use the bool in structures.
> > >>
> > >> No. Please use bools in structs when it makes sense. Avoid bools in
> > >> structs when you need to care about memory footprint or alignment or
> > >> packing or the like. This is not one of those cases.
> > >>
> > >> > Thats why I have changed these from bool to u8 from v8 onwards.
> > >> > Checkpatch also complains on this
> > >>
> > >> Sorry to say, checkpatch is not the authority although we do send out
> > >> automated checkpatch results.
> > >
> > > I believe it was Linus' call to not use bool in structs at all
> > > https://lkml.org/lkml/2017/11/21/384
> >
> > I don't care. That's a valid judgement in the context referenced, but the
> > conclusion "no bools in structs at all" isn't. In this case, I think bools
> > are the
> > better option, and anything else makes the code worse.
>
> The solution was to use bit fields,
> unsinged int is_paired:1;
> unsinged int is_repeter:1
This doesn't work with READ_ONCE/WRITE_ONCE, and it generates terrible
assembly (at least gcc is well known for struggling with these, compared
to open-coded bitops). So depending upon what you want to do, and where
youre space/performance tradeoff lies, doing this unconditionally is just
wrong.
It was the right thing for the patch Linus commented on though.
-Daniel
> There is a strong point in consistency so there are no mistakes.
>
> But frankly I don't really have strong feelings about it.
>
> Thanks
> Tomas
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
> On Wed, 19 Dec 2018, "Winkler, Tomas" wrote:
> >>
> >> On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
> >> > On 12/19/2018 8:05 PM, Daniel Vetter wrote:
> >> >> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> >> >>> struct intel_hdcp {
> >> >>> @@ -414,6 +430,24 @@ struct intel_hdcp {
> >> >>> */
> >> >>>u8 content_type;
> >> >>>struct hdcp_port_data port_data;
> >> >>> +
> >> >>> + u8 is_paired;
> >> >>> + u8 is_repeater;
> >> >> Make these two bool, will simplify the code a bunch.
> >> >
> >> > Seems there is a movement for not to use the bool in structures.
> >>
> >> No. Please use bools in structs when it makes sense. Avoid bools in
> >> structs when you need to care about memory footprint or alignment or
> >> packing or the like. This is not one of those cases.
> >>
> >> > Thats why I have changed these from bool to u8 from v8 onwards.
> >> > Checkpatch also complains on this
> >>
> >> Sorry to say, checkpatch is not the authority although we do send out
> >> automated checkpatch results.
> >
> > I believe it was Linus' call to not use bool in structs at all
> > https://lkml.org/lkml/2017/11/21/384
>
> I don't care. That's a valid judgement in the context referenced, but the
> conclusion "no bools in structs at all" isn't. In this case, I think bools
> are the
> better option, and anything else makes the code worse.
The solution was to use bit fields,
unsinged int is_paired:1;
unsinged int is_repeter:1
There is a strong point in consistency so there are no mistakes.
But frankly I don't really have strong feelings about it.
Thanks
Tomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Wed, 19 Dec 2018, "Winkler, Tomas" wrote:
>>
>> On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
>> > On 12/19/2018 8:05 PM, Daniel Vetter wrote:
>> >> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
>> >>> struct intel_hdcp {
>> >>> @@ -414,6 +430,24 @@ struct intel_hdcp {
>> >>> */
>> >>> u8 content_type;
>> >>> struct hdcp_port_data port_data;
>> >>> +
>> >>> +u8 is_paired;
>> >>> +u8 is_repeater;
>> >> Make these two bool, will simplify the code a bunch.
>> >
>> > Seems there is a movement for not to use the bool in structures.
>>
>> No. Please use bools in structs when it makes sense. Avoid bools in structs
>> when you need to care about memory footprint or alignment or packing or
>> the like. This is not one of those cases.
>>
>> > Thats why I have changed these from bool to u8 from v8 onwards.
>> > Checkpatch also complains on this
>>
>> Sorry to say, checkpatch is not the authority although we do send out
>> automated checkpatch results.
>
> I believe it was Linus' call to not use bool in structs at all
> https://lkml.org/lkml/2017/11/21/384
I don't care. That's a valid judgement in the context referenced, but
the conclusion "no bools in structs at all" isn't. In this case, I think
bools are the better option, and anything else makes the code worse.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
>
> On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
> > On 12/19/2018 8:05 PM, Daniel Vetter wrote:
> >> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> >>> struct intel_hdcp {
> >>> @@ -414,6 +430,24 @@ struct intel_hdcp {
> >>>*/
> >>> u8 content_type;
> >>> struct hdcp_port_data port_data;
> >>> +
> >>> + u8 is_paired;
> >>> + u8 is_repeater;
> >> Make these two bool, will simplify the code a bunch.
> >
> > Seems there is a movement for not to use the bool in structures.
>
> No. Please use bools in structs when it makes sense. Avoid bools in structs
> when you need to care about memory footprint or alignment or packing or
> the like. This is not one of those cases.
>
> > Thats why I have changed these from bool to u8 from v8 onwards.
> > Checkpatch also complains on this
>
> Sorry to say, checkpatch is not the authority although we do send out
> automated checkpatch results.
I believe it was Linus' call to not use bool in structs at all
https://lkml.org/lkml/2017/11/21/384
Thanks
Tomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Wed, 19 Dec 2018, "C, Ramalingam" wrote:
> On 12/19/2018 8:05 PM, Daniel Vetter wrote:
>> On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
>>> struct intel_hdcp {
>>> @@ -414,6 +430,24 @@ struct intel_hdcp {
>>> */
>>> u8 content_type;
>>> struct hdcp_port_data port_data;
>>> +
>>> + u8 is_paired;
>>> + u8 is_repeater;
>> Make these two bool, will simplify the code a bunch.
>
> Seems there is a movement for not to use the bool in structures.
No. Please use bools in structs when it makes sense. Avoid bools in
structs when you need to care about memory footprint or alignment or
packing or the like. This is not one of those cases.
> Thats why I have changed these from bool to u8 from v8
> onwards. Checkpatch also complains on this
Sorry to say, checkpatch is not the authority although we do send out
automated checkpatch results.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On 12/19/2018 9:05 PM, Daniel Vetter wrote:
On Wed, Dec 19, 2018 at 08:35:48PM +0530, C, Ramalingam wrote:
On 12/19/2018 8:05 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
+ if (!hdcp->is_repeater && shim->config_stream_type) {
+ /*
+* Errata for DP: As Stream type is used for encryption,
+* Receiver should be communicated with stream type for the
+* decryption of the content.
+* Repeater will be communicated with stream type as a
+* part of it's auth later in time.
+*/
I'm not following what you want to say with this comment, and haven't
found anything in the hdcp2 dp spec about this either.
this is there in the errata of DP HDCP2.2 spec.
hdcp2.2 encryption algo involves the stream type as a parameter.
And as part of hdcp auth mentioned in base spec DP repeaters receive that
details to decrypt the content.
But DP receivers dont get it. So errata adds the missing piece for decryption.
Ok I found it, but the fake HDCP_2_2_ERRATA_DP_STREAM_TYPE define is kinda
annoying. It doesn't exist in the spec, but we put it into the drm_hdcp.h
header. Since you have a special ->config_stream_type hook for this
anyway, and it's only needed for DP, please move that into the shim
implementation.
And then a follow-up patch to remove the fake #define from drm_hdcp.h.
This is defined to make the hdcp_shim interface to look common between DP and
HDMI.
We can move this errata msg definition and its msg_id into intel_drv.h just for
the intel's consumption.
-Ram
-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Wed, Dec 19, 2018 at 08:35:48PM +0530, C, Ramalingam wrote:
> On 12/19/2018 8:05 PM, Daniel Vetter wrote:
> > On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> > > + if (!hdcp->is_repeater && shim->config_stream_type) {
> > > + /*
> > > + * Errata for DP: As Stream type is used for encryption,
> > > + * Receiver should be communicated with stream type for the
> > > + * decryption of the content.
> > > + * Repeater will be communicated with stream type as a
> > > + * part of it's auth later in time.
> > > + */
> > I'm not following what you want to say with this comment, and haven't
> > found anything in the hdcp2 dp spec about this either.
>
> this is there in the errata of DP HDCP2.2 spec.
> hdcp2.2 encryption algo involves the stream type as a parameter.
> And as part of hdcp auth mentioned in base spec DP repeaters receive that
> details to decrypt the content.
> But DP receivers dont get it. So errata adds the missing piece for decryption.
Ok I found it, but the fake HDCP_2_2_ERRATA_DP_STREAM_TYPE define is kinda
annoying. It doesn't exist in the spec, but we put it into the drm_hdcp.h
header. Since you have a special ->config_stream_type hook for this
anyway, and it's only needed for DP, please move that into the shim
implementation.
And then a follow-up patch to remove the fake #define from drm_hdcp.h.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On 12/19/2018 8:05 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key exchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type configuration for receivers.
At AKE, the HDCP Receiver’s public key certificate is verified by the
HDCP Transmitter. A Master Key k m is exchanged.
At LC, the HDCP Transmitter enforces locality on the content by
requiring that the Round Trip Time (RTT) between a pair of messages
is not more than 20 ms.
At SKE, The HDCP Transmitter exchanges Session Key ks with
the HDCP Receiver.
In DP HDCP2.2 encryption and decryption logics use the stream type as
one of the parameter. So Before enabling the Encryption DP HDCP2.2
receiver needs to be communicated with stream type. This is added to
spec as ERRATA.
This generic implementation is complete only with the hdcp2 specific
functions defined at hdcp_shim.
v2: Rebased.
v3:
%s/PARING/PAIRING
Coding style fixing [Uma]
v4:
Rebased as part of patch reordering.
Defined the functions for mei services. [Daniel]
v5:
Redefined the mei service functions as per comp redesign.
Required intel_hdcp members are defined [Sean Paul]
v6:
Typo of cipher is Fixed [Uma]
%s/uintxx_t/uxx
Check for comp_master is removed.
v7:
Adjust to the new interface.
Avoid using bool structure members. [Tomas]
v8: Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 34 ++
drivers/gpu/drm/i915/intel_hdcp.c | 211 +++---
2 files changed, 230 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6d5361616ca3..a6b632d71490 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -387,6 +387,22 @@ struct intel_hdcp_shim {
/* Detects whether Panel is HDCP2.2 capable */
int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
bool *capable);
+
+ /* Write HDCP2.2 messages */
+ int (*write_2_2_msg)(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size);
+
+ /* Read HDCP2.2 messages */
+ int (*read_2_2_msg)(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, void *buf, size_t size);
+
+ /*
+* Implementation of DP HDCP2.2 Errata for the communication of stream
+* type to Receivers. In DP HDCP2.2 Stream type is one of the input to
+* the HDCP2.2 Cipher for En/De-Cryption. Not applicable for HDMI.
+*/
+ int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
+ void *buf, size_t size);
};
struct intel_hdcp {
@@ -414,6 +430,24 @@ struct intel_hdcp {
*/
u8 content_type;
struct hdcp_port_data port_data;
+
+ u8 is_paired;
+ u8 is_repeater;
Make these two bool, will simplify the code a bunch.
Seems there is a movement for not to use the bool in structures.
Thats why I have changed these from bool to u8 from v8 onwards. Checkpatch also
complains on this
+
+ /*
+* Count of ReceiverID_List received. Initialized to 0 at AKE_INIT.
+* Incremented after processing the RepeaterAuth_Send_ReceiverID_List.
+* When it rolls over re-auth has to be triggered.
+*/
+ u32 seq_num_v;
+
+ /*
+* Count of RepeaterAuth_Stream_Manage msg propagated.
+* Initialized to 0 on AKE_INIT. Incremented after every successful
+* transmission of RepeaterAuth_Stream_Manage message. When it rolls
+* over re-Auth has to be triggered.
+*/
+ u32 seq_num_m;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index f0ee448e6546..f1f0ef294e20 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -18,6 +18,7 @@
#define KEY_LOAD_TRIES 5
#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
+#define HDCP2_LC_RETRY_CNT 3
static
bool intel_hdcp_is_ksv_valid(u8 *ksv)
@@ -854,7 +855,7 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
}
-static __attribute__((unused)) int
+static int
hdcp2_prepare_ake_init(struct intel_connector *connector,
struct hdcp2_ake_init *ake_data)
{
@@ -875,7 +876,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
return ret;
}
-static __attribute__((unused)) int
+static int
hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
struct hdcp2_ake_send_cert *rx_cert,
bool *paired,
@@ -8
Re: [Intel-gfx] [PATCH v9 10/39] drm/i915: Implement HDCP2.2 receiver authentication
On Thu, Dec 13, 2018 at 09:31:12AM +0530, Ramalingam C wrote:
> Implements HDCP2.2 authentication for hdcp2.2 receivers, with
> following steps:
> Authentication and Key exchange (AKE).
> Locality Check (LC).
> Session Key Exchange(SKE).
> DP Errata for stream type configuration for receivers.
>
> At AKE, the HDCP Receiver’s public key certificate is verified by the
> HDCP Transmitter. A Master Key k m is exchanged.
>
> At LC, the HDCP Transmitter enforces locality on the content by
> requiring that the Round Trip Time (RTT) between a pair of messages
> is not more than 20 ms.
>
> At SKE, The HDCP Transmitter exchanges Session Key ks with
> the HDCP Receiver.
>
> In DP HDCP2.2 encryption and decryption logics use the stream type as
> one of the parameter. So Before enabling the Encryption DP HDCP2.2
> receiver needs to be communicated with stream type. This is added to
> spec as ERRATA.
>
> This generic implementation is complete only with the hdcp2 specific
> functions defined at hdcp_shim.
>
> v2: Rebased.
> v3:
> %s/PARING/PAIRING
> Coding style fixing [Uma]
> v4:
> Rebased as part of patch reordering.
> Defined the functions for mei services. [Daniel]
> v5:
> Redefined the mei service functions as per comp redesign.
> Required intel_hdcp members are defined [Sean Paul]
> v6:
> Typo of cipher is Fixed [Uma]
> %s/uintxx_t/uxx
> Check for comp_master is removed.
> v7:
> Adjust to the new interface.
> Avoid using bool structure members. [Tomas]
> v8: Rebased.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_drv.h | 34 ++
> drivers/gpu/drm/i915/intel_hdcp.c | 211
> +++---
> 2 files changed, 230 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6d5361616ca3..a6b632d71490 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -387,6 +387,22 @@ struct intel_hdcp_shim {
> /* Detects whether Panel is HDCP2.2 capable */
> int (*hdcp_2_2_capable)(struct intel_digital_port *intel_dig_port,
> bool *capable);
> +
> + /* Write HDCP2.2 messages */
> + int (*write_2_2_msg)(struct intel_digital_port *intel_dig_port,
> + void *buf, size_t size);
> +
> + /* Read HDCP2.2 messages */
> + int (*read_2_2_msg)(struct intel_digital_port *intel_dig_port,
> + u8 msg_id, void *buf, size_t size);
> +
> + /*
> + * Implementation of DP HDCP2.2 Errata for the communication of stream
> + * type to Receivers. In DP HDCP2.2 Stream type is one of the input to
> + * the HDCP2.2 Cipher for En/De-Cryption. Not applicable for HDMI.
> + */
> + int (*config_stream_type)(struct intel_digital_port *intel_dig_port,
> + void *buf, size_t size);
> };
>
> struct intel_hdcp {
> @@ -414,6 +430,24 @@ struct intel_hdcp {
>*/
> u8 content_type;
> struct hdcp_port_data port_data;
> +
> + u8 is_paired;
> + u8 is_repeater;
Make these two bool, will simplify the code a bunch.
> +
> + /*
> + * Count of ReceiverID_List received. Initialized to 0 at AKE_INIT.
> + * Incremented after processing the RepeaterAuth_Send_ReceiverID_List.
> + * When it rolls over re-auth has to be triggered.
> + */
> + u32 seq_num_v;
> +
> + /*
> + * Count of RepeaterAuth_Stream_Manage msg propagated.
> + * Initialized to 0 on AKE_INIT. Incremented after every successful
> + * transmission of RepeaterAuth_Stream_Manage message. When it rolls
> + * over re-Auth has to be triggered.
> + */
> + u32 seq_num_m;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index f0ee448e6546..f1f0ef294e20 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -18,6 +18,7 @@
>
> #define KEY_LOAD_TRIES 5
> #define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
> +#define HDCP2_LC_RETRY_CNT 3
>
> static
> bool intel_hdcp_is_ksv_valid(u8 *ksv)
> @@ -854,7 +855,7 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
> enum port port)
> return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
> }
>
> -static __attribute__((unused)) int
> +static int
> hdcp2_prepare_ake_init(struct intel_connector *connector,
> struct hdcp2_ake_init *ake_data)
> {
> @@ -875,7 +876,7 @@ hdcp2_prepare_ake_init(struct intel_connector *connector,
> return ret;
> }
>
> -static __attribute__((unused)) int
> +static int
> hdcp2_verify_rx_cert_prepare_km(struct intel_connector *connector,
> struct hdcp2_ake_send_cert *rx_cert,
> bool *paired,
> @@ -897,9 +898,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_con
