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: <aJyN1uX60BJQYDHj@smile.fi.intel.com>
Date: Wed, 13 Aug 2025 16:06:30 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Gabor Juhos <j4g8y7@...il.com>
Cc: Wolfram Sang <wsa@...nel.org>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Andi Shyti <andi.shyti@...nel.org>,
	Russell King <rmk+kernel@...linux.org.uk>,
	Andrew Lunn <andrew@...n.ch>, Hanna Hawa <hhhawa@...zon.com>,
	Robert Marko <robert.marko@...tura.hr>,
	Linus Walleij <linus.walleij@...aro.org>, linux-i2c@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Imre Kaloz <kaloz@...nwrt.org>, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/3] i2c: add init_recovery() callback

On Wed, Aug 13, 2025 at 12:24:22PM +0200, Gabor Juhos wrote:
> 2025. 08. 11. 22:17 keltezéssel, Andy Shevchenko írta:
> > On Mon, Aug 11, 2025 at 09:49:55PM +0200, Gabor Juhos wrote:

...

> >> This is needed for the 'i2c-pxa' driver in order to be able to fix
> >> a long standing bug for which the fix will be implemented in a

The above left for some context for the below discussion.

...

> > The first traditional question is why the generic recovery is not working.
> 
> The details are in the driver specific patches. Should I write it all down here too?

Instead of the above paragraph, give a summary of your use case to answer 'why'
it can not be done differently.

...

> >> -	if (i2c_gpio_init_recovery(adap) == -EPROBE_DEFER)
> >> +	if (bri->init_recovery) {
> >> +		ret = bri->init_recovery(adap);
> >> +		if (ret)
> >> +			return ret;
> > 
> >> +	} else if (i2c_gpio_init_recovery(adap) == -EPROBE_DEFER) {
> >>  		return -EPROBE_DEFER;
> >> +	}
> > 
> > If the above stays, I think we would drop the last and always have
> > init_recovery to be assigned.
> 
> In that case we would have something like this:
> 
>     if (!bri->init_recovery)
>         bri->init_recovery = i2c_gpio_init_recovery;
> 
>     ret = bri->init_recovery(adap);
>     if (ret)
>         return ret;
> 
> Since the callback is used only once, and within the same fuction where it is
> assigned, I don't really see the advantage of the assignment. Although it
> definitely looks cleaner as far as error handling is concerned.
> 
> Originally, I have used the following solution:
> 
>     if (bri->init_recovery)
>         ret = bri->init_recovery(adap);
>     else
>         ret = i2c_gpio_init_recovery(adap);

> 

Without this blank line...

>     if (ret)
>         return ret;

...this looks like the best compromise among proposed implementations.

> However the existing code ignores errors from i2c_gpio_init_recovery() except
> EPROBE_DEFER, so I changed this to the code proposed in the patch in order to
> keep the existing behaviour.

-- 
With Best Regards,
Andy Shevchenko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ