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-next>] [day] [month] [year] [list]
Message-Id: <201103280125.11750.rjw@sisk.pl>
Date:	Mon, 28 Mar 2011 01:25:11 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Greg KH <gregkh@...e.de>, Kay Sievers <kay.sievers@...e.de>,
	Linux PM mailing list <linux-pm@...ts.linux-foundation.org>,
	Russell King <linux@....linux.org.uk>,
	linux-omap@...r.kernel.org, Kevin Hilman <khilman@...com>,
	linux-arm-kernel@...ts.infradead.org,
	Ben Dooks <ben-linux@...ff.org>
Subject: [PATCH 0/7] ARM: Use syscore_ops for "core" power management

Hi,

There are multiple problems with sysdevs, or struct sys_device objects to
be precise, that are so annoying that some people have started to think
of removind them entirely from the kernel.  To me, personally, the most
obvious issue is the way sysdevs are used for defining suspend/resume
callbacks to be executed with one CPU on-line and interrupts disabled.
Apart from this, sysdevs do not follow general rules related to the
representation of things in /sys/devices/, so user space that uses
/sys/devices/ to retrieve information on device hierarchy layout and
device configuration, such as udev, cannot really handle them correctly.

Some subsystems need to carry out certain operations during suspend after
we've disabled non-boot CPUs and interrupts have been switched off on the
only on-line one.  Currently, the only way to achieve that is to define
sysdev suspend/resume callbacks, but this is cumbersome and inefficient.
Namely, to do that, one has to define a sysdev class providing the callbacks
and a sysdev actually using them, which is excessively complicated.  Moreover,
the sysdev suspend/resume callbacks take arguments that are not really used
by the majority of subsystems defining sysdev suspend/resume callbacks
(or even if they are used, they don't really need to be used, so they
are simply unnecessary).  Of course, if a sysdev is only defined to provide
suspend/resume (and maybe shutdown) callbacks, there's no real reason why
it should show up in sysfs.

For this reason, I thought it would be a good idea to provide a simpler
interface for subsystems to define "very late" suspend callbacks and
"very early" resume callbacks (and "very late" shutdown callbacks as well)
without the entire bloat related to sysdevs.  Such an interface has been
merged recently in the form of struct syscore_ops framework that can be used
to replace sysdevs in the "core" power management area.

The x86 architecture and subsystems it depends on have already been converted
to using the new framework instead of sysdevs for "core" power management and
the following series of patches does the analogous thing for the ARM
architecture.  I have done my best to build the kernel for every affected
platform, but unfortunately some of them don't build even without my changes,
so some minor issues might have slept through my fingers.  Hopefully, though,
there won't be too many of them.

[1/7] - Use syscore_ops for "core" PM in some common ARM code.
[2/7] - Use syscore_ops for "core" PM on OMAP.
[3/7] - Use syscore_ops for "core" PM on Integrator.
[4/7] - Use syscore_ops for "core" PM on SA1100.
[5/7] - Use syscore_ops for "core" PM on PXA-based platforms.
[6/7] - Use syscore_ops for "core" PM on Samsung platforms.
[7/7] - Mark ARM select CONFIG_ARCH_NO_SYSDEV_OPS.

Thanks,
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