Is there any update on this issue? I found that this issue still exists on the latest v2024.10 u-boot.
-----Original Message----- From: Zhu, Jianfeng <[email protected]> Sent: Tuesday, August 20, 2024 10:45 AM To: Caleb Connolly <[email protected]>; Marek Vasut <[email protected]>; [email protected]; [email protected] Cc: Cao, Jacky <[email protected]>; [email protected]; [email protected] Subject: 回复: usb: ehci: Fix db410c usb reset not working > Jianfeng: could you run the usb reset command with log level 8 and > paste a log? That might reveal where the FDT lookup goes wrong. Please confirm below log with level 8 dragonboard410c => usb reset resetting USB... Sending event 5/(unknown) to spy 'efi_disk add' Bus usb@78d9000: ofnode_read_prop: assigned-clock-rates: <not found> Sending event 5/(unknown) to spy 'efi_disk add' ofnode_read_prop: assigned-clock-rates: <not found> Sending event 5/(unknown) to spy 'efi_disk add' ofnode_read_prop: assigned-clock-rates: ofnode_read_u32_array: assigned-clock-rates: Looking for clock-controller@1800000 Looking for clock-controller@1800000 - checking qcom_clk - result for clock-controller@1800000: qcom_clk (ret=0) - result for clock-controller@1800000: qcom_clk (ret=0) Looking for clock-controller@1800000 Looking for clock-controller@1800000 - checking qcom_clk - result for clock-controller@1800000: qcom_clk (ret=0) - result for clock-controller@1800000: qcom_clk (ret=0) Looking for clock-controller@1800000 Looking for clock-controller@1800000 - checking qcom_clk - result for clock-controller@1800000: qcom_clk (ret=0) - result for clock-controller@1800000: qcom_clk (ret=0) Looking for phy Looking for phy - result for phy: (none) (ret=-19) - result for phy: (none) (ret=-19) Looking for ulpi Looking for ulpi - result for ulpi: (none) (ret=-19) - result for ulpi: (none) (ret=-19) Port not available. dragonboard410c => Best Regards jianfeng zhu ________________________________________ 发件人: Caleb Connolly <[email protected]> 发送时间: 2024年8月19日 19:28 收件人: Marek Vasut <[email protected]>; Zhu, Jianfeng <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 抄送: Cao, Jacky <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 主题: Re: usb: ehci: Fix db410c usb reset not working On 19/08/2024 13:21, Marek Vasut wrote: > On 8/19/24 4:05 AM, [email protected] wrote: >> usb reset not working error log >> ==================================================================== >> dragonboard410c => usb reset >> resetting USB... >> Bus usb@78d9000: Port not available. >> dragonboard410c => >> ==================================================================== >> >> After commit ed8fbd2889fc ("dts: msm8916: replace with upstream DTS") >> msm8916_usbphy will be defined as a child device of usb@78d9000. usb >> reset will first call usb_stop, and msm8916_usbphy as child dev will >> be unbind in usb_stop, and there is no bind operation in do_usb_start >> afterwards, so the msm8916_usbphy uclass cannot be found. This causes >> ehci_msm probe to fail. >> >> Detailed calling process >> ==================================================================== >> usb reset: >> |-> usb_stop (drivers/usb/host/usb-uclass.c) >> .|-> device_find_first_child >> . |-> device_unbind(rh); <== (unbind msm8916_usbphy) >> |-> do_usb_start >> |-> usb_init (drivers/usb/host/usb-uclass.c) >> |-> device_probe(bus); >> |-> ehci_usb_probe >> |-> generic_setup_phy <== err couldn't find msm8916_usbphy >> ==================================================================== >> >> Fix: rebind the msm8916_usbphy driver during ehci_usb_probe if the >> msm8916_usbphy uclass has been removed. >> >> Signed-off-by: Jianfeng Zhu <[email protected]> >> Reviewed-by: Jacky Cao <[email protected]> >> Reviewed-by: Toyama, Yoshihiro <[email protected]> >> --- >> drivers/usb/host/ehci-msm.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/usb/host/ehci-msm.c >> b/drivers/usb/host/ehci-msm.c index ff336082e3..7cb3ae0849 100644 >> --- a/drivers/usb/host/ehci-msm.c >> +++ b/drivers/usb/host/ehci-msm.c >> @@ -47,6 +47,8 @@ static const struct ehci_ops msm_ehci_ops = { >> .init_after_reset = msm_init_after_reset >> }; >> +static int ehci_usb_of_bind(struct udevice *dev); >> + >> static int ehci_usb_probe(struct udevice *dev) >> { >> struct msm_ehci_priv *p = dev_get_priv(dev); @@ -54,6 +56,7 @@ >> static int ehci_usb_probe(struct udevice *dev) >> struct usb_plat *plat = dev_get_plat(dev); >> struct ehci_hccr *hccr; >> struct ehci_hcor *hcor; >> + struct udevice *phydev; >> int ret; >> ret = clk_get_by_name(dev, "core", &p->core_clk); @@ -80,6 >> +83,10 @@ static int ehci_usb_probe(struct udevice *dev) >> hcor = (struct ehci_hcor *)((phys_addr_t)hccr + >> HC_LENGTH(ehci_readl(&(hccr)->cr_capbase))); >> + ret = uclass_get_device_by_name(UCLASS_PHY, "msm8916_usbphy", >> &phydev); > > Thanks for looking into this. > > Caleb, do you know why generic_setup_phy() started failing now ? Can > it be fixed to handle this platform instead ? I'm not sure, but I do agree that it doesn't seem like this patch addresses the root cause. Jianfeng: could you run the usb reset command with log level 8 and paste a log? That might reveal where the FDT lookup goes wrong. Kind regards, -- // Caleb (they/them)
