| Message ID | 20231115035753.925534-2-chris.packham@alliedtelesis.co.nz |
|---|---|
| State | New |
| Headers | show |
| Series | [v6,1/2] dt-bindings: i2c: add bus-reset-gpios property | expand |
> I personally would like to see it accepted but it seems there are > objections to this approach. I've yet to come up with anything better to > offer as an alternative. I see. Thanks for the heads up!
Hi, > > I personally would like to see it accepted but it seems there are > > objections to this approach. I've yet to come up with anything better to > > offer as an alternative. > > I see. Thanks for the heads up! I'm also inclined to have this merged. A real fix might take time. Myself I have developed a prototype for what has been discussed with Krzysztof, but I don't know how much time it will take to get things done. Andi
Hi Krzysztof, On Wed, Dec 20, 2023 at 08:22:38AM +0100, Krzysztof Kozlowski wrote: > On 20/12/2023 00:25, Andi Shyti wrote: > > Hi, > > > >>> I personally would like to see it accepted but it seems there are > >>> objections to this approach. I've yet to come up with anything better to > >>> offer as an alternative. > >> > >> I see. Thanks for the heads up! > > > > I'm also inclined to have this merged. A real fix might take > > time. > > NAK > > If you intend to merge it, then please carry: > > Nacked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> ehehe... too much drama here :-) I know you nacked this patch and of course won't be taken anywhere. I was actually referring to Chris previous patch rather than this one. Andi > The patchset is wrong and made of wrong reasons. It claimed GPIO cannot > be shared, which is simply not true. > > > > > Myself I have developed a prototype for what has been discussed > > with Krzysztof, but I don't know how much time it will take to > > get things done. > > > Best regards, > Krzysztof >
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. + +- bus-reset-duration-us: + Reset duration in us. + default: 1 + Required properties (per child device) --------------------------------------
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@alliedtelesis.co.nz> --- Notes: I expect the first reaction to this will be a request to convert the binding to dtschema. I can attempt such a conversion but given it's one of the more core bindings I expect others may have strong opinions. I didn't want to start a conversion without hearing those opinions (or if I could get away without doing the conversion). It's also likely to spin off a whole lot of work to bring existing device trees into line. Changes in v6: - Retarget changes at the i2c core instead of an individual driver Changes in v5: - Rename reset-gpios and reset-duration-us to bus-reset-gpios and bus-reset-duration-us as requested by Wolfram Changes in v4: - Add r-by from Krzysztof Changes in v3: - Rename reset-delay-us to reset-duration-us to better reflect its purpose - Add default: for reset-duration-us - Add description: for reset-gpios Changes in v2: - Update commit message - Add reset-delay-us property Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++ 1 file changed, 8 insertions(+)