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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA8EJpq2rZu5ciSc4Zg6cO66B9b7QLszgZjhhqX6Mk2Q0sHpdQ@mail.gmail.com>
Date: Thu, 26 Sep 2024 11:22:46 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Hermes.Wu@....com.tw
Cc: Kenneth.Hung@....com.tw, andrzej.hajda@...el.com, 
	neil.armstrong@...aro.org, rfoss@...nel.org, 
	Laurent.pinchart@...asonboard.com, jonas@...boo.se, jernej.skrabec@...il.com, 
	maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de, 
	airlied@...il.com, simona@...ll.ch, angelogioacchino.delregno@...labora.com, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 10/11] drm/bridge: it6505: fix HDCP CTS ksv wait timer

On Thu, 26 Sept 2024 at 10:39, <Hermes.Wu@....com.tw> wrote:
>
> >On Thu, Sep 26, 2024 at 03:51:33PM GMT, Hermes Wu wrote:
> >> From: Hermes Wu <Hermes.wu@....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@....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