summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-11-01proc: test ProtectionKey in proc-empty-vm testSwarup Laxman Kotiaklapudi
Check ProtectionKey field in /proc/*/smaps output, if system supports protection keys feature. [adobriyan@gmail.com: test support in the beginning of the program, use syscall, not glibc pkey_alloc(3) which may not compile] Link: https://lkml.kernel.org/r/ac05efa7-d2a0-48ad-b704-ffdd5450582e@p183 Signed-off-by: Swarup Laxman Kotiaklapudi <swarupkotikalapudi@gmail.com> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Reviewed-by: Swarup Laxman Kotikalapudi<swarupkotikalapudi@gmail.com> Tested-by: Swarup Laxman Kotikalapudi<swarupkotikalapudi@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01proc: fix proc-empty-vm test with vsyscallAlexey Dobriyan
* fix embarassing /proc/*/smaps test bug due to a typo in variable name it tested only the first line of the output if vsyscall is enabled: ffffffffff600000-ffffffffff601000 r-xp ... so test passed but tested only VMA location and permissions. * add "KSM" entry, unnoticed because (1) * swap "r-xp" and "--xp" vsyscall test strings, also unnoticed because (1) Link: https://lkml.kernel.org/r/76f42cce-b1ab-45ec-b6b2-4c64f0dccb90@p183 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Tested-by: Swarup Laxman Kotikalapudi<swarupkotikalapudi@mail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01fs/proc/base.c: remove unneeded semicolonYang Li
./fs/proc/base.c:3829:2-3: Unneeded semicolon Link: https://lkml.kernel.org/r/20231026005634.6581-1-yang.lee@linux.alibaba.com Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7057 Acked-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01do_io_accounting: use sig->stats_lockOleg Nesterov
Rather than lock_task_sighand(), sig->stats_lock was specifically designed for this type of use. This way the "if (whole)" branch runs lockless in the likely case. Link: https://lkml.kernel.org/r/20231023153405.GA4639@redhat.com Signed-off-by: Oleg Nesterov <oleg@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01do_io_accounting: use __for_each_thread()Oleg Nesterov
Rather than while_each_thread() which should be avoided when possible. This makes the code more clear and allows the next change. Link: https://lkml.kernel.org/r/20231023153343.GA4629@redhat.com Signed-off-by: Oleg Nesterov <oleg@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01ocfs2: replace BUG_ON() at ocfs2_num_free_extents() with ocfs2_error()Jia Rui
The BUG_ON() at ocfs2_num_free_extents() handles the error that l_tree_deepth of leaf extent block just read form disk is invalid. This error is mostly caused by file system metadata corruption on the disk. There is no need to call BUG_ON() to handle such errors. We can return error code, since the caller can deal with errors from ocfs2_num_free_extents(). Also, we should make the file system read-only to avoid the damage from expanding. Therefore, BUG_ON() is removed and ocfs2_error() is called instead. Link: https://lkml.kernel.org/r/20231018191811.412458-1-jindui71@gmail.com Signed-off-by: Jia Rui <jindui71@gmail.com> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01mm/damon/sysfs: update monitoring target regions for online input commitSeongJae Park
When user input is committed online, DAMON sysfs interface is ignoring the user input for the monitoring target regions. Such request is valid and useful for fixed monitoring target regions-based monitoring ops like 'paddr' or 'fvaddr'. Update the region boundaries as user specified, too. Note that the monitoring results of the regions that overlap between the latest monitoring target regions and the new target regions are preserved. Treat empty monitoring target regions user request as a request to just make no change to the monitoring target regions. Otherwise, users should set the monitoring target regions same to current one for every online input commit, and it could be challenging for dynamic monitoring target regions update DAMON ops like 'vaddr'. If the user really need to remove all monitoring target regions, they can simply remove the target and then create the target again with empty target regions. Link: https://lkml.kernel.org/r/20231031170131.46972-1-sj@kernel.org Fixes: da87878010e5 ("mm/damon/sysfs: support online inputs update") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> [5.19+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01mm/damon/sysfs: remove requested targets when online-commit inputsSeongJae Park
damon_sysfs_set_targets(), which updates the targets of the context for online commitment, do not remove targets that removed from the corresponding sysfs files. As a result, more than intended targets of the context can exist and hence consume memory and monitoring CPU resource more than expected. Fix it by removing all targets of the context and fill up again using the user input. This could cause unnecessary memory dealloc and realloc operations, but this is not a hot code path. Also, note that damon_target is stateless, and hence no data is lost. [sj@kernel.org: fix unnecessary monitoring results removal] Link: https://lkml.kernel.org/r/20231028213353.45397-1-sj@kernel.org Link: https://lkml.kernel.org/r/20231022210735.46409-2-sj@kernel.org Fixes: da87878010e5 ("mm/damon/sysfs: support online inputs update") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: Brendan Higgins <brendanhiggins@google.com> Cc: <stable@vger.kernel.org> [5.19.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01selftests: add a sanity check for zswapNhat Pham
We recently encountered a bug that makes all zswap store attempt fail. Specifically, after: "141fdeececb3 mm/zswap: delay the initialization of zswap" if we build a kernel with zswap disabled by default, then enabled after the swapfile is set up, the zswap tree will not be initialized. As a result, all zswap store calls will be short-circuited. We have to perform another swapon to get zswap working properly again. Fortunately, this issue has since been fixed by the patch that kills frontswap: "42c06a0e8ebe mm: kill frontswap" which performs zswap_swapon() unconditionally, i.e always initializing the zswap tree. This test add a sanity check that ensure zswap storing works as intended. Link: https://lkml.kernel.org/r/20231020222009.2358953-1-nphamcs@gmail.com Signed-off-by: Nhat Pham <nphamcs@gmail.com> Acked-by: Rik van Riel <riel@surriel.com> Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Zefan Li <lizefan.x@bytedance.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01Documentation: maple_tree: fix word spelling errorTom Yang
The "first" is spelled "fist". Link: https://lkml.kernel.org/r/20231023095737.21823-1-yangqixiao@inspur.com Signed-off-by: Tom Yang <yangqixiao@inspur.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01mm/vmalloc: fix the unchecked dereference warning in vread_iter()Baoquan He
LKP reported smatch warning as below: =================== smatch warnings: mm/vmalloc.c:3689 vread_iter() error: we previously assumed 'vm' could be null (see line 3667) ...... 06c8994626d1b7 @3667 size = vm ? get_vm_area_size(vm) : va_size(va); ...... 06c8994626d1b7 @3689 else if (!(vm->flags & VM_IOREMAP)) ^^^^^^^^^ Unchecked dereference ===================== This is not a runtime bug because the possible null 'vm' in the pointed place could only happen when flags == VMAP_BLOCK. However, the case 'flags == VMAP_BLOCK' should never happen and has been detected with WARN_ON. Please check vm_map_ram() implementation and the earlier checking in vread_iter() at below: ~~~~~~~~~~~~~~~~~~~~~~~~~~ /* * VMAP_BLOCK indicates a sub-type of vm_map_ram area, need * be set together with VMAP_RAM. */ WARN_ON(flags == VMAP_BLOCK); if (!vm && !flags) continue; ~~~~~~~~~~~~~~~~~~~~~~~~~~ So add checking on whether 'vm' could be null when dereferencing it in vread_iter(). This mutes smatch complaint. Link: https://lkml.kernel.org/r/ZTCURc8ZQE+KrTvS@MiWiFi-R3L-srv Link: https://lkml.kernel.org/r/ZS/2k6DIMd0tZRgK@MiWiFi-R3L-srv Signed-off-by: Baoquan He <bhe@redhat.com> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202310171600.WCrsOwFj-lkp@intel.com/ Cc: Lorenzo Stoakes <lstoakes@gmail.com> Cc: Philip Li <philip.li@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01zswap: export compression failure statsNhat Pham
During a zswap store attempt, the compression algorithm could fail (for e.g due to the page containing incompressible random data). This is not tracked in any of existing zswap counters, making it hard to monitor for and investigate. We have run into this problem several times in our internal investigations on zswap store failures. This patch adds a dedicated debugfs counter for compression algorithm failures. Link: https://lkml.kernel.org/r/20231024234509.2680539-1-nphamcs@gmail.com Signed-off-by: Nhat Pham <nphamcs@gmail.com> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Dan Streetman <ddstreet@ieee.org> Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Seth Jennings <sjenning@redhat.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Vitaly Wool <vitaly.wool@konsulko.com> Cc: Yosry Ahmed <yosryahmed@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01Documentation: ubsan: drop "the" from article titleAndrey Konovalov
Drop "the" from the title of the documentation article for UBSAN, as it is redundant. Also add SPDX-License-Identifier for ubsan.rst. Link: https://lkml.kernel.org/r/5fb11a4743eea9d9232a5284dea0716589088fec.1698161845.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-by: Marco Elver <elver@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-11-01Merge tag 'arm64-upstream' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 updates from Catalin Marinas: "No major architecture features this time around, just some new HWCAP definitions, support for the Ampere SoC PMUs and a few fixes/cleanups. The bulk of the changes is reworking of the CPU capability checking code (cpus_have_cap() etc). - Major refactoring of the CPU capability detection logic resulting in the removal of the cpus_have_const_cap() function and migrating the code to "alternative" branches where possible - Backtrace/kgdb: use IPIs and pseudo-NMI - Perf and PMU: - Add support for Ampere SoC PMUs - Multi-DTC improvements for larger CMN configurations with multiple Debug & Trace Controllers - Rework the Arm CoreSight PMU driver to allow separate registration of vendor backend modules - Fixes: add missing MODULE_DEVICE_TABLE to the amlogic perf driver; use device_get_match_data() in the xgene driver; fix NULL pointer dereference in the hisi driver caused by calling cpuhp_state_remove_instance(); use-after-free in the hisi driver - HWCAP updates: - FEAT_SVE_B16B16 (BFloat16) - FEAT_LRCPC3 (release consistency model) - FEAT_LSE128 (128-bit atomic instructions) - SVE: remove a couple of pseudo registers from the cpufeature code. There is logic in place already to detect mismatched SVE features - Miscellaneous: - Reduce the default swiotlb size (currently 64MB) if no ZONE_DMA bouncing is needed. The buffer is still required for small kmalloc() buffers - Fix module PLT counting with !RANDOMIZE_BASE - Restrict CPU_BIG_ENDIAN to LLVM IAS 15.x or newer move synchronisation code out of the set_ptes() loop - More compact cpufeature displaying enabled cores - Kselftest updates for the new CPU features" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (83 commits) arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer arm64: module: Fix PLT counting when CONFIG_RANDOMIZE_BASE=n arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a helper perf: hisi: Fix use-after-free when register pmu fails drivers/perf: hisi_pcie: Initialize event->cpu only on success drivers/perf: hisi_pcie: Check the type first in pmu::event_init() arm64: cpufeature: Change DBM to display enabled cores arm64: cpufeature: Display the set of cores with a feature perf/arm-cmn: Enable per-DTC counter allocation perf/arm-cmn: Rework DTC counters (again) perf/arm-cmn: Fix DTC domain detection drivers: perf: arm_pmuv3: Drop some unused arguments from armv8_pmu_init() drivers: perf: arm_pmuv3: Read PMMIR_EL1 unconditionally drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process clocksource/drivers/arm_arch_timer: limit XGene-1 workaround arm64: Remove system_uses_lse_atomics() arm64: Mark the 'addr' argument to set_ptes() and __set_pte_at() as unused drivers/perf: xgene: Use device_get_match_data() perf/amlogic: add missing MODULE_DEVICE_TABLE arm64/mm: Hoist synchronization out of set_ptes() loop ...
2023-11-01watchdog: move softlockup_panic back to early_paramKrister Johansen
Setting softlockup_panic from do_sysctl_args() causes it to take effect later in boot. The lockup detector is enabled before SMP is brought online, but do_sysctl_args runs afterwards. If a user wants to set softlockup_panic on boot and have it trigger should a softlockup occur during onlining of the non-boot processors, they could do this prior to commit f117955a2255 ("kernel/watchdog.c: convert {soft/hard}lockup boot parameters to sysctl aliases"). However, after this commit the value of softlockup_panic is set too late to be of help for this type of problem. Restore the prior behavior. Signed-off-by: Krister Johansen <kjlx@templeofstupid.com> Cc: stable@vger.kernel.org Fixes: f117955a2255 ("kernel/watchdog.c: convert {soft/hard}lockup boot parameters to sysctl aliases") Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-11-01proc: sysctl: prevent aliased sysctls from getting passed to initKrister Johansen
The code that checks for unknown boot options is unaware of the sysctl alias facility, which maps bootparams to sysctl values. If a user sets an old value that has a valid alias, a message about an invalid parameter will be printed during boot, and the parameter will get passed to init. Fix by checking for the existence of aliased parameters in the unknown boot parameter code. If an alias exists, don't return an error or pass the value to init. Signed-off-by: Krister Johansen <kjlx@templeofstupid.com> Cc: stable@vger.kernel.org Fixes: 0a477e1ae21b ("kernel/sysctl: support handling command line aliases") Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-11-01Merge tag 'drm-next-2023-10-31-1' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm updates from Dave Airlie: "Highlights: - AMD adds some more upcoming HW platforms - Intel made Meteorlake stable and started adding Lunarlake - nouveau has a bunch of display rework in prepartion for the NVIDIA GSP firmware support - msm adds a7xx support - habanalabs has finished migration to accel subsystem Detail summary: kernel: - add initial vmemdup-user-array core: - fix platform remove() to return void - drm_file owner updated to reflect owner - move size calcs to drm buddy allocator - let GPUVM build as a module - allow variable number of run-queues in scheduler edid: - handle bad h/v sync_end in EDIDs panfrost: - add Boris as maintainer fbdev: - use fb_ops helpers more - only allow logo use from fbcon - rename fb_pgproto to pgprot_framebuffer - add HPD state to drm_connector_oob_hotplug_event - convert to fbdev i/o mem helpers i915: - Enable meteorlake by default - Early Xe2 LPD/Lunarlake display enablement - Rework subplatforms into IP version checks - GuC based TLB invalidation for Meteorlake - Display rework for future Xe driver integration - LNL FBC features - LNL display feature capability reads - update recommended fw versions for DG2+ - drop fastboot module parameter - added deviceid for Arrowlake-S - drop preproduction workarounds - don't disable preemption for resets - cleanup inlines in headers - PXP firmware loading fix - Fix sg list lengths - DSC PPS state readout/verification - Add more RPL P/U PCI IDs - Add new DG2-G12 stepping - DP enhanced framing support to state checker - Improve shared link bandwidth management - stop using GEM macros in display code - refactor related code into display code - locally enable W=1 warnings - remove PSR watchdog timers on LNL amdgpu: - RAS/FRU EEPROM updatse - IP discovery updatses - GC 11.5 support - DCN 3.5 support - VPE 6.1 support - NBIO 7.11 support - DML2 support - lots of IP updates - use flexible arrays for bo list handling - W=1 fixes - Enable seamless boot in more cases - Enable context type property for HDMI - Rework GPUVM TLB flushing - VCN IB start/size alignment fixes amdkfd: - GC 10/11 fixes - GC 11.5 support - use partial migration in GPU faults radeon: - W=1 Fixes - fix some possible buffer overflow/NULL derefs nouveau: - update uapi for NO_PREFETCH - scheduler/fence fixes - rework suspend/resume for GSP-RM - rework display in preparation for GSP-RM habanalabs: - uapi: expose tsc clock - uapi: block access to eventfd through control device - uapi: force dma-buf export to PAGE_SIZE alignments - complete move to accel subsystem - move firmware interface include files - perform hard reset on PCIe AXI drain event - optimise user interrupt handling msm: - DP: use existing helpers for DPCD - DPU: interrupts reworked - gpu: a7xx (a730/a740) support - decouple msm_drv from kms for headless devices mediatek: - MT8188 dsi/dp/edp support - DDP GAMMA - 12 bit LUT support - connector dynamic selection capability rockchip: - rv1126 mipi-dsi/vop support - add planar formats ast: - rename constants panels: - Mitsubishi AA084XE01 - JDI LPM102A188A - LTK050H3148W-CTA6 ivpu: - power management fixes qaic: - add detach slice bo api komeda: - add NV12 writeback tegra: - support NVSYNC/NHSYNC - host1x suspend fixes ili9882t: - separate into own driver" * tag 'drm-next-2023-10-31-1' of git://anongit.freedesktop.org/drm/drm: (1803 commits) drm/amdgpu: Remove unused variables from amdgpu_show_fdinfo drm/amdgpu: Remove duplicate fdinfo fields drm/amd/amdgpu: avoid to disable gfxhub interrupt when driver is unloaded drm/amdgpu: Add EXT_COHERENT support for APU and NUMA systems drm/amdgpu: Retrieve CE count from ce_count_lo_chip in EccInfo table drm/amdgpu: Identify data parity error corrected in replay mode drm/amdgpu: Fix typo in IP discovery parsing drm/amd/display: fix S/G display enablement drm/amdxcp: fix amdxcp unloads incompletely drm/amd/amdgpu: fix the GPU power print error in pm info drm/amdgpu: Use pcie domain of xcc acpi objects drm/amd: check num of link levels when update pcie param drm/amdgpu: Add a read to GFX v9.4.3 ring test drm/amd/pm: call smu_cmn_get_smc_version in is_mode1_reset_supported. drm/amdgpu: get RAS poison status from DF v4_6_2 drm/amdgpu: Use discovery table's subrevision drm/amd/display: 3.2.256 drm/amd/display: add interface to query SubVP status drm/amd/display: Read before writing Backlight Mode Set Register drm/amd/display: Disable SYMCLK32_SE RCO on DCN314 ...
2023-11-01vsprintf: uninline simple_strntoull(), reorder argumentsAlexey Dobriyan
* uninline simple_strntoull(), gcc overinlines and this function is not performance critical * reorder arguments, so that appending INT_MAX as 4th argument generates very efficient tail call Space savings: add/remove: 1/0 grow/shrink: 0/3 up/down: 27/-179 (-152) Function old new delta simple_strntoll - 27 +27 simple_strtoull 15 10 -5 simple_strtoll 41 7 -34 vsscanf 1930 1790 -140 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/all/82a2af6e-9b6c-4a09-89d7-ca90cc1cdad1@p183/
2023-11-01leds: lp5521: Add an error check in lp5521_post_init_deviceSu Hui
lp55xx_write() can return an error code, add a check for this. Signed-off-by: Su Hui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20231020091930.207870-1-suhui@nfschina.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: gpio: Update headersAndy Shevchenko
Include headers which we are direct users of, no need to have proxies. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231016161005.1471768-6-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: gpio: Remove unneeded assignmentAndy Shevchenko
The initial ret is not used anywhere, drop the unneeded assignment. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231016161005.1471768-5-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: gpio: Move temporary variable for struct device to gpio_led_probe()Andy Shevchenko
Use temporary variable for struct device in gpio_led_probe() in order to make code neater. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231016161005.1471768-4-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: gpio: Refactor code to use devm_gpiod_get_index_optional()Andy Shevchenko
Instead of checking for the specific error codes, replace devm_gpiod_get_index() with devm_gpiod_get_index_optional(). In this case we just return all errors to the caller and simply check for NULL in case if legacy GPIO is being used. As the result the code is easier to read and maintain. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231016161005.1471768-3-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: gpio: Utilise PTR_ERR_OR_ZERO()Andy Shevchenko
Avoid a boilerplate code by using PTR_ERR_OR_ZERO() in create_gpio_led(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231016161005.1471768-2-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: gpio: Keep driver firmware interface agnosticAndy Shevchenko
The of.h is used as a proxy to mod_devicetable, replace former by latter. The commit 2d6180147e92 ("leds: gpio: Configure per-LED pin control") added yet another unneeded OF APIs. Replace with direct use of fwnode. Altogether this makes driver agnostic to the firmware interface in use. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231016161005.1471768-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: core: Refactor led_update_brightness() to use standard patternAndy Shevchenko
The standard conditional pattern is to check for errors first and bail out if any. Refactor led_update_brightness() accordingly. While at it, drop unneeded assignment and return 0 unconditionally on success. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Denis Osterland-Heim <denis.osterland@diehl.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231016153051.1409074-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: turris-omnia: Fix brightness setting and trigger activatingMarek Behún
I have improperly refactored commits 4d5ed2621c24 ("leds: turris-omnia: Make set_brightness() more efficient") and aaf38273cf76 ("leds: turris-omnia: Support HW controlled mode via private trigger") after Lee requested a change in API semantics of the new functions I introduced in commit 28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls"). Before the change, the function omnia_cmd_write_u8() returned 0 on success, and afterwards it returned a positive value (number of bytes written). The latter version was applied, but the following commits did not properly account for this change. This results in non-functional LED's .brightness_set_blocking() and trigger's .activate() methods. The main reasoning behind the semantics change was that read/write methods should return the number of read/written bytes on success. It was pointed to me [1] that this is not always true (for example the regmap API does not do so), and since the driver never uses this number of read/written bytes information, I decided to fix this issue by changing the functions to the original semantics (return 0 on success). [1] https://lore.kernel.org/linux-gpio/ZQnn+Gi0xVlsGCYA@smile.fi.intel.com/ Fixes: 28350bc0ac77 ("leds: turris-omnia: Do not use SMBUS calls") Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20231016141538.30037-1-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: sc27xx: Move mutex_init() downChunyan Zhang
Move the mutex_init() to avoid redundant mutex_destroy() calls after that for each time the probe fails. Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Link: https://lore.kernel.org/r/20231013022010.854367-1-chunyan.zhang@unisoc.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: trigger: netdev: Move size check in set_device_nameChristian Marangi
GCC 13.2 complains about array subscript 17 is above array bounds of 'char[16]' with IFNAMSIZ set to 16. The warning is correct but this scenario is impossible. set_device_name is called by device_name_store (store sysfs entry) and netdev_trig_activate. device_name_store already check if size is >= of IFNAMSIZ and return -EINVAL. (making the warning scenario impossible) netdev_trig_activate works on already defined interface, where the name has already been checked and should already follow the condition of strlen() < IFNAMSIZ. Aside from the scenario being impossible, set_device_name can be improved to both mute the warning and make the function safer. To make it safer, move size check from device_name_store directly to set_device_name and prevent any out of bounds scenario. Cc: stable@vger.kernel.org Fixes: 28a6a2ef18ad ("leds: trigger: netdev: refactor code setting device name") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309192035.GTJEEbem-lkp@intel.com/ Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20231007131042.15032-1-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: Add ktd202x driverAndré Apitzsch
This commit adds support for Kinetic KTD2026/7 RGB/White LED driver. Signed-off-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20231002-ktd202x-v6-2-26be8eefeb88@apitzsch.eu Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01dt-bindings: leds: Add Kinetic KTD2026/2027 LEDAndré Apitzsch
Document Kinetic KTD2026/2027 LED driver devicetree bindings. Signed-off-by: André Apitzsch <git@apitzsch.eu> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231002-ktd202x-v6-1-26be8eefeb88@apitzsch.eu Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: core: Add more colors from DT bindings to led_colorsOndrej Jirman
The colors are already part of DT bindings. Make sure the kernel is able to convert them to strings. Signed-off-by: Ondrej Jirman <megi@xff.cz> Link: https://lore.kernel.org/r/20231008144014.1180334-1-megi@xff.cz Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01dt-bindings: leds: Last color ID is now 14 (LED_COLOR_ID_LIME)Ondrej Jirman
Increase the limit to match available values in dt-bindings/leds/common.h Fixes: 472d7b9e8141 ("dt-bindings: leds: Expand LED_COLOR_ID definitions") Signed-off-by: Ondrej Jirman <megi@xff.cz> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231008142103.1174028-1-megi@xff.cz Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: tca6507: Don't use fixed GPIO baseAndy Shevchenko
First of all, the fixed GPIO base is source of troubles and it doesn't scale. Second, there is no in-kernel user of this base, so drop it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231002135629.2605462-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: lp3952: Convert to use maple tree register cacheMark Brown
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230929-leds-maple-v1-4-ba5f9dcb1e75@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: lm392x: Convert to use maple tree register cacheMark Brown
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230929-leds-maple-v1-3-ba5f9dcb1e75@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: aw200xx: Convert to use maple tree register cacheMark Brown
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230929-leds-maple-v1-2-ba5f9dcb1e75@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: lm3601x: Convert to use maple tree register cacheMark Brown
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230929-leds-maple-v1-1-ba5f9dcb1e75@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: triggers: gpio: Rewrite to use trigger-sourcesLinus Walleij
By providing a GPIO line as "trigger-sources" in the FWNODE (such as from the device tree) and combining with the GPIO trigger, we can support a GPIO LED trigger in a natural way from the hardware description instead of using the custom sysfs and deprecated global GPIO numberspace. Example: gpio: gpio@0 { compatible "my-gpio"; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; #trigger-source-cells = <2>; }; leds { compatible = "gpio-leds"; led-my-gpio { label = "device:blue:myled"; gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; default-state = "off"; linux,default-trigger = "gpio"; trigger-sources = <&gpio 1 GPIO_ACTIVE_HIGH>; }; }; Make this the norm, unmark the driver as broken. Delete the sysfs handling of GPIOs. Since GPIO descriptors inherently can describe inversion, the inversion handling can just be deleted. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230926-gpio-led-trigger-dt-v2-3-e06e458b788e@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01dt-bindings: leds: Mention GPIO triggersLinus Walleij
We reuse the trigger-sources phandle to just point to GPIOs we may want to use as LED triggers. Example: gpio: gpio@0 { compatible "my-gpio"; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; #trigger-source-cells = <2>; }; leds { compatible = "gpio-leds"; led-my-gpio { label = "device:blue:myled"; gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; default-state = "off"; linux,default-trigger = "gpio"; trigger-sources = <&gpio 1 GPIO_ACTIVE_HIGH>; }; }; Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230926-gpio-led-trigger-dt-v2-2-e06e458b788e@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: pca955x: Cleanup OF/ID table terminatorsBiju Das
Some cleanups: * Remove the trailing comma in the terminator entry for the OF table making code robust against (theoretical) misrebases or other similar things where the new entry goes _after_ the termination without the compiler noticing. * Drop a space from terminator entry for ID table. While at it, move OF/ID table near to the user. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230923171921.53503-3-biju.das.jz@bp.renesas.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: pca955x: Convert enum->pointer for data in the match tablesBiju Das
Convert enum->pointer for data in the match tables, so that device_get_match_data() can do match against OF/ACPI/I2C tables, once i2c bus type match support added to it. Replace enum->struct *pca955x_chipdefs for data in the match table. Simplify the probe() by replacing device_get_match_data() and ID lookup for retrieving data by i2c_get_match_data(). While at it, add const definition to pca955x_chipdefs[]. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230923171921.53503-2-biju.das.jz@bp.renesas.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: lp3952: Replace deprecated strncpy with strscpyJustin Stitt
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. We expect `dest` to be NUL-terminated due to its use with dev_err. lp3952_get_label()'s dest argument is priv->leds[i].name: | acpi_ret = lp3952_get_label(&priv->client->dev, led_name_hdl[i], | priv->leds[i].name); ... which is then assigned to: | priv->leds[i].cdev.name = priv->leds[i].name; ... which is used with a format string | dev_err(&priv->client->dev, | "couldn't register LED %s\n", | priv->leds[i].cdev.name); There is no indication that NUL-padding is required but if it is let's opt for strscpy_pad. Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230922-strncpy-drivers-leds-leds-lp3952-c-v1-1-4941d6f60ca4@google.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: trigger: ledtrig-cpu:: Fix 'output may be truncated' issue for 'cpu'Christophe JAILLET
In order to teach the compiler that 'trig->name' will never be truncated, we need to tell it that 'cpu' is not negative. When building with W=1, this fixes the following warnings: drivers/leds/trigger/ledtrig-cpu.c: In function ‘ledtrig_cpu_init’: drivers/leds/trigger/ledtrig-cpu.c:155:56: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 [-Werror=format-truncation=] 155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu); | ^~ drivers/leds/trigger/ledtrig-cpu.c:155:52: note: directive argument in the range [-2147483648, 7] 155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu); | ^~~~~~~ drivers/leds/trigger/ledtrig-cpu.c:155:17: note: ‘snprintf’ output between 5 and 15 bytes into a destination of size 8 155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 8f88731d052d ("led-triggers: create a trigger for CPU activity") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/3f4be7a99933cf8566e630da54f6ab913caac432.1695453322.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: pwm: Don't disable the PWM when the LED should be offUwe Kleine-König
Disabling a PWM (i.e. calling pwm_apply_state with .enabled = false) gives no guarantees what the PWM output does. It might freeze where it currently is, or go in a High-Z state or drive the active or inactive state, it might even continue to toggle. To ensure that the LED gets really disabled, don't disable the PWM even when .duty_cycle is zero. This fixes disabling a leds-pwm LED on i.MX28. The PWM on this SoC is one of those that freezes its output on disable, so if you disable an LED that is full on, it stays on. If you disable a LED with half brightness it goes off in 50% of the cases and full on in the other 50%. Fixes: 41c42ff5dbe2 ("leds: simple driver for pwm driven LEDs") Reported-by: Rogan Dawes <rogan@dawes.za.net> Reported-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@denx.de> Link: https://lore.kernel.org/r/20230922192834.1695727-1-u.kleine-koenig@pengutronix.de Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: turris-omnia: Add support for enabling/disabling HW gamma correctionMarek Behún
If the MCU on Turris Omnia is running newer firmware versions, the LED controller supports RGB gamma correction (and enables it by default for newer boards). Determine whether the gamma correction setting feature is supported and add the ability to set it via sysfs attribute file. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230918161104.20860-5-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: turris-omnia: Support HW controlled mode via private triggerMarek Behún
Add support for enabling MCU controlled mode of the Turris Omnia LEDs via a LED private trigger called "omnia-mcu". Recall that private LED triggers will only be listed in the sysfs trigger file for LEDs that support them (currently there is no user of this mechanism). When in MCU controlled mode, the user can still set LED color, but the blinking is done by MCU, which does different things for different LEDs: - WAN LED is blinked according to the LED[0] pin of the WAN PHY - LAN LEDs are blinked according to the LED[0] output of the corresponding port of the LAN switch - PCIe LEDs are blinked according to the logical OR of the MiniPCIe port LED pins In the future I want to make the netdev trigger to transparently offload the blinking to the HW if user sets compatible settings for the netdev trigger (for LEDs associated with network devices). There was some work on this already, and hopefully we will be able to complete it sometime, but for now there are still multiple blockers for this, and even if there weren't, we still would not be able to configure HW controlled mode for the LEDs associated with MiniPCIe ports. In the meantime let's support HW controlled mode via the private LED trigger mechanism. If, in the future, we manage to complete the netdev trigger offloading, we can still keep this private trigger for backwards compatibility, if needed. We also set "omnia-mcu" to cdev->default_trigger, so that the MCU keeps control until the user first wants to take over it. If a different default trigger is specified in device-tree via the 'linux,default-trigger' property, LED class will overwrite cdev->default_trigger, and so the DT property will be respected. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230918161104.20860-4-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: turris-omnia: Make set_brightness() more efficientMarek Behún
Implement caching of the LED color and state values that are sent to MCU in order to make the set_brightness() operation more efficient by avoiding I2C transactions which are not needed. On Turris Omnia's MCU, which acts as the RGB LED controller, each LED has a RGB color, and a ON/OFF state, which are configurable via I2C commands CMD_LED_COLOR and CMD_LED_STATE. The CMD_LED_COLOR command sends 5 bytes and the CMD_LED_STATE command 2 bytes over the I2C bus, which operates at 100 kHz. With I2C overhead this allows ~1670 color changing commands and ~3200 state changing commands per second (or around 1000 color + state changes per second). This may seem more than enough, but the issue is that the I2C bus is shared with another peripheral, the MCU. The MCU exposes an interrupt interface, and it can trigger hundreds of interrupts per second. Each time, we need to read the interrupt state register over this I2C bus. Whenever we are sending a LED color/state changing command, the interrupt reading is waiting. Currently, every time LED brightness or LED multi intensity is changed, we send a CMD_LED_STATE command, and if the computed color (brightness adjusted multi_intensity) is non-zero, we also send a CMD_LED_COLOR command. Consider for example the situation when we have a netdev trigger enabled for a LED. The netdev trigger does not change the LED color, only the brightness (either to 0 or to currently configured brightness), and so there is no need to send the CMD_LED_COLOR command. But each change of brightness to 0 sends one CMD_LED_STATE command, and each change of brightness to max_brightness sends one CMD_LED_STATE command and one CMD_LED_COLOR command: set_brightness(0) -> CMD_LED_STATE set_brightness(255) -> CMD_LED_STATE + CMD_LED_COLOR (unnecessary) We can avoid the unnecessary I2C transactions if we cache the values of state and color that are sent to the controller. If the color does not change from the one previously sent, there is no need to do the CMD_LED_COLOR I2C transaction, and if the state does not change, there is no need to do the CMD_LED_STATE transaction. Because we need to make sure that our cached values are consistent with the controller state, add explicit setting of the LED color to white at probe time (this is the default setting when MCU resets, but does not necessarily need to be the case, for example if U-Boot played with the LED colors). Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230918161104.20860-3-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: turris-omnia: Do not use SMBUS callsMarek Behún
The leds-turris-omnia driver uses three function for I2C access: - i2c_smbus_write_byte_data() and i2c_smbus_read_byte_data(), which cause an emulated SMBUS transfer, - i2c_master_send(), which causes an ordinary I2C transfer. The Turris Omnia MCU LED controller is not semantically SMBUS, it operates as a simple I2C bus. It does not implement any of the SMBUS specific features, like PEC, or procedure calls, or anything. Moreover the I2C controller driver also does not implement SMBUS, and so the emulated SMBUS procedure from drivers/i2c/i2c-core-smbus.c is used for the SMBUS calls, which gives an unnecessary overhead. When I first wrote the driver, I was unaware of these facts, and I simply used the first function that worked. Drop the I2C SMBUS calls and instead use simple I2C transfers. Fixes: 089381b27abe ("leds: initial support for Turris Omnia LEDs") Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230918161104.20860-2-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-01leds: lp55xx: Use gpiod_set_value_cansleep()Stefan Eichenberger
Use gpiod_set_value_cansleep in the init_device function. Without this change, the driver may print a warning if the LP55xx enable pin is connected to a GPIO chip which can sleep (e.g. a GPIO expander): WARNING: CPU: 0 PID: 2719 at drivers/gpio/gpiolib.c:3051 gpiod_set_value+0x64/0xbc Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Link: https://lore.kernel.org/r/20230918143238.75600-1-eichest@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 16:07:54 +0000