dts: st: stm32u5: restore correct clocks on multi-bit devices

[mathieuchopstm]

During the transition to STM32_CLOCK macro (in 57723cf), the clocks property of peripherals requiring more than one bit to be set were mistakenly modified. Commit 2c3294b partially fixed these errors, but some nodes for the U5 series are still wrong.

Restore clocks on affected devices in corresponding STM32U5 DTSI.

Fixes: 57723cf

[mathieuchopstm]

FTR, pre-STM32_CLOCK DTSI files:

zephyr/dts/arm/st/u5/stm32u5.dtsi

Lines 303 to 310 in 79cf84c

	backup_sram: memory@40036400 {
	compatible = "zephyr,memory-region", "st,stm32-backup-sram";
	reg = <0x40036400 DT_SIZE_K(2)>;
	/* BKPSRAMEN and RAMCFGEN clock enable */
	clocks = <&rcc STM32_CLOCK_BUS_AHB1 0x10020000>;
	zephyr,memory-region = "BACKUP_SRAM";
	status = "disabled";
	};

zephyr/dts/arm/st/u5/stm32u595.dtsi

Lines 101 to 113 in 79cf84c

	usbotg_hs: otghs@42040000 {
	compatible = "st,stm32-otghs";
	reg = <0x42040000 0x20000>;
	interrupts = <73 0>;
	interrupt-names = "otghs";
	num-bidir-endpoints = <9>;
	ram-size = <4096>;
	maximum-speed = "high-speed";
	clocks = <&rcc STM32_CLOCK_BUS_AHB2 0x0000c000>,
	<&rcc STM32_SRC_HSI48 ICKLK_SEL(0)>;
	phys = <&otghs_phy>;
	status = "disabled";
	};

[JarmouniA]

Thanks for taking care of this.

[mathieuchopstm]

I am realizing now - too late 😢 - that f72ef5c accidentally(?) fixed the error in stm32u959.dtsi by moving the OTGPHYEN bit to the OTG PHY node. As such, usbotg_hs is expected to have only STM32_CLOCK(AHB2, 14)...

The backup SRAM node was definitely wrong though.