Messages in this thread | | | Date | Fri, 29 Sep 2023 11:48:10 +0300 | Subject | Re: [PATCH v2] i2c: designware: Fix corrupted memory seen in the ISR | From | Jarkko Nikula <> |
| |
On 9/27/23 22:38, Wolfram Sang wrote: > >> So my next question, is the change to dw_reg_write something that I should >> write and submit, or should someone else submit something more generalized, >> like option 2 above? I don't own the i2c driver, I'm just trying to fix one >> issue on one processor with minimal risk of breaking something. I don't have >> the broader view of what's optimal for the whole DesignWare i2c driver. I >> also don't have any way to test changes on other models of processors. > > Well, I guess this is a question for the designware maintainers: do we > want this one conversion from *_relaxed to non-relaxed. Or are we > playing safe by using non-relaxed all the time. I would suggest the > latter because the drivers I look after hardly write registers in a hot > path (and not many of them at a time). But you guys know your driver > better... > Well I don't have any preference (read enough knowledge) either here and I hardly think performance becomes issue in any configuration.
Not a showstopper to this fix nor necessarily need to cover either but one another memory barrier case might be in i2c-slave flows:
1. I2C bus read/write from another host 2. Interrupt to i2c-designware IP i2c-designware-slave.c: i2c_dw_isr_slave() i2c-core-slave.c: i2c_slave_event() -> irq handler goes to slave backend like i2c-slave-eeprom i2c-slave-eeprom.c: i2c_slave_eeprom_slave_cb() 3. Shared data between irq handler and process context struct eeprom_data is accessed both from irq handler via i2c_slave_eeprom_slave_cb() and process context via sysfs node handlers i2c_slave_eeprom_bin_read() and i2c_slave_eeprom_bin_write()
| |