stm32mp1xx: use of reg11, reg18 and vdd_usb rails

[Mark Brown]

On Fri, Mar 01, 2024 at 03:41:08PM +0100, Sean Nyekjaer wrote:

> With this device tree[1]. We have noticed during boot the reg18 is toggled on and off
> without vdd_usb being turned off before reg18 as required in the data sheet[2], section 3.8.1:
> VDD3V3_USBHS must not be present unless VDDA1V8_REG is present, otherwise permanent 
> STM32MP157C/F damage could occur. Must be ensured by PMIC ranking order or with
> external component in case of discrete component power supply implementation.

The most expedient way of dealing with this might be to mark the 1.8V
supply as always on.  That's not ideal if you've got low power use cases
though.

We don't actually have a facility for forcing one supply to be on
whenever another is on - it's something I was expecting someone to have
a need for but it never came up as a runtime issue before, there is
support for keeping the voltage different between two supplies within a
limit which I'd expect would look similar.

> I can fix it by removing the vdd_usb from the usb33 supply[3]:
> The stm32-pwr.c is (to me) rather weird, as it exposes the usb33 as a regulator when in fact it’s a detection pin.
> Is that done on purpose?

If this is not a regulator then it quite simply should not be exposed
via the regulator API.  People keep abusing it rather than implement
reference counting....

> I would like introduce a error in the stm32-pwr.c if something is trying to power off reg18 with usb33 present?
> Would it be okay to return -EBUSY? Or even -ESMOKE? :)

You'd also need to consider what's going to happen with the error but
yes, if the driver knows it's unsafe in all circumstances it's probably
a good idea to prevent the operation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240301/a6e98b96/attachment.sig>