Re: [PATCH] firmware: add a function to load optional firmware v2

From: Andres Rodriguez <andresx7@gmail.com>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
	Arend Van Spriel <arend.vanspriel@broadcom.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Ilia Mirkin <imirkin@alum.mit.edu>
Subject: Re: [PATCH] firmware: add a function to load optional firmware v2
Date: Tue, 13 Mar 2018 12:25:54 -0400	[thread overview]
Message-ID: <CAFQ_0eGrjDKJegK+8kJD90nThFeDHgdzGqYrmiYXSqKBorog0Q@mail.gmail.com> (raw)
In-Reply-To: <87r2oo9jsk.fsf@kamboji.qca.qualcomm.com>

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

Hi All,

I've been a little busy at the hospital with a kidney stone, sorry for no
updates :(

Just wanted to also chime in to say that I'm also okay with using a
different name. Preference for nowarn over quiet since I don't think we'll
provide a guarantee about other error messages being printed.

I probably won't have time for a respin of the patch until at least next
week.

Regards,
Andres

On Mar 13, 2018 9:39 AM, "Kalle Valo" <kvalo@codeaurora.org> wrote:

> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
>
> > On Mon, Mar 12, 2018 at 12:10:47AM +0100, Arend van Spriel wrote:
> >> On 3/11/2018 5:05 PM, Andres Rodriguez wrote:
> >> > > Your patch series then should also have the driver callers who you
> >> > > want to modify to use this new API. Collect from the 802.11 folks
> the
> >> > > other drivers which I think they wanted changed as well.
> >> >
> >> > Arend, Kalle, would love to hear your feedback.
> >>
> >> I am not sure if it was ath10k, but Kalle will surely know. The other
> driver
> >> firing a whole batch of firmware requests is iwlwifi. These basically
> try to
> >> get latest firmware version and if not there try an older one.
> >
> > Ah I recall now. At least for iwlwifi its that it requests firmware with
> a
> > range of api files, and we don't need information about files in the
> middle
> > not found, given all we need to know if is if at lest one file was found
> > or not.
> >
> > I have future code to also enable use of a range request which would
> replace
> > the recursive nature of iwlwifi's firmware API request, so it simplifies
> it
> > considerably.
> >
> > Once we get this flag to be silent in, this can be used later. Ie, the
> new
> > API I'd add would replace the complex api revision thing for an internal
> set.
>
> TBH I doubt we would use this kind of "range" request in ath10k, the
> current code works just fine only if we can get rid of the annoying
> warning from request_firmware(). Unless if it's significantly faster or
> something.
>
> --
> Kalle Valo
>

[-- Attachment #2: Type: text/html, Size: 2875 bytes --]