On 2012/8/1 1:02, Alan Stern wrote:
On Tue, 31 Jul 2012, Oliver Neukum wrote:
On Monday 30 July 2012 17:03:27 Alan Stern wrote:
On Mon, 30 Jul 2012, Sarah Sharp wrote:
I'm not even sure that RESET_MORPHS is the right thing to look at here.
It's possible for a device to retain important settings across a reset
but lose them when power is removed.
True. So an additional quirk? QUIRK_FIRMWARE_VOLATILE?
To be consistent we should call it QUIRK_POWEROFF_MORPHS. But how is
this quirk going to get set? Static entries in the quirks table?
Dynamically by firmware loaders?
I think the quirk work in the both two ways. Static entries can set the
default config. User-space also can set it via a sysfs file dyanamically.
2. If the device is internal and suspended, power off the port if all
the following are true:
a) all interface drivers have supports_power_off set, or no
interface drivers are bound and usbfs has not claimed the
device.
b) remote wakeup is disabled
c) USB_QUIRK_RESET_MORPHS is not set
- If userspace wants a port to be powered off, and one of the interface
drivers doesn't set supports_power_off or the driver enables remote
wakeup, then userspace will need to unbind or unload the driver.
Like other people, I'm dubious about these conditions.
Can you propose other conditions?
I don't know. I can't think of anything more, but there's a nagging
feeling that if we use these then something will go wrong.
How about if we start with only the first policy rule: Ports that can
never have anything plugged in should be shut down automatically.
So we should add a variable for each port to record whether the port
has been ever attached with devices. When set sys file set to "auto"
these port should power off directly, right?
Initially, everything else can be left up to userspace. Then we can
experiment with adding other policies to the kernel.
Alan Stern
--
Best Regards
Tianyu Lan
linux kernel enabling team
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
