Linux-PHY Archive mirror
 help / color / mirror / Atom feed
From: Sean Nyekjaer <sean@geanix.com>
To: vkoul@kernel.org, kishon@kernel.org,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	lgirdwood@gmail.com, broonie@kernel.org,
	u.kleine-koenig@pengutronix.de,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	m.grzeschik@pengutronix.de, linux-phy@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org, marex@denx.de,
	p.paillet@st.com, Olivier Moysan <olivier.moysan@foss.st.com>,
	l.goehrs@pengutronix.de, Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: "Martin Hundebøll" <martin@geanix.com>
Subject: stm32mp1xx: use of reg11, reg18 and vdd_usb rails
Date: Fri, 1 Mar 2024 15:41:08 +0100	[thread overview]
Message-ID: <4807FD7F-FEB5-4460-B1EB-3E2330864C8B@geanix.com> (raw)

Hi all,

We are using the osd32mp1 SIP module [0].
We are seeing some hardware get’s fried inside the SIP module.
It’s somewhat traced down to the usb controller/phy/regulator.

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.

It’s happens because the something is already uses the vdd_usb, it’s both the drivers/phy/st/phy-stm32-usbphyc.c
and drivers/regulator/stm32-pwr.c that consumes it.

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?

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? :)

Or is it better to do it in phy-stm32-usbphyc.c[4]?

/Sean

[0]: https://octavosystems.com/octavo_products/osd32mp15x/
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts
[2]: https://www.st.com/resource/en/datasheet/stm32mp157c.pdf
[3]:
diff --git a/arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts b/arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts
index 527c33be66cc..0d67006806c4 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-osd32mp1-red.dts
@@ -149,7 +149,6 @@ &m_can1 {

 &pwr_regulators {
        vdd-supply = <&vdd>;
-       vdd_3v3_usbfs-supply = <&vdd_usb>;
 };

 &rtc {
[4]:
diff --git a/drivers/phy/st/phy-stm32-usbphyc.c b/drivers/phy/st/phy-stm32-usbphyc.c
index d5e7e44000b5..58fcc3099803 100644
--- a/drivers/phy/st/phy-stm32-usbphyc.c
+++ b/drivers/phy/st/phy-stm32-usbphyc.c
@@ -188,8 +188,18 @@ static int stm32_usbphyc_regulators_enable(struct stm32_usbphyc *usbphyc)

 static int stm32_usbphyc_regulators_disable(struct stm32_usbphyc *usbphyc)
 {
+       struct stm32_usbphyc_phy *usbphyc_phy;
        int ret;

+       for (port = 0; port < usbphyc->nphys; port++) {
+               usbphyc_phy = usbphyc->phys[port];
+
+               if(regulator_is_enabled(usbphyc_phy->phy->pwr)) {
+                       pr_err("%s: phy is powered not allowed to switch off regulator\n", __func__);
+                       return -EBUSY;
+               }
+       }
+
        ret = regulator_disable(usbphyc->vdda1v8);
        if (ret)
                return ret;



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

             reply	other threads:[~2024-03-01 14:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01 14:41 Sean Nyekjaer [this message]
2024-03-01 17:04 ` stm32mp1xx: use of reg11, reg18 and vdd_usb rails Mark Brown
2024-03-01 17:58 ` [Linux-stm32] " Fabrice Gasnier
2024-03-04  8:30   ` Sean Nyekjaer
2024-03-04 17:50     ` Fabrice Gasnier
2024-03-05  7:59       ` Sean Nyekjaer
2024-03-18  6:14         ` Sean Nyekjaer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4807FD7F-FEB5-4460-B1EB-3E2330864C8B@geanix.com \
    --to=sean@geanix.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=alexandre.torgue@foss.st.com \
    --cc=broonie@kernel.org \
    --cc=kishon@kernel.org \
    --cc=l.goehrs@pengutronix.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=m.grzeschik@pengutronix.de \
    --cc=marex@denx.de \
    --cc=martin@geanix.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mkl@pengutronix.de \
    --cc=olivier.moysan@foss.st.com \
    --cc=p.paillet@st.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).