[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8cc8e9e1-6abc-4dd2-b402-dff66fa1429b@alliedtelesis.co.nz>
Date: Sun, 15 Oct 2023 20:12:48 +0000
From: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To: Wolfram Sang <wsa@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
"gregory.clement@...tlin.com" <gregory.clement@...tlin.com>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"pierre.gondois@....com" <pierre.gondois@....com>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] i2c: mv64xxx: add support for FSM based recovery
On 13/10/23 20:11, Wolfram Sang wrote:
>> mmmhhh... still a bit skeptical about waiting 100 times 10us in
>> atomic.
> Has it been discussed already why the non-atomic version of
> read_poll_timeout is not enough?
>
For mv64xxx i2c_recovery() is called from two places. One would be fine
with read_poll_timeout() but the other is in an interrupt handler so
needs the atomic version (or something else that doesn't schedule).
Powered by blists - more mailing lists