linux-kernel - Re: [RFC][PATCH] PM: Print a warning if firmware is requested when tasks are frozen

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110503140525.GA7944@suse.de>
Date:	Tue, 3 May 2011 07:05:25 -0700
From:	Greg KH <gregkh@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux PM mailing list <linux-pm@...ts.linux-foundation.org>
Subject: Re: [RFC][PATCH] PM: Print a warning if firmware is requested when
 tasks are frozen

On Mon, May 02, 2011 at 05:59:22PM -0700, Linus Torvalds wrote:
> On Mon, May 2, 2011 at 4:28 PM, Greg KH <gregkh@...e.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.

Well, we all want that :)

> A driver that needs firmware loading at resume time IS A BROKEN DRIVER.
> 
> It really is that simple.

Ok, fair enough, then I have no objection to this patch.  It will let us
catch those shitty drivers and fix them up to not do this.

thanks,

greg k-h
--
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/