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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 26 Jan 2007 23:15:21 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	akpm@...l.org
Subject: Re: [PATCH] Fix /sys/device/.../power/state regression

On Fri, Jan 26, 2007 at 01:56:41PM -0800, David Brownell wrote:

> I thought the resolution was that fixing a few of those drivers
> should solve the problem Matthew needed resolved, and that in
> the meanwhile "rmmod drivername" should suffice.  There also seemed
> to be agreement that power management for wireless devices needed
> more work; there might need to be a state between "down/off" and
> "configured and able to talk IP".

It's certainly the case that fixing those drivers would result in a 
better long-term situation - however, nobody currently seems to have any 
interest in doing so, and I've only got access to a subset of the 
hardware and approximately none of the documentation. It's likely that 
I'll end up spending time on that, but right now I'm afraid that other 
things are taking a higher priority.

I'm not sure what you mean by using rmmod instead. Most drivers don't 
explicitly set the power state when unbinding, and I can't see anywhere 
in the generic PCI code that will do it.

As I've said before, I think it's unreasonable to cripple interfaces for 
(mostly) aesthetic reasons without ensuring that equivalent 
functionality already exists. This patch restores useful functionality 
without breaking the extra sanity checks that you've added. I appreciate 
that it's not an interface that you want to support in the long term 
(well, even the short term...), and that suggesting its removal provides 
a useful incentive to fix things properly in the long term. But it would 
be nice if we didn't make it impossible to do this until the right thing 
is implemented.

-- 
Matthew Garrett | mjg59@...f.ucam.org
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ