[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170330032450.17121-1-mcgrof@kernel.org>
Date: Wed, 29 Mar 2017 20:24:45 -0700
From: "Luis R. Rodriguez" <mcgrof@...nel.org>
To: gregkh@...uxfoundation.org
Cc: wagi@...om.org, dwmw2@...radead.org, rafal@...ecki.pl,
arend.vanspriel@...adcom.com, rjw@...ysocki.net,
yi1.li@...ux.intel.com, atull@...nsource.altera.com,
moritz.fischer@...us.com, pmladek@...e.com,
johannes.berg@...el.com, emmanuel.grumbach@...el.com,
luciano.coelho@...el.com, kvalo@...eaurora.org, luto@...nel.org,
takahiro.akashi@...aro.org, dhowells@...hat.com, pjones@...hat.com,
linux-kernel@...r.kernel.org,
"Luis R. Rodriguez" <mcgrof@...nel.org>
Subject: [PATCH 0/5] firmware: move UMH locks onto fallback code
Greg,
One of the eyesores on the old API was the use of the UMH lock even when
we don't use any of the usermode helpers. It took quite a bit of git
archeology to draw up a solution which makes me feel comfortable in
moving this code out of the way given it may have added new protections
we never knew about. A resolution is to make similar protections for
direct FS lookups for now, and later after a release or so we can
consider removing them. There is further possible work to do to clean
up the UMH pollution on external code, but this can be done separately
and is more a generic kernel/kmod.c thing than firmware thing.
This changes makes subsequent patches able to fold the new driver data
API onto the older firmware API. These all go hammered with 0-day and
the firmware test scripts shipped upstream.
Luis R. Rodriguez (5):
firmware: share fw fallback killing on reboot/suspend
firmware: always enable the reboot notifier
firmware: add sanity check on shutdown/suspend
firmware: move assign_firmware_buf() further up
firmware: move umh try locks into the umh code
.../driver-api/firmware/request_firmware.rst | 11 +
drivers/base/firmware_class.c | 293 ++++++++++++++-------
2 files changed, 207 insertions(+), 97 deletions(-)
--
2.11.0
Powered by blists - more mailing lists