linux-kernel - Re: [PATCH v4 2/2] usb: dwc3: Add Google Tensor SoC DWC3 glue driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251106003830.v22dnomurtqmqc2y@synopsys.com>
Date: Thu, 6 Nov 2025 00:38:45 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: Roy Luo <royluo@...gle.com>
CC: Thinh Nguyen <Thinh.Nguyen@...opsys.com>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Peter Griffin <peter.griffin@...aro.org>,
        André Draszik <andre.draszik@...aro.org>,
        Tudor Ambarus <tudor.ambarus@...aro.org>,
        Joy Chakraborty <joychakr@...gle.com>,
        Naveen Kumar <mnkumar@...gle.com>,
        Badhri Jagan Sridharan <badhri@...gle.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
        "linux-samsung-soc@...r.kernel.org" <linux-samsung-soc@...r.kernel.org>
Subject: Re: [PATCH v4 2/2] usb: dwc3: Add Google Tensor SoC DWC3 glue driver

On Tue, Nov 04, 2025, Roy Luo wrote:
> On Tue, Nov 4, 2025 at 10:07 AM Thinh Nguyen <Thinh.Nguyen@...opsys.com> wrote:
> >
> > On Fri, Oct 31, 2025, Roy Luo wrote:
> > > On Wed, Oct 29, 2025 at 6:35 PM Thinh Nguyen <Thinh.Nguyen@...opsys.com> wrote:
> >
> > In dwc3_google_suspend(), looks like is_hibernation is set after you
> > enable pme irq, probably very unlikely, but can the interrupt be
> > asserted then? If so, will there be another interrupt asserted?
> > Otherwise the current logic may think it was spurious interrupt a miss
> > an event.
> 
> The pme interrupt can only be asserted after controller is in
> hibernation, that is, after the usb psw dom is turned off and
> the dwc3_google_usb_psw_pd_notifier() callback is
> completed. So no, the interrupt won't fire before is_hibernation
> is set.

Thanks for the confirmation.


<snip>


> > > >
> > > > I'm still trying to wrap my head around how usb_top_pd, usb_psw_pd, and
> > > > the google->dev are working together in the glue here, particularly why
> > > > usb_top_pd is needed. It seems usb_top_pd shouldn't be handled by this
> > > > glued? Do you do anything except setting wakeup-capable?
> > > >
> > > > BR,
> > > > Thinh
> > >
> > > To provide more context, the underlying usb power domain has 3 power
> > > states: Full Power, Power Gated, Off. The usb_top_pd and usb_psw_pd
> > > are the logical power domains to represent the 3 power states.
> > > - Full Power:     usb_psw_pd ON,   usb_top_p ON.
> > > - Power Gated: usb_psw_pd OFF, usb_top_p ON.
> > > - Off:                 usb_psw_pd OFF, usb_top_p OFF.
> > >
> > > To enter hibernation, the usb power domain must enter Power Gated
> > > state. To achieve this, this glue driver holds a handle to usb_top_pd
> > > and would cast a vote to keep it ON when attempting to enter
> > > hibernation. In addition, the usb_psw_pd runtime PM is directly tied
> > > to google->dev so that usb_psw_pd would be OFF when google->dev
> > > suspends. Together, the usb power domain would reach Power Gated
> > > state when device suspends.
> > >
> > > I hope this information helps.
> > >
> >
> > Yes. This is very helpful.
> >
> > So, while the glue driver is bound, usb_top_pd is always ON? Even when
> > xhci driver is not bound or when in device mode?
> 
> Since usb_top_pd is the parent power domain of usb_psw_pd, and
> usb_psw_pd RPM is directly tied to glue device, usb_top_pd would
> be ON when glue device is active (because usb_psw_pd is ON)
> and would be OFF when glue device suspends in non-hibernation
> scenarios (because usb_psw_pd is OFF). In hibernation scenario,
> a vote is casted for usb_top_pd to keep it on even when the
> glue device is suspended and usb_psw_pd is OFF.
> 
> To your question, usb_top_pd is not always ON because it would be
> turned off when the glue device suspends in non-hibernation scenario.
> When in device mode and provided dwc3 dev is active, usb_top_pd
> would be ON because its child usb_psw_pd is ON.
> 

Thanks for the clarification and bearing with my questions.

If there's no device connected, do you role-switch back to default mode?
Often I see that the role-switch is defaulted to peripheral and switch
to default mode if there's no connection.

I want to check the case where the device may wakeup by connection but
cannot because it is not in host mode. Do you have a separate
TCPC/connector that can wakeup the system on attachment?

BR,
Thinh