Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Tue, 2015-04-28 at 10:31 +, 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 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
Re: [OpenWrt-Devel] [PATCH] bcm53xx: Add functions to get/release copies of nvram contents.
On Tue, 2015-05-12 at 19:31 +0200, Rafał Miłecki wrote:
> On 12 May 2015 at 15:10, Hante Meuleman wrote:
> > Added two functions to the bcm47xx_nvram module to get and release copies
> > of the complete nvram contents. This can be used by for example brcmfmac
> > to get complete nvram contents which will after some parsing be sent to
> > device.
>
> Thanks for sending this PATCH in a friendly way. It's plain text and
> seems to be well formatted, nice!
>
> Two comments:
>
> 1) This patch does more than you say. You modify initialization and
> reading. Please keep patch per change (and explain them).
>
> 2) You modify OpenWrt's copy of mainline driver code. I'm pretty sure
> I explained it to you. I don't want these driver to start differ
> again. I want to submit all change to mainline version and just copy
> most recent version to bcm53xx. So instead of this patch against
> OpenWrt's copy, please send a patch against mainline's nvram.c in the
> first place.
>
>
>
> > +char *bcm47xx_nvram_get_contents(size_t *nvram_size)
> > +{
> > + int err;
> > + char *nvram;
> > +
> > + if (!nvram_buf[0]) {
> > + err = nvram_init();
> > + if (err)
> > + return NULL;
> > + }
> > +
> > + *nvram_size = nvram_len - sizeof(struct nvram_header);
> > + nvram = vmalloc(*nvram_size);
>
> I can see you switched to vmalloc. Just to confirm, I'm OK with either way.
kmalloc() can fail on larger allocation requests, especially on low
memory systems, due to chunk table fragmentation and there's a limit on
size, 128k I think.
I've seen order 4 allocation failures when trying to kmalloc() 64k
chunks in the past. But I also agree that, this being done early in the
boot process, those fails shouldn't occur, but nevertheless
>
>
> > + if (nvram == NULL)
> > + return NULL;
> > + memcpy(nvram, &nvram_buf[sizeof(struct nvram_header)], *nvram_size);
> > +
> > + return nvram;
> > +}
> > +EXPORT_SYMBOL(bcm47xx_nvram_get_contents);
> > +
> > +void bcm47xx_nvram_release_contents(char *nvram)
> > +{
> > + vfree(nvram);
> > +}
> > +EXPORT_SYMBOL(bcm47xx_nvram_release_contents);
> > +
> > +
> > MODULE_LICENSE("GPLv2");
>
> One empty line will be enough.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bcm53xx: Add functions to get/release copies of nvram contents.
On Wed, 2015-05-13 at 06:34 +0200, Rafał Miłecki wrote:
> On 13 May 2015 at 03:49, Ian Kent wrote:
> > On Tue, 2015-05-12 at 19:31 +0200, Rafał Miłecki wrote:
> >> On 12 May 2015 at 15:10, Hante Meuleman wrote:
> >> > Added two functions to the bcm47xx_nvram module to get and release copies
> >> > of the complete nvram contents. This can be used by for example brcmfmac
> >> > to get complete nvram contents which will after some parsing be sent to
> >> > device.
> >>
> >> Thanks for sending this PATCH in a friendly way. It's plain text and
> >> seems to be well formatted, nice!
> >>
> >> Two comments:
> >>
> >> 1) This patch does more than you say. You modify initialization and
> >> reading. Please keep patch per change (and explain them).
> >>
> >> 2) You modify OpenWrt's copy of mainline driver code. I'm pretty sure
> >> I explained it to you. I don't want these driver to start differ
> >> again. I want to submit all change to mainline version and just copy
> >> most recent version to bcm53xx. So instead of this patch against
> >> OpenWrt's copy, please send a patch against mainline's nvram.c in the
> >> first place.
> >>
> >>
> >>
> >> > +char *bcm47xx_nvram_get_contents(size_t *nvram_size)
> >> > +{
> >> > + int err;
> >> > + char *nvram;
> >> > +
> >> > + if (!nvram_buf[0]) {
> >> > + err = nvram_init();
> >> > + if (err)
> >> > + return NULL;
> >> > + }
> >> > +
> >> > + *nvram_size = nvram_len - sizeof(struct nvram_header);
> >> > + nvram = vmalloc(*nvram_size);
> >>
> >> I can see you switched to vmalloc. Just to confirm, I'm OK with either way.
> >
> > kmalloc() can fail on larger allocation requests, especially on low
> > memory systems, due to chunk table fragmentation and there's a limit on
> > size, 128k I think.
> >
> > I've seen order 4 allocation failures when trying to kmalloc() 64k
> > chunks in the past. But I also agree that, this being done early in the
> > boot process, those fails shouldn't occur, but nevertheless
>
> I was thinking about vmalloc vs. returning nvram_buf address :)
Ha, right, still I believe in not using a data structure owned by
someone else when you don't "really" know what might be happening with
it along the way.
Ian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Looking for a Broadcom Asus tester(s)
On Wed, 2015-05-27 at 22:32 +0200, Rafał Miłecki wrote: > Hi, > > With few recent commits OpenWrt can now generate Asus-specific TRX > files for brcm47xx and bcm53xx. The magic is about some extra data at > the end of TRX (so the format differs a bit, even it using the same > file extension and layout). > > My request for someone having Broadcom-based Asus devices is: > 1) Install original firmware > 2) Try to install OpenWrt .trx firmware for that device > 3) Let us know if it worked > > I don't have any Asus device around, so I'm not sure if OpenWrt > generates really compatible images now. Above way is the only one to > verify it for sure :) Has the partition corruption I saw with the RT-AC87U a while ago (when I tested if it would boot, which it didn't) been sorted out? I really don't want to risk breaking my device again. I was lucky I was able to get a build of asuswrt-merlin to go far enough to build mtd-erase2, actually it's a symlink to the rc utility, (with an appropriate change) to allow me to fix the problem. btw, off-topic, I've been able to load the R8000 OpenWrt chk firmware via Luci a few times now so I don't know what changed but it seems ok now. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Sun, 2015-06-21 at 19:19 +0200, Rafał Miłecki wrote: > On 10 March 2015 at 04:30, Ian Kent wrote: > > The Netgear R8000 has a PEX8603 connected to the BCM53012 and if > > it isn't configured during the bus scan the PCI layer goes crazy > > trying to configure phantom devices. > > This is kind of magic for me. > Hauke: are you able to review this? Yeah, it's a bridge so it needs upstream and downstream bus ids set but the main issue is that it doesn't respond with appropriate return values for non-existent devices. I modelled the code on the corresponding source from the Broadcom SDK file that this source was originally developed from (at least it appeared to match). I confirmed that PEX860X devices don't return proper return code from another PEX driver, from the WRT1900 source I think, its been a while now. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Mon, 2015-06-22 at 18:42 +0200, Hauke Mehrtens wrote:
>
> On 03/10/2015 04:30 AM, Ian Kent wrote:
> > The Netgear R8000 has a PEX8603 connected to the BCM53012 and if
> > it isn't configured during the bus scan the PCI layer goes crazy
> > trying to configure phantom devices.
>
> Could you provide some diagram how this is connected?
I could try, when I get a chance, ascii art isn't my strong suit.
>
> My current assumption is that on one of the 3 PCIe ports is this switch,
> so the scan will find this switch as a PCIe device, bu how does it go
> from there?
I can only infer from looking at sysfs, which is what I have done.
Perhaps I'm not correct but it looks to me that there are is a BCM53012
connected with two legs, one has one wireless device, and the other has
a PEX8603 bridge which has two legs, each with a wireless device.
> From the vendor driver I would assume that that the two devices behind
> the switch are device function 0x08 and 0x10 on the switch device.
I'll have to reacquaint myself with the code before I respond to the
comments below, its been a while.
>
> Can you also post the output of lspci on your device?
Don't think I have lspci in the build I was using, I'll need to add it
and rebuild. That probably won't be until the weekend.
>
> >
> > Signed-off-by: Ian Kent
> > ---
> > .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
> >
> > .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
> >
> > 2 files changed, 450 insertions(+)
> > create mode 100644
> > target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > create mode 100644
> > target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> >
>
>
> ..
>
>
> > diff --git
> > a/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> >
> > b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > new file mode 100644
> > index 000..fc606b4
> > --- /dev/null
> > +++
> > b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > @@ -0,0 +1,225 @@
> > +bcm53xx: R8000 handle PEX8603 switch
> > +
> > +The Netgear R8000 has a PEX8603 which, if not configured at
> > +bus probe results in quite a few phantom devices as it doesn't
> > +respond properly to configuration requests. The device needs
> > +to be configured when seen.
> > +
> > +Signed-off-by: Ian Kent
> > +
> > +--- a/drivers/pci/host/pci-host-bcm5301x.c
> > b/drivers/pci/host/pci-host-bcm5301x.c
> > +@@ -29,6 +29,21 @@
> > + #define PCI_TARGET_LINK_SPEED_GEN20x2
> > + #define PCI_TARGET_LINK_SPEED_GEN10x1
> > +
> > ++#define PCI_MAX_BUS 4
> > ++#define PLX_PRIM_SEC_BUS_NUM (0x0201 | (PCI_MAX_BUS <<
> > 16))
> > ++
> > ++#ifndef SZ_48M
> > ++#define SZ_48M(SZ_32M + SZ_16M)
> > ++#endif
>
> Please remove the ifndef, it should fail if this gets added.
>
>
> > ++
> > ++struct pex86xx_info {
> > ++ u8 busno; /* Upstream bus PEX is on */
> > ++ u8 slot;/* Upstream slot PEX is at */
> > ++ u16 active; /* Active port count */
> > ++ u16 ports; /* Active port bit map */
> > ++};
> > ++struct pex86xx_info pex8603;
> > ++
> > + static int bcma_pcie2_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
> > + {
> > + struct pci_sys_data *sys = pdev->sysdata;
> > +@@ -115,6 +130,39 @@ static int bcma_pcie2_read_config_pci(st
> > + struct pci_sys_data *sys = bus->sysdata;
> > + struct bcma_device *bdev = sys->private_data;
> > +
> > ++ /* The PEX8603 won't return sensible values to the PCI layer so
> > ++ * we have to do that ourselves.
> > ++ */
> > ++ if (pex8603.busno) {
> > ++ u16 slot = PCI_SLOT(devfn);
> > ++
> > ++ /* Not the PEX upstream slot */
> > ++ if (pex8603.busno == bus->number && pex8603.slot != slot)
> > ++ goto done;
> > ++
> > ++ /* Not the PEX downstream bus? */
> > ++ if (bus->number < pex8603.busno ||
> > ++ bus->number > pex8603.busno + 1)
> > ++ goto done;
> > ++
> > ++ switch (bus->number - pex8603.busno) {
> > ++ case 0:
> > ++ /* Upstream port */
> > ++ break;
&
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Tue, 2015-06-23 at 07:58 +0800, Ian Kent wrote:
> On Mon, 2015-06-22 at 18:42 +0200, Hauke Mehrtens wrote:
> >
> > On 03/10/2015 04:30 AM, Ian Kent wrote:
> > > The Netgear R8000 has a PEX8603 connected to the BCM53012 and if
> > > it isn't configured during the bus scan the PCI layer goes crazy
> > > trying to configure phantom devices.
> >
> > Could you provide some diagram how this is connected?
>
> I could try, when I get a chance, ascii art isn't my strong suit.
>
> >
> > My current assumption is that on one of the 3 PCIe ports is this switch,
> > so the scan will find this switch as a PCIe device, bu how does it go
> > from there?
>
> I can only infer from looking at sysfs, which is what I have done.
>
> Perhaps I'm not correct but it looks to me that there are is a BCM53012
> connected with two legs, one has one wireless device, and the other has
> a PEX8603 bridge which has two legs, each with a wireless device.
I still think this is the correct topology and IIRC that was also
inferred by looking at sysfs with vendor firmware installed. But maybe
my recollection fails me, I'll need to check.
>
> > From the vendor driver I would assume that that the two devices behind
> > the switch are device function 0x08 and 0x10 on the switch device.
>
> I'll have to reacquaint myself with the code before I respond to the
> comments below, its been a while.
Yes, looking at the code again they are "upstream port bus number + 1,
devfn 0x08 (aka. slot 1)" and "upstream port bus number + 2, devfn 0x10
(aka. slot 2)" so the slot number can't be used alone.
>
> >
> > Can you also post the output of lspci on your device?
>
> Don't think I have lspci in the build I was using, I'll need to add it
> and rebuild. That probably won't be until the weekend.
I'll get this when the ncurses build breakage is fixed or perhaps by
deselecting ncurses dependencies if it takes too long for it to be
fixed.
>
> >
> > >
> > > Signed-off-by: Ian Kent
> > > ---
> > > .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
> > >
> > > .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
> > >
> > > 2 files changed, 450 insertions(+)
> > > create mode 100644
> > > target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > > create mode 100644
> > > target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > >
> >
> >
> > ..
> >
> >
> > > diff --git
> > > a/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > >
> > > b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > > new file mode 100644
> > > index 000..fc606b4
> > > --- /dev/null
> > > +++
> > > b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
> > > @@ -0,0 +1,225 @@
> > > +bcm53xx: R8000 handle PEX8603 switch
> > > +
> > > +The Netgear R8000 has a PEX8603 which, if not configured at
> > > +bus probe results in quite a few phantom devices as it doesn't
> > > +respond properly to configuration requests. The device needs
> > > +to be configured when seen.
> > > +
> > > +Signed-off-by: Ian Kent
> > > +
> > > +--- a/drivers/pci/host/pci-host-bcm5301x.c
> > > b/drivers/pci/host/pci-host-bcm5301x.c
> > > +@@ -29,6 +29,21 @@
> > > + #define PCI_TARGET_LINK_SPEED_GEN20x2
> > > + #define PCI_TARGET_LINK_SPEED_GEN10x1
> > > +
> > > ++#define PCI_MAX_BUS 4
> > > ++#define PLX_PRIM_SEC_BUS_NUM(0x0201 | (PCI_MAX_BUS <<
> > > 16))
> > > ++
> > > ++#ifndef SZ_48M
> > > ++#define SZ_48M (SZ_32M + SZ_16M)
> > > ++#endif
> >
> > Please remove the ifndef, it should fail if this gets added.
OK, I put the conditional in thinking this might be added to
linux/sizes.h at some point but looking at sizes.h again we probably
won't see the 48 variant being added.
> >
> >
> > > ++
> > > ++struct pex86xx_info {
> > > ++u8 busno; /* Upstream bus PEX is on */
> > > ++u8 slot;/* Upstream slot PEX is at */
> > > ++u16 active; /* Active port count */
> > > ++u16 ports; /* Active port bit map */
> >
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Tue, 2015-07-14 at 18:19 +0200, Rafał Miłecki wrote: > On 28 June 2015 at 05:37, Ian Kent wrote: > > Let me rework this using the bus number as you recommend. > > I'll repost my updated patch series once I've done that. > > Hi Ian, > > Is there any chance you'll find a moment for it anytime soon? It'd be > awesome to get R8000 support for CC release. I have reworked the patch and a broken package build problem I had is gone but I didn't get time to fix build problems with a third patch I have. Just didn't get time last weekend and this week has been quite busy too. I'll try and get onto this in the next few days. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Wed, 2015-08-12 at 22:01 +0200, Hauke Mehrtens wrote: > On 07/15/2015 12:11 PM, Ian Kent wrote: > > On Tue, 2015-07-14 at 18:19 +0200, Rafał Miłecki wrote: > >> On 28 June 2015 at 05:37, Ian Kent wrote: > >>> Let me rework this using the bus number as you recommend. > >>> I'll repost my updated patch series once I've done that. > >> > >> Hi Ian, > >> > >> Is there any chance you'll find a moment for it anytime soon? It'd be > >> awesome to get R8000 support for CC release. > > > > I have reworked the patch and a broken package build problem I had is > > gone but I didn't get time to fix build problems with a third patch I > > have. > > > > Just didn't get time last weekend and this week has been quite busy too. > > I'll try and get onto this in the next few days. > > > > Ian > > Hi Ian, > > you patch looks better than the hack Broadcom did in their vendor driver. I thought so, ;) > > Could you send me a lspci output or the content of /proc/bus/pci/devices > of the original firmware or of OpenWrt with your patch applied? I would > prefer lspci because it is easier to read but cat from > /proc/bus/pci/devices also works. I do not have such a device and want > to understand how this PCIe switch looks like on the software side, so > we can fix the domain, bus, slot, function mixup. I haven't been able to build OpenWrt for a while now and that's why I haven't been able to test my changes to the patch. I really wish we could avoid committing changes that don't build but I know it isn't that simple. I have got some other lists (around somewhere) based on output, mostly from the Vendor firmware, and one where I went through the devices and listed what they are along with and their pci ids so I could try and understand what was going on. I could try and find that and post it if it would be useful. Note that it was just used to understand what was what so it isn't pretty but should have quite a bit of info in it. There's no question the current patch is wrong so I don't recommend it be used. I can however post my updated patch now on the understanding that it hasn't been tested at all, which might be good for initial review anyway. > > On the hardware side this SoC has 3 PCIe controllers, but one shares a > PHY with the USB 3.0 controller. Instead of using the 3rd PCIe > controller they used USB 3.0 and split one of the PCIe controllers into > 2 PCIE lanes. Right, I didn't get that, mmm ... Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Fri, 2015-08-14 at 19:55 +0200, Hauke Mehrtens wrote: > On 08/14/2015 06:03 AM, Ian Kent wrote: > > On Wed, 2015-08-12 at 22:01 +0200, Hauke Mehrtens wrote: > >> On 07/15/2015 12:11 PM, Ian Kent wrote: > >>> On Tue, 2015-07-14 at 18:19 +0200, Rafał Miłecki wrote: > >>>> On 28 June 2015 at 05:37, Ian Kent wrote: > >>>>> Let me rework this using the bus number as you recommend. > >>>>> I'll repost my updated patch series once I've done that. > >>>> > >>>> Hi Ian, > >>>> > >>>> Is there any chance you'll find a moment for it anytime soon? It'd be > >>>> awesome to get R8000 support for CC release. > >>> > >>> I have reworked the patch and a broken package build problem I had is > >>> gone but I didn't get time to fix build problems with a third patch I > >>> have. > >>> > >>> Just didn't get time last weekend and this week has been quite busy too. > >>> I'll try and get onto this in the next few days. > >>> > >>> Ian > >> > >> Hi Ian, > >> > >> you patch looks better than the hack Broadcom did in their vendor driver. > > > > I thought so, ;) > > > >> > >> Could you send me a lspci output or the content of /proc/bus/pci/devices > >> of the original firmware or of OpenWrt with your patch applied? I would > >> prefer lspci because it is easier to read but cat from > >> /proc/bus/pci/devices also works. I do not have such a device and want > >> to understand how this PCIe switch looks like on the software side, so > >> we can fix the domain, bus, slot, function mixup. > > > > I haven't been able to build OpenWrt for a while now and that's why I > > haven't been able to test my changes to the patch. > > I haven't noticed a problem in the OpenWrt build system, do you still > have this problem? Have you tried to clean and rebuild again? The problem I have now is with mkimage. It started after a distclean and reconfigure to ensure I was getting a fully up to date repo. > > > I really wish we could avoid committing changes that don't build but I > > know it isn't that simple. > > > > I have got some other lists (around somewhere) based on output, mostly > > from the Vendor firmware, and one where I went through the devices and > > listed what they are along with and their pci ids so I could try and > > understand what was going on. > > I found some boot log of OpenWrt in the OpenWrt forum in this post, it > shows how the PCIe devices are looking without your patch. > https://forum.openwrt.org/viewtopic.php?pid=269905#p269905 > I am used to search for some boot logs random people posted on the > Internet. ;-) Yes, I'm pretty sure the broken PEX8603 patch was applied to the build I used that produced that dmesg output. Is that sufficient? > > > I could try and find that and post it if it would be useful. > > Note that it was just used to understand what was what so it isn't > > pretty but should have quite a bit of info in it. > > > > There's no question the current patch is wrong so I don't recommend it > > be used. > > > > I can however post my updated patch now on the understanding that it > > hasn't been tested at all, which might be good for initial review > > anyway. > > > >> > >> On the hardware side this SoC has 3 PCIe controllers, but one shares a > >> PHY with the USB 3.0 controller. Instead of using the 3rd PCIe > >> controller they used USB 3.0 and split one of the PCIe controllers into > >> 2 PCIE lanes. > > > > Right, I didn't get that, mmm ... > > With kernel 4.1 OpenWrt switched to a different PICe driver, which is > also in the mainline kernel and supported by Broadcom. > > Hauke > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Sat, 2015-08-15 at 09:55 +0800, Ian Kent wrote: > On Fri, 2015-08-14 at 19:55 +0200, Hauke Mehrtens wrote: > > On 08/14/2015 06:03 AM, Ian Kent wrote: > > > On Wed, 2015-08-12 at 22:01 +0200, Hauke Mehrtens wrote: > > >> On 07/15/2015 12:11 PM, Ian Kent wrote: > > >>> On Tue, 2015-07-14 at 18:19 +0200, Rafał Miłecki wrote: > > >>>> On 28 June 2015 at 05:37, Ian Kent wrote: > > >>>>> Let me rework this using the bus number as you recommend. > > >>>>> I'll repost my updated patch series once I've done that. > > >>>> > > >>>> Hi Ian, > > >>>> > > >>>> Is there any chance you'll find a moment for it anytime soon? It'd be > > >>>> awesome to get R8000 support for CC release. > > >>> > > >>> I have reworked the patch and a broken package build problem I had is > > >>> gone but I didn't get time to fix build problems with a third patch I > > >>> have. > > >>> > > >>> Just didn't get time last weekend and this week has been quite busy too. > > >>> I'll try and get onto this in the next few days. > > >>> > > >>> Ian > > >> > > >> Hi Ian, > > >> > > >> you patch looks better than the hack Broadcom did in their vendor driver. > > > > > > I thought so, ;) > > > > > >> > > >> Could you send me a lspci output or the content of /proc/bus/pci/devices > > >> of the original firmware or of OpenWrt with your patch applied? I would > > >> prefer lspci because it is easier to read but cat from > > >> /proc/bus/pci/devices also works. I do not have such a device and want > > >> to understand how this PCIe switch looks like on the software side, so > > >> we can fix the domain, bus, slot, function mixup. > > > > > > I haven't been able to build OpenWrt for a while now and that's why I > > > haven't been able to test my changes to the patch. > > > > I haven't noticed a problem in the OpenWrt build system, do you still > > have this problem? Have you tried to clean and rebuild again? > > The problem I have now is with mkimage. > > It started after a distclean and reconfigure to ensure I was getting a > fully up to date repo. > > > > > > I really wish we could avoid committing changes that don't build but I > > > know it isn't that simple. > > > > > > I have got some other lists (around somewhere) based on output, mostly > > > from the Vendor firmware, and one where I went through the devices and > > > listed what they are along with and their pci ids so I could try and > > > understand what was going on. > > > > I found some boot log of OpenWrt in the OpenWrt forum in this post, it > > shows how the PCIe devices are looking without your patch. > > https://forum.openwrt.org/viewtopic.php?pid=269905#p269905 > > I am used to search for some boot logs random people posted on the > > Internet. ;-) > > Yes, I'm pretty sure the broken PEX8603 patch was applied to the build I > used that produced that dmesg output. I looked at that output again and it does must the broken patch applied. If it didn't you would see a message about a broken device class device, hence the fixup, and lots of non-existent pci devices during discovery. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Sat, 2015-08-15 at 09:55 +0800, Ian Kent wrote: > On Fri, 2015-08-14 at 19:55 +0200, Hauke Mehrtens wrote: > > On 08/14/2015 06:03 AM, Ian Kent wrote: > > > On Wed, 2015-08-12 at 22:01 +0200, Hauke Mehrtens wrote: > > >> On 07/15/2015 12:11 PM, Ian Kent wrote: > > >>> On Tue, 2015-07-14 at 18:19 +0200, Rafał Miłecki wrote: > > >>>> On 28 June 2015 at 05:37, Ian Kent wrote: > > >>>>> Let me rework this using the bus number as you recommend. > > >>>>> I'll repost my updated patch series once I've done that. > > >>>> > > >>>> Hi Ian, > > >>>> > > >>>> Is there any chance you'll find a moment for it anytime soon? It'd be > > >>>> awesome to get R8000 support for CC release. > > >>> > > >>> I have reworked the patch and a broken package build problem I had is > > >>> gone but I didn't get time to fix build problems with a third patch I > > >>> have. > > >>> > > >>> Just didn't get time last weekend and this week has been quite busy too. > > >>> I'll try and get onto this in the next few days. > > >>> > > >>> Ian > > >> > > >> Hi Ian, > > >> > > >> you patch looks better than the hack Broadcom did in their vendor driver. > > > > > > I thought so, ;) > > > > > >> > > >> Could you send me a lspci output or the content of /proc/bus/pci/devices > > >> of the original firmware or of OpenWrt with your patch applied? I would > > >> prefer lspci because it is easier to read but cat from > > >> /proc/bus/pci/devices also works. I do not have such a device and want > > >> to understand how this PCIe switch looks like on the software side, so > > >> we can fix the domain, bus, slot, function mixup. > > > > > > I haven't been able to build OpenWrt for a while now and that's why I > > > haven't been able to test my changes to the patch. > > > > I haven't noticed a problem in the OpenWrt build system, do you still > > have this problem? Have you tried to clean and rebuild again? > > The problem I have now is with mkimage. > > It started after a distclean and reconfigure to ensure I was getting a > fully up to date repo. OK, I had a quick look around for this problem and, much to my surprise, I found this (I hadn't found anything previously). https://dev.openwrt.org/ticket/20134#comment:10 I'll try reverting the commit and see if I can make some progress over the weekend. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Tue, 2015-06-23 at 07:58 +0800, Ian Kent wrote: > On Mon, 2015-06-22 at 18:42 +0200, Hauke Mehrtens wrote: > > > > On 03/10/2015 04:30 AM, Ian Kent wrote: > > > The Netgear R8000 has a PEX8603 connected to the BCM53012 and if > > > it isn't configured during the bus scan the PCI layer goes crazy > > > trying to configure phantom devices. > > > > Could you provide some diagram how this is connected? > > I could try, when I get a chance, ascii art isn't my strong suit. > > > > > My current assumption is that on one of the 3 PCIe ports is this switch, > > so the scan will find this switch as a PCIe device, bu how does it go > > from there? > > I can only infer from looking at sysfs, which is what I have done. > > Perhaps I'm not correct but it looks to me that there are is a BCM53012 > connected with two legs, one has one wireless device, and the other has > a PEX8603 bridge which has two legs, each with a wireless device. > > > From the vendor driver I would assume that that the two devices behind > > the switch are device function 0x08 and 0x10 on the switch device. > > I'll have to reacquaint myself with the code before I respond to the > comments below, its been a while. > > > > > Can you also post the output of lspci on your device? > > Don't think I have lspci in the build I was using, I'll need to add it > and rebuild. That probably won't be until the weekend. OK, I've been able get a build. My updated patch doesn't yet function so I've used the driver we're discussing here to get info. TBH, looking at this, I'm not so sure the patch is wrong now. lspci gives: :00:00.0 PCI bridge: Broadcom Corporation Device 8012 (rev 01) :01:00.0 Network controller: Broadcom Corporation Device aa52 (rev 01) 0001:00:00.0 PCI bridge: Broadcom Corporation Device 8012 (rev 01) 0001:01:00.0 PCI bridge: PLX Technology, Inc. Device 8603 (rev ab) 0001:02:01.0 PCI bridge: PLX Technology, Inc. Device 8603 (rev ab) 0001:02:02.0 PCI bridge: PLX Technology, Inc. Device 8603 (rev ab) 0001:03:00.0 Network controller: Broadcom Corporation Device aa52 (rev 01) 0001:04:00.0 Network controller: Broadcom Corporation Device aa52 (rev 01) and a list of /sys/bus/pci/devices on a Vendor firmware install gives: :00:00.0 :00:06.0 :00:0b.1 :00:11.0 0002:01:00.0 :00:01.0 :00:07.0 :00:0c.0 :00:12.0 0002:02:01.0 :00:02.0 :00:08.0 :00:0d.0 :00:13.0 0002:02:02.0 :00:03.0 :00:09.0 :00:0e.0 0001:00:00.0 0002:03:00.0 :00:04.0 :00:0a.0 :00:0f.0 0001:01:00.0 0002:04:00.0 :00:05.0 :00:0b.0 :00:10.0 0002:00:00.0 which looks like the topology is the same. So, possibly, my description of how I believe the devices are connected is accurate. bcm8012 | | aa52 pex8603 --- | | aa52 aa52 > > > > > > > > > Signed-off-by: Ian Kent > > > --- > > > .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225 > > > > > > .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225 > > > > > > 2 files changed, 450 insertions(+) > > > create mode 100644 > > > target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch > > > create mode 100644 > > > target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch > > > > > > > > > .. > > > > > > > diff --git > > > a/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch > > > > > > b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch > > > new file mode 100644 > > > index 000..fc606b4 > > > --- /dev/null > > > +++ > > > b/target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch > > > @@ -0,0 +1,225 @@ > > > +bcm53xx: R8000 handle PEX8603 switch > > > + > > > +The Netgear R8000 has a PEX8603 which, if not configured at > > > +bus probe results in quite a few phantom devices as it doesn't > > > +respond properly to configuration requests. The device needs > > > +to be configured when seen. > > > + > > > +Signed-off-by: Ian Kent > > > + > > > +--- a/drivers/pci/host/pci-host-bcm5301x.c > > > b/drivers/pci/host/pci-host-bcm5301x.c > > > +@@ -29,6 +29,21 @@ > > > + #define PCI_TARGET_LINK_SPEED_GEN20x2 &
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On Fri, 2015-08-21 at 20:17 +0200, Hauke Mehrtens wrote: > > On 08/16/2015 06:19 AM, Ian Kent wrote: > > On Tue, 2015-06-23 at 07:58 +0800, Ian Kent wrote: > >> On Mon, 2015-06-22 at 18:42 +0200, Hauke Mehrtens wrote: > >>> > >>> On 03/10/2015 04:30 AM, Ian Kent wrote: > >>>> The Netgear R8000 has a PEX8603 connected to the BCM53012 and if > >>>> it isn't configured during the bus scan the PCI layer goes crazy > >>>> trying to configure phantom devices. > >>> > >>> Could you provide some diagram how this is connected? > >> > >> I could try, when I get a chance, ascii art isn't my strong suit. > >> > >>> > >>> My current assumption is that on one of the 3 PCIe ports is this switch, > >>> so the scan will find this switch as a PCIe device, bu how does it go > >>> from there? > >> > >> I can only infer from looking at sysfs, which is what I have done. > >> > >> Perhaps I'm not correct but it looks to me that there are is a BCM53012 > >> connected with two legs, one has one wireless device, and the other has > >> a PEX8603 bridge which has two legs, each with a wireless device. > >> > >>> From the vendor driver I would assume that that the two devices behind > >>> the switch are device function 0x08 and 0x10 on the switch device. > >> > >> I'll have to reacquaint myself with the code before I respond to the > >> comments below, its been a while. > >> > >>> > >>> Can you also post the output of lspci on your device? > >> > >> Don't think I have lspci in the build I was using, I'll need to add it > >> and rebuild. That probably won't be until the weekend. > > > > OK, I've been able get a build. > > I think we do not get this into OpenWrt CC any more. You should probably > base your work on top of the new PCIe host driver in the trunk used with > kernel 4.1. > > Will you send a new Version or should I look into this? I will, have been and continue to be quite busy so it will need to be done when I decide to have some "weekend time", ;) > > > My updated patch doesn't yet function so I've used the driver we're > > discussing here to get info. > > > > TBH, looking at this, I'm not so sure the patch is wrong now. > > > > lspci gives: > > :00:00.0 PCI bridge: Broadcom Corporation Device 8012 (rev 01) > > :01:00.0 Network controller: Broadcom Corporation Device aa52 (rev 01) > > 0001:00:00.0 PCI bridge: Broadcom Corporation Device 8012 (rev 01) > > 0001:01:00.0 PCI bridge: PLX Technology, Inc. Device 8603 (rev ab) > > 0001:02:01.0 PCI bridge: PLX Technology, Inc. Device 8603 (rev ab) > > 0001:02:02.0 PCI bridge: PLX Technology, Inc. Device 8603 (rev ab) > > 0001:03:00.0 Network controller: Broadcom Corporation Device aa52 (rev 01) > > 0001:04:00.0 Network controller: Broadcom Corporation Device aa52 (rev 01) > > > > and a list of /sys/bus/pci/devices on a Vendor firmware install gives: > > :00:00.0 :00:06.0 :00:0b.1 :00:11.0 0002:01:00.0 > > :00:01.0 :00:07.0 :00:0c.0 :00:12.0 0002:02:01.0 > > :00:02.0 :00:08.0 :00:0d.0 :00:13.0 0002:02:02.0 > > :00:03.0 :00:09.0 :00:0e.0 0001:00:00.0 0002:03:00.0 > > :00:04.0 :00:0a.0 :00:0f.0 0001:01:00.0 0002:04:00.0 > > :00:05.0 :00:0b.0 :00:10.0 0002:00:00.0 > > Thanks for these information. > Without your patch the PCI subsystem will find lots of strange devices > and will report broken data and does not only show nothing, is that > correct? That's exactly so. And the bridge itself isn't recognised properly because of fixup needed at initial probe. > > > which looks like the topology is the same. > > > > So, possibly, my description of how I believe the devices are connected > > is accurate. > > > > bcm8012 > > > > | | > > aa52 pex8603 > > --- > > | | > > aa52 aa52 > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT1900AC - Available firmwares ?
On Thu, 2015-01-08 at 14:36 -0200, Fernando Frediani wrote: > Hi all, > > Does anyone here have a Linksys WRT1900AC (that fiasco that suppose to > be the new generation of WRT54G) ? Yes and I like it. As Imre Kaloz says Marvel recently released updated driver source. It seems to me the major hold up was the development approach used in the beginning. I think it cost quite a bit of time on what was essentially a false start. Now Marvel have chosen to update (pretty much re-wrote) the driver with the goal of having it accepted into the upstream kernel. It arrears to have much less code than the original and what looks to me like ugly hacks to other core OpenWrt subsystems to make the old driver work are no longer needed so the maintenance burden should be much less for all concerned. Over all very good news. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Announcement of mac80211 driver support for Marvell 88W8864 chip
Hi David,
Please forgive the top posting.
I don't think that the kernel programming style guidelines recommend
against it and I also don't know if checkpatch.pl will complain about it
but personally I find the additional blank lines in things like the
below actually make the code harder to read:
struct hostcmd_header {
u16 cmd;
u16 len;
u8 seq_num;
u8 macid;
u16 result;
} __packed;
and
if ((conf->chandef.width == NL80211_CHAN_WIDTH_20_NOHT) ||
(conf->chandef.width == NL80211_CHAN_WIDTH_20)) {
width = CH_20_MHz_WIDTH;
sub_ch = NO_EXT_CHANNEL;
} else if (conf->chandef.width == NL80211_CHAN_WIDTH_40) {
Certainly we all have own own preferences about what is more readable
for ourselves but please re-consider whether this really does aid
readability.
One other thing to consider about using checkpatch.pl is that the
changes it reports are strongly recommended to be made, based on the
kernel coding style guide, but if you feel strongly about some of the
needed changes you can try and make a case for what you believe aids
readability more so than the recommended changes.
It might not be my place to ask but I'm having some problems with the
driver. I've started to become familiar with the code and, after a
while, may have some questions. This is likely to be a little tedious
for you since mac80211 and wireless is not my area in the kernel.
Would you mind discussing them here on the list or would you rather me
wait for the next update (don't feel obligated, I'll survive)?
Ian
On Sun, 2015-01-11 at 19:46 -0800, David Lin wrote:
> Hi Jiri,
>
> It is always nice to include all needed headers in all .c files. For
> example when you use skb_queue_head_init please include
> Spotted a comment typo in mwl_fwdl.c:
> "This file implements frimware downloa related functions"
> "MODULE_" macros are usually placed by the end of file.
>
> --> Modifications should be included in next release.
>
> Drop comments like:
> /* PRIVATE FUNCTION DEFINITION
> */
> Not needed.
>
> --> Unless it is really forbidden, I will keep this comment.
>
> I would suggest you to develop your driver inside net-next git:
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/
> That would save you time during potential forward port need.
> Also, if you use scripts/checkpatch.pl script to check your patches, it
> will reveal many problems to you. The obvious one is lines longer than 80
> chars.
> Module parameters should be always avoided if possible.
> I suggest you make patch against net-next and send it on
> linux-wirel...@vger.kernel.org and net...@vger.kernel.org mailing lists.
> You will get much more reviewers there.
>
> --> After major problems reported from community are fixed, I will try
> to apply patch against net-next as suggested by you. Lines longer than 80
> chars and avoiding module parameters would be checked at that time.
>
> Note: Once if a version is ready for release, I will add patch to
> https://github.com/kaloz/mwlwifi.
>
> Regards
> David
>
> -Original Message-
> From: Jiri Pirko [mailto:j...@resnulli.us]
> Sent: Thursday, January 01, 2015 2:55 AM
> To: David Lin
> Cc: openwrt-devel@lists.openwrt.org; Imre Kaloz
> Subject: Re: [OpenWrt-Devel] Announcement of mac80211 driver support for
> Marvell 88W8864 chip
>
> Wed, Dec 24, 2014 at 05:04:29PM CET, d...@marvell.com wrote:
> >Hi all,
> >
> >
> >
> >Marvell is pleased to announce this open source driver for the 88W8864 chip
> >as a joint effort with Linksys. The 88W8864 features 4x4 MIMO 3-spatial
> >Stream Dual-band 802.11ac enabling 1.3Gbps WLAN PHY rate and support for
> >80/40/20 MHz channel bandwidths. The 88W8864 is used in the Linksys
> >WRT1900AC and other products.
> >
> >
> >
> >Please note that this is an initial release and we plan to send the driver
> >upstream after cleanup.
> >
> >
> >
> >We do appreciate your feedback and look forward to serving the community
> >with exciting new offerings in the future!
>
>
> Hi.
>
> I took a very quick peek at the sources you sent.
>
> First I would like to thank you for taking the upstream way with this.
> Much appreciated.
>
> I would suggest you to develop your driver inside net-next git:
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/
>
> That would save you time during potential forward port need.
>
> Also, if you use scripts/checkpatch.pl script to check your patches, it will
> reveal many problems to you. The obvious one is lines longer than 80 chars.
>
> It is always nice to include all needed headers in all .c files. For example
> when you use skb_queue_head_init please include
>
> Spotted a comment typo in mwl_fwdl.c:
> "This file implements frimware downloa related functions"
>
> Drop comments like:
> /* PRIVATE FUNCTIO
Re: [OpenWrt-Devel] Announcement of mac80211 driver support for Marvell 88W8864 chip
On Mon, 2015-01-12 at 19:03 -0800, David Lin wrote:
> Hi Ian,
>
> 1. I will take off these additional blank lines.
> 2. I work for problems reported from community. If you do find problems
> for the driver, please let me know.
Thanks David.
I've posted an issue description at
https://github.com/kaloz/mwlwifi/issues along with the others but,
sadly, I suspect there's really not enough detailed information to work
with in these.
I'm still trying to work out how isr and tasklets work together and how
the locking works within them. I don't have experience with device
drivers since file systems are more my area, actually more the VFS than
anything, necessarily, as I'm the autofs maintainer, ;)
>
> Thanks
> David
>
> -Original Message-
> From: Ian Kent [mailto:ra...@themaw.net]
> Sent: Tuesday, January 13, 2015 10:41 AM
> To: David Lin
> Cc: Jiri Pirko; openwrt-devel@lists.openwrt.org; Imre Kaloz
> Subject: Re: [OpenWrt-Devel] Announcement of mac80211 driver support for
> Marvell 88W8864 chip
>
> Hi David,
>
> Please forgive the top posting.
>
> I don't think that the kernel programming style guidelines recommend against
> it and I also don't know if checkpatch.pl will complain about it but
> personally I find the additional blank lines in things like the below
> actually make the code harder to read:
>
> struct hostcmd_header {
>
> u16 cmd;
> u16 len;
> u8 seq_num;
> u8 macid;
> u16 result;
>
> } __packed;
>
> and
> if ((conf->chandef.width == NL80211_CHAN_WIDTH_20_NOHT) ||
> (conf->chandef.width == NL80211_CHAN_WIDTH_20)) {
>
> width = CH_20_MHz_WIDTH;
> sub_ch = NO_EXT_CHANNEL;
>
> } else if (conf->chandef.width == NL80211_CHAN_WIDTH_40) {
>
> Certainly we all have own own preferences about what is more readable for
> ourselves but please re-consider whether this really does aid readability.
>
> One other thing to consider about using checkpatch.pl is that the changes it
> reports are strongly recommended to be made, based on the kernel coding style
> guide, but if you feel strongly about some of the needed changes you can try
> and make a case for what you believe aids readability more so than the
> recommended changes.
>
> It might not be my place to ask but I'm having some problems with the driver.
> I've started to become familiar with the code and, after a while, may have
> some questions. This is likely to be a little tedious for you since mac80211
> and wireless is not my area in the kernel.
>
> Would you mind discussing them here on the list or would you rather me wait
> for the next update (don't feel obligated, I'll survive)?
>
> Ian
>
> On Sun, 2015-01-11 at 19:46 -0800, David Lin wrote:
> > Hi Jiri,
> >
> > It is always nice to include all needed headers in all .c files. For
> > example when you use skb_queue_head_init please include
> > Spotted a comment typo in mwl_fwdl.c:
> > "This file implements frimware downloa related functions"
> > "MODULE_" macros are usually placed by the end of file.
> >
> > --> Modifications should be included in next release.
> >
> > Drop comments like:
> > /* PRIVATE FUNCTION DEFINITION
> > */
> > Not needed.
> >
> > --> Unless it is really forbidden, I will keep this comment.
> >
> > I would suggest you to develop your driver inside net-next git:
> > http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/
> > That would save you time during potential forward port need.
> > Also, if you use scripts/checkpatch.pl script to check your patches, it
> > will reveal many problems to you. The obvious one is lines longer than 80
> > chars.
> > Module parameters should be always avoided if possible.
> > I suggest you make patch against net-next and send it on
> > linux-wirel...@vger.kernel.org and net...@vger.kernel.org mailing lists.
> > You will get much more reviewers there.
> >
> > --> After major problems reported from community are fixed, I will try
> > to apply patch against net-next as suggested by you. Lines longer than 80
> > chars and avoiding module parameters would be checked at that time.
> >
> > Note: Once if a version is ready for release, I will add patch to
> > https://github.com/kaloz/mwlwifi.
> >
> > Regards
> > David
> >
> > -Original Message-
> > From: Jiri Pirko [mailto:
[OpenWrt-Devel] [PATCH] mwlwifi - dont break fw upload timing with log prints
The patch included here is needed if debug logging in mwlwifi
is enabled to a high enough level that the log prints are done
during time critical parts of firmware loading.
Enabling debug logging is, unfortuneatly, not as simple as defining
MWLDBG on the module make command line.
Something like this is also needed:
diff --git a/mwl_debug.c b/mwl_debug.c
index 821b0c0..f8644a8 100644
--- a/mwl_debug.c
+++ b/mwl_debug.c
@@ -41,7 +41,7 @@
/* PRIVATE VARIABLES
*/
-static u32 dbg_levels = 0;
+static u32 dbg_levels = 0x;
/* PUBLIC FUNCTION DEFINITION
*/
or dbg_levels set to some suitable integer that enables the logging
required. But that's another story.
This change is meant to avoid the firmware loading problem if anyone
does use the logging, and that's all.
Signed-off-by: Ian Kent
---
...nt-break-fw-upload-timing-with-log-prints.patch | 82
1 file changed, 82 insertions(+)
create mode 100644
package/kernel/mwlwifi/patches/002-dont-break-fw-upload-timing-with-log-prints.patch
diff --git
a/package/kernel/mwlwifi/patches/002-dont-break-fw-upload-timing-with-log-prints.patch
b/package/kernel/mwlwifi/patches/002-dont-break-fw-upload-timing-with-log-prints.patch
new file mode 100644
index 000..e112606
--- /dev/null
+++
b/package/kernel/mwlwifi/patches/002-dont-break-fw-upload-timing-with-log-prints.patch
@@ -0,0 +1,82 @@
+mwlwifi - dont break fw upload timing with log prints
+
+From: Ian Kent
+
+In the function mwl_fwdl_download_firmware() there's a comment that it
+takes ~1300 nSec for the register change that acknowledges each chunk
+of the firmware uploaded. But if you take too long to get to the check
+you can miss the event altogether.
+
+The Function mwl_fwdl_trig_pcicmd_bootcode() contains log prints that
+can take several miliseconds to complete and it is called from the above
+function to transfer a chunk of the firmware at a time. When logging is
+enabled it breaks the firware upload.
+
+So remove the function call that uploads the chunk (and contains log prints)
+and add its code in-line to avoid inadvertantly breaking the firmware upload
+by enabling logging.
+
+Signed-off-by: Ian Kent
+---
+ mwl_fwdl.c | 29 ++---
+ 1 file changed, 10 insertions(+), 19 deletions(-)
+
+diff --git a/mwl_fwdl.c b/mwl_fwdl.c
+index 5f9ef91..46b61ed 100644
+--- a/mwl_fwdl.c
b/mwl_fwdl.c
+@@ -40,7 +40,6 @@
+ */
+
+ static void mwl_fwdl_trig_pcicmd(struct mwl_priv *priv);
+-static void mwl_fwdl_trig_pcicmd_bootcode(struct mwl_priv *priv);
+
+ /* PUBLIC FUNCTION DEFINITION
+ */
+@@ -99,9 +98,12 @@ int mwl_fwdl_download_firmware(struct ieee80211_hw *hw)
+ */
+ memcpy((char *)&priv->pcmd_buf[0], (fw->data +
size_fw_downloaded), len);
+
+- /* this function writes pdata to c10, then write 2 to c18
++ /* write pdata to c10, then write 2 to c18
+ */
+- mwl_fwdl_trig_pcicmd_bootcode(priv);
++ writel(priv->pphys_cmd_buf, priv->iobase1 + MACREG_REG_GEN_PTR);
++ writel(0x00, priv->iobase1 + MACREG_REG_INT_CODE);
++ writel(MACREG_H2ARIC_BIT_DOOR_BELL,
++ priv->iobase1 + MACREG_REG_H2A_INTERRUPT_EVENTS);
+
+ curr_iteration = FW_MAX_NUM_CHECKS; /* this is arbitrary per
your platform; we use 0x */
+
+@@ -110,6 +112,11 @@ int mwl_fwdl_download_firmware(struct ieee80211_hw *hw)
+* the write of event 2 to C1C == 2 is ~1300 nSec. Hence the
checkings on host
+* has to consider how efficient your code can be to meet this
timing, or you
+* can alternatively tweak this routines to fit your platform
++ *
++ * NOTE: not only does the register change take ~1300 nSec
++ * but if you take too long to get to the check below, such
++ * as issuing a printk() for logging, you can miss the event
++ * altogether.
+*/
+ do {
+
+@@ -201,19 +208,3 @@ static void mwl_fwdl_trig_pcicmd(struct mwl_priv *priv)
+
+ WLDBG_EXIT(DBG_LEVEL_1);
+ }
+-
+-static void mwl_fwdl_trig_pcicmd_bootcode(struct mwl_priv *priv)
+-{
+- WLDBG_ENTER(DBG_LEVEL_1);
+-
+- BUG_ON(!priv);
+-
+- writel(priv->pphys_cmd_buf, priv->iobase1 + MACREG_REG_GEN_PTR);
+-
+- writel(0x00, priv->iobase1 + MACREG_REG_INT_CODE);
+-
+- writel(MACREG_H2ARIC_BIT_DOOR_BELL,
+- priv->iobase1 + MACREG_REG_H2A_INTERRUPT_EVENTS);
+-
+- WLDBG_EXIT(DBG_LEVEL_1);
+-}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Announcement of mac80211 driver support for Marvell 88W8864 chip
On Mon, 2015-01-12 at 19:03 -0800, David Lin wrote: > Hi Ian, > > 1. I will take off these additional blank lines. > 2. I work for problems reported from community. If you do find problems > for the driver, please let me know. Hi David, I was disappointed to find that client mode wireless in the driver isn't supported yet. I logged an issue for it at https://github.com/kaloz/mwlwifi/issues/13 along with the kernel WARN() info. As I say in the issue I believe that client mode is quite important for the coming WRT1200AC, assuming the wireless on that device is to be supported by this driver. I've been looking at the driver source and I'm a bit puzzled about the rate and ht_sig2 fields in the receive descriptor structure. There's no documentation (that I can locate) on the interface to the wireless device so I can't refer to it. It appears the rate field isn't just a rate or an index into the rate table or just an MCS rate either. So can you describe what the encoding is please? The ht_sig2 field has a describing comment of "as the name suggests" but HT SIG 2 is 24 bits not 16 and even if the CRC and tail fields were discarded, I see there's more than the remaining 10 bits being used in the field. So can you describe the encoding in this field too please? The other puzzling thing is the handling of VHT modes. I don't see anything in the receive descriptor for that case. It looks like the wireless device handles the rate (along with a lot more) but how does the driver find out the VHT information that it may need for informational and reporting purposes (up to the mac80211 layer). Could you help with this please. These questions may sound like I don't know low level wireless concepts and that would be correct, but I'm slowly working on that, so sorry for the possibly silly questions. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Ethernet problem with R8000
Hi all, I'm trying to make progress on getting the Netgear R8000 to work. Basically it's a BCM4799 but with a BCM53012 switch rather than the usual BCM53011 (among other differences). I have a number of problems but the one that is the most concerning is that Ethernet doesn't work. Now, this is all quite new to me so I'm struggling and would appreciate some help. AFAICS the switch is matched in the various drivers so it appears to be supported to the extent that it's believed to function. The nvram claims sprom rev 11, I've added that (although I'm not sure it's done the way it should be) and it looks like the only things the bgmac driver needs from it are a couple of mac addresses and a phy address which it gets. But I have no Ethernet at all! The only things I can say for sure are, packets sent are seen by the bgmac driver and the driver gets a transmit completion interrupt which it processes. However, no packets is seen coming from the router switch port. Similarly no interrupts are seen by the driver for incoming packets at all. I have, to the extent that I can and not yet completely, worked through the GPL Broadcom source for the R8000 comparing the switch source to the bgmac driver (together with the spec at the sip solutions site) and I can't yet identify any significant differences. Also, again to the extent I can, I see what looks like should be in the registers for the first DMA channel and that changes as it should as packets are sent, channels 2-4, aren't really used yet by the look of it so I'm not sure inconsistencies in them matter, in any case it's the ring descriptor offset that appears incorrect. Can anyone offer any suggestions on how to work out what this problem is? Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ethernet problem with R8000
On Sat, 2015-02-28 at 23:07 +0800, Ian Kent wrote: > Hi all, > > I'm trying to make progress on getting the Netgear R8000 to work. > Basically it's a BCM4799 but with a BCM53012 switch rather than the > usual BCM53011 (among other differences). Obviously that's a BCM4709. > > I have a number of problems but the one that is the most concerning is > that Ethernet doesn't work. Maybe the original question is too hard and possibly to vague. How about a simpler question, there are 4 GBit devices listed at boot (id 04bf:082d). How do these devices relate to the physical ports on the router box, ie. which one is used for what, are they all used, how do I work out which is which? > > Now, this is all quite new to me so I'm struggling and would appreciate > some help. > > AFAICS the switch is matched in the various drivers so it appears to be > supported to the extent that it's believed to function. The nvram > claims sprom rev 11, I've added that (although I'm not sure it's done > the way it should be) and it looks like the only things the bgmac > driver needs from it are a couple of mac addresses and a phy address > which it gets. > > But I have no Ethernet at all! > > The only things I can say for sure are, packets sent are seen by the > bgmac driver and the driver gets a transmit completion interrupt which > it processes. However, no packets is seen coming from the router switch > port. Similarly no interrupts are seen by the driver for incoming > packets at all. > > I have, to the extent that I can and not yet completely, worked through > the GPL Broadcom source for the R8000 comparing the switch source to > the bgmac driver (together with the spec at the sip solutions site) and > I can't yet identify any significant differences. > > Also, again to the extent I can, I see what looks like should be in the > registers for the first DMA channel and that changes as it should as > packets are sent, channels 2-4, aren't really used yet by the look of > it so I'm not sure inconsistencies in them matter, in any case it's the > ring descriptor offset that appears incorrect. > > Can anyone offer any suggestions on how to work out what this problem > is? > > Ian > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ethernet problem with R8000
On Wed, 2015-03-04 at 10:29 +, Conor O'Gorman wrote: > On 04/03/15 05:29, Ian Kent wrote: > > On Sat, 2015-02-28 at 23:07 +0800, Ian Kent wrote: > >> The only things I can say for sure are, packets sent are seen by the > >> bgmac driver and the driver gets a transmit completion interrupt which > >> it processes. However, no packets is seen coming from the router switch > >> port. Similarly no interrupts are seen by the driver for incoming > >> packets at all. Thanks for giving this some thought. > > Can you access switch chip registers? Reckon so. This device uses the bgmac driver. What I've looked at so far is the DMA state and error registers and how the Descriptor stop index (last posted descriptor for transmit, etc) registers change for the DMA controller transmit and receive queues (see below link). I've also done some printks to check some key values in the driver and that looks ok too. All looks as it should in that no error bits are set and the status register shows the transmit and receive functions are enabled and AFAICS the magic to poke the DMA engine is being done as it should. It's puzzling. Truth is I can't find anything that looks even a little wrong comparing it to the router GPL source code and the brcmfmac DMA code referenced in the link blow. It's even stranger that network packets pass through the router when I have a machine plugged into a port and into the network on another port, just nothing ever passes from the router to the network and visa versa. > > There may be counters in there, that will indicate if packets are making > it that far, in or out. You may see counters indicating errors. You > might be able to work out the arangement of ports from that info. > You may have to configure some of the switch registers to get the > correct arrangement of the ports and/or vlan settings. Haven't seen counters as such. There are a bunch of counters listed in the b53 switch driver (mib entries, but I haven't checked the device registers actually hold these values) that essentially reflect what I'm seeing but don't offer much else. It would be good if someone could identify devices using bcm53xx that are known to work and, if available point to a boot log. And in case anyone is interested my most recent R8000 boot log is here: https://www.dropbox.com/s/jx8d771fcu22dcz/debug-3.txt?dl=0 But there are a bunch of other registers, maybe I should go hunting I'm working from this http://bcm-v4.sipsolutions.net/mac-gbit/Registers and this for the DMA http://bcm-v4.sipsolutions.net/802.11/DMA#A64_Bit_DMA. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/6] bcm53xx - changes for R8000 so far
Here are some changes done while working to get the R8000 working. Some are straight forward while some require review. I'm not sure if I've done the sprom rev 11 change the way it should be done so that needs fairly close review. I thought about making a seperate driver for the the PEX8603 in the R8000 but believe the way it's done here (along the lines of the router GPL release code) is the better choice for the moment. It's a specific device in a single router (at the moment) and is used as a bridge to allow connecting the two 5Ghz radios. Possibly it was designed ths way for production cost reasons since it probably could have benn done in a more sensible way (such as using the unused PCIe device). Anyway, feedback welcome. --- Ian Kent (6): bcm53xx - fixup early device id 8012 bcm53xx - fix typo in bcm47xx sprom driver bcm53xx - update sprom from nvram to handle rev 11 bcm53xx - increase nvram allocation size to 64k bcm53xx - deal with R8000 mac address settings bcm5301x - R8000 handle PEX8603 switch .../bcm53xx/files/drivers/misc/bcm47xx-sprom.c |2 .../111-bcm53xx-add-sprom-rev-11-vars.patch| 426 ...3xx-increase-nvram-allocation-size-to-64k.patch | 19 + ...53xx-deal-with-R8000-mac-address-settings.patch | 83 .../171-bcm5301x-fixup-early-device-id-8012.patch | 26 + .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225 ++ .../111-bcm53xx-add-sprom-rev-11-vars.patch| 432 ...3xx-increase-nvram-allocation-size-to-64k.patch | 20 + ...53xx-deal-with-R8000-mac-address-settings.patch | 83 .../171-bcm5301x-fixup-early-device-id-8012.patch | 26 + .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225 ++ 11 files changed, 1566 insertions(+), 1 deletion(-) create mode 100644 target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch create mode 100644 target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch create mode 100644 target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch create mode 100644 target/linux/bcm53xx/patches-3.14/171-bcm5301x-fixup-early-device-id-8012.patch create mode 100644 target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch create mode 100644 target/linux/bcm53xx/patches-3.18/111-bcm53xx-add-sprom-rev-11-vars.patch create mode 100644 target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch create mode 100644 target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch create mode 100644 target/linux/bcm53xx/patches-3.18/171-bcm5301x-fixup-early-device-id-8012.patch create mode 100644 target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch -- Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/6] bcm53xx - fixup early device id 8012
Looks like the BCM53012 has a similar problem to the BCM53011. Signed-off-by: Ian Kent --- .../171-bcm5301x-fixup-early-device-id-8012.patch | 26 .../171-bcm5301x-fixup-early-device-id-8012.patch | 26 2 files changed, 52 insertions(+) create mode 100644 target/linux/bcm53xx/patches-3.14/171-bcm5301x-fixup-early-device-id-8012.patch create mode 100644 target/linux/bcm53xx/patches-3.18/171-bcm5301x-fixup-early-device-id-8012.patch diff --git a/target/linux/bcm53xx/patches-3.14/171-bcm5301x-fixup-early-device-id-8012.patch b/target/linux/bcm53xx/patches-3.14/171-bcm5301x-fixup-early-device-id-8012.patch new file mode 100644 index 000..10168a1 --- /dev/null +++ b/target/linux/bcm53xx/patches-3.14/171-bcm5301x-fixup-early-device-id-8012.patch @@ -0,0 +1,26 @@ +bcm5301x - fixup early device id 8012 + +From: Ian Kent + +It appears the BCM53012 has a similar problem to the BCM53011. + +If the top 24 bits of the dev->class field isn't PCI_CLASS_BRIDGE_PCI +the kernel will not do the bridge setup. + +Signed-off-by: Ian Kent +--- + drivers/pci/host/pci-host-bcm5301x.c |1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/pci/host/pci-host-bcm5301x.c b/drivers/pci/host/pci-host-bcm5301x.c +index d47405c..1a10622 100644 +--- a/drivers/pci/host/pci-host-bcm5301x.c b/drivers/pci/host/pci-host-bcm5301x.c +@@ -145,6 +145,7 @@ static void bcma_pcie2_fixup_class(struct pci_dev *dev) + dev->class = PCI_CLASS_BRIDGE_PCI << 8; + } + DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8011, bcma_pcie2_fixup_class); ++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8012, bcma_pcie2_fixup_class); + + /* + * Check link status, return 0 if link is up in RC mode, diff --git a/target/linux/bcm53xx/patches-3.18/171-bcm5301x-fixup-early-device-id-8012.patch b/target/linux/bcm53xx/patches-3.18/171-bcm5301x-fixup-early-device-id-8012.patch new file mode 100644 index 000..10168a1 --- /dev/null +++ b/target/linux/bcm53xx/patches-3.18/171-bcm5301x-fixup-early-device-id-8012.patch @@ -0,0 +1,26 @@ +bcm5301x - fixup early device id 8012 + +From: Ian Kent + +It appears the BCM53012 has a similar problem to the BCM53011. + +If the top 24 bits of the dev->class field isn't PCI_CLASS_BRIDGE_PCI +the kernel will not do the bridge setup. + +Signed-off-by: Ian Kent +--- + drivers/pci/host/pci-host-bcm5301x.c |1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/pci/host/pci-host-bcm5301x.c b/drivers/pci/host/pci-host-bcm5301x.c +index d47405c..1a10622 100644 +--- a/drivers/pci/host/pci-host-bcm5301x.c b/drivers/pci/host/pci-host-bcm5301x.c +@@ -145,6 +145,7 @@ static void bcma_pcie2_fixup_class(struct pci_dev *dev) + dev->class = PCI_CLASS_BRIDGE_PCI << 8; + } + DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8011, bcma_pcie2_fixup_class); ++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8012, bcma_pcie2_fixup_class); + + /* + * Check link status, return 0 if link is up in RC mode, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/6] bcm53xx - fix typo in bcm47xx sprom driver
Fix thinko' in the bcm47xx sprom driver.
Signed-off-by: Ian Kent
---
.../bcm53xx/files/drivers/misc/bcm47xx-sprom.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/bcm53xx/files/drivers/misc/bcm47xx-sprom.c
b/target/linux/bcm53xx/files/drivers/misc/bcm47xx-sprom.c
index a82728d..3c5d58f 100644
--- a/target/linux/bcm53xx/files/drivers/misc/bcm47xx-sprom.c
+++ b/target/linux/bcm53xx/files/drivers/misc/bcm47xx-sprom.c
@@ -734,7 +734,7 @@ static const struct of_device_id
bcm47xx_sprom_of_match_table[] = {
{ .compatible = "brcm,bcm47xx-sprom", },
{},
};
-MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
+MODULE_DEVICE_TABLE(of, bcm47xx_sprom_of_match_table);
static struct platform_driver bcm47xx_sprom_driver = {
.driver = {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/6] bcm53xx - update sprom from nvram to handle rev 11
Add new sprom revision 11 variables to the nvram -> sprom reader.
Signed-off-by: Ian Kent
---
.../111-bcm53xx-add-sprom-rev-11-vars.patch| 426
.../111-bcm53xx-add-sprom-rev-11-vars.patch| 432
2 files changed, 858 insertions(+)
create mode 100644
target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch
create mode 100644
target/linux/bcm53xx/patches-3.18/111-bcm53xx-add-sprom-rev-11-vars.patch
diff --git
a/target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch
b/target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch
new file mode 100644
index 000..463c8b9
--- /dev/null
+++ b/target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch
@@ -0,0 +1,426 @@
+bcm53xx - add sprom rev 11 vars
+
+From: Ian Kent
+
+Up date bcm47xx-sprom.c to read new sprom revision 11 variables.
+
+Signed-off-by: Ian Kent
+--- a/drivers/bcma/sprom.c
b/drivers/bcma/sprom.c
+@@ -165,7 +165,7 @@ static int bcma_sprom_valid(struct bcma_
+ return err;
+
+ revision = sprom[words - 1] & SSB_SPROM_REVISION_REV;
+- if (revision != 8 && revision != 9 && revision != 10) {
++ if (revision < 8 || revision > 11) {
+ pr_err("Unsupported SPROM revision: %d\n", revision);
+ return -ENOENT;
+ }
+--- a/drivers/misc/bcm47xx-sprom.c
b/drivers/misc/bcm47xx-sprom.c
+@@ -187,6 +187,30 @@ static void nvram_read_alpha2(const stru
+ memcpy(val, buf, 2);
+ }
+
++static void nvram_read_string(const struct bcm47xx_sprom_fill *fill,
++const char *name, char *val, unsigned int len)
++{
++ char buf[121];
++ int err;
++
++ *val = '\0';
++
++ if (len > 120)
++ return;
++
++ memset(buf, 0, 121);
++ err = get_nvram_var(fill, NULL, name, buf, sizeof(buf) - 1);
++ if (err < 0)
++ return;
++ if (buf[0] == '0')
++ return;
++ if (buf[120] != '\0') {
++ pr_warn("string is too long %s\n", buf);
++ return;
++ }
++ strcpy(val, buf);
++}
++
+ static void bcm47xx_sprom_fill_r1234589(struct ssb_sprom *sprom,
+ const struct bcm47xx_sprom_fill *fill)
+ {
+@@ -439,6 +463,63 @@ static void bcm47xx_sprom_fill_r9(struct
+ nvram_read_u8(fill, NULL, "sar5g", &sprom->sar5g, 0);
+ }
+
++static void bcm47xx_sprom_fill_r11(struct ssb_sprom *sprom,
++ const struct bcm47xx_sprom_fill *fill)
++{
++ nvram_read_u8(fill, NULL, "agbg0", &sprom->agbg0, 0);
++ nvram_read_u8(fill, NULL, "agbg1", &sprom->agbg1, 0);
++ nvram_read_u8(fill, NULL, "agbg2", &sprom->agbg2, 0);
++ nvram_read_u8(fill, NULL, "aga0", &sprom->aga0, 0);
++ nvram_read_u8(fill, NULL, "aga1", &sprom->aga1, 0);
++ nvram_read_u8(fill, NULL, "aga2", &sprom->aga2, 0);
++ nvram_read_u8(fill, NULL, "tssiposslope2g", &sprom->tssiposslope2g, 0);
++ nvram_read_u8(fill, NULL, "epagain2g", &sprom->epagain2g, 0);
++ nvram_read_u8(fill, NULL, "pdgain2g", &sprom->pdgain2g, 0);
++ nvram_read_u8(fill, NULL, "tworangetssi2g", &sprom->tworangetssi2g, 0);
++ nvram_read_u8(fill, NULL, "papdcap2g", &sprom->papdcap2g, 0);
++ nvram_read_u8(fill, NULL, "femctrl", &sprom->femctrl, 0);
++ nvram_read_u8(fill, NULL, "tssiposslope5g", &sprom->tssiposslope5g, 0);
++ nvram_read_u8(fill, NULL, "epagain5g", &sprom->epagain5g, 0);
++ nvram_read_u8(fill, NULL, "pdgain5g", &sprom->pdgain5g, 0);
++ nvram_read_u8(fill, NULL, "tworangetssi5g", &sprom->tworangetssi5g, 0);
++ nvram_read_u8(fill, NULL, "papdcap5g", &sprom->papdcap5g, 0);
++ nvram_read_u8(fill, NULL, "gainctrlsph", &sprom->gainctrlsph, 0);
++ nvram_read_u16(fill, NULL, "pdoffset40ma0", &sprom->pdoffset40ma0, 0);
++ nvram_read_u16(fill, NULL, "pdoffset40ma1", &sprom->pdoffset40ma1, 0);
++ nvram_read_u16(fill, NULL, "pdoffset40ma2", &sprom->pdoffset40ma2, 0);
++ nvram_read_u16(fill, NULL, "pdoffset80ma0", &sprom->pdoffset80ma0, 0);
++ nvram_read_u16(fill, NULL, "pdoffset80ma1", &sprom->pdoffset80ma1, 0);
++ nvram_read_u16(fill, NULL, "pdoffset80ma2", &sprom->pdoffset80ma2, 0);
++ nvram_read_u16(fill, NULL, "dot11agofdmhrbw202gpo",
&sprom->dot11agofdmhrbw202gpo, 0);
++ nvram_read_u16(fill, NULL, "ofdmlrbw202gpo",
[OpenWrt-Devel] [PATCH 4/6] bcm53xx - increase nvram allocation size to 64k
The R8000 nvram is larger than 32k, increase nvram allocation to 64k to accomadate. --- ...3xx-increase-nvram-allocation-size-to-64k.patch | 19 +++ ...3xx-increase-nvram-allocation-size-to-64k.patch | 20 2 files changed, 39 insertions(+) create mode 100644 target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch create mode 100644 target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch diff --git a/target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch b/target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch new file mode 100644 index 000..a063fb6 --- /dev/null +++ b/target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch @@ -0,0 +1,19 @@ +bcm53xx - increase nvram allocation size to 64k + +The R8000 nvram is too large for the 32k allocation size in +bcm47xx_nvram.c. + +Increase the allocation size to 64k. + +Signed-off-by: Ian Kent +--- a/drivers/firmware/broadcom/bcm47xx_nvram.c b/drivers/firmware/broadcom/bcm47xx_nvram.c +@@ -20,7 +20,7 @@ + #include + + #define NVRAM_MAGIC 0x48534C46 /* 'FLSH' */ +-#define NVRAM_SPACE 0x8000 ++#define NVRAM_SPACE 0x1 + #define NVRAM_MAX_GPIO_ENTRIES32 + #define NVRAM_MAX_GPIO_VALUE_LEN 30 + diff --git a/target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch b/target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch new file mode 100644 index 000..29c91a6 --- /dev/null +++ b/target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch @@ -0,0 +1,20 @@ +bcm53xx - increase nvram allocation size to 64k + +The R8000 nvram is too large for the 32k allocation size in +bcm47xx_nvram.c. + +Increase the allocation size to 64k. + +Signed-off-by: Ian Kent + +--- a/drivers/firmware/broadcom/bcm47xx_nvram.c b/drivers/firmware/broadcom/bcm47xx_nvram.c +@@ -20,7 +20,7 @@ + #include + + #define NVRAM_MAGIC 0x48534C46 /* 'FLSH' */ +-#define NVRAM_SPACE 0x8000 ++#define NVRAM_SPACE 0x1 + #define NVRAM_MAX_GPIO_ENTRIES32 + #define NVRAM_MAX_GPIO_VALUE_LEN 30 + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 5/6] bcm53xx - deal with R8000 mac address settings
After a vendor firmware install the values seen in nvram for et0macaddr
and et1macaddr are that of nvram macaddr and nvram macaddr+1.
So set them that way here too.
Signed-off-by: Ian Kent
---
...53xx-deal-with-R8000-mac-address-settings.patch | 83
...53xx-deal-with-R8000-mac-address-settings.patch | 83
2 files changed, 166 insertions(+)
create mode 100644
target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
create mode 100644
target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
diff --git
a/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
new file mode 100644
index 000..68835b5
--- /dev/null
+++
b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
@@ -0,0 +1,83 @@
+bcm53xx - deal with R8000 mac address settings
+
+The R8000 ends up with et0macaddr and et1macaddr nvram values being all
+zeros with the et*mdcport and et*phyaddr set to the expected values.
+
+The values seen in the nvram after a vendor firmware install are
+et0macaddr and et2macaddr set to the value of macaddr and et1macaddr
+set to macaddr+1.
+
+But after an nvram erase only et2macaddr has a value, so if et0macaddr
+is all zeros use et2macaddr to set et0macaddr and et1macaddr.
+
+Signed-off-by: Ian Kent
+--- a/drivers/misc/bcm47xx-sprom.c
b/drivers/misc/bcm47xx-sprom.c
+@@ -734,6 +734,24 @@ static void bcm47xx_sprom_fill_path_r11(
+ }
+ }
+
++static bool bcm47xx_is_zero_mac(u8 *mac)
++{
++ bool res = 1;
++ int i;
++
++ if (!mac)
++ goto out;
++
++ for (i = 5; i >= 0; i--) {
++ if (mac[i]) {
++ res = 0;
++ break;
++ }
++ }
++out:
++ return res;
++}
++
+ static bool bcm47xx_is_valid_mac(u8 *mac)
+ {
+ return mac && !(mac[0] == 0x00 && mac[1] == 0x90 && mac[2] == 0x4c);
+@@ -780,6 +798,42 @@ static void bcm47xx_sprom_fill_ethernet(
+ nvram_read_macaddr(fill, "il0macaddr", sprom->il0mac);
+
+ /*
++ * The R8000 ends up with et0macaddr and et1macaddr nvram values
++ * being all zeros with the et*mdcport and et*phyaddr set to the
++ * expected values. The values seen in the nvram after a vendor
++ * firmware install are et0macaddr set to the value of macaddr
++ * and et1macaddr set to macaddr+1. But after an nvram erase only
++ * et2macaddr has a value, so if et0macaddr is all zeros use
++ * et2macaddr to set et0macaddr and et1macaddr.
++ *
++ * Note: il0macaddr is also the same as macaddr following a vendor
++ * install and the key doesn't exist at all after an nvram erase,
++ * so sprom->il0mac may need to cwbe calculated as well.
++ */
++ if (bcm47xx_is_zero_mac(sprom->et0mac)) {
++ struct bcm47xx_sprom_fill fill_no_prefix;
++ u8 mac[6];
++
++ memcpy(&fill_no_prefix, fill, sizeof(fill_no_prefix));
++ fill_no_prefix.prefix = NULL;
++
++ nvram_read_macaddr(&fill_no_prefix, "et2macaddr", mac);
++
++ if (bcm47xx_is_valid_mac(mac) && !bcm47xx_is_zero_mac(mac)) {
++ int err;
++
++ ether_addr_copy(sprom->et0mac, mac);
++
++ err = bcm47xx_increase_mac_addr(mac, 1);
++ if (!err) {
++ ether_addr_copy(sprom->et1mac, mac);
++ /* don't change mac_addr_used so below
++ * will behave as expected, if needed */
++ }
++ }
++ }
++
++ /*
+* The address prefix 00:90:4C is used by Broadcom in their initial
+* configuration. When a mac address with the prefix 00:90:4C is used
+* all devices from the same series are sharing the same mac address.
diff --git
a/target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
b/target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
new file mode 100644
index 000..68835b5
--- /dev/null
+++
b/target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
@@ -0,0 +1,83 @@
+bcm53xx - deal with R8000 mac address settings
+
+The R8000 ends up with et0macaddr and et1macaddr nvram values being all
+zeros with the et*mdcport and et*phyaddr set to the expected values.
+
+The values seen in the nvram after a vendor firmware install are
+et0macaddr and et2macaddr set to the value of macaddr and et1macaddr
+set to macaddr+1.
+
+But after an nvram erase only et2macaddr has a value, so if et0macaddr
+is all zeros use et2macaddr t
[OpenWrt-Devel] [PATCH 6/6] bcm5301x - R8000 handle PEX8603 switch
The Netgear R8000 has a PEX8603 connected to the BCM53012 and if
it isn't configured during the bus scan the PCI layer goes crazy
trying to configure phantom devices.
---
.../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
.../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
2 files changed, 450 insertions(+)
create mode 100644
target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
create mode 100644
target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
diff --git
a/target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
b/target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
new file mode 100644
index 000..e321845
--- /dev/null
+++
b/target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
@@ -0,0 +1,225 @@
+bcm5301x - R8000 handle PEX8603 switch
+
+The Netgear R8000 has a PEX8603 which, if not configured at
+bus probe results in quite a few phantom devices as it doesn't
+respond properly to configuration requests. The device needs
+to be configured when seen.
+
+Signed-off-by: Ian Kent
+
+--- a/drivers/pci/host/pci-host-bcm5301x.c
b/drivers/pci/host/pci-host-bcm5301x.c
+@@ -29,6 +29,21 @@
+ #define PCI_TARGET_LINK_SPEED_GEN20x2
+ #define PCI_TARGET_LINK_SPEED_GEN10x1
+
++#define PCI_MAX_BUS 4
++#define PLX_PRIM_SEC_BUS_NUM (0x0201 | (PCI_MAX_BUS << 16))
++
++#ifndef SZ_48M
++#define SZ_48M(SZ_32M + SZ_16M)
++#endif
++
++struct pex86xx_info {
++ u8 busno; /* Upstream bus PEX is on */
++ u8 slot;/* Upstream slot PEX is at */
++ u16 active; /* Active port count */
++ u16 ports; /* Active port bit map */
++};
++struct pex86xx_info pex8603;
++
+ static int bcma_pcie2_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
+ {
+ struct pci_sys_data *sys = pdev->sysdata;
+@@ -115,6 +130,39 @@ static int bcma_pcie2_read_config_pci(st
+ struct pci_sys_data *sys = bus->sysdata;
+ struct bcma_device *bdev = sys->private_data;
+
++ /* The PEX8603 won't return sensible values to the PCI layer so
++ * we have to do that ourselves.
++ */
++ if (pex8603.busno) {
++ u16 slot = PCI_SLOT(devfn);
++
++ /* Not the PEX upstream slot */
++ if (pex8603.busno == bus->number && pex8603.slot != slot)
++ goto done;
++
++ /* Not the PEX downstream bus? */
++ if (bus->number < pex8603.busno ||
++ bus->number > pex8603.busno + 1)
++ goto done;
++
++ switch (bus->number - pex8603.busno) {
++ case 0:
++ /* Upstream port */
++ break;
++
++ case 1:
++ /* PEX8603, not present for slots other than 1 or 2 */
++ if (!(slot == 1 || slot == 2)) {
++ *val = 0x;
++ return PCIBIOS_SUCCESSFUL;
++ }
++ break;
++
++ default:
++ break;
++ }
++ }
++done:
+ *val = bcma_pcie2_read_config(bdev, bus->number, devfn, where, size);
+
+ return PCIBIOS_SUCCESSFUL;
+@@ -126,6 +174,37 @@ static int bcma_pcie2_write_config_pci(s
+ struct pci_sys_data *sys = bus->sysdata;
+ struct bcma_device *bdev = sys->private_data;
+
++ /* Don't try and set anything on the PEX8603 if it isn't
++ * valid.
++ */
++ if (pex8603.busno) {
++ u16 slot = PCI_SLOT(devfn);
++
++ /* Not the PEX upstream slot */
++ if (pex8603.busno == bus->number && pex8603.slot != slot)
++ goto done;
++
++ /* Not the PEX downstream bus? */
++ if (bus->number < pex8603.busno ||
++ bus->number > pex8603.busno + 1)
++ goto done;
++
++ switch (bus->number - pex8603.busno) {
++ case 0:
++ /* Upstream port */
++ break;
++
++ case 1:
++ /* PEX8603 slots only slots 1 and 2 present */
++ if (!(slot == 1 || slot == 2))
++ return PCIBIOS_SUCCESSFUL;
++ break;
++
++ default:
++ break;
++ }
++ }
++done:
+ bcma_pcie2_write_config(bdev, bus->number, devfn, where, size, val);
+
+ return PCIBIOS_SUCCESSFUL;
+@@ -147,6 +226,113 @@ static void bcma_pcie2_fixup_class(struc
+ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8011,
bcma_pcie2_fixup_class);
+ DECLARE_PCI_FIXUP_EARLY(PCI_V
Re: [OpenWrt-Devel] [PATCH 1/6] bcm53xx - fixup early device id 8012
On Mon, 2015-03-09 at 10:23 +0100, Rafał Miłecki wrote: > On 9 March 2015 at 10:08, Ian Kent wrote: > > Looks like the BCM53012 has a similar problem to the BCM53011. > > Change looks OK, however I'd prefer you to simply modify existing > patch 170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch > > It still wasn't included/accepted mainline, so it's safe to update it > without loosing any changes when submitting it upstream. I also don't > think there is much point in having a single-line 171 patch. Sure, will do. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] bcm53xx - changes for R8000 so far
On Mon, 2015-03-09 at 10:28 +0100, Rafał Miłecki wrote: > On 9 March 2015 at 10:21, Rafał Miłecki wrote: > > On 9 March 2015 at 10:08, Ian Kent wrote: > >> Here are some changes done while working to get the R8000 working. > >> Some are straight forward while some require review. > > > > Thanks :) > > > > One request: please use "bcm53xx: " prefix, as it's what we do since always. > > > > I'll try to reply to all patches as I find a moment. > > Please sign-off-by every single patch. Umm, must have made a mistake, thought I did, I'll check and fix. Can you mention which patches need to be reposted (or perhaps all, ;)) as you go please. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/6] Series short description
The following series implements... --- Ian Kent (6): bcm53xx: fixup early device id 8012 bcm53xx: fix typo in bcm47xx sprom driver bcm53xx: update sprom from nvram to handle rev 11 bcm53xx - increase nvram allocation size to 64k bcm53xx: deal with R8000 mac address settings bcm53xx: R8000 handle PEX8603 switch .../bcm53xx/files/drivers/misc/bcm47xx-sprom.c |2 .../111-bcm53xx-add-sprom-rev-11-vars.patch| 426 ...3xx-increase-nvram-allocation-size-to-64k.patch | 19 + ...53xx-deal-with-R8000-mac-address-settings.patch | 83 ...-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch | 12 + .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225 ++ .../111-bcm53xx-add-sprom-rev-11-vars.patch| 432 ...3xx-increase-nvram-allocation-size-to-64k.patch | 20 + ...53xx-deal-with-R8000-mac-address-settings.patch | 83 ...-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch | 12 + .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225 ++ 11 files changed, 1536 insertions(+), 3 deletions(-) create mode 100644 target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch create mode 100644 target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch create mode 100644 target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch create mode 100644 target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch create mode 100644 target/linux/bcm53xx/patches-3.18/111-bcm53xx-add-sprom-rev-11-vars.patch create mode 100644 target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch create mode 100644 target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch create mode 100644 target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch -- Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far
Rather than struggle working out what needs what I thought it better to update and resend with the few changes you recommended so we can work from there. --- Ian Kent (6): bcm53xx: fixup early device id 8012 bcm53xx: fix typo in bcm47xx sprom driver bcm53xx: update sprom from nvram to handle rev 11 bcm53xx: increase nvram allocation size to 64k bcm53xx: deal with R8000 mac address settings bcm53xx: R8000 handle PEX8603 switch .../bcm53xx/files/drivers/misc/bcm47xx-sprom.c |2 .../111-bcm53xx-add-sprom-rev-11-vars.patch| 426 ...3xx-increase-nvram-allocation-size-to-64k.patch | 19 + ...53xx-deal-with-R8000-mac-address-settings.patch | 83 ...-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch | 12 + .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225 ++ .../111-bcm53xx-add-sprom-rev-11-vars.patch| 432 ...3xx-increase-nvram-allocation-size-to-64k.patch | 20 + ...53xx-deal-with-R8000-mac-address-settings.patch | 83 ...-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch | 12 + .../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225 ++ 11 files changed, 1536 insertions(+), 3 deletions(-) create mode 100644 target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch create mode 100644 target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch create mode 100644 target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch create mode 100644 target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch create mode 100644 target/linux/bcm53xx/patches-3.18/111-bcm53xx-add-sprom-rev-11-vars.patch create mode 100644 target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch create mode 100644 target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch create mode 100644 target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch -- Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/6] bcm53xx: fixup early device id 8012
Looks like the BCM53012 has a similar problem to the BCM53011. Signed-off-by: Ian Kent --- ...-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch | 12 +++- ...-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch | 12 +++- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/target/linux/bcm53xx/patches-3.14/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch b/target/linux/bcm53xx/patches-3.14/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch index e963133..4e2e59e 100644 --- a/target/linux/bcm53xx/patches-3.14/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch +++ b/target/linux/bcm53xx/patches-3.14/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch @@ -30,7 +30,16 @@ to remove the call to pci_bus_add_devices() in pci_scan_root_bus() to make registration work, calling pci_bus_add_devices() later again does not fix this problem. +edit: imk +It appears the BCM53012 has a similar problem to the BCM53011. + +If the top 24 bits of the dev->class field isn't PCI_CLASS_BRIDGE_PCI +the kernel will not do the bridge setup so add an early fixup for it +too. +end edit: imk + Signed-off-by: Hauke Mehrtens +Signed-off-by: Ian Kent --- arch/arm/mach-bcm/Kconfig| 1 + drivers/pci/host/Kconfig | 7 + @@ -72,7 +81,7 @@ Signed-off-by: Hauke Mehrtens +obj-$(CONFIG_PCI_BCM5301X) += pci-host-bcm5301x.o --- /dev/null +++ b/drivers/pci/host/pci-host-bcm5301x.c -@@ -0,0 +1,459 @@ +@@ -0,0 +1,460 @@ +/* + * Northstar PCI-Express driver + * Only supports Root-Complex (RC) mode @@ -220,6 +229,7 @@ Signed-off-by: Hauke Mehrtens + dev->class = PCI_CLASS_BRIDGE_PCI << 8; +} +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8011, bcma_pcie2_fixup_class); ++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8012, bcma_pcie2_fixup_class); + +/* + * Check link status, return 0 if link is up in RC mode, diff --git a/target/linux/bcm53xx/patches-3.18/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch b/target/linux/bcm53xx/patches-3.18/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch index 1a84604..94fdea1 100644 --- a/target/linux/bcm53xx/patches-3.18/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch +++ b/target/linux/bcm53xx/patches-3.18/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch @@ -30,7 +30,16 @@ to remove the call to pci_bus_add_devices() in pci_scan_root_bus() to make registration work, calling pci_bus_add_devices() later again does not fix this problem. +edit: imk +It appears the BCM53012 has a similar problem to the BCM53011. + +If the top 24 bits of the dev->class field isn't PCI_CLASS_BRIDGE_PCI +the kernel will not do the bridge setup so add an early fixup for it +too. +end edit: imk + Signed-off-by: Hauke Mehrtens +Signed-off-by: Ian Kent --- arch/arm/mach-bcm/Kconfig| 1 + drivers/pci/host/Kconfig | 7 + @@ -72,7 +81,7 @@ Signed-off-by: Hauke Mehrtens +obj-$(CONFIG_PCI_BCM5301X) += pci-host-bcm5301x.o --- /dev/null +++ b/drivers/pci/host/pci-host-bcm5301x.c -@@ -0,0 +1,459 @@ +@@ -0,0 +1,460 @@ +/* + * Northstar PCI-Express driver + * Only supports Root-Complex (RC) mode @@ -220,6 +229,7 @@ Signed-off-by: Hauke Mehrtens + dev->class = PCI_CLASS_BRIDGE_PCI << 8; +} +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8011, bcma_pcie2_fixup_class); ++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8012, bcma_pcie2_fixup_class); + +/* + * Check link status, return 0 if link is up in RC mode, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/6] bcm53xx: fix typo in bcm47xx sprom driver
Fix thinko' in the bcm47xx sprom driver.
Signed-off-by: Ian Kent
---
.../bcm53xx/files/drivers/misc/bcm47xx-sprom.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/bcm53xx/files/drivers/misc/bcm47xx-sprom.c
b/target/linux/bcm53xx/files/drivers/misc/bcm47xx-sprom.c
index a82728d..3c5d58f 100644
--- a/target/linux/bcm53xx/files/drivers/misc/bcm47xx-sprom.c
+++ b/target/linux/bcm53xx/files/drivers/misc/bcm47xx-sprom.c
@@ -734,7 +734,7 @@ static const struct of_device_id
bcm47xx_sprom_of_match_table[] = {
{ .compatible = "brcm,bcm47xx-sprom", },
{},
};
-MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
+MODULE_DEVICE_TABLE(of, bcm47xx_sprom_of_match_table);
static struct platform_driver bcm47xx_sprom_driver = {
.driver = {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/6] bcm53xx: update sprom from nvram to handle rev 11
Add new sprom revision 11 variables to the nvram -> sprom reader.
Signed-off-by: Ian Kent
---
.../111-bcm53xx-add-sprom-rev-11-vars.patch| 426
.../111-bcm53xx-add-sprom-rev-11-vars.patch| 432
2 files changed, 858 insertions(+)
create mode 100644
target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch
create mode 100644
target/linux/bcm53xx/patches-3.18/111-bcm53xx-add-sprom-rev-11-vars.patch
diff --git
a/target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch
b/target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch
new file mode 100644
index 000..742ab65
--- /dev/null
+++ b/target/linux/bcm53xx/patches-3.14/111-bcm53xx-add-sprom-rev-11-vars.patch
@@ -0,0 +1,426 @@
+bcm53xx: add sprom rev 11 vars
+
+From: Ian Kent
+
+Up date bcm47xx-sprom.c to read new sprom revision 11 variables.
+
+Signed-off-by: Ian Kent
+--- a/drivers/bcma/sprom.c
b/drivers/bcma/sprom.c
+@@ -165,7 +165,7 @@ static int bcma_sprom_valid(struct bcma_
+ return err;
+
+ revision = sprom[words - 1] & SSB_SPROM_REVISION_REV;
+- if (revision != 8 && revision != 9 && revision != 10) {
++ if (revision < 8 || revision > 11) {
+ pr_err("Unsupported SPROM revision: %d\n", revision);
+ return -ENOENT;
+ }
+--- a/drivers/misc/bcm47xx-sprom.c
b/drivers/misc/bcm47xx-sprom.c
+@@ -187,6 +187,30 @@ static void nvram_read_alpha2(const stru
+ memcpy(val, buf, 2);
+ }
+
++static void nvram_read_string(const struct bcm47xx_sprom_fill *fill,
++const char *name, char *val, unsigned int len)
++{
++ char buf[121];
++ int err;
++
++ *val = '\0';
++
++ if (len > 120)
++ return;
++
++ memset(buf, 0, 121);
++ err = get_nvram_var(fill, NULL, name, buf, sizeof(buf) - 1);
++ if (err < 0)
++ return;
++ if (buf[0] == '0')
++ return;
++ if (buf[120] != '\0') {
++ pr_warn("string is too long %s\n", buf);
++ return;
++ }
++ strcpy(val, buf);
++}
++
+ static void bcm47xx_sprom_fill_r1234589(struct ssb_sprom *sprom,
+ const struct bcm47xx_sprom_fill *fill)
+ {
+@@ -439,6 +463,63 @@ static void bcm47xx_sprom_fill_r9(struct
+ nvram_read_u8(fill, NULL, "sar5g", &sprom->sar5g, 0);
+ }
+
++static void bcm47xx_sprom_fill_r11(struct ssb_sprom *sprom,
++ const struct bcm47xx_sprom_fill *fill)
++{
++ nvram_read_u8(fill, NULL, "agbg0", &sprom->agbg0, 0);
++ nvram_read_u8(fill, NULL, "agbg1", &sprom->agbg1, 0);
++ nvram_read_u8(fill, NULL, "agbg2", &sprom->agbg2, 0);
++ nvram_read_u8(fill, NULL, "aga0", &sprom->aga0, 0);
++ nvram_read_u8(fill, NULL, "aga1", &sprom->aga1, 0);
++ nvram_read_u8(fill, NULL, "aga2", &sprom->aga2, 0);
++ nvram_read_u8(fill, NULL, "tssiposslope2g", &sprom->tssiposslope2g, 0);
++ nvram_read_u8(fill, NULL, "epagain2g", &sprom->epagain2g, 0);
++ nvram_read_u8(fill, NULL, "pdgain2g", &sprom->pdgain2g, 0);
++ nvram_read_u8(fill, NULL, "tworangetssi2g", &sprom->tworangetssi2g, 0);
++ nvram_read_u8(fill, NULL, "papdcap2g", &sprom->papdcap2g, 0);
++ nvram_read_u8(fill, NULL, "femctrl", &sprom->femctrl, 0);
++ nvram_read_u8(fill, NULL, "tssiposslope5g", &sprom->tssiposslope5g, 0);
++ nvram_read_u8(fill, NULL, "epagain5g", &sprom->epagain5g, 0);
++ nvram_read_u8(fill, NULL, "pdgain5g", &sprom->pdgain5g, 0);
++ nvram_read_u8(fill, NULL, "tworangetssi5g", &sprom->tworangetssi5g, 0);
++ nvram_read_u8(fill, NULL, "papdcap5g", &sprom->papdcap5g, 0);
++ nvram_read_u8(fill, NULL, "gainctrlsph", &sprom->gainctrlsph, 0);
++ nvram_read_u16(fill, NULL, "pdoffset40ma0", &sprom->pdoffset40ma0, 0);
++ nvram_read_u16(fill, NULL, "pdoffset40ma1", &sprom->pdoffset40ma1, 0);
++ nvram_read_u16(fill, NULL, "pdoffset40ma2", &sprom->pdoffset40ma2, 0);
++ nvram_read_u16(fill, NULL, "pdoffset80ma0", &sprom->pdoffset80ma0, 0);
++ nvram_read_u16(fill, NULL, "pdoffset80ma1", &sprom->pdoffset80ma1, 0);
++ nvram_read_u16(fill, NULL, "pdoffset80ma2", &sprom->pdoffset80ma2, 0);
++ nvram_read_u16(fill, NULL, "dot11agofdmhrbw202gpo",
&sprom->dot11agofdmhrbw202gpo, 0);
++ nvram_read_u16(fill, NULL, "ofdmlrbw202gpo",
[OpenWrt-Devel] [PATCH 4/6] bcm53xx: increase nvram allocation size to 64k
The R8000 nvram is larger than 32k, increase nvram allocation to 64k to accomadate. Signed-off-by: Ian Kent --- ...3xx-increase-nvram-allocation-size-to-64k.patch | 19 +++ ...3xx-increase-nvram-allocation-size-to-64k.patch | 20 2 files changed, 39 insertions(+) create mode 100644 target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch create mode 100644 target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch diff --git a/target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch b/target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch new file mode 100644 index 000..89763eb --- /dev/null +++ b/target/linux/bcm53xx/patches-3.14/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch @@ -0,0 +1,19 @@ +bcm53xx: increase nvram allocation size to 64k + +The R8000 nvram is too large for the 32k allocation size in +bcm47xx_nvram.c. + +Increase the allocation size to 64k. + +Signed-off-by: Ian Kent +--- a/drivers/firmware/broadcom/bcm47xx_nvram.c b/drivers/firmware/broadcom/bcm47xx_nvram.c +@@ -20,7 +20,7 @@ + #include + + #define NVRAM_MAGIC 0x48534C46 /* 'FLSH' */ +-#define NVRAM_SPACE 0x8000 ++#define NVRAM_SPACE 0x1 + #define NVRAM_MAX_GPIO_ENTRIES32 + #define NVRAM_MAX_GPIO_VALUE_LEN 30 + diff --git a/target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch b/target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch new file mode 100644 index 000..3382549 --- /dev/null +++ b/target/linux/bcm53xx/patches-3.18/113-bcm53xx-increase-nvram-allocation-size-to-64k.patch @@ -0,0 +1,20 @@ +bcm53xx: increase nvram allocation size to 64k + +The R8000 nvram is too large for the 32k allocation size in +bcm47xx_nvram.c. + +Increase the allocation size to 64k. + +Signed-off-by: Ian Kent + +--- a/drivers/firmware/broadcom/bcm47xx_nvram.c b/drivers/firmware/broadcom/bcm47xx_nvram.c +@@ -20,7 +20,7 @@ + #include + + #define NVRAM_MAGIC 0x48534C46 /* 'FLSH' */ +-#define NVRAM_SPACE 0x8000 ++#define NVRAM_SPACE 0x1 + #define NVRAM_MAX_GPIO_ENTRIES32 + #define NVRAM_MAX_GPIO_VALUE_LEN 30 + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 5/6] bcm53xx: deal with R8000 mac address settings
After a vendor firmware install the values seen in nvram for et0macaddr
and et1macaddr are that of nvram macaddr and nvram macaddr+1.
So set them that way here too.
Signed-off-by: Ian Kent
---
...53xx-deal-with-R8000-mac-address-settings.patch | 83
...53xx-deal-with-R8000-mac-address-settings.patch | 83
2 files changed, 166 insertions(+)
create mode 100644
target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
create mode 100644
target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
diff --git
a/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
new file mode 100644
index 000..a476405
--- /dev/null
+++
b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
@@ -0,0 +1,83 @@
+bcm53xx: deal with R8000 mac address settings
+
+The R8000 ends up with et0macaddr and et1macaddr nvram values being all
+zeros with the et*mdcport and et*phyaddr set to the expected values.
+
+The values seen in the nvram after a vendor firmware install are
+et0macaddr and et2macaddr set to the value of macaddr and et1macaddr
+set to macaddr+1.
+
+But after an nvram erase only et2macaddr has a value, so if et0macaddr
+is all zeros use et2macaddr to set et0macaddr and et1macaddr.
+
+Signed-off-by: Ian Kent
+--- a/drivers/misc/bcm47xx-sprom.c
b/drivers/misc/bcm47xx-sprom.c
+@@ -734,6 +734,24 @@ static void bcm47xx_sprom_fill_path_r11(
+ }
+ }
+
++static bool bcm47xx_is_zero_mac(u8 *mac)
++{
++ bool res = 1;
++ int i;
++
++ if (!mac)
++ goto out;
++
++ for (i = 5; i >= 0; i--) {
++ if (mac[i]) {
++ res = 0;
++ break;
++ }
++ }
++out:
++ return res;
++}
++
+ static bool bcm47xx_is_valid_mac(u8 *mac)
+ {
+ return mac && !(mac[0] == 0x00 && mac[1] == 0x90 && mac[2] == 0x4c);
+@@ -780,6 +798,42 @@ static void bcm47xx_sprom_fill_ethernet(
+ nvram_read_macaddr(fill, "il0macaddr", sprom->il0mac);
+
+ /*
++ * The R8000 ends up with et0macaddr and et1macaddr nvram values
++ * being all zeros with the et*mdcport and et*phyaddr set to the
++ * expected values. The values seen in the nvram after a vendor
++ * firmware install are et0macaddr set to the value of macaddr
++ * and et1macaddr set to macaddr+1. But after an nvram erase only
++ * et2macaddr has a value, so if et0macaddr is all zeros use
++ * et2macaddr to set et0macaddr and et1macaddr.
++ *
++ * Note: il0macaddr is also the same as macaddr following a vendor
++ * install and the key doesn't exist at all after an nvram erase,
++ * so sprom->il0mac may need to cwbe calculated as well.
++ */
++ if (bcm47xx_is_zero_mac(sprom->et0mac)) {
++ struct bcm47xx_sprom_fill fill_no_prefix;
++ u8 mac[6];
++
++ memcpy(&fill_no_prefix, fill, sizeof(fill_no_prefix));
++ fill_no_prefix.prefix = NULL;
++
++ nvram_read_macaddr(&fill_no_prefix, "et2macaddr", mac);
++
++ if (bcm47xx_is_valid_mac(mac) && !bcm47xx_is_zero_mac(mac)) {
++ int err;
++
++ ether_addr_copy(sprom->et0mac, mac);
++
++ err = bcm47xx_increase_mac_addr(mac, 1);
++ if (!err) {
++ ether_addr_copy(sprom->et1mac, mac);
++ /* don't change mac_addr_used so below
++ * will behave as expected, if needed */
++ }
++ }
++ }
++
++ /*
+* The address prefix 00:90:4C is used by Broadcom in their initial
+* configuration. When a mac address with the prefix 00:90:4C is used
+* all devices from the same series are sharing the same mac address.
diff --git
a/target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
b/target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
new file mode 100644
index 000..a476405
--- /dev/null
+++
b/target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
@@ -0,0 +1,83 @@
+bcm53xx: deal with R8000 mac address settings
+
+The R8000 ends up with et0macaddr and et1macaddr nvram values being all
+zeros with the et*mdcport and et*phyaddr set to the expected values.
+
+The values seen in the nvram after a vendor firmware install are
+et0macaddr and et2macaddr set to the value of macaddr and et1macaddr
+set to macaddr+1.
+
+But after an nvram erase only et2macaddr has a value, so if et0macaddr
+is all zeros use et2macaddr t
[OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
The Netgear R8000 has a PEX8603 connected to the BCM53012 and if
it isn't configured during the bus scan the PCI layer goes crazy
trying to configure phantom devices.
Signed-off-by: Ian Kent
---
.../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
.../172-bcm5301x-R8000-handle-PEX8603-switch.patch | 225
2 files changed, 450 insertions(+)
create mode 100644
target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
create mode 100644
target/linux/bcm53xx/patches-3.18/172-bcm5301x-R8000-handle-PEX8603-switch.patch
diff --git
a/target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
b/target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
new file mode 100644
index 000..fc606b4
--- /dev/null
+++
b/target/linux/bcm53xx/patches-3.14/172-bcm5301x-R8000-handle-PEX8603-switch.patch
@@ -0,0 +1,225 @@
+bcm53xx: R8000 handle PEX8603 switch
+
+The Netgear R8000 has a PEX8603 which, if not configured at
+bus probe results in quite a few phantom devices as it doesn't
+respond properly to configuration requests. The device needs
+to be configured when seen.
+
+Signed-off-by: Ian Kent
+
+--- a/drivers/pci/host/pci-host-bcm5301x.c
b/drivers/pci/host/pci-host-bcm5301x.c
+@@ -29,6 +29,21 @@
+ #define PCI_TARGET_LINK_SPEED_GEN20x2
+ #define PCI_TARGET_LINK_SPEED_GEN10x1
+
++#define PCI_MAX_BUS 4
++#define PLX_PRIM_SEC_BUS_NUM (0x0201 | (PCI_MAX_BUS << 16))
++
++#ifndef SZ_48M
++#define SZ_48M(SZ_32M + SZ_16M)
++#endif
++
++struct pex86xx_info {
++ u8 busno; /* Upstream bus PEX is on */
++ u8 slot;/* Upstream slot PEX is at */
++ u16 active; /* Active port count */
++ u16 ports; /* Active port bit map */
++};
++struct pex86xx_info pex8603;
++
+ static int bcma_pcie2_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
+ {
+ struct pci_sys_data *sys = pdev->sysdata;
+@@ -115,6 +130,39 @@ static int bcma_pcie2_read_config_pci(st
+ struct pci_sys_data *sys = bus->sysdata;
+ struct bcma_device *bdev = sys->private_data;
+
++ /* The PEX8603 won't return sensible values to the PCI layer so
++ * we have to do that ourselves.
++ */
++ if (pex8603.busno) {
++ u16 slot = PCI_SLOT(devfn);
++
++ /* Not the PEX upstream slot */
++ if (pex8603.busno == bus->number && pex8603.slot != slot)
++ goto done;
++
++ /* Not the PEX downstream bus? */
++ if (bus->number < pex8603.busno ||
++ bus->number > pex8603.busno + 1)
++ goto done;
++
++ switch (bus->number - pex8603.busno) {
++ case 0:
++ /* Upstream port */
++ break;
++
++ case 1:
++ /* PEX8603, not present for slots other than 1 or 2 */
++ if (!(slot == 1 || slot == 2)) {
++ *val = 0x;
++ return PCIBIOS_SUCCESSFUL;
++ }
++ break;
++
++ default:
++ break;
++ }
++ }
++done:
+ *val = bcma_pcie2_read_config(bdev, bus->number, devfn, where, size);
+
+ return PCIBIOS_SUCCESSFUL;
+@@ -126,6 +174,37 @@ static int bcma_pcie2_write_config_pci(s
+ struct pci_sys_data *sys = bus->sysdata;
+ struct bcma_device *bdev = sys->private_data;
+
++ /* Don't try and set anything on the PEX8603 if it isn't
++ * valid.
++ */
++ if (pex8603.busno) {
++ u16 slot = PCI_SLOT(devfn);
++
++ /* Not the PEX upstream slot */
++ if (pex8603.busno == bus->number && pex8603.slot != slot)
++ goto done;
++
++ /* Not the PEX downstream bus? */
++ if (bus->number < pex8603.busno ||
++ bus->number > pex8603.busno + 1)
++ goto done;
++
++ switch (bus->number - pex8603.busno) {
++ case 0:
++ /* Upstream port */
++ break;
++
++ case 1:
++ /* PEX8603 slots only slots 1 and 2 present */
++ if (!(slot == 1 || slot == 2))
++ return PCIBIOS_SUCCESSFUL;
++ break;
++
++ default:
++ break;
++ }
++ }
++done:
+ bcma_pcie2_write_config(bdev, bus->number, devfn, where, size, val);
+
+ return PCIBIOS_SUCCESSFUL;
+@@ -147,6 +226,113 @@ static void bcma_pcie2_fixup_class(struc
+ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_BROADCOM, 0x8011,
bcma_pcie2_fixup_clas
Re: [OpenWrt-Devel] [PATCH 0/6] Series short description
On Tue, 2015-03-10 at 12:17 +0100, Jonas Gorski wrote: > On Tue, Mar 10, 2015 at 4:25 AM, Ian Kent wrote: > > The following series implements... > > If you don't have anything nice to say, ... ;) (i.e. you should drop > the cover letter if it does not contain anything useful). Apologies, that was a misfire when I noticed one of the patches needed another change, sorry for the noise. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/6] bcm53xx: deal with R8000 mac address settings
On Tue, 2015-03-10 at 12:26 +0100, Jonas Gorski wrote:
> On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent wrote:
> > After a vendor firmware install the values seen in nvram for et0macaddr
> > and et1macaddr are that of nvram macaddr and nvram macaddr+1.
> >
> > So set them that way here too.
> >
> > Signed-off-by: Ian Kent
> > ---
> > ...53xx-deal-with-R8000-mac-address-settings.patch | 83
> >
> > ...53xx-deal-with-R8000-mac-address-settings.patch | 83
> >
> > 2 files changed, 166 insertions(+)
> > create mode 100644
> > target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
> > create mode 100644
> > target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
> >
> > diff --git
> > a/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
> >
> > b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
> > new file mode 100644
> > index 000..a476405
> > --- /dev/null
> > +++
> > b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch
> > @@ -0,0 +1,83 @@
> > +bcm53xx: deal with R8000 mac address settings
> > +
> > +The R8000 ends up with et0macaddr and et1macaddr nvram values being all
> > +zeros with the et*mdcport and et*phyaddr set to the expected values.
> > +
> > +The values seen in the nvram after a vendor firmware install are
> > +et0macaddr and et2macaddr set to the value of macaddr and et1macaddr
> > +set to macaddr+1.
> > +
> > +But after an nvram erase only et2macaddr has a value, so if et0macaddr
> > +is all zeros use et2macaddr to set et0macaddr and et1macaddr.
> > +
> > +Signed-off-by: Ian Kent
> > +--- a/drivers/misc/bcm47xx-sprom.c
> > b/drivers/misc/bcm47xx-sprom.c
> > +@@ -734,6 +734,24 @@ static void bcm47xx_sprom_fill_path_r11(
> > + }
> > + }
> > +
> > ++static bool bcm47xx_is_zero_mac(u8 *mac)
> > ++{
> > ++ bool res = 1;
> > ++ int i;
> > ++
> > ++ if (!mac)
> > ++ goto out;
> > ++
> > ++ for (i = 5; i >= 0; i--) {
> > ++ if (mac[i]) {
> > ++ res = 0;
> > ++ break;
> > ++ }
> > ++ }
> > ++out:
> > ++ return res;
> > ++}
> > ++
> > + static bool bcm47xx_is_valid_mac(u8 *mac)
> > + {
> > + return mac && !(mac[0] == 0x00 && mac[1] == 0x90 && mac[2] == 0x4c);
> > +@@ -780,6 +798,42 @@ static void bcm47xx_sprom_fill_ethernet(
> > + nvram_read_macaddr(fill, "il0macaddr", sprom->il0mac);
> > +
> > + /*
> > ++ * The R8000 ends up with et0macaddr and et1macaddr nvram values
> > ++ * being all zeros with the et*mdcport and et*phyaddr set to the
> > ++ * expected values. The values seen in the nvram after a vendor
> > ++ * firmware install are et0macaddr set to the value of macaddr
> > ++ * and et1macaddr set to macaddr+1. But after an nvram erase only
> > ++ * et2macaddr has a value, so if et0macaddr is all zeros use
> > ++ * et2macaddr to set et0macaddr and et1macaddr.
> > ++ *
> > ++ * Note: il0macaddr is also the same as macaddr following a vendor
> > ++ * install and the key doesn't exist at all after an nvram erase,
> > ++ * so sprom->il0mac may need to cwbe calculated as well.
> > ++ */
> > ++ if (bcm47xx_is_zero_mac(sprom->et0mac)) {
>
> sprom->et0mac is u16 aligned, so you can replace this with
> is_zero_ether_addr().
>
> > ++ struct bcm47xx_sprom_fill fill_no_prefix;
> > ++ u8 mac[6];
>
> and if you make mac aligned to u16, then you can drop the
> reimplementation completely.
>
> > ++
> > ++ memcpy(&fill_no_prefix, fill, sizeof(fill_no_prefix));
> > ++ fill_no_prefix.prefix = NULL;
> > ++
> > ++ nvram_read_macaddr(&fill_no_prefix, "et2macaddr", mac);
> > ++
> > ++ if (bcm47xx_is_valid_mac(mac) && !bcm47xx_is_zero_mac(mac))
> > {
>
> and use it here, too.
>
> > ++ int err;
> > ++
> > ++ ether_addr_copy(sprom->et0mac, mac);
>
> And this will produce alignment issues anyway if mac isn't aligned to u16.
OK, thanks for the
Re: [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far
On Tue, 2015-03-10 at 12:55 +0100, Rafał Miłecki wrote: > On 10 March 2015 at 12:29, Jonas Gorski wrote: > > On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent wrote: > >> [OpenWrt-Devel] [PATCH 0/6] bcm53xx: changes for R8000 so far > > > > Ah, this is supposed to be the V2. > > > > Please version your patchsets when resubmitting, i.e. this would be > > then [PATCH V2], and add a changelog to the individual patches (under > > the tear line, so it won't land in the actual commit message when > > accepted). > > Right. Something like > git format-patch --subject-prefix="PATCH V2" Right, as I say I prefer StGIT, so that's probably "stg mail -v v2", I haven't actually used that option before. > > No need to do it this time, I'll recognize V2 on my own. > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ethernet problem with R8000
On Sat, 2015-02-28 at 23:07 +0800, Ian Kent wrote: > Hi all, > > I'm trying to make progress on getting the Netgear R8000 to work. > Basically it's a BCM4799 but with a BCM53012 switch rather than the > usual BCM53011 (among other differences). > > I have a number of problems but the one that is the most concerning is > that Ethernet doesn't work. > > Now, this is all quite new to me so I'm struggling and would appreciate > some help. > > AFAICS the switch is matched in the various drivers so it appears to be > supported to the extent that it's believed to function. The nvram > claims sprom rev 11, I've added that (although I'm not sure it's done > the way it should be) and it looks like the only things the bgmac > driver needs from it are a couple of mac addresses and a phy address > which it gets. > > But I have no Ethernet at all! > > The only things I can say for sure are, packets sent are seen by the > bgmac driver and the driver gets a transmit completion interrupt which > it processes. However, no packets is seen coming from the router switch > port. Similarly no interrupts are seen by the driver for incoming > packets at all. > > I have, to the extent that I can and not yet completely, worked through > the GPL Broadcom source for the R8000 comparing the switch source to > the bgmac driver (together with the spec at the sip solutions site) and > I can't yet identify any significant differences. > > Also, again to the extent I can, I see what looks like should be in the > registers for the first DMA channel and that changes as it should as > packets are sent, channels 2-4, aren't really used yet by the look of > it so I'm not sure inconsistencies in them matter, in any case it's the > ring descriptor offset that appears incorrect. > > Can anyone offer any suggestions on how to work out what this problem > is? Hi Rafał, As I say above I've tried quite hard to check for changes in the GPLed source that might be causing this and, apart from one small change that appears to be related to scatter gather support, I can't find anything not already present in the bgmac driver. One thing I'm wondering is perhaps, if flow accelerator hardware is present (and I haven't yet checked if that's the case on the R8000), maybe it must be handled for the Ethernet to function. Thoughts? Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [package] mwlwifi: generate TX_STATUS event on transmitting auth, associate, and reallocate responses
On Wed, 2015-03-18 at 21:40 -0600, Pat Fruth wrote:
> This patch addresses an issue specific to Apple devices experiencing a
> wireless disconnect when trying to associate with either 2.4Ghz or 5Ghz wifi
> of a Linksys WRT1900AC router.
> Apple devices (MacBooks running Mac OS X 10.10.x Yosemite in particular, but
> there may be others), appear to re-auth/re-associate within approximately 25
> seconds of initially associating.
> Evidence of this can be seen by the presence of an entry similar to the
> following in the Apple system logs;
> MM/DD/YY HH:MM:SS.sss AM kernel[0]: wl0: Roamed or switched channel,
> reason #8, bssid xx:xx:xx:xx:xx:xx
> The Marvell wifi driver doesn’t generate a NL80211_CMD_FRAME_TX_STATUS event
> on transmitting a response to auth and/or reassociate requests. Thus, the
> respective callback handler functions (in hostapd’s ieee802_11.c) never get
> driven, ultimately leading to the problem.
> The patch causes a TX_STATUS event to be generated for auth and reassociate
> request’s responses, in addition to associate request’s responses.
>
> Signed-off-by: Pat Fruth
> ---
> .../mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch | 14
> ++
> 1 file changed, 14 insertions(+)
> create mode 100644
> package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
>
> diff --git
> a/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> new file mode 100644
> index 000..5f0d7fb
> --- /dev/null
> +++ b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> @@ -0,0 +1,14 @@
> +--- a/mwl_tx.c
> b/mwl_tx.c
> +@@ -395,7 +395,10 @@ void mwl_tx_done(unsigned long data)
> +
> + tr = (struct mwl_dma_data *)done_skb->data;
> +
> +-if
> (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> ++// if
> (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> ++if
> (ieee80211_is_assoc_resp(tr->wh.frame_control) ||
> ++
> ieee80211_is_reassoc_resp(tr->wh.frame_control) ||
> ++ieee80211_is_auth(tr->wh.frame_control)) {
> +
> + /* Remove H/W dma header
> + */
I don't think there's anything to be gained by commenting out the
original line. It only adds extra noise and the change that's been made
is evident from the log.
Ian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [package] mwlwifi: generate TX_STATUS event on transmitting auth, associate, and reallocate responses
On Thu, 2015-03-19 at 12:05 +0800, Ian Kent wrote:
> On Wed, 2015-03-18 at 21:40 -0600, Pat Fruth wrote:
> > This patch addresses an issue specific to Apple devices experiencing a
> > wireless disconnect when trying to associate with either 2.4Ghz or 5Ghz
> > wifi of a Linksys WRT1900AC router.
> > Apple devices (MacBooks running Mac OS X 10.10.x Yosemite in particular,
> > but there may be others), appear to re-auth/re-associate within
> > approximately 25 seconds of initially associating.
> > Evidence of this can be seen by the presence of an entry similar to the
> > following in the Apple system logs;
> > MM/DD/YY HH:MM:SS.sss AM kernel[0]: wl0: Roamed or switched channel,
> > reason #8, bssid xx:xx:xx:xx:xx:xx
> > The Marvell wifi driver doesn’t generate a NL80211_CMD_FRAME_TX_STATUS
> > event on transmitting a response to auth and/or reassociate requests.
> > Thus, the respective callback handler functions (in hostapd’s ieee802_11.c)
> > never get driven, ultimately leading to the problem.
> > The patch causes a TX_STATUS event to be generated for auth and reassociate
> > request’s responses, in addition to associate request’s responses.
> >
> > Signed-off-by: Pat Fruth
> > ---
> > .../mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch | 14
> > ++
> > 1 file changed, 14 insertions(+)
> > create mode 100644
> > package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> >
> > diff --git
> > a/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> > b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> > new file mode 100644
> > index 000..5f0d7fb
> > --- /dev/null
> > +++ b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> > @@ -0,0 +1,14 @@
> > +--- a/mwl_tx.c
> > b/mwl_tx.c
> > +@@ -395,7 +395,10 @@ void mwl_tx_done(unsigned long data)
> > +
> > + tr = (struct mwl_dma_data *)done_skb->data;
> > +
> > +- if
> > (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> > ++ // if
> > (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> > ++ if
> > (ieee80211_is_assoc_resp(tr->wh.frame_control) ||
> > ++
> > ieee80211_is_reassoc_resp(tr->wh.frame_control) ||
> > ++ ieee80211_is_auth(tr->wh.frame_control)) {
> > +
> > + /* Remove H/W dma header
> > + */
>
> I don't think there's anything to be gained by commenting out the
> original line. It only adds extra noise and the change that's been made
> is evident from the log.
On a different note this might resolve a problem I have that makes the
WRT1900AC unusable in my situation.
I use a number of different routers as media bridges and some of them
will work for a while and then I find they aren't connected. That could
be an example of the re-associate problem here.
Not sure when I'll be able to test this as it involves time I don't have
and putting the WRT1900AC in as my main router which has proven to be
disruptive, but I will get to it.
>
> Ian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] [package] mwlwifi: generate TX_STATUS event on transmitting auth, associate, and reallocate responses
On Thu, 2015-03-19 at 19:32 -0600, Pat Fruth wrote:
> > On Mar 18, 2015, at 10:05 PM, Ian Kent wrote:
> >
> > On Wed, 2015-03-18 at 21:40 -0600, Pat Fruth wrote:
> >> This patch addresses an issue specific to Apple devices experiencing a
> >> wireless disconnect when trying to associate with either 2.4Ghz or 5Ghz
> >> wifi of a Linksys WRT1900AC router.
> >> Apple devices (MacBooks running Mac OS X 10.10.x Yosemite in particular,
> >> but there may be others), appear to re-auth/re-associate within
> >> approximately 25 seconds of initially associating.
> >> Evidence of this can be seen by the presence of an entry similar to the
> >> following in the Apple system logs;
> >>MM/DD/YY HH:MM:SS.sss AM kernel[0]: wl0: Roamed or switched channel,
> >> reason #8, bssid xx:xx:xx:xx:xx:xx
> >> The Marvell wifi driver doesn’t generate a NL80211_CMD_FRAME_TX_STATUS
> >> event on transmitting a response to auth and/or reassociate requests.
> >> Thus, the respective callback handler functions (in hostapd’s
> >> ieee802_11.c) never get driven, ultimately leading to the problem.
> >> The patch causes a TX_STATUS event to be generated for auth and
> >> reassociate request’s responses, in addition to associate request’s
> >> responses.
> >>
> >> Signed-off-by: Pat Fruth
> >> ---
> >> .../mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch | 14
> >> ++
> >> 1 file changed, 14 insertions(+)
> >> create mode 100644
> >> package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> >>
> >> diff --git
> >> a/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> >> b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> >> new file mode 100644
> >> index 000..5f0d7fb
> >> --- /dev/null
> >> +++ b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> >> @@ -0,0 +1,14 @@
> >> +--- a/mwl_tx.c
> >> b/mwl_tx.c
> >> +@@ -395,7 +395,10 @@ void mwl_tx_done(unsigned long data)
> >> +
> >> + tr = (struct mwl_dma_data *)done_skb->data;
> >> +
> >> +- if
> >> (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> >> ++ // if
> >> (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> >> ++ if
> >> (ieee80211_is_assoc_resp(tr->wh.frame_control) ||
> >> ++
> >> ieee80211_is_reassoc_resp(tr->wh.frame_control) ||
> >> ++ ieee80211_is_auth(tr->wh.frame_control)) {
> >> +
> >> + /* Remove H/W dma header
> >> + */
> >
> > I don't think there's anything to be gained by commenting out the
> > original line. It only adds extra noise and the change that's been made
> > is evident from the log.
> >
> > Ian
> >
>
> Thanks Ian.
> Fair enough.
> Here’s the patch, this time without the commented line of code.
I think the process is that we should send changes to the component
maintainer, cc OpenWrt-devel, since maintainers might miss the post.
Imre, is this change acceptable, what other changes are needed, should
Pat re-submit this afresh or is what's here OK?
>
> Signed-off-by: Pat Fruth
> ---
> .../mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch| 13
> +
> 1 file changed, 13 insertions(+)
> create mode 100644
> package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
>
> diff --git
> a/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> new file mode 100644
> index 000..f454cc5
> --- /dev/null
> +++ b/package/kernel/mwlwifi/patches/002_TX-STATUS-for-reassoc-auth.patch
> @@ -0,0 +1,13 @@
> +--- a/mwl_tx.c
> b/mwl_tx.c
> +@@ -395,7 +395,9 @@ void mwl_tx_done(unsigned long data)
> +
> + tr = (struct mwl_dma_data *)done_skb->data;
> +
> +- if
> (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
> ++ if
> (ieee80211_is_assoc_resp(tr->wh.frame_control) ||
> ++
> ieee80211_is_reassoc_resp(tr->wh.frame_control) ||
> ++ ieee80211_is_auth(tr->wh.frame_control)) {
> +
> + /* Remove H/W dma header
> + */
> --
> 1.9.1
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/6] bcm53xx: update sprom from nvram to handle rev 11
On Thu, 2015-04-02 at 10:22 +0200, Rafał Miłecki wrote:
> Hi Ian,
>
> On 10 March 2015 at 04:30, Ian Kent wrote:
> > Add new sprom revision 11 variables to the nvram -> sprom reader.
> >
> > Signed-off-by: Ian Kent
>
> There are few problems with bcm53xx's SPROM and I've few comments to your
> patch.
As I expected, ;)
>
> bcm53xx's SPROM driver is modified version of mainline
> arch/mips/bcm74xx/sprom.c. It already differs a bit, but we can still
> see the differences and try to mainline them. By adding more changes
> to it we'll get lost and upsteaming changes will become more complex.
Yes, that's not good.
>
> Other than that, current way of handling revisions is quite messy, I
> guess you noticed it by yourself. I started reworking, see:
> http://patchwork.linux-mips.org/patch/9659/
> Again, my change if for upstream driver.
I've noticed a couple of changes you've submitted.
I must admit they are interesting but not what I would have come up
with. I guess it's my lack of experience with the code, but that'll come
in time.
>
> Also your changes to struct ssb_sprom may get complex to maintain, I
> believe you should try to upstream them.
Sure, we needed a place to start and something to work with.
At least the patch captures the names that need to be catered for and
should at least save a bit of leg work.
>
> So my idea to resolve this situation is to:
> 1) sync bcm53xx SPROM driver with mainline one, let it differ only
> with DT specific code
> 2) keep submitting SPROM changes to the mainline driver and just
> backport them to bcm53xx
> 3) clear bcm47xx's sprom.c and work on moving it to the
> drivers/firmware/broadcom/
OK, just to clarify, your recommending the canonical source is the
current bcm47xx and the goal is to make that generic and move it to a
common location in the source tree.
So I should familiarize myself with that source too.
>
> I'm really happy you worked on SPROM rev 11 properties, it would be
> great to get them as a patch for the bcm47xx's driver.
LOL, I need to start somewhere, thanks.
>
>
> > ++ entry_count = ARRAY_SIZE(gains_info->rxgains5gmelnagaina);
> > ++ for (j = 0; j < entry_count; j++) {
> > ++ snprintf(postfix, sizeof(postfix), "%i", j);
> > ++ snprintf(tmp, sizeof(tmp), "%i:%s", i,
> > "rxgains5gmelnagaina");
> > ++ nvram_read_u8(fill, postfix, tmp,
> > ++&gains_info->rxgains5gmelnagaina[j],
> > 0);
> > ++ }
>
> You shouldn't let unexpected NVRAM content crash your driver. Don't
> trust the entry_count, verify it with your array size.
Umm ... don't have my patch handy and don't quite follow.
Since I set the array size in the sprom structure I've assumed I could
use it.
I'll check since I suspect I've used local working storage and perhaps
your saying I shouldn't trust the structure. So yes, I should check
entry_count in case something has changed in the sprom structure.
I'll need to check what happens if a value isn't present, IIRC the last
parameter was used in that case, setting the gains_info entry to NULL.
Ian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/6] bcm53xx: increase nvram allocation size to 64k
On Thu, 2015-04-02 at 09:45 +0200, Rafał Miłecki wrote: > On 10 March 2015 at 04:30, Ian Kent wrote: > > The R8000 nvram is larger than 32k, increase nvram allocation to > > 64k to accomadate. > > I handled this by sending nvram.c patch for mainline: > http://patchwork.linux-mips.org/patch/9651/ > And backporting all changes to bcm53xx: > https://dev.openwrt.org/changeset/45204/ OK, help me out with this patch. I thought it was necessary to calculate a from starting offset based on mtd size and nvram size since the code assumes the nvram partition might not start at 0 whereas in the patch it looks like a 0 starting offset is assumed? When I was working on this area of code, IIRC, the from offset was actually not 0. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/6] bcm53xx: increase nvram allocation size to 64k
On Thu, 2015-04-02 at 17:47 +0800, Ian Kent wrote:
> On Thu, 2015-04-02 at 09:45 +0200, Rafał Miłecki wrote:
> > On 10 March 2015 at 04:30, Ian Kent wrote:
> > > The R8000 nvram is larger than 32k, increase nvram allocation to
> > > 64k to accomadate.
> >
> > I handled this by sending nvram.c patch for mainline:
> > http://patchwork.linux-mips.org/patch/9651/
> > And backporting all changes to bcm53xx:
> > https://dev.openwrt.org/changeset/45204/
>
> OK, help me out with this patch.
>
> I thought it was necessary to calculate a from starting offset based on
> mtd size and nvram size since the code assumes the nvram partition might
> not start at 0 whereas in the patch it looks like a 0 starting offset is
> assumed?
>
> When I was working on this area of code, IIRC, the from offset was
> actually not 0.
Mmm .. so that's probably wrong since ...
mtd = get_mtd_device_nm("nvram");
Should get us the start of the nvram partition at offset 0.
>
> Ian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] b53: override CPU port state on BCM5301X with CPU port other than 8
On Sun, 2015-04-12 at 19:01 +0200, Rafał Miłecki wrote:
> Newer revisions (5+) of BCM53011 and probably all revs of BCM53012
> require overriding CPU port to work. So far we were handling it only for
> CPU port 8, but some devices may use e.g. port 5. In such case we need
> to use recently defined GMII_PORT registers.
> It was tested for regressions on BCM53011 revs 2 & 3. It was also
> confirmed to fix switch on some internal Broadcom board.
CPU port as 5 also allows the switch on my R8000 (BCM53012) rev 5 device
to function.
The puzzle is the the Vendor firmware uses port 8 as the cpu port (+ 5
and 7 for some unknown purpose) for these higher rev switches. We
clearly don't know what the relationship is between ports 5, 7 and 8 and
I suspect there's more to it than just configuring the three ports
properly. But my code to set ports 5, 7 and 8 when cpu is 8 might not be
correct either, don't know yet.
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: Use new code branch to make (unused) port 8 branch reachable.
> ---
> .../generic/files/drivers/net/phy/b53/b53_common.c | 17
> +
> 1 file changed, 17 insertions(+)
>
> diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> index d2bb51a..2079f80 100644
> --- a/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> +++ b/target/linux/generic/files/drivers/net/phy/b53/b53_common.c
> @@ -536,6 +536,23 @@ static int b53_switch_reset(struct b53_device *dev)
> PORT_OVERRIDE_LINK);
> }
>
> + if (is5301x(dev)) {
> + if (dev->sw_dev.cpu_port == 8) {
> + /* TODO: Ports 5 & 7 require some extra handling */
> + } else {
> + u8 po_reg =
> B53_GMII_PORT_OVERRIDE_CTRL(dev->sw_dev.cpu_port);
> + u8 gmii_po;
> +
> + b53_read8(dev, B53_CTRL_PAGE, po_reg, &gmii_po);
> + gmii_po |= GMII_PO_LINK |
> +GMII_PO_RX_FLOW |
> +GMII_PO_TX_FLOW |
> +GMII_PO_EN |
> +GMII_PO_SPEED_2000M;
> + b53_write8(dev, B53_CTRL_PAGE, po_reg, gmii_po);
> + }
> + }
> +
> b53_enable_mib(dev);
>
> return b53_flush_arl(dev);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] b53: override CPU port state on BCM5301X with CPU port other than 8
On Wed, 2015-04-15 at 09:01 +0200, Rafał Miłecki wrote: > On 15 April 2015 at 07:37, Ian Kent wrote: > > On Sun, 2015-04-12 at 19:01 +0200, Rafał Miłecki wrote: > >> Newer revisions (5+) of BCM53011 and probably all revs of BCM53012 > >> require overriding CPU port to work. So far we were handling it only for > >> CPU port 8, but some devices may use e.g. port 5. In such case we need > >> to use recently defined GMII_PORT registers. > >> It was tested for regressions on BCM53011 revs 2 & 3. It was also > >> confirmed to fix switch on some internal Broadcom board. > > > > CPU port as 5 also allows the switch on my R8000 (BCM53012) rev 5 device > > to function. > > > > The puzzle is the the Vendor firmware uses port 8 as the cpu port (+ 5 > > and 7 for some unknown purpose) for these higher rev switches. We > > clearly don't know what the relationship is between ports 5, 7 and 8 and > > I suspect there's more to it than just configuring the three ports > > properly. But my code to set ports 5, 7 and 8 when cpu is 8 might not be > > correct either, don't know yet. > > I guess this is simply for performance reasons. Imagine there are two > 1 Gbps devices connected to the router and that they want to "talk" > with router system (for whatever reason). To achieve max speeds we > need router system to Tx/Rx with 2 Gbps. This is impossible if switch > is connected to CPU with a single 1 Gbps port. By combining 2/3 ports > this should be possible (of course you're still limited by CPU > performance). I think so too. It might be related to the "Flow Accelerator" that appears to live in the GMAC-3 address space and (I'm not sure about this) may be connected to the third PCIE device that's currently not configured by bgmac being the reason nothing works when using port 8 as cpu. But that also looks to be related to the mystery Cut Through Forward code so I'm not sure we would benefit putting effort into working out how this all works. The Flow Accelerator code isn't present in the Netgear GPL code either so it becomes a guessing game as to what changes may have been made looking at other router GPL code. Even more it appears the Netgear GPL code is configured to disable the Flow Accelerator code but, from what I've seen of other routers features that are supposedly disabled but aren't in the Actual firmware release, we can't assume that is really the case either. Anyway, food for thought. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Fri, 2015-04-17 at 10:55 +0200, Arend van Spriel wrote: > Resend as it bounced on openwrt-devel list. > > Original Message > Subject: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE > devices in nvram. > Date: Fri, 17 Apr 2015 10:50:08 +0200 > From: Arend van Spriel > To: Rafał Miłecki > CC: Hante Meuleman , > "linux-wirel...@vger.kernel.org" , Kalle > Valo , mailinglist > , Florian Fainelli > > + openwrt-devel list > > On 04/17/15 09:45, Rafał Miłecki wrote: > > Huh, why dropping linux-wireless (and top posting btw)? Please let > > everyone follow the discussion :) > > > > On 15 April 2015 at 21:20, Hante Meuleman wrote: > >> As I wrote to you in a mail and on the openwrt forum, this patch is indeed > >> an attempt to support more complex nvram files. I also wrote, that in > >> order to be able to use it, the nvram contents of the device (r8000) needs > >> tobe put a specific file. Now for your concerns, we can perhaps add > >> something which will read the nvram contents directly from an nvram store. > >> But thatis irrelevant to this patch. The parsing is still needed, and all > >> we wouldneed to add is something which is reading the nvram contents from > >> some other place > > > > So it makes me wonder if we need this patch in its current form. I > > think getting NVRAM directly from the platform is much user friendly. > > It doesn't require user to install some extra tools for dumping NVRAM > > and putting it in a specific file. One extra layer less. > > With that said I think it's hard to review your code for parsing > > NVRAM. We don't know how it's going to be fetched in the first place. > > You already made that point and we agreed to look for a solution. > > >> though it would have to be put under some kernel config flag as this would > >> not be supported in non-router systems. The contents of the nvram would > >> however still need to be parsed in exactly the same way as the nvram files > >> we read from disk. > > > > Again, it's hard to say for me. Are you going to use > > bcm47xx_nvram_getenv? Are you going to use MTD subsystem? Are you > > going to develop different solution? When using e.g. > > bcm47xx_nvram_getenv you won't want all this parsing stuff at all. > > Please look at the usage scenario here. The brcmfmac driver is not > needing a few key,value pairs. It needs a portion of NVRAM to download > to the device. The patch provides the functionality to do just that. Get > the appropriate portion, strip comments and whitespace, and send it to > the device. Using bcm47xx_nvram_getenv is not a useful api as it would > mean we need brcmfmac to know which key ids to ask for, reassemble it to > key=value string and send it to the fullmac device. Following an "nvram erase" none of the needed pairs remain in nvram. So we probably can't use nvram in a reliable way to create the wireless configuration. But there's no information about what the (I guess) device firmware actually needs. Is there a list of key value pairs used/needed? What are there default values? Are sensible default values used for key value pairs that are not present in the configuration? Point is there should be only a few entries needed in a configuration to alter some specific default values for a sane implementation. Why use pcie domain and bus number? What do you get from hard coding things that might change over time with implementation? The nvram from a vendor install doesn't use pcie domain and bus number, it uses "0:", "1:" and "2:" prefixes, and as much as I don't like that either, it is implementation independent. Knowing more about what is really needed and how it is handled (for which there is no information whatsoever that I can find) might help me understand why the driver doesn't work on my R8000. Perhaps that's a bit harsh, the driver does work partially. Extracting each prefixed section and replacing the prefix with // doesn't seem to make any difference. The driver still insists these devices are 2.4Ghz only and barfs at any 5Ghz configuration. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Mon, 2015-04-20 at 11:27 +0200, Arend van Spriel wrote: > On 04/20/15 03:00, Ian Kent wrote: > > On Fri, 2015-04-17 at 10:55 +0200, Arend van Spriel wrote: > >> Resend as it bounced on openwrt-devel list. > >> > >> Original Message > >> Subject: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE > >> devices in nvram. > >> Date: Fri, 17 Apr 2015 10:50:08 +0200 > >> From: Arend van Spriel > >> To: Rafał Miłecki > >> CC: Hante Meuleman, > >> "linux-wirel...@vger.kernel.org" , Kalle > >> Valo,mailinglist > >> , Florian Fainelli > >> > >> > >> + openwrt-devel list > >> > >> On 04/17/15 09:45, Rafał Miłecki wrote: > >>> Huh, why dropping linux-wireless (and top posting btw)? Please let > >>> everyone follow the discussion :) > >>> > >>> On 15 April 2015 at 21:20, Hante Meuleman wrote: > >>>> As I wrote to you in a mail and on the openwrt forum, this patch is > >>>> indeed an attempt to support more complex nvram files. I also wrote, > >>>> that in order to be able to use it, the nvram contents of the device > >>>> (r8000) needs tobe put a specific file. Now for your concerns, we can > >>>> perhaps add something which will read the nvram contents directly from > >>>> an nvram store. But thatis irrelevant to this patch. The parsing is > >>>> still needed, and all we wouldneed to add is something which is reading > >>>> the nvram contents from some other place > >>> > >>> So it makes me wonder if we need this patch in its current form. I > >>> think getting NVRAM directly from the platform is much user friendly. > >>> It doesn't require user to install some extra tools for dumping NVRAM > >>> and putting it in a specific file. One extra layer less. > >>> With that said I think it's hard to review your code for parsing > >>> NVRAM. We don't know how it's going to be fetched in the first place. > >> > >> You already made that point and we agreed to look for a solution. > >> > >>>> though it would have to be put under some kernel config flag as this > >>>> would not be supported in non-router systems. The contents of the nvram > >>>> would however still need to be parsed in exactly the same way as the > >>>> nvram files we read from disk. > >>> > >>> Again, it's hard to say for me. Are you going to use > >>> bcm47xx_nvram_getenv? Are you going to use MTD subsystem? Are you > >>> going to develop different solution? When using e.g. > >>> bcm47xx_nvram_getenv you won't want all this parsing stuff at all. > >> > >> Please look at the usage scenario here. The brcmfmac driver is not > >> needing a few key,value pairs. It needs a portion of NVRAM to download > >> to the device. The patch provides the functionality to do just that. Get > >> the appropriate portion, strip comments and whitespace, and send it to > >> the device. Using bcm47xx_nvram_getenv is not a useful api as it would > >> mean we need brcmfmac to know which key ids to ask for, reassemble it to > >> key=value string and send it to the fullmac device. > > > > Following an "nvram erase" none of the needed pairs remain > > in nvram. So we probably can't use nvram in a reliable way to create the > > wireless configuration. > > So why do "nvram erase"? The assumption that it is not needed because > you are running an OpenWRT image is wrong or at least only partially > true, ie. for the user-space settings. I'm saying that this does happen, and could break things when it does. Perhaps what I say isn't quite right now since I haven't tried going from Vendor firmware to OpenWRT for quite a long time now and things have changed somewhat. Nevertheless people will do an "nvram erase" and possibly get into trouble and, even without doing an "nvram erase", I've observed that the nvram content is significantly less than seen on a Vendor install. Just exactly what that means will need further testing, maybe the wireless nvram values will remain. But I can say that they do remain after an initial OpenWRT install from Vendor firmware. More detail from me on that on that will have to wait for future OpenWRT installs going from Vendor firmware to OpenWRT and upgrades of OpenWRT I'm afraid. But it does worry me a bit based on my experience so fa
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Mon, 2015-04-20 at 18:26 +0800, Ian Kent wrote: > On Mon, 2015-04-20 at 11:27 +0200, Arend van Spriel wrote: > > On 04/20/15 03:00, Ian Kent wrote: > > > On Fri, 2015-04-17 at 10:55 +0200, Arend van Spriel wrote: > > >> Resend as it bounced on openwrt-devel list. > > >> > > >> Original Message > > >> Subject: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE > > >> devices in nvram. > > >> Date: Fri, 17 Apr 2015 10:50:08 +0200 > > >> From: Arend van Spriel > > >> To: Rafał Miłecki > > >> CC: Hante Meuleman, > > >> "linux-wirel...@vger.kernel.org" , Kalle > > >> Valo, mailinglist > > >> , Florian Fainelli > > >> > > >> > > >> + openwrt-devel list > > >> > > >> On 04/17/15 09:45, Rafał Miłecki wrote: > > >>> Huh, why dropping linux-wireless (and top posting btw)? Please let > > >>> everyone follow the discussion :) > > >>> > > >>> On 15 April 2015 at 21:20, Hante Meuleman > > >>> wrote: > > >>>> As I wrote to you in a mail and on the openwrt forum, this patch is > > >>>> indeed an attempt to support more complex nvram files. I also wrote, > > >>>> that in order to be able to use it, the nvram contents of the device > > >>>> (r8000) needs tobe put a specific file. Now for your concerns, we can > > >>>> perhaps add something which will read the nvram contents directly from > > >>>> an nvram store. But thatis irrelevant to this patch. The parsing is > > >>>> still needed, and all we wouldneed to add is something which is > > >>>> reading the nvram contents from some other place > > >>> > > >>> So it makes me wonder if we need this patch in its current form. I > > >>> think getting NVRAM directly from the platform is much user friendly. > > >>> It doesn't require user to install some extra tools for dumping NVRAM > > >>> and putting it in a specific file. One extra layer less. > > >>> With that said I think it's hard to review your code for parsing > > >>> NVRAM. We don't know how it's going to be fetched in the first place. > > >> > > >> You already made that point and we agreed to look for a solution. > > >> > > >>>> though it would have to be put under some kernel config flag as this > > >>>> would not be supported in non-router systems. The contents of the > > >>>> nvram would however still need to be parsed in exactly the same way as > > >>>> the nvram files we read from disk. > > >>> > > >>> Again, it's hard to say for me. Are you going to use > > >>> bcm47xx_nvram_getenv? Are you going to use MTD subsystem? Are you > > >>> going to develop different solution? When using e.g. > > >>> bcm47xx_nvram_getenv you won't want all this parsing stuff at all. > > >> > > >> Please look at the usage scenario here. The brcmfmac driver is not > > >> needing a few key,value pairs. It needs a portion of NVRAM to download > > >> to the device. The patch provides the functionality to do just that. Get > > >> the appropriate portion, strip comments and whitespace, and send it to > > >> the device. Using bcm47xx_nvram_getenv is not a useful api as it would > > >> mean we need brcmfmac to know which key ids to ask for, reassemble it to > > >> key=value string and send it to the fullmac device. > > > > > > Following an "nvram erase" none of the needed pairs remain > > > in nvram. So we probably can't use nvram in a reliable way to create the > > > wireless configuration. > > > > So why do "nvram erase"? The assumption that it is not needed because > > you are running an OpenWRT image is wrong or at least only partially > > true, ie. for the user-space settings. > > I'm saying that this does happen, and could break things when it does. > > Perhaps what I say isn't quite right now since I haven't tried going > from Vendor firmware to OpenWRT for quite a long time now and things > have changed somewhat. > > Nevertheless people will do an "nvram erase" and possibly get into > trouble and, even without doing an "nvram erase", I've observed that the > nvram conten
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Mon, 2015-04-20 at 18:40 +0800, Ian Kent wrote: > On Mon, 2015-04-20 at 18:26 +0800, Ian Kent wrote: > > On Mon, 2015-04-20 at 11:27 +0200, Arend van Spriel wrote: > > > On 04/20/15 03:00, Ian Kent wrote: > > > > On Fri, 2015-04-17 at 10:55 +0200, Arend van Spriel wrote: > > > >> Resend as it bounced on openwrt-devel list. > > > >> > > > >> Original Message > > > >> Subject: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE > > > >> devices in nvram. > > > >> Date: Fri, 17 Apr 2015 10:50:08 +0200 > > > >> From: Arend van Spriel > > > >> To: Rafał Miłecki > > > >> CC: Hante Meuleman, > > > >> "linux-wirel...@vger.kernel.org" > > > >> , Kalle > > > >> Valo,mailinglist > > > >> , Florian Fainelli > > > >> > > > >> > > > >> + openwrt-devel list > > > >> > > > >> On 04/17/15 09:45, Rafał Miłecki wrote: > > > >>> Huh, why dropping linux-wireless (and top posting btw)? Please let > > > >>> everyone follow the discussion :) > > > >>> > > > >>> On 15 April 2015 at 21:20, Hante Meuleman > > > >>> wrote: > > > >>>> As I wrote to you in a mail and on the openwrt forum, this patch is > > > >>>> indeed an attempt to support more complex nvram files. I also wrote, > > > >>>> that in order to be able to use it, the nvram contents of the device > > > >>>> (r8000) needs tobe put a specific file. Now for your concerns, we > > > >>>> can perhaps add something which will read the nvram contents > > > >>>> directly from an nvram store. But thatis irrelevant to this patch. > > > >>>> The parsing is still needed, and all we wouldneed to add is > > > >>>> something which is reading the nvram contents from some other place > > > >>> > > > >>> So it makes me wonder if we need this patch in its current form. I > > > >>> think getting NVRAM directly from the platform is much user friendly. > > > >>> It doesn't require user to install some extra tools for dumping NVRAM > > > >>> and putting it in a specific file. One extra layer less. > > > >>> With that said I think it's hard to review your code for parsing > > > >>> NVRAM. We don't know how it's going to be fetched in the first place. > > > >> > > > >> You already made that point and we agreed to look for a solution. > > > >> > > > >>>> though it would have to be put under some kernel config flag as this > > > >>>> would not be supported in non-router systems. The contents of the > > > >>>> nvram would however still need to be parsed in exactly the same way > > > >>>> as the nvram files we read from disk. > > > >>> > > > >>> Again, it's hard to say for me. Are you going to use > > > >>> bcm47xx_nvram_getenv? Are you going to use MTD subsystem? Are you > > > >>> going to develop different solution? When using e.g. > > > >>> bcm47xx_nvram_getenv you won't want all this parsing stuff at all. > > > >> > > > >> Please look at the usage scenario here. The brcmfmac driver is not > > > >> needing a few key,value pairs. It needs a portion of NVRAM to download > > > >> to the device. The patch provides the functionality to do just that. > > > >> Get > > > >> the appropriate portion, strip comments and whitespace, and send it to > > > >> the device. Using bcm47xx_nvram_getenv is not a useful api as it would > > > >> mean we need brcmfmac to know which key ids to ask for, reassemble it > > > >> to > > > >> key=value string and send it to the fullmac device. > > > > > > > > Following an "nvram erase" none of the needed pairs remain > > > > in nvram. So we probably can't use nvram in a reliable way to create the > > > > wireless configuration. > > > > > > So why do "nvram erase"? The assumption that it is not needed because > > > you are running an OpenWRT image is wrong or at least only partially > > > true, ie. for the user-space settings. &g
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Mon, 2015-04-20 at 19:28 +0200, Arend van Spriel wrote: > On 04/20/15 13:50, Jonas Gorski wrote: > > Hi, > > > > On Mon, Apr 20, 2015 at 1:29 PM, Rafał Miłecki wrote: > >> On 20 April 2015 at 11:27, Arend van Spriel wrote: > Following an "nvram erase" none of the needed pairs remain > in nvram. So we probably can't use nvram in a reliable way to create the > wireless configuration. > >>> > >>> > >>> So why do "nvram erase"? The assumption that it is not needed because you > >>> are running an OpenWRT image is wrong or at least only partially true, ie. > >>> for the user-space settings. > >> > >> I agree with Arend. If you're are erasing sensitive wireless info from > >> your device, expect problems. The same will happen if you'll overwrite > >> standard Broadcom PCI device SPROM (which contains the same kind of > >> data). > > > > At least on older bcm47xx/MIPS devices nvram was also used for (user > > changable) configuration like lan ip address, and consequently erasing > > nvram caused CFE to restore the default values, which should include > > the right wifi configuration values. Several devices even do so when > > holding down reset for a long time at power up*. Does this not happen > > anymore with bcm53xx/ARM? Are user values now stored in a different > > partition? > > Hi Jonas, > > I was hoping that the firmware specific wifi config would indeed be in a > separate MTD partition. However, Hante has been looking at the MTD > partitions and none match up with what CFE dumps upon 'nvram show'. So > we are going through our CFE code, but no clues (yet) whether R8000 > specific changes have been made. There is also an spiflash device > configured in DT but the bcm53xxspiflash driver does not seem to be > working for it. Yes, that's what I see too. Last time I looked I got the impression the device used isn't known to the kernel. > > Regards, > Arend > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Wed, 2015-04-22 at 11:45 +, Hante Meuleman wrote: > Today I wrote the original firmware back on the device > (using the latest from netgear). This worked and the device > was working fine. Then I flashed openwrt again, now the > switch didn’t work anymore. So I checked the ports > configuration and it had changed. So I reverted that > using the nvram userspace program. This killed the > nvram contents completely and after reboot I only had > the bare minimum nvram contents and it was the same > as before. However, now I cannot get the switch to work > anymore. > > So doing an nvram set "xxx=yyy", followed by nvram commit > appears to be killing my nvram contents. > > I've no idea why my switch is not working anymore. The > problems with this switch is starting to get frustrating Yes, the switch is frustrating and all I can do is describe what I've seen, maybe it will help. A fairly recent change to setting the switch configuration in /etc/config/network at install sets the switch ports to "0 1 2 3 5 7 8t" and "4 8t" for the respective vlans. But the b53 driver still uses port 5 as the cpu and does the setup that you've previously described as working (using port 5 as cpu). The switch configuration in network is done once at firmware install so it needs to be changed by hand. What's more annoying is doing the heavy lifting in b53 to setup the switch to use port 8 for the cpu, the way the Broadcom source does, doesn't work so I'm missing something with that for sure. So we do need to stick to using port 5 for the cpu consistently throughout for now. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 17:22 > To: 'Ian Kent'; Arend Van Spriel > Cc: 'Jonas Gorski'; 'mailinglist' > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > Today I managed to update brcmfmac to load the data > directly from bcm47xx_nvram but it will require an additional > api in this module. I will post my version of bcm47xx_nvram > later this week. Also the patch for brcmfmac will be posted > later this week. With proper NVRAM the device is now booting > fine and all wireless devices get detected properly and are > working fine. > > I still do not know why I lost the complete contents of the nvram. > I do know that the CFE holds a very small default set which get > programmed if nothing is available from the nvram mtd block > device. As I dumped the nvram initially I was able to restore the > nvram completely and after that I was not able to get in the > situation where the nvram would be cleared and only hold the > default set of keys. > > We do have another r8000, but that one needs to be "recoverable". > So I will spent some time to see if I can make sure that I can restore > the r8000 with the original firmware and the original nvram > contents and once I'm sure I can I will try to update the other > r8000 as well. Then I can see if nvram gets perhaps erased on > the initial flashing of the OpenWRT. It's just a guess, but I really > don’t know what cleared the nvram contents on my device and > as long as that isn’t clear I wouldn’t recommend anybody to flash > an openwrt image on it. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 10:29 > To: 'Ian Kent'; Arend Van Spriel > Cc: 'Jonas Gorski'; 'mailinglist' > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > It is something else, the CFE appears to override the > nvram for some reason with some default data. Don’t > know yet what is reason for CFE to determine that nvram > is invalid but it appears to be within the CFE that NVRAM > gets erased and defaulted to something minimal. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 9:36 > To: 'Ian Kent'; Arend Van Spriel > Cc: Jonas Gorski; mailinglist > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > Well, I found that the cause is within openwrt. > I thought that CFE would still show the original > contents, but that is incorrect. So I reprogrammed > the nvram (via CFE, using created script, as I still > had the original nvram contents) then booted openwrt, > gave the command "nvram show" then rebooted and > the contents was suddenly very minimal. I'm still > investigating i
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Wed, 2015-04-22 at 12:50 +, Hante Meuleman wrote: > Found the problem for the "lost" nvram. The nvram user > space app build from directory package/utils/nvram/src > uses a maximum size of 32KB for nvram. As a result when > writing it will not write all entries. Once rebooted and the > CFE doesn’t detect certain critical nvram entries then it > will erase the complete nvram contents and put in a > default set. Changing the define NVRAM_SPACE from > 0x8000 into 0x1 in the nvram.h fixes this problem. > A similar change was already made in the kernel driver, > though I don’t think that in this case it can be done > without breaking backwards compatibility with older > devices. Oh, wow, so now we know why, that's a big step in resolving it, good catch. > > Now to the switch problems. > > Regards, > Hante > > -Original Message----- > From: Hante Meuleman > Sent: woensdag 22 april 2015 13:45 > To: 'Ian Kent'; Arend Van Spriel > Cc: 'Jonas Gorski'; 'mailinglist' > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > Today I wrote the original firmware back on the device > (using the latest from netgear). This worked and the device > was working fine. Then I flashed openwrt again, now the > switch didn’t work anymore. So I checked the ports > configuration and it had changed. So I reverted that > using the nvram userspace program. This killed the > nvram contents completely and after reboot I only had > the bare minimum nvram contents and it was the same > as before. However, now I cannot get the switch to work > anymore. > > So doing an nvram set "xxx=yyy", followed by nvram commit > appears to be killing my nvram contents. > > I've no idea why my switch is not working anymore. The > problems with this switch is starting to get frustrating > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 17:22 > To: 'Ian Kent'; Arend Van Spriel > Cc: 'Jonas Gorski'; 'mailinglist' > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > Today I managed to update brcmfmac to load the data > directly from bcm47xx_nvram but it will require an additional > api in this module. I will post my version of bcm47xx_nvram > later this week. Also the patch for brcmfmac will be posted > later this week. With proper NVRAM the device is now booting > fine and all wireless devices get detected properly and are > working fine. > > I still do not know why I lost the complete contents of the nvram. > I do know that the CFE holds a very small default set which get > programmed if nothing is available from the nvram mtd block > device. As I dumped the nvram initially I was able to restore the > nvram completely and after that I was not able to get in the > situation where the nvram would be cleared and only hold the > default set of keys. > > We do have another r8000, but that one needs to be "recoverable". > So I will spent some time to see if I can make sure that I can restore > the r8000 with the original firmware and the original nvram > contents and once I'm sure I can I will try to update the other > r8000 as well. Then I can see if nvram gets perhaps erased on > the initial flashing of the OpenWRT. It's just a guess, but I really > don’t know what cleared the nvram contents on my device and > as long as that isn’t clear I wouldn’t recommend anybody to flash > an openwrt image on it. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 10:29 > To: 'Ian Kent'; Arend Van Spriel > Cc: 'Jonas Gorski'; 'mailinglist' > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > It is something else, the CFE appears to override the > nvram for some reason with some default data. Don’t > know yet what is reason for CFE to determine that nvram > is invalid but it appears to be within the CFE that NVRAM > gets erased and defaulted to something minimal. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 9:36 > To: 'Ian Kent'; Arend Van Spriel > Cc: Jonas Gorski; mailinglist > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > Well, I found that the cause is within openwrt. > I thought that CFE would
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Thu, 2015-04-23 at 13:19 +, Hante Meuleman wrote: > Can you tell a bit more about: > > "switch to use port 8 for the cpu, the way the Broadcom source does, > doesn't work so I'm missing something with that for sure." > > Is that something you tried with the by Rafał suggested changes to > fix the cpu port to 8 in the struct, as described on the forum? This goes back to quite a while before you had a look at the switch problem. Essentially I was not able to get the switch to work at all so here's probably a lot more info. than you really want but I was sure I had tried what you ultimately described as working and which does work now so that was a bit of a surprise. That probably changed along the way and I never returned to trying what you found to work. The fact that the nvram settings indicate that switch port 8 is set as the cpu port is what lead to the belief that it should be used rather than port 5, but also ports 5 and 7 are related to port 8 in some way as well (judging by the nvram setting). I located GPL released source that looked like what the bgmac driver originated from and tried to find any new changes. I didn't find any except perhaps the endian order of the mac address when setting it. That made no difference. The next thing was to go through the same process for the b53 driver but it doesn't have a real parallel in the Broadcom source. The closest is bcmrobo.c which I used for the comparison. The patch I posted in the forum, when you started looking at the switch problem, is the result of that comparison and essentially configures switch port 8 and switch ports 5 and 7 as is done in bcmrobo.c in order to try and use port 8 as the switch cpu port. It doesn't work for me. I believe that there's some other device, perhaps a Flow Accelerator, that lives on the third pcie device that bgmac ignores which needs to be configured to provide the link between ports 5 and 7 to port 8. But that looks like it's also related to the cut through forward proprietary code so is probably something we can't use. The bottom line is, in light of you pointing out that using switch port 5 as the cpu port does now work, we probably need to ignore the fact that the nvram setting uses port 8 and just use port 5. For a long time the switch configuration in /etc/config/network set at install used port 5 as the cpu. But this recently changed to use port 8 if the nvram setting used port 8 which actually breaks the switch until it is set back to use port 5. Rafał has asked me to try only setting the cpu port to 8 in the b53 driver code for this switch device and try that to see if it works. I haven't done that yet but will get to it. > > > On Wed, 2015-04-22 at 11:45 +, Hante Meuleman wrote: > > Today I wrote the original firmware back on the device > > (using the latest from netgear). This worked and the device > > was working fine. Then I flashed openwrt again, now the > > switch didn’t work anymore. So I checked the ports > > configuration and it had changed. So I reverted that > > using the nvram userspace program. This killed the > > nvram contents completely and after reboot I only had > > the bare minimum nvram contents and it was the same > > as before. However, now I cannot get the switch to work > > anymore. > > > > So doing an nvram set "xxx=yyy", followed by nvram commit > > appears to be killing my nvram contents. > > > > I've no idea why my switch is not working anymore. The > > problems with this switch is starting to get frustrating > > Yes, the switch is frustrating and all I can do is describe what I've > seen, maybe it will help. > > A fairly recent change to setting the switch configuration > in /etc/config/network at install sets the switch ports to "0 1 2 3 5 7 > 8t" and "4 8t" for the respective vlans. > > But the b53 driver still uses port 5 as the cpu and does the setup that > you've previously described as working (using port 5 as cpu). > > The switch configuration in network is done once at firmware install so > it needs to be changed by hand. > > What's more annoying is doing the heavy lifting in b53 to setup the > switch to use port 8 for the cpu, the way the Broadcom source does, > doesn't work so I'm missing something with that for sure. > > So we do need to stick to using port 5 for the cpu consistently > throughout for now. > > > > > Regards, > > Hante > > > > -Original Message- > > From: Hante Meuleman > > Sent: dinsdag 21 april 2015 17:22 > > To: 'Ian Kent'; Arend Van Spriel > > Cc: 'Jonas Gorski'; 'mailinglist' > > Subject: RE:
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On Thu, 2015-04-23 at 14:48 +, Hante Meuleman wrote: > Thank you for the information Ian, that was very helpful. Just found > part of the problem. My R8000 used to work quite well, till I upgraded > to new Netgear firmware. The old Netgear firmware is using this nvram > entry: > > vlan1ports=3 2 1 0 5 7 8* > > Newer firmware will update this nvram entry to > > vlan1ports=0 1 2 3 5 7 8* My device had this setting from the beginning. > > So depending on when you bought the AP you will have one of these > entries in the nvram. Both strings indicate that port 8 is the cpu port, > however, somehow the application (or script, not sure what is doing > this) that generates the file /etc/config/network at first boot will > generate different results for the entry: > > option ports > > vlan1ports=3 2 1 0 5 7 8* -> option ports '0 1 2 3 5t' > vlan1ports=0 1 2 3 5 7 8* -> option ports '0 1 2 3 5 7 8t' > > So when you have newer Netgear FW in your AP then you'll have a > different setting for vlan1ports in /etc/config/network then with older > firmware. This setting determines whether or not the switch is going to > work (as you already figured out). > > Still investigating to as of why this setting doesn't work with b53 driver. > > -Original Message- > On Wed, 2015-04-22 at 11:45 +, Hante Meuleman wrote: > > Today I wrote the original firmware back on the device > > (using the latest from netgear). This worked and the device > > was working fine. Then I flashed openwrt again, now the > > switch didn’t work anymore. So I checked the ports > > configuration and it had changed. So I reverted that > > using the nvram userspace program. This killed the > > nvram contents completely and after reboot I only had > > the bare minimum nvram contents and it was the same > > as before. However, now I cannot get the switch to work > > anymore. > > > > So doing an nvram set "xxx=yyy", followed by nvram commit > > appears to be killing my nvram contents. > > > > I've no idea why my switch is not working anymore. The > > problems with this switch is starting to get frustrating > > Yes, the switch is frustrating and all I can do is describe what I've > seen, maybe it will help. > > A fairly recent change to setting the switch configuration > in /etc/config/network at install sets the switch ports to "0 1 2 3 5 7 > 8t" and "4 8t" for the respective vlans. > > But the b53 driver still uses port 5 as the cpu and does the setup that > you've previously described as working (using port 5 as cpu). > > The switch configuration in network is done once at firmware install so > it needs to be changed by hand. > > What's more annoying is doing the heavy lifting in b53 to setup the > switch to use port 8 for the cpu, the way the Broadcom source does, > doesn't work so I'm missing something with that for sure. > > So we do need to stick to using port 5 for the cpu consistently > throughout for now. > > > > > Regards, > > Hante > > > > -Original Message- > > From: Hante Meuleman > > Sent: dinsdag 21 april 2015 17:22 > > To: 'Ian Kent'; Arend Van Spriel > > Cc: 'Jonas Gorski'; 'mailinglist' > > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support > > for multiple PCIE devices in nvram. > > > > Today I managed to update brcmfmac to load the data > > directly from bcm47xx_nvram but it will require an additional > > api in this module. I will post my version of bcm47xx_nvram > > later this week. Also the patch for brcmfmac will be posted > > later this week. With proper NVRAM the device is now booting > > fine and all wireless devices get detected properly and are > > working fine. > > > > I still do not know why I lost the complete contents of the nvram. > > I do know that the CFE holds a very small default set which get > > programmed if nothing is available from the nvram mtd block > > device. As I dumped the nvram initially I was able to restore the > > nvram completely and after that I was not able to get in the > > situation where the nvram would be cleared and only hold the > > default set of keys. > > > > We do have another r8000, but that one needs to be "recoverable". > > So I will spent some time to see if I can make sure that I can restore > > the r8000 with the original firmware and the original nvram > > contents and once I'm sure I can I will try to updat
