Messages in this thread | | | Subject | Re: [PATCH v2 1/2] usb: ulpi: defer ulpi_register on ulpi_read_id timeout | From | Stephen Boyd <> | Date | Mon, 12 Dec 2022 13:51:39 -0800 |
| |
Quoting Ferry Toth (2022-11-11 06:04:16) > + Stephen Boyd > > On 10-11-2022 22:11, Ferry Toth wrote: > > Since commit 0f010171 > > Dual Role support on Intel Merrifield platform broke due to rearranging > > the call to dwc3_get_extcon(). > > > > It appears to be caused by ulpi_read_id() on the first test write failing > > with -ETIMEDOUT. Currently ulpi_read_id() expects to discover the phy via > > DT when the test write fails and returns 0 in that case even if DT does not > > provide the phy. As a result usb probe completes without phy. > > > > Signed-off-by: Ferry Toth <ftoth@exalondelft.nl> > > --- > > drivers/usb/common/ulpi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c > > index d7c8461976ce..60e8174686a1 100644 > > --- a/drivers/usb/common/ulpi.c > > +++ b/drivers/usb/common/ulpi.c > > @@ -207,7 +207,7 @@ static int ulpi_read_id(struct ulpi *ulpi) > > /* Test the interface */ > > ret = ulpi_write(ulpi, ULPI_SCRATCH, 0xaa); > > if (ret < 0) > > - goto err; > > + return ret; > > > > ret = ulpi_read(ulpi, ULPI_SCRATCH); > > if (ret < 0) > > Would this affect others phys (like qcom HSIC)? I'm not sure if failing > the test write is a normal behavior.
I don't think failing a test write is normal behavior. I don't have this hardware on hand anymore though, so I can't help test it. Looks OK to me though:
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
| |