mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Kyle Tso <kyletso@google.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"raychi@google.com" <raychi@google.com>,
	"badhri@google.com" <badhri@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"royluo@google.com" <royluo@google.com>,
	"bvanassche@acm.org" <bvanassche@acm.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH v3] usb: dwc3: Runtime get and put usb power_supply handle
Date: Thu, 8 Aug 2024 01:37:47 +0000	[thread overview]
Message-ID: <20240808013743.tgvfjqgdtxluz52i@synopsys.com> (raw)
In-Reply-To: <CAGZ6i=1v6+Jt3Jecd3euNnumVK781U9DQvRz7cHWnxi8Ga6W=g@mail.gmail.com>

On Wed, Aug 07, 2024, Kyle Tso wrote:
> On Wed, Aug 7, 2024 at 7:29 AM Thinh Nguyen <Thinh.Nguyen@synopsys.com> wrote:
> >
> > On Sun, Aug 04, 2024, Kyle Tso wrote:
> > > It is possible that the usb power_supply is registered after the probe
> >
> > Should we defer the dwc3 probe until the power_supply is registered
> > then?
> >
> 
> We can do that, but getting the power_supply reference just before
> using the power_supply APIs is safer because we don't risk waiting for
> the registration of the usb power_supply. If vbus_draw is being called

I'm a bit confused, wouldn't we need the power_supply to be registered
before you can get the reference. Can you clarify the risk here?

> but the usb power_supply is still not ready, just let it fail without
> doing anything (only print the error logs). The usb gadget function
> still works. And once the usb power_supply is ready, the vbus_draw
> will be fine in following usb state changes.
> 
> Moreover, all drivers using power_supply_get_by_name in the source
> tree adopt this way. IMO it should be okay.
> 
> > > of dwc3. In this case, trying to get the usb power_supply during the
> > > probe will fail and there is no chance to try again. Also the usb
> > > power_supply might be unregistered at anytime so that the handle of it
> >
> > This is problematic... If the power_supply is unregistered, the device
> > is no longer usable.
> >
> > > in dwc3 would become invalid. To fix this, get the handle right before
> > > calling to power_supply functions and put it afterward.
> >
> > Shouldn't the life-cycle of the dwc3 match with the power_supply? How
> > can we maintain function without the proper power_supply?
> >
> > BR,
> > Thinh
> >
> 
> usb power_supply is controlled by "another" driver which can be
> unloaded without notifying other drivers using it (such as dwc3).
> Unless there is a notification mechanism for the (un)registration of
> the power_supply class, getting/putting the reference right
> before/after calling the power_supply api is the best we can do for
> now.
> 

The power_supply driver should not be able to unload while the dwc3
holds the power_supply handle due to dependency between the two. Why
would we want to release the handle while dwc3 still needs it.

This creates an unpredictable behavior where sometime vbus can be drawn
and sometime it can't. Your specific gadget function may work for its
specific purpose, some other may not as its vbus_draw may be essential
for its application.

BR,
Thinh

  reply	other threads:[~2024-08-08  1:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-04  8:46 Kyle Tso
2024-08-06 23:28 ` Thinh Nguyen
2024-08-07  4:33   ` Kyle Tso
2024-08-08  1:37     ` Thinh Nguyen [this message]
2024-08-08 13:11       ` Kyle Tso
2024-08-10  0:56         ` Thinh Nguyen

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=20240808013743.tgvfjqgdtxluz52i@synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=badhri@google.com \
    --cc=bvanassche@acm.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kyletso@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=raychi@google.com \
    --cc=royluo@google.com \
    --cc=stable@vger.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

all inboxes | Powered by JetHome®