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  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]
Date:	Sun, 1 Jan 2012 18:06:06 +0100
From:	Marek Vasut <marek.vasut@...il.com>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Larry Finger <Larry.Finger@...inger.net>,
	Chaoming Li <chaoming_li@...lsil.com.cn>,
	"John W. Linville" <linville@...driver.com>,
	Matthew Garrett <mjg@...hat.com>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	USB list <linux-usb@...r.kernel.org>,
	Linux Wireless List <linux-wireless@...r.kernel.org>
Subject: Re: loading firmware while usermodehelper disabled.

> > Am Sonntag, 1. Januar 2012, 10:54:47 schrieb Marek Vasut:
> > > > Am Samstag, 31. Dezember 2011, 19:39:18 schrieb Marek Vasut:
> > > > > maybe we should implement such thing into the firmware loader
> > > > > itself? Allow it -- for example via some node in /dev -- to force
> > > > > loading firmware into some buffer in kernel just before suspend so
> > > > > it'll certainly be readily available at resume time?
> > > > 
> > > > This is difficult. We don't know at suspend time which firmware we
> > > > will need at resume time.
> > > 
> > > That's not actually true ... you can ask the drivers if they need to
> > > load firmware after resume ... that can be implemented and udev can
> > > handle it. The driver should know if the hardware it's controlling is
> > > stupid or not.
> > 
> > Device IDs can morph due to a power loss. After resumption another driver
> > would bind.
> 
> What do you mean? I don't think I quite follow.

Ah I see ... you mean like you can swap the devices (eg. usb devices) when the 
computer is asleep. Yea, that's an issue.

On the other hand, you'd expect those to keep pestering udev to load firmware 
later in the wakeup process (maybe it can be somehow defered?). But if we 
actually implemented some pre-suspend FW cache, it might help the speed of 
resume a bit, right ?

M
> 
> M
> 
> > 	Regards
> > 	
> > 		Oliver
--
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/

Powered by blists - more mailing lists