On Thu, 12 May 2022 12:08:07 -0500 Eddie James <eajames@xxxxxxxxxxxxx> wrote: > On 5/12/22 11:48, Jonathan Cameron wrote: > > On Thu, 12 May 2022 11:20:18 -0500 > > Eddie James <eajames@xxxxxxxxxxxxx> wrote: > > > >> I2C commands issued after the SI7020 is starting up or after reset > >> can potentially upset the startup sequence. Therefore, the host > >> needs to wait for the startup sequence to finish before issuing > >> further i2c commands. This is impractical in cases where the SI7020 > >> is on a shared bus or behind a mux, which may switch channels at > >> any time (generating I2C traffic). Therefore, check for a device > >> property that indicates that the driver should skip resetting the > >> device when probing. > > Why not lock the bus? It's not ideal, but then not resetting and hence > > potentially ending up in an unknown state isn't great either. > > > Agreed, but locking the bus doesn't work in the case where the chip is > behind a mux. The mux core driver deselects the mux immediately after > the transfer to reset the si7020, causing some i2c traffic, breaking the > si7020. So it would also be a requirement to configure the mux to idle > as-is... That's why I went with the optional skipping of the reset. > Maybe I should add the bus lock too? > +Cc Peter and linux-i2c for advice as we should resolve any potential issue with the mux side of things rather than hiding it in the driver (if possible!) Jonathan > > Thanks, > > Eddie > > > > > > Jonathan > > > >> Changes since v1: > >> - Fix dt binding document > >> > >> Eddie James (2): > >> dt-bindings: iio: humidity: Add si7020 bindings > >> iio: humidity: si7020: Check device property for skipping reset in probe > >> > >> .../bindings/iio/humidity/silabs,si7020.yaml | 47 +++++++++++++++++++ > >> .../devicetree/bindings/trivial-devices.yaml | 2 - > >> drivers/iio/humidity/si7020.c | 14 +++--- > >> 3 files changed, 55 insertions(+), 8 deletions(-) > >> create mode 100644 Documentation/devicetree/bindings/iio/humidity/silabs,si7020.yaml > >>
