From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Mason <slash.tmp@free.fr>, 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: Fri, 10 Jun 2016 15:39:16 +0200 [thread overview]
Message-ID: <CAMuHMdUCGamgurk+oocuvbXW_UOnoGLx+2=8Gez0s5-gowoAWA@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1606091054140.1697-100000@iolanthe.rowland.org>
Hi Alan,
On Thu, Jun 9, 2016 at 5:05 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 8 Jun 2016, Mason wrote:
>> On 08/06/2016 19:45, Alan Stern wrote:
>> > On Wed, 8 Jun 2016, Mason wrote:
>> >> 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?
>> >
>> > Those drivers should already take care of their own contexts. Is
>> > there anything platform-specific you need to do in addition?
>>
>> Take the eth driver, for example:
>>
>> http://lxr.free-electrons.com/source/drivers/net/ethernet/aurora/nb8800.c
>>
>> It doesn't have any suspend/resume callbacks.
>>
>> Would that make the suspend request fail?
>
> There are plenty of drivers that don't have suspend/resume callbacks.
> (Fewer than there used to be, fortunately.) They don't make suspend
> fail; rather, the PM core just skips over them when carrying out a
> suspend.
>
> Of course, if a driver needs suspend support but doesn't include it,
> then it's quite likely the driver will not work properly after the
> system has been resumed. But that's not a platform-specific issue.
It may be. The same device may be present on different SoCs. On some
SoCs, the device may be part of a power area, on others not.
When running on the former SoC, the driver needs to save/restore registers,
while this is not needed (but harmless, except for a small time impact)
on the latter SoC.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2016-06-10 13:39 UTC|newest]
Thread overview: 13+ 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 15:06 ` Alan Stern
2016-06-08 16:26 ` Mason
2016-06-08 17:45 ` Alan Stern
2016-06-08 21:26 ` Mason
2016-06-09 15:05 ` Alan Stern
2016-06-10 11:03 ` Mason
2016-06-10 14:19 ` Alan Stern
2016-06-10 22:32 ` Kevin Hilman
2016-06-10 13:39 ` Geert Uytterhoeven [this message]
2016-06-09 8:52 ` Sebastian Frias
2016-06-09 15:14 ` Alan Stern
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='CAMuHMdUCGamgurk+oocuvbXW_UOnoGLx+2=8Gez0s5-gowoAWA@mail.gmail.com' \
--to=geert@linux-m68k.org \
--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=slash.tmp@free.fr \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).