[PATCH 0/8] Convert Netgear WNR854T to devicetree

This is an attempt to resurrect the mainline WNR854T support and
convert to device tree. The major change since v0 is the embedded
ethernet switch is now functional, thanks to Andrew Lunn, making the
device actually useful. Full list of changes:

* The DT definition for the switch in this patchset has changed to
match the 88e6131 DSA driver currently in net-next, and all
now-superflous attempts at fixing up the DSA driver have been removed
from this patchset.

* Use Flash partition scheme from original netgear Linux image (but
keeping the uboot/uboot_env split) instead of the partition scheme from
the old non-DT support, which didn't match either Netgear's layout,
u-boot or openWRT. NB: I've no copy of the original flash contents
(Netgear's firmware images only contain a squashfs image of the rootfs),
so I can't confirm the other partitions are accurately named.

* Set NOR Flash bank-width to correct value

* Reassign defconfig entries pointing at CONFIG_MACH_WNR854T (old
non-DT support) to CONFIG_MACH_WNR854T_DT

* Move eth0 pinctrl definitions and assignment to
orion5x-mv88f5181.dtsi [Andrew Lunn]

* Get the copyright year right [Rob Herring]

* Reformat pinctrl docs to one-compatible-string-per-line [Rob Herring]

* Rename reset button pinctrl to pmx_reset_button [Andrew Lunn]

* Move pmx_ge pinctrl definition to SoC include [Andrew Lunn]

* Put flash partitions into their own node [Andrew Lunn]

* Make LED names standards-compliant [Andrew Lunn]

* Use standard stdout-path definition for bootargs [Andrew Lunn]

The patches are also available at https://github.com/lentinj/linux
wnr854t-support-v1 - this is based on net-next to use in the
88e6131 changes there, and applies the patch in
https://lkml.org/lkml/2016/8/3/93 to allow the device to boot.

Thanks,

Jamie Lentin (8):
  arm: orion5x: Add documentation for SoC and board bindings
  arm: orion5x: Add clk support for mv88f5181
  arm: orion5x: Generalise mv88f5181l pinctrl support for 88f5181
  arm: orion5x: Alias uart0 to serial0 for all orion5x
  arm: orion5x: Add DT include for mv88f5181
  arm: orion5x: Add DT-based support for Netgear WNR854T
  arm: orion5x: Remove old non-DT-based WNR854T support
  arm: orion5x: Configure WNR854T ethernet PHY LEDs

 .../bindings/arm/marvell/marvell,orion5x.txt       |  25 ++
 .../devicetree/bindings/clock/mvebu-core-clock.txt |   1 +
 .../bindings/pinctrl/marvell,orion-pinctrl.txt     |   4 +-
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/orion5x-mv88f5181.dtsi           |  49 ++++
 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts      | 263 +++++++++++++++++++++
 arch/arm/boot/dts/orion5x.dtsi                     |   1 +
 arch/arm/configs/multi_v5_defconfig                |   2 +-
 arch/arm/configs/mvebu_v5_defconfig                |   2 +-
 arch/arm/configs/orion5x_defconfig                 |   2 +-
 arch/arm/mach-orion5x/Kconfig                      |   4 +-
 arch/arm/mach-orion5x/Makefile                     |   2 +-
 arch/arm/mach-orion5x/board-wnr854t.c              |  78 ++++++
 arch/arm/mach-orion5x/wnr854t-setup.c              | 185 ---------------
 drivers/clk/mvebu/orion.c                          |  70 ++++++
 drivers/pinctrl/mvebu/pinctrl-orion.c              |  23 +-
 16 files changed, 509 insertions(+), 203 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/marvell,orion5x.txt
 create mode 100644 arch/arm/boot/dts/orion5x-mv88f5181.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-netgear-wnr854t.dts
 create mode 100644 arch/arm/mach-orion5x/board-wnr854t.c
 delete mode 100644 arch/arm/mach-orion5x/wnr854t-setup.c

-- 
2.8.1

Hi Jamie,

On Fri, 26 Aug 2016 11:20:56 +0200, Jamie Lentin [off-list ref] wrote:

<snip>

* Use Flash partition scheme from original netgear Linux image (but
keeping the uboot/uboot_env split) instead of the partition scheme from
the old non-DT support, which didn't match either Netgear's layout,
u-boot or openWRT. NB: I've no copy of the original flash contents
(Netgear's firmware images only contain a squashfs image of the rootfs),
so I can't confirm the other partitions are accurately named.

Both the factory layout and OpenWrt's changed a few times - the later just  
to accommodate bigger kernels. Some factory firmwares did include a kernel  
update, too.

I would suggest staying with the OpenWrt layour (maybe increase again the  
size of the kernel partition):
- the bootloader loads the kernel from JFFS2
- most of the partitions in the factory firmware are empty
- the factory layout gives you almost no space to play with

But this is up to you now :)


Best,

Imre

On Fri, 26 Aug 2016, Imre Kaloz wrote:

Hi Jamie,

On Fri, 26 Aug 2016 11:20:56 +0200, Jamie Lentin [off-list ref] wrote:

<snip>

quoted

* Use Flash partition scheme from original netgear Linux image (but
keeping the uboot/uboot_env split) instead of the partition scheme from
the old non-DT support, which didn't match either Netgear's layout,
u-boot or openWRT. NB: I've no copy of the original flash contents
(Netgear's firmware images only contain a squashfs image of the rootfs),
so I can't confirm the other partitions are accurately named.

Both the factory layout and OpenWrt's changed a few times - the later just to 
accommodate bigger kernels. Some factory firmwares did include a kernel 
update, too.

The Netgear firwmare images (as far as I've seen) all contain a uImage, as 
the uImage lives in the same JFFS2 partition as the rootfs, which the 
firmware image is a dump of.

I would suggest staying with the OpenWrt layour (maybe increase again the 
size of the kernel partition):
- the bootloader loads the kernel from JFFS2
- most of the partitions in the factory firmware are empty

Phew, I'm not missing out on much then :)

- the factory layout gives you almost no space to play with

But this is up to you now :)

When making a patchset for the D-Link DNS-325 I remember being told that 
the kernel's default partition scheme should match the vendor's (even if 
it is fairly nonsensical). It's easy enough to override if you've replaced 
the default firmware, and I'll invariably be overriding it so the mainline 
kernel definition won't make much difference to me either way.

Of course, one could also argue I'm breaking backwards compatibility at 
this point by changing it, so maybe I should put it back.

Best,

Imre

-- 
Jamie Lentin