linux-kernel - Re: [PATCH RFT v2 0/5] i3c: introduce and use generic parity helper

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: <20250103221117bb066057@mail.local>
Date: Fri, 3 Jan 2025 23:11:17 +0100
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: linux-i3c@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Guenter Roeck <linux@...ck-us.net>,
	Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
	Przemysław Gaj <pgaj@...ence.com>,
	Yury Norov <yury.norov@...il.com>
Subject: Re: [PATCH RFT v2 0/5] i3c: introduce and use generic parity helper

On 29/12/2024 11:12:28+0100, Wolfram Sang wrote:
> Changes since v1:
> 
> * renamed from 'get_parity8' to 'parity8'
> * use XOR instead of OR in the kdoc example (Thanks, Rasmus, for both)
> * added tag from Guenter (thanks!)
> * rebased to 6.13-rc4
> 
> Old coverletter follows:
> 
> I am currently working on upstreaming another I3C controller driver. As
> many others, it needs to ensure odd parity for a dynamically assigned
> address. The BSP version of the driver implemented a custom parity
> algorithm. Wondering why we don't have a generic helper for this in the
> kernel, I found that many I3C controller drivers all implement their
> version of handling parity.
> 
> So, I sent out an RFC[1] moving the efficient implementation of the
> SPD5118 driver to a generic location. The series was well received, but
> the path for upstream was not clear. Because I need the implementation
> for my I3C controller driver and I3C is a prominent user of this new
> function, I got the idea of converting the existing I3C drivers and
> resend the series, suggesting this all goes upstream via I3C.
> 
> Is this acceptable? The non-I3C patches have all the tags they need,
> only the I3C patches would need testing on hardware.
> 
> A build-tested (incl. build-bots) branch is here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/i3c/get_parity
> 
> Looking forward to comments...
> 
> [1] https://lore.kernel.org/all/20241214085833.8695-1-wsa+renesas@sang-engineering.com/
> 

I'll apply the series once you get some agreement on the function name.
I don't care to much but the _odd suggestion seems wise to me.

> 
> 
> Wolfram Sang (5):
>   bitops: add generic parity calculation for u8
>   hwmon: (spd5118) Use generic parity calculation
>   i3c: dw: use get_parity8 helper instead of open coding it
>   i3c: mipi-i3c-hci: use get_parity8 helper instead of open coding it
>   i3c: cdns: use get_parity8 helper instead of open coding it
> 
>  drivers/hwmon/spd5118.c                  |  8 +-----
>  drivers/i3c/master/dw-i3c-master.c       | 14 +++--------
>  drivers/i3c/master/i3c-master-cdns.c     |  3 +--
>  drivers/i3c/master/mipi-i3c-hci/dat_v1.c | 11 +--------
>  include/linux/bitops.h                   | 31 ++++++++++++++++++++++++
>  5 files changed, 37 insertions(+), 30 deletions(-)
> 
> -- 
> 2.39.2
> 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com