Re: [PATCH] usb: ulpi: warn when a PHY with no DT node cannot be read

[Brian Ellis (US)]

Hello Heikki,

Thanks for looking at this.  Nothing in software powers it on: our
board feeds the USB3340's VBAT from the connector's VBUS, so the PHY
only comes up when a cable is plugged in.  Booted without one, there is
no ULPI clock and the scratch write times out.  That was a bad design
choice, and the next board spin fixes it.

So the root problem is our board, not ulpi, and I agree a warning is
the wrong answer.  A dev_dbg version would only help boards wired like
ours, so I won't send one.  Greg, please don't apply this patch; I
withdraw it.

An LLM assistant (Claude) helped draft this reply.

Thanks,
Brian

________________________________________
From: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
Sent: Wednesday, November 11, 2026 7:56 AM
To: Brian Ellis (US) <brianellis@xxxxxxxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; linux-usb@xxxxxxxxxxxxxxx <linux-usb@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>
Subject: Re: [PATCH] usb: ulpi: warn when a PHY with no DT node cannot be read

[You don't often get email from heikki.krogerus@xxxxxxxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


On Mon, Nov 09, 2026 at 11:22:57AM -0700, Brian Ellis via B4 Relay wrote:
> From: Brian Ellis <brianellis@xxxxxxxxxxx>
>
> ulpi_read_id() checks that the PHY's registers can be reached by writing
> ULPI_SCRATCH and reading it back.  If the write fails or the value does
> not come back, it falls back to OF matching and returns success, with
> nothing logged and ulpi->id left at 0000:0000.
>
> Commit ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") added
> that fallback for PHYs described in DT, which may not be powered yet when
> the ID is read.  For a PHY with no DT node it does nothing:
> of_request_module() returns -ENODEV for a NULL node, and ulpi_match() can
> only match a zero vendor ID through OF.  The PHY is never identified and
> nothing says why, so code that keys off ulpi->id, such as dwc3's USB3340
> detection, silently does not apply.
>
> Commit 8a7b31d545d3 ("usb: ulpi: defer ulpi_register on ulpi_read_id
> timeout") made the failed write an error for this reason.  It was
> reverted by commit b659b613cea2 ("Revert "usb: ulpi: defer
> ulpi_register on ulpi_read_id timeout"") because QEMU's Zynq machines,
> where this write times out, then could not boot from USB.  So keep the
> behaviour and only report it.
>
> We hit this on a ZynqMP board whose USB3340 takes its PLL supply from
> VBUS, so its ULPI clock only runs with a cable attached.  Booted without
> one, the scratch write times out, the PHY reads as 0000:0000, and dwc3
> never enables the USB3340 transceiver delay, all without a message.
>
> Warn when register access fails and there is no DT node to fall back on.
> PHYs described in DT, and PHYs whose registers work but report no vendor
> ID, stay silent as before.
>
> Signed-off-by: Brian Ellis <brianellis@xxxxxxxxxxx>
> ---
> How this was tested: the failure was observed on our board, on AMD's
> 6.6-based vendor kernel, where an earlier version of this patch warned on
> every fallback and printed
>
>   dwc3 fe200000.usb: ULPI id read failed or unavailable (0000:0000); relying on OF match
>
> on a boot without a cable.  That version would also have warned for
> DT-described PHYs and for PHYs with no vendor ID, which is why it was
> narrowed to this one.  This version has not been run on hardware.  On
> usb-next it is compile-tested only (x86_64 allmodconfig, W=1, no
> warnings).
>
> On QEMU's Zynq machines, where the scratch write times out (see
> b659b613cea2), this prints one line at boot.  That is accurate there too:
> the PHY is not identified.
>
> Tool use: an LLM coding assistant (Claude) helped investigate this, wrote
> the code change, and drafted this changelog and these notes.  The
> observation above was made on our hardware.

Instead of adding this kind noise back, I would prefer to see a patch
that fixes the root problem. Do you know how is the PHY powered on on
this system?

The message is probable only useful for debugging. Maybe it should be
dev_dbg instead of dev_warn.

Thanks,

--
heikki
________________________________
The information contained in this e-mail and any attachments from Forterra may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.