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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cec7e3f531d936ab34486d52bd16daee@manjaro.org>
Date: Thu, 26 Sep 2024 12:14:48 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Mark Brown <broonie@...nel.org>
Cc: Heiko Stuebner <heiko@...ech.de>, linux-spi@...r.kernel.org,
 linux-rockchip@...ts.infradead.org, oss@...ene.moe,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] spi: rockchip: Don't check for failed get_fifo_len()

Hello Mark,

On 2024-09-26 11:17, Mark Brown wrote:
> On Thu, Sep 26, 2024 at 10:55:01AM +0200, Heiko Stuebner wrote:
>> Am Donnerstag, 26. September 2024, 10:38:14 CEST schrieb Dragan Simic:
>> > Since commit 13a96935e6f6 ("spi: rockchip: Support 64-location deep FIFOs"),
>> > function get_fifo_len() can no longer return zero, so delete the redundant
>> > check for zero in function rockchip_spi_probe().
> 
>> Didn't this topic come up in another recent patch too?
> 
>> Anyway, having looked up the what the current get_fifo_len does,
>> the 0 case should never happen, as you describe, so
> 
> One of the people doing random cleanups posted the same patch which I
> pushed back on since probe() isn't a hot path and it means if
> get_fifo_len() changes again it could silently break things.

Thanks for the clarification, it makes sense to keep the check for
future proofing.  I'll drop this patch in the v2 of this series.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ