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:zaj...@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 <meule...@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?

Attachment: firmware_nvram.patch
Description: firmware_nvram.patch

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to