Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

The beagleboard doesn't boot with Thumb enabled, but without Thumb the
SPL (first stage bootloader) is too big to fit into SRAM.

Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

to use them later by image/Makefile to create full working sdcard images

Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

including phy and required dma options

Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

the pandaboard is a multicore omap

Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

Signed-off-by: Alexander Couzens <lynxis@fe80.eu>

Do as the vendor driver does -- however, some devices apparently
patched support for external PA into the driver similar to how it was
done on Rt3352, using EEPROM_NIC_CONF1 rather than EEPROM_NIC_CONF2,
hence we check for both fields. Somehow the vendor driver also no
longer offers the option of only one of the TX paths having an external
PA (which was probably to weird to ever be implemented in practise,
though it doesn't seem like a particularly bad idea to me). Do the same
in rt2x00 and enable support for external PA on both TX paths whenever
it is set for TX0 in EEPROM.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>

Import change to make external PA capability consistent with the
vendor driver instead of having the logic inverted.
While at it, apply patches in the same order as they got merged
upstream.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>

boardnames were changed with the recent target update. the sysupgrade board
detection was not updated properly.

Signed-off-by: John Crispin <john@phrozen.org>

Signed-off-by: John Crispin <john@phrozen.org>

This is the same as the NAND board but gmac1 is wired to an external phy.

Signed-off-by: John Crispin <john@phrozen.org>

Signed-off-by: John Crispin <john@phrozen.org>

Signed-off-by: John Crispin <john@phrozen.org>

Without patch unloading the dwc3-of-simple module went stuck after
successfully removing hcd.1 during the hcd.0 removal:

root@LEDE:/# rmmod dwc3-of-simple
[   21.391846] xhci-hcd xhci-hcd.1.auto: remove, state 1
[   21.391931] usb usb4: USB disconnect, device number 1
[   21.397038] xhci-hcd xhci-hcd.1.auto: USB bus 4 deregistered
[   21.401111] xhci-hcd xhci-hcd.1.auto: remove, state 1
[   21.406685] usb usb3: USB disconnect, device number 1
[   21.412848] xhci-hcd xhci-hcd.1.auto: USB bus 3 deregistered
[   21.417248] xhci-hcd xhci-hcd.0.auto: remove, state 1
[   21.422521] usb usb2: USB disconnect, device number 1
followed by nothing.

Sometimes a stall CPU was detected, or a kernel panic,
or a reboot occurred after a couple of minutes.

At the same time unloading the dwc3 module followed by dwc3-of-simple
module was working repeatedly.

root@LEDE:/# rmmod dwc3
[   53.827328] xhci-hcd xhci-hcd.1.auto: remove, state 1
[   53.827412] usb usb4: USB disconnect, device number 1
[   53.832630] xhci-hcd xhci-hcd.1.auto: USB bus 4 deregistered
[   53.836452] xhci-hcd xhci-hcd.1.auto: remove, state 1
[   53.842314] usb usb3: USB disconnect, device number 1
[   53.848412] xhci-hcd xhci-hcd.1.auto: USB bus 3 deregistered
[   53.852542] xhci-hcd xhci-hcd.0.auto: remove, state 1
[   53.857882] usb usb2: USB disconnect, device number 1
[   53.863956] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[   53.867875] xhci-hcd xhci-hcd.0.auto: remove, state 1
[   53.873696] usb usb1: USB disconnect, device number 1
[   53.879742] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered
root@LEDE:/# rmmod dwc3-of-simple
root@LEDE:/#

For the non-working case, the code was stuck in a readl() in
http://lxr.free-electrons.com/source/drivers/usb/host/xhci.c#L91
because
http://lxr.free-electrons.com/source/drivers/usb/dwc3/dwc3-of-simple.c#L126


was disabling the wrong clocks when removing hcd.1 (it was disabling
the clock of hcd.0). That's why the readl() went stuck when removing
hcd.0

The patch however addresses the clock assignment from the Netgear R7500
dts file and backs off the previous attempt.

Now unloading and repeated module loading is working just fine.

root@LEDE:/# rmmod dwc3-of-simple
[   24.089679] xhci-hcd xhci-hcd.1.auto: remove, state 1
[   24.089765] usb usb4: USB disconnect, device number 1
[   24.094856] xhci-hcd xhci-hcd.1.auto: USB bus 4 deregistered
[   24.098963] xhci-hcd xhci-hcd.1.auto: remove, state 1
[   24.104522] usb usb3: USB disconnect, device number 1
[   24.111194] xhci-hcd xhci-hcd.1.auto: USB bus 3 deregistered
[   24.115086] xhci-hcd xhci-hcd.0.auto: remove, state 1
[   24.120396] usb usb2: USB disconnect, device number 1
[   24.126503] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[   24.130347] xhci-hcd xhci-hcd.0.auto: remove, state 1
[   24.135948] usb usb1: USB disconnect, device number 1
[   24.142085] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered
root@LEDE:/#

Fixes: dwc3-of-simple module unloading for Netgear R7500

Signed-off-by: Thomas Reifferscheid <thomas@reifferscheid.org>

The patch follows the qualcomm code comments setting
SSUSB_CTRL_TEST_POWERDOWN to 0x1 and is testing and clearing the
bit during USB superspeed PHY init. According to Andy Gross it
needs to be BIT(26).

Signed-off-by: Thomas Reifferscheid <thomas@reifferscheid.org>
Acked-by: Andy Gross <andy.gross@linaro.org>

We need to ensure there is enough headroom to push extra header,
but we also need to check if we are allowed to change headers.

skb_cow_head() is the proper helper to deal with this.

Fixes Ethernet<->WiFi bridge for Raspberry Pi and probably other devices.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>

The script can be used to quickly spin up QEMU virtual machines with lan
and wan network.  Please read the initial part of the script for
instructions about how to configure host machine

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>

Original armvirt target is now subtarget 32.  Other than that the built
result should remain the same as before

Besides old features already available with arm64, the new armvirt/64
subtarget will also have those features originally enabled for
armvirt/32 with commit 44ecfc26 ("armvirt: new target")
 - pl011, uart
 - pl031, rtc
 - pl061, gpio
 - pci-host-generic
 - virtio_{mmio,pci,net,blk,scsi,9p,console,balloon}
 - smp with NR_CPUS=4
 - cpu-hotplug
 - ext4
 - DEBUG_BUGVERBOSE for debug purposes

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>

Not sure since when the issue emerged, but according to the current doc of gcc
and as, armv8-a is intended as argument of -march

The change will affect at the moment arm64 and layerscape/64b

Below is the relevant error messages when building toolchain

    Assembler messages:
    Error: unknown cpu `armv8-a'
    Error: unrecognized option -mcpu=armv8-a
    /home/yousong/git-repo/lede-project/lede/build_dir/toolchain-aarch64_armv8-a_gcc-5.4.0_musl/gcc-5.4.0/libgcc/libgcc2.c:1:0: error: unknown value 'armv8-a' for -mcpu

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>

The dep for the nftables support was wrong, if someone actually enable
that option gain a compilation error. This fix this problem.

Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>

Fix a '==' that should be a '=' in a test condition. Busybox fortunately
doesn't care.

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>

Fixes removal of unneeded kernel modules with per-device rootfs.

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>

Signed-off-by: Daniel Golle <daniel@makrotopia.org>

Protect any IPv6 related with appropriate guards to fix compilation with
disabled IPv6 support in Busybox.

Fixes #728.

Signed-off-by: Jo-Philipp Wich <jo@mein.io>

Add red:internet led on gpio 30 previously claimed as missing.
Wifi led was claimed as blue however there are no blue leds on the
board at all.  Actually there are two wifi leds, green & amber so add
definitions for those.  Make the newly discovered green wifi led gpio
14 the default.

There is no amber power led on this board. The mention of the amber
power led in the manual means power red and power green at the same
time.

Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
[removed unnecessary aliases, add migration script]
Signed-off-by: Mathias Kresin <dev@kresin.me>

Use fixed led names and add each board variant instead of manipulating
the board name.

It makes the ramips board name function less different to the one used
in other targets and allows to merge them with a common function.

Signed-off-by: Mathias Kresin <dev@kresin.me>

We need to keep the former used (unmodified) boardname in the metadata.
Otherwise an upgrade from an board using the old boardname will be
refused.

Fixes: a75ce960 ("ramips: use different board names for variants")
Signed-off-by: Mathias Kresin <dev@kresin.me>

Fix previous commit to be less ambigous:
PSG1218 rev.A = 5 ports, external PA, heatsinks
PSG1218 rev.B = 4 ports, internal PA, no heatsinks

Signed-off-by: Daniel Golle <daniel@makrotopia.org>

PSG1218 got only 4 Ethernet ports and WAN on port 3 while
PSG1218K2C got 5 Ethernet ports and WAN on port 4
Switch to use kmod-kt76x2 instead of kmod-mt76 for both devices while
at it.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>

It allows monitoring CPU temp and will shutdown system on critical
value.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>

Use the stateless 4-byte op codes for this flash chip to fix reboot
hangs on SoCs expecting the flash chip in 3-byte mode.

Fixes: FS#179

Signed-off-by: Mathias Kresin <dev@kresin.me>

update RF register 47 and 54 values according to vendor driver

Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[daniel@makrotopia.org: moved changes into a separate patch]

Use register values from init LNA function instead of the ones from
restore LNA function. Apply register values based on rx path
configuration.

Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[daniel@makrotopia.org: moved changes into a separate patch]

Make brcmfmac depend on !TARGET_uml.
Technically, brcmfmac could be built for uml because only SDIO support
won't work on that target. However, selectively avoiding the dependency
propagation of !TARGET_uml from kmod-mmc to avoid including a reference
to BRCMFMAC_SDIO doesn't work.

In practice, brcmfmac is completely useless on uml, so let's just
disable it there.

Signed-off-by: Felix Fietkau <nbd@nbd.name>

This should fix issues with bad RX as well as AP not coming up and/or
scanning failing.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>