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.

Marek Vasut (6):
  dt-bindings: usb: generic-ehci: Document access-controllers property
  dt-bindings: usb: generic-ohci: Document access-controllers property
  dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller
  usb: dwc3: dwc3-generic-plat: Add ST STM32MP2 DWC3 xHCI USB controller
    glue
  dt-bindings: arm: stm32: Switch st,stm32mp23/25-syscfg into simple-mfd
  arm64: dts: st: Add USB nodes on stm32mp231

Pankaj Dev (3):
  dt-bindings: phy: Document ST STM32MP25 USB2-FEMTO PHY
  phy: stm32: Add support for ST STM32MP25 USB2-FEMTO PHY
  arm64: dts: st: Add USB nodes on stm32mp251

 .../bindings/arm/stm32/st,stm32-syscon.yaml   |   7 +-
 .../bindings/phy/st,stm32-usb2phy.yaml        |  73 ++++
 .../devicetree/bindings/usb/generic-ehci.yaml |   3 +
 .../devicetree/bindings/usb/generic-ohci.yaml |   3 +
 .../bindings/usb/st,stm32mp25-dwc3.yaml       | 108 ++++++
 arch/arm64/boot/dts/st/stm32mp231.dtsi        |  81 +++-
 arch/arm64/boot/dts/st/stm32mp251.dtsi        |  65 +++-
 drivers/phy/st/Kconfig                        |  10 +
 drivers/phy/st/Makefile                       |   1 +
 drivers/phy/st/phy-stm32-usb2phy.c            | 361 ++++++++++++++++++
 drivers/usb/dwc3/dwc3-generic-plat.c          |  44 +++
 11 files changed, 751 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-usb2phy.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/st,stm32mp25-dwc3.yaml
 create mode 100644 drivers/phy/st/phy-stm32-usb2phy.c

Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: Christian Bruel <christian.bruel@foss.st.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Pankaj Dev <pankaj.dev@st.com>
Cc: Rahul Kumar <rahul.kumar05@st.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Rosen Penev <rosenp@gmail.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: kernel@dh-electronics.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-phy@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-usb@vger.kernel.org

-- 
2.53.0

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,

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/20260817163101.6203-1-fabrice.gasnier@foss.st.com/


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
- On coming MP21 (not supported here), there's address translation control
- Common dedicated interrupt to manage wakeup

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'd like to sort this glue management out before the DT for the USBH can
land.

Best Regards,
Thanks,
Fabrice

> 
> Marek Vasut (6):
>   dt-bindings: usb: generic-ehci: Document access-controllers property
>   dt-bindings: usb: generic-ohci: Document access-controllers property
>   dt-bindings: usb: dwc3: Document ST STM32MP2 DWC3 xHCI USB controller
>   usb: dwc3: dwc3-generic-plat: Add ST STM32MP2 DWC3 xHCI USB controller
>     glue
>   dt-bindings: arm: stm32: Switch st,stm32mp23/25-syscfg into simple-mfd
>   arm64: dts: st: Add USB nodes on stm32mp231
> 
> Pankaj Dev (3):
>   dt-bindings: phy: Document ST STM32MP25 USB2-FEMTO PHY
>   phy: stm32: Add support for ST STM32MP25 USB2-FEMTO PHY
>   arm64: dts: st: Add USB nodes on stm32mp251
> 
>  .../bindings/arm/stm32/st,stm32-syscon.yaml   |   7 +-
>  .../bindings/phy/st,stm32-usb2phy.yaml        |  73 ++++
>  .../devicetree/bindings/usb/generic-ehci.yaml |   3 +
>  .../devicetree/bindings/usb/generic-ohci.yaml |   3 +
>  .../bindings/usb/st,stm32mp25-dwc3.yaml       | 108 ++++++
>  arch/arm64/boot/dts/st/stm32mp231.dtsi        |  81 +++-
>  arch/arm64/boot/dts/st/stm32mp251.dtsi        |  65 +++-
>  drivers/phy/st/Kconfig                        |  10 +
>  drivers/phy/st/Makefile                       |   1 +
>  drivers/phy/st/phy-stm32-usb2phy.c            | 361 ++++++++++++++++++
>  drivers/usb/dwc3/dwc3-generic-plat.c          |  44 +++
>  11 files changed, 751 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/phy/st,stm32-usb2phy.yaml
>  create mode 100644 Documentation/devicetree/bindings/usb/st,stm32mp25-dwc3.yaml
>  create mode 100644 drivers/phy/st/phy-stm32-usb2phy.c
> 
> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
> Cc: Christian Bruel <christian.bruel@foss.st.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Pankaj Dev <pankaj.dev@st.com>
> Cc: Rahul Kumar <rahul.kumar05@st.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Rosen Penev <rosenp@gmail.com>
> Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: kernel@dh-electronics.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-phy@lists.infradead.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-usb@vger.kernel.org
>

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/20260817163101.6203-1-fabrice.gasnier@foss.st.com/

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

[...]

On 8/17/26 21:48, Marek Vasut wrote:
> 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/20260817163101.6203-1-
>> fabrice.gasnier@foss.st.com/
> 
> 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 ?

Hello Marek,

Please see later comment.

> 
>> - On coming MP21 (not supported here), there's address translation
>> control
> 
> What kind of address translation ? IOMMU ?

This is much more "basic". The controller can address 4G of memory, e.g.
it's 32bits. That feature is only for STM32MP21 that can address 4G of
DDR which starts at 2G offset. So basically there's a SYSCFG bit
(SYSCFG_USBHARCR AREN), that adds a 2G offset so the controller 'DMA'
addresses directly the 4G of the DDR (instead of 2G lower memory map,
that's not necessarily useful, and 2G of the 4G DDR, requiring swiotlb
with perf penalty).

Current downstream glue driver checks the 'dma_range_map', (e.g. DT prop
dma-ranges = <0x0 0x0 0x80000000 0x1 0x0>;) that represent this, to
enable the syscon bit that adds offset in hardware (so 4G of DDR can be
accessed by the controller, without swiotlb).
For USBH, there's nothing mode: set it at probe time, based on
dma_range_map, restore it after resume from low power.

> 
>> - 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 better see your point, thanks for your explanation.
This makes sense! For this part, the approach can be the same on all
STM32MP2 SoCs (21/23/25).

Still for STM32MP21 address remapping feature (out of scope here) I
think there will be not much choice to keep a minimal glue DT & driver
(and parent to generic ehci/ohci). It seems totally out of the PHY
driver purpose.
Maybe you have some thoughts about this ?

Please advise,
Best Regards,
Fabrice

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

On 8/18/26 6:07 PM, Fabrice Gasnier wrote:

Hello Fabrice,

>>> - On coming MP21 (not supported here), there's address translation
>>> control
>>
>> What kind of address translation ? IOMMU ?
> 
> This is much more "basic". The controller can address 4G of memory, e.g.
> it's 32bits. That feature is only for STM32MP21 that can address 4G of
> DDR which starts at 2G offset. So basically there's a SYSCFG bit
> (SYSCFG_USBHARCR AREN), that adds a 2G offset so the controller 'DMA'
> addresses directly the 4G of the DDR (instead of 2G lower memory map,
> that's not necessarily useful, and 2G of the 4G DDR, requiring swiotlb
> with perf penalty).
> 
> Current downstream glue driver checks the 'dma_range_map', (e.g. DT prop
> dma-ranges = <0x0 0x0 0x80000000 0x1 0x0>;) that represent this, to
> enable the syscon bit that adds offset in hardware (so 4G of DDR can be
> accessed by the controller, without swiotlb).
> For USBH, there's nothing mode: set it at probe time, based on
> dma_range_map, restore it after resume from low power.

Maybe the DT syscfg node shouldn't be a plain syscon , but rather there 
should be an actual driver which binds to the syscfg DT node and 
configures all these hardware details early on boot ? The USB controller 
drivers will start only later, when the syscfg configuration is already 
set in the hardware by this (future) driver, since they depend on the 
syscfg node and the PHY subnodes. Maybe that is the way to fix the MP21 
without having USB controller glue ?

>>> - 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 better see your point, thanks for your explanation.
> This makes sense! For this part, the approach can be the same on all
> STM32MP2 SoCs (21/23/25).
> 
> Still for STM32MP21 address remapping feature (out of scope here) I
> think there will be not much choice to keep a minimal glue DT & driver
> (and parent to generic ehci/ohci). It seems totally out of the PHY
> driver purpose.
> Maybe you have some thoughts about this ?
Please see above.

On 8/18/26 18:35, Marek Vasut wrote:
> On 8/18/26 6:07 PM, Fabrice Gasnier wrote:
> 
> Hello Fabrice,
> 
>>>> - On coming MP21 (not supported here), there's address translation
>>>> control
>>>
>>> What kind of address translation ? IOMMU ?
>>
>> This is much more "basic". The controller can address 4G of memory, e.g.
>> it's 32bits. That feature is only for STM32MP21 that can address 4G of
>> DDR which starts at 2G offset. So basically there's a SYSCFG bit
>> (SYSCFG_USBHARCR AREN), that adds a 2G offset so the controller 'DMA'
>> addresses directly the 4G of the DDR (instead of 2G lower memory map,
>> that's not necessarily useful, and 2G of the 4G DDR, requiring swiotlb
>> with perf penalty).
>>
>> Current downstream glue driver checks the 'dma_range_map', (e.g. DT prop
>> dma-ranges = <0x0 0x0 0x80000000 0x1 0x0>;) that represent this, to
>> enable the syscon bit that adds offset in hardware (so 4G of DDR can be
>> accessed by the controller, without swiotlb).
>> For USBH, there's nothing mode: set it at probe time, based on
>> dma_range_map, restore it after resume from low power.
> 
> Maybe the DT syscfg node shouldn't be a plain syscon , but rather there
> should be an actual driver which binds to the syscfg DT node and
> configures all these hardware details early on boot ? The USB controller
> drivers will start only later, when the syscfg configuration is already
> set in the hardware by this (future) driver, since they depend on the
> syscfg node and the PHY subnodes. Maybe that is the way to fix the MP21
> without having USB controller glue ?

Hello Marek,

Ok, I'll think more about it regarding MP21. Let's continue on current
series without any additional glue driver for MP23/25.

Thanks,
Best Regards,
Fabrice

> 
>>>> - 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 better see your point, thanks for your explanation.
>> This makes sense! For this part, the approach can be the same on all
>> STM32MP2 SoCs (21/23/25).
>>
>> Still for STM32MP21 address remapping feature (out of scope here) I
>> think there will be not much choice to keep a minimal glue DT & driver
>> (and parent to generic ehci/ohci). It seems totally out of the PHY
>> driver purpose.
>> Maybe you have some thoughts about this ?
> Please see above.

On 8/19/26 5:19 PM, Fabrice Gasnier wrote:

Hello Fabrice,

>> Maybe the DT syscfg node shouldn't be a plain syscon , but rather there
>> should be an actual driver which binds to the syscfg DT node and
>> configures all these hardware details early on boot ? The USB controller
>> drivers will start only later, when the syscfg configuration is already
>> set in the hardware by this (future) driver, since they depend on the
>> syscfg node and the PHY subnodes. Maybe that is the way to fix the MP21
>> without having USB controller glue ?
> 
> Hello Marek,
> 
> Ok, I'll think more about it regarding MP21. Let's continue on current
> series without any additional glue driver for MP23/25.
There is really no rush, if you can come up with something for MP21 that 
does not require the controller glue, that would be real nice.

Thank you for your help !