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 [...]