linux-kernel - Re: [PATCH] drm/bridge: adv7511: Exit interrupt handling when necessary

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: <CAA8EJpowLnrnV8ezXYj=oWBFFTa6LqkPFFHc9F49un6AYgZvzw@mail.gmail.com>
Date: Mon, 20 May 2024 15:00:30 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Sui Jingfeng <sui.jingfeng@...ux.dev>
Cc: Liu Ying <victor.liu@....com>, dri-devel@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, 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, daniel@...ll.ch, biju.das.jz@...renesas.com, 
	u.kleine-koenig@...gutronix.de, aford173@...il.com, jani.nikula@...el.com, 
	bli@...g-olufsen.dk
Subject: Re: [PATCH] drm/bridge: adv7511: Exit interrupt handling when necessary

On Mon, 20 May 2024 at 14:48, Sui Jingfeng <sui.jingfeng@...ux.dev> wrote:
>
> Hi,
>
>
> On 5/20/24 19:13, Dmitry Baryshkov wrote:
> > On Mon, 20 May 2024 at 14:11, Sui Jingfeng <sui.jingfeng@...ux.dev> wrote:
> >>
> >> Hi,
> >>
> >> On 5/20/24 06:11, Dmitry Baryshkov wrote:
> >>> On Thu, May 16, 2024 at 06:10:06PM +0800, Liu Ying wrote:
> >>>> Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
> >>>> fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
> >>>> no interrupt requested at all.
> >>>>
> >>>> Without interrupt, adv7511_wait_for_edid() could return -EIO sometimes,
> >>>> because it polls adv7511->edid_read flag by calling adv7511_irq_process()
> >>>> a few times, but adv7511_irq_process() happens to refuse to handle
> >>>> interrupt by returning -ENODATA.  Hence, EDID retrieval fails randomly.
> >>>>
> >>>> Fix the issue by checking adv7511->i2c_main->irq before exiting interrupt
> >>>> handling from adv7511_irq_process().
> >>>>
> >>>> Fixes: f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
> >>>> Signed-off-by: Liu Ying <victor.liu@....com>
> >>>> ---
> >>>>    drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 ++-
> >>>>    1 file changed, 2 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >>>> index 6089b0bb9321..2074fa3c1b7b 100644
> >>>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >>>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >>>> @@ -479,7 +479,8 @@ static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
> >>>>               return ret;
> >>>>
> >>>>       /* If there is no IRQ to handle, exit indicating no IRQ data */
> >>>> -    if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> >>>> +    if (adv7511->i2c_main->irq &&
> >>>> +        !(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> >>>>           !(irq1 & ADV7511_INT1_DDC_ERROR))
> >>>>               return -ENODATA;
> >>>
> >>> I think it might be better to handle -ENODATA in adv7511_wait_for_edid()
> >>> instead. WDYT?
> >>>
> >>
> >> I think this is may deserve another patch.
> >
> > My point is that the IRQ handler is fine to remove -ENODATA here,
>
> [...]
>
> > there is no pending IRQ that can be handled.
>
> But there may has other things need to do in the adv7511_irq_process()
> function.

But the function returns anyway. So, we know that the condition is broken.

>
> > So instead of continuing
> > the execution when we know that IRQ bits are not set,
>
> Even when IRQ bits are not set, it just means that there is no HPD
> and no EDID ready-to-read signal. HDMI CEC interrupts still need
> to process.

Yes. Let's get the CEC fixed. Then maybe we won't need this commit at all.

>
>
> > it's better to
> > ignore -ENODATA in the calling code and go on with msleep().
> >
>
> So, It's confusing to ignore the -ENODATA here.

[BTW: you had quotation levels wrong in two places, I've fixed them]

-- 
With best wishes
Dmitry