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

[Ian Kent]

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: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?
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel