stm32: usb: inconsistent clock selection, at least on U5

[bearsh]

Describe the bug

The usb peripheral consists of two part the controller and the phy. Looking at the U5, if has a "st,stm32-otghs" controller and a "st,stm32u5-otghs-phy" phy. both have a clocks property.

The current driver udc_stm32.c is able to use 2 arguments to the clocks property of the controller, the clocks property of the phy is ignore. this means, if someone want to use the PLL_p clock for usb, he needs to add e.g. <&rcc STM32_SRC_PLL1_P OTGHS_SEL(1)> the the clocks property of the controller. but to make it work with frequencies other than 16MHz, a clock-reference property has to be added to the phy.

this seems quite strange as part of the phy clocking is configured in the controller part in the phy node. furthermore, phy node's clock property is ignored.

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

• Commit: bcc920d

[mathieuchopstm]

As a byproduct of #97539, the clocks property of the PHY will be consumed.

Automatic selection of the source at SYSCFG level from clock configuration (i.e., drop the clock-reference property) may be implemented at a later stage.

When #97539 is merged, this issue will be reclassified as enhancement.