[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <655e9afc-cfe9-4b52-8308-7ffe1011e6d5@kernel.org>
Date: Thu, 24 Oct 2024 09:08:57 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: "Wojciech Siudy (Nokia)" <wojciech.siudy@...ia.com>
Cc: Rob Herring <robh@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"andi.shyti@...nel.org" <andi.shyti@...nel.org>,
"peda@...ntia.se" <peda@...ntia.se>
Subject: Re: ODP: [PATCH v5 1/2] dt-bindings: i2c: pca954x: Add timeout reset
property
On 24/10/2024 09:05, Wojciech Siudy (Nokia) wrote:
> Hello,
>
>> This is reset of the I2C devices (children), not the controller, right?
> Right, the mux is child device.
Not sure to which part I replied to. I have DT 200 emails in inbox per
day, I respond to less but still more than I can track. Keep some context.
I suspect you are adding reset for some other device, not for the one here.
>
>> switch to reset controller framework
> Please note that I left the function pca954x_reset_deassert() unchanged,
> just moved it up and implemented two corresponding ones.
> Do you mean that we should get rid of gpiod_set_value_cansleep(),
> because the reset controller will handle it? I can agree but this is topic
> for another submission since there we change when the reset is done,
> not the way we achieve that.
No, I meant I suspect you place property in inappropriate binding to
avoid shared GPIO problem.
Best regards,
Krzysztof
Powered by blists - more mailing lists