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>
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>
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>
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>
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>
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>
Thomas Reifferscheid