All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mehmet Fide <mehmet.fide@gmail.com>
To: Marek Vasut <marek.vasut+usb@mailbox.org>,
	Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>,
	u-boot@lists.u-boot-project.org,
	Mehmet Fide <mehmet.fide@screeningeagle.com>
Subject: [PATCH v3 0/2] vf610: make the USB host port usable
Date: Thu, 20 Aug 2026 12:25:21 +0200	[thread overview]
Message-ID: <20260820102523.1076815-1-mehmet.fide@gmail.com> (raw)

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

A device plugged into the host port of a Colibri VF50 or VF61 carrier is
never found, for two reasons.

The pin that switches VBUS never becomes an output: device_probe() reads
the device tree into plat data before it applies the pinctrl state, so
the fixed regulator asks for its GPIO first and the pinctrl state of the
same device then rewrites the pad. Harmless on most SoCs, where the
direction lives in the GPIO block, but on Vybrid the output buffer
enable is a bit of that pad. Patch 1 moves the call back below the
pinctrl step, where it was until 2019. Unchanged since v1.

Patch 2 makes the driver enable the vbus-supply of its port.

v3: Marek asked what happens if the lookup fails with something like
-ENOMEM. v2 ignored every error, so a supply that is described but
cannot be brought up left the port silently unpowered. It now separates
the two cases the way stm32_dsi.c and tdo-tl070wsh30.c do: -ENOENT means
the port has no vbus-supply and -ENOSYS means the build has no
DM_REGULATOR, both of which are normal here, since of the five boards
that select ARCH_VF610 only the Colibri enables DM_REGULATOR at all.
Anything else fails the probe.

v2: dropped the CONFIG_IS_ENABLED(DM_REGULATOR) guards and the NULL
check, the regulator calls handle both themselves.

Patch 2 applies on top of

  https://lore.kernel.org/u-boot/20260820071511.1036506-1-mehmet.fide@gmail.com/

Testing. test/py on sandbox, before and after patch 1: 11 failed, 414
passed, 210 skipped, 1 xfailed, 20 errors, the same failures both times.
Built for vf610twr as well, which has no DM_REGULATOR, to cover the
stubbed path.

On a Colibri VF50 V1.2A on an Iris carrier, U-Boot 2026.07 from NAND:
"usb start" finds a USB stick, the pad of the VBUS pin reads 0x22ef
instead of 0x22ed, and Linux still boots with Ethernet, SD card and USB
working.

v1: https://lore.kernel.org/u-boot/20260819143543.427396-1-mehmet.fide@gmail.com/
v2: https://lore.kernel.org/u-boot/20260820071536.1036898-1-mehmet.fide@gmail.com/

Mehmet Fide (2):
  dm: core: read the device tree into plat data after pinctrl
  usb: ehci-vf: enable the vbus supply of the port

 drivers/core/device.c      |  8 ++++----
 drivers/usb/host/ehci-vf.c | 29 ++++++++++++++++++++++++++++-
 2 files changed, 32 insertions(+), 5 deletions(-)

-- 
2.54.0


             reply	other threads:[~2026-08-20 10:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 10:25 Mehmet Fide [this message]
2026-08-20 10:25 ` [PATCH v3 1/2] dm: core: read the device tree into plat data after pinctrl Mehmet Fide
2026-08-20 10:25 ` [PATCH v3 2/2] usb: ehci-vf: enable the vbus supply of the port Mehmet Fide

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260820102523.1076815-1-mehmet.fide@gmail.com \
    --to=mehmet.fide@gmail.com \
    --cc=marek.vasut+usb@mailbox.org \
    --cc=mehmet.fide@screeningeagle.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.u-boot-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.