On 16. 2. 2023 16:21, Peter Naulls wrote: > > On 2/15/23 13:31, Peter Naulls wrote: > > > > I'm trying to track yet another vendor vs current OpenWrt driver > > mishandling. > > > x00
Can you please provide info about the exact SoC and hardware you are using? > > > > In particular, for the first read attempt, the value is always the first > > value sent as part of the last write. i.e, 3 in this case. After, that, > > it's always 0 (the correct answer ought to be 0xf). > > Without a logic analyzer/scope, it would be hard to tell what's happening. The problem can be deeper and not in the code itself. > So I pulled out the old vendor-supplied driver and dropped it in the current > kernel, where it compiled with no changes. > > It works for reads, after a fashion. It will read the correct value a few > times, and then 0 after. The state can be "reset" by doing a write, and then > it works again. I'm a little bit lost here. It seems to me, that also the vendor driver does not work all the time for you and you must "reset" something, but maybe I just misunderstood this. Can you please describe the exact protocol you would like to implement in terms of I2C and what device is on the other side? > Pursing getting the current driver working here seems most prudent - clearly > the most recent changes were made for a reason, but I'm not sure what to do > next. The old driver does not support clock stretching and messages were limited to 32 bytes. It did not support repeated start correctly. It ignores ACK/NAK so i2cdetect did not work, etc. So if the communication is broken "the right way" on the hardware level, the old driver can behave differently. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
