| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 af850e14a7ae ("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>
|
|
These files were created and ever touched by a group of three people
only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC.
Introducing and discussing SPDX-License-Identifier resulted in a
conclusion that ISC is a not recommended license (see also a
license-rules.rst). Moveover an old e-mail from Alan Cox was pointed
which explained that dual licensing is a safer solution than depending
on a common compatibility belief.
This commit switches most of BCM5301X DTS files to dual licensing using:
1) GPL 2.0+ to make sure they are compatible with Linux kernel
2) MIT to allow sharing with more permissive projects
Both licenses belong to the preferred ones (see LICENSES/preferred/).
An attempt to relicense remaining files will be made separately and will
require approve from more/other developers.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Dan Haab <dan.haab@luxul.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
|
This uses trigger-sources documented in commit 80dc6e1cd85fc ("dt-bindings:
leds: document new trigger-sources property") to specify USB ports. Such an
information can be used by operating system to setup LEDs behavior.
I updated dts files for 7 devices I own and I was able to test.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
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>
|
|
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's BCM4709A0 based device with 16 MiB flash, 128 MiB of RAM and two
PCIe based on-PCB BCM4360 chipsets.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
