linux-kernel - Re: [PATCH] PM: Hide CONFIG

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: <20110208121254.GE29850@opensource.wolfsonmicro.com>
Date:	Tue, 8 Feb 2011 12:12:55 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Len Brown <len.brown@...el.com>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-embedded@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] PM: Hide CONFIG_PM from users

On Mon, Feb 07, 2011 at 10:15:59PM +0100, Rafael J. Wysocki wrote:

> I really think we should do things that makes sense rather that worry about
> who's going to like or dislike it (except for Linus maybe, but he tends to like
> things that make sense anyway).  At this point I think the change I suggested
> makes sense, because it (a) simplifies things and (b) follows the quite common
> practice which is to make PM callbacks depend on CONFIG_PM.

So, part of the issue here is that it's not clear if having the ifdefs
in the drivers is really something that makes sense.  It's not at all
clear that anyone is actually making active use of them on real systems
rather than just doing build coverage testing, it really feels like the
ifdefs that people are currently using are just being cargo culted
around.

The reason it's come up for me is that dev_pm_ops changes things a bit
as you've got to decide how to handle the struct itself and there's no
clear decision on what the best way forward for that is (is it OK to
leave the struct if it's empty?) so you end up with the approach you
need to take varying between maintainers which is annoying.

> I'd appreciate it if people could review/test it and drop their comments.

Looks good to me:

Reviewed/Tested-by: Mark Brown <broonie@...nsource.wolfsonmicro.com>
--
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/