* [RFC] Replacing sysdevs with platform devices
@ 2007-07-18 15:20 Rafael J. Wysocki
2007-07-19 9:23 ` Russell King
0 siblings, 1 reply; 3+ messages in thread
From: Rafael J. Wysocki @ 2007-07-18 15:20 UTC (permalink / raw)
To: Greg KH, pm list; +Cc: Russell King, Andi Kleen, Pavel Machek
Hi,
Some time ago we agreed that it would be a good idea to stop using device
drivers' .suspend() and .resume() callbacks for hibernation and to introduce
new hibernation-specific driver callbacks. I'm currently working on
implementing that and I'd like to avoid adding any hibernation-specific
callbacks to sysdev drivers. For this reason, I thought I first would try to
replace sysdevs used for late suspending and early resuming with platform
devices, where possible and straightforward, so I have reviewed the code and
found that:
(1) In many cases sysdevs are used only for the late suspending and early
resuming of platform-dependent stuff (such as , timers, local APICs etc.).
These instances can be readily replaced with platform devices and platform
drivers, so can you please tell me if patches to do that would be acceptable
and useful?
(2) In some cases sysdevs are used for late suspending, early resuming and late
shutdown of platform-dependent stuff (such as I/O APICs on x86* etc.). In
such cases, to replace sysdevs with platform devices we would need to
add a .shutdown_late() callback to 'struct platform_driver' and a piece of
infrastructure to execute these callbacks in device_shutdown(), right
before or after, or instead of sysdev_shutdown(). Can you please tell me
if that would be useful?
(3) In arch/x86_64/kernel/mce.c the sysdev is used for early resuming and
communications with user space, so I don't think it would be a good idea to
replace the sysdev with a platform device entirely. However, would it make
sense to add a platform device for the early resuming alone and leave the
sysdev for other purposes?
(4) In a few cases one sysdev is used for many different purposes, including
late suspend and early resume, and many different drivers bind to it. This
is done by the i386 MTRR code and by the ARM s3c24xx platforms.
Still, as far as the i386 MTRR code is concerned, it only is necessary to
apply the late suspend and early resume to the boot CPU, since we disable
the other CPUs before this code is called and we eanble them after it has
been called using the CPU hotplug. Thus, it seems that we only need one
platform device for handling the boot CPU's MTRR late suspend and early
resume.
Now, on the s3c24xx platforms one sysdev seems to be used for many
platform-related operations. In particular, two or more different sysdev
drivers having .suspend() and/or .resume() callbacks defined, related to
different parts of the platform, seem to bind to the same sysdev, which is
kind of ugly. It seems to be more correct to have a separate platform
device defined for each thing that requires to be suspended late or resumed
early and a dedicated platform driver handling these operations.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [RFC] Replacing sysdevs with platform devices
2007-07-18 15:20 [RFC] Replacing sysdevs with platform devices Rafael J. Wysocki
@ 2007-07-19 9:23 ` Russell King
2007-07-19 9:39 ` Rafael J. Wysocki
0 siblings, 1 reply; 3+ messages in thread
From: Russell King @ 2007-07-19 9:23 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Andi Kleen, Pavel Machek, pm list
On Wed, Jul 18, 2007 at 05:20:16PM +0200, Rafael J. Wysocki wrote:
> Now, on the s3c24xx platforms one sysdev seems to be used for many
> platform-related operations. In particular, two or more different sysdev
> drivers having .suspend() and/or .resume() callbacks defined, related to
> different parts of the platform, seem to bind to the same sysdev, which is
> kind of ugly. It seems to be more correct to have a separate platform
> device defined for each thing that requires to be suspended late or resumed
> early and a dedicated platform driver handling these operations.
A suggestion. The information's all there. All it takes is to look it
up.
ARM/S3C2410 ARM ARCHITECTURE
P: Ben Dooks
M: ben-linux@fluff.org
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
W: http://www.fluff.org/ben/linux/
S: Maintained
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] Replacing sysdevs with platform devices
2007-07-19 9:23 ` Russell King
@ 2007-07-19 9:39 ` Rafael J. Wysocki
0 siblings, 0 replies; 3+ messages in thread
From: Rafael J. Wysocki @ 2007-07-19 9:39 UTC (permalink / raw)
To: Russell King; +Cc: Andi Kleen, Pavel Machek, pm list
On Thursday, 19 July 2007 11:23, Russell King wrote:
> On Wed, Jul 18, 2007 at 05:20:16PM +0200, Rafael J. Wysocki wrote:
> > Now, on the s3c24xx platforms one sysdev seems to be used for many
> > platform-related operations. In particular, two or more different sysdev
> > drivers having .suspend() and/or .resume() callbacks defined, related to
> > different parts of the platform, seem to bind to the same sysdev, which is
> > kind of ugly. It seems to be more correct to have a separate platform
> > device defined for each thing that requires to be suspended late or resumed
> > early and a dedicated platform driver handling these operations.
>
> A suggestion. The information's all there. All it takes is to look it
> up.
>
> ARM/S3C2410 ARM ARCHITECTURE
> P: Ben Dooks
> M: ben-linux@fluff.org
> L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
> W: http://www.fluff.org/ben/linux/
> S: Maintained
OK, thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-07-19 9:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-18 15:20 [RFC] Replacing sysdevs with platform devices Rafael J. Wysocki
2007-07-19 9:23 ` Russell King
2007-07-19 9:39 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox