Commit Graph

3 Commits (0d23fd2ab29a66f5d03187db4fac3e396b4f3b62)

Author SHA1 Message Date
Petr Štetiar 0d23fd2ab2 treewide: dts: Remove default-state=off property from all gpio LED nodes
>From the Documentation/devicetree/bindings/leds/common.txt:

- default-state : The initial state of the LED. Valid values are "on", "off",
  and "keep". If the LED is already on or off and the default-state property is
  set the to same value, then no glitch should be produced where the LED
  momentarily turns off (or on). The "keep" setting will keep the LED at
  whatever its current state is, without producing a glitch.  The default is
  off if this property is not present.

So setting the default-state of the LEDs to `off` is redundant as `off`
is default LED state anyway. We should remove it as almost every new
PR/patch submission contains this property by default which seems to be
just copy&paste from some DTS file already present in the tree.

Signed-off-by: Petr Štetiar <ynezz@true.cz>
6 years ago
Petr Štetiar d9753f0ec5 ath79, brcm63xx: Fix debounce-interval properties in gpio-keys-polled nodes
This patch fixes wrong usage of debounce-interval subnode property of
gpio-keys-polled nodes, which was used inproperly in parent node, but it
belongs to the subnodes, excerpt from the docs:

 Optional subnode-properties:
     - debounce-interval: Debouncing interval time in milliseconds.
       If not specified defaults to 5.

And the docs are up to date as the source code matches that description
as well:

 if (fwnode_property_read_u32(child, "debounce-interval",
                              &button->debounce_interval))
         button->debounce_interval = 5;

While at it, I've also re-formatted gpio-keys-polled nodes, usually just
adding new lines after every key subnode.

Cc: Tomasz Maciej Nowak <tomek_n@o2.pl>
Cc: Matt Merhar <mattmerhar@protonmail.com>
Cc: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
6 years ago
Matt Merhar d03c89838e ath79: initial support for Ubiquiti RouterStation and RouterStation Pro
This adds a shared ar7161_ubnt_routerstation.dtsi as well as two other
.dts files that utilize it, ar7161_ubnt_routerstation.dts and
ar7161_ubnt_routerstation-pro.dts.

The modifications to generic-ubnt.mk, config-default, and base-files
necessary for image generation, parsing RedBoot FIS partitions, network
configuration, and sysupgrade are also included.

This reintroduces vital bits from platform_do_upgrade_combined() and its
supporting functions to /lib/upgrade/platform.sh, which were previously
removed from ath79 in 3e9d9f6225 "ath79:
sysupgrade: drop unused platform checks". The new function is called
"routerstation_do_upgrade" and will *only* work for the RouterStation
series of boards. It does however retain the ability to downgrade (e.g.
from master -> 17.01.x using sysupgrade -F).

All hardware is functional including the AR8216 switch (for the Pro),
wireless via ath5k/ath9k using the miniPCI slots, flash, USB, button,
and LED.

Switch and LAN/WAN configuration is the same as it is with the
equivalent ar71xx targets. MAC addresses are assigned based upon the
content stored in the RedBoot config partition.

Flashing via both sysupgrade and TFTP has been confirmed to work. Also,
the initramfs images are now raw .bin files instead of being wrapped in
a uImage (as they currently are in ar71xx), which makes them bootable
with RedBoot.

One notable difference to ar71xx is the inclusion of the RedBoot
"fconfig" utility (analogous to U-Boot’s fw_printenv/fw_setenv) in
DEVICE_PACKAGES. The FIS partitions are probed using the RedBoot MTD
parser’s DT binding, whose proper usage is mutually exclusive to
defining a separate fixed-partitions node for "RedBoot config". This
config partition contains the board's base MAC address. The lack of a
hard-coded flash location means that the mtd-mac-address property cannot
be used in the .dts, so instead fconfig is used to read the MAC
addresses from flash in userspace during first boot.

Signed-off-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Signed-off-by: Matt Merhar <mattmerhar@protonmail.com>
6 years ago