summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-07-28thermal/drivers/tegra: Remove get_trend functionDaniel Lezcano
The get_trend function does already what the generic framework does. Remove it. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20220616202537.303655-2-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28thermal/drivers/qcom: Remove get_trend functionDaniel Lezcano
There is a get_trend function which is a wrapper to call a private get_trend function. However, this private get_trend function is not assigned anywhere. Remove this dead code. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Amit Kucheria <amitk@kernel.org> Link: https://lore.kernel.org/r/20220616202537.303655-1-daniel.lezcano@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28dt-bindings: thermal: rcar-gen3-thermal: Add r8a779f0 supportWolfram Sang
Add support for R-Car S4. The S4 IP differs a bit from its siblings in such way that it has 3 out of 4 TSC nodes for Linux and the interrupts are not routed to the INTC-AP but to the ECM. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220610201701.7946-2-wsa+renesas@sang-engineering.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28dt-bindings: thermal: rcar-gen3-thermal: use positive logicWolfram Sang
When handling the V3U/r8a779a0 exception, avoid using 'not:' because then its subschemas are far away in the 'else:' branch. Keep them together using positive logic. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20220610201701.7946-1-wsa+renesas@sang-engineering.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28dt-bindings: thermal: qcom,spmi-temp-alarm: convert to dtschemaKrzysztof Kozlowski
Convert the Qualcomm QPNP PMIC Temperature Alarm to DT Schema. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220608112702.80873-1-krzysztof.kozlowski@linaro.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/rcar_gen3_thermal: Improve logging during probeWolfram Sang
When setting up a new board, a plain "Can't register thermal zone" didn't help me much because the thermal zones in DT were all fine. I just had a sensor entry too much in the parent TSC node. Reword the failure/success messages to contain the sensor number to make it easier to understand which sensor is affected. Example output now: rcar_gen3_thermal e6198000.thermal: Sensor 0: Loaded 1 trip points rcar_gen3_thermal e6198000.thermal: Sensor 1: Loaded 1 trip points rcar_gen3_thermal e6198000.thermal: Sensor 2: Loaded 1 trip points rcar_gen3_thermal e6198000.thermal: Sensor 3: Can't register thermal zone Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20220610200500.6727-1-wsa+renesas@sang-engineering.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28MAINTAINERS: add include/dt-bindings/thermal to THERMALLukas Bulwahn
Maintainers of the directory Documentation/devicetree/bindings/thermal are also the maintainers of the corresponding directory include/dt-bindings/thermal. Add the file entry for include/dt-bindings/thermal to the appropriate section in MAINTAINERS. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20220613124309.28790-1-lukas.bulwahn@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/devfreq_cooling: Extend the devfreq_cooling_device with opsLukasz Luba
Remove unneeded global variable devfreq_cooling_ops which is used only as a copy pattern. Instead, extend the struct devfreq_cooling_device with the needed ops structure. This also simplifies the allocation/free code during the setup/cleanup. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220613124327.30766-5-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/cpufreq_cooling: Update outdated commentsLukasz Luba
The code has moved and left some comments stale. Update them where there is a need. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220613124327.30766-4-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/cpufreq_cooling : Refactor thermal_power_cpu_get_power tracingLukasz Luba
Simplify the thermal_power_cpu_get_power trace event by removing complicated cpumask and variable length array. Now the tools parsing trace output don't have to hassle to get this power data. The simplified format version uses 'policy->cpu'. Remove also the 'load' information completely since there is very little value of it in this trace event. To get the CPUs' load (or utilization) there are other dedicated trace hooks in the kernel. This patch also simplifies and speeds-up the main cooling code when that trace event is enabled. Rename the trace event to avoid confusion of tools which parse the trace file. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220613124327.30766-3-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28drivers/thermal/cpufreq_cooling: Use private callback ops for each cooling ↵Lukasz Luba
device It is very unlikely that one CPU cluster would have the EM and some other won't have it (because EM registration failed or DT lacks needed entry). Although, we should avoid modifying global variable with callbacks anyway. Redesign this and add safety for such situation. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20220613124327.30766-2-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2022-07-28tty: amiserial: Fix comment typoJason Wang
The double `should' is duplicated in line 15, remove one. Signed-off-by: Jason Wang <wangborong@cdjrlc.com> Link: https://lore.kernel.org/r/20220715054401.9870-1-wangborong@cdjrlc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-28firmware_loader: Replace kmap() with kmap_local_page()Fabio M. De Francesco
The use of kmap() is being deprecated in favor of kmap_local_page(). Two main problems with kmap(): (1) It comes with an overhead as mapping space is restricted and protected by a global lock for synchronization and (2) kmap() also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. kmap_local_page() is preferred over kmap() and kmap_atomic(). Where it cannot mechanically replace the latters, code refactor should be considered (special care must be taken if kernel virtual addresses are aliases in different contexts). With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). Call kmap_local_page() in firmware_loader wherever kmap() is currently used. In firmware_rw() use the helpers copy_{from,to}_page() instead of open coding the local mappings + memcpy(). Successfully tested with "firmware" selftests on a QEMU/KVM 32-bits VM with 4GB RAM, booting a kernel with HIGHMEM64GB enabled. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Suggested-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20220714235030.12732-1-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-28sysfs docs: ABI: Fix typo in commentSlark Xiao
Fix typo in the comment Signed-off-by: Slark Xiao <slark_xiao@163.com> Link: https://lore.kernel.org/r/20220721020623.20974-1-slark_xiao@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-28kobject: fix Kconfig.debug "its" grammarRandy Dunlap
Use the possessive "its" instead of the contraction "it's" where appropriate. Cc: Russell King <linux@armlinux.org.uk> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220715015959.12657-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-28Merge tag 'asoc-fix-v5.19-rc8' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.19 A few more small fixes, they could all wait for the merge window if you prefer.
2022-07-28swiotlb: fix passing local variable to debugfs_create_ulong()Tianyu Lan
Debugfs node will be run-timely checked and so local variable should be not passed to debugfs_create_ulong(). Fix it via debugfs_create_file() to create io_tlb_used node and calculate used io tlb number with fops_io_tlb_used attribute. Fixes: 20347fca71a3 ("swiotlb: split up the global swiotlb lock") Signed-off-by: Tianyu Lan <tiala@microsoft.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-07-28dma-mapping: reformat comment to suppress htmldoc warningLogan Gunthorpe
make html doc reports a cryptic warning with the commit named below: kernel/dma/mapping.c:258: WARNING: Option list ends without a blank line; unexpected unindent. Seems the parser is a bit fussy about the tabbing and having a single space tab causes the warning. To suppress the warning add another tab to the list and reindent everything. Fixes: 7c2645a2a30a ("dma-mapping: allow EREMOTEIO return code for P2PDMA transfers") Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2022-07-28drivers: lkdtm: fix clang -Wformat warningJustin Stitt
When building with Clang we encounter the following warning (ARCH=hexagon + CONFIG_FRAME_WARN=0): | ../drivers/misc/lkdtm/bugs.c:107:3: error: format specifies type | 'unsigned long' but the argument has type 'int' [-Werror,-Wformat] | REC_STACK_SIZE, recur_count); | ^~~~~~~~~~~~~~ Cast REC_STACK_SIZE to `unsigned long` to match format specifier `%lu` as well as maintain symmetry with `#define REC_STACK_SIZE (_AC(CONFIG_FRAME_WARN, UL) / 2)`. Link: https://github.com/ClangBuiltLinux/linux/issues/378 Fixes: 24cccab42c419 ("lkdtm/bugs: Adjust recursion test to avoid elision") Reported-by: Nathan Chancellor <nathan@kernel.org> Suggested-by: Nathan Chancellor <nathan@kernel.org> Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Justin Stitt <justinstitt@google.com> Link: https://lore.kernel.org/r/20220721215706.4153027-1-justinstitt@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-28char: remove VR41XX related char driverThomas Bogendoerfer
Commit d3164e2f3b0a ("MIPS: Remove VR41xx support") removed support for MIPS VR41xx platform, so remove exclusive drivers for this platform, too. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://lore.kernel.org/r/20220716130802.11660-1-tsbogend@alpha.franken.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-28ARM: 9220/1: amba: Remove deferred device additionSaravana Kannan
The uevents generated for an amba device need PID and CID information that's available only when the amba device is powered on, clocked and out of reset. So, if those resources aren't available, the information can't be read to generate the uevents. To workaround this requirement, if the resources weren't available, the device addition was deferred and retried periodically. However, this deferred addition retry isn't based on resources becoming available. Instead, it's retried every 5 seconds and causes arbitrary probe delays for amba devices and their consumers. Also, maintaining a separate deferred-probe like mechanism is maintenance headache. With this commit, instead of deferring the device addition, we simply defer the generation of uevents for the device and probing of the device (because drivers needs PID and CID to match) until the PID and CID information can be read. This allows us to delete all the amba specific deferring code and also avoid the arbitrary probing delays. Cc: Rob Herring <robh@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Nicolas Saenz Julienne <nsaenz@kernel.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: patches@armlinux.org.uk Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-07-28ARM: 9219/1: fix undeclared soft_restartBen Dooks
The soft_restart() is declared in <asm/system_misc.h> so include that to fix the following sparse warning: arch/arm/kernel/reboot.c:78:6: warning: symbol 'soft_restart' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-07-28ARM: 9218/1: dma-mapping: fix pointer/integer warningBen Dooks
Fix the use of a pointer assignment from integer where false is being used instead of NULL. Fix the following warning by usign NULL: arch/arm/mm/dma-mapping.c:712:52: warning: Using plain integer as NULL pointer Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-07-28ARM: 9217/1: add definition of arch_irq_work_raise()Ben Dooks
The arm <asm/irq_work.h> does not define arch_irq_work_raise() so is triggering the following sparse warning. Add a definiton to fix this: kernel/irq_work.c:70:13: warning: symbol 'arch_irq_work_raise' was not declared. Should it be static? arch/arm/kernel/smp.c:582:6: warning: symbol 'arch_irq_work_raise' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-07-28ARM: 9203/1: kconfig: fix MODULE_PLTS for KASAN with KASAN_VMALLOCLecopzer Chen
When we run out of module space address with ko insertion, and with MODULE_PLTS, module would turn to try to find memory from VMALLOC address space. Unfortunately, with KASAN enabled, VMALLOC doesn't work without KASAN_VMALLOC, thus select KASAN_VMALLOC by default. 8<--- cut here --- Unable to handle kernel paging request at virtual address bd300860 [bd300860] *pgd=41cf1811, *pte=41cf26df, *ppte=41cf265f Internal error: Oops: 80f [#1] PREEMPT SMP ARM Modules linked in: hello(O+) CPU: 0 PID: 89 Comm: insmod Tainted: G O 5.16.0-rc6+ #19 Hardware name: Generic DT based system PC is at mmioset+0x30/0xa8 LR is at 0x0 pc : [<c077ed30>] lr : [<00000000>] psr: 20000013 sp : c451fc18 ip : bd300860 fp : c451fc2c r10: f18042cc r9 : f18042d0 r8 : 00000000 r7 : 00000001 r6 : 00000003 r5 : 01312d00 r4 : f1804300 r3 : 00000000 r2 : 00262560 r1 : 00000000 r0 : bd300860 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 43e9406a DAC: 00000051 Register r0 information: non-paged memory Register r1 information: NULL pointer Register r2 information: non-paged memory Register r3 information: NULL pointer Register r4 information: 4887-page vmalloc region starting at 0xf1802000 allocated at load_module+0x14f4/0x32a8 Register r5 information: non-paged memory Register r6 information: non-paged memory Register r7 information: non-paged memory Register r8 information: NULL pointer Register r9 information: 4887-page vmalloc region starting at 0xf1802000 allocated at load_module+0x14f4/0x32a8 Register r10 information: 4887-page vmalloc region starting at 0xf1802000 allocated at load_module+0x14f4/0x32a8 Register r11 information: non-slab/vmalloc memory Register r12 information: non-paged memory Process insmod (pid: 89, stack limit = 0xc451c000) Stack: (0xc451fc18 to 0xc4520000) fc00: f18041f0 c04803a4 fc20: c451fc44 c451fc30 c048053c c0480358 f1804030 01312cff c451fc64 c451fc48 fc40: c047f330 c0480500 f18040c0 c1b52ccc 00000001 c5be7700 c451fc74 c451fc68 fc60: f1802098 c047f300 c451fcb4 c451fc78 c026106c f180208c c4880004 00000000 fc80: c451fcb4 bf001000 c044ff48 c451fec0 f18040c0 00000000 c1b54cc4 00000000 fca0: c451fdf0 f1804268 c451fe64 c451fcb8 c0264e88 c0260d48 ffff8000 00007fff fcc0: f18040c0 c025cd00 c451fd14 00000003 0157f008 f1804258 f180425c f1804174 fce0: f1804154 f180424c f18041f0 f180414c f1804178 f18041c0 bf0025d4 188a3fa8 fd00: 0000009e f1804170 f2b18000 c451ff10 c0d92e40 f180416c c451feec 00000001 fd20: 00000000 c451fec8 c451fe20 c451fed0 f18040cc 00000000 f17ea000 c451fdc0 fd40: 41b58ab3 c1387729 c0261c28 c047fb5c c451fe2c c451fd60 c0525308 c048033c fd60: 188a3fb4 c3ccb090 c451fe00 c3ccb080 00000000 00000000 00016920 00000000 fd80: c02d0388 c047f55c c02d0388 00000000 c451fddc c451fda0 c02d0388 00000000 fda0: 41b58ab3 c13a72d0 c0524ff0 c1705f48 c451fdfc c451fdc0 c02d0388 c047f55c fdc0: 00016920 00000000 00000003 c1bb2384 c451fdfc c3ccb080 c1bb2384 00000000 fde0: 00000000 00000000 00000000 00000000 c451fe1c c451fe00 c04e9d70 c1705f48 fe00: c1b54cc4 c1bbc71c c3ccb080 00000000 c3ccb080 00000000 00000003 c451fec0 fe20: c451fe64 c451fe30 c0525918 c0524ffc c451feb0 c1705f48 00000000 c1b54cc4 fe40: b78a3fd0 c451ff60 00000000 0157f008 00000003 c451fec0 c451ffa4 c451fe68 fe60: c0265480 c0261c34 c451feb0 7fffffff 00000000 00000002 00000000 c4880000 fe80: 41b58ab3 c138777b c02652cc c04803ec 000a0000 c451ff00 ffffff9c b6ac9f60 fea0: c451fed4 c1705f48 c04a4a90 b78a3fdc f17ea000 ffffff9c b6ac9f60 c0100244 fec0: f17ea21a f17ea300 f17ea000 00016920 f1800240 f18000ac f17fb7dc 01316000 fee0: 013161b0 00002590 01316250 00000000 00000000 00000000 00002580 00000029 ff00: 0000002a 00000013 00000000 0000000c 00000000 00000000 0157f004 c451ffb0 ff20: c1719be0 aed6f410 c451ff74 c451ff38 c0c4103c c0c407d0 c451ff84 c451ff48 ff40: 00000805 c02c8658 c1604230 c1719c30 00000805 0157f004 00000005 c451ffb0 ff60: c1719be0 aed6f410 c451ffac c451ff78 c0122130 c1705f48 c451ffac 0157f008 ff80: 00000006 0000005f 0000017b c0100244 c4880000 0000017b 00000000 c451ffa8 ffa0: c0100060 c02652d8 0157f008 00000006 00000003 0157f008 00000000 b6ac9f60 ffc0: 0157f008 00000006 0000005f 0000017b 00000000 00000000 aed85f74 00000000 ffe0: b6ac9cd8 b6ac9cc8 00030200 aecf2d60 a0000010 00000003 00000000 00000000 Backtrace: [<c048034c>] (kasan_poison) from [<c048053c>] (kasan_unpoison+0x48/0x5c) [<c04804f4>] (kasan_unpoison) from [<c047f330>] (__asan_register_globals+0x3c/0x64) r5:01312cff r4:f1804030 [<c047f2f4>] (__asan_register_globals) from [<f1802098>] (_sub_I_65535_1+0x18/0xf80 [hello]) r7:c5be7700 r6:00000001 r5:c1b52ccc r4:f18040c0 [<f1802080>] (_sub_I_65535_1 [hello]) from [<c026106c>] (do_init_module+0x330/0x72c) [<c0260d3c>] (do_init_module) from [<c0264e88>] (load_module+0x3260/0x32a8) r10:f1804268 r9:c451fdf0 r8:00000000 r7:c1b54cc4 r6:00000000 r5:f18040c0 r4:c451fec0 [<c0261c28>] (load_module) from [<c0265480>] (sys_finit_module+0x1b4/0x1e8) r10:c451fec0 r9:00000003 r8:0157f008 r7:00000000 r6:c451ff60 r5:b78a3fd0 r4:c1b54cc4 [<c02652cc>] (sys_finit_module) from [<c0100060>] (ret_fast_syscall+0x0/0x1c) Exception stack(0xc451ffa8 to 0xc451fff0) ffa0: 0157f008 00000006 00000003 0157f008 00000000 b6ac9f60 ffc0: 0157f008 00000006 0000005f 0000017b 00000000 00000000 aed85f74 00000000 ffe0: b6ac9cd8 b6ac9cc8 00030200 aecf2d60 r10:0000017b r9:c4880000 r8:c0100244 r7:0000017b r6:0000005f r5:00000006 r4:0157f008 Code: e92d4100 e1a08001 e1a0e003 e2522040 (a8ac410a) ---[ end trace df6e12843197b6f5 ]--- Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-07-28ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOCLecopzer Chen
Simply make shadow of vmalloc area mapped on demand. Since the virtual address of vmalloc for Arm is also between MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow address has already included between KASAN_SHADOW_START and KASAN_SHADOW_END. Thus we need to change nothing for memory map of Arm. This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem and support CONFIG_VMAP_STACK with KASan. Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2022-07-28dt-bindings: gpio: fsl-imx-gpio: Add i.MXRT compatiblesJesse Taube
Both the i.MXRT1170 and 1050 have the same gpio controller as "fsl,imx35-gpio". Add i.MXRT to the compatible list. Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-07-28gpio: 74xx-mmio: Use bits instead of plain numbers for flagsAndy Shevchenko
The initial code was misleading to use bitwise AND against plain number, and the commit d3054ba1db62 ("gpio: 74xx-mmio: Check MMIO_74XX_DIR_IN flag in mmio_74xx_dir_in()") missed that. Switch definitions to be defined bits for the correct comparison. Fixes: d3054ba1db62 ("gpio: 74xx-mmio: Check MMIO_74XX_DIR_IN flag in mmio_74xx_dir_in()") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2022-07-28ovl: drop WARN_ON() dentry is NULL in ovl_encode_fh()Jiachen Zhang
Some code paths cannot guarantee the inode have any dentry alias. So WARN_ON() all !dentry may flood the kernel logs. For example, when an overlayfs inode is watched by inotifywait (1), and someone is trying to read the /proc/$(pidof inotifywait)/fdinfo/INOTIFY_FD, at that time if the dentry has been reclaimed by kernel (such as echo 2 > /proc/sys/vm/drop_caches), there will be a WARN_ON(). The printed call stack would be like: ? show_mark_fhandle+0xf0/0xf0 show_mark_fhandle+0x4a/0xf0 ? show_mark_fhandle+0xf0/0xf0 ? seq_vprintf+0x30/0x50 ? seq_printf+0x53/0x70 ? show_mark_fhandle+0xf0/0xf0 inotify_fdinfo+0x70/0x90 show_fdinfo.isra.4+0x53/0x70 seq_show+0x130/0x170 seq_read+0x153/0x440 vfs_read+0x94/0x150 ksys_read+0x5f/0xe0 do_syscall_64+0x59/0x1e0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 So let's drop WARN_ON() to avoid kernel log flooding. Reported-by: Hongbo Yin <yinhongbo@bytedance.com> Signed-off-by: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com> Signed-off-by: Tianci Zhang <zhangtianci.1997@bytedance.com> Fixes: 8ed5eec9d6c4 ("ovl: encode pure upper file handles") Cc: <stable@vger.kernel.org> # v4.16 Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2022-07-28reset: tps380x: Fix spelling mistake "Voltags" -> "Voltage"Colin Ian King
There is a spelling mistake in the MODULE_DESCRIPTION text. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20220728110554.18320-1-colin.i.king@gmail.com
2022-07-28ovl: improve ovl_get_acl() if POSIX ACL support is offYang Xu
Provide a proper stub for the !CONFIG_FS_POSIX_ACL case. Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2022-07-28net: cdns,macb: use correct xlnx prefix for XilinxKrzysztof Kozlowski
Use correct vendor for Xilinx versions of Cadence MACB/GEM Ethernet controller. The Versal compatible was not released, so it can be changed. Zynq-7xxx and Ultrascale+ has to be kept in new and deprecated form. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Harini Katakam <harini.katakam@amd.com> Link: https://lore.kernel.org/r/20220726070802.26579-2-krzysztof.kozlowski@linaro.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-07-28dt-bindings: net: cdns,macb: use correct xlnx prefix for XilinxKrzysztof Kozlowski
Use correct vendor for Xilinx versions of Cadence MACB/GEM Ethernet controller. The Versal compatible was not released, so it can be changed. Zynq-7xxx and Ultrascale+ has to be kept in new and deprecated form. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220726070802.26579-1-krzysztof.kozlowski@linaro.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-07-28ASoC: q6asm: use kcalloc() instead of kzalloc()Gustavo A. R. Silva
Use 2-factor multiplication argument form kcalloc() instead of kzalloc(). Link: https://github.com/KSPP/linux/issues/162 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20211006180810.GA913370@embeddedor Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-28net/funeth: Fix fun_xdp_tx() and XDP packet reclaimDimitris Michailidis
The current implementation of fun_xdp_tx(), used for XPD_TX, is incorrect in that it takes an address/length pair and later releases it with page_frag_free(). It is OK for XDP_TX but the same code is used by ndo_xdp_xmit. In that case it loses the XDP memory type and releases the packet incorrectly for some of the types. Assorted breakage follows. Change fun_xdp_tx() to take xdp_frame and rely on xdp_return_frame() in reclaim. Fixes: db37bc177dae ("net/funeth: add the data path") Signed-off-by: Dimitris Michailidis <dmichail@fungible.com> Link: https://lore.kernel.org/r/20220726215923.7887-1-dmichail@fungible.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-07-28Merge tag 'irqchip-5.20' of ↵Thomas Gleixner
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip/genirq updates from Marc Zyngier: * Core code update: - Non-SMP IRQ affinity fixes, allowing UP kernel to behave similarly to SMP ones for the purpose of interrupt affinity - Let irq_set_chip_handler_name_locked() take a const struct irq_chip * - Tidy-up the NOMAP irqdomain API variant - Teach action_show() to use for_each_action_of_desc() - Make irq_chip_request_resources_parent() allow the parent callback to be optional - Remove dynamic allocations from populate_parent_alloc_arg() * New drivers: - Merge the long awaited IRQ support for the LoongArch architecture, with the provisional ACPICA update (to be reverted once the official support lands) - New Renesas RZ/G2L IRQC driver, equipped with its companion GPIO driver * Driver updates - Optimise the hot path operations for the SiFive PLIC, trading the locking for per-CPU priority masking masking operations which are apparently faster - Work around broken PLIC implementations that deal pretty badly with edge-triggered interrupts. Flag two implementations as affected. - Simplify the irq-stm32-exti driver, particularly the table that remaps the interrupts from exti to the GIC, reducing the memory usage - Convert the ocelot irq_chip to being immutable - Check ioremap() return value in the MIPS GIC driver - Move MMP driver init function declarations into the common .h - The obligatory typo fixes Link: https://lore.kernel.org/all/20220727192356.1860546-1-maz@kernel.org
2022-07-28wait: Fix __wait_event_hrtimeout for RT/DL tasksJuri Lelli
Changes to hrtimer mode (potentially made by __hrtimer_init_sleeper on PREEMPT_RT) are not visible to hrtimer_start_range_ns, thus not accounted for by hrtimer_start_expires call paths. In particular, __wait_event_hrtimeout suffers from this problem as we have, for example: fs/aio.c::read_events wait_event_interruptible_hrtimeout __wait_event_hrtimeout hrtimer_init_sleeper_on_stack <- this might "mode |= HRTIMER_MODE_HARD" on RT if task runs at RT/DL priority hrtimer_start_range_ns WARN_ON_ONCE(!(mode & HRTIMER_MODE_HARD) ^ !timer->is_hard) fires since the latter doesn't see the change of mode done by init_sleeper Fix it by making __wait_event_hrtimeout call hrtimer_sleeper_start_expires, which is aware of the special RT/DL case, instead of hrtimer_start_range_ns. Reported-by: Bruno Goncalves <bgoncalv@redhat.com> Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Daniel Bristot de Oliveira <bristot@kernel.org> Reviewed-by: Valentin Schneider <vschneid@redhat.com> Link: https://lore.kernel.org/r/20220627095051.42470-1-juri.lelli@redhat.com
2022-07-28Merge tag 'timers-v5.20-rc1' of ↵Thomas Gleixner
https://git.linaro.org/people/daniel.lezcano/linux into timers/core Pull clockevent/source updates from Daniel Lezcano: - Add the missing DT bindings for the MTU nomadik timer (Linus Walleij) - Fix grammar typo in the ARM global timer Kconfig option (Randy Dunlap) - Add the tegra186 timer and use it on the tegra234 board (Thierry Reding) - Add the 'CPUXGPT' CPU timer for Mediatek MT6795 and implement a workaround to overcome an ATF bug where the timer is not correctly initialized (AngeloGioacchino Del Regno) - Rework the suspend/resume approach to enable the feature on the timer even it is not an active clock and fix a compilation warning (Claudiu Beznea) - Add the Add R-Car Gen4 timer support along with the DT bindings (Wolfram Sang) - Add compatible for ti,am654-timer to support AM6 SoC (Tony Lindgren) - Fix Kconfig option to put it back to 'bool' instead of 'tristate' for the tegra186 (Daniel Lezcano) - Sort 'family,type' DT bindings for the Renesas timers (Geert Uytterhoeven) - Add compatible 'allwinner,sun20i-d1-timer' for Allwinner D1 (Samuel Holland) - Remove unnecessary (void*) conversions for sun4i (XU pengfei) - Remove unnecessary (void*) conversions for sun5i (Li zeming) Link: https://lore.kernel.org/all/7472984e-f502-5f27-82bf-070127dd85a5@linaro.org
2022-07-28wifi: brcmfmac: prevent double-free on hardware-resetDanny van Heumen
In case of buggy firmware, brcmfmac may perform a hardware reset. If during reset and subsequent probing an early failure occurs, a memory region is accidentally double-freed. With hardened memory allocation enabled, this error will be detected. - return early where appropriate to skip unnecessary clean-up. - set '.freezer' pointer to NULL to prevent double-freeing under possible other circumstances and to re-align result under various different behaviors of memory allocation freeing. - correctly claim host on func1 for disabling func2. - after reset, do not initiate probing immediately, but rely on events. Given a firmware crash, function 'brcmf_sdio_bus_reset' is called. It calls 'brcmf_sdiod_remove', then follows up with 'brcmf_sdiod_probe' to reinitialize the hardware. If 'brcmf_sdiod_probe' fails to "set F1 blocksize", it exits early, which includes calling 'brcmf_sdiod_remove'. In both cases 'brcmf_sdiod_freezer_detach' is called to free allocated '.freezer', which has not yet been re-allocated the second time. Stacktrace of (failing) hardware reset after firmware-crash: Code: b9402b82 8b0202c0 eb1a02df 54000041 (d4210000) ret_from_fork+0x10/0x20 kthread+0x154/0x160 worker_thread+0x188/0x504 process_one_work+0x1f4/0x490 brcmf_core_bus_reset+0x34/0x44 [brcmfmac] brcmf_sdio_bus_reset+0x68/0xc0 [brcmfmac] brcmf_sdiod_probe+0x170/0x21c [brcmfmac] brcmf_sdiod_remove+0x48/0xc0 [brcmfmac] kfree+0x210/0x220 __slab_free+0x58/0x40c Call trace: x2 : 0000000000000040 x1 : fffffc00002d2b80 x0 : ffff00000b4aee40 x5 : ffff8000013fa728 x4 : 0000000000000001 x3 : ffff00000b4aee00 x8 : ffff800009967ce0 x7 : ffff8000099bfce0 x6 : 00000006f8005d01 x11: ffff8000099bfce0 x10: 00000000fffff000 x9 : ffff8000083401d0 x14: 0000000000000000 x13: 657a69736b636f6c x12: 6220314620746573 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000030 x20: fffffc00002d2ba0 x19: fffffc00002d2b80 x18: 0000000000000000 x23: ffff00000b4aee00 x22: ffff00000b4aee00 x21: 0000000000000001 x26: ffff00000b4aee00 x25: ffff0000f7753705 x24: 000000000001288a x29: ffff80000a22bbf0 x28: ffff000000401200 x27: 000000008020001a sp : ffff80000a22bbf0 lr : kfree+0x210/0x220 pc : __slab_free+0x58/0x40c pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) Workqueue: events brcmf_core_bus_reset [brcmfmac] Hardware name: Pine64 Pinebook Pro (DT) CPU: 2 PID: 639 Comm: kworker/2:2 Tainted: G C 5.16.0-0.bpo.4-arm64 #1 Debian 5.16.12-1~bpo11+1 nvmem_rockchip_efuse industrialio_triggered_buffer videodev snd_soc_core snd_pcm_dmaengine kfifo_buf snd_pcm io_domain mc industrialio mt> Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reje> Internal error: Oops - BUG: 0 [#1] SMP kernel BUG at mm/slub.c:379! Signed-off-by: Danny van Heumen <danny@dannyvanheumen.nl> Reviewed-by: Arend van Spriel <aspriel.gmail.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/id1HN6qCMAirApBzTA6fT7ZFWBBGCJhULpflxQ7NT6cgCboVnn3RHpiOFjA9SbRqzBRFLk9ES0C4FNvO6fUQsNg7pqF6ZSNAYUo99nHy8PY=@dannyvanheumen.nl
2022-07-28wifi: brcmfmac: support brcm,ccode-map-trivial DT propertyAlvin Šipraga
Commit a21bf90e927f ("brcmfmac: use ISO3166 country code and 0 rev as fallback on some devices") introduced a fallback mechanism whereby a trivial mapping from ISO3166 country codes to firmware country code and revision is used on some devices. This fallback operates on the device level, so it is enabled only for certain supported chipsets. In general though, the firmware country codes are determined by the CLM blob, which is board-specific and may vary despite the underlying chipset being the same. The aforementioned commit is actually a refinement of a previous commit that was reverted in commit 151a7c12c4fc ("Revert "brcmfmac: use ISO3166 country code and 0 rev as fallback"") due to regressions with a BCM4359 device. The refinement restricted the fallback mechanism to specific chipsets such as the BCM4345. We use a chipset - CYW88359 - that the driver identifies as a BCM4359 too. But in our case, the CLM blob uses ISO3166 country codes internally, and all with revision 0. So the trivial mapping is exactly what is needed in order for the driver to sync the kernel regulatory domain to the firmware. This is just a matter of how the CLM blob was prepared by the hardware vendor. The same could hold for other boards too. Although the brcm,ccode-map device tree property is useful for cases where the mapping is more complex, the trivial case invites a much simpler specification. This patch adds support for parsing the brcm,ccode-map-trivial device tree property. Subordinate to the more specific brcm,ccode-map property, this new proprety simply informs the driver that the fallback method should be used in every case. In the absence of the new property in the device tree, expect no functional change. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220711123005.3055300-3-alvin@pqrs.dk
2022-07-28dt-bindings: bcm4329-fmac: add optional brcm,ccode-map-trivialAlvin Šipraga
The bindings already offer a brcm,ccode-map property to describe the mapping between the kernel's ISO3166 alpha 2 country code string and the firmware's country code string and revision number. This is a board-specific property and determined by the CLM blob firmware provided by the hardware vendor. However, in some cases the firmware will also use ISO3166 country codes internally, and the revision will always be zero. This implies a trivial mapping: cc -> { cc, 0 }. For such cases, add an optional property brcm,ccode-map-trivial which obviates the need to describe every trivial country code mapping in the device tree with the existing brcm,ccode-map property. The new property is subordinate to the more explicit brcm,ccode-map property. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220711123005.3055300-2-alvin@pqrs.dk
2022-07-28wifi: brcmfmac: Replace default (not configured) MAC with a random MACHans de Goede
On some boards there is no eeprom to hold the nvram, in this case instead a board specific nvram is loaded from /lib/firmware. On most boards the macaddr=... setting in the /lib/firmware nvram file is ignored because the wifi/bt chip has a unique MAC programmed into the chip itself. But in some cases the actual MAC from the /lib/firmware nvram file gets used, leading to MAC conflicts. The MAC addresses in the troublesome nvram files seem to all come from the same nvram file template, so we can detect this by checking for the template nvram file MAC. Detect that the default MAC address is being used and replace it with a random MAC address to avoid MAC address conflicts. Note that udev will detect this is a random MAC based on /sys/class/net/wlan0/addr_assign_type and then replace this with a MAC based on hashing the netdev-name + the machine-id. So that the MAC address is both guaranteed to be unique per machine while it is still the same/persistent at each boot (assuming the default Link.MACAddressPolicy=persistent udev setting). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220708133712.102179-2-hdegoede@redhat.com
2022-07-28wifi: brcmfmac: Add brcmf_c_set_cur_etheraddr() helperHans de Goede
Add a little helper to send "cur_etheraddr" commands to the interface and to handle the error reporting of it in a single place. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Arend van Spriel <aspriel@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220708133712.102179-1-hdegoede@redhat.com
2022-07-28wifi: brcmfmac: Remove #ifdef guards for PM related functionsPaul Cercueil
Use the new DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() macros to handle the .suspend/.resume callbacks. These macros allow the suspend and resume functions to be automatically dropped by the compiler when CONFIG_SUSPEND is disabled, without having to use #ifdef guards. Some other functions not directly called by the .suspend/.resume callbacks, but still related to PM were also taken outside #ifdef guards. The advantage is then that these functions are now always compiled independently of any Kconfig option, and thanks to that bugs and regressions are easier to catch. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220627193701.31074-1-paul@crapouillou.net
2022-07-28wifi: brcmfmac: use strreplace() in brcmf_of_probe()Dan Carpenter
The for loop in brcmf_of_probe() would ideally end with something like "i <= strlen(board_type)" instead of "i < board_type[i]". But fortunately, the two are equivalent. Anyway, it's simpler to use strreplace() instead. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Suggested-by: Johannes Berg <johannes@sipsolutions.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YqrhsKcjEA7B2pC4@kili
2022-07-28Merge branch '100GbE' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== ice: PPPoE offload support Marcin Szycik says: Add support for dissecting PPPoE and PPP-specific fields in flow dissector: PPPoE session id and PPP protocol type. Add support for those fields in tc-flower and support offloading PPPoE. Finally, add support for hardware offload of PPPoE packets in switchdev mode in ice driver. Example filter: tc filter add dev $PF1 ingress protocol ppp_ses prio 1 flower pppoe_sid \ 1234 ppp_proto ip skip_sw action mirred egress redirect dev $VF1_PR Changes in iproute2 are required to use the new fields (will be submitted soon). ICE COMMS DDP package is required to create a filter in ice. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: Add support for PPPoE hardware offload flow_offload: Introduce flow_match_pppoe net/sched: flower: Add PPPoE filter flow_dissector: Add PPPoE dissectors ==================== Link: https://lore.kernel.org/r/20220726203133.2171332-1-anthony.l.nguyen@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-07-28Merge patch series "can: add ethtool support and reporting of timestamping ↵Marc Kleine-Budde
capabilities" Vincent Mailhol <mailhol.vincent@wanadoo.fr> says: ==================== This series revolves around ethtool and timestamping. Its ultimate goal is that the timestamping implementation within socketCAN meets the specification of other network drivers in the kernel. This way, tcpdump or other tools derived from libpcap can be used to do timestamping on CAN devices. * Example on a device with hardware timestamp support * Before this series: | # tcpdump -j adapter_unsynced -i can0 | tcpdump: WARNING: When trying to set timestamp type | 'adapter_unsynced' on can0: That type of time stamp is not supported | by that device After applying this series, the warning disappears and tcpdump can be used to get RX hardware timestamps. This series is articulated in three major parts. * Part 1: Add TX software timestamps and report the software timestamping capabilities through ethtool. All the drivers using can_put_echo_skb() already support TX software timestamps. However, the five drivers not using this function (namely can327, janz-ican3, slcan, vcan and vxcan) lack such support. Patch 1 to 4 adds this support. Finally, patch 5 advertises the timesamping capabilities of all drivers which do not support hardware timestamps. * Part 2: add TX hardware timestapms This part is a single patch. In SocketCAN TX hardware is equal to the RX hardware timestamps of the corresponding loopback frame. Reuse the TX hardware timestamp to populate the RX hardware timestamp. While the need of this feature can be debatable, we implement it here so that generic timestamping tools which are agnostic of the specificity of SocketCAN can still obtain the value. For example, tcpdump expects for both TX and RX hardware timestamps to be supported in order to do: | # tcpdump -j adapter_unsynced -i canX * Part 3: report the hardware timestamping capabilities and implement the hardware timestamps ioctls. The kernel documentation specifies in [1] that, for the drivers which support hardware timestamping, SIOCSHWTSTAMP ioctl must be supported and that SIOCGHWTSTAMP ioctl should be supported. Currently, none of the CAN drivers do so. This is a gap. Furthermore, even if not specified, the tools based on libpcap (e.g. tcpdump) also expect ethtool_ops::get_ts_info to be implemented. This last part first adds some generic implementation of net_device_ops::ndo_eth_ioctl and ethtool_ops::get_ts_info which can be used by the drivers with hardware timestamping capabilities. It then uses those generic functions to add ioctl and reporting functionalities to the drivers with hardware timestamping support (namely: mcp251xfd, etas_es58x, kvaser_{pciefd,usb}, peak_{canfd,usb}) [1] Kernel doc: Timestamping, section 3.1 "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers * Testing * I also developed a tool to test all the different timestamps. For those who would also like to test it, please have a look at: https://lore.kernel.org/linux-can/20220725134345.432367-1-mailhol.vincent@wanadoo.fr/T/ * Changelog * changes since v3: https://lore.kernel.org/all/20220726102454.95096-1-mailhol.vincent@wanadoo.fr * The peak drivers (both PCI and USB) do not support hardware TX timestamps (only RX). Implement specific ioctl and ethtool callback functions for this device. changes since v2: https://lore.kernel.org/all/20220725155354.482986-1-mailhol.vincent@wanadoo.fr * The c_can, flexcan, mcp251xfd and the slcan drivers already declared a struct ethtool_ops. Do not declare again the same structure and instead populate the .get_ts_info() field of the existing structures. changes since v1: https://lore.kernel.org/all/20220725133208.432176-1-mailhol.vincent@wanadoo.fr * First series had a patch to implement ethtool_ops::get_drvinfo. This proved to be useless. This patch was removed and all the clean-up patches made in preparation of that one were moved to a separate series: https://lore.kernel.org/linux-can/20220725153124.467061-1-mailhol.vincent@wanadoo.fr/T/#u ==================== Link: https://lore.kernel.org/all/20220727101641.198847-1-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-28can: peak_usb: advertise timestamping capabilities and add ioctl supportVincent Mailhol
Currently, userland has no method to query which timestamping features are supported by the peak_usb driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way to add hardware timestamp support is to implement ethtool_ops::get_ts_info() in order to advertise the timestamping capabilities and to implement net_device_ops::ndo_eth_ioctl() as requested in [1]. Currently, the driver only supports hardware RX timestamps [2] but not hardware TX. For this reason, the generic function can_ethtool_op_get_ts_info_hwts() and can_eth_ioctl_hwts() can not be reused and instead this patch adds pcan_get_ts_info() and peak_eth_ioctl(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers [2] https://lore.kernel.org/linux-can/20220727080634.l6uttnbrmwbabh3o@pengutronix.de/ CC: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20220727101641.198847-15-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-28can: peak_canfd: advertise timestamping capabilities and add ioctl supportVincent Mailhol
Currently, userland has no method to query which timestamping features are supported by the peak_canfd driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way to add hardware timestamp support is to implement ethtool_ops::get_ts_info() in order to advertise the timestamping capabilities and to implement net_device_ops::ndo_eth_ioctl() as requested in [1]. Currently, the driver only supports hardware RX timestamps [2] but not hardware TX. For this reason, the generic function can_ethtool_op_get_ts_info_hwts() and can_eth_ioctl_hwts() can not be reused and instead this patch adds peak_get_ts_info() and peak_eth_ioctl(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers [2] https://lore.kernel.org/linux-can/20220727084257.brcbbf7lksoeekbr@pengutronix.de/ CC: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20220727101641.198847-14-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-28can: kvaser_usb: advertise timestamping capabilities and add ioctl supportVincent Mailhol
Currently, userland has no method to query which timestamping features are supported by the kvaser_usb driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertise what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). Here, we use the CAN specific can_ethtool_op_get_ts_info_hwts() function to achieve this. In addition, the driver currently does not support the hardware timestamps ioctls. According to [1], SIOCSHWTSTAMP is "must" and SIOCGHWTSTAMP is "should". This patch fills up that gap by implementing net_device_ops::ndo_eth_ioctl() using the CAN specific function can_eth_ioctl_hwts(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers CC: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20220727101641.198847-13-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit (git 2.34.1) at 2025-09-21 19:39:25 +0000