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 -
> >
> > Facts -
> > 1. USBFS driver
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 -
>
> Facts -
> 1. USBFS driver grabs a PM ref-count in .open and drops it in .close which
> means
> USB
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.
> > >
> > > But still unclear about step (1) for host-wake as below
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.
> >
> > But still unclear about step (1) for host-wake as below (please note, I am
> > refering to host-wake and remote-wake as per my previous
On Do, 2018-11-15 at 12:45 +, Mayuresh Kulkarni wrote:
>
> Understood this for remote-wake part.
>
> But still unclear about step (1) for host-wake as below (please note, I am
> refering to host-wake and remote-wake as per my previous comment) -
> Pre-condition: device in suspend and link in
On Mon, 2018-11-12 at 15:36 +0100, Oliver Neukum wrote:
> On Mo, 2018-11-12 at 12:04 +, 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 use-case(s), the end user can
On Mon, 12 Nov 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
On Mo, 2018-11-12 at 12:04 +, 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 use-case(s), the end user can "interact" with composite USB device
> either by physically
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 resume to be
> > > caused by _both_ the host and
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 resume to be
> > caused by _both_ the host and the device, if they request it at the
> > same time.) In the end, it
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 Mon, 22 Oct 2018 10:24:46 -0400
> > >
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 Mon, 22 Oct 2018 10:24:46 -0400
> > > Alan Stern wrote:
> > >
> > > > On Mon, 22 Oct 2018, Oliver Neukum wrote:
> > > >
> >
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 Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > > > >
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
> > checking internally about the pros/cons of
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
> checking internally about the pros/cons of suggested approach.
>
> > On Mon, 22 Oct 2018, Oliver Neukum 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
checking internally about the pros/cons of suggested approach.
> On Mon, 22 Oct 2018, Oliver Neukum wrote:
>
> > On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > >
On Wed, 24 Oct 2018, Mayuresh Kulkarni wrote:
> > > In such a case, since user-space is waiting in "new" ioctl, it is not
> > > in position to queue a request to read-out the async event info. It
> > > will be able to queue a request when the "new" ioctl returns which
> > > will be "time-out"
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 Do, 2018-10-18 at 13:42 -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 Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > > > On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
> > > >
> > > > > > The
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 make the ioctl work properly is to have it do a
> > >
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. This is true regardless of the
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 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
>
On Do, 2018-10-18 at 13:42 -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
If and only if you want to do this with one ioctl()
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. This is true regardless of the reason for returning: normal
> > termination, timeout, signal,
On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
> As I understand, you seem to mention - user-space to tell the USB
> device when to remote-wake.
> But in our case, we cannot tell the device when to remote-wake as the
> USB device needs to detect an "activity" by end user (after link goes
> into
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 it is time to suspend the device and calls
> >
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
> > > submit an URB via usbfs and receive
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 it is time to suspend the device and calls
> > > this ioctl. The implmentation takes care to ensure, no URB is in
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 it is time to suspend the device and calls
> > this ioctl. The implmentation takes care to ensure, no URB is in
> > flight from this caller to this device. Then
On Tue, 16 Oct 2018, Oliver Neukum wrote:
> On Mo, 2018-10-15 at 09:50 -0400, Alan Stern wrote:
> >
> > It seems that a better approach would be to have an ioctl which would:
> >
> > fail if there are any active user URBs;
> >
> > drop the usbfs PM reference so the device can
On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote:
> > It seems that a better approach would be to have an ioctl which would:
> >
> > fail if there are any active user URBs;
> >
> > drop the usbfs PM reference so the device can suspend;
> >
> > block interruptibly until the device
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
> > submit an URB via usbfs and receive the async notification.
> >
> > Alan Stern
>
> Unfortunately,
On Di, 2018-10-16 at 12:10 +0100, Mayuresh Kulkarni wrote:
> On Mon, 15 Oct 2018 09:50:46 -0400
> Alan Stern wrote:
>
> > It seems that a better approach would be to have an ioctl which would:
> >
> > fail if there are any active user URBs;
> >
> > drop the usbfs PM reference so the
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 device instance during normal operation
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:
> > > > With all due respect, one of the possible reason
On Mo, 2018-10-15 at 09:50 -0400, Alan Stern wrote:
>
> It seems that a better approach would be to have an ioctl which would:
>
> fail if there are any active user URBs;
>
> drop the usbfs PM reference so the device can suspend;
>
> block interruptibly until the device
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 device instance during normal operation
> > > i.e.: only open/close device when needed.
> > >
> > >
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 device instance during normal operation
> > i.e.: only open/close device when needed.
> >
> > However, we still have one particular use-case where our USB
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:
> > > With all due respect, one of the possible reason for this could be,
> > > power saving on mobile/tablet platforms
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 usually have a single
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 usually have a single USB port. Specifically from our point
> of view, these
On Di, 2018-10-09 at 10:51 +0100, Mayuresh Kulkarni wrote:
>
> The USB core driver has a module-param "usb_autosuspend_delay" whose default
> value is 2 sec. AFAIU, the PM core will wait at-least 2 sec before scheduling
> the suspend of this USB device.
> So, if the user-space driving any of
First of all thanks for the comments. It is really helpful to get better
insights of this driver.
On Mon, 8 Oct 2018 21:59:44 +0200
Oliver Neukum wrote:
> On Mo, 2018-10-08 at 11:16 -0400, Alan Stern wrote:
> > On Mon, 8 Oct 2018, Oliver Neukum wrote:
> >
> > > On Mo, 2018-10-08 at 10:50
On Mo, 2018-10-08 at 11:16 -0400, Alan Stern wrote:
> On Mon, 8 Oct 2018, Oliver Neukum wrote:
>
> > On 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
On Mon, 8 Oct 2018, Oliver Neukum wrote:
> On 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 driver. The USB suspend
On 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
> driver. The USB suspend seem to happen only when the caller in user-space
46 matches
Mail list logo
