mirror of
https://github.com/smaeul/u-boot.git
synced 2025-09-11 20:46:00 +01:00
5ea3e3e37e
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>