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: <20240224170225.4720f9a2@jic23-huawei>
Date: Sat, 24 Feb 2024 17:02:25 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andy@...nel.org>
Cc: Ceclan Dumitru <mitrutzceclan@...il.com>, linus.walleij@...aro.org,
 brgl@...ev.pl, linux-gpio@...r.kernel.org, Lars-Peter Clausen
 <lars@...afoo.de>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
 Michael Walle <michael@...le.cc>, Arnd Bergmann <arnd@...db.de>, ChiaEn Wu
 <chiaen_wu@...htek.com>, Niklas Schnelle <schnelle@...ux.ibm.com>, Leonard
 Göhrs <l.goehrs@...gutronix.de>, Mike Looijmans
 <mike.looijmans@...ic.nl>, Haibo Chen <haibo.chen@....com>, Hugo Villeneuve
 <hvilleneuve@...onoff.com>, David Lechner <dlechner@...libre.com>, Ceclan
 Dumitru <dumitru.ceclan@...log.com>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v13 2/3] iio: adc: ad_sigma_delta: Add optional irq
 selection

On Tue, 20 Feb 2024 16:17:52 +0200
Andy Shevchenko <andy@...nel.org> wrote:

> On Tue, Feb 20, 2024 at 04:13:12PM +0200, Ceclan Dumitru wrote:
> > On 2/20/24 16:11, Andy Shevchenko wrote:  
> > > On Tue, Feb 20, 2024 at 11:43:39AM +0200, Dumitru Ceclan wrote:  
> 
> ...
> 
> > >> +	if (!info->irq_num)
> > >> +		sigma_delta->irq_num = spi->irq;
> > >> +	else
> > >> +		sigma_delta->irq_num = info->irq_num;  
> > > 
> > > Why not positive check?
> > >   
> > Considered that selecting spi->irq is usually the default case, so it should
> > be the first branch  
> 
> Let compiler do its job, the negative conditions are harder to read/parse by
> human beings.
> 
FWIW compiler almost certainly won't figure this out as it has nothing to go on
- history based branch prediction in processors will though!  We don't want to
be hinting direction to the compiler for a case like this as that will make
it very painful if we get it wrong.  Anyhow Andy's comment is valid even if
I disagree with the reason.

Jonathan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ