u-boot.git/drivers/phy, branch v2025.07 Unnamed repository; edit this file 'description' to name the repository. phy: zynqmp: Fix sgmii clk ctrl GTR lane bit shift 2025-06-02T07:13:48+00:00 Frantisek Bohacek rutherther@ditigal.xyz 2025-05-22T06:07:03+00:00 90df44fb4f0e1cbe18b02080ef8bf9e365f867b8 The bitshift in GEM_CLK_CTRL register is five bits, not two. There are four bits for each GEM, and one bit reserved in between. This has caused that using more than one GEM is impossible, additionally corrupting the GEM0's configuration, leaving GEM0 unusable as well (ie. if GEM0 and GEM1 are used, GEM1 configuration is going to write to GEM0's registers wrong value, leaving GEM0 unusable) Signed-off-by: Frantisek Bohacek <rutherther@ditigal.xyz> Link: https://lore.kernel.org/r/20250522060703.4863-1-rutherther@ditigal.xyz Signed-off-by: Michal Simek <michal.simek@amd.com> 
The bitshift in GEM_CLK_CTRL register is five bits, not two. There are
four bits for each GEM, and one bit reserved in between.

This has caused that using more than one GEM is impossible,
additionally corrupting the GEM0's configuration, leaving GEM0
unusable as well (ie. if GEM0 and GEM1 are used, GEM1 configuration is
going to write to GEM0's registers wrong value, leaving GEM0 unusable)

Signed-off-by: Frantisek Bohacek <rutherther@ditigal.xyz>
Link: https://lore.kernel.org/r/20250522060703.4863-1-rutherther@ditigal.xyz
Signed-off-by: Michal Simek <michal.simek@amd.com>
phy: sun4i-usb: Determine USB OTG detection pin from devicetree 2025-04-28T18:45:44+00:00 Andre Przywara andre.przywara@arm.com 2025-03-30T16:13:50+00:00 ab4c636484976c0b2608128b7c0bfbd21ff71487 So far Allwinner boards controlled the USB OTG ID detection via the respective GPIO pin specified in Kconfig, as a string. All boards should have the same GPIO already specified in the devicetree, in the usb0_id_det-gpios property. Convert the usage of the Kconfig configured GPIO over to query that information from the devicetree, then use the existing DM GPIO infrastructure to request the GPIO. Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to avoid claiming it multiple times. This removes the need to name that GPIO in the defconfig file. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> 
So far Allwinner boards controlled the USB OTG ID detection via the
respective GPIO pin specified in Kconfig, as a string. All boards should
have the same GPIO already specified in the devicetree, in the
usb0_id_det-gpios property.

Convert the usage of the Kconfig configured GPIO over to query that
information from the devicetree, then use the existing DM GPIO
infrastructure to request the GPIO.
Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to
avoid claiming it multiple times.

This removes the need to name that GPIO in the defconfig file.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
phy: sun4i-usb: Determine VBUS detection pin from devicetree 2025-04-28T18:45:44+00:00 Andre Przywara andre.przywara@arm.com 2025-03-30T16:13:23+00:00 af24fbb24a35cd892c27fbbea3caed726211f018 So far Allwinner boards controlled the USB VBUS detection via the respective GPIO pin specified in Kconfig, as a string. All boards should have the same GPIO already specified in the devicetree, in the usb0_vbus_det-gpios property. Convert the usage of the Kconfig configured GPIO over to query that information from the devicetree, then use the existing DM GPIO infrastructure to request the GPIO. Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to avoid claiming it multiple times. This removes the need to name that GPIO in the defconfig file. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> 
So far Allwinner boards controlled the USB VBUS detection via the
respective GPIO pin specified in Kconfig, as a string. All boards should
have the same GPIO already specified in the devicetree, in the
usb0_vbus_det-gpios property.

Convert the usage of the Kconfig configured GPIO over to query that
information from the devicetree, then use the existing DM GPIO
infrastructure to request the GPIO.
Only PHY0 supports USB-OTG, so limit the GPIO request to that PHY, to
avoid claiming it multiple times.

This removes the need to name that GPIO in the defconfig file.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
phy: sun4i-usb: Control supplies via the regulator uclass 2025-04-28T18:45:43+00:00 Samuel Holland samuel@sholland.org 2023-10-31T06:39:53+00:00 3d88f264f4c3444f77ce5015d80e190536784cfd The device tree binding for the PHY provides VBUS supplies as regulator references. Now that all boards have the appropriate regulator uclass drivers enabled, the PHY driver can switch to using them. This replaces direct GPIO usage, which in some cases needed a special DM-incompatible "virtual" GPIO from the PMIC. The following boards provided a value for CONFIG_USB0_VBUS_PIN, but are missing the "usb0_vbus-supply" property in their device tree. None of them have the MUSB controller enabled in host or OTG mode, so they should see no impact: - Ainol_AW1_defconfig / sun7i-a20-ainol-aw1 - Ampe_A76_defconfig / sun5i-a13-ampe-a76 - CHIP_pro_defconfig / sun5i-gr8-chip-pro - Cubieboard4_defconfig / sun9i-a80-cubieboard4 - Merrii_A80_Optimus_defconfig / sun9i-a80-optimus - Sunchip_CX-A99_defconfig / sun9i-a80-cx-a99 - Yones_Toptech_BD1078_defconfig / sun7i-a20-yones-toptech-bd1078 - Yones_Toptech_BS1078_V2_defconfig / sun6i-a31s-yones-toptech-bs1078-v2 - iNet_3F_defconfig / sun4i-a10-inet-3f - iNet_3W_defconfig / sun4i-a10-inet-3w - iNet_86VS_defconfig / sun5i-a13-inet-86vs - iNet_D978_rev2_defconfig / sun8i-a33-inet-d978-rev2 - icnova-a20-swac_defconfig / sun7i-a20-icnova-swac - sun8i_a23_evb_defconfig / sun8i-a23-evb Similarly, the following boards set CONFIG_USB1_VBUS_PIN, but do not have "usb1_vbus-supply" in their device tree. Neither of them have USB enabled at all, so again there should be no impact: - Cubieboard4_defconfig / sun9i-a80-cubieboard4 (also for USB3) - sun8i_a23_evb_defconfig / sun8i-a23-evb The following boards use a different pin for USB1 VBUS between their defconfig and their device tree. Depending on which is correct, they may be broken: - Linksprite_pcDuino3_Nano_defconfig (PH11) / sun7i-a20-pcduino3-nano (PD2) - icnova-a20-swac_defconfig (PG10) / sun7i-a20-icnova-swac (PH6) Finally, this board has conflicting pins given for its USB2 VBUS: - Lamobo_R1_defconfig (PH3) / sun7i-a20-lamobo-r1 (PH12) Signed-off-by: Samuel Holland <samuel@sholland.org> [Andre: use regulator_set_enable_if_allowed()] Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> 
The device tree binding for the PHY provides VBUS supplies as regulator
references. Now that all boards have the appropriate regulator uclass
drivers enabled, the PHY driver can switch to using them. This replaces
direct GPIO usage, which in some cases needed a special DM-incompatible
"virtual" GPIO from the PMIC.

The following boards provided a value for CONFIG_USB0_VBUS_PIN, but are
missing the "usb0_vbus-supply" property in their device tree. None of
them have the MUSB controller enabled in host or OTG mode, so they
should see no impact:
 - Ainol_AW1_defconfig / sun7i-a20-ainol-aw1
 - Ampe_A76_defconfig / sun5i-a13-ampe-a76
 - CHIP_pro_defconfig / sun5i-gr8-chip-pro
 - Cubieboard4_defconfig / sun9i-a80-cubieboard4
 - Merrii_A80_Optimus_defconfig / sun9i-a80-optimus
 - Sunchip_CX-A99_defconfig / sun9i-a80-cx-a99
 - Yones_Toptech_BD1078_defconfig / sun7i-a20-yones-toptech-bd1078
 - Yones_Toptech_BS1078_V2_defconfig /
   sun6i-a31s-yones-toptech-bs1078-v2
 - iNet_3F_defconfig / sun4i-a10-inet-3f
 - iNet_3W_defconfig / sun4i-a10-inet-3w
 - iNet_86VS_defconfig / sun5i-a13-inet-86vs
 - iNet_D978_rev2_defconfig / sun8i-a33-inet-d978-rev2
 - icnova-a20-swac_defconfig / sun7i-a20-icnova-swac
 - sun8i_a23_evb_defconfig / sun8i-a23-evb

Similarly, the following boards set CONFIG_USB1_VBUS_PIN, but do not
have "usb1_vbus-supply" in their device tree. Neither of them have USB
enabled at all, so again there should be no impact:
 - Cubieboard4_defconfig / sun9i-a80-cubieboard4 (also for USB3)
 - sun8i_a23_evb_defconfig / sun8i-a23-evb

The following boards use a different pin for USB1 VBUS between their
defconfig and their device tree. Depending on which is correct, they
may be broken:
 - Linksprite_pcDuino3_Nano_defconfig (PH11) /
   sun7i-a20-pcduino3-nano (PD2)
 - icnova-a20-swac_defconfig (PG10) / sun7i-a20-icnova-swac (PH6)

Finally, this board has conflicting pins given for its USB2 VBUS:
 - Lamobo_R1_defconfig (PH3) / sun7i-a20-lamobo-r1 (PH12)

Signed-off-by: Samuel Holland <samuel@sholland.org>
[Andre: use regulator_set_enable_if_allowed()]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
phy: rockchip-inno-usb2: Add support for RK3528 2025-04-23T14:12:04+00:00 Jonas Karlman jonas@kwiboo.se 2025-04-07T22:47:00+00:00 b9cf58dacd69e3458832e4edc9de8baeb8e26ec2 Add support for the two USB2.0 PHYs use in the RK3528 SoC. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> 
Add support for the two USB2.0 PHYs use in the RK3528 SoC.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
phy: rockchip-inno-usb2: Add support for clkout_ctl_phy 2025-04-23T14:12:04+00:00 Jonas Karlman jonas@kwiboo.se 2025-04-07T22:46:59+00:00 229218373c221d3ac093179f83ec1fdddcbd4dfe The 480m clk is controlled using regs in the PHY address space and not in the USB GRF address space on e.g. RK3528 and RK3506. Add a clkout_ctl_phy usb2phy_reg to handle enable/disable of the 480m clk on these SoCs. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> 
The 480m clk is controlled using regs in the PHY address space and not
in the USB GRF address space on e.g. RK3528 and RK3506.

Add a clkout_ctl_phy usb2phy_reg to handle enable/disable of the 480m
clk on these SoCs.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Merge patch series "Switch to using $(PHASE_) in Makefiles" 2025-04-11T18:16:49+00:00 Tom Rini trini@konsulko.com 2025-04-11T18:16:49+00:00 407d68638fe32418d61681407effba2a303bb9ee Tom Rini <trini@konsulko.com> says: This series switches to always using $(PHASE_) in Makefiles when building rather than $(PHASE_) or $(XPL_). It also starts on documenting this part of the build, but as a follow-up we need to rename doc/develop/spl.rst and expand on explaining things a bit. Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com 
Tom Rini <trini@konsulko.com> says:

This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.

Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
Kbuild: Always use $(PHASE_) 2025-04-11T18:16:44+00:00 Tom Rini trini@konsulko.com 2025-04-01T22:55:23+00:00 302b41d5397e9f821d360a74335e8821d4513970 It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our Makefiles as part of the macros to determine when to do something in our Makefiles based on what phase of the build we are in. For consistency, bring this down to a single macro and use "$(PHASE_)" only. Signed-off-by: Tom Rini <trini@konsulko.com> 
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.

Signed-off-by: Tom Rini <trini@konsulko.com>
phy: phy-qcom-qusb2: Fix USB PHY power on sequence 2025-04-10T13:43:12+00:00 Sumit Garg sumit.garg@oss.qualcomm.com 2025-04-10T08:00:27+00:00 45acd9d2d4ec84775d09c73aab75a4fd989beb41 Recent addition of support for SDM660 inadvertently broke USB PHY power on sequence on RB1/RB2 and others with following error: starting USB... Bus usb@4e00000: QUSB2PHY pll lock failed: status reg = 0 qcom-qusb2-phy phy@1613000: PHY: Failed to power on phy@1613000: -16. Can't power on PHY0 probe failed, error -16 No USB controllers found The root cause was the addition of flag se_clk_scheme_default which was configured correctly for SDM660 but incorrect for all other supported SoC. Fix that by properly assignment as per upstream Linux driver. Fixes: 475497dc3c15 ("phy: Add SDM660 support to Qualcomm QUSB2 phy") Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250410080027.208674-3-sumit.garg@kernel.org Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> 
Recent addition of support for SDM660 inadvertently broke USB PHY power
on sequence on RB1/RB2 and others with following error:

starting USB...
Bus usb@4e00000: QUSB2PHY pll lock failed: status reg = 0
qcom-qusb2-phy phy@1613000: PHY: Failed to power on phy@1613000: -16.
Can't power on PHY0
probe failed, error -16
No USB controllers found

The root cause was the addition of flag se_clk_scheme_default which was
configured correctly for SDM660 but incorrect for all other supported
SoC. Fix that by properly assignment as per upstream Linux driver.

Fixes: 475497dc3c15 ("phy: Add SDM660 support to Qualcomm QUSB2 phy")
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by:
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250410080027.208674-3-sumit.garg@kernel.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
phy: Add SDM660 support to Qualcomm QUSB2 phy 2025-04-10T13:43:08+00:00 Alexey Minnekhanov alexeymin@postmarketos.org 2025-03-25T08:37:13+00:00 ec2850e40ceb182b81d7ad74686d96585fbedebc Imported from Linux driver. Note that already existing but previously unused member of struct qusb2_phy::has_se_clk_scheme is now utilized for it's purpose. Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Link: https://lore.kernel.org/r/20250325083713.2425430-1-alexeymin@postmarketos.org Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> 
Imported from Linux driver.

Note that already existing but previously unused member of
struct qusb2_phy::has_se_clk_scheme is now utilized for it's
purpose.

Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250325083713.2425430-1-alexeymin@postmarketos.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>