drivers: usb: udc: stm32: move power configuration to common code

[mathieuchopstm]

Create infrastructure for shared USB common code on STM32 family, and move the Power Controller configuration logic to common code.

The power configuration is left unchanged for now, but it can be further cleaned up and improved in the future.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jfischer-no]

Create infrastructure for shared USB common code on STM32 family, and move
the Power Controller configuration logic to common code.

But it is not shared. You just moved the code from UDC driver. It is not worth it to touch legacy driver at this point. What is the reason to move the code?

If there is stm32_usb_pwr_enable(void), then you need also stm32_usb_pwr_disable(). stm32_usb_pwr.c actually looks like regulator driver. Why not use regulator API and implement a regulator driver? What you would need to implement is just

static DEVICE_API(regulator, api) = {
	.enable = stm32_usbreg_enable,
	.disable = stm32_usbreg_disable,
};

[mathieuchopstm]

But it is not shared.

It is not shared for now, but would become shared when/if an STM32 UHC driver is implemented.

It is not worth it to touch legacy driver

What do you mean by legacy driver? This is the mainline UDC driver, usb_dc_stm32.c is left untouched.

If there is stm32_usb_pwr_enable(void), then you need also stm32_usb_pwr_disable().

I did not implement disable() because it requires refcounting, but...

stm32_usb_pwr.c actually looks like regulator driver.

...good remark - and this solves refcounting issues. I'll try implementing as a regulator driver.

[mathieuchopstm]

After a quick and dirty implementation, I don't think a regulator driver will be an acceptable solution. Turning this code into a regulator driver (and thus enabling the regulator subsystem!) adds an unjustified ~1K to the ROM footprint (on our smallest product with USB support, that's 2% of ROM size!)

Would you be OK if the code was in soc/st/common instead of drivers/usb/common?
(note that next PR in patchlist will place things in drivers/usb/common either way - unless that directory is pure legacy, in which case what's there should be migrated to a Nordic SoC-specific folder 🙂)

[jfischer-no]

It is not shared for now, but would become shared when/if an STM32 UHC driver is implemented.

Just FYI, UHC shim driver for DWC2 controller would not be acceptable.

It is not worth it to touch legacy driver

What do you mean by legacy driver? This is the mainline UDC driver, usb_dc_stm32.c is left untouched.

From the commit message it is not clear where it would be shared, so I have to guess.

If there is stm32_usb_pwr_enable(void), then you need also stm32_usb_pwr_disable().

I did not implement disable() because it requires refcounting, but...

But why move still "not yet" shared code and keep it half-backed?

After a quick and dirty implementation, I don't think a regulator driver will be an acceptable solution. Turning this code into a regulator driver (and thus enabling the regulator subsystem!) adds an unjustified ~1K to the ROM footprint (on our smallest product with USB support, that's 2% of ROM size!)

AFAIK there is no regulator subsystem and the increased footprint sounds acceptable to me, we should stimulate the market, but I do not insist on it. Please add stm32_usb_pwr_disable().