Currently, the USB 3.0 PHY in bcm5301x.dtsi uses platform driver which
requires register range "ccb-mii" <0x18003000 0x1000>. This range
overlaps with MDIO cmd and param registers (<0x18003000 0x8>).
Essentially, the platform driver partly acts like a MDIO bus driver,
hence to use of this register range.
In some Northstar devices like Linksys EA9500, secondary switch is
connected via external MDIO. The only way to access and configure the
external switch is via MDIO bus. When we enable the MDIO bus in it's
current state, the MDIO bus and any child buses fail to register because
of the register range overlap.
On Northstar, the USB 3.0 PHY is connected at address 0x10 on the
internal MDIO bus. This change moves the usb3_phy node and makes it a
child node of internal MDIO bus.
Thanks to Rafał Miłecki's commit af850e14a7 ("phy: bcm-ns-usb3: add
MDIO driver using proper bus layer") the same USB 3.0 platform driver
can now act as USB 3.0 PHY MDIO driver.
Tested on Linksys Panamera (EA9500)
Signed-off-by: Vivek Unune <npcomplete13@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Such a trigger doesn't exist in Linux and is not needed as LED is being
turned off by default. This could cause errors in LEDs core code when
trying to set default trigger.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Added two WAN status LEDs and a GPIO key for brightness which were
missing.
Signed-off-by: Aditya Xavier <adityaxavier@gmail.com>
Acked-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
It's preferred to have DT source files licensed under BSD compatible
license. All new BCM5301X DTS files use ISC so let's also relicense old
ones to it.
Except for me only Hauke was ever touched these files in his commit
9faa5960ee ("ARM: BCM5301X: add NAND flash chip description") and
commit bb1d8fba19 ("ARM: BCM5301X: add NAND flash chip description for
Asus RT-AC87U").
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Netgear R8000 is a tri-band home router. It has three BCM43602 chipsets
two of them for 5 GHz band. Both seem the same and their firmwares
report the same set of channels. The problem is due to hardware / board
design there are extra limitations that should be respected.
First PHY should be used for U-NII-2 and U-NII-3. Third PHY should be
used for U-NII-1. Using them in a different way may result in wireless
not working or in noticeably reduced performance. Basic version of this
info was provided by Broadcom employee, then it has been verified by me
using original vendor firmware (which has limitations hardcoded in UI).
This patch uses recently introduced ieee80211-freq-limit property to
describe these limitations at DT level.
Referencing PCIe devices in DT required specifying all related bridges.
Below you can see (a bit complex) PCI tree from R8000 that explains all
entries that I needed to put in DT.
0000:00:00.0 14e4:8012 Bridge Device
└─ 0000:01:00.0 14e4:aa52 Network Controller
0001:00:00.0 14e4:8012 Bridge Device
└─ 0001:01:00.0 10b5:8603 Bridge Device
├─ 0001:02:01.0 10b5:8603 Bridge Device
│ └─ 0001:03:00.0 14e4:aa52 Network Controller
├─ 0001:02:02.0 10b5:8603 Bridge Device
│ └─ 0001:04:00.0 14e4:aa52 Network Controller
├─ 0001:02:03.0 000d:0000 0x000000
├─ 0001:02:04.0 000d:0000 0x000000
├─ 0001:02:05.0 000d:0000 0x000000
├─ 0001:02:06.0 000d:0000 0x000000
├─ (...)
├─ 0001:02:1d.0 000d:0000 0x000000
├─ 0001:02:1e.0 000d:0000 0x000000
└─ 0001:02:1f.0 000d:0000 0x000000
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
The first 128 MiB of RAM can be accessed using an alias at address 0x0.
In theory we could access whole RAM using 0x80000000 - 0xbfffffff range
(up to 1 GiB) but it doesn't seem to work on Northstar. For some reason
(hardware setup left by the bootloader maybe?) 0x80000000 - 0x87ffffff
range can't be used. I reproduced this problem on:
1) Buffalo WZR-600DHP2 (BCM47081)
2) Netgear R6250 (BCM4708)
3) D-Link DIR-885L (BCM47094)
So it seems we're forced to access first 128 MiB using alias at 0x0 and
the rest using real base address + 128 MiB offset which is 0x88000000.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Jon Mason <jon.mason@broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Every device tested so far got UART0 (at 0x18000300) working as serial
console. It's most likely part of reference design and all vendors use
it that way.
It seems to be easier to enable it by default and just disable it if we
ever see a device with different hardware design.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Jon Mason <jon.mason@broadcom.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
It was tested by LEDE users, all we need is to adjust clock frequency.
While we're at it create a separated DTS include file to share code with
other BCM4709 devices easier.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
There are few devices that have USB power controlled using GPIO. Linux
USB host driver (bcma-hcd) already supports this by reading vcc-gpio
from DT. Set it properly for all known devices.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Add a bunch of LEDs missing for the Netgear R8000: wireless, wps, 5Ghz radio
and USB LEDs.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
This adds the NAND flash chip description for a standard chip found
connected to this SoC. This makes use of generic Broadcom NAND driver
with the iProc interface.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
