riscv: dts: starfive: jh7110-common: drop no-sdio property from mmc1
Subsystems (3)
PATCH 1/1 riscv: dts: starfive: jh7110-common: drop no-sdio property from mmc1
Drop no-sdio property avoids a delete-property on variant board dts having an SDIO wireless module connected to mmc1.
--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 1 - 1 file changed, 1 deletion(-)
arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0 -1
@@ -299,7 +299,6 @@ &mmc1 { assigned-clock-rates = <50000000>; bus-width = <4>; bootph-pre-ram; - no-sdio; no-mmc; cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>; disable-wp;
base-commit: 28fa0dcb571ab8f3be4d919f0e20e01d4e44bcb1
Signature · 1 line
2.50.0
Conor Dooley
maintainerQuoted 2 lines · E Shattow
Drop no-sdio property avoids a delete-property on variant board dts having an SDIO wireless module connected to mmc1.
I'm struggling to understand why this change is correct.
If there are specific boards that have wireless modules connected instead of using sdcards, how come the no-sdio property isn't moved to the the boards that do have sdcard slots?
The property was added for the visionfive 2, and only on mmc1, so should it be retained for boards that match the visionfive 2 in terms of how they use mmc?
Could you add an explanation for why removing this entirely is the right thing to do, rather than only removing it for these variant boards?
Cheers,
Conor.
Quoted 23 lines
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 1 - 1 file changed, 1 deletion(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-1@@ -299,7 +299,6 @@ &mmc1 { assigned-clock-rates = <50000000>; bus-width = <4>; bootph-pre-ram; - no-sdio; no-mmc; cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>; disable-wp;base-commit:
28fa0dcb571ab8f3be4d919f0e20e01d4e44bcb1Signature · 1 line
2.50.0
Hi Conor,
Quoted 9 lines · Conor Dooley
Quoted 2 lines · E Shattow
Drop no-sdio property avoids a delete-property on variant board dts having an SDIO wireless module connected to mmc1.
I'm struggling to understand why this change is correct.
If there are specific boards that have wireless modules connected instead of using sdcards, how come the no-sdio property isn't moved to the the boards that do have sdcard slots?
Why is 'no-sdio' property there to begin with...
Quoted 3 lines
The property was added for the visionfive 2, and only on mmc1, so should it be retained for boards that match the visionfive 2 in terms of how they use mmc?
Ref.:
https://lore.kernel.org/lkml/[email protected]/
My theory is VisionFive2 board hardware can support connecting up some SDIO module there with ready-made available adapters, it may be possible (if unusual) that would work? SDIO is 4-wide and some voltage requirements, and a couple of GPIO, so I'm aware that's a stretch of a statement but it could be done without soldering. I wouldn't expect it, but why restrict this everywhere inheriting from jh7110-common.dtsi with 'no-sdio' and then (needs testing!) if it doesn't matter one way or the other for VisionFive2 just drop it I think as being inaccurate/unnecessary?
JH7110 CPU supports two interfaces of SDIO3.0/eMMC so it's not clear to me if there's some reason for 'no-sdio' property to be there. Does allowing SDIO (?) break eMMC and SD Card devices, is it destructive?
Not knowing what 'no-sdio' does technically I dropped the property and tested with the hardware I do have. The 'no-sdio' property present/absent does not appear to do anything user-impactful on Pine64 Star64 that has SD Card slot on mmc1, and as would be expected on Milk-V Mars CM Lite WiFi when there's an SDIO module at mmc1 it then fails to initialize if 'no-sdio' property is present.
Quoted 3 lines
Could you add an explanation for why removing this entirely is the right thing to do, rather than only removing it for these variant boards?
Yes, I can rephrase a bit like "relax no-sdio restriction on mmc1 for jh7110 boards", or else reconsider the approach. I was going to approach with /delete-property/ no-sdio; later elsewhere but after testing on Pine64 Star64 with similar configuration to VisionFive2 mmc interfaces, and knowing that Milk-V Mars CM Lite WiFi detects AP6256 SDIO peripheral at mmc1 when this property is dropped (and with a few additional things)... I prefer to reduce the problems that would need to be avoided.
I have done all the testing I can do with hardware I have. As-is it's just like I wrote, we'll have to solicit some testing feedback on that and wait to learn what this does for the other boards.
Aside, anyone want to chime in what is the utility of 'no-sdio' property, how do you know from a schematic if it is appropriate, can it be simply dropped as I suggest for JH7110 boards?
Quoted 3 lines
Cheers,
Conor.
Thank you for reviewing! -E
Quoted 24 lines
Quoted 24 lines
Signed-off-by E Shattow <[email protected]>--- arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 1 - 1 file changed, 1 deletion(-)arch/riscv/boot/dts/starfive/jh7110-common.dtsi +0
-1@@ -299,7 +299,6 @@ &mmc1 { assigned-clock-rates = <50000000>; bus-width = <4>; bootph-pre-ram; - no-sdio; no-mmc; cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>; disable-wp;base-commit:
28fa0dcb571ab8f3be4d919f0e20e01d4e44bcb1Signature · 1 line
2.50.0
Conor Dooley
maintainerQuoted 20 lines · E Shattow
Quoted 9 lines · Conor Dooley
Quoted 2 lines · E Shattow
Drop no-sdio property avoids a delete-property on variant board dts having an SDIO wireless module connected to mmc1.
I'm struggling to understand why this change is correct.
If there are specific boards that have wireless modules connected instead of using sdcards, how come the no-sdio property isn't moved to the the boards that do have sdcard slots?
Why is 'no-sdio' property there to begin with...
Quoted 3 lines
The property was added for the visionfive 2, and only on mmc1, so should it be retained for boards that match the visionfive 2 in terms of how they use mmc?
Quoted 7 lines
My theory is VisionFive2 board hardware can support connecting up some SDIO module there with ready-made available adapters, it may be possible (if unusual) that would work? SDIO is 4-wide and some voltage requirements, and a couple of GPIO, so I'm aware that's a stretch of a statement but it could be done without soldering. I wouldn't expect it, but why restrict this everywhere inheriting from
jh7110-common.dtsiwith 'no-sdio' and then (needs testing!) if it doesn't matter one way or the
In case it was not clear, I am not questioning removing it from the common file, just that you're removing it entirely.
Quoted 6 lines
other for VisionFive2 just drop it I think as being inaccurate/unnecessary?
JH7110 CPU supports two interfaces of SDIO3.0/eMMC so it's not clear to me if there's some reason for 'no-sdio' property to be there. Does allowing SDIO (?) break eMMC and SD Card devices, is it destructive?
Quoted 6 lines
Not knowing what 'no-sdio' does technically I dropped the property and tested with the hardware I do have. The 'no-sdio' property present/absent does not appear to do anything user-impactful on Pine64 Star64 that has SD Card slot on mmc1, and as would be expected on Milk-V Mars CM Lite WiFi when there's an SDIO module at mmc1 it then fails to initialize if 'no-sdio' property is present.
The original addition looks very intentional - however I didn't look at the commit message itself last night, just the diff. I wonder if "no-sdio" and "no-mmc" were just added because William intended to restrict SD cards since sdio1 is the SD card slot, rather than because the use of sdio or mmc commands during init would cause problems. The wording of "Set sdioo node to emmc and set sdio1 node to sd" is what makes me think that.
Quoted 10 lines
Quoted 2 lines
Could you add an explanation for why removing this entirely is the right thing to do, rather than only removing it for these variant boards?
Yes, I can rephrase a bit like "relax no-sdio restriction on mmc1 for jh7110 boards", or else reconsider the approach. I was going to approach with
/delete-property/ no-sdio;later elsewhere but after testing on Pine64 Star64 with similar configuration to VisionFive2 mmc interfaces, and knowing that Milk-V Mars CM Lite WiFi detects AP6256 SDIO peripheral at mmc1 when this property is dropped (and with a few additional things)... I prefer to reduce the problems that would need to be avoided.
I think using /delete-property/ would be unwise, properties shouldn't be in the common dtsi if they are not, in fact, common.
Quoted 3 lines
I have done all the testing I can do with hardware I have. As-is it's just like I wrote, we'll have to solicit some testing feedback on that and wait to learn what this does for the other boards.
I'd kinda be inclined to apply this diff, with a better commit message, shortly after -rc1, unless someone comes forward with a justification for it being there on the vf2. I figure it's only in the common dtsi because it was not problematic until now cos noone tried to use the sdio aspect.
Quoted 3 lines
Aside, anyone want to chime in what is the utility of 'no-sdio' property, how do you know from a schematic if it is appropriate, can it be simply dropped as I suggest for JH7110 boards?
My (limited) understanding, mostly from looking at the caps in mmc/host.h because I find the binding description obtuse, is that these properties (no-sdio and no-mmc) block the use of commands that would cause a device to malfunction. They don't appear to be required at all just because the board layout doesn't support these types of devices.
Conor.
Adding CC: Hal Feng, Minda Chen
Quoted 64 lines · Conor Dooley
Quoted 20 lines · E Shattow
Quoted 9 lines · Conor Dooley
Quoted 2 lines · E Shattow
Drop no-sdio property avoids a delete-property on variant board dts having an SDIO wireless module connected to mmc1.
I'm struggling to understand why this change is correct.
If there are specific boards that have wireless modules connected instead of using sdcards, how come the no-sdio property isn't moved to the the boards that do have sdcard slots?
Why is 'no-sdio' property there to begin with...
Quoted 3 lines
The property was added for the visionfive 2, and only on mmc1, so should it be retained for boards that match the visionfive 2 in terms of how they use mmc?
Quoted 7 lines
My theory is VisionFive2 board hardware can support connecting up some SDIO module there with ready-made available adapters, it may be possible (if unusual) that would work? SDIO is 4-wide and some voltage requirements, and a couple of GPIO, so I'm aware that's a stretch of a statement but it could be done without soldering. I wouldn't expect it, but why restrict this everywhere inheriting from
jh7110-common.dtsiwith 'no-sdio' and then (needs testing!) if it doesn't matter one way or theIn case it was not clear, I am not questioning removing it from the common file, just that you're removing it entirely.
Quoted 6 lines
other for VisionFive2 just drop it I think as being inaccurate/unnecessary?
JH7110 CPU supports two interfaces of SDIO3.0/eMMC so it's not clear to me if there's some reason for 'no-sdio' property to be there. Does allowing SDIO (?) break eMMC and SD Card devices, is it destructive?
Quoted 6 lines
Not knowing what 'no-sdio' does technically I dropped the property and tested with the hardware I do have. The 'no-sdio' property present/absent does not appear to do anything user-impactful on Pine64 Star64 that has SD Card slot on mmc1, and as would be expected on Milk-V Mars CM Lite WiFi when there's an SDIO module at mmc1 it then fails to initialize if 'no-sdio' property is present.
The original addition looks very intentional - however I didn't look at the commit message itself last night, just the diff. I wonder if "no-sdio" and "no-mmc" were just added because William intended to restrict SD cards since sdio1 is the SD card slot, rather than because the use of sdio or mmc commands during init would cause problems. The wording of "Set sdioo node to emmc and set sdio1 node to sd" is what makes me think that.
Quoted 10 lines
Quoted 2 lines
Could you add an explanation for why removing this entirely is the right thing to do, rather than only removing it for these variant boards?
Yes, I can rephrase a bit like "relax no-sdio restriction on mmc1 for jh7110 boards", or else reconsider the approach. I was going to approach with
/delete-property/ no-sdio;later elsewhere but after testing on Pine64 Star64 with similar configuration to VisionFive2 mmc interfaces, and knowing that Milk-V Mars CM Lite WiFi detects AP6256 SDIO peripheral at mmc1 when this property is dropped (and with a few additional things)... I prefer to reduce the problems that would need to be avoided.
Quoted 3 lines
I think using /delete-property/ would be unwise, properties shouldn't be in the common dtsi if they are not, in fact, common.
Ack, you wanted these moved out into each board dts? That would be okay with me. I suspected that no-sdio no-mmc don't belong so I'm still in favor of dropping them overall. I think nothing will break but I want more data from users.
Quoted 10 lines
Quoted 3 lines
I have done all the testing I can do with hardware I have. As-is it's just like I wrote, we'll have to solicit some testing feedback on that and wait to learn what this does for the other boards.
I'd kinda be inclined to apply this diff, with a better commit message, shortly after -rc1, unless someone comes forward with a justification for it being there on the vf2. I figure it's only in the common dtsi because it was not problematic until now cos noone tried to use the sdio aspect.
I will revise the commit message v2 and send soon, just for dropping the no-sdio... and actively seek testing reports from users of all the JH7110 boards to drop no-sdio and then also no-mmc properties for a follow-up.
Quoted 11 lines
Quoted 3 lines
Aside, anyone want to chime in what is the utility of 'no-sdio' property, how do you know from a schematic if it is appropriate, can it be simply dropped as I suggest for JH7110 boards?
My (limited) understanding, mostly from looking at the caps in
mmc/host.hbecause I find the binding description obtuse, is that these properties (no-sdio and no-mmc) block the use of commands that would cause a device to malfunction. They don't appear to be required at all just because the board layout doesn't support these types of devices.Conor.
Hal and/or Minda (from StarFive) any comment about this? I would ask William but they are not involved anymore. Can we drop some of these suspicious mmc properties, what are the reasons for these? -E
Conor Dooley
maintainerQuoted 8 lines · E Shattow
Quoted 8 lines
Quoted 7 lines
Yes, I can rephrase a bit like "relax no-sdio restriction on mmc1 for jh7110 boards", or else reconsider the approach. I was going to approach with
/delete-property/ no-sdio;later elsewhere but after testing on Pine64 Star64 with similar configuration to VisionFive2 mmc interfaces, and knowing that Milk-V Mars CM Lite WiFi detects AP6256 SDIO peripheral at mmc1 when this property is dropped (and with a few additional things)... I prefer to reduce the problems that would need to be avoided.
Quoted 8 lines
Quoted 3 lines
I think using /delete-property/ would be unwise, properties shouldn't be in the common dtsi if they are not, in fact, common.
Ack, you wanted these moved out into each board dts? That would be okay with me. I suspected that
no-sdiono-mmcdon't belong so I'm still in favor of dropping them overall. I think nothing will break but I want more data from users.
Ye, moved out to the board dts is my preference over using /delete-property/. Things that aren't actually common shouldn't be in the common file. I do agree that in this case, removal entirely is probably the right call. There's some sdio wifi cards that can go into sd card slots, so just because the mmc controller is connected to a sd card slot doesn't mean no-sdio should be used.
Conor Dooley
maintainerQuoted 4 lines · E Shattow
Hal and/or Minda (from StarFive) any comment about this? I would ask William but they are not involved anymore. Can we drop some of these suspicious mmc properties, what are the reasons for these?
Additionally, William is mentioned in several maintainers entries, could you StarFive folks either replace/remove him please?