| Message ID | 20250205134623.6921-1-wsa+renesas@sang-engineering.com |
|---|---|
| Headers | show |
| Series | i2c: revert flag based client handling | expand |
Hi Heiner, > With RFC fix (v2) sent, the issue should be solved. > Would be good to have your feedback on the fix approach. I had a glimpse, and the patch was too intrusive for a quick fix with changing the locking everywhere. So, I will still revert the original changes to buy us more time. In addition, as we overlooked one code path, we should double check that we didn't overlook another one in that regard, i.e. muxes. We should develop better test cases, too. Happy hacking, Wolfram
On 06.02.2025 17:59, Wolfram Sang wrote: > Hi Heiner, > >> With RFC fix (v2) sent, the issue should be solved. >> Would be good to have your feedback on the fix approach. > > I had a glimpse, and the patch was too intrusive for a quick fix with > changing the locking everywhere. So, I will still revert the original > changes to buy us more time. In addition, as we overlooked one code > path, we should double check that we didn't overlook another one in that > regard, i.e. muxes. We should develop better test cases, too. > Understood. How to go on from here? Bring the two patches plus v2 of the fix to linux-next for 6.15? I only have consumer hw w/o i2c muxes, therefore can just compile-test the mux part. > Happy hacking, > > Wolfram > Heiner
It turned out the new mechanism does not handle all muxing cases. Revert the changes to give a proper solution more time. Wolfram Sang (2): Revert "i2c: Replace list-based mechanism for handling userspace-created clients" Revert "i2c: Replace list-based mechanism for handling auto-detected clients" drivers/i2c/i2c-core-base.c | 113 ++++++++++++++++++++++++------------ include/linux/i2c.h | 10 +++- 2 files changed, 83 insertions(+), 40 deletions(-)