ed (but did not submit) a more comprehensive solution to
this and other related problems. For example, HID devices typically
run at low speed or full speed. When attached through a hub to an EHCI
controller (very common on modern systems), unplugging the device
causes -EPIPE errors, so the dri
hid_cancel_delayed_stuff calls cancel_work_sync for reset_work.
So the reset_work routine tries to cancel itself synchronously while it
is running. usb_queue_reset_device was carefully written to avoid such
deadlocks.
> d. shall we "useusb_lock_device_for_reset(hid_to_usb_dev(hi
on't remember the entire call chain. It was pretty long.
hid_destroy_device calls hid_remove_device, which calls device_del,
which calls lots of other things. If you really want to see all the
details, put a dump_stack() call in usbhid_close and examine what it
prints in the kernel log when you unplug an HID device.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 25 Aug 2014, vichy wrote:
> hi Oliver:
>
> 2014-08-25 18:21 GMT+08:00 Oliver Neukum :
> > On Fri, 2014-08-22 at 14:23 -0400, Alan Stern wrote:
> >> On Sat, 23 Aug 2014, vichy wrote:
> >>
> >> > from your patch, I have some questions:
> &
> usbhid_disconnect, right?
If the pre_reset and post_reset routines both return 0,
usb_unbind_and_rebind_marked_interfaces will _not_ call
usbhid_disconnect. Otherwise it will.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
tf->needs_remote_wakeup = 0;
+ usb_kill_urb(usbhid->urbin);
Have you tried this?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 13 Nov 2014, Benson Leung wrote:
> On Thu, Nov 13, 2014 at 12:41 PM, Alan Stern
> wrote:
> > usbhid_stop probably doesn't need it. And it should be possible to fix
> > usbhid_close more easily just by interchanging the two lines:
> >
> > -
On Thu, 13 Nov 2014, Benson Leung wrote:
> On Thu, Nov 13, 2014 at 1:18 PM, Alan Stern wrote:
> > If you interchange the two lines then the flag _will_ be cleared before
> > usb_kill_urb() and autosuspend_check() can run. This means your patch
> > description is bogus.
&
On Thu, 13 Nov 2014, Benson Leung wrote:
> Hi Alan,
>
> On Thu, Nov 13, 2014 at 2:11 PM, Alan Stern wrote:
> > Wait a minute -- in your previous email you said this approach didn't
> > work. So does it work or doesn't it?
>
> Sorry for the confusion. Th
e_idle(&usbhid->intf->dev);
in usbhid_close() just after needs_remote_wakeup is set to 0? You can
do the same thing in usbhid_stop() if you want.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 22 Nov 2014, Alan Stern wrote:
> There is no USB wrapper for pm_runtime_idle calls, but one could be
> added. Still, in the meantime can you check to see what happens if you
> add
>
> pm_runtime_idle(&usbhid->intf->dev);
>
> in usbhid_close() just a
On Mon, 24 Nov 2014, Benson Leung wrote:
> Hi Alan,
>
>
> On Sat, Nov 22, 2014 at 7:55 AM, Alan Stern wrote:
> > There is no USB wrapper for pm_runtime_idle calls, but one could be
> > added. Still, in the meantime can you check to see wha
/* error */
> hid_warn(urb->dev, "ctrl urb status %d received\n", status);
In general, there isn't much you can do about a control stall. It
means the device did not understand or does not support the request it
received. You can't force the device to respond to
ameter to wait for userspace...
>
> > > There must be better
> > > solution
> >
> > I am not sure how it could look like.
>
> Rafael, do you have any idea how this is supposed to work?
>
> Original patch is at https://lkml.org/lkm
it well with the problem you want to solve, because you want
to turn off devices even when they _are_ still in use.
A separate sysfs interface might work out better.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the days before in-kernel mode
switching for displays was common, when user programs like the X server
would drive displays directly, without using a kernel driver.)
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
since
the circumstances would be unusual (userspace is still running,
->prepare() was not called beforehand, ->suspend_irq() won't be called
afterward), subsystems and drivers may very well react inappropriately.
Alan Stern
--
To unsubscribe from this list: send the line "un
suspend prevent it from
showing up on a list of available video devices? I doubt it. More
likely, the video driver would have to unregister the class device
while remaining bound to the physical device. Probably other drivers
would have to do the same sort of thing. (I don't know whe
ome aware that the camera wasn't available.
Would it sometimes be okay to unregister the class device and
invalidate the old handles, forcing programs to open new handles when
the lid is opened? This would reduce the number of changes user
programs would need.
Alan Stern
--
To unsubscribe fro
On Fri, 18 Jul 2014, Patrik Fimml wrote:
> On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> > device from doing anything, which isn't what you want. You want t
ld be regarded
> > as a wakeup source.
>
> I'd say no.
This raises an interesting question. Suppose the system gets suspended
while the lid is closed. At that point, shouldn't wakeup devices be
enabled, even if they were already inhibited?
Alan Stern
--
To unsubscribe fro
is closed, you should
never enable it for wakeup. After all, one of the first things that
people often do after suspending their laptop is close the lid.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
o do this. It shouldn't be hard; we
already have a flag indicating that an interface needs to be unbound at
reprobed at resume time. You can update the kerneldoc in addition; as
you noticed, it currently does not describe the actual code completely
accurately.
Alan Stern
--
To uns
ystem suspend failure to recover device.
I don't understand what this is supposed to mean. How about this
instead? "so do NOT try to continue using the device if suspend fails
in this case. Instead, let the resume or reset-resume routine recover
from the failure."
Alan Ster
ng the device if suspend fails in this case.
> + * Instead, let the resume or reset-resume routine recover from
> + * the failure.
> * @resume: Called when the device is being resumed by the system.
> * @reset_resume: Called when the suspended device has been reset instead
> *
_interfaces(udev);
}
The pm_runtime_set_active() call tells the PM core that the device is
RPM_ACTIVE.
> 2. At USB layer:
> It can do auto resume and auto suspend USB device
> after system resume to keep the usb device runtime pm status correct.
The runtime PM sta
fore the system suspend, we can
> see the ../power/control is still "auto".
This happens automatically, when the PM core calls pm_runtime_put()
from device_complete() in drivers/base/power/main.c. This has changed
since 3.5 -- in fact, that's probably the explanation for your proble
. MOUSE_SYNAPTICS_I2C) already
> handle this in a similar way.
That seems reasonable.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 11 Jul 2013, Arnd Bergmann wrote:
> On Wednesday 10 July 2013, Alan Stern wrote:
> > This isn't right. There are USB host controllers that use PIO, not
> > DMA. The HAS_DMA dependency should go with the controller driver, not
> > the USB core.
> >
>
On Thu, 11 Jul 2013, Geert Uytterhoeven wrote:
> On Thu, Jul 11, 2013 at 3:01 AM, Alan Stern wrote:
> > On Thu, 11 Jul 2013, Arnd Bergmann wrote:
> >
> >> On Wednesday 10 July 2013, Alan Stern wrote:
> >> > This isn't right. There are USB host contr
transfer).
I don't know what happens with USB-3 devices when the sequence numbers
get out of alignment.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
n off-list report, so can't really provide a
> > pointer to ML archives).
>
> Ah, ok. I wasn't aware of that. I'll assume then that the necessary
> people have the complete picture.
It might help to get a usbmon trace and dmesg log from Linus, if he
still has this pro
On Sun, 18 Aug 2013, Geert Uytterhoeven wrote:
> On Thu, Jul 11, 2013 at 1:12 AM, Arnd Bergmann wrote:
> > On Wednesday 10 July 2013, Alan Stern wrote:
> >> This isn't right. There are USB host controllers that use PIO, not
> >> DMA. The HAS_DMA dependency shou
w
parameters applied to an endpoint in several altsettings, it will have
to change each altsetting separately.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
o, then usb_change_ep_bandwidth() as a quirk, if bInterval
> or wMaxPacketSize were improperly filled.
>
> Right?
Or if the values are correct, but the driver wants to use something
different for its own reasons (for example, to get lower latency or
because it knows that it will never use pac
usting the streaming
> video resolution selected, right?
We haven't decided on the final API yet. However, note that
usb_alloc_urb() doesn't depend on the packet size. It requires you to
specify only the number of packets, not their sizes. Therefore it
doesn't matter whether you call us
iver unbinds, correct?
Absolutely. When the next driver binds, it should get the default
values (i.e., the ones stored in the descriptors). This would be
analogous to the way we currently set each interface back to altsetting
0 when a driver unbinds.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2 Oct 2013, Alan Stern wrote:
> > Ok, so it sounds like we want to keep the changes the endpoints across
> > alt setting changes.
>
> No, just the opposite. That was the point I was trying to make. Any
> changes to ep5 in altsetting 0 (for example) will
On Sat, 18 Aug 2012, Bruno Prémont wrote:
> Hi Jiri,
>
> [CCing Alan Stern]
>
> On Thu, 16 August 2012 Jiri Kosina wrote:
> > On Thu, 16 Aug 2012, Bruno Prémont wrote:
> >
> > > > I don't really understand this explanation. Once usb_kill_urb()
port() should check the HID_DISCONNECTED flag.
> I will attempt to see if it makes a difference to shortcut my
> usbhid_submit_report() calls from the point on I have called hid_hw_close()...
I don't know bout hid_hw_close(). Certainly no more reports should be
submitted following usb
usbhid->urbout->transfer_buffer_length);
> ^^^_ this is exploding
Right. Like I said, usbhid->outbuf is freed in hid_free_buffers(),
which is called from usbhid_stop().
Forget about usbhid_close(). The race is between hid_sub
o, in which case data does get sent
and the buffer must be kmalloc'ed. If the 0 is correct then the buffer
should be NULL, not "\x0A\x01A" (and what's the purpose of the leading
'0' in the second byte?).
In addition, although the bRequestType specifies
but
"echo w >/proc/sysrq-trigger" from a network login should). Then send
the dmesg output
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 4 Oct 2012, Sébastien Dinot wrote:
> Hi,
>
> Alan Stern a écrit :
> > Please build a kernel with CONFIG_USB_DEBUG enabled.
>
> Done (3.6.0+ kernel)
>
> > When a hang occurs, get a list of hang tasks (Alt-SysRq-w probably
> > won't work, but &qu
On Thu, 4 Oct 2012, Sébastien Dinot wrote:
> Alan Stern a écrit :
> > The log file shows lots and lots of low-level communication errors.
> > They could be caused by bad cabling or by bad USB hardware in your
> > computer. It's unlikely that they were caused by the mous
7;s okay to do the get/put
cycle after setting needs_remote_wakeup to 0.
By the way, how does the HID core handle the case where the device file
is closed long after the device has disconnected?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-inp
akes up suspended devices. So, I tried using
> usb_autopm_get_interface_no_resume(). To my considerable
> surprise that didn't work. I cannot understand why.
In what way did it not work?
> So what is to be done?
Start with a little debugging. When you do the put, what happens
inside autosuspend_check()?
A
o this thoroughly, you
have to iterate up the dev->parent chain, making sure at each step that
the ->removable value is USB_DEVICE_FIXED.
Also, are you really certain this is safe? Aren't there a number of
built-in keyboards that will work badly if you allow them to
autosuspend?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 26 Jun 2015, Alan Stern wrote:
> On Fri, 26 Jun 2015, Tom Gundersen wrote:
>
> > This policy used to be unconditionally applied by udev, but there
> > is no reason to make userspace be involved in this and in the future
> > udev will not be doing it by defau
s known to work okay with
autosuspend. Does it really turn on autosuspend for _every_ USB HID
device that is marked as removable?
(Come to think of it, given the bug in the hub driver, no device
attached directly to the root hub will _ever_ be marked as removable
AFAICS. So maybe that bug is mas
On Sat, 27 Jun 2015, Greg Kroah-Hartman wrote:
> On Fri, Jun 26, 2015 at 09:20:19PM -0400, Alan Stern wrote:
> > My Apple keyboard isn't here at the moment, and I don't remember
> > exactly what its hub descriptor contains. In theory, it _should_ mark
> > the p
g. Instead it would mean the same as the "auto" mode,
except that remote wakeup should be disabled during runtime suspend.
We never got around to implementing this, however.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of
e that the device would actually be able to go
> into runtime suspend when requested.
Exactly. What we discussed at LinuxCon wasn't forcing things into
runtime suspend; it was disabling remote wakeup during runtime suspend.
And even though the topic was quite different from Irina's
On Wed, 9 Sep 2015, Oliver Neukum wrote:
> On Tue, 2015-09-08 at 10:44 -0400, Alan Stern wrote:
> > It would not put the device into runtime suspend immediately, like you
> > are proposing. Instead it would mean the same as the "auto" mode,
> > except that remote w
ose the touchscreen device when the screen
is turned off. Or am I missing something?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 8 Sep 2015, Rafael J. Wysocki wrote:
> Hi,
>
> On Tue, Sep 8, 2015 at 5:00 PM, Alan Stern wrote:
> > On Tue, 8 Sep 2015, Rafael J. Wysocki wrote:
> >
> >> > > [1] http://marc.info/?l=linux-input&m=140564626306396&w=2
> >> >
>
rspace issue, rather than a kernel problem? The X
server does have some notion of power management and power savings; why
not extend that notion to include touchscreens?
> ..and it would be nice to have enough hardware abstraction in the
> kernel so that X can be used on phones...
What -- not
On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
> On Mon, Sep 21, 2015 at 10:38:46AM -0400, Alan Stern wrote:
> > On Mon, 21 Sep 2015, Pavel Machek wrote:
> >
> > > > > In fact, then, what you need seems to be the feature discussed by Alan
> > > > > and
into
runtime suspend?
Qustions like these make me think that this mechanism is best suited
for a kind of device that doesn't handle I/O requests. In other words,
something that just reports events as they occur -- which is another
way of describing an input device!
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ot very suitable
> for such mechanism.
Should the mechanism really be per-device? Or would it be more useful
to have a single "inhibit" setting that affected all the relevant
devices at once?
The runtime-PM "usage" value for these devices is a little tricky to
calculate.
t from
the existing runtime-PM callbacks? And when this new callback is
invoked, drivers should cancel existing input requests (these devices
are input-only) and go to low power?
This would create a parallel runtime-PM mechanism which is independent
of the existing one. Is that really a good idea?
vents will help prevent
unwanted wakeups (or unwanted failures to go to sleep).
But Dmitry made a stronger claim: Inhibiting an input device should
allow the device to go to low power. I would like to know how we can
implement this cleanly. The most straightforward approach is to use
runtime PM
On Wed, 23 Sep 2015, Oliver Neukum wrote:
> On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> > On Tue, 22 Sep 2015, Oliver Neukum wrote:
> >
> > > Cancel, yes, going to low power is a consequence which needn't bother
> > > the power subsystem.
>
pended devices without that are not configured to do remote wakeup
> cannot really signal anything in the majority of cases.
That works only for drivers that use autosuspend to go to low power in
between events. It doesn't work for drivers that remain at full power
as long as the device file
On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote:
> > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> >
> > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS
> > > f
it" callback for cases where the
driver doesn't want to go into runtime suspend but does want to turn
off all I/O. Should this callback be triggered when the user writes
"off" to power/wakeup, or when the user writes "inhibit" to
power/control, or should there be a se
On Sun, 27 Sep 2015, Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 11:20:50 AM Alan Stern wrote:
> > On Sat, 26 Sep 2015, Rafael J. Wysocki wrote:
> >
> > > > > So something like:
> > > > >
> > > > >
ower/control.
Another question is: Do we want to make it easy for drivers to support
inhibit while still incrementing their PM usage counter every time the
device file is opened? If we do then inhibit must be considered
separate from runtime suspend, because a device _can't_ go directly
into r
On Mon, 28 Sep 2015, Rafael J. Wysocki wrote:
> Hi Alan,
>
> On Mon, Sep 28, 2015 at 4:29 PM, Alan Stern wrote:
> > On Mon, 28 Sep 2015, Rafael J. Wysocki wrote:
> >
> >> > This suggests we forget about power/wakeup == "off" and introduce an
> >
w-to-probe device
> might wedge the process like that.
USB is a little similar. Probing can be slow, but it is carried out in
a workqueue thread. Since the workqueue is marked as FREEZABLE, it
doesn't run at all during any stage of system sleep, so the problem
can't arise.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
can do everything it needs using only
endpoint 0. Driver shouldn't assume anything about the endpoints in
the interfaces they problem.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nt 0 exists; it always does.
But they do have to check any other endpoint they use.
> btw, indeed, this is not the only driver with this problem, I've met 2 more.
In fact, there's no way to check whether endpoint 0 exists. Where
would you look to find out? There isn'
to check whether endpoint 0 exists. Where
> > would you look to find out? There isn't any endpoint descriptor for it.
>
> I believe, there is a configuration descriptor for that, probably, I'm wrong:
>
> if (intf->altsetting[0].desc.bNumEndpoints < 1) { ...
That value is the number of endpoints _other_ than endpoint 0. This is
documented in the USB-2.0 specification, Table 9-12.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 30 Nov 2015, Dmitry Torokhov wrote:
> How about we do something like below?
It looks okay to me. If you want to propose it on the linux-usb
mailing list, you can add:
Acked-by: Alan Stern
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-input
aiptek's probe routine. It should check that
> > intf->altsetting[0].desc.bNumEndpoints > 0 before trying to accessing
> > the endpoint array.
>
> Thank you, yes, the patch proposed does something quite alike.
You're welcome. Glad I could help.
Alan Stern
75 matches
Mail list logo
