| Age | Commit message (Collapse) | Author |
|---|
|
Fix the bulk of the unit_address_vs_reg warnings and unnecessary
\#address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
|
During the removal of the skeleton.dtsi file with commit abe60a3a7afb
("ARM: dts: Kill off skeleton{64}.dtsi") a number of Broadcom SoCs were
converted, but a few were left unoticed, now causing boot failures with
v5.1 since the kernel cannot find suitable memory.
Updating the .dtsi files with the property will be done next, since
there are some memory nodes that do not follow the proper naming
convention and lack an unit name.
Fixes: abe60a3a7afb ("ARM: dts: Kill off skeleton{64}.dtsi")
Reported-by: Kevin Hilman <khilman@kernel.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
|
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>
|
|
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>
|
|
Define the port mapping for the SmartRG SR400ACE device.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
|
Controller is present on every BCM4708* board but only few devices have
serial flash attached so mark it as disabled by default.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
|
This allows reporting & debugging problems occurring early in the boot
process.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
|
There are two possible UARTs so we have (both of) them disabled by
default. Override uart0 status on devices that were verified to use it.
In case of Netgear R6250 also drop an old (and invalid) overwrite. It
doesn't have uart1 connected.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
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>
|
|
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
