aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/ipq806x/patches-4.19/0063-4-ip806x-tsense-rework-driver.patch
Commit message (Collapse)AuthorAgeFilesLines
* ipq806x: remove support for kernel 4.19Adrian Schmutzler2020-10-191-107/+0
| | | | | | | | | | | | | The target uses 5.4 as default kernel since 04/2020. Kernel 4.19 support is not really maintained anymore, and there has been a lot of changes between 4.19 and 5.4 on this target. Despite, new devices are typically added for 5.4 only anyway. Thus, make maintaining of old stuff and reviewing of new stuff easier by removing support for kernel 4.19. Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
* kernel: bump 4.19 to 4.19.93Hauke Mehrtens2020-01-051-3/+3
| | | | | | | | | | | | | | Refreshed all patches. The patch hack-4.19/550-loop-better-discard-for-block-devices.patch was replaced with an new version of the patch from: https://lore.kernel.org/patchwork/patch/1153625/ https://lore.kernel.org/patchwork/patch/1153626/ Compile-tested on: ipq40xx, lantiq Runtime-tested on: ipq40xx, lantiq Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* ipq806x: rework ipq806x specific tsense temp driverAnsuel Smith2019-12-261-0/+107
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>