From: Conor Dooley <conor@kernel.org>
To: Frieder Schrempf <frieder.schrempf@kontron.de>
Cc: Frieder Schrempf <frieder@fris.de>,
linux-arm-kernel@lists.infradead.org, Marek Vasut <marex@denx.de>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Rob Herring <robh@kernel.org>, Robin Gong <yibin.gong@nxp.com>,
Joy Zou <joy.zou@nxp.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Subject: Re: [PATCH v2 01/11] Revert "regulator: pca9450: Add sd-vsel GPIO"
Date: Mon, 16 Dec 2024 19:59:20 +0000 [thread overview]
Message-ID: <20241216-unchain-respect-1c344203a140@spud> (raw)
In-Reply-To: <b5456480-a68f-4e71-831b-f145453e2646@kontron.de>
[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]
On Tue, Dec 10, 2024 at 04:59:06PM +0100, Frieder Schrempf wrote:
> On 28.11.24 6:37 PM, Conor Dooley wrote:
> > On Wed, Nov 27, 2024 at 05:42:17PM +0100, Frieder Schrempf wrote:
> >> From: Frieder Schrempf <frieder.schrempf@kontron.de>
> >>
> >> This reverts commit 27866e3e8a7e93494f8374f48061aa73ee46ceb2.
> >>
> >> It turned out that this feature was implemented based on
> >> the wrong assumption that the SD_VSEL signal needs to be
> >> controlled as GPIO in any case.
> >>
> >> In fact the straight-forward approach is to mux the signal
> >> as USDHC_VSELECT and let the USDHC controller do the job.
> >>
> >> Most users never even used this property and the few who
> >> did have been or are getting migrated to the alternative
> >> approach.
> >>
> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> >> ---
> >> Changes for v2:
> >> * split revert into separate patch
> >> ---
> >> .../devicetree/bindings/regulator/nxp,pca9450-regulator.yaml | 5 -----
> >> 1 file changed, 5 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
> >> index f8057bba747a5..79fc0baf5fa2f 100644
> >> --- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
> >> +++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
> >> @@ -77,11 +77,6 @@ properties:
> >>
> >> additionalProperties: false
> >>
> >> - sd-vsel-gpios:
> >> - description: GPIO that is used to switch LDO5 between being configured by
> >> - LDO5CTRL_L or LDO5CTRL_H register. Use this if the SD_VSEL signal is
> >> - connected to a host GPIO.
> >
> > Your driver side of this, that I wasn't sent and cba downloading an
> > mbox of is not backwards compatible. The code has been there for a few
> > years, are you sure that there are no out of tree users or other OSes
> > that use the property?
>
> Yes, this is not backwards compatible. I introduced the original meaning
> for the sd-vsel-gpios property based on some misunderstanding of how the
> hardware actually works. Therefore I'm quite sure that except for the
> cases where someone copied my erroneous implementation into their
> devicetree, nobody has really any reason to actually use this.
>
> In-tree all users have been removed (one fix still included in this
> series). Of course we can't be fully sure that there isn't someone out
> there having non-standard hardware (SD_VSEL not connected to
> USDHC_VSELECT but to GPIO only) and using the old sd-vsel-gpios, but the
> probability is very, very low.
>
> IMHO taking the small risk here is better than keeping the misleading
> implementation which will likely cause confusion and failures in the
> future. But of course that's not up to me to decide.
Given that the !property case retains the behaviour from before, only
those with the property are affected - which means if it does end up
being problematic then it can be rectified at that point in time.
> > tbh, I think all 3 of your dt-binding patches should be squashed rather
> > than drip-feeding the conversion. It makes more sense as a single
> > change, rather than splitting the rationales across 3 patches.
>
> Ok, if you like this better in one change I can squash these for the
> next version.
Sounds good, sorry again for the delay getting back to you.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-12-16 20:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-27 16:42 [PATCH v2 00/11] Use correct LDO5 control registers for PCA9450 Frieder Schrempf
2024-11-27 16:42 ` [PATCH v2 01/11] Revert "regulator: pca9450: Add sd-vsel GPIO" Frieder Schrempf
2024-11-27 16:47 ` Mark Brown
2024-11-28 17:37 ` Conor Dooley
2024-12-10 15:59 ` Frieder Schrempf
2024-12-16 19:59 ` Conor Dooley [this message]
2024-11-27 16:42 ` [PATCH v2 02/11] dt-bindings: regulator: pca9450: Add sd-vsel-gpios to read back LDO5 status Frieder Schrempf
2024-11-27 16:42 ` [PATCH v2 03/11] dt-bindings: regulator: pca9450: Document nxp,sd-vsel-fixed-low property for LDO5 Frieder Schrempf
2024-11-28 17:33 ` Conor Dooley
2024-12-10 15:36 ` Frieder Schrempf
2024-12-16 19:50 ` Conor Dooley
2024-11-27 16:42 ` [PATCH v2 04/11] arm64: dts: imx8mp-skov-reva: Use hardware signal for SD card VSELECT Frieder Schrempf
2024-11-27 16:42 ` [PATCH v2 05/11] Revert "regulator: pca9450: Add SD_VSEL GPIO for LDO5" Frieder Schrempf
2024-11-27 16:42 ` [PATCH v2 06/11] regulator: pca9450: Fix control register for LDO5 Frieder Schrempf
2024-11-27 16:42 ` [PATCH v2 07/11] regulator: pca9450: Fix enable " Frieder Schrempf
2024-11-27 16:42 ` [PATCH v2 08/11] regulator: pca9450: Handle hardware with fixed SD_VSEL " Frieder Schrempf
2024-11-27 16:42 ` [PATCH v2 09/11] arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL signal Frieder Schrempf
2024-11-27 16:42 ` [PATCH v2 10/11] arm64: dts: imx93-kontron: Fix SD card IO voltage control Frieder Schrempf
2024-11-27 16:42 ` [PATCH v2 11/11] arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL signal Frieder Schrempf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241216-unchain-respect-1c344203a140@spud \
--to=conor@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frieder.schrempf@kontron.de \
--cc=frieder@fris.de \
--cc=joy.zou@nxp.com \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marex@denx.de \
--cc=robh@kernel.org \
--cc=yibin.gong@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox