From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: Ming Lei <ming.lei@canonical.com>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
Daniel Wagner <wagi@monom.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"rafael.j.wysocki" <rafael.j.wysocki@intel.com>,
Daniel Vetter <daniel.vetter@intel.com>,
Takashi Iwai <tiwai@suse.com>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Arend van Spriel <arend.vanspriel@broadcom.com>
Subject: Re: [PATCH v5 1/5] firmware: document user mode helper lock usage
Date: Wed, 5 Oct 2016 22:46:28 +0200 [thread overview]
Message-ID: <20161005204628.GH3296@wotan.suse.de> (raw)
In-Reply-To: <ab544ba0-2128-055f-3190-6a1a24e879e1@bmw-carit.de>
On Fri, Sep 23, 2016 at 10:13:44AM +0200, Daniel Wagner wrote:
> On 09/22/2016 04:36 AM, Ming Lei wrote:
> >On Sat, Sep 10, 2016 at 6:14 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> >>On Fri, Sep 09, 2016 at 02:12:20PM +0200, Daniel Wagner wrote:
> >>>From: Daniel Wagner <daniel.wagner@bmw-carit.de>
> >>>
> >>>The lock is also used to generate warnings when a direct
> >>>firmware load is requested too early.
> >>
> >>I've determined the firmware cache lets us bail out of this
> >>consideration now. If Ming agrees with the logic we don't need this
> >>patch and you can continue as you had intended. Sorry for the trouble.
> >
> >IMO it is helpful to add comment about using the lock for direct loading,
> >and we can sort it out in future if anyone want to improve it.
> >
> >So for this patch, I am fine.
>
> Sorry, I am a bit confused now. What is the consensus here:
>
> a) add a comment to _request_firmware() as in this patch #1 v5
The adding a comment note from Daniel was that the UMH lock is *not*
needed on the direct firmware loading case, he's lazy to remove it
now so he'll just add a comment.
> b) move the umh locking to fw_load_from_user_helper() as in
> patch #1 v4
This is fine and IMHO the non-lazy approach.
To be clear -- I did my own vetting of the removal of the lock by
inspecting the original purpose of the UMH lock being added on the
history Linux git tree, having a secondary review of that would be
appreciated as well.
Luis
next prev parent reply other threads:[~2016-10-05 20:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 12:12 [PATCH v5 0/5] firmware: encapsulate firmware loading status Daniel Wagner
2016-09-09 12:12 ` [PATCH v5 1/5] firmware: document user mode helper lock usage Daniel Wagner
2016-09-09 22:14 ` Luis R. Rodriguez
2016-09-22 2:36 ` Ming Lei
2016-10-05 20:41 ` Luis R. Rodriguez
[not found] ` <ab544ba0-2128-055f-3190-6a1a24e879e1@bmw-carit.de>
2016-10-05 20:46 ` Luis R. Rodriguez [this message]
[not found] ` <2ec51622-f727-e884-1a09-a595a31f4b21@bmw-carit.de>
2016-10-10 18:40 ` Luis R. Rodriguez
2016-09-09 12:12 ` [PATCH v5 2/5] firmware: encapsulate firmware loading status Daniel Wagner
2016-09-09 22:19 ` Luis R. Rodriguez
2016-09-09 22:24 ` Luis R. Rodriguez
2016-09-13 9:47 ` Daniel Wagner
2016-10-05 20:27 ` Luis R. Rodriguez
2016-10-07 11:41 ` Daniel Wagner
2016-10-10 20:37 ` Luis R. Rodriguez
2016-10-18 13:30 ` Daniel Wagner
2016-10-18 21:54 ` Luis R. Rodriguez
2016-10-19 8:05 ` Daniel Wagner
2016-09-09 12:12 ` [PATCH v5 3/5] firmware: rename fw_load_from_user_helper() and _request_firmware_load() Daniel Wagner
2016-09-09 22:17 ` Luis R. Rodriguez
2016-09-09 12:12 ` [PATCH v5 4/5] firmware: drop bit ops in favor of simple state machine Daniel Wagner
2016-09-09 22:30 ` Luis R. Rodriguez
2016-09-09 12:12 ` [PATCH v5 5/5] firmware: do not use fw_lock for fw_umh protection Daniel Wagner
2016-09-09 17:38 ` [PATCH v5 0/5] firmware: encapsulate firmware loading status Luis R. Rodriguez
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=20161005204628.GH3296@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=arend.vanspriel@broadcom.com \
--cc=bjorn.andersson@linaro.org \
--cc=daniel.vetter@intel.com \
--cc=daniel.wagner@bmw-carit.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=rafael.j.wysocki@intel.com \
--cc=tiwai@suse.com \
--cc=wagi@monom.org \
/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
Powered by JetHome