[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cc85a29ff0392811e2a79567eb849c12de7adb8f.camel@alliedtelesis.co.nz>
Date: Wed, 26 Aug 2020 22:31:16 +0000
From: Mark Tomlinson <Mark.Tomlinson@...iedtelesis.co.nz>
To: "wsa@...nel.org" <wsa@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"gregory.clement@...tlin.com" <gregory.clement@...tlin.com>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH v2] i2c: mv64xxx: Add bus error recovery
On Tue, 2020-08-25 at 11:26 +0200, Wolfram Sang wrote:
> On Tue, Aug 25, 2020 at 10:52:54AM +1200, Mark Tomlinson wrote:
>
> This adds i2c bus recovery to the mv64xxx driver.
>
> Implement bus recovery to recover from SCL/SDA stuck low.
>
> This uses the generic recovery function, setting the clock/data lines as
> GPIO pins, and sending 9 clocks to try and recover the bus.
>
> Signed-off-by: Mark Tomlinson <mark.tomlinson@...iedtelesis.co.nz>
> ---
> Changes in v2:
> - use generic GPIO recovery function.
>
> Thank you for doing that! Glad to see the new helper function works for
> you as well. The initialization code is all well, but I wonder about the
> use of i2c_recover_bus(). Recovery should be tried only if it is
> detected that SDA is pulled low when the bus should be free. So, you
> shouldn't call i2c_recover_bus() in unconditionally in probe(). Can your
> HW detect if SDA is stuck low?
We actually don't need this call, as the bootloader checks and leaves the
bus in a good state. I will remove this from the patch.
Powered by blists - more mailing lists