[RFC] ath10k: silence firmware file probing warnings

Arend van Spriel arend.vanspriel at broadcom.com
Wed Aug 3 12:19:14 PDT 2016

On 03-08-16 19:10, Luis R. Rodriguez wrote:
> On Wed, Aug 03, 2016 at 03:04:39PM +0000, Valo, Kalle wrote:
>> "Luis R. Rodriguez" <mcgrof at kernel.org> writes:
>>> On Wed, Aug 03, 2016 at 01:33:31PM +0200, Arend van Spriel wrote:
>>>> On 02-08-16 16:16, Luis R. Rodriguez wrote:
>>>>> On Tue, Aug 02, 2016 at 11:10:22AM +0000, Valo, Kalle wrote:
>>>>>> "Luis R. Rodriguez" <mcgrof at kernel.org> writes:
>>>>>>> I was considering this as a future extension to the firmware API
>>>>>>> through the new extensible firmware API, the sysdata API.
>>>>>> I think Linus mentioned this already, but I want to reiterate anyway.
>>>>>> The name "sysdata" is horrible, I didn't have any idea what it means
>>>>>> until I read your description. Please continue to use the term
>>>>>> "firmware", anyone already know what it means.
>>>>> We've gone well past using the firmware API for firmware though, if
>>>>> we use it for 802.11 to replace CRDA for instance its really odd to
>>>>> be calling it firmware. But sure... I will rebrand again to firmware...
>>>> I tend to agree. Although some people even call an OpenWrt image
>>>> firmware. Guess it is just in the eye of the beholder.
>>> Sure...
>>> Come to think of it I'll still go with "sysdata", this is a very minor
>>> detail, do let me know if there is anything technical rather than
>>> the color of the bikeshed [0] over the patches.
>> Well, you don't seem to care but I prefer that the terminology is clear
>> and I don't want to waste people's time browsing the source to find out
>> what something means.
> Its not that I don't care, its this is a super trivial matter, like the
> color of a bikeshed, and I'd much prefer to put energy and review on
> technical matters.
>> Even "driverdata" would be more descriptive for me
>> than "sysdata".
>> Actually, what does the "sys" refer here, system? And what system is
>> that exactly?
> Yes system, so as in system data file. "driver_data" is just as good.
> Although who knows, others may want to paint the bikeshed a different
> color.
> The core reason why the name change is to make emphasis of the fact that
> we've gone way past the point where the APIs are used for non-firmware
> and I expect this use will only grow.

Here some colors to add to the palet with "color code" in brackets:
- device specific data (dsd): although if CRDA stuff is loaded it is no
	longer tied to a device.
- eXtensible firmware API (xfw): the ever popular x factor :-p
- binary blob loader (bbl): just popped up in me head.

Need more beer to go on.


More information about the ath10k mailing list