[Resending because I3C list was not added on all patches. Sorry!] 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 locally build-tested 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@xxxxxxxxxxxxxxxxxxxx/ 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
