[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <864d3027-188f-4612-9770-d617244aad17@linaro.org>
Date: Thu, 29 Feb 2024 18:45:37 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Tim Harvey <tharvey@...eworks.com>, Sean Anderson <sean.anderson@...o.com>
Cc: Linux-ALSA <alsa-devel@...a-project.org>, andersson@...nel.org,
bgoswami@...cinc.com, brgl@...ev.pl, Mark Brown <broonie@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Device Tree Mailing List <devicetree@...r.kernel.org>,
konrad.dybcio@...aro.org,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Liam Girdwood <lgirdwood@...il.com>, linux-arm-msm@...r.kernel.org,
open list <linux-kernel@...r.kernel.org>, linux-sound@...r.kernel.org,
Philipp Zabel <p.zabel@...gutronix.de>, perex@...ex.cz,
Rob Herring <robh+dt@...nel.org>, srinivas.kandagatla@...aro.org,
tiwai@...e.com
Subject: Re: [PATCH 2/4] reset: add GPIO-based reset controller
On 29/02/2024 18:26, Tim Harvey wrote:
>> On 1/9/24 04:41, Krzysztof Kozlowski wrote:
>>
>> I think a separate pseudo-device is necessary a generic solution. So I
>> guess I will revive my patchset.
>>
>
> Sean and Krzysztof,
>
> I see a lot of value in a generic reset-gpio driver that you have both
> tried to get accepted in the past. I support boards that have a number
> of SPI and I2C devices that often have GPIO resets wired to them that
> are pulled in hardware to the in-reset state and find no support in
> the various drivers for reset handling. I've often wondered why a
> generic gpio reset wasn't supported in the SPI/I2C cores like it is
> for some other subsystems.
>
> The approach of a gpios-reset solution makes sense to me.
>
> Will you be submitting a follow-on series to your previous attempts?
Sorry, don't get. Why do you revive this old thread after code was
merged? If my patchset which was finally merged a week ago or so does
not work for you, please comment there or send follow-up work extending it.
Best regards,
Krzysztof
Powered by blists - more mailing lists