"i2c-scl-clk-low-timeout-us" has flaws in itself and the usage here is
all wrong. The driver doesn't use it as a maximum time for clock
stretching but the maximum time for a total transfer. We already have
a binding for the latter. Convert the wrong binding from examples.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
index 70fb69b923c4..b1d7d14c0be4 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
@@ -96,6 +96,6 @@ examples:
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <400000>;
- i2c-scl-clk-low-timeout-us = <10000>;
+ i2c-transfer-timeout-us = <10000>;
};
...
--
2.43.0
Hi, On Thu, Feb 29, 2024 at 11:58:11AM +0100, Wolfram Sang wrote: > "i2c-scl-clk-low-timeout-us" has flaws in itself and the usage here is > all wrong. The driver doesn't use it as a maximum time for clock > stretching but the maximum time for a total transfer. We already have > a binding for the latter. Convert the wrong binding from examples. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml > index 70fb69b923c4..b1d7d14c0be4 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml > +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml > @@ -96,6 +96,6 @@ examples: > interrupts = <43 2>; > interrupt-parent = <&mpic>; > clock-frequency = <400000>; > - i2c-scl-clk-low-timeout-us = <10000>; > + i2c-transfer-timeout-us = <10000>; Chris, can you please give it an ack? The whole series is coherent to this change. Andi
Hi Andi, On 5/03/24 04:16, Andi Shyti wrote: > Hi, > > On Thu, Feb 29, 2024 at 11:58:11AM +0100, Wolfram Sang wrote: >> "i2c-scl-clk-low-timeout-us" has flaws in itself and the usage here is >> all wrong. The driver doesn't use it as a maximum time for clock >> stretching but the maximum time for a total transfer. We already have >> a binding for the latter. Convert the wrong binding from examples. >> >> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> >> --- >> Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml >> index 70fb69b923c4..b1d7d14c0be4 100644 >> --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml >> +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml >> @@ -96,6 +96,6 @@ examples: >> interrupts = <43 2>; >> interrupt-parent = <&mpic>; >> clock-frequency = <400000>; >> - i2c-scl-clk-low-timeout-us = <10000>; >> + i2c-transfer-timeout-us = <10000>; > Chris, can you please give it an ack? > > The whole series is coherent to this change. Looks like you weren't on the To: list for the cover letter which I replied to. For the series Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> and on a P2041RDB Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> Chris, can you please give it an ack? He did on the coverletter for the whole series? Or did I overlook something?
On Thu, 29 Feb 2024 11:58:11 +0100, Wolfram Sang wrote: > "i2c-scl-clk-low-timeout-us" has flaws in itself and the usage here is > all wrong. The driver doesn't use it as a maximum time for clock > stretching but the maximum time for a total transfer. We already have > a binding for the latter. Convert the wrong binding from examples. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > Documentation/devicetree/bindings/i2c/i2c-mpc.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Rob Herring <robh@kernel.org>
© 2016 - 2026 Red Hat, Inc.