* 答复: [PATCH] drivers/usb/dwc3: Set PHY ready after soft reset done
2021-06-11 13:02 ` Felipe Balbi
@ 2021-06-16 2:55 ` Fang, Yuan
2021-06-29 2:42 ` Fang, Yuan
2021-09-07 11:01 ` Fang, Yuan
2 siblings, 0 replies; 7+ messages in thread
From: Fang, Yuan @ 2021-06-16 2:55 UTC (permalink / raw)
To: Felipe Balbi, Yuan Fang, linux-usb
Hi Balbi,
> It's more safe to set PHY ready after soft reset done
>
> Let's consider a test case like this:
> I have a usb PHY which don't need SW initial before access it, But i
> have a wrong PHY clock default setting in PHY register which means PHY
> is not ready in fact.
> in dwc3_core_init, dwc3_core_get_phy will return 0 despite usb get
> PHYs with return -ENODEV, and set phys_ready=true
> your PHY driver shouldn't return -ENODEV here. Why are you returning -ENODEV? The PHY isn't ready but it _does_ exist.
Sorry for the late reply, my explain may be not clear, let me describe it once more
1, I don’t coding a PHY driver, I have a PHY which do NOT need SW operation
All I should do is set the related PHY ctrl regs correctly. So I do not return anything to generic PHY framework.
2, In my above case, dwc3_core_get_phy will return 0, and set dwc->phys_ready=true, And then,
dwc3_core_soft_reset will cost retries*20ms to check if soft-reset is done , and return -ETIMEDOUT if time out, is that correct?
My point is, in this case(PHY do not set correctly, which is not rare during development stage I think),
PHY initial fail led to soft-reset timeout but dwc->phys_ready is true,
So I think is more safe to say "PHY is ready" after soft-reset done, please let me know your opinion, thanks a lot
Yuan Fang
-----邮件原件-----
发件人: Felipe Balbi [mailto:balbi@kernel.org]
发送时间: 2021年6月11日 21:03
收件人: Yuan Fang; linux-usb@vger.kernel.org
抄送: Fang, Yuan
主题: Re: [PATCH] drivers/usb/dwc3: Set PHY ready after soft reset done
Yuan Fang <fangyuanseu@gmail.com> writes:
> It's more safe to set PHY ready after soft reset done
>
> Let's consider a test case like this:
> I have a usb PHY which don't need SW initial before access it, But i
> have a wrong PHY clock default setting in PHY register which means PHY
> is not ready in fact.
> in dwc3_core_init, dwc3_core_get_phy will return 0 despite usb get
> PHYs with return -ENODEV, and set phys_ready=true
your PHY driver shouldn't return -ENODEV here. Why are you returning -ENODEV? The PHY isn't ready but it _does_ exist.
--
balbi
^ permalink raw reply [flat|nested] 7+ messages in thread
* 答复: [PATCH] drivers/usb/dwc3: Set PHY ready after soft reset done
2021-06-11 13:02 ` Felipe Balbi
2021-06-16 2:55 ` 答复: " Fang, Yuan
@ 2021-06-29 2:42 ` Fang, Yuan
2021-09-07 11:01 ` Fang, Yuan
2 siblings, 0 replies; 7+ messages in thread
From: Fang, Yuan @ 2021-06-29 2:42 UTC (permalink / raw)
To: Fang, Yuan, Felipe Balbi, Yuan Fang, linux-usb
Hi Maintainner,
Could you please share your thoughts with me?
Thanks a lot.
-----邮件原件-----
发件人: Fang, Yuan
发送时间: 2021年6月16日 10:56
收件人: 'Felipe Balbi'; Yuan Fang; linux-usb@vger.kernel.org
主题: 答复: [PATCH] drivers/usb/dwc3: Set PHY ready after soft reset done
Hi Balbi,
> It's more safe to set PHY ready after soft reset done
>
> Let's consider a test case like this:
> I have a usb PHY which don't need SW initial before access it, But i
> have a wrong PHY clock default setting in PHY register which means PHY
> is not ready in fact.
> in dwc3_core_init, dwc3_core_get_phy will return 0 despite usb get
> PHYs with return -ENODEV, and set phys_ready=true
> your PHY driver shouldn't return -ENODEV here. Why are you returning -ENODEV? The PHY isn't ready but it _does_ exist.
Sorry for the late reply, my explain may be not clear, let me describe it once more 1, I don’t coding a PHY driver, I have a PHY which do NOT need SW operation All I should do is set the related PHY ctrl regs correctly. So I do not return anything to generic PHY framework.
2, In my above case, dwc3_core_get_phy will return 0, and set dwc->phys_ready=true, And then, dwc3_core_soft_reset will cost retries*20ms to check if soft-reset is done , and return -ETIMEDOUT if time out, is that correct?
My point is, in this case(PHY do not set correctly, which is not rare during development stage I think), PHY initial fail led to soft-reset timeout but dwc->phys_ready is true, So I think is more safe to say "PHY is ready" after soft-reset done, please let me know your opinion, thanks a lot
Yuan Fang
-----邮件原件-----
发件人: Felipe Balbi [mailto:balbi@kernel.org]
发送时间: 2021年6月11日 21:03
收件人: Yuan Fang; linux-usb@vger.kernel.org
抄送: Fang, Yuan
主题: Re: [PATCH] drivers/usb/dwc3: Set PHY ready after soft reset done
Yuan Fang <fangyuanseu@gmail.com> writes:
> It's more safe to set PHY ready after soft reset done
>
> Let's consider a test case like this:
> I have a usb PHY which don't need SW initial before access it, But i
> have a wrong PHY clock default setting in PHY register which means PHY
> is not ready in fact.
> in dwc3_core_init, dwc3_core_get_phy will return 0 despite usb get
> PHYs with return -ENODEV, and set phys_ready=true
your PHY driver shouldn't return -ENODEV here. Why are you returning -ENODEV? The PHY isn't ready but it _does_ exist.
--
balbi
^ permalink raw reply [flat|nested] 7+ messages in thread
* 答复: [PATCH] drivers/usb/dwc3: Set PHY ready after soft reset done
2021-06-11 13:02 ` Felipe Balbi
2021-06-16 2:55 ` 答复: " Fang, Yuan
2021-06-29 2:42 ` Fang, Yuan
@ 2021-09-07 11:01 ` Fang, Yuan
2 siblings, 0 replies; 7+ messages in thread
From: Fang, Yuan @ 2021-09-07 11:01 UTC (permalink / raw)
To: Fang, Yuan, Felipe Balbi, Yuan Fang, linux-usb
Hi Maintainer,
May I know your thoughts on this topic?
Thanks a lot.
-----邮件原件-----
发件人: Fang, Yuan
发送时间: 2021年6月29日 10:42
收件人: Fang, Yuan; 'Felipe Balbi'; 'Yuan Fang'; 'linux-usb@vger.kernel.org'
主题: 答复: [PATCH] drivers/usb/dwc3: Set PHY ready after soft reset done
Hi Maintainner,
Could you please share your thoughts with me?
Thanks a lot.
-----邮件原件-----
发件人: Fang, Yuan
发送时间: 2021年6月16日 10:56
收件人: 'Felipe Balbi'; Yuan Fang; linux-usb@vger.kernel.org
主题: 答复: [PATCH] drivers/usb/dwc3: Set PHY ready after soft reset done
Hi Balbi,
> It's more safe to set PHY ready after soft reset done
>
> Let's consider a test case like this:
> I have a usb PHY which don't need SW initial before access it, But i
> have a wrong PHY clock default setting in PHY register which means PHY
> is not ready in fact.
> in dwc3_core_init, dwc3_core_get_phy will return 0 despite usb get
> PHYs with return -ENODEV, and set phys_ready=true
> your PHY driver shouldn't return -ENODEV here. Why are you returning -ENODEV? The PHY isn't ready but it _does_ exist.
Sorry for the late reply, my explain may be not clear, let me describe it once more 1, I don’t coding a PHY driver, I have a PHY which do NOT need SW operation All I should do is set the related PHY ctrl regs correctly. So I do not return anything to generic PHY framework.
2, In my above case, dwc3_core_get_phy will return 0, and set dwc->phys_ready=true, And then, dwc3_core_soft_reset will cost retries*20ms to check if soft-reset is done , and return -ETIMEDOUT if time out, is that correct?
My point is, in this case(PHY do not set correctly, which is not rare during development stage I think), PHY initial fail led to soft-reset timeout but dwc->phys_ready is true, So I think is more safe to say "PHY is ready" after soft-reset done, please let me know your opinion, thanks a lot
Yuan Fang
-----邮件原件-----
发件人: Felipe Balbi [mailto:balbi@kernel.org]
发送时间: 2021年6月11日 21:03
收件人: Yuan Fang; linux-usb@vger.kernel.org
抄送: Fang, Yuan
主题: Re: [PATCH] drivers/usb/dwc3: Set PHY ready after soft reset done
Yuan Fang <fangyuanseu@gmail.com> writes:
> It's more safe to set PHY ready after soft reset done
>
> Let's consider a test case like this:
> I have a usb PHY which don't need SW initial before access it, But i
> have a wrong PHY clock default setting in PHY register which means PHY
> is not ready in fact.
> in dwc3_core_init, dwc3_core_get_phy will return 0 despite usb get
> PHYs with return -ENODEV, and set phys_ready=true
your PHY driver shouldn't return -ENODEV here. Why are you returning -ENODEV? The PHY isn't ready but it _does_ exist.
--
balbi
^ permalink raw reply [flat|nested] 7+ messages in thread