Re: [PATCH v2 0/9] arm64: dts: phy: st: usb: Add STM32MP2 USB support

Marek Vasut <[email protected]>
Newsgroups org.kernel.vger.linux-devicetree,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-phy,org.kernel.vger.linux-kernel,org.kernel.vger.linux-usb
Message-ID <[email protected]>
On 8/17/26 6:35 PM, Fabrice Gasnier wrote:
> 
> On 8/16/26 23:37, Marek Vasut wrote:
>> Add USB support for STM32MP23xx/STM32MP25xx SoCs. This includes USB 2.0
>> FEMTO-PHY driver, DWC3 glue code and DT adjustments. Parts of this are
>> taken from ST downstream kernel fork, reduced, or rewritten, since not
>> all of the content there was useful and bits which might be missing and
>> are useful can be added later.
>>
>> Unlike the downstream implementation, the DWC3 glue code is using plain
>> dwc3-generic-plat, the EHCI and OHCI controllers are instantiated as
>> plain generic controllers without any wrapper glue driver, and the USB2
>> PHY driver is simplified.
>>
>> Both USB 2.0 Host controller and DWC3 super-speed controller are tested.
> 
> Hi Marek,

Hello Fabrice,

> Regarding dwc3, I've started to test and needed another patch from our
> downstream. I've posted it here:
> https://lore.kernel.org/linux-usb/[email protected]/

Understood.

> Regarding USBH, there's a dedicated glue on STM32MP2x SoCs for the
> EHCI/OHCI controllers, similar to the dwc3. On dwc3, I see it can be
> managed.
> 
> There are:
> - AFMUX signals out of EHCI/OHCI controllers, to manage a Vbus power
> switch (with polarity) control.
> - AFMUX need pinctrl to be added, and managed during system PM

This can be managed by the PHY instead, can it not ?

> - On coming MP21 (not supported here), there's address translation control

What kind of address translation ? IOMMU ?

> - Common dedicated interrupt to manage wakeup

This is EXTI configuration, is it not ?

> Using generic controller drivers, I don't see how to manage it, without
> describing it in the DT.
> 
> For sure, generic ehci/ochi drivers and bindings can/must be used. What
> would be the proper place for this glue to leave ? Why not adding the
> glue driver from the downstream ? That's supposed to address this.
> 
> Do you wish I send it upstream, so it can be properly reviewed, amended ?

I would very much prefer to avoid the glue if that is at all possible.
Thus far, it seems this could be done (interrupts are generic interrupts 
managed by EXTI, Vbus detection polarity is likely a PHY thing since 
this is managed by SYSCFG anyway) ?

> I'd like to sort this glue management out before the DT for the USBH can
> land.
ACK

[...]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.