Hi Krystof, On 16/11/23 10:29, Krzysztof Kozlowski wrote: > On 15/11/2023 04:57, Chris Packham wrote: >> Add bus-reset-gpios and bus-reset-duration-us properties to the binding >> description for i2c busses. These can be used to describe hardware where >> a common reset GPIO is connected to all downstream devices on and I2C >> bus. This reset will be asserted then released before the downstream >> devices on the bus are probed. >> >> Signed-off-by: Chris Packham <chris.packham@xxxxxxxxxxxxxxxxxxx> >> --- >> > ... > >> Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt >> index fc3dd7ec0445..3f95d71b9985 100644 >> --- a/Documentation/devicetree/bindings/i2c/i2c.txt >> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt >> @@ -99,6 +99,14 @@ wants to support one of the below features, it should adapt these bindings. >> indicates that the system is accessible via this bus as an endpoint for >> MCTP over I2C transport. >> >> +- bus-reset-gpios: >> + GPIO pin providing a common reset for all downstream devices. This GPIO >> + will be asserted then released before the downstream devices are probed. > I initially reviewed it, but did not think enough about it. After more > consideration, I believe this is not a property of the I2C bus > controller. This is a property of each device, even if the GPIO is the same. > > Linux kernel already supports shared GPIO, so you only need > enable-ref-counting on it. That's the kind of breadcrumb I need. Although I can't see enable-ref-counting as any kind of DT property. Do you mean GPIOD_FLAGS_BIT_NONEXCLUSIVE? > Putting it into the controller bindings looks like solving OS issue with > incorrect hardware description. Yes that's entirely whats happening here. > Best regards, > Krzysztof >
