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]
Message-Id: <200702122243.11801.rjw@sisk.pl>
Date:	Mon, 12 Feb 2007 22:43:10 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	nigel@...el.suspend2.net
Cc:	Pavel Machek <pavel@....cz>, Manu Abraham <abraham.manu@...il.com>,
	Willy Tarreau <w@....eu>,
	Arjan van de Ven <arjan@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>, tilman@...p.cc,
	Robert Hancock <hancockr@...w.ca>
Subject: Re: NAK new drivers without proper power management?

On Monday, 12 February 2007 22:24, Nigel Cunningham wrote:
> Hi.
> 
> On Mon, 2007-02-12 at 22:01 +0100, Rafael J. Wysocki wrote:
> > On Monday, 12 February 2007 21:58, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > > If all you need to do is say 'I don't need to do anything' and we have a
> > > > > > shared function that does that, all we're talking about doing is adding
> > > > > > to your struct pci_device (or whatever)
> > > > > > 
> > > > > > .resume = generic_empty_resume;
> > > > > > 
> > > > > > To me at least, that doesn't look awkward, and says cleanly and clearly
> > > > > > that you've checked things over and decided you know what's required.
> > > > > 
> > > > > Actually, I'd like it to be
> > > > > 
> > > > > .resume = generic_empty_resume; /* Explain, why your driver needs no
> > > > > 				   resume */
> > > > 
> > > > Okay, but we can't define an empty .resume(), because, for example, the PCI's
> > > > generic suspend/resume won't be called.
> > > 
> > > PCI drivers should just do .resume = pci_generic_resume, explicitely.
> > 
> > Well, I generally agree, but I think the idea with the "pm_safe" flag has some
> > advantages.  For example, the drivers that do define .suspend() and .resume()
> > which don't work correctly could be flagged as not "pm_safe" until the problems
> > are fixed.
> 
> Oooh. Now I like that idea. Are you thinking of a document in
> Documentation/power that describes why pm_safe is off, or comments in
> the code itself?

I think the code should be commented in the first place.  Additionally, we can
create a file or a directory under Documentation/power for documenting more
complicated cases, if necessary.

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