From: Mason <slash.tmp@free.fr>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-pm <linux-pm@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Kevin Hilman <khilman@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Pavel Machek <pavel@ucw.cz>, Arnd Bergmann <arnd@arndb.de>,
Mans Rullgard <mans@mansr.com>,
Sebastian Frias <sf84@laposte.net>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: Platform-specific suspend/resume code in drivers
Date: Wed, 8 Jun 2016 18:26:30 +0200 [thread overview]
Message-ID: <57584736.7020201@free.fr> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1606071055010.1604-100000@iolanthe.rowland.org>
On 07/06/2016 17:06, Alan Stern wrote:
> On Tue, 7 Jun 2016, Mason wrote:
>
>> Another point of confusion for me is this: drivers are supposed to
>> be shared among platforms, right? So my platform-specific suspend
>> code should be enabled only if my platform is detected at run-time?
>
> Is your device platform-specific? If it is then the driver is also
> platform-specific, and so no part of the driver will be called at
> runtime unless your platform is detected.
Specifically, my platform uses
drivers/net/ethernet/aurora/nb8800.c => 3 entries in of_match_table.
drivers/tty/serial/8250/8250_core.c (CONFIG_SERIAL_8250_RT288X variant)
and also the XHCI USB3 driver, and AHCI SATA driver, wouldn't I need to
save the context for these too?
> If the device isn't platform-specific then the driver has to work on a
> bunch of different platforms. It should be written to be
> platform-independent as much as possible.
>
>> So this means I need to add in the probe function, for every driver
>> my platform uses:
>>
>> if (platform == MY_PLATFORM) {
>> ops.suspend = my_suspend;
>> ops.resume = my_resume;
>> }
>>
>> Is that correct?
>
> No. For one thing, you only have to worry about the
> platform-independent drivers -- you know that the platform-specific
> ones won't get used unless your platform is present.
I guess the thermal driver is platform-specific, but most devices
are third-party IP blocks, so there is a "common" driver upstream.
But I would need a platform-specific suspend/resume sequence,
just for my platform.
> For another, the driver should be written in a way that doesn't require
> this sort of code. The ops pointer (not any of the structure's members
> -- a pointer to the structure) should be set by the platform-dependent
> part of the driver that handles initialization.
I don't understand. If my platform loses context on suspend, then
I must save/restore it. But this wasteful operation should not be
imposed on other platforms.
Regards.
WARNING: multiple messages have this Message-ID (diff)
From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: Platform-specific suspend/resume code in drivers
Date: Wed, 8 Jun 2016 18:26:30 +0200 [thread overview]
Message-ID: <57584736.7020201@free.fr> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1606071055010.1604-100000@iolanthe.rowland.org>
On 07/06/2016 17:06, Alan Stern wrote:
> On Tue, 7 Jun 2016, Mason wrote:
>
>> Another point of confusion for me is this: drivers are supposed to
>> be shared among platforms, right? So my platform-specific suspend
>> code should be enabled only if my platform is detected at run-time?
>
> Is your device platform-specific? If it is then the driver is also
> platform-specific, and so no part of the driver will be called at
> runtime unless your platform is detected.
Specifically, my platform uses
drivers/net/ethernet/aurora/nb8800.c => 3 entries in of_match_table.
drivers/tty/serial/8250/8250_core.c (CONFIG_SERIAL_8250_RT288X variant)
and also the XHCI USB3 driver, and AHCI SATA driver, wouldn't I need to
save the context for these too?
> If the device isn't platform-specific then the driver has to work on a
> bunch of different platforms. It should be written to be
> platform-independent as much as possible.
>
>> So this means I need to add in the probe function, for every driver
>> my platform uses:
>>
>> if (platform == MY_PLATFORM) {
>> ops.suspend = my_suspend;
>> ops.resume = my_resume;
>> }
>>
>> Is that correct?
>
> No. For one thing, you only have to worry about the
> platform-independent drivers -- you know that the platform-specific
> ones won't get used unless your platform is present.
I guess the thermal driver is platform-specific, but most devices
are third-party IP blocks, so there is a "common" driver upstream.
But I would need a platform-specific suspend/resume sequence,
just for my platform.
> For another, the driver should be written in a way that doesn't require
> this sort of code. The ops pointer (not any of the structure's members
> -- a pointer to the structure) should be set by the platform-dependent
> part of the driver that handles initialization.
I don't understand. If my platform loses context on suspend, then
I must save/restore it. But this wasteful operation should not be
imposed on other platforms.
Regards.
next prev parent reply other threads:[~2016-06-08 16:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 8:56 Platform-specific suspend/resume code in drivers Mason
2016-06-07 8:56 ` Mason
2016-06-07 15:06 ` Alan Stern
2016-06-07 15:06 ` Alan Stern
2016-06-08 16:26 ` Mason [this message]
2016-06-08 16:26 ` Mason
2016-06-08 17:45 ` Alan Stern
2016-06-08 17:45 ` Alan Stern
2016-06-08 21:26 ` Mason
2016-06-08 21:26 ` Mason
2016-06-09 15:05 ` Alan Stern
2016-06-09 15:05 ` Alan Stern
2016-06-10 11:03 ` Mason
2016-06-10 11:03 ` Mason
2016-06-10 14:19 ` Alan Stern
2016-06-10 14:19 ` Alan Stern
2016-06-10 22:32 ` Kevin Hilman
2016-06-10 22:32 ` Kevin Hilman
2016-06-10 13:39 ` Geert Uytterhoeven
2016-06-10 13:39 ` Geert Uytterhoeven
2016-06-09 8:52 ` Sebastian Frias
2016-06-09 8:52 ` Sebastian Frias
2016-06-09 15:14 ` Alan Stern
2016-06-09 15:14 ` Alan Stern
2016-06-18 14:35 ` Pavel Machek
2016-06-18 14:35 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57584736.7020201@free.fr \
--to=slash.tmp@free.fr \
--cc=arnd@arndb.de \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=mans@mansr.com \
--cc=mark.rutland@arm.com \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=sf84@laposte.net \
--cc=stern@rowland.harvard.edu \
--cc=ulf.hansson@linaro.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.