Return-path: Received: from mail-wj0-f171.google.com ([209.85.210.171]:35525 "EHLO mail-wj0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760567AbcLRKt5 (ORCPT ); Sun, 18 Dec 2016 05:49:57 -0500 Received: by mail-wj0-f171.google.com with SMTP id v7so127312585wjy.2 for ; Sun, 18 Dec 2016 02:49:56 -0800 (PST) Subject: Re: wl1251 & mac address & calibration data To: =?UTF-8?Q?Pali_Roh=c3=a1r?= , Daniel Wagner References: <201611111820.52072@pali> <07be7fc8-6c7f-6e03-379d-fa781b248259@monom.org> <201612161140.27241@pali> Cc: "Luis R. Rodriguez" , Tom Gundersen , Johannes Berg , Ming Lei , Mimi Zohar , Bjorn Andersson , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Kalle Valo , Sebastian Reichel , Pavel Machek , Michal Kazior , Ivaylo Dimitrov , Aaro Koskinen , Tony Lindgren , linux-wireless , Network Development , "linux-kernel@vger.kernel.org" , David Woodhouse , Takashi Iwai , Josh Boyer , Dmitry Torokhov From: Arend Van Spriel Message-ID: <68166247-bcd3-f598-7f9e-2139e732233e@broadcom.com> (sfid-20161218_115138_069536_22B85F88) Date: Sun, 18 Dec 2016 11:49:53 +0100 MIME-Version: 1.0 In-Reply-To: <201612161140.27241@pali> Content-Type: text/plain; charset=utf-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 16-12-2016 11:40, Pali Rohár wrote: > On Friday 16 December 2016 08:25:44 Daniel Wagner wrote: >> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote: >>> For the new API a solution for "fallback mechanisms" should be >>> clean though and I am looking to stay as far as possible from the >>> existing mess. A solution to help both the old API and new API is >>> possible for the "fallback mechanism" though -- but for that I can >>> only refer you at this point to some of Daniel Wagner and Tom >>> Gunderson's firmwared deamon prospect. It should help pave the way >>> for a clean solution and help address other stupid issues. >> >> The firmwared project is hosted here >> >> https://github.com/teg/firmwared >> >> As Luis pointed out, firmwared relies on >> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default. > > I know. But it does not mean that I cannot enable this option at kernel > compile time. > > Bigger problem is that currently request_firmware() first try to load > firmware directly from VFS and after that (if fails) fallback to user > helper. > > So I would need to extend kernel firmware code with new function (or > flag) to not use VFS and try only user mode helper. Why do you need the user-mode helper anyway. This is all static data, right? So why not cook up a firmware file in user-space once and put it in /lib/firmware for the driver to request directly. Seems a bit overkill to have a {e,}udev or whatever daemon running if the result is always the same. Just my 2 cents. Regards, Arend