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?
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