linux-kernel - Re: NAK new drivers without proper power management?

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: <1171236594.4493.127.camel@nigel.suspend2.net>
Date:	Mon, 12 Feb 2007 10:29:54 +1100
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	Pavel Machek <pavel@....cz>
Cc:	Alan <alan@...rguk.ukuu.org.uk>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Arjan van de Ven <arjan@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: NAK new drivers without proper power management?

Hi.

On Mon, 2007-02-12 at 00:21 +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > define .suspend that will always return -ENOSYS (then people will know they
> > > > > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > > > > whether or not the device requires .suspend and .resume, define .suspend that
> > > > > will always return -ENOSYS."
> > > > 
> > > > Sounds ok to me. Where should this text go?
> > > > Documentation/SubmittingDrivers ?
> > > 
> > > And testing/submitting drivers, perhaps with additional text in that to
> > > make it clear we want suspend/resume support or good excuses
> > > 
> > > "Please verify your driver correctly handles suspend and resume. If it
> > > does not your patch submission is likely to be suspended and only resume
> > > when the driver correctly handles this feature"
> > 
> > Maybe make it explicit that testing should be done for both suspend to
> > ram and to disk, and with the following usage scenarios as
>  > applicable?
> 
> Well, for many people s2ram does not work even today... so requiring
> them to test it is slightly draconian.
> 
> > - built in;
> > - modular, loaded while suspending but not loaded prior to resume from
> > disk;
> 
> These two should be equivalent.

No. The differences are:

Built in: The initcalls will have run, but the driver may or may not
actually have been used, depending on whether it's used before we start
the resume. It should probably be tested with both having been used and
not having been used.
Modular, loaded prior to suspending but not prior to resuming: At resume
time, will still be in whatever config the bios puts it in. No Linux
driver code will have touched it.
Modular, loaded prior to suspending and resuming: Should be equivalent
to built in (module initcalls will have run), but may vary if there's
some difference in code/timing between being a module and built in.
(This shouldn't happen, but that's the point to testing).

> > - modular, loaded while suspending and loaded prior to resume from disk;
> 
> Ok.. but I'm not sure how many people will actually test it _that_
> thoroughly. "Try to test it" is good enough for a first version. When
> suspend is in better shape, we can ask for more.

I'd prefer to ask for what should be done from the start. Will we expect
people to go back and retest if we change the rules, or do we prefer
them to complain "You didn't adequately point out the testing I needed
to do, and I got all these complaints from my users!"

Regards,

Nigel

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