On Tue, 2015-04-28 at 10:31 +0000, Hante Meuleman wrote: > 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.
Yeah, I wonder if there is any possibility that the buffer could go away while brcmfmac thinks it's still available? That would be the only reason to worry. Not sure I see the difficulty here either. Reading the nvram isn't done in interrupt context (is it?) and I think it's not time critical either? So kvmalloc() is essentially a drop in replacement for kmalloc() .... > > 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? _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
