[PATCH] dts: riscv: spacemit: k3: Fix I/O power settings

[PATCH] dts: riscv: spacemit: k3: Fix I/O power settings

[Yixun Lan]

SpacemiT K3 SoC support dual-voltage I/O power domain, while initially
configure to 3.3v, and need to access register from APBC space to switch
to 1.8v domain.

Fix the GMAC0's I/O pins 1.8v switch failure that will result a broken
ethernet driver.

Fixes: d8944577496b ("riscv: dts: spacemit: k3: add pinctrl support")
Reported-by: Han Gao <gaohan@iscas.ac.cn>
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
This issue is reported by Han while booting kernel from UFS storage, and
found the ethernet driver is broken, we can see the message as below:

 [    1.635881] mdio_bus stmmac-0: MDIO device at address 1 is missing.

This problem is caused by GMAC driver that unable to configure I/O power
domain to 1.8v, which leads to the MDIO communication failure.

We didn't find this problem due to using tftp(net) to load kernel images
while bootloader already configured the I/O power.
---
 arch/riscv/boot/dts/spacemit/k3.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
index 815debd16409..2b0bf9cd755b 100644
--- a/arch/riscv/boot/dts/spacemit/k3.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
@@ -803,6 +803,7 @@ pinctrl: pinctrl@d401e000 {
 			clocks = <&syscon_apbc CLK_APBC_AIB>,
 				 <&syscon_apbc CLK_APBC_AIB_BUS>;
 			clock-names = "func", "bus";
+			spacemit,apbc = <&syscon_apbc>;
 		};
 
 		uart10: serial@d401f000 {

---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260518-07-dts-pinctrl-io-power-1bd33bfe5894

Best regards,
--  
Yixun Lan <dlan@kernel.org>

Re: [PATCH] dts: riscv: spacemit: k3: Fix I/O power settings

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added `spacemit,apbc` DT property triggers a spurious boot warning and relies on a fragile probe deferral dependency, because the target `syscon_apbc` node lacks the `"syscon"` compatible string.
--

commit 89bb8c89cecf7c32a2e825a2b8f604c5c45762bd
Author: Yixun Lan <dlan@kernel.org>

dts: riscv: spacemit: k3: Fix I/O power settings
    
SpacemiT K3 SoC support dual-voltage I/O power domain, while initially
configure to 3.3v, and need to access register from APBC space to switch
to 1.8v domain.
    
Fix the GMAC0's I/O pins 1.8v switch failure that will result a broken
ethernet driver.

> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> index 815debd16409b..2b0bf9cd755bd 100644
> --- a/arch/riscv/boot/dts/spacemit/k3.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> @@ -803,6 +803,7 @@ pinctrl: pinctrl@d401e000 {
>  			clocks = <&syscon_apbc CLK_APBC_AIB>,
>  				 <&syscon_apbc CLK_APBC_AIB_BUS>;
>  			clock-names = "func", "bus";
> +			spacemit,apbc = <&syscon_apbc>;

Does this newly added spacemit,apbc property trigger a spurious boot warning
and rely on a fragile probe deferral dependency?

Looking at the referenced syscon_apbc node, it lacks the "syscon" compatible
string.

This prevents syscon_node_to_regmap() from instantiating the regmap
on-the-fly, causing it to return -EPROBE_DEFER if the pinctrl driver probes
before the clock driver registers the regmap.

The pinctrl driver catches this with a blanket IS_ERR() check and prints a
now-spurious "no syscon found" warning during boot while discarding the
regmap pointer:

drivers/pinctrl/spacemit/pinctrl-k1.c:spacemit_pinctrl_probe() {
	...
	pctrl->regmap_apbc = syscon_regmap_lookup_by_phandle(np, "spacemit,apbc");
	if (IS_ERR(pctrl->regmap_apbc)) {
		dev_warn(dev, "no syscon found, disable power voltage switch functionality\n");
		pctrl->regmap_apbc = NULL;
	}
	...
}

The voltage switch functionality only ultimately succeeds because the
subsequent devm_clk_get_enabled() call against the same node also returns
-EPROBE_DEFER.

This gives the clock driver time to probe and register the regmap before the
pinctrl driver retries.

Would adding "syscon" to the syscon_apbc node's compatible string, or
explicitly handling -EPROBE_DEFER in the pinctrl driver, resolve this issue
and prevent the spurious warning?

>  		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518-07-dts-pinctrl-io-power-v1-1-abe19c14a726@kernel.org?part=1

Re: [PATCH] dts: riscv: spacemit: k3: Fix I/O power settings

[Yixun Lan]

Hi 

On 21:15 Mon 18 May     , sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The newly added `spacemit,apbc` DT property triggers a spurious boot warning and relies on a fragile probe deferral dependency, because the target `syscon_apbc` node lacks the `"syscon"` compatible string.
> --
> 
> commit 89bb8c89cecf7c32a2e825a2b8f604c5c45762bd
> Author: Yixun Lan <dlan@kernel.org>
> 
> dts: riscv: spacemit: k3: Fix I/O power settings
>     
> SpacemiT K3 SoC support dual-voltage I/O power domain, while initially
> configure to 3.3v, and need to access register from APBC space to switch
> to 1.8v domain.
>     
> Fix the GMAC0's I/O pins 1.8v switch failure that will result a broken
> ethernet driver.
> 
> > diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > index 815debd16409b..2b0bf9cd755bd 100644
> > --- a/arch/riscv/boot/dts/spacemit/k3.dtsi
> > +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > @@ -803,6 +803,7 @@ pinctrl: pinctrl@d401e000 {
> >  			clocks = <&syscon_apbc CLK_APBC_AIB>,
> >  				 <&syscon_apbc CLK_APBC_AIB_BUS>;
> >  			clock-names = "func", "bus";
> > +			spacemit,apbc = <&syscon_apbc>;
> 
> Does this newly added spacemit,apbc property trigger a spurious boot warning
> and rely on a fragile probe deferral dependency?
> 
> Looking at the referenced syscon_apbc node, it lacks the "syscon" compatible
> string.
> 
> This prevents syscon_node_to_regmap() from instantiating the regmap
> on-the-fly, causing it to return -EPROBE_DEFER if the pinctrl driver probes
> before the clock driver registers the regmap.
> 
This is possible, I think it's worth the effort to add some logic to
handle the deferral probe situation

> The pinctrl driver catches this with a blanket IS_ERR() check and prints a
> now-spurious "no syscon found" warning during boot while discarding the
> regmap pointer:
> 
> drivers/pinctrl/spacemit/pinctrl-k1.c:spacemit_pinctrl_probe() {
> 	...
> 	pctrl->regmap_apbc = syscon_regmap_lookup_by_phandle(np, "spacemit,apbc");
> 	if (IS_ERR(pctrl->regmap_apbc)) {
> 		dev_warn(dev, "no syscon found, disable power voltage switch functionality\n");
> 		pctrl->regmap_apbc = NULL;
> 	}
> 	...
> }
> 
> The voltage switch functionality only ultimately succeeds because the
> subsequent devm_clk_get_enabled() call against the same node also returns
> -EPROBE_DEFER.
> 
> This gives the clock driver time to probe and register the regmap before the
> pinctrl driver retries.
> 
make sense

> Would adding "syscon" to the syscon_apbc node's compatible string, or
> explicitly handling -EPROBE_DEFER in the pinctrl driver, resolve this issue
> and prevent the spurious warning?
> 
I prefer to do the latter way

-- 
Yixun Lan (dlan)

Re: [PATCH] dts: riscv: spacemit: k3: Fix I/O power settings

[E Shattow]

On 5/18/26 13:58, Yixun Lan wrote:
> SpacemiT K3 SoC support dual-voltage I/O power domain, while initially
> configure to 3.3v, and need to access register from APBC space to switch
> to 1.8v domain.
> 
> Fix the GMAC0's I/O pins 1.8v switch failure that will result a broken
> ethernet driver.
> 
> Fixes: d8944577496b ("riscv: dts: spacemit: k3: add pinctrl support")
> Reported-by: Han Gao <gaohan@iscas.ac.cn>
> Signed-off-by: Yixun Lan <dlan@kernel.org>
> ---
> This issue is reported by Han while booting kernel from UFS storage, and
> found the ethernet driver is broken, we can see the message as below:
> 
>  [    1.635881] mdio_bus stmmac-0: MDIO device at address 1 is missing.
> 
> This problem is caused by GMAC driver that unable to configure I/O power
> domain to 1.8v, which leads to the MDIO communication failure.
> 
> We didn't find this problem due to using tftp(net) to load kernel images
> while bootloader already configured the I/O power.
> ---
>  arch/riscv/boot/dts/spacemit/k3.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> index 815debd16409..2b0bf9cd755b 100644
> --- a/arch/riscv/boot/dts/spacemit/k3.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> @@ -803,6 +803,7 @@ pinctrl: pinctrl@d401e000 {
>  			clocks = <&syscon_apbc CLK_APBC_AIB>,
>  				 <&syscon_apbc CLK_APBC_AIB_BUS>;
>  			clock-names = "func", "bus";
> +			spacemit,apbc = <&syscon_apbc>;
>  		};
>  
>  		uart10: serial@d401f000 {
> 
> ---
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> change-id: 20260518-07-dts-pinctrl-io-power-1bd33bfe5894
> 
> Best regards,
> --  
> Yixun Lan <dlan@kernel.org>
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Hi Yixun,

This property on its own does not seem to be enough to get the ethernet
network port functional on Sipeed K3 Pico-ITX 32GB model that I have,
when it is loading Debian 13 Trixie debian-installer netinst initramfs
(with cross-compiled Linux kernel and modules from -next 20260602).

Reproducer instructions for cross-compiling and debian-installer netinst
initramfs modification at:
https://wiki.debian.org/InstallingDebianOn/SpacemiT/K3PicoITX?action=recall&rev=2

In addition to those instructions above I am using within the factory
pre-installed vendor U-Boot the following commands to try what your
patch does:

fdt addr $fdt_addr_r
fdt resize
fdt header get filesize totalsize
fdt rm /soc/pinctrl@d401e000 spacemit,apbc
fdt get value spacemit_apbc_phandle /soc/system-controller@d4015000 phandle
fdt set /soc/pinctrl@d401e000 spacemit,apbc <$spacemit_apbc_phandle>

I then verify within Linux environment the presence of
/sys/firmware/devicetree/base/soc/pinctrl@d401e000/spacemit,apbc

The same Linux kernel and modules as modified into the installer then do
have functional ethernet networking on that board if running from the
installed system and with the spacemit,apbc devicetree property. Is this
a dependency or ordering issue of the modules, or the Kconfig options?

Also, the more general problem is that cycling rmmod and modprobe on the
ethernet networking related modules fails:

rmmod dwmac_spacemit
rmmod stmmac_platform
rmmod stmmac
rmmod mdio
modprobe dwmac_spacemit

[ 1487.618517] mdio_bus stmmac-0: MDIO device at address 1 is missing.

[ 1487.623815] spacemit-dwmac cac80000.ethernet end0: renamed from eth0

rmmod dwmac_spacemit
rmmod stmmac_platform
rmmod stmmac
rmmod mdio
modprobe dwmac_spacemit

[ 1539.374486] spacemit-dwmac cac80000.ethernet end0: cannot attach to
PHY (erro
r: -ENODEV)
[ 1615.299451] spacemit-dwmac cac80000.ethernet end0: stmmac_dvr_remove:
removin
g driver

Please advise how to troubleshoot?  Thanks,

- E Shattow

Re: [PATCH] dts: riscv: spacemit: k3: Fix I/O power settings

[Yixun Lan]

Hi E Shattow,

On 13:17 Wed 03 Jun     , E Shattow wrote:
> 
> Hi Yixun,
> 
> This property on its own does not seem to be enough to get the ethernet
> network port functional on Sipeed K3 Pico-ITX 32GB model that I have,
> when it is loading Debian 13 Trixie debian-installer netinst initramfs
> (with cross-compiled Linux kernel and modules from -next 20260602).
> 
I don't think your problem directly connect to this pacth..

> Reproducer instructions for cross-compiling and debian-installer netinst
> initramfs modification at:
> https://wiki.debian.org/InstallingDebianOn/SpacemiT/K3PicoITX?action=recall&rev=2
> 
> In addition to those instructions above I am using within the factory
> pre-installed vendor U-Boot the following commands to try what your
> patch does:
> 
> fdt addr $fdt_addr_r
> fdt resize
> fdt header get filesize totalsize
> fdt rm /soc/pinctrl@d401e000 spacemit,apbc
> fdt get value spacemit_apbc_phandle /soc/system-controller@d4015000 phandle
> fdt set /soc/pinctrl@d401e000 spacemit,apbc <$spacemit_apbc_phandle>
> 
> I then verify within Linux environment the presence of
> /sys/firmware/devicetree/base/soc/pinctrl@d401e000/spacemit,apbc
> 
> The same Linux kernel and modules as modified into the installer then do
> have functional ethernet networking on that board if running from the
> installed system and with the spacemit,apbc devicetree property. Is this
> a dependency or ordering issue of the modules, or the Kconfig options?
> 
I've checked with the failure kernel dmesg log (you provided offline),
the dwmac driver has been probed twice, with first time failed, it
might be the PHY driver not been initialized, adjust following 
configuration works for me..

CONFIG_STMMAC_ETH=y
CONFIG_REALTEK_PHY=y
CONFIG_I2C_K1=y

the PMIC/Power Regulator rely on I2C driver..

> Also, the more general problem is that cycling rmmod and modprobe on the
> ethernet networking related modules fails:
> 
> rmmod dwmac_spacemit
> rmmod stmmac_platform
> rmmod stmmac
> rmmod mdio
> modprobe dwmac_spacemit
> 
> [ 1487.618517] mdio_bus stmmac-0: MDIO device at address 1 is missing.
> 
> [ 1487.623815] spacemit-dwmac cac80000.ethernet end0: renamed from eth0
> 
> rmmod dwmac_spacemit
> rmmod stmmac_platform
> rmmod stmmac
> rmmod mdio
> modprobe dwmac_spacemit
> 
Need to investigate, could be problem of resource deinitialization issue..

> [ 1539.374486] spacemit-dwmac cac80000.ethernet end0: cannot attach to
> PHY (erro
> r: -ENODEV)
> [ 1615.299451] spacemit-dwmac cac80000.ethernet end0: stmmac_dvr_remove:
> removin
> g driver
> 
> Please advise how to troubleshoot?  Thanks,
> 
> - E Shattow
> 

-- 
Yixun Lan (dlan)

Re: [PATCH] dts: riscv: spacemit: k3: Fix I/O power settings

[E Shattow]

On 6/5/26 01:58, Yixun Lan wrote:
> Hi E Shattow,
> 
> On 13:17 Wed 03 Jun     , E Shattow wrote:
>>
>> Hi Yixun,
>>
>> This property on its own does not seem to be enough to get the ethernet
>> network port functional on Sipeed K3 Pico-ITX 32GB model that I have,
>> when it is loading Debian 13 Trixie debian-installer netinst initramfs
>> (with cross-compiled Linux kernel and modules from -next 20260602).
>>
> I don't think your problem directly connect to this pacth..
> 
>> Reproducer instructions for cross-compiling and debian-installer netinst
>> initramfs modification at:
>> https://wiki.debian.org/InstallingDebianOn/SpacemiT/K3PicoITX?action=recall&rev=2
>>
>> In addition to those instructions above I am using within the factory
>> pre-installed vendor U-Boot the following commands to try what your
>> patch does:
>>
>> fdt addr $fdt_addr_r
>> fdt resize
>> fdt header get filesize totalsize
>> fdt rm /soc/pinctrl@d401e000 spacemit,apbc
>> fdt get value spacemit_apbc_phandle /soc/system-controller@d4015000 phandle
>> fdt set /soc/pinctrl@d401e000 spacemit,apbc <$spacemit_apbc_phandle>
>>
>> I then verify within Linux environment the presence of
>> /sys/firmware/devicetree/base/soc/pinctrl@d401e000/spacemit,apbc
>>
>> The same Linux kernel and modules as modified into the installer then do
>> have functional ethernet networking on that board if running from the
>> installed system and with the spacemit,apbc devicetree property. Is this
>> a dependency or ordering issue of the modules, or the Kconfig options?
>>
> I've checked with the failure kernel dmesg log (you provided offline),
> the dwmac driver has been probed twice, with first time failed, it
> might be the PHY driver not been initialized, adjust following 
> configuration works for me..
> 
> CONFIG_STMMAC_ETH=y
> CONFIG_REALTEK_PHY=y
> CONFIG_I2C_K1=y
> 
> the PMIC/Power Regulator rely on I2C driver..
> 
>> Also, the more general problem is that cycling rmmod and modprobe on the
>> ethernet networking related modules fails:
>>
>> rmmod dwmac_spacemit
>> rmmod stmmac_platform
>> rmmod stmmac
>> rmmod mdio
>> modprobe dwmac_spacemit
>>
>> [ 1487.618517] mdio_bus stmmac-0: MDIO device at address 1 is missing.
>>
>> [ 1487.623815] spacemit-dwmac cac80000.ethernet end0: renamed from eth0
>>
>> rmmod dwmac_spacemit
>> rmmod stmmac_platform
>> rmmod stmmac
>> rmmod mdio
>> modprobe dwmac_spacemit
>>
> Need to investigate, could be problem of resource deinitialization issue..
> 
>> [ 1539.374486] spacemit-dwmac cac80000.ethernet end0: cannot attach to
>> PHY (erro
>> r: -ENODEV)
>> [ 1615.299451] spacemit-dwmac cac80000.ethernet end0: stmmac_dvr_remove:
>> removin
>> g driver
>>
>> Please advise how to troubleshoot?  Thanks,
>>
>> - E Shattow
>>
> 

Yes, confirming now that the network is functional (with -next 20260603
from 4th Jun 2026, inclusive of this patch as-is) in debian-installer
netinst by manually configure and ping the network interface before the
application begins the network probe action. After the network probe
action the network device is not reachable.

I'm not experienced with internals of debian-installer to know if the
module is rmmod/modprobe cycled or how else this may be triggered by the
debian-installer application and its network probe action. I do note the
following, that 'lsmod' output has changed:

 Module                  Size  Used by
 sd_mod                167936  0
 uas                    36864  0
 usb_storage           110592  1 uas
 scsi_mod              405504  3 sd_mod,usb_storage,uas
 scsi_common            20480  4 scsi_mod,sd_mod,usb_storage,uas
 onboard_usb_dev        24576  0
 xhci_plat_hcd          24576  0
 xhci_hcd              569344  1 xhci_plat_hcd
 dwc3_generic_plat      12288  0
 dwc3                  471040  1 dwc3_generic_plat
-realtek                61440  0
+realtek                61440  1
 phy_package            16384  1 realtek
 udc_core              114688  1 dwc3
 roles                  20480  1 dwc3
 dwmac_spacemit         12288  0
 stmmac_platform        40960  1 dwmac_spacemit
 stmmac                495616  2 stmmac_platform,dwmac_spacemit
 usbcore               536576  6
xhci_hcd,onboard_usb_dev,usb_storage,uas,xhci_pl
 at_hcd,dwc3
 pcs_xpcs               36864  1 stmmac
 phylink               118784  2 stmmac,pcs_xpcs
 i2c_k1                 28672  0
 usb_common             24576  6
xhci_hcd,usbcore,dwc3_generic_plat,xhci_plat_hcd
 ,dwc3,udc_core
 phy_k1_usb2            12288  2

before and after probe respectively. There is no other change in the
'lsmod' output. The corresponding change in dmesg as follows:

 [    4.911996]  sda: sda1

 [    4.912160] sd 0:0:0:0: [sda] Attached SCSI removable disk

 [   14.820291] workqueue: work func deferred_probe_timeout_work_func
enqueued on deprecated workqueue. Use system_{percpu|dfl}_wq instead.

+[   33.767106] dldo4: disabling

+[   47.890240] spacemit-dwmac cac80000.ethernet end0: Register
MEM_TYPE_PAGE_POOL RxQ-0
+[   47.920334] spacemit-dwmac cac80000.ethernet end0: PHY [stmmac-0:01]
driver [RTL8211F Gigabit Ethernet] (irq=POLL)

+[   47.921411] dwmac4: Master AXI performs any burst length

+[   47.921426] spacemit-dwmac cac80000.ethernet end0: No Safety
Features support found
+[   47.921791] spacemit-dwmac cac80000.ethernet end0: IEEE 1588-2008
Advanced Timestamp supported

+[   47.921958] spacemit-dwmac cac80000.ethernet end0: registered PTP
clock
+[   47.921966] spacemit-dwmac cac80000.ethernet end0: configuring for
phy/rgmii-id link mode

+[   49.087144] spacemit-dwmac cac80000.ethernet end0: Register
MEM_TYPE_PAGE_POOL RxQ-0
+[   49.128304] spacemit-dwmac cac80000.ethernet end0: PHY [stmmac-0:01]
driver [RTL8211F Gigabit Ethernet] (irq=POLL)

+[   49.238342] dwmac4: Master AXI performs any burst length

+[   49.238357] spacemit-dwmac cac80000.ethernet end0: No Safety
Features support found
+[   49.238400] spacemit-dwmac cac80000.ethernet end0: IEEE 1588-2008
Advanced Timestamp supported

+[   49.238580] spacemit-dwmac cac80000.ethernet end0: registered PTP
clock
+[   49.238588] spacemit-dwmac cac80000.ethernet end0: configuring for
phy/rgmii-id link mode

+[   52.325163] spacemit-dwmac cac80000.ethernet end0: Link is Up -
1Gbps/Full - flow control rx/tx

Thanks for looking into this,

-E