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: <57bfde5b-aee1-c15f-896a-63033e86d9a2@ti.com>
Date:   Mon, 2 Nov 2020 08:57:08 +0200
From:   Tomi Valkeinen <tomi.valkeinen@...com>
To:     Sam Ravnborg <sam@...nborg.org>, YueHaibing <yuehaibing@...wei.com>
CC:     <a.hajda@...sung.com>, <narmstrong@...libre.com>,
        <Laurent.pinchart@...asonboard.com>, <jonas@...boo.se>,
        <jernej.skrabec@...l.net>, <airlied@...ux.ie>, <daniel@...ll.ch>,
        <sebastian.reichel@...labora.com>,
        <dri-devel@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/bridge: tpd12s015: Fix irq registering in
 tpd12s015_probe

On 31/10/2020 09:19, Sam Ravnborg wrote:
> Hi YueHaibing
> 
> Thanks for the fix. Appreciated but please update as per comments below.
> 
> On Sat, Oct 31, 2020 at 11:16:48AM +0800, YueHaibing wrote:
>> gpiod_to_irq() return negative value in case of error,
>> the existing code handle negative error codes wrongly.
>>
>> Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level shifter")
>> Signed-off-by: YueHaibing <yuehaibing@...wei.com>
>> ---
>>  drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c b/drivers/gpu/drm/bridge/ti-tpd12s015.c
>> index 514cbf0eac75..a18d5197c16c 100644
>> --- a/drivers/gpu/drm/bridge/ti-tpd12s015.c
>> +++ b/drivers/gpu/drm/bridge/ti-tpd12s015.c
>> @@ -160,7 +160,7 @@ static int tpd12s015_probe(struct platform_device *pdev)
>>  
>>  	/* Register the IRQ if the HPD GPIO is IRQ-capable. */
>>  	tpd->hpd_irq = gpiod_to_irq(tpd->hpd_gpio);
>> -	if (tpd->hpd_irq) {
>> +	if (tpd->hpd_irq > 0) {
>>  		ret = devm_request_threaded_irq(&pdev->dev, tpd->hpd_irq, NULL,
>>  						tpd12s015_hpd_isr,
>>  						IRQF_TRIGGER_RISING |
> 
> The current implmentation will skip devm_request_threaded_irq() in case
> or error - but continue with the rest of the function. So the
> driver fails to return an error code.

That is intended. If the HPD gpio supports IRQs (gpiod_to_irq returns a valid number), we use the
IRQ. If it doesn't (gpiod_to_irq returns an error), it gets polled via detect(). Both are ok.

I don't know if the gpiod_to_irq never returning 0 is something we should rely on. The docs say
gpiod_to_irq returns the irq number or an error, so I think checking for >= 0 matches the docs better.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ