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]
Message-Id: <200702120029.23657.rjw@sisk.pl>
Date:	Mon, 12 Feb 2007 00:29:22 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	nigel@...el.suspend2.net
Cc:	Robert Hancock <hancockr@...w.ca>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@....cz>
Subject: Re: NAK new drivers without proper power management?

On Sunday, 11 February 2007 23:40, Nigel Cunningham wrote:
> Hi.
> 
> On Sun, 2007-02-11 at 01:44 +0100, Rafael J. Wysocki wrote:
> > > Well, it's probably more acceptable than silently doing nothing and the 
> > > device failing or locking up the machine on resume, but I couldn't agree 
> > > more that it's not what we want to be encouraging. Perfect may be the 
> > > enemy of the good, but "works except no power management" is hardly what 
> > > I would call good these days, more like pretty sloppy..
> > 
> > I think there are situations in which it can be justified, like:
> > - The driver is not entirely finished, but we want to merge it early, because
> > of many potential users,
> > - The driver has only a few users who aren't interested in the suspend/resume
> > functionality,
> 
> How do you determine that? How many users have to want suspend/resume
> functionality before you say "Ok. It has to be done now"?

That depends on what the driver author tells us.  If he says there's only one
such device in the world and it needs a Linux drivers, but the system in
question will never be suspended, that will be fine, I think.  There are such
cases already and I see no reason why there won't be any more in the future.

> > - The device is undocumented and we don't know how to make it handle the
> > suspend/resume (we may learn that in the future or not).
> 
> If we know how to initialise/cleanup, we know a good portion of what is
> needed for suspend/resume. Sure, for some video chipsets, you need more
> (you need to know how to reprogram the whole thing after S3), but
> they're the exception. Yes, there are other cases. But on the whole,
> we're not talking about esoteric knowledge.

No, in general this is not _that_ simple.  Please browse the archives of
bcm43xx-dev, for example.

While I agree that the support for suspend and resume _is_ generally important,
I also admit that there are situations in which it doesn't matter and there are
many people who won't care a whit for it.

Greetings,
Rafael 
-
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