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.
-
nxp,i2c-lt-enable:
type: boolean
description:
--
2.46.1On 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? 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.
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. > > 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. Thanks!
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.
On Wed, Nov 27, 2024 at 05:42:17PM +0100, Frieder Schrempf wrote: > From: Frieder Schrempf <frieder.schrempf@kontron.de> > > This reverts commit 27866e3e8a7e93494f8374f48061aa73ee46ceb2. Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. There's no need to resubmit to fix this alone. Please include human readable descriptions of things like commits and issues being discussed in e-mail in your mails, this makes them much easier for humans to read especially when they have no internet access. I do frequently catch up on my mail on flights or while otherwise travelling so this is even more pressing for me than just being about making things a bit easier to read.
© 2016 - 2026 Red Hat, Inc.