From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kalle Valo Subject: Re: Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property Date: Thu, 30 Jun 2016 11:50:41 +0300 Message-ID: <87inwr6owu.fsf@kamboji.qca.qualcomm.com> References: <1467209074-15634-1-git-send-email-hdegoede@redhat.com> <871t3gdj6p.fsf@purkki.adurom.net> Reply-To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: (Arend Van Spriel's message of "Wed, 29 Jun 2016 20:57:35 +0200") List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Arend Van Spriel Cc: Hans de Goede , Jonas Gorski , "John W . Linville" , Arend van Spriel , Maxime Ripard , Chen-Yu Tsai , "linux-wireless@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , devicetree , linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-Id: devicetree@vger.kernel.org Arend Van Spriel writes: >>> Typical wifi devices will have some sort of non volatile storage >>> on board to not only store the ethernet(mac) address, but also >>> to contain e.g. info about the antenna gain so that the firmware >>> and/or the driver can take the antenna gain into account and ensure >>> that they never exceed the maximum allowed broadcast strength. >>> >>> However on some embedded devices there is no non-volatile storage >>> for the wifi (for cost reasons) and instead this configuration info >>> (which is board / pcb specific) is loaded in the form of a >>> file which contains the contents which would normally be in the >>> non-volatile storage. >>> >>> Since we are dealing with a per-board config-file here, which is >>> loaded from the os filesystem we really need to specify a basename >>> here as the list of possible boards is endless, so we cannot >>> have a lookup table in the driver. > > As a note: For BT Marcel was playing with the idea of having a lookup > table on the file system which would be loaded by the driver. In ath10k we have a similar problem but in our case we can use the subsystem id to detect what board file to use, so it's not exactly same as yours. In our board-2.bin we have identifiers like this from which ath10k selects the correct board file: bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=334e bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=3360 bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=3361 -- Kalle Valo