On Fri, 2015-04-17 at 10:55 +0200, Arend van Spriel wrote: > Resend as it bounced on openwrt-devel list. > > -------- Original Message -------- > Subject: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE > devices in nvram. > Date: Fri, 17 Apr 2015 10:50:08 +0200 > From: Arend van Spriel <[email protected]> > To: Rafał Miłecki <[email protected]> > CC: Hante Meuleman <[email protected]>, > "[email protected]" <[email protected]>, Kalle > Valo <[email protected]>, mailinglist > <[email protected]>, Florian Fainelli <[email protected]> > > + openwrt-devel list > > On 04/17/15 09:45, Rafał Miłecki wrote: > > Huh, why dropping linux-wireless (and top posting btw)? Please let > > everyone follow the discussion :) > > > > On 15 April 2015 at 21:20, Hante Meuleman<[email protected]> wrote: > >> As I wrote to you in a mail and on the openwrt forum, this patch is indeed > >> an attempt to support more complex nvram files. I also wrote, that in > >> order to be able to use it, the nvram contents of the device (r8000) needs > >> tobe put a specific file. Now for your concerns, we can perhaps add > >> something which will read the nvram contents directly from an nvram store. > >> But thatis irrelevant to this patch. The parsing is still needed, and all > >> we wouldneed to add is something which is reading the nvram contents from > >> some other place > > > > So it makes me wonder if we need this patch in its current form. I > > think getting NVRAM directly from the platform is much user friendly. > > It doesn't require user to install some extra tools for dumping NVRAM > > and putting it in a specific file. One extra layer less. > > With that said I think it's hard to review your code for parsing > > NVRAM. We don't know how it's going to be fetched in the first place. > > You already made that point and we agreed to look for a solution. > > >> though it would have to be put under some kernel config flag as this would > >> not be supported in non-router systems. The contents of the nvram would > >> however still need to be parsed in exactly the same way as the nvram files > >> we read from disk. > > > > Again, it's hard to say for me. Are you going to use > > bcm47xx_nvram_getenv? Are you going to use MTD subsystem? Are you > > going to develop different solution? When using e.g. > > bcm47xx_nvram_getenv you won't want all this parsing stuff at all. > > Please look at the usage scenario here. The brcmfmac driver is not > needing a few key,value pairs. It needs a portion of NVRAM to download > to the device. The patch provides the functionality to do just that. Get > the appropriate portion, strip comments and whitespace, and send it to > the device. Using bcm47xx_nvram_getenv is not a useful api as it would > mean we need brcmfmac to know which key ids to ask for, reassemble it to > key=value string and send it to the fullmac device.
Following an "nvram erase" none of the needed <key, value> pairs remain in nvram. So we probably can't use nvram in a reliable way to create the wireless configuration. But there's no information about what the (I guess) device firmware actually needs. Is there a list of key value pairs used/needed? What are there default values? Are sensible default values used for key value pairs that are not present in the configuration? Point is there should be only a few entries needed in a configuration to alter some specific default values for a sane implementation. Why use pcie domain and bus number? What do you get from hard coding things that might change over time with implementation? The nvram from a vendor install doesn't use pcie domain and bus number, it uses "0:", "1:" and "2:" prefixes, and as much as I don't like that either, it is implementation independent. Knowing more about what is really needed and how it is handled (for which there is no information whatsoever that I can find) might help me understand why the driver doesn't work on my R8000. Perhaps that's a bit harsh, the driver does work partially. Extracting each prefixed section and replacing the prefix with <pcie domain>/<bus>/ doesn't seem to make any difference. The driver still insists these devices are 2.4Ghz only and barfs at any 5Ghz configuration. Ian _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
