mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Greg KH <gregkh@suse.de>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux PM mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: [RFC][PATCH] PM: Print a warning if firmware is requested when tasks are frozen
Date: Mon, 2 May 2011 17:59:22 -0700	[thread overview]
Message-ID: <BANLkTimwmC=ckj4g_ct4EhOSLD7NDgxdng@mail.gmail.com> (raw)
In-Reply-To: <20110502232820.GA9578@suse.de>

On Mon, May 2, 2011 at 4:28 PM, Greg KH <gregkh@suse.de> wrote:
>
> A driver that does not rely on the firmware being built in would be
> correct in calling request_firmware_nowait() on resume, then when
> userspace is properly woken up, the firmware would be sent to the
> device, then the driver would be notified, load it, and handle things
> as part of its resume sequence from that notification.
>
> Isn't that ideally what we want to have happen?

No. Absolutely not.

What we ideally want to happen is for the driver to not be a stupid
piece of sh*t.

A driver that needs firmware loading at resume time IS A BROKEN DRIVER.

It really is that simple.

> Or am I missing something else?

The only correct thing to do is for a driver that is active over a
suspend to cache the firmware in RAM.

There is absolutely no other possible solution. You can't rely on
user-space loading, because the user space may well require that
driver to load things in the first place. And even if it doesn't, it
leaves a huge gaping window where the driver is useless because it has
no firmware, and then any other (unrelated to firmware loading or udev
or anythign else) user space that wants to access the device - because
it was accessing it before the suspend - will be hosed.

Seriously. Anything else is pure idiocy. The only sane model is for
drivers to load the firmware before the suspend even happens.
Preferably by simply never unloading the firmware in the first place.

No amount of crazy hacks will ever solve the problem if a driver
doesn't do that.  Not "nowait", not "reload it from udev when user
space comes back".

                        Linus

  reply	other threads:[~2011-05-03  1:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-02 22:44 Rafael J. Wysocki
2011-05-02 23:12 ` Greg KH
2011-05-02 23:21   ` Linus Torvalds
2011-05-02 23:28     ` Greg KH
2011-05-03  0:59       ` Linus Torvalds [this message]
2011-05-03 14:05         ` Greg KH
2011-05-02 23:30 ` Valdis.Kletnieks
2011-05-03 11:02   ` Rafael J. Wysocki
2011-05-03 14:06     ` Greg KH
2011-05-03 17:12       ` Rafael J. Wysocki
2011-05-03 15:47     ` Valdis.Kletnieks
2011-05-03 15:56       ` Joe Perches
2011-05-03 17:14         ` Rafael J. Wysocki
     [not found]       ` <201105031914.18160.rjw@sisk.pl>
2011-05-03 18:03         ` Valdis.Kletnieks

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='BANLkTimwmC=ckj4g_ct4EhOSLD7NDgxdng@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=rjw@sisk.pl \
    /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

all inboxes | Powered by JetHome®