On 04/20/15 03:00, Ian Kent wrote:
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<ar...@broadcom.com>
To: Rafał Miłecki<zaj...@gmail.com>
CC: Hante Meuleman<meule...@broadcom.com>,
"linux-wirel...@vger.kernel.org" <linux-wirel...@vger.kernel.org>, Kalle
Valo<kv...@codeaurora.org>, mailinglist
<openwrt-devel@lists.openwrt.org>, Florian Fainelli
<faine...@broadcom.com>
+ 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<meule...@broadcom.com> 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.
So why do "nvram erase"? The assumption that it is not needed because
you are running an OpenWRT image is wrong or at least only partially
true, ie. for the user-space settings.
But there's no information about what the (I guess) device firmware
actually needs.
There is because those keys have a prefix.
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?
Not on R8000. Almost all configuration has to come from nvram.
Point is there should be only a few entries needed in a configuration to
alter some specific default values for a sane implementation.
Why?
Why use pcie domain and bus number?
What do you get from hard coding things that might change over time with
implementation?
What implementation do you have in mind here.
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.
This is explained in the patch as compressed format. The nvram has a
couple of devpathX keys that provide mapping of those prefixes to pcie
domain and bus number.
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.
So did you try this patch. If so there should be no need to replace
things. Just dump the entire nvram content and put it in a file so
brcmfmac can request it through the firmware api.
Regards,
Arend
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
