From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: question about usb_rebind_intf
Date: Sat, 18 Nov 2017 11:28:35 +0100 [thread overview]
Message-ID: <20171118102835.GG8368@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1711171317370.1447-100000@iolanthe.rowland.org>
On Fri, Nov 17, 2017 at 01:21:28PM -0500, Alan Stern wrote:
> On Fri, 17 Nov 2017, Mathias Nyman wrote:
>
> > On 17.11.2017 19:09, Greg Kroah-Hartman wrote:
> > > On Fri, Nov 17, 2017 at 09:35:51AM -0700, Jerry Snitselaar wrote:
> > >> Should this skip warning that the rebind failed if device_attach
> > >> is returning -EPROBE_DEFER? If I do something like 'rtcwake -m mem -s 30'
> > >> on a laptop I have here I will see a couple "rebind failed: -517" messages
> > >> as it comes back out of suspend. Since the device probe eventually happens
> > >> once probes are not deferred wondering if this warning this be given in that
> > >> case.
> > >>
> > >>
> > >> diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
> > >> index 64262a9a8829..5d3408010112 100644
> > >> --- a/drivers/usb/core/driver.c
> > >> +++ b/drivers/usb/core/driver.c
> > >> @@ -1070,7 +1070,7 @@ static void usb_rebind_intf(struct usb_interface *intf)
> > >> if (!intf->dev.power.is_prepared) {
> > >> intf->needs_binding = 0;
> > >> rc = device_attach(&intf->dev);
> > >> - if (rc < 0)
> > >> + if (rc < 0 && rc != -EPROBE_DEFER)
> > >> dev_warn(&intf->dev, "rebind failed: %d\n", rc);
> > >> }
> > >> }
> > >
> > > What USB driver is returning -EPROBE_DEFER to cause this to be an issue?
> > > Shouldn't that really only be for "platform" drivers and the like? USB
> > > interface drivers should all be "self-contained" within reason.
> > >
> >
> > I see this as well with btusb driver in resume if port was reset.
> >
> > drivers/base/dd.c really_probe() returns -EPROBE_DEFER if it's called before
> > device_unblock_probing() is called.
> >
> > drivers/base/power/main/dpm_complete() will unlock probing after it has
> > finished resuming all devices and called all the pm_ops .complete callbacks.
> >
> > The usb_device_pm_ops .complete callback will try to rebind the interface driver
> > if device was reset at resume, leading to them -EPROBE_DEFER.
> >
> > I guess we either need to rework a few things, or remove that warning.
>
> I agree, and the patch seems like a good idea for now.
Ah, I forgot about the reset stuff.
If someone sends this patch in a format that can be applied, that would
be nice :)
thanks,
greg k-h
next prev parent reply other threads:[~2017-11-18 10:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-17 16:35 question about usb_rebind_intf Jerry Snitselaar
2017-11-17 17:09 ` Greg Kroah-Hartman
2017-11-17 17:45 ` Mathias Nyman
2017-11-17 18:21 ` Alan Stern
2017-11-18 10:28 ` Greg Kroah-Hartman [this message]
2017-12-04 12:05 ` [PATCH] usb: Don't print a warning if interface driver rebind is deferred at resume Mathias Nyman
2017-12-04 18:45 ` Jerry Snitselaar
2017-11-20 10:39 ` question about usb_rebind_intf Oliver Neukum
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=20171118102835.GG8368@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=stern@rowland.harvard.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.