[PATCH v4 10/11] drm/bridge: it6505: fix HDCP CTS ksv wait timer

[PATCH v4 10/11] drm/bridge: it6505: fix HDCP CTS ksv wait timer

[Hermes Wu]

From: Hermes Wu <Hermes.wu@ite.com.tw>

When running the HDCP CTS test on UNIGRAF DPR-100.
HDCP must disabled after waiting KSV for 5s.
Consider system ksv work schedules. The original timer has a chance to expire.

Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
Signed-off-by: Hermes Wu <Hermes.wu@ite.com.tw>
---
 drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
index e75bc1575aa8..22d9bec3faea 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2093,7 +2093,8 @@ static void it6505_hdcp_wait_ksv_list(struct work_struct *work)
 	struct it6505 *it6505 = container_of(work, struct it6505,
 					     hdcp_wait_ksv_list);
 	struct device *dev = it6505->dev;
-	unsigned int timeout = 5000;
+	/* 1B-04 fail, wait to long to Stop encription(5s->3s). */
+	unsigned int timeout = 3000;
 	u8 bstatus = 0;
 	bool ksv_list_check;
 
-- 
2.34.1

[PATCH v4 11/11] drm/bridge: it6505: Add aux i2c functionality

[Hermes Wu]

From: Hermes Wu <Hermes.wu@ite.com.tw>

Add aux-i2c operaction in order to support the MCCS function.


Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
Signed-off-by: Hermes Wu <Hermes.wu@ite.com.tw>
---
 drivers/gpu/drm/bridge/ite-it6505.c | 177 +++++++++++++++++++++++++++-
 1 file changed, 175 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
index 22d9bec3faea..95a156ff4790 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -266,6 +266,18 @@
 #define REG_SSC_CTRL1 0x189
 #define REG_SSC_CTRL2 0x18A
 
+#define REG_AUX_USER_CTRL 0x190
+#define EN_USER_AUX BIT(0)
+#define USER_AUX_DONE BIT(1)
+#define AUX_EVENT BIT(4)
+
+#define REG_AUX_USER_DATA_REC 0x191
+#define M_AUX_IN_REC   0xF0
+#define M_AUX_OUT_REC  0x0F
+
+#define REG_AUX_USER_REPLY 0x19A
+#define REG_AUX_USER_RXB(n) ((n) + 0x19B)
+
 #define RBR DP_LINK_BW_1_62
 #define HBR DP_LINK_BW_2_7
 #define HBR2 DP_LINK_BW_5_4
@@ -301,6 +313,8 @@
 #define MAX_EQ_LEVEL 0x03
 #define AUX_WAIT_TIMEOUT_MS 15
 #define AUX_FIFO_MAX_SIZE 16
+#define AUX_I2C_MAX_SIZE 4
+#define AUX_I2C_DEFER_RETRY 4
 #define PIXEL_CLK_DELAY 1
 #define PIXEL_CLK_INVERSE 0
 #define ADJUST_PHASE_THRESHOLD 80000
@@ -323,7 +337,12 @@
 enum aux_cmd_type {
 	CMD_AUX_NATIVE_READ = 0x0,
 	CMD_AUX_NATIVE_WRITE = 0x5,
+	CMD_AUX_GI2C_ADR = 0x08,
+	CMD_AUX_GI2C_READ = 0x09,
+	CMD_AUX_GI2C_WRITE = 0x0A,
 	CMD_AUX_I2C_EDID_READ = 0xB,
+	CMD_AUX_I2C_READ = 0x0D,
+	CMD_AUX_I2C_WRITE = 0x0C,
 
 	/* KSV list read using AUX native read with FIFO */
 	CMD_AUX_GET_KSV_LIST = 0x10,
@@ -1106,6 +1125,161 @@ static ssize_t it6505_aux_do_transfer(struct it6505 *it6505,
 	return ret;
 }
 
+static bool it6505_aux_i2c_reply_defer(u8 reply)
+{
+	if (reply == DP_AUX_NATIVE_REPLY_DEFER || reply == DP_AUX_I2C_REPLY_DEFER)
+		return true;
+	return false;
+}
+
+static bool it6505_aux_i2c_reply_nack(u8 reply)
+{
+	if (reply == DP_AUX_NATIVE_REPLY_NACK || reply == DP_AUX_I2C_REPLY_NACK)
+		return true;
+	return false;
+}
+
+static int it6505_aux_i2c_wait(struct it6505 *it6505, u8 *reply)
+{
+	int err;
+	unsigned long timeout;
+	struct device *dev = it6505->dev;
+
+	timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1;
+
+	do {
+		if (it6505_read(it6505, REG_AUX_USER_CTRL) & AUX_EVENT)
+			break;
+		if (time_after(jiffies, timeout)) {
+			dev_err(dev, "Timed out waiting AUX I2C, BUSY = %X\n",
+				it6505_aux_op_finished(it6505));
+			err = -ETIMEDOUT;
+			goto end_aux_i2c_wait;
+		}
+		usleep_range(300, 800);
+	} while (!it6505_aux_op_finished(it6505));
+
+	*reply = it6505_read(it6505, REG_AUX_USER_REPLY) >> 4;
+
+	if (*reply == 0)
+		goto end_aux_i2c_wait;
+
+	if (it6505_aux_i2c_reply_defer(*reply))
+		err = -EBUSY;
+	else if (it6505_aux_i2c_reply_nack(*reply))
+		err = -ENXIO;
+
+end_aux_i2c_wait:
+	it6505_set_bits(it6505, REG_AUX_USER_CTRL, USER_AUX_DONE, USER_AUX_DONE);
+	return err;
+}
+
+static int it6505_aux_i2c_readb(struct it6505 *it6505, u8 *buf, size_t size, u8 *reply)
+{
+	int ret, i;
+	int retry;
+
+	for (retry = 0; retry < AUX_I2C_DEFER_RETRY; retry++) {
+		it6505_write(it6505, REG_AUX_CMD_REQ, CMD_AUX_GI2C_READ);
+
+		ret = it6505_aux_i2c_wait(it6505, reply);
+		if (it6505_aux_i2c_reply_defer(*reply))
+			continue;
+		if (ret >= 0)
+			break;
+	}
+
+	for (i = 0; i < size; i++)
+		buf[i] = it6505_read(it6505, REG_AUX_USER_RXB(0 + i));
+
+	return size;
+}
+
+static int it6505_aux_i2c_writeb(struct it6505 *it6505, u8 *buf, size_t size, u8 *reply)
+{
+	int i, ret;
+	int retry;
+
+	for (i = 0; i < size; i++)
+		it6505_write(it6505, REG_AUX_OUT_DATA0 + i, buf[i]);
+
+	for (retry = 0; retry < AUX_I2C_DEFER_RETRY; retry++) {
+		it6505_write(it6505, REG_AUX_CMD_REQ, CMD_AUX_GI2C_WRITE);
+
+		ret = it6505_aux_i2c_wait(it6505, reply);
+		if (it6505_aux_i2c_reply_defer(*reply))
+			continue;
+		if (ret >= 0)
+			break;
+	}
+	return size;
+}
+
+static ssize_t it6505_aux_i2c_operation(struct it6505 *it6505,
+					struct drm_dp_aux_msg *msg)
+{
+	int ret;
+	ssize_t request_size, data_cnt = 0;
+	u8 *buffer = msg->buffer;
+
+	/* set AUX user mode */
+	it6505_set_bits(it6505, REG_AUX_CTRL,
+			AUX_USER_MODE | AUX_NO_SEGMENT_WR, AUX_USER_MODE);
+	it6505_set_bits(it6505, REG_AUX_USER_CTRL, EN_USER_AUX, EN_USER_AUX);
+	/* clear AUX FIFO */
+	it6505_set_bits(it6505, REG_AUX_CTRL,
+			AUX_EN_FIFO_READ | CLR_EDID_FIFO,
+			AUX_EN_FIFO_READ | CLR_EDID_FIFO);
+
+	it6505_set_bits(it6505, REG_AUX_CTRL,
+			AUX_EN_FIFO_READ | CLR_EDID_FIFO, 0x00);
+
+	it6505_write(it6505, REG_AUX_ADR_0_7, 0x00);
+	it6505_write(it6505, REG_AUX_ADR_8_15, msg->address << 1);
+
+	if (msg->size == 0) {
+		/* IIC Start/STOP dummy write */
+		it6505_write(it6505, REG_AUX_ADR_16_19, msg->request);
+		it6505_write(it6505, REG_AUX_CMD_REQ, CMD_AUX_GI2C_ADR);
+
+		ret = it6505_aux_i2c_wait(it6505, &msg->reply);
+		goto end_aux_i2c_transfer;
+	}
+
+	/* IIC data transfer */
+	for (data_cnt = 0; data_cnt < msg->size; ) {
+		request_size = min_t(ssize_t, msg->size - data_cnt, AUX_I2C_MAX_SIZE);
+		it6505_write(it6505, REG_AUX_ADR_16_19,
+			     msg->request | ((request_size - 1) << 4));
+		if ((msg->request & DP_AUX_I2C_READ) == DP_AUX_I2C_READ)
+			ret = it6505_aux_i2c_readb(it6505, &buffer[data_cnt],
+						   equest_size, &msg->reply);
+		else
+			ret = it6505_aux_i2c_writeb(it6505, &buffer[data_cnt],
+						    request_size, &msg->reply);
+
+		if (ret < 0)
+			goto end_aux_i2c_transfer;
+
+		data_cnt += request_size;
+	}
+	ret = data_cnt;
+end_aux_i2c_transfer:
+
+	it6505_set_bits(it6505, REG_AUX_USER_CTRL, EN_USER_AUX, 0);
+	it6505_set_bits(it6505, REG_AUX_CTRL, AUX_USER_MODE, 0);
+	return ret;
+}
+
+static ssize_t it6505_aux_i2c_transfer(struct drm_dp_aux *aux,
+				       struct drm_dp_aux_msg *msg)
+{
+	struct it6505 *it6505 = container_of(aux, struct it6505, aux);
+
+	guard(mutex)(&it6505->aux_lock);
+	return it6505_aux_i2c_operation(it6505, msg);
+}
+
 static ssize_t it6505_aux_transfer(struct drm_dp_aux *aux,
 				   struct drm_dp_aux_msg *msg)
 {
@@ -1115,9 +1289,8 @@ static ssize_t it6505_aux_transfer(struct drm_dp_aux *aux,
 	int ret;
 	enum aux_cmd_reply reply;
 
-	/* IT6505 doesn't support arbitrary I2C read / write. */
 	if (is_i2c)
-		return -EINVAL;
+		return it6505_aux_i2c_transfer(aux, msg);
 
 	switch (msg->request) {
 	case DP_AUX_NATIVE_READ:
-- 
2.34.1

Re: [PATCH v4 11/11] drm/bridge: it6505: Add aux i2c functionality

[Dmitry Baryshkov]

On Thu, Sep 26, 2024 at 03:51:34PM GMT, Hermes Wu wrote:
> From: Hermes Wu <Hermes.wu@ite.com.tw>
> 
> Add aux-i2c operaction in order to support the MCCS function.

Brevity is the soul of wit. However in the commit message we appreciate
more details. Is it enough to get monitor control to work? Or is there
anything left to be implemented?

> 
> 
> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")

This is definitely not a fix.

> Signed-off-by: Hermes Wu <Hermes.wu@ite.com.tw>
> ---
>  drivers/gpu/drm/bridge/ite-it6505.c | 177 +++++++++++++++++++++++++++-
>  1 file changed, 175 insertions(+), 2 deletions(-)

-- 
With best wishes
Dmitry

RE: [PATCH v4 11/11] drm/bridge: it6505: Add aux i2c functionality

[Hermes.Wu]

>-----Original Message-----
>From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> 
>Sent: Thursday, September 26, 2024 8:58 PM
>To: Hermes Wu (吳佳宏) <Hermes.Wu@ite.com.tw>
>Cc: Kenneth Hung (洪家倫) <Kenneth.Hung@ite.com.tw>; Andrzej Hajda <andrzej.hajda@intel.com>; Neil Armstrong <neil.armstrong@linaro.org>; Robert Foss <rfoss@kernel.org>; Laurent Pinchart <Laurent.pinchart@ideasonboard.com>; Jonas Karlman <jonas@kwiboo.se>; Jernej Skrabec <jernej.skrabec@gmail.com>; Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>; David Airlie <airlied@gmail.com>; Simona Vetter <simona@ffwll.ch>; AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>; Allen Chen <allen.chen@ite.com.tw>; open list:DRM DRIVERS <dri-devel@lists.freedesktop.org>; open list <linux-kernel@vger.kernel.org>
>Subject: Re: [PATCH v4 11/11] drm/bridge: it6505: Add aux i2c functionality
>
>On Thu, Sep 26, 2024 at 03:51:34PM GMT, Hermes Wu wrote:
>> From: Hermes Wu <Hermes.wu@ite.com.tw>
>> 
>> Add aux-i2c operaction in order to support the MCCS function.
>
>Brevity is the soul of wit. However in the commit message we appreciate more details. Is it enough to get monitor control to work? Or is there anything left to be implemented?

In drm_dp_helper, drm_dp_i2c_xfer() pack I2C request into sequence of AUX request.
it6505_aux_i2c_operation() is implement to match drm_dp_i2c_xfer() behavior 

>> 
>> 
>> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
>
>This is definitely not a fix.

will remove.

>> Signed-off-by: Hermes Wu <Hermes.wu@ite.com.tw>
>> ---
>>  drivers/gpu/drm/bridge/ite-it6505.c | 177 
>> +++++++++++++++++++++++++++-
>>  1 file changed, 175 insertions(+), 2 deletions(-)
>
>--
>With best wishes
>Dmitry
>
BR,
Hermes

Re: [PATCH v4 11/11] drm/bridge: it6505: Add aux i2c functionality

[Dmitry Baryshkov]

On Fri, 27 Sept 2024 at 04:43, <Hermes.Wu@ite.com.tw> wrote:
>
>
> >-----Original Message-----
> >From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> >Sent: Thursday, September 26, 2024 8:58 PM
> >To: Hermes Wu (吳佳宏) <Hermes.Wu@ite.com.tw>
> >Cc: Kenneth Hung (洪家倫) <Kenneth.Hung@ite.com.tw>; Andrzej Hajda <andrzej.hajda@intel.com>; Neil Armstrong <neil.armstrong@linaro.org>; Robert Foss <rfoss@kernel.org>; Laurent Pinchart <Laurent.pinchart@ideasonboard.com>; Jonas Karlman <jonas@kwiboo.se>; Jernej Skrabec <jernej.skrabec@gmail.com>; Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>; David Airlie <airlied@gmail.com>; Simona Vetter <simona@ffwll.ch>; AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>; Allen Chen <allen.chen@ite.com.tw>; open list:DRM DRIVERS <dri-devel@lists.freedesktop.org>; open list <linux-kernel@vger.kernel.org>
> >Subject: Re: [PATCH v4 11/11] drm/bridge: it6505: Add aux i2c functionality
> >
> >On Thu, Sep 26, 2024 at 03:51:34PM GMT, Hermes Wu wrote:
> >> From: Hermes Wu <Hermes.wu@ite.com.tw>
> >>
> >> Add aux-i2c operaction in order to support the MCCS function.
> >
> >Brevity is the soul of wit. However in the commit message we appreciate more details. Is it enough to get monitor control to work? Or is there anything left to be implemented?
>
> In drm_dp_helper, drm_dp_i2c_xfer() pack I2C request into sequence of AUX request.
> it6505_aux_i2c_operation() is implement to match drm_dp_i2c_xfer() behavior

Commit message, please.

>
> >>
> >>
> >> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
> >
> >This is definitely not a fix.
>
> will remove.
>
> >> Signed-off-by: Hermes Wu <Hermes.wu@ite.com.tw>
> >> ---
> >>  drivers/gpu/drm/bridge/ite-it6505.c | 177
> >> +++++++++++++++++++++++++++-
> >>  1 file changed, 175 insertions(+), 2 deletions(-)
> >
> >--
> >With best wishes
> >Dmitry
> >
> BR,
> Hermes



-- 
With best wishes
Dmitry

Re: [PATCH v4 10/11] drm/bridge: it6505: fix HDCP CTS ksv wait timer

[Dmitry Baryshkov]

On Thu, Sep 26, 2024 at 03:51:33PM GMT, Hermes Wu wrote:
> From: Hermes Wu <Hermes.wu@ite.com.tw>
> 
> When running the HDCP CTS test on UNIGRAF DPR-100.
> HDCP must disabled after waiting KSV for 5s.
> Consider system ksv work schedules. The original timer has a chance to expire.

I can't understand two last sentences, excuse me.

Nit: KSV, not ksv

> 
> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
> Signed-off-by: Hermes Wu <Hermes.wu@ite.com.tw>
> ---
>  drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
> index e75bc1575aa8..22d9bec3faea 100644
> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -2093,7 +2093,8 @@ static void it6505_hdcp_wait_ksv_list(struct work_struct *work)
>  	struct it6505 *it6505 = container_of(work, struct it6505,
>  					     hdcp_wait_ksv_list);
>  	struct device *dev = it6505->dev;
> -	unsigned int timeout = 5000;
> +	/* 1B-04 fail, wait to long to Stop encription(5s->3s). */

encryption, most likely it's also "too long".

> +	unsigned int timeout = 3000;

What is the timeout per the standard?

>  	u8 bstatus = 0;
>  	bool ksv_list_check;
>  
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

RE: [PATCH v4 10/11] drm/bridge: it6505: fix HDCP CTS ksv wait timer

[Hermes.Wu]

>On Thu, Sep 26, 2024 at 03:51:33PM GMT, Hermes Wu wrote:
>> From: Hermes Wu <Hermes.wu@ite.com.tw>
>> 
>> When running the HDCP CTS test on UNIGRAF DPR-100.
>> HDCP must disabled after waiting KSV for 5s.
>> Consider system ksv work schedules. The original timer has a chance to expire.
>
>I can't understand two last sentences, excuse me.
>
>Nit: KSV, not ksv

Form HDCP CTS, DUT should wait downstream KSV list at least 5s.
And driver use a while loop with a 20ms sleep to reach the scope.
The true wait timer will reach 10s which is much longer then it supposed to.

It should better use other APIs to implement this waiting, rather than just reduce the counter.

	timeout /= 20;
	while (timeout > 0) {
		if (!it6505_get_sink_hpd_status(it6505))
			return;

		bstatus = it6505_dpcd_read(it6505, DP_AUX_HDCP_BSTATUS);

		if (bstatus & DP_BSTATUS_READY)
			break;

		msleep(20);
		timeout--;
	}

>> 
>> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
>> Signed-off-by: Hermes Wu <Hermes.wu@ite.com.tw>
>> ---
>>  drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
>> index e75bc1575aa8..22d9bec3faea 100644
>> --- a/drivers/gpu/drm/bridge/ite-it6505.c
>> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
>> @@ -2093,7 +2093,8 @@ static void it6505_hdcp_wait_ksv_list(struct work_struct *work)
>>  	struct it6505 *it6505 = container_of(work, struct it6505,
>>  					     hdcp_wait_ksv_list);
>>  	struct device *dev = it6505->dev;
>> -	unsigned int timeout = 5000;
>> +	/* 1B-04 fail, wait to long to Stop encription(5s->3s). */
>
>encryption, most likely it's also "too long".
>
>> +	unsigned int timeout = 3000;
>
>What is the timeout per the standard?
>
>>  	u8 bstatus = 0;
>>  	bool ksv_list_check;
>>  
>> -- 
>> 2.34.1
>> 
>
>-- 
>With best wishes
>Dmitry
>

Re: [PATCH v4 10/11] drm/bridge: it6505: fix HDCP CTS ksv wait timer

[Dmitry Baryshkov]

On Thu, 26 Sept 2024 at 10:39, <Hermes.Wu@ite.com.tw> wrote:
>
> >On Thu, Sep 26, 2024 at 03:51:33PM GMT, Hermes Wu wrote:
> >> From: Hermes Wu <Hermes.wu@ite.com.tw>
> >>
> >> When running the HDCP CTS test on UNIGRAF DPR-100.
> >> HDCP must disabled after waiting KSV for 5s.
> >> Consider system ksv work schedules. The original timer has a chance to expire.
> >
> >I can't understand two last sentences, excuse me.
> >
> >Nit: KSV, not ksv
>
> Form HDCP CTS, DUT should wait downstream KSV list at least 5s.
> And driver use a while loop with a 20ms sleep to reach the scope.
> The true wait timer will reach 10s which is much longer then it supposed to.
>
> It should better use other APIs to implement this waiting, rather than just reduce the counter.

See all the macros in <linux/iopoll.h>, maybe that helps. Consider
adding a version of read_poll_timeout with the in-loop break
condition.

>
>         timeout /= 20;
>         while (timeout > 0) {
>                 if (!it6505_get_sink_hpd_status(it6505))
>                         return;
>
>                 bstatus = it6505_dpcd_read(it6505, DP_AUX_HDCP_BSTATUS);
>
>                 if (bstatus & DP_BSTATUS_READY)
>                         break;
>
>                 msleep(20);
>                 timeout--;
>         }
>
> >>
> >> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
> >> Signed-off-by: Hermes Wu <Hermes.wu@ite.com.tw>
> >> ---
> >>  drivers/gpu/drm/bridge/ite-it6505.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
> >> index e75bc1575aa8..22d9bec3faea 100644
> >> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> >> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> >> @@ -2093,7 +2093,8 @@ static void it6505_hdcp_wait_ksv_list(struct work_struct *work)
> >>      struct it6505 *it6505 = container_of(work, struct it6505,
> >>                                           hdcp_wait_ksv_list);
> >>      struct device *dev = it6505->dev;
> >> -    unsigned int timeout = 5000;
> >> +    /* 1B-04 fail, wait to long to Stop encription(5s->3s). */
> >
> >encryption, most likely it's also "too long".
> >
> >> +    unsigned int timeout = 3000;
> >
> >What is the timeout per the standard?
> >
> >>      u8 bstatus = 0;
> >>      bool ksv_list_check;
> >>
> >> --
> >> 2.34.1
> >>
> >
> >--
> >With best wishes
> >Dmitry
> >



-- 
With best wishes
Dmitry