On Thu, Jul 19, 2012 at 10:42:23AM -0400, Alan Stern wrote:
The same is true for external ports if they are marked as
non-removable. For example, consider a compound keyboard/mouse device
with a built-in hub. The connections from the keyboard and the mouse
to the hub are internal and not
On Mon, Jul 23, 2012 at 08:06:22AM -0700, Greg KH wrote:
On Mon, Jul 23, 2012 at 09:23:53AM +0800, Lan Tianyu wrote:
On 2012年07月21日 01:08, Sarah Sharp wrote:
On Thu, Jul 19, 2012 at 11:42:57AM +0200, Oliver Neukum wrote:
On Thursday 19 July 2012 15:42:37 Lan Tianyu wrote:
On 2012年07月19日
On Monday 23 July 2012 11:08:47 Sarah Sharp wrote:
By disabling this, you are not creating a real-world situation. Those
disks need to be polled for a reason, right?
Tianyu is trying to test the port power off mechanism with USB 3.0
devices, to make sure the patches work on USB 3.0.
On Mon, 23 Jul 2012, Oliver Neukum wrote:
On Monday 23 July 2012 11:08:47 Sarah Sharp wrote:
By disabling this, you are not creating a real-world situation. Those
disks need to be polled for a reason, right?
Tianyu is trying to test the port power off mechanism with USB 3.0
On Monday 23 July 2012 15:55:51 Alan Stern wrote:
The runtime PM framework already provides such an API, although the USB
layer doesn't have a wrapper for it.
That should be rectified.
I suggest that rather than have usb-storage mess around with details
like no medium or offline, the SCSI
Sorry for later reply. :)
On 2012年07月21日 01:08, Sarah Sharp wrote:
On Thu, Jul 19, 2012 at 11:42:57AM +0200, Oliver Neukum wrote:
On Thursday 19 July 2012 15:42:37 Lan Tianyu wrote:
On 2012年07月19日 14:37, Oliver Neukum wrote:
But this leaves me with a question. Has anybody ever measured the
On Fri, 20 Jul 2012, Sarah Sharp wrote:
Well, then the device violates the standard for power consumption.
Not necessarily.
Tianyu, are you measuring the whole system power consumption or just the
power drawn by the device? How are you measuring power consumption?
Also, are you sure
On Wednesday 18 July 2012 15:07:14 Sarah Sharp wrote:
On Wed, Jul 18, 2012 at 09:03:59PM +0200, Oliver Neukum wrote:
No, now that I think about it an attribute for the drivers is necessary.
Like drivers have supports_autosuspend they also should have
supports_power_off. In addition it is
On 2012年07月19日 14:37, Oliver Neukum wrote:
On Wednesday 18 July 2012 15:07:14 Sarah Sharp wrote:
On Wed, Jul 18, 2012 at 09:03:59PM +0200, Oliver Neukum wrote:
No, now that I think about it an attribute for the drivers is necessary.
Like drivers have supports_autosuspend they also should
On 2012年07月19日 14:37, Oliver Neukum wrote:
On Wednesday 18 July 2012 15:07:14 Sarah Sharp wrote:
On Wed, Jul 18, 2012 at 09:03:59PM +0200, Oliver Neukum wrote:
No, now that I think about it an attribute for the drivers is necessary.
Like drivers have supports_autosuspend they also should
On Thursday 19 July 2012 15:42:37 Lan Tianyu wrote:
On 2012年07月19日 14:37, Oliver Neukum wrote:
But this leaves me with a question. Has anybody ever measured the additional
power savings compared to a suspended state for devices? Or are you doing
this only as a prelude to become able to
On Thu, Jul 19, 2012 at 5:33 PM, Oliver Neukum oneu...@suse.de wrote:
On Thursday 19 July 2012 16:21:38 Lan Tianyu wrote:
On 2012年07月19日 14:37, Oliver Neukum wrote:
Unloading the driver is a user space issue.
But you are right there is a missing case
hi all:
I have a question About
Resend because sent to maillist failed.
2012/7/19 Oliver Neukum oneu...@suse.de
On Thursday 19 July 2012 16:21:38 Lan Tianyu wrote:
On 2012年07月19日 14:37, Oliver Neukum wrote:
Unloading the driver is a user space issue.
But you are right there is a missing case
hi all:
I have a
On Wed, 18 Jul 2012, Oliver Neukum wrote:
On Wednesday 18 July 2012 12:40:38 Alan Stern wrote:
Oliver, you seem to be arguing both sides of this discussion. You
But there are more than two sides in this discussion.
point out the the power-off operation is too dangerous in general
On Thursday 19 July 2012 18:58:38 Ming Lei wrote:
On Thu, Jul 19, 2012 at 5:33 PM, Oliver Neukum oneu...@suse.de wrote:
Yes. That's how reset_resume() works.
If reset_resume flag is set, usbcore will try to reset the device first
during resume, and no disconnect will be involved if reset
On Thursday 19 July 2012 10:42:23 Alan Stern wrote:
1) remote wakeup is requested
2) user space has blocked it via the new sysfs attribute
3) USB_QUIRK_RESET_MORPHS is set
The same is true for external ports if they are marked as
non-removable. For example, consider a compound
On Fri, Jul 20, 2012 at 3:37 AM, Oliver Neukum oli...@neukum.org wrote:
We cannot do this as the device state is specific to a driver. And the driver
must have an interface to be bound to. That is why we use reset_resume()
instead of resume(). resume() means that the device must be brought up
Oh. I recheck find these device will use ordinary resume rather than
reset_resume().
I remeber you said userspace should set USB_QUIRK_RESET_MORPHS for those
kind devices. After reset, they will morph. So reset_resume doesn't
work for them.
Ordinary resume almost just calls
On Tuesday 17 July 2012 14:52:51 Sarah Sharp wrote:
2. If an internal USB port is suspended with remote wakeup disabled,
power off the port. Add code to the USB core to ignore the device
disconnect in this special case, so the driver thinks the device is
still suspended. Issue a reset-resume
On 2012/7/18 12:43, Oliver Neukum wrote:
On Tuesday 17 July 2012 14:52:51 Sarah Sharp wrote:
2. If an internal USB port is suspended with remote wakeup disabled,
power off the port. Add code to the USB core to ignore the device
disconnect in this special case, so the driver thinks the device
On Wed, 18 Jul 2012, Oliver Neukum wrote:
I have a question that reset-resume still can not resolve firmware
problem? I think this depend on driver. right?
Right, but this is not really useful information. We can infer from
a lack of support for reset_resume() that we must not cut
On 2012/7/18 22:19, Alan Stern wrote:
An alternative to her suggestion would be to disconnect the device when
the port goes off. When the port is powered back on, the device will
be rediscovered and probed again.
hi alan:
Reprobe may cause the devnum change. Userspace will treat it a
On Wed, 18 Jul 2012, Oliver Neukum wrote:
On Wednesday 18 July 2012 10:54:20 Alan Stern wrote:
On Wed, 18 Jul 2012, Lan Tianyu wrote:
On 2012/7/18 22:19, Alan Stern wrote:
An alternative to her suggestion would be to disconnect the device when
the port goes off. When the port is
On Wednesday 18 July 2012 11:42:50 Alan Stern wrote:
On Wed, 18 Jul 2012, Oliver Neukum wrote:
On Wednesday 18 July 2012 10:54:20 Alan Stern wrote:
On Wed, 18 Jul 2012, Lan Tianyu wrote:
On 2012/7/18 22:19, Alan Stern wrote:
An alternative to her suggestion would be to
Alan Stern st...@rowland.harvard.edu writes:
Any attempt to use a suspended device will return an error, whether the
port is powered off or not. The driver has to resume the device before
using it, and Sarah is proposing that this should cause the port to
power back on.
Assuming that
On Wed, 18 Jul 2012, Oliver Neukum wrote:
On Wednesday 18 July 2012 11:42:50 Alan Stern wrote:
On Wed, 18 Jul 2012, Oliver Neukum wrote:
On Wednesday 18 July 2012 10:54:20 Alan Stern wrote:
On Wed, 18 Jul 2012, Lan Tianyu wrote:
On 2012/7/18 22:19, Alan Stern wrote:
On Wed, 18 Jul 2012, Bjørn Mork wrote:
Alan Stern st...@rowland.harvard.edu writes:
Any attempt to use a suspended device will return an error, whether the
port is powered off or not. The driver has to resume the device before
using it, and Sarah is proposing that this should cause the
On Wed, Jul 18, 2012 at 12:40:38PM -0400, Alan Stern wrote:
On Wed, 18 Jul 2012, Oliver Neukum wrote:
On Wednesday 18 July 2012 11:42:50 Alan Stern wrote:
On Wed, 18 Jul 2012, Oliver Neukum wrote:
On Wednesday 18 July 2012 10:54:20 Alan Stern wrote:
On Wed, 18 Jul 2012, Lan
On Wednesday 18 July 2012 12:40:38 Alan Stern wrote:
Oliver, you seem to be arguing both sides of this discussion. You
But there are more than two sides in this discussion.
point out the the power-off operation is too dangerous in general for
the kernel to do it, and now you say that it's
On 2012/7/17 21:48, Oliver Neukum wrote:
On Tuesday 17 July 2012 21:35:00 Lan Tianyu wrote:
On 2012/7/16 22:13, Alan Stern wrote:
On Mon, 16 Jul 2012, Lan Tianyu wrote:
Currently, power/wakeup sysfs file can't control remote wakeup in the runtime
suspend. It only depends on
On Tuesday 17 July 2012 22:28:32 Lan Tianyu wrote:
On 2012/7/17 21:48, Oliver Neukum wrote:
But the driver will not work if you don't use remote wakeup when it needs
it.
Under those circumstances you better unbind the driver.
hi Oliver:
Thanks for reply. Why unbind driver? I am
On Tuesday 17 July 2012 22:49:26 Lan Tianyu wrote:
On 2012/7/17 22:26, Alan Stern wrote:
What sort of driver are you talking about? An HID driver? Serial
driver?
I can find hid, bcm, serial, mouse, screen and some net device drivers
does such thing. set needs_remote_wakeup to 1 in
On Tue, 17 Jul 2012, Lan Tianyu wrote:
Why is that? What happens if you power-off a port where the device has
remove wakeup enabled?
I will not power off a port where the device has remote wakeup enabled.
Only when disabled, the port will power off.
What about the case where the device
On Tue, Jul 17, 2012 at 10:49:26PM +0800, Lan Tianyu wrote:
On 2012/7/17 22:26, Alan Stern wrote:
On Tue, 17 Jul 2012, Oliver Neukum wrote:
Yeah. Lost some background introduction. I recently try to realize usb
port power off mechanism for ports with device. So design, the port with
device
On Tue, 17 Jul 2012, Sarah Sharp wrote:
On Tue, Jul 17, 2012 at 10:49:26PM +0800, Lan Tianyu wrote:
On 2012/7/17 22:26, Alan Stern wrote:
On Tue, 17 Jul 2012, Oliver Neukum wrote:
Yeah. Lost some background introduction. I recently try to realize usb
port power off mechanism for ports
Alan Stern st...@rowland.harvard.edu writes:
Last time I checked, the
kernel did not try to prevent users from unplugging their USB devices.
:-)
That would be a nice feature for usb attached storage devices though :-)
Bjørn
--
To unsubscribe from this list: send the line unsubscribe
On Tue, Jul 17, 2012 at 03:00:08PM -0400, Alan Stern wrote:
On Tue, 17 Jul 2012, Sarah Sharp wrote:
On Tue, Jul 17, 2012 at 10:49:26PM +0800, Lan Tianyu wrote:
On 2012/7/17 22:26, Alan Stern wrote:
On Tue, 17 Jul 2012, Oliver Neukum wrote:
Yeah. Lost some background introduction.
2. If an internal USB port is suspended with remote wakeup disabled,
power off the port. Add code to the USB core to ignore the device
disconnect in this special case, so the driver thinks the device is
still suspended. Issue a reset-resume when the driver wants to resume
the device.
Currently, power/wakeup sysfs file can't control remote wakeup in the runtime
suspend. It only depends on usb_interface-needs_remote_wakeup to determine
whether enable remote wakeup or not when runtime suspending. Usr space has no
choice. This patch is to enable power/wakeup to control remote
On Monday 16 July 2012 15:43:15 Lan Tianyu wrote:
Currently, power/wakeup sysfs file can't control remote wakeup in the
runtime
suspend. It only depends on usb_interface-needs_remote_wakeup to determine
whether enable remote wakeup or not when runtime suspending. Usr space has no
choice.
On Mon, 16 Jul 2012, Lan Tianyu wrote:
Currently, power/wakeup sysfs file can't control remote wakeup in the
runtime
suspend. It only depends on usb_interface-needs_remote_wakeup to determine
whether enable remote wakeup or not when runtime suspending. Usr space has no
choice. This patch is
41 matches
Mail list logo
