linux-kernel - [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware

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

Message-Id: <1343149213-10160-1-git-send-email-ming.lei@canonical.com>
Date:	Wed, 25 Jul 2012 01:00:00 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Borislav Petkov <borislav.petkov@....com>,
	linux-kernel@...r.kernel.org
Subject: [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware

Hi,

In [1][2], the problem below has been discussed for some time:

	device's firmware may be lost during suspend/resume
	cycle because device is unplugged and plugged again
	or device experiences system power loss in the period.
	but during resume path, system is still not ready(process
	frozen, rootfs not usable, ...) to complete loading firmware
	from user space for the device

The conclusion is that caching firmware during suspend/resume cycle
is capable of solving the problem.

This patchset implements cache/uncache firmware mechanism,
and apply the mechnism to cache device's firmware in kernel memory
space automatically during suspend/resume cyclye, so device can
load its firmware easily during resume path. When resume is completed
and system is ready, the cached firmwares will be removed from
kernel memory later.

Even there are some corener cases[3] which can't be solved this cache
approach, but as Linus pointed, the driver should use some specific
way to fix it, for example, the isight camera problem can easily be
solved with deferral probe by driver explicitly, see [1], and some
patches will be posted later to do it.

[1]. http://marc.info/?t=134278790800004&r=1&w=2
[2]. http://marc.info/?t=132528956000002&r=10&w=2
[3]. http://marc.info/?l=linux-usb&m=132554118928398&w=2

Thanks,
--
Ming Lei

--
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/