[OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.

[Hante Meuleman]

Hello Rafał

Attached is the brcmfmac patch as it is under review. One comment 
needs to be processed, but the general idea remains the same. All 
calls for this nvram reading are made under the define 
CONFIG_BCM47XX_NVRAM. Therefor it is mandatory that openwrt 
gets updated first. Only once the patch in openwrt is out the patch 
for brcmfmac will be posted. It can only break openwrt builds and 
nothing else as CONFIG_BCM47XX_NVRAM is openwrt specific.

The reason why I choose not to copy the buffer in a freshly allocated 
buffer is that it was much more work. The problem is that allocating 
more than 64K or more will fail with kzalloc (or similar) so other 
alloc function need to be used. As a result also an API (and 
implementation) for releasing this memory needs to be added. This 
buffer is to be used read-only. So I choose the easy road, but if you 
prefer something else then I can do that.

Regards,
Hante

-----Original Message-----
From: Rafał Miłecki [mailto:zajec5 at gmail.com] 
Sent: vrijdag 24 april 2015 14:08
To: Hante Meuleman
Cc: Ian Kent; Arend Van Spriel; Jonas Gorski; mailinglist
Subject: Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.

On 24 April 2015 at 12:03, Hante Meuleman <meuleman at broadcom.com> wrote:
> Attached are the two patch files. They were generated from
> include/linux/bcm47xx_nvram.h and from
> drivers/firmware/broadcom/bcm47xx_nvram.c.

I think your idea is correct, I was just thinking about bcm47xx_nvram
copying content to provided buffer, instead of sharing its own. I got
an impression it's solution usually used when dealing with such
situations & this would also protect bcm47xx internals.

I'm not really sure how to submit this patch. It exports symbol and
will be required by brcmfmac, so I guess we should ask Kalle to pick
it. However I also planned moving nvram.c from mips to bcm47xx_nvram.c
in firmware and I planned to submit this patch to Ralf (mips
maintainer).

Maybe it'll be better to work on moving NVRAM driver first? This would
make more sense to Kalle accepting drivers/firmware/ patch rather than
arch/mips/. We could keep this change in OpenWrt for now. I could
submit patch to Ralf for 3.2 kernel. Then for 3.3 we could finally
upstream your change to Kalle's tree.

Can you also share your brcmfmac patch?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firmware_nvram.patch
Type: application/octet-stream
Size: 6985 bytes
Desc: firmware_nvram.patch
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150428/2ac4b5ba/attachment.obj>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel