d should have some result at-
most
by early next week. I am attempting to verify the use-case of suspend/resume
with: host wake and remote wake.
Thanks again for your nudge.
>
>
> On Tue, 20 Nov 2018, Mayuresh Kulkarni wrote:
>
> >
> > On Fri, 2018-11-16 at 11:08 -0500,
On Tue, 2019-04-23 at 17:12 +0100, Mayuresh Kulkarni wrote:
> On Mon, 2019-04-01 at 16:22 -0400, Alan Stern wrote:
> >
> > Mayuresh:
> >
> > Whatever happened to this discussion? Did you reach a decision on
> > whether the proposed API addition would suit you
USBDEVFS_WAIT_RESUME call returns,
the callers queries the device/interface of its interest to see
what caused resume and take appropriate action on it.
The link to relevant discussion about this patch on linux-usb is -
https://www.spinics.net/lists/linux-usb/msg173285.html
Signed-off-by: Mayuresh Kulkarni
On Wed, 2019-06-05 at 17:02 -0400, Alan Stern wrote:
> On Wed, 5 Jun 2019, Greg KH wrote:
>
> >
> > On Fri, May 10, 2019 at 11:01:09AM +0100, Mayuresh Kulkarni wrote:
> > >
> > > - The current driver increments the PM ref-count in its .open
> >
On Wed, 2019-06-05 at 11:41 +0200, Greg KH wrote:
> On Fri, May 10, 2019 at 11:01:09AM +0100, Mayuresh Kulkarni wrote:
> >
> > - The current driver increments the PM ref-count in its .open
> > API and decrements it in its .close API.
> > - Due to this, it is not possib
On Wed, 2019-06-05 at 17:02 -0400, Alan Stern wrote:
> On Wed, 5 Jun 2019, Greg KH wrote:
>
> >
> > On Fri, May 10, 2019 at 11:01:09AM +0100, Mayuresh Kulkarni wrote:
> > >
> > > - The current driver increments the PM ref-count in its .open
> >
On Mon, 2019-06-17 at 11:55 -0400, Alan Stern wrote:
> On Mon, 17 Jun 2019, Mayuresh Kulkarni wrote:
>
> >
> > >
> > > (Note: I imagine you might run into trouble because devices
> > > generally
> > > do not get put into runtim
On Wed, 2019-06-19 at 11:19 +0200, Oliver Neukum wrote:
> Am Dienstag, den 18.06.2019, 11:50 -0400 schrieb Alan Stern:
> >
> > On Tue, 18 Jun 2019, Mayuresh Kulkarni wrote:
> >
> > >
> > > >
> > > > You're right that the progra
On Wed, 2019-06-19 at 10:40 -0400, Alan Stern wrote:
> On Wed, 19 Jun 2019, Oliver Neukum wrote:
>
> >
> > Am Dienstag, den 18.06.2019, 11:50 -0400 schrieb Alan Stern:
> > >
> > > On Tue, 18 Jun 2019, Mayuresh Kulkarni wrote:
> > >
> > >
On Thu, 2019-06-20 at 11:49 -0400, Alan Stern wrote:
> On Thu, 20 Jun 2019, Mayuresh Kulkarni wrote:
>
> >
> > On Wed, 2019-06-19 at 10:40 -0400, Alan Stern wrote:
> >
> > >
> > > The only solution I can think of is for the userspace program to
>
On Fri, 2019-06-21 at 15:28 -0400, Alan Stern wrote:
> On Fri, 21 Jun 2019, Mayuresh Kulkarni wrote:
>
> >
> > Hi Alan,
> >
> > With the suggested modification (of having suspend/resume of usbfs
> > at
> > device level instead of interface level), looks
On Mon, 2019-06-24 at 13:48 -0400, Alan Stern wrote:
> On Mon, 24 Jun 2019, Mayuresh Kulkarni wrote:
>
> >
> > On Fri, 2019-06-21 at 15:28 -0400, Alan Stern wrote:
> > >
> > > On Fri, 21 Jun 2019, Mayuresh Kulkarni wrote:
> > >
> > >
On Tue, 2019-06-25 at 10:08 -0400, Alan Stern wrote:
> On Tue, 25 Jun 2019, Mayuresh Kulkarni wrote:
>
> >
> > >
> > > There are two possible ways a userspace program can monitor the
> > > device's state:
> > >
> > > 1.
On Wed, 2019-06-26 at 11:07 -0400, Alan Stern wrote:
> On Wed, 26 Jun 2019, Mayuresh Kulkarni wrote:
>
> >
> > On Tue, 2019-06-25 at 10:08 -0400, Alan Stern wrote:
> >
> > >
> > > >
> > > > Based on discussion so far and my understandi
On Fri, 2019-06-21 at 15:28 -0400, Alan Stern wrote:
> On Fri, 21 Jun 2019, Mayuresh Kulkarni wrote:
>
> However, I have been thinking about how to do all this in light of
> Oliver's comments, and it seems like we should make some changes.
>
> First, let's change th
On Fri, 2019-07-05 at 14:51 -0400, Alan Stern wrote:
> On Wed, 3 Jul 2019, Mayuresh Kulkarni wrote:
>
> >
> > As you had mentioned in one of the comment before, the only addition
> > to
> > the patch I have locally is -
> > usbfs_notify_resume() has us
On Fri, 2019-07-05 at 14:51 -0400, Alan Stern wrote:
> On Wed, 3 Jul 2019, Mayuresh Kulkarni wrote:
>
> >
> > As you had mentioned in one of the comment before, the only addition
> > to
> > the patch I have locally is -
> > usbfs_notify_resume() has us
Hi All,
I am seeing a peculiar behaviour which I think *might* be
caused by usb_new_device(). Since usb_new_device() is one of the core
APIs, I cannot explain how PM works for USB device at later point in
time.
In a particular use-case, our composite USB device
exposes HID interface with vendor
On Thu, 2019-08-01 at 13:51 -0400, Alan Stern wrote:
> On Thu, 1 Aug 2019, Mayuresh Kulkarni wrote:
>
> >
> > Hi All,
> >
> > I am seeing a peculiar behaviour which I think *might* be
> > caused by usb_new_device(). Since usb_new_device() is one of the
>
On Fri, 2019-08-02 at 12:27 -0400, Alan Stern wrote:
> On Fri, 2 Aug 2019, Mayuresh Kulkarni wrote:
>
> >
> > Hi Alan,
> >
> > Thanks a lot for clearing out the confusion.
> >
> > Our USB device can operate in 2 mutually exclusive modes: one is
> &g
On Mon, 2019-08-05 at 10:07 -0400, Alan Stern wrote:
> On Mon, 5 Aug 2019, Mayuresh Kulkarni wrote:
>
> >
> > I think I found what is happening here:
> > - Looks like, the USB audio class driver is
> > calling usb_enable_autosuspend().
> The audio maintainers mus
Hi Greg KH,
I have a query regarding the USB-FS driver, usb/core/devio.c.
It looks like it takes a PM ref-count on the USB device in its .open() and
release the PM ref-count on the USB device in its .release().
As a result of this, the USB suspend (L2) does not seem to happen, even if all
the
Mo, 2018-10-08 at 10:50 +0100, Mayuresh Kulkarni wrote:
> > > >
> > > > As a result of this, the USB suspend (L2) does not seem to happen, even
> > > > if all the interface drivers of a composite USB device report "idle" to
> > > > USB core
On Tue, 9 Oct 2018 13:27:02 +0200
Greg KH wrote:
> On Tue, Oct 09, 2018 at 10:51:53AM +0100, Mayuresh Kulkarni wrote:
> > With all due respect, one of the possible reason for this could be,
> > power saving on mobile/tablet platforms (running Android). These
> > platforms
On Thu, 11 Oct 2018 14:29:54 -0400
Alan Stern wrote:
> On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote:
>
> > On Tue, 9 Oct 2018 13:27:02 +0200
> > Greg KH wrote:
> >
> > > On Tue, Oct 09, 2018 at 10:51:53AM +0100, Mayuresh Kulkarni wrote:
> > > > Wit
On Mon, 15 Oct 2018 09:50:46 -0400
Alan Stern wrote:
> On Mon, 15 Oct 2018, Oliver Neukum wrote:
>
> > On Do, 2018-10-11 at 14:29 -0400, Alan Stern wrote:
> > > On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote:
> > [..]
> > > > We are looking into closing the
On Tue, 16 Oct 2018 10:35:47 -0400
Alan Stern wrote:
> On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote:
>
> > > How about instead having a mechanism whereby your usrspace driver can
> > > tell when the device does a remote wakeup? At that point it could
> > > su
On Wed, 17 Oct 2018 10:32:14 -0400
Alan Stern wrote:
> On Wed, 17 Oct 2018, Oliver Neukum wrote:
>
> > On Di, 2018-10-16 at 10:46 -0400, Alan Stern wrote:
> > > On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote:
> > >
> > > > 1. User space decides when
On Thu, 18 Oct 2018 13:42:46 -0400
Alan Stern wrote:
> On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
>
> > > The only way to make the ioctl work properly is to have it do a
> > > runtime-PM put at the start and then a runtime-PM get before it
> > > returns
On Mon, 22 Oct 2018 10:24:46 -0400
Alan Stern wrote:
> On Mon, 22 Oct 2018, Oliver Neukum wrote:
>
> > On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > > On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
> > >
> > > > > The only way to ma
On Wed, 24 Oct 2018 10:10:32 -0400
Alan Stern wrote:
> On Wed, 24 Oct 2018, Mayuresh Kulkarni wrote:
>
> > On Mon, 22 Oct 2018 10:24:46 -0400
> > Alan Stern wrote:
> >
> > > On Mon, 22 Oct 2018, Oliver Neukum wrote:
> > >
> > > &
Stern wrote:
> > > On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
> > >
> > > > > The only way to make the ioctl work properly is to have it do a
> > > > > runtime-PM put at the start and then a runtime-PM get before it
> >
> > If and only if
On Thu, 1 Nov 2018 10:27:06 -0400
Alan Stern wrote:
> On Thu, 1 Nov 2018, Mayuresh Kulkarni wrote:
>
> > On Mon, 22 Oct 2018 10:24:46 -0400
> > Alan Stern wrote:
> >
> > Apologies for late response on this thread, had been on PTOs and also
> > checki
On Wed, 24 Oct 2018 10:10:32 -0400
Alan Stern wrote:
> On Wed, 24 Oct 2018, Mayuresh Kulkarni wrote:
>
> > On Mon, 22 Oct 2018 10:24:46 -0400
> > Alan Stern wrote:
> >
> > > On Mon, 22 Oct 2018, Oliver Neukum wrote:
> > >
> > > &
On Thu, 2018-11-08 at 10:26 -0500, Alan Stern wrote:
> On Thu, 8 Nov 2018, Mayuresh Kulkarni wrote:
>
> >
> > On Wed, 24 Oct 2018 10:10:32 -0400
> > Alan Stern wrote:
> >
> > >
> > > On Wed, 24 Oct 2018, Mayuresh Kulkarni wrote:
> >
On Fri, 2018-11-09 at 10:33 -0500, Alan Stern wrote:
> On Fri, 9 Nov 2018, Mayuresh Kulkarni wrote:
>
> >
> > >
> > > The driver has no way to tell whether the resume was caused by the
> > > host or by the device. (In fact, it's possible for a resum
On Mon, 2018-11-12 at 15:36 +0100, Oliver Neukum wrote:
> On Mo, 2018-11-12 at 12:04 +0000, Mayuresh Kulkarni wrote:
> >
> > I think I now understand the disconnect between us this point. Below is an
> > attempt to bridge that, so please bear with me:
> > 1. In our us
On Thu, 2018-11-15 at 09:56 -0500, Alan Stern wrote:
> On Thu, 15 Nov 2018, Oliver Neukum wrote:
>
> >
> > On Do, 2018-11-15 at 12:45 +, Mayuresh Kulkarni wrote:
> > >
> > >
> > > Understood this for remote-wake part.
> > >
> &g
On Fri, 2018-11-16 at 11:08 -0500, Alan Stern wrote:
> On Fri, 16 Nov 2018, Mayuresh Kulkarni wrote:
>
> >
> > Thanks for the comments. Based on the info so far, attempting to summarize
> > the
> > probable solution, to ensure that I understand it clearly -
> &
39 matches
Mail list logo
