Specification:
- SoC: Qualcomm Atheros QCA9563 (775 MHz, MIPS 74Kc)
- RAM: 128 MiB
- Storage: 16MB NOR flash
- Wireless: Built into QCA9563 (Dragonfly), PHY modes b/g/n, 3x3 MIMO
- Ethernet: 2x1G
Tested and working:
- ethernet / switch / lan / wan
- 2.4GHz SoC wifi
- PCIe
- leds
- buzzer
Ramload:
- tftpboot 0x84000000 lede-ar71xx-generic-wpj563-16M-initramfs-uImage.bin
- bootm 0x84000000
Install:
- tftpboot 0x80500000 lede-ar71xx-generic-wpj563-16M-squashfs-sysupgrade.bin
- erase 0x9f030000 +$filesize
- erase 0x9f680000 +1
- cp.b $fileaddr 0x9f030000 $filesize
Erasing 0x9f680000 is required because uboot defines
"bootcmd=bootm 0x9f680000 || bootm 0x9f030000", so it first tries to boot
the higher address. I think the 16 mb flash are intended to be used as
8+8mb for a fallback image. In my hardware only the lower address has a
bootable image. But to make sure future hardware will boot lede too, I
erase one block, so uboot will skip this address.
Signed-off-by: Christian Mehlis <christian@m3hlis.de>
RGMII RX delay setting needs to be always specified for AR8337 to
avoid port 5 RX hang on high traffic / flood conditions.
Also, the HOL registers that set per-port and per-packet-priority
buffer sizes are updated with the reduced values suggested by the
QCA switch team.
Finally, AR8327 reserved register fixups are disabled for the AR8337.
This patch is adapted from the Code Aurora QSDK, but with magic
values mapped to proper defines.
Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
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 .dtsi
file. Most probably it went into openwrt here:
https://dev.openwrt.org/browser/trunk/target/linux/ipq806x/patches-3.18/101-ARM-qcom-add-USB-nodes-to-ipq806x-ap148.patch?rev=45261
copied from Qualcomms attempt here: https://lkml.org/lkml/2015/11/20/116
Now unloading and repeated module loading is working just fine,
no matter if you'd remove dwc3-of-simple or dwc3.
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
Signed-off-by: Thomas Reifferscheid <thomas@reifferscheid.org>
Allow module unloading by fixing a mistake.
qcom_dwc3_phy_write_readback() is expecting (phy, offset, mask, value)
while the mistake was calling it with (phy, offset, value, mask)
The patch is swapping value and mask.
Without the patch unloading the dwc3 module was showing a
write to QSCRATCH failed and repeated module loading was
failing:
root@LEDE:/# rmmod dwc3
[ 19.167998] xhci-hcd xhci-hcd.1.auto: remove, state 1
[ 19.168084] usb usb4: USB disconnect, device number 1
[ 19.173371] xhci-hcd xhci-hcd.1.auto: USB bus 4 deregistered
[ 19.177134] xhci-hcd xhci-hcd.1.auto: remove, state 1
[ 19.182960] usb usb3: USB disconnect, device number 1
[ 19.189023] xhci-hcd xhci-hcd.1.auto: USB bus 3 deregistered
[ 19.192989] qcom-dwc3-usb-phy 110f8830.phy: write: 8000000 to QSCRATCH: 0 FAILED
[ 19.199064] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 19.205912] usb usb2: USB disconnect, device number 1
[ 19.211611] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[ 19.215905] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 19.221751] usb usb1: USB disconnect, device number 1
[ 19.227307] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered
[ 19.231795] qcom-dwc3-usb-phy 100f8830.phy: write: 8000000 to QSCRATCH: 0 FAILED
root@LEDE:/# modprobe dwc3
[ 29.583343] phy phy-100f8830.phy.4: phy init failed --> -110
[ 29.583399] dwc3 10000000.dwc3: failed to initialize core
[ 29.588169] dwc3: probe of 10000000.dwc3 failed with error -110
[ 29.652943] phy phy-110f8830.phy.2: phy init failed --> -110
[ 29.652988] dwc3 11000000.dwc3: failed to initialize core
[ 29.657735] dwc3: probe of 11000000.dwc3 failed with error -110
root@LEDE:/#
With patch repeated module unloading and loading is working good:
root@LEDE:/# rmmod dwc3
[ 22.622214] xhci-hcd xhci-hcd.1.auto: remove, state 1
[ 22.622298] usb usb4: USB disconnect, device number 1
[ 22.627401] xhci-hcd xhci-hcd.1.auto: USB bus 4 deregistered
[ 22.631492] xhci-hcd xhci-hcd.1.auto: remove, state 1
[ 22.637054] usb usb3: USB disconnect, device number 1
[ 22.643721] xhci-hcd xhci-hcd.1.auto: USB bus 3 deregistered
[ 22.647421] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 22.652910] usb usb2: USB disconnect, device number 1
[ 22.659219] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[ 22.662768] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 22.668604] usb usb1: USB disconnect, device number 1
[ 22.674803] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered
root@LEDE:/# modprobe dwc3
[ 25.404592] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 25.404694] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[ 25.409444] xhci-hcd xhci-hcd.0.auto: hcc params 0x0228f065 hci version 0x100 quirks 0x00010010
[ 25.416589] xhci-hcd xhci-hcd.0.auto: irq 168, io mem 0x10000000
[ 25.426509] hub 1-0:1.0: USB hub found
[ 25.431626] hub 1-0:1.0: 1 port detected
[ 25.435472] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 25.439206] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[ 25.444573] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 25.452926] hub 2-0:1.0: USB hub found
[ 25.460420] hub 2-0:1.0: 1 port detected
[ 25.525037] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[ 25.525099] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 3
[ 25.529750] xhci-hcd xhci-hcd.1.auto: hcc params 0x0228f065 hci version 0x100 quirks 0x00010010
[ 25.537002] xhci-hcd xhci-hcd.1.auto: irq 169, io mem 0x11000000
[ 25.546583] hub 3-0:1.0: USB hub found
[ 25.551997] hub 3-0:1.0: 1 port detected
[ 25.555734] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[ 25.559621] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 4
[ 25.564942] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
[ 25.573063] hub 4-0:1.0: USB hub found
[ 25.580842] hub 4-0:1.0: 1 port detected
root@LEDE:/#
Fixes: dwc3 module unloading
Signed-off-by: Thomas Reifferscheid <thomas@reifferscheid.org>
Many (most?) devices can't boot raw kernel using tftp and probably none
allows flashing it. It's way more usable to have TRX with kernel
containing initrams as such an image can be actually flashed.
An exception are Buffalo devices which have recovery mode with support
for booting kernels over TFTP. For them keep building default images.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Makes use of the syscon tcsr and enables both USB ports. Cleans up
qcom-ipq8064.dtsi from previous attempts.
Fixes FS#497
Signed-off-by: Thomas Reifferscheid <thomas@reifferscheid.org>
Current driver shows temp in full degrees while other apps await it
to be in millidegrees.
Initially the driver represents termal data in millidegrees but then
it gets divided by TSENS_FACTOR. So lets just set it to '1'.
Signed-off-by: Pavel Kubelun <be.dissent@gmail.com>
Deactivate all the ARM64 erratums by default. The target code should
activate them if needed. This fixes a problem with a new erratum added
in kernel 4.9.17 breaking brcm2708.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This gets us in sync with dts from kernel 4.11. Two patches were already
backported earlier.
I decided to use 03x prefix as it's kind of similar to the 3xx prefix:
3xx - architecture specific patches
It isn't any documented or strict rule though. We don't need to stick to
it if we hit any problems.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Álvaro Fernández Rojas <noltari@gmail.com>
modify 0152-lantiq-VPE.patch from
commit e0229a16b0 ("lantiq: added support for VPE1")
- remove wdog function declarations from header (asm/vpe.h)
- remove wdog command line init functions (vpe.c)
Signed-off-by: Stefan Koch <stefan.koch10@gmail.com>
- remove patched header (vpe.h) because kernel
already provides one (asm/vpe.h)
- remove module softdog_vpe since watchdog functionality is unused
- remove module softdog_vpe from Makefile
Signed-off-by: Stefan Koch <stefan.koch10@gmail.com>
Even the commit message of the patch adding support for the MiWiFi Nano
says that a 16 MB flash chip is used. Extend the firmware partition to
make use of all available flash space.
Fixes: FS#622
Signed-off-by: Mathias Kresin <dev@kresin.me>
Netgear X4 R7500 comes with a QCA988X. Select a firmware that matches
the ath10k chipset
Signed-off-by: Thomas Reifferscheid <thomas@reifferscheid.org>
Commit 23dac14d058f ("MIPS: PCI: Use struct list_head lists") changed
the controller list from reverse to straight order. Use the last entry
in the controller list to get the fist conroller of the system.
Signed-off-by: Mathias Kresin <dev@kresin.me>
Upstream commit 23dac14d058f ("MIPS: PCI: Use struct list_head lists")
changed the controller list from reverse to straight order without
taking care of the changed order for the scan of the recorded PCI
controllers.
Traverse the list in reverse order to restore the former behaviour.
This patches fixes the following PCI error on lantiq:
pci 0000:01:00.0: BAR 0: error updating (0x1c000004 != 0x000000)
Signed-off-by: Mathias Kresin <dev@kresin.me>
Right now all brcm2708 patches are extracted from the non-mainline
raspberrypi/linux git tree. Many of them are hacks and/or are unneeded
in LEDE. Raspberry Pi is getting better and better mainline support so
it would be nice to finally start maintaining patches in a cleaner way:
1) Backport patches accepted in upstream tree
2) Start using upstream drivers
3) Pick only these patches that are needed for more complete support
Handling above tasks requires grouping patches - ideally using the same
prefixes as generic ones. It means we should rename existing patches to
use some high prefix. This will allow e.g. use 0xx for backported code.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Stijn Tintel <stijn@linux-ipv6.be>
P&W (full name: Shenzhen Progress&Win Technologies) R602N (could be also
labeled as R602F, R602, etc.) is a simple N300 router with 5-port
10/100 Mbps switch, non-detachable antennas and USB.
CPE505 is an outdoor CPE with PoE support and detachable antennas.
Both devices are based on Qualcomm/Atheros QCA9531 v2.
Common specification:
- 650/597/216 MHz (CPU/DDR/AHB)
- 64 MB of RAM (DDR2)
- 16 MB of FLASH
- UART (J2) header on PCB
R602N specification:
- 5x 10/100 Mbps Ethernet
- 1x USB 2.0
- 2T2R 2.4 GHz with external LNA and PA (SE2576L), up to 28 dBm
- 2x external, non-detachable antennas
- 7x LED, 1x button
CPE505N specification:
- 2x 10/100 Mbps Ethernet (both ports support passive PoE 12-24 V)
- 2T2R 2.4 GHz with external LNA and PA (SKY65174-21), up to 30 dBm
- 2x external, detachable antennas (RP-SMA connectors)
- 1x RGB LED, 2x LEDs (in RJ45 sockets), 1x button
Flash instructions:
It seems that there are many different versions of the firmware which
these devices are shipped with. The generic/standard one is based on
some modified OpenWrt and LEDE firmware can be flashed directly from
vendor's webgui or with sysupgrade (root password is "admin123").
Before flashing, make sure (use "fw_printenv") that the kernel load
address in your device is set to "0x9f050000" (bootcmd variable is
"bootm 0x9f050000"). If your device uses different load address, you
should first change it, under vendor's firmware, with command:
fw_setenv bootcmd "bootm 0x9f050000 || bootm OLD_ADDRESS"
Where OLD_ADDRESS is previous kernel load address (in CPE505 version
I got access to, it was "0x9fe80000"). This will allow you to use
both the vendor's and LEDE firmware.
If version of your device contains empty U-Boot environment (you will
get information about this after issuing "fw_printenv"), you should
use U-Boot, serial line access and TFTP to perform firmware upgrade:
1. tftp 0x80060000 lede-ar71xx-generic-...-squashfs-sysupgrade.bin
2. erase 0x9f050000 +$filesize
3. cp.b $fileaddr 0x9f050000 $filesize
4. setenv bootcmd "bootm 0x9f050000 || bootm OLD_ADDRESS"
5. saveenv && reset
These devices contain also web recovery mode inside U-Boot. It can be
started with pressing the reset button for around 3 seconds just after
the device powerup. Web recovery panel is available on "192.168.10.9"
and to be able to use it, IP on your PC must be set to "192.168.10.10".
Make sure to change kernel load address before using recovery mode or
the U-Boot will not be able to load LEDE firmware.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
This patch adds initial support for the MikroTik RouterBOARD hAP ac
(RB962UiGS-5HacT2HnT).
All functions are supported except:
-SFP cage (eth1) is not working
-WLAN LEDs are not working
Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
This patch adds support for the MikroTik RouterBOARD hAP ac lite
(RB952Ui-5ac2nD).
The hAP ac lite is nearly identical to the hAP, with an added QCA9887
5GHz radio. The 2.4GHz radio ID is also changed in the hAP ac lite.
Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
v4.9 CM code has a few bugs on this HW. Disable the GCR register access
during boot. This caused a cpu stall.
Signed-off-by: John Crispin <john@phrozen.org>
The Pistachio target is a MIPS interaptiv based SoC developed by
Imagination Technologies. It includes blocks for i2c, spi, audio,
usb and WiFi.
This also adds the base support for the 'Creator Ci40 (marduk)'
device which uses the Pistachio SoC to create an IoT hub by
including Bluetooth, WiFi and 6lowpan on one board. Additionally 2x
Mikrobus ports are available to expand with further RF technologies
or add sensors. You can find out more here http://creatordev.io.
Note, this commit is just the initial board support hence the
following are not expected to work yet:
* WiFi
* Bluetooth
* 6lowpan
* Audio
* Mikrobus uarts, user leds (clock dependency of 6lowpan chip)
The aim of this commit is to essentially have the same level of
support that currently exists in the mainline kernel.
Signed-off-by: Abhijit Mahajani <Abhijit.Mahajani@imgtec.com>
Signed-off-by: Francois Berder <francois.berder@imgtec.com>
Signed-off-by: Ian Pozella <Ian.Pozella@imgtec.com>
Signed-off-by: Mayank Sirotiya <Mayank.Sirotiya@imgtec.com>
Signed-off-by: Sean Kelly <Sean.Kelly@imgtec.com>
This adds kernel support for the Pistachio SoC and the Marduk (Ci40)
board which uses it.
Much of the code for Pistachio has been upstreamed however some
patches are still required to boot from the Marduk board:
* spi bug fixes
* dma bug fixes
* pistachio internal clock tree bug fixes
* spi-nand implementation
* dts based mtd device naming scheme
* dts backports and bug fixes
Signed-off-by: Abhijit Mahajani <Abhijit.Mahajani@imgtec.com>
Signed-off-by: Francois Berder <francois.berder@imgtec.com>
Signed-off-by: Ian Pozella <Ian.Pozella@imgtec.com>
This patch adds support for AVM FRITZ!Box 4040.
hardware highlights:
SOC: IPQ4018 / QCA Dakota
CPU: Quad-Core ARMv7 Processor rev 5 (v7l) Cortex-A7
DRAM: 256 MiB Nanya NT5CC128M16IP
FLASH: 32 MiB MXIC MX25L25635FMI
ETH: Qualcomm Atheros QCA8075 Gigabit Switch (4 x LAN, 1 x WAN)
USB: 1 x 3.0 (via Synopsys DesignWare DWC3 controller in the SoC)
1 x 2.0 (via Synopsys DesignWare DWC3 controller in the SoC)
WLAN1: Qualcomm Atheros QCA4018 2.4GHz 802.11bgn 2:2x2
WLAN2: Qualcomm Atheros QCA4018 5GHz 802.11a/n/ac 2:2x2
INPUT: one WLAN and one WPS button
LEDS: Power, WAN/Internet, WIFI, INFO (red and amber) and LAN.
Serial:
WARNING: The serial port needs a TTL/RS-232 v3.3 level converter!
The Serial setting is 115200-8-N-1. The SoC's serial port is right
next to the MXIC FLASH chip. The board has a unpopulated 1x4 0.1"
header for it. Use a multimeter to figure out the pinout!
This board currently needs an additional u-boot image in order to boot
properly. Booting with EVA isn't possible ATM.
Install Procedure:
0. It's highly recommended to connect to the serial port.
The serial settings are listed above.
1. install a u-boot image for AVM Fritz!Box 4040
(see <https://github.com/chunkeey/FritzBox-4040-UBOOT/releases> and
<https://github.com/chunkeey/FritzBox-4040-UBOOT/blob/master/upload-to-f4040.sh>)
2. upload the initramfs.itb image via tftp (u-boot listens to
192.168.1.1 - use binary transfer mode!)
3. connect to the FB4040 and use sysupgrade sysupgrade.bin
to install the image.
Works:
- Switch and Ethernet (99%)
- Buttons (WLAN, WPS)
- FLASH (1 x 32MiB NOR Chip)
- WLAN2G and WLAN5G
- CPUFREQ scaling
- PRNG
- serial
- Crypto Accelerator
- sysupgrade (Read the flash instructions to avoid bricking)
- full LEDE Install (Read the flash instructions to avoid bricking)
- LEDs (Power, WAN, Info (red and amber), LAN)
The LEDs are connected to the QCA8075 LED ports.
The AR40xx driver contains a gpio-controller to
handle these special "GPIOs".
- USB Both 3.0 and 2.0 ports
- many packages from other ARMv7 boards
(This does include the RaspberryPi Model 2!)
- ...
Not planned:
- WAN<->LAN short-cut
- Qualcomm Secure Execution Environment
- ...
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John Crispin <john@phrozen.org>
This adds support for describing GPIO chips placed on PCIe cards. Thanks
to this we get working 2.4 GHz LED on Tenda AC9.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This is the standard way we handle this. Please note (it seems) I could
drop few symbols as they are hidden under (disabled) DRM_LEGACY now.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Add back support for the independent_clocks definition that has been
removed between kernel 4.4 and 4.9 by upstream commits
eb96924acddc709db58221c210ca05cd9effb1df and
e86eee6bc2aaa6b3637f6497b26beee09a91bde9
* extend the new cpufreq_dt_platform_data definition in cpufreq-dt.h
* revert the removal of its usage in cpufreq-dt.c
* use new cpufreq-dt.h in qcom-cpufreq.c
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
For IPQ806x targets, TZ protects the registers that are used to
configure the routing of interrupts to a target processor.
To resolve this, this patch uses scm call to route GPIO interrupts
to application processor. Also the scm call interface is changed.
Signed-off-by: Pavel Kubelun <be.dissent@gmail.com>
At the moment as a workaround definition for scm firmware in DT is used as if it is
apq8064 board. This leads to incomplete scm firmware initialization and as a result
cpuidle driver fails to configure.
By design unlike other qcom boards ipq do not use clocks to connect to scm.
Considering this we're removing from DT and scm driver clocks for ipq boards.
As a result cpuidle does not produce errors about failed configuration anymore.
Signed-off-by: Pavel Kubelun <be.dissent@gmail.com>
This fixes GIC interrupts (required before switching to 4.9), adds few
new entires & introduces DTS for Archer C5.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This patch adds support for the Zbtlink ZBT-WE2026.
Specification:
- SoC: MediaTek MT7620N (580MHz)
- RAM: 64 MiB
- Flash: 8 MiB SPI
- LAN: 4x100M
- WAN: 1x100M
Installation through bootloader webserver:
- With the power unplugged press and hold reset button.
- Plug power and hold reset button until LED starts to blink.
- Install sysupgrade image using web interface on 192.168.1.1.
Signed-off-by: Vaclav Svoboda <svoboda@neng.cz>
SMP state is generally affected by
- CONFIG_SMP build-time kernel configuration option and
- 'nosmp' runtime kernel commandline option
The SMP state within vpe-mt.c is determined by CONFIG_SMP option.
A runtime check is needed if VPE functionality
should be used with a kernel image that supports SMP.
This fix introduces a check for 'nosmp' command line option
if CONFIG_SMP kernel configuration option is enabled.
Note: This patch is needed to use lantiq FXS if CONFIG_MIPS_MT_SMP
(that activates CONFIG_SMP) is enabled within kernel configuration
and the 'nosmp' command line argument is given to disable SMP at runtime.
Without this patch CONFIG_MIPS_MT_SMP must be disabled before using FXS.
With this patch setting the 'nosmp' parameter is enough.
In general, concurrent usage of FXS and SMP
is incompatible and will cause kernel panics.
Signed-off-by: Stefan Koch <stefan.koch10@gmail.com>
It is not needed for anything on the system and skipping this saves some
build time, especially in cases where there is nothing to do.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The problem is caused by the incorrect handling of the parent inode's
i_nlink count for the dentry to be RENAME_EXCHANGED. There are 3 cases
to consider. Assume we want to RENAME_EXCHANGE struct dentry *a and
struct dentry *b, and inode_a is pointed to by dentry_a, inode_b is
pointed to by dentry_b:
1. If inode_a is a directory, but inode_b isn't, then we must decrease
the i_nlink count of old_dir_i, and increase the i_nlink of new_dir_i.
2. If inode_a isn't a directory, but inode_b is a directory, then we
must increase the i_nlink of old_dir_i, and decrease the i_nlink count
of new_dir_i.
3. If the types of inode_a and inode_b are the same, we don't change the
i_nlink for either old_dir_i or new_dir_i.
Signed-off-by: Jing Qiu <aqiu0720@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Switch to the common LED related status_led_blink_* functions in
set_state() as it's done in most of other targets.
Also, use "status_led_on" instead of "status_led_set_heartbeat"
and incorrect "status_led_set_on" in the "done" state.
Moreover, remove outdated comment from the script.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
When the device name doesn't already contain "RouterBOARD", this patch adds
this string to the machine name.
Most NOR devices already have "RouterBOARD" in their hardware-stored device name,
but not all of them.
This patch also makes the code more robust against buffer overflows.
Signed-off-by: Thibaut VARENE <hacks@slashdirt.org>
This driver supports CPU-specific idle features on recent Intel
processors. It does not conflict with the ACPI idle driver and
that driver will continue to be used for unsupported and non-Intel
processors.
Signed-off-by: Michael Marley <michael@michaelmarley.com>
The x86_64 build already has the k10temp driver for AMD processors
built in, so this patch adds the coretemp driver for the same
functionality on Intel processors.
Signed-off-by: Michael Marley <michael@michaelmarley.com>
SMP state is generally affected by
- CONFIG_SMP build-time kernel configuration option and
- 'nosmp' runtime kernel commandline option
The SMP state within vpe-mt.c is determined by CONFIG_SMP option.
A runtime check is needed if VPE functionality
should be used with a kernel image that supports SMP.
This fix introduces a check for 'nosmp' command line option
if CONFIG_SMP kernel configuration option is enabled.
Note: This patch is needed to use lantiq FXS if CONFIG_MIPS_MT_SMP
(that activates CONFIG_SMP) is enabled within kernel configuration
and the 'nosmp' command line argument is given to disable SMP at runtime.
Without this patch CONFIG_MIPS_MT_SMP must be disabled before using FXS.
With this patch setting the 'nosmp' parameter is enough.
In general, concurrent usage of FXS and SMP
is incompatible and will cause kernel panics.
Signed-off-by: Stefan Koch <stefan.koch10@gmail.com>
The available amount of coherent DMA memory is very limited. On Linux
4.4 this issue was worked around by increasing the pool size.
It turns out that using coherent memory here is completely unnecessary.
This change reworks the driver code to use kzalloc+dma_map_single
instead.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Do not patch upstream files, overwrite them entirely. The upstream files
are buggy for a number of devices and this significantly simplifies the
patch structure
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: John Crispin <john@phrozen.org>
The Netgear WNDR4300, equipped with an Atheros AR8327 Gigabit Switch,
has two LEDs on each port for monitoring LAN activity, but it currently
only uses one. Fix the configuration to use both.
The patch provides this new configuration:
- green LED: 1 Gbps link, 4Hz blink frequency
- amber LED: 10/100 Mbps link. 4Hz for 100Mbps, 2Hz for 10Mbps
Signed-off-by: Daniel Gonzalez Cabanelas <dgcbueu@gmail.com>
At now there is no general rule about what part of (or whole) machine
name string should be used for board name assignment/detection and every
target handles this in a different way.
For most of the boards in ar71xx we already use only part of the string,
generally without the vendor name.
This shortens wildcards patterns in case statement for board name
assignment, wherever possible (e.g. where it won't be misleading).
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
Be consistent and always use double quotes for case statement patterns,
as in other targets. With this approach it should be less confusing for
users adding support for new devices.
Also, be consistent with MikroTik boards wildcard pattern.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
