On Monday, 4 August 2025 00:39:40 CEST Chris Packham wrote:
For the series
Reviewed-by: Chris Packham chris.packham@alliedtelesis.co.nz Tested-by: Chris Packham chris.packham@alliedtelesis.co.nz
Thank you.
Note that I've only got the same simple eeprom devices that I did the initial development on so I don't think I've really exercised the block data paths but I can say the changes don't appear to have regressed anything.
I can understand this problem quite well. We can all only try our best and then hope that someone with the actual HW can figure out the specific parts which we didn't had access to.
Is you series intended to apply on top of Jonas's? I'm trying to apply yours alone (for various reasons happens to be on top of net-next/main) and I'm getting conflicts.
No, I prepare something for downstream testing (with Jonas' patch): https://github.com/openwrt/openwrt/pull/19577#discussion_r2248520949
Conflict appears to be with https://lore.kernel.org/all/20250615235248.529019-1-alexguo1023@gmail.com/
Thanks, I was not aware of this specific one. I don't exactly know the repo structure for I2C Host drivers. But git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git i2c/i2c-host-fixes or i2c/i2c-host-next didn't had this patch. I've also checked linux-next and couldn't find the patch at the moment.
I am guessing it is the best when I resent this patch as part of my patchset and modify my patches accordingly. The resent will then be done this evening (GMT+2). Preview can be found at https://git.open-mesh.org/linux-merge.git/log/?h=b4/i2c-rtl9300-multi-byte
I've also checked linux-next and couldn't find the patch at the moment.
Kind regards, Sven