linux-kernel - Re: [linux-usb-devel] error to be returned while suspended

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Oct 2006 14:10:09 -0700
From:	David Brownell <david-b@...bell.net>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	linux-usb-devel@...ts.sourceforge.net,
	Alan Stern <stern@...land.harvard.edu>,
	linux-kernel@...r.kernel.org, Pavel Machek <pavel@....cz>
Subject: Re: [linux-usb-devel] error to be returned while suspended

On Friday 06 October 2006 12:04 am, Oliver Neukum wrote:
> Am Freitag, 6. Oktober 2006 04:47 schrieb David Brownell:
> > On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
> > 
> > > - the issues of manual & automatic suspend and remote wakeup are orthogonal
> > > - there should be a common API for all devices
> > 
> > AFAIK there is no demonstrated need for an API to suspend
> > individual devices.  ...
> 
> I doubt that a lot. 

You haven't demonstrated such a need either; so why doubt it?

> Eg. Again, if I close the lid I may want my USB 
> network cards be suspended 

If "close lid" means system suspend, then you _do_ want that
(by definition of system suspend).  If that doesn't trigger
system suspend, then it's up to you to decide whether or not
you "ifdown eth1" or not ... as with non-USB network adapters.

Likewise with autosuspending of network devices, which I'd
actually like to see happen.  Starting in 2.6.19-rc, the USB
drivers could be updated to do that, as I understand ... at
least for hardware that has sane remote wakeup capabilities.
No point in having host controllers doing nothing except
polling a USB network adapter, unless there's actually some
traffic directed to that host!

> or not and that decision might change several 
> times a day. It's a policy decision in many cases. And I'd not be happy
> with being required to down the interfaces to do so.

Lots of us would be even more unhappy to see USB network adapters
be made to follow different rules than non-USB ones.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/