Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <d92dbf13-5c64-03d0-1aab-6f96d8f45669@gmail.com>
References: <20221110211132.297512-1-ftoth@exalondelft.nl> <20221110211132.297512-2-ftoth@exalondelft.nl> <d92dbf13-5c64-03d0-1aab-6f96d8f45669@gmail.com>
Subject: Re: [PATCH v2 1/2] usb: ulpi: defer ulpi_register on ulpi_read_id timeout
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
        Sean Anderson <sean.anderson@seco.com>,
        Liu Shixin <liushixin2@huawei.com>,
        Andrey Smirnov <andrew.smirnov@gmail.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     Ferry Toth <fntoth@gmail.com>, Ferry Toth <ftoth@exalondelft.nl>,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Date:   Mon, 12 Dec 2022 13:51:39 -0800
User-Agent: alot/0.10
Message-Id: <20221212215141.ADC2EC433EF@smtp.kernel.org>
Precedence: bulk

Quoting Ferry Toth (2022-11-11 06:04:16)
> + Stephen Boyd
>=20
> 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().
> >=20
> > It appears to be caused by ulpi_read_id() on the first test write faili=
ng
> > with -ETIMEDOUT. Currently ulpi_read_id() expects to discover the phy v=
ia
> > 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.
> >=20
> > Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
> > ---
> >   drivers/usb/common/ulpi.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >=20
> > 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 =3D ulpi_write(ulpi, ULPI_SCRATCH, 0xaa);
> >       if (ret < 0)
> > -             goto err;
> > +             return ret;
> >  =20
> >       ret =3D ulpi_read(ulpi, ULPI_SCRATCH);
> >       if (ret < 0)
>=20
> Would this affect others phys (like qcom HSIC)? I'm not sure if failing=20
> 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>