Tsense driver for ipq806x have various problem.
- Emit wrong error. On probing of this driver, nvmem driver can be
not ready and this cause a EDEFER error. Actually this is not an
error as the kernel will retry to probe the driver after the
nvmem driver is loaded.
- Use uninitialized value on trigger of critical temp
- Doesn't free allocated memory
Because of this, rework the driver and improve it by removing extra
load of data.
Change the logic of loading data. Use the backup calib data only
when the calib data is not present. As the calibration is only
needed to set the temp offset, we don't really need to read
both calib data and set the offset based only on the backup one.
Also change how the notifier function work. At times when we
output the trigger message, we already have read the temp so
remove the extra read and the wrong uninitialized data that
probably caused a kernel panic for null pointer exception.
(Think we never experience this bug because the router
never reached that temp ever... So just lucky)
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
The config name for cpufreq driver has changed.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
The new driver use opp table to register frequency.
Drop psv bindings as they are not used anymore.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
The new driver use opp table to register frequency.
Drop psv bindings as they are not used anymore.
Adds speedbin definition for nvmem driver
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
This patch has been proposed but never actually merged to
mainline. It was accepted but never re proposed by the
creator.
Rework it, fix kernel panic cause by double kfree.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Backport patch applied to qcom-cpufreq-kryo
driver as krait cpu will base on this driver.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Drop old cpufreq as now we have new driver that
can use normal kernel opp definition
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Rework 0052-PM-OPP-Update-the-voltage-tolerance-when-adjusting-t
to reflect changes upstream.
- Skip unnecessary allocation of buffer to set u_volt
- Change opp u_volt directly
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Update 0049-PM-OPP-Support-adjusting-OPP-voltages-at-runtime with
upstream version.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
It has been notice a buf in L2 cache scaling where the scaling is not
done proprely if the frequency is set to the initial state before
the new frequency.
From: https://patchwork.kernel.org/patch/10565443/
* The clocks are set to aux clock rate first to make sure the
* secondary mux is not sourcing off of QSB. The rate is then set to
* two different rates to force a HFPLL reinit under all
* circumstances.
In the initial stage of boot to force a new frequency to apply, is
needed to first set the frequency back to the lowest one (aux_rate)
and then to the target one. This force and make sure the controller
actually switch the frequency to the right one. Apply the same
mechanism to L2 frequency scaling. Before scaling to the target
frequency, first set the frequency to the aux_rate to force the
transition, then scale it to the target frequency. Doing the wrong way
can produce unexpected results and could lock the scaling mechanism
until a full reboot is done (Causing a full reset by the krait-cc driver)
From: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=77612720a2362230af726baa4149c40ec7a7fb05
When the Hfplls are reprogrammed during the rate change,
the primary muxes which are sourced from the same hfpll
for higher frequencies, needs to be switched to the 'safe
secondary mux' as the parent for that small window. This
is done by registering a clk notifier for the muxes and
switching to the safe parent in the PRE_RATE_CHANGE notifier
and back to the original parent in the POST_RATE_CHANGE notifier.
This should apply also to L2 scaling... as we can't relly use
the notifier, we manually do this on L2 scaling.
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [nbg6817/ipq8065]
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
edad0d6 version: bump snapshot
0e38a3c compat: ipv6_dst_lookup_flow was backported to 5.3 and 5.4
2e52c41 wg-quick: linux: use already configured addresses instead of in-memory
3721521 tools: adjust wg.8 syntax for consistency in COMMANDS section
21a1498 wg-quick: linux: try both iptables(8) and nft(8) on teardown
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
According to many bugreports [0][1][2] the default ath10k-ct kernel
module is unusable on devices with just 64 MiB RAM or with 128 MiB and
dual ath10k cards. The target boards boot but eventually oom-killer
starts to interfere with normal operation, so the current state is
effectively broken.
Since the two patches in question have a performance impact (and
possibly some other unexpected side-effects) a dedicated build variant
is added so that users of the low RAM devices can still benefit from all
the ath10k-ct advantages.
According to testing [3] results, the issue can be experienced even with
"a 256MB device with three radios". Measured performance impact of
implementing small buffers was lowering "the maximum 5 GHz throughput on
an IPQ40xx device without RPS/XPS optimizations from 494/432 Mbit/s for
TCP transfers (download/upload) to 438/343 Mbit/s"
The patches were apparently inspired by QSDK tweaks used by ODMs for the
affected devices.
[0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html
[1] https://github.com/openwrt/openwrt/pull/1077
[2] https://bugs.openwrt.org/index.php?do=details&task_id=2664
[3] https://github.com/freifunk-gluon/gluon/pull/1440#issue-195607701
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
[Remove double CONFIG_ATH10K-CT_LEDS entry]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Deactivate CONFIG_SFP for kernel 4.19 in the generic configuration.
The CONFIG_SFP configuration option was not set to anything in the
ath79 build for me, set it to deactivated by default.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The factory image for the dlink_dir-615-e4 is getting too big which makes
the full ath79 tiny build fail, deactivate it by default.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Don't build with uClibc-ng. It's totally unsupported as several functions
are missing.
Make the musl libc support conditional.
Fix hash with make check FIXUP=1. Apparently I based the Makefile off of
libedit and forgot to fix the hash.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Fixes: 856ea2bad3 ("libcxx: Add package")
The device label contains:
E01: 74:4D:28:xx:xx:30
E05: 74:4D:28:xx:xx:34
The first value corresponds to the address set in hard_config 0x10.
That one is taken for the label MAC address.
Signed-off-by: Sven Roederer <freifunk@it-solutions.geroedel.de>
The node pinctrl0 is already set up in the SOC DTSI files, but
defined again as member of pinctrl in most of the device DTS(I)
files. This patch removes this redundancy for the entire ramips
target.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Unloading and reloading the modules fails, as platform_device_put() does not
release resources fully.
root@OpenWrt:/# insmod i2c-gpio-custom bus0=0,18,0,5
[ 196.860620] Custom GPIO-based I2C driver version 0.1.1
[ 196.871162] ------------[ cut here ]------------
[ 196.880517] WARNING: CPU: 0 PID: 1365 at fs/sysfs/dir.c:31 0x80112158
[ 196.893431] sysfs: cannot create duplicate filename '/devices/platform/i2c-gpio.0'
...
[ 197.513200] kobject_add_internal failed for i2c-gpio.0 with -EEXIST, don't try to register things with the same name in the same directory.
This patch fixes it by replacing platform_device_put() to
platform_device_unregister().
Fixes: da77408537 ("i2c-gpio-custom: minor bugfix")
Fixes: 3bc81edc70 ("package: fix w1-gpio-custom package (closes#6770)")
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
The rpcd service is an important service, but if the service stops
working for any reason, no one will ever respawn that service. With this
commit, the procd service will monitor if the rpcd service
is running. If the rpcd service has crashed, then
procd respawns the rpcd service.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Several CMake packages such as log4cplus and protobuf(-c) install to
lib64 instead of lib on some hosts. This completely breaks rpath linking.
Override it globally to avoid fixing each package individually.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Tested-by: Sebastian Kemper <sebastian_ml@gmx.net>
The USB descriptor parsing in adb fails to detect SuperSpeed devices
because of the SuperSpeed Endpoint Companion Descriptor. This
cherry-picks the upstream fix for the problem.
Unfortunately there never were a release with this fix before the
conversion to C++, so upgrading to a newer version isn't an option.
This makes adb work with SuperSpeed devices like the Sierra Wireless
EM7565. Tested and verified.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
- both packages provide ca-certs
- make ca-bundle the default provider
This should allow easy transition between these two forms of CA certificates storage
Signed-off-by: Maxim Storchak <m.storchak@gmail.com>
Currently in OpenWrt, there are two libc++: libstdcpp and uClibc++. The
former is huge and the latter supports only C++98 with some basic support
for C++11. Those C++ versions seem to be specific to the compiler version
libcxx supports C++11 and above while being much smaller than libstdcpp.
On mt7621, these are the sizes of the ipks that I get:
libstdcpp: 460786
libcxx: 182881
uClibc++:67720
libcxx is faster than uClibc++ and is under active development as part of
the LLVM project while uClibc++ is effectively dead.
This PR modifies uclibc++.mk to expose the make menuconfig option. Further
cleanup is beyond the scope of this PR. What that means is, this is not
used by default.
A g++-libcxx wrapper based on the uClibc++ one was added. Works the same
way.
Compile tested with all packages that use uclibc++.mk in their Makefiles
under mipsel_24kc. kismet fails compilation but that package needs to be
cleaned up and updated.
Runtime tested with gddrescue, gdisk, dcwapd, bonnie++, and aircrack-ng
on a TP-Link Archer C7v2.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
VMWare ESXI 6.5 and above is not compatible with
subformat=monolithicSparse (The default qemu-img convert -O VMDK option).
Monolithic Sparse vmdk can be imported, but issues occur when running
sysupgrade with new images and other tasks that modify the file system
(issues like Kernel panics, reboot loops, sometimes crashing the Host ESXI
box).
This change creates an additional VMDK output file for ESXI that sets the
subformat to monlithicFlat, and the adapter_type to the SCSI lsilogic
controller.
This change existed back on:
25e36d379e
But it looks like the change was removed when refactoring occurred with:
5f6a2732f892b6229473576d89cc963ae9c97d5d
Signed-off-by: John Sommerville <jsommerville@untangle.com>
Its way more trouble to update this to a newer version of qemu than it
is to backport the two additional features we need.
Signed-off-by: Brett Mastbergen <bmastbergen@untangle.com>
apache mirrors holds only latest releases, to download
older releases, one must use archive.apache.org to get
them.
Signed-off-by: Jiri Kastner <cz172638@gmail.com>
The release notes since last time for wave-1:
* No changes to wave-1, but I make a version .014 copy anyway to keep
the makefile in sync.
The release notes since last time for wave-2:
* December 16, 2019: Wave-2 has a fix to make setting txpower work
better. Before setting the power was ignored at
least some of the time (it also appeared to work
mostly, so I guess it was being correctly set in
other ways).
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
This backports the patch for GCC PR target/89587 (gcc's rs6000
configuration unconditionally sets MULTIARCH_DIRNAME, even when
multiarch is disabled).
This currently affects apm821xx and may cause issues when
cross-compiling packages, e.g. Python 3[1].
This includes patches for GCC 8 (with the changelog diff removed);
this change is already included in GCC 9.2 and 7.5.
[1]: https://github.com/openwrt/packages/issues/10552
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
[Removed patch for GCC 7.4.0, GCC 7.5.0 already contains this]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
led2l and led2h value is incorrectly set by led3l and led3h.
Bug was introduced in commit: 863e79f8d5
Signed-off-by: Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Fixes: 863e79f8d5 ("lantiq: add support for kernel 4.9")
