public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	JC Kuo <jckuo@nvidia.com>, Vinod Koul <vkoul@kernel.org>,
	Kishon Vijay Abraham I <kishon@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>
Cc: linux-usb@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 2/5] phy: tegra: xusb: Fix USB2 port regulator disable logic
Date: Tue, 13 Jan 2026 14:42:07 +0000	[thread overview]
Message-ID: <043663d0-d592-432b-8550-10669674d17a@nvidia.com> (raw)
In-Reply-To: <54afff11-df9b-4c25-bd1d-8134196ce093@tecnico.ulisboa.pt>


On 13/01/2026 13:59, Diogo Ivo wrote:
> 
> 
> On 1/13/26 12:01, Jon Hunter wrote:
>>
>> On 04/12/2025 21:27, Diogo Ivo wrote:
>>> The USB2 PHY mode handling on Tegra210 incorrectly relied on
>>> regulator_is_enabled() when determining whether the VBUS supply should
>>> be disabled during role changes. This is because regulator_is_enabled()
>>> reports exactly what is states and not if there is an unbalanced number
>>> of calls between regulator_enable() and regulator_disable(). For
>>> example, regulator_is_enabled() always reports true on a fixed-regulator
>>> with no enable gpio, which is the case on the Pixel C.
>>>
>>> This then leads to the PHY driver wrongfully calling regulator_disable()
>>> when transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE since the 
>>> driver
>>> did not previously call the corresponding regulator_enable().
>>>
>>> Fix this by keeping track of the current role and updating the logic to
>>> disable the regulator only when the previous role was USB_ROLE_HOST.
>>>
>>> While at it fix a small typo in a comment.
>>>
>>> Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
>>> ---
>>>   drivers/phy/tegra/xusb-tegra210.c | 5 +++--
>>>   drivers/phy/tegra/xusb.h          | 1 +
>>>   2 files changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/phy/tegra/xusb-tegra210.c b/drivers/phy/tegra/ 
>>> xusb-tegra210.c
>>> index 3409924498e9..63ad57d95514 100644
>>> --- a/drivers/phy/tegra/xusb-tegra210.c
>>> +++ b/drivers/phy/tegra/xusb-tegra210.c
>>> @@ -1934,9 +1934,9 @@ static int tegra210_usb2_phy_set_mode(struct 
>>> phy *phy, enum phy_mode mode,
>>>               /*
>>>                * When port is peripheral only or role transitions to
>>>                * USB_ROLE_NONE from USB_ROLE_DEVICE, regulator is not
>>> -             * be enabled.
>>> +             * enabled.
>>>                */
>>> -            if (regulator_is_enabled(port->supply))
>>> +            if (port->role == USB_ROLE_HOST)
>>>                   regulator_disable(port->supply);
>>>               tegra210_xusb_padctl_id_override(padctl, false);
>>> @@ -1944,6 +1944,7 @@ static int tegra210_usb2_phy_set_mode(struct 
>>> phy *phy, enum phy_mode mode,
>>>           }
>>>       }
>>> +    port->role = submode;
>>>       mutex_unlock(&padctl->lock);
>>>       return err;
>>> diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
>>> index d2b5f9565132..273af147dfd3 100644
>>> --- a/drivers/phy/tegra/xusb.h
>>> +++ b/drivers/phy/tegra/xusb.h
>>> @@ -317,6 +317,7 @@ struct tegra_xusb_usb2_port {
>>>       enum usb_dr_mode mode;
>>>       bool internal;
>>>       int usb3_port_fake;
>>> +    enum usb_role role;
>>>   };
>>
>>
>> A similar fix was made to the Tegra186 code by commit cefc1caee9dd 
>> ("phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY 
>> mode"). Although the above looks simpler, I am wondering if we should 
>> make a similar change to the Tegra210 code so that they both are 
>> implemented in the same way?
> 
> Looking at cefc1caee9dd my approach leads to less changes but I do agree
> that standardization benefits us here. However in that case I think we
> can take it a step further and actually just have a single function
> tegra_xusb_padctl_id_override() (and likewise for vbus_override() and
> set_mode()) since they all seem to do the same thing in both platforms.

Yes I think that would be fine. I can't say I have looked at that in 
detail but that would seem like the logical way to go.

Jon

-- 
nvpublic


  reply	other threads:[~2026-01-13 14:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-04 21:27 [PATCH 0/5] Fixes to Tegra USB role switching and Smaug USB role switching enablement Diogo Ivo
2025-12-04 21:27 ` [PATCH 1/5] usb: host: tegra: Remove redundant pm_runtime_mark_last_busy() call Diogo Ivo
2025-12-07 10:37   ` Diogo Ivo
2025-12-04 21:27 ` [PATCH 2/5] phy: tegra: xusb: Fix USB2 port regulator disable logic Diogo Ivo
2025-12-24  7:27   ` Vinod Koul
2026-01-13 13:30     ` Diogo Ivo
2026-01-13 12:01   ` Jon Hunter
2026-01-13 13:59     ` Diogo Ivo
2026-01-13 14:42       ` Jon Hunter [this message]
2026-01-13 15:05         ` Diogo Ivo
2025-12-04 21:27 ` [PATCH 3/5] phy: tegra: xusb: Fix ordering issue when switching roles on USB2 ports Diogo Ivo
2026-01-13 11:35   ` Jon Hunter
2026-01-13 11:44     ` Jon Hunter
2026-01-13 13:59       ` Diogo Ivo
2026-01-13 11:56   ` Jon Hunter
2026-01-13 14:05     ` Diogo Ivo
2026-01-13 14:48       ` Jon Hunter
2026-01-13 15:10         ` Diogo Ivo
2026-01-13 16:36           ` Jon Hunter
2026-01-15 11:06     ` Diogo Ivo
2026-01-19 14:31       ` Jon Hunter
2025-12-04 21:27 ` [PATCH 4/5] arm64: tegra: smaug: Complete and enable tegra-udc node Diogo Ivo
2025-12-04 21:27 ` [PATCH 5/5] arm64: tegra: smaug: Add usb-role-switch support Diogo Ivo
2026-01-12 22:03   ` Jon Hunter
2026-01-13 14:20     ` Diogo Ivo
2026-01-13 14:49       ` Jon Hunter
2026-01-13 15:11         ` Diogo Ivo
2025-12-05 22:36 ` [PATCH 0/5] Fixes to Tegra USB role switching and Smaug USB role switching enablement Rob Herring
2026-01-13 10:58   ` Jon Hunter
2026-01-12 13:46 ` Diogo Ivo
2026-01-17  0:25 ` (subset) " Thierry Reding

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=043663d0-d592-432b-8550-10669674d17a@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=diogo.ivo@tecnico.ulisboa.pt \
    --cc=gregkh@linuxfoundation.org \
    --cc=jckuo@nvidia.com \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=robh@kernel.org \
    --cc=thierry.reding@gmail.com \
    --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