[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20811ebf-04e0-4196-9d0e-bd46a88065dd@tuxon.dev>
Date: Tue, 28 Nov 2023 09:19:21 +0200
From: claudiu beznea <claudiu.beznea@...on.dev>
To: Sergey Shtylyov <s.shtylyov@....ru>, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
richardcochran@...il.com, p.zabel@...gutronix.de,
yoshihiro.shimoda.uh@...esas.com, geert+renesas@...der.be,
wsa+renesas@...g-engineering.com, robh@...nel.org,
biju.das.jz@...renesas.com,
prabhakar.mahadev-lad.rj@...renesas.com,
mitsuhiro.kimura.kc@...esas.com, masaru.nagai.vx@...esas.com
Cc: netdev@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-kernel@...r.kernel.org,
Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH 1/6] net: ravb: Check return value of
reset_control_deassert()
On 27.11.2023 18:39, Sergey Shtylyov wrote:
> On 11/27/23 12:04 PM, Claudiu wrote:
>
>> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>>
>> reset_control_deassert() could return an error. Some devices cannot work
>> if reset signal de-assert operation fails.
>
> Well, I think all devices can't work if the reset line is connected at all. :-)
I was thinking at the fact that the de-assert support was added just 2
years ago, while the driver seems to be ~8 years old.
>
>> To avoid this check the return
>> code of reset_control_deassert() in ravb_probe() and take proper action.
>
> I'd also mention moving of the free_nedev() call...
ok
>
>> Fixes: 0d13a1a464a0 ("ravb: Add reset support")
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>
> Reviewed-by: Sergey Shtylyov <s.shtylyov@....ru>
>
> [...]
>
> MBR, Sergey
Powered by blists - more mailing lists