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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.