linux-kernel - Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

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] [day] [month] [year] [list]

Message-Id: <200611141456.52201.david-b@pacbell.net>
Date:	Tue, 14 Nov 2006 14:56:51 -0800
From:	David Brownell <david-b@...bell.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	arvidjaar@...l.ru, linux-usb-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

On Tuesday 14 November 2006 1:42 pm, Alan Stern wrote:
> On Tue, 14 Nov 2006, David Brownell wrote:
> 
> > On Monday 13 November 2006 9:15 am, Alan Stern wrote:
> > > On Mon, 13 Nov 2006, David Brownell wrote:
> > > 
> > > > It's a *driver model* API, which is also accessible from sysfs ... to support
> > > > per-device policies, for example the (a) workaround.  The mechanism exists
> > > > even on kernels that don't include sysfs ... although on such systems, there
> > > > is no way for users to do things like say "ignore the fact that this mouse
> > > > claims to issue wakeup events, its descriptors lie".
> > > 
> > > Yes, it is separate from sysfs -- but it is _tied_ to the sysfs API.
> > 
> > I can't agree.  If you deconfigure sysfs, it still works.
> > Since it's independent like that, there's no way it's "tied".
> 
> We could carry on this argument indefinitely.  Yes, the device_may_wakeup
> stuff does work without sysfs.  But it doesn't do anything significant; it
> amounts to no more than device_can_wakeup().  AFAIK there's no way to
> change the setting of the may_wakeup flag other than via sysfs.  That's
> what I meant by "tied".

So "tied" means "nobody has yet needed to create a different API for
that subset of the mechanism"?  Still can't agree.  Nothing's preventing
anyone from creating such an API, if they need to.


> > So "may" is correct, and "can" is insufficient.
> 
> Things work differently in uhci-hcd. 

They shouldn't.  That's the point of having this in the driver model:
so that all wakeup-capable devices can/will act the same in terms of
the basic capability and policy.

(Of course, there are ugly PPC/OF-only enumeration issues that keep us
from kicking in the wakeup mechanisms for PCI devices.  But that's a
separate issue, specific to PCI ... although it sucks hugely, since
so few developers have non-PCI wakeup-capable devices.)


> However even when it is added and may_wakeup is off, autostop will still 
> function.  It won't rely on interrupts or other wakeup events, though -- 
> instead the root-hub status polling mechanism will be used.

Well, as was said previously:  For UHCI it's not "just" a PM mechanism.

- Dave
-
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/