linux-kernel - Re: [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL register for OTG mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <988658d3485232a0bb6c433b6533ebf0ae41226a.camel@pengutronix.de>
Date: Tue, 07 Oct 2025 16:13:02 +0200
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Biju Das <biju.das.jz@...renesas.com>, Tommaso Merciai	
 <tommaso.merciai.xr@...renesas.com>, Tommaso Merciai
 <tomm.merciai@...il.com>
Cc: "linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
  Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, Vinod Koul
 <vkoul@...nel.org>, Kishon Vijay Abraham I	 <kishon@...nel.org>, Geert
 Uytterhoeven <geert+renesas@...der.be>,  "magnus.damm"
 <magnus.damm@...il.com>, Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
 Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
 "linux-phy@...ts.infradead.org"	 <linux-phy@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org"	 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL register for
 OTG mode

Hi Biju,

On Di, 2025-10-07 at 11:04 +0000, Biju Das wrote:
> Hi Philipp,
> 
> > -----Original Message-----
> > From: Philipp Zabel <p.zabel@...gutronix.de>
> > Sent: 07 October 2025 10:44
> > Subject: Re: [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL register for OTG mode
> > 
> > Hi Biju,
> > 
> > On Di, 2025-10-07 at 04:02 +0000, Biju Das wrote:
> > > Hi Philipp,
> > > 
> > > Thanks for the feedback.
> > > 
> > > > -----Original Message-----
> > > > From: Philipp Zabel <p.zabel@...gutronix.de>
> > > > Sent: 06 October 2025 17:32
> > > > Subject: Re: [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL
> > > > register for OTG mode
> > > > 
> > > > On Mi, 2025-10-01 at 23:26 +0200, Tommaso Merciai wrote:
> > > > > Add logic to set the VBENCTL register when the USB controller
> > > > > operates in OTG mode. This is required to ensure proper USB
> > > > > transceiver behavior when the device is configured as OTG.
> > > > > 
> > > > > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@...renesas.com>
> > > > 
> > > > I had reservations about this driver before, because of the opaque
> > > > register initialization sequence, and I was told that no, this is a reset driver alright [1].
> > > 
> > > The latest hardware manual document about VBENCTRL register which sets source for VBUS selection.
> > > s
> > 
> > I still can't look at this, right? The USB2PHY control register space appears to be documented in
> > the "RZ/V2H Group User's Manual: Hardware (Additional document)" (under NDA).	
> 
> It is documented here[1], Page 2177, USB2PHY Control Register (USB2m_PHY_VBENCTL)
> 
> [1]
> https://www.renesas.com/en/document/mah/rzg3e-group-users-manual-hardware?r=25574493

For me, that link points to a document without the USB2m_PHY_* register
definitions. Page 2177 is unrelated (documenting PCI_EP_HLOG2_Fn,
somewhere in the PCIe interface chapter).

> > > > Can you please try to find a proper abstraction for this, because
> > > > drivers/reset is not the correct place for USB OTG mode handling.
> > > 
> > > Sorry for the confusion. This driver is not handling USB OTG mode. It
> > > just configures VBENCTRL(one time setting) that selects the source for
> > > VBUS_SEL. Actual USB OTG mode handling is done USB PHY driver which sets host/device mode based on
> > ID detection.
> > 
> > So this is a mux for the VBUS_SEL signal?
> 
> Yes, Please find the bit definition.
> 
> 0 VBUS_SEL 0h RW Select VBUSEN control
> 0b: Output PP controlled by PORTSC1 register of the Host Controller as VBUSEN.
> 1b: Output VBOUT controlled by VBCTRL register of the Host Controller as VBUSEN.
> 
> We have USB PHY control driver(This driver)-> USB PHY driver->| USB HOST(Generic ehci/ohci)
>                                                        	  | USB function (renesas usbhs)
> 
> We plan to set 1b for this IP in this driver for OTG channel during probe.
> After that using VBOUT register the PHY driver can switch between Host and device.

Thank you for the explanation.

> > Why don't the USB host controller drivers parse their "dr_mode"
> > property themselves and control USB2PHY VBENCTRL via the mux API, for example?
> 
> Currently for OTG channel, based ID detection IRQ, the USB PHY driver switches between host
> and device. We use method2 below for the host operation.
> 
> For Host operation:
> Method1: USB2m_PHY_VBENCTL.VBUS_SEL=0
> or
> method2: USB2m_PHY_VBENCTL.VBUS_SEL=1 and USB_HOST_VBCTRL.VBOUT = 1
> 
> For device operation:
> USB2m_PHY_VBENCTL.VBUS_SEL=1 and USB_HOST_VBCTRL.VBOUT = 0
> 
> Are you suggesting to use method1(mux) for host operation?

No, not necessarily. I was thinking of letting the PHY driver, before
registering the VBOUT controlled VBUS regulator in its probe function,
call into the mux API to set VBENCTL.VBUS_SEL=1 and thus make the VBOUT
bit functional.

> Currently this is one time configuration. If we plan to
> use mux, then it becomes dynamic.
>
> How we can we make use of PHY driver using mux API to select the mux register(VBUS_SEL)
> in USB PHY control Driver?

For example, this driver could spawn an auxiliary mux device with a
driver in drivers/mux that registers a mux for VBENCTL.VBUS_SEL on the
&usb20phyrst node.

The phy could then get a "mux-states = <&usb20phyrst 1>;" property in
its device tree node and call the equivalent of:

  mux_state = devm_mux_state_get_optional(dev, NULL);
  mux_state_select(mux_state);

to switch to VBOUT controlled VBUSEN.

regards
Philipp