summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-01-02Merge tag 'block-6.19-20260102' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - Scan partition tables asynchronously for ublk, similarly to how nvme does it. This avoids potential deadlocks, which is why nvme does it that way too. Includes a set of selftests as well. - MD pull request via Yu: - Fix null-pointer dereference in raid5 sysfs group_thread_cnt store (Tuo Li) - Fix possible mempool corruption during raid1 raid_disks update via sysfs (FengWei Shih) - Fix logical_block_size configuration being overwritten during super_1_validate() (Li Nan) - Fix forward incompatibility with configurable logical block size: arrays assembled on new kernels could not be assembled on older kernels (v6.18 and before) due to non-zero reserved pad rejection (Li Nan) - Fix static checker warning about iterator not incremented (Li Nan) - Skip CPU offlining notifications on unmapped hardware queues - bfq-iosched block stats fix - Fix outdated comment in bfq-iosched * tag 'block-6.19-20260102' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: block, bfq: update outdated comment blk-mq: skip CPU offline notify on unmapped hctx selftests/ublk: fix Makefile to rebuild on header changes selftests/ublk: add test for async partition scan ublk: scan partition in async way block,bfq: fix aux stat accumulation destination md: Fix forward incompatibility from configurable logical block size md: Fix logical_block_size configuration being overwritten md: suspend array while updating raid_disks via sysfs md/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt() md: Fix static checker warning in analyze_sbs
2026-01-02HID: bpf: drop dead NULL checks in kfuncsPuranjay Mohan
As KF_TRUSTED_ARGS is now considered default for all kfuns, the verifier will not allow passing NULL pointers to these kfuns. These checks for NULL pointers can therefore be removed. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260102180038.2708325-6-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-02bus: qcom-ebi2: Simplify with scoped for each OF child loopKrzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260102125030.65186-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-02Merge tag 'drm-fixes-2026-01-02' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Happy New Year, jetlagged fixes from me, still pretty quiet, xe is most of this, with i915/nouveau/imagination fixes and some shmem cleanups. shmem: - docs and MODULE_LICENSE fix xe: - Ensure svm device memory is idle before migration completes - Fix a SVM debug printout - Use READ_ONCE() / WRITE_ONCE() for g2h_fence i915: - Fix eb_lookup_vmas() failure path nouveau: - fix prepare_fb warnings imagination: - prevent export of protected objects" * tag 'drm-fixes-2026-01-02' of https://gitlab.freedesktop.org/drm/kernel: drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer drm/xe/guc: READ/WRITE_ONCE g2h_fence->done drm/pagemap, drm/xe: Ensure that the devmem allocation is idle before use drm/xe/svm: Fix a debug printout drm/gem-shmem: Fix the MODULE_LICENSE() string drm/gem-shmem: Fix typos in documentation drm/nouveau/dispnv50: Don't call drm_atomic_get_crtc_state() in prepare_fb drm/imagination: Disallow exporting of PM/FW protected objects
2026-01-02dm-stripe: adjust max_hw_discard_sectors to avoid unnecessary discard bio ↵Yongpeng Yang
splitting Currently, the max_hw_discard_sectors of a stripe target is set to the minimum max_hw_discard_sectors among all sub devices. When the discard bio is larger than max_hw_discard_sectors, this may cause the stripe device to split discard bios unnecessarily, because the value of max_hw_discard_sectors affects max_discard_sectors, which equal to min(max_hw_discard_sectors, max_user_discard_sectors). For example: root@vm:~# echo '0 33554432 striped 2 256 /dev/vdd 0 /dev/vde 0' | dmsetup create stripe_dev root@vm:~# cat /sys/block/dm-1/queue/discard_max_bytes 536870912 root@vm:~# cat /sys/block/dm-1/slaves/vdd/queue/discard_max_bytes 536870912 root@vm:~# blkdiscard -o 0 -l 1073741824 -p 1073741824 /dev/mapper/stripe_dev dm-1 is the stripe device, and its discard_max_bytes is equal to each sub device’s discard_max_bytes. Since the requested discard length exceeds discard_max_bytes, the block layer splits the discard bio: block_bio_queue: 252,1 DS 0 + 2097152 [blkdiscard] block_split: 252,1 DS 0 / 1048576 [blkdiscard] block_rq_issue: 253,48 DS 268435456 () 0 + 524288 be,0,4 [blkdiscard] block_bio_queue: 253,64 DS 524288 + 524288 [blkdiscard] However, both vdd and vde can actually handle a discard bio of 536870912 bytes, so this split is not necessary. This patch updates the stripe target’s q->limits.max_hw_discard_sectors to be the minimum max_hw_discard_sectors of the sub devices multiplied by the # of stripe devices, and max_hw_discard_sectors must round down to chunk size multiply # of stripe devices to avoid issue discard bio to sub devices which is larger than max_hw_discard_sectors. This patch enables the stripe device to handle larger discard bios without incurring unnecessary splitting. Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com> Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-02dm: replace -EEXIST with -EBUSYDaniel Gomez
The -EEXIST error code is reserved by the module loading infrastructure to indicate that a module is already loaded. When a module's init function returns -EEXIST, userspace tools like kmod interpret this as "module already loaded" and treat the operation as successful, returning 0 to the user even though the module initialization actually failed. This follows the precedent set by commit 54416fd76770 ("netfilter: conntrack: helper: Replace -EEXIST by -EBUSY") which fixed the same issue in nf_conntrack_helper_register(). Affected modules: * dm_cache dm_clone dm_integrity dm_mirror dm_multipath dm_pcache * dm_vdo dm-ps-round-robin dm_historical_service_time dm_io_affinity * dm_queue_length dm_service_time dm_snapshot Signed-off-by: Daniel Gomez <da.gomez@samsung.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-02dm: remove fake timeout to avoid leak requestDing Hui
Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] <TASK> [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] </TASK> Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts. Signed-off-by: Ding Hui <dinghui@sangfor.com.cn> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-02dm-vdo: adjust function name referenceJulia Lawall
There is no function advance_compression_stage(). But advance_data_vio_compression_stage() does iterate through the values of the data_vio_compression_stage enum, so it seems to be what was intended. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-02ACPI: scan: Drop outdated comment regarding removed functionJulia Lawall
The function acpi_video_get_capabilities() was removed from drivers/acpi/video_detect.c by commit 87521e16a7ab ("acpi-video-detect: Rewrite backlight interface selection logic") in 2015. At the time, comments about this function were just removed, and no replacement seemed to be proposed. Drop the reference to acpi_video_get_capabilities() here as well. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> [ rjw: Subject adjustment, changelog edits ] Link: https://patch.msgid.link/20251230160644.100439-1-Julia.Lawall@inria.fr Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-02ACPI: scan: Use resource_type() for resource type checkingRafael J. Wysocki
To follow a well-established existing pattern, use resource_type() for resource type checking in acpi_scan_claim_resources(). No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/12814730.O9o76ZdvQC@rafael.j.wysocki
2026-01-02ACPI: bus: Fix typo under sizeof() in acpi_run_osc()Rafael J. Wysocki
The sizeof(32) in acpi_run_osc() should be sizeof(u32), so fix it. Fixes: e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/2817106.mvXUDI8C0e@rafael.j.wysocki
2026-01-02ACPI: bus: Adjust acpi_osc_handshake() parameter listRafael J. Wysocki
For the sake of interface cleanliness, it is better to avoid using ACPICA data types in the parameter lists of helper functions that don't belong to ACPICA, so adjust the parameter list of recently introduced acpi_osc_handshake() to take a capabilities buffer pointer and the size of the buffer (in u32 size units) as parameters directly instead of a struct acpi_buffer pointer. This is also somewhat more straightforward on the caller side because they won't need to create struct acpi_buffer objects themselves to pass them to the helper function and it guarantees that the size of the buffer in bytes will always be a multiple of 4 (the size of u32). Moreover, it addresses a premature cap pointer dereference and eliminates a sizeof(32) that should have been sizeof(u32) [1]. Fixes: e5322888e6bf ("ACPI: bus: Rework the handling of \_SB._OSC platform features") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-acpi/202512242052.W4GhDauV-lkp@intel.com/ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> [ rjw: Fixed typo under sizeof(), used ARRAY_SIZE() in two places ] Link: https://patch.msgid.link/12833187.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-02virtio: add virtqueue_add_inbuf_cache_clean APIMichael S. Tsirkin
Add virtqueue_add_inbuf_cache_clean() for passing DMA_ATTR_CPU_CACHE_CLEAN to virtqueue operations. This suppresses DMA debug cacheline overlap warnings for buffers where proper cache management is ensured by the caller. Message-ID: <e50d38c974859e731e50bda7a0ee5691debf5bc4.1767601130.git.mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2026-01-02drm/i915/gvt: include intel_display_limits.h where neededJani Nikula
In this case, it's actually gvt.h that needs I915_MAX_PORTS etc. from intel_display_limits.h. Make this more evident by moving the include there, instead of getting it via fb_decoder.h. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/30696b712f4beba171c15765632ad9c3e1b8b1d1.1767180318.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-02drm/i915/gvt: reduce include of vfio.hJani Nikula
Nothing in dmabuf.h needs vfio.h. Replace with actually needed minimal includes. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/fbfca6252798ab58717486d1592fed310f880d42.1767180318.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-02drm/i915/gvt: reduce include of gt/intel_engine_regs.hJani Nikula
Move IS_RESTORE_INHIBIT() to scheduler.c, along with the gt/intel_engine_regs.h include. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/2f5440016b5d164a6f3889565761caa17cccd4b7.1767180318.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-02drm/i915/gvt: include sched_policy.h only where neededJani Nikula
Not everything needs sched_policy.h. Drop it from gvt.h, and include where needed. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/2807f82cf571ed6e736242bdfad786efcad50f02.1767180318.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-02drm/i915/gvt: sort and group include directivesJani Nikula
The include directives are a bit of a mess in gvt. Sort and group them to make them easier to deal with. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/c9f2b5a7367671965a7f5fa4f22b94ce9b980cfd.1767180318.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-02gpio: max77759: drop use of irqd_get_trigger_typeAndré Draszik
irqd_get_trigger_type() is meant for cases where the driver needs to know the configured IRQ trigger type and e.g. wants to change its behaviour accordingly. Furthermore, platform support code, e.g. DT handling, will configure the hardware based on that, and drivers don't need to pass the trigger type into request_irq() and friends. Drop the use from this driver, as it doesn't need to know the trigger type. Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20251217-max77759-gpio-irq-trigger-v1-1-5738953c1172@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-02gpio: add gpio-line-mux driverJonas Jelonek
Add a new driver which provides a 1-to-many mapping for a single real GPIO using a multiplexer. Each virtual GPIO corresponds to a multiplexer state which, if set for the multiplexer, connects the real GPIO to the corresponding virtual GPIO. This can help in various usecases. One practical case is the special hardware design of the Realtek-based XS1930-10 switch from Zyxel. It features two SFP+ ports/cages whose signals are wired directly to the switch SoC. Although Realtek SoCs are short on GPIOs, there are usually enough the fit the SFP signals without any hacks. However, Zyxel did some weird design and connected RX_LOS, MOD_ABS and TX_FAULT of one SFP cage onto a single GPIO line controlled by a multiplexer (the same for the other SFP cage). The single multiplexer controls the lines for both SFP and depending on the state, the designated 'signal GPIO lines' are connected to one of the three SFP signals. Because the SFP core/driver doesn't support multiplexer but needs single GPIOs for each of the signals, this driver fills the gap between both. It registers a gpio_chip, provides multiple virtual GPIOs and sets the backing multiplexer accordingly. Due to several practical issues, this is input-only and doesn't support IRQs. Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com> Reviewed-by: Thomas Richard <thomas.richard@bootlin.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251227180134.1262138-3-jelonek.jonas@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-02drm/i915/display: remove accidentally added empty fileJani Nikula
intel_display_limits.c was never supposed to be added. Remove it. Fixes: f3255cf4490e ("drm/i915/display: Add APIs to be used by gvt to get the register offsets") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20251231103232.627666-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-02gpio: mpsse: fix reference leak in gpio_mpsse_probe() error pathsAbdun Nihaal
The reference obtained by calling usb_get_dev() is not released in the gpio_mpsse_probe() error paths. Fix that by using device managed helper functions. Also remove the usb_put_dev() call in the disconnect function since now it will be released automatically. Cc: stable@vger.kernel.org Fixes: c46a74ff05c0 ("gpio: add support for FTDI's MPSSE as GPIO") Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Link: https://lore.kernel.org/r/20251226060414.20785-1-nihaal@cse.iitm.ac.in Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-02gpio: pca953x: handle short interrupt pulses on PCAL devicesErnest Van Hoecke
GPIO drivers with latch input support may miss short pulses on input pins even when input latching is enabled. The generic interrupt logic in the pca953x driver reports interrupts by comparing the current input value against the previously sampled one and only signals an event when a level change is observed between two reads. For short pulses, the first edge is captured when the input register is read, but if the signal returns to its previous level before the read, the second edge is not observed. As a result, successive pulses can produce identical input values at read time and no level change is detected, causing interrupts to be missed. Below timing diagram shows this situation where the top signal is the input pin level and the bottom signal indicates the latched value. ─────┐ ┌──*───────────────┐ ┌──*─────────────────┐ ┌──*─── │ │ . │ │ . │ │ . │ │ │ │ │ │ │ │ │ └──*──┘ │ └──*──┘ │ └──*──┘ │ Input │ │ │ │ │ │ ▼ │ ▼ │ ▼ │ IRQ │ IRQ │ IRQ │ . . . ─────┐ .┌──────────────┐ .┌────────────────┐ .┌── │ │ │ │ │ │ │ │ │ │ │ │ └────────*┘ └────────*┘ └────────*┘ Latched │ │ │ ▼ ▼ ▼ READ 0 READ 0 READ 0 NO CHANGE NO CHANGE PCAL variants provide an interrupt status register that records which pins triggered an interrupt, but the status and input registers cannot be read atomically. The interrupt status is only cleared when the input port is read, and the input value must also be read to determine the triggering edge. If another interrupt occurs on a different line after the status register has been read but before the input register is sampled, that event will not be reflected in the earlier status snapshot, so relying solely on the interrupt status register is also insufficient. Support for input latching and interrupt status handling was previously added by [1], but the interrupt status-based logic was reverted by [2] due to these issues. This patch addresses the original problem by combining both sources of information. Events indicated by the interrupt status register are merged with events detected through the existing level-change logic. As a result: * short pulses, whose second edges are invisible, are detected via the interrupt status register, and * interrupts that occur between the status and input reads are still caught by the generic level-change logic. This significantly improves robustness on devices that signal interrupts as short pulses, while avoiding the issues that led to the earlier reversion. In practice, even if only the first edge of a pulse is observable, the interrupt is reliably detected. This fixes missed interrupts from an Ilitek touch controller with its interrupt line connected to a PCAL6416A, where active-low pulses are approximately 200 us long. [1] commit 44896beae605 ("gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2") [2] commit d6179f6c6204 ("gpio: pca953x: Improve interrupt support") Fixes: d6179f6c6204 ("gpio: pca953x: Improve interrupt support") Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20251217153050.142057-1-ernestvanhoecke@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-02gpiolib: fix race condition for gdev->srcuPaweł Narewski
If two drivers were calling gpiochip_add_data_with_key(), one may be traversing the srcu-protected list in gpio_name_to_desc(), meanwhile other has just added its gdev in gpiodev_add_to_list_unlocked(). This creates a non-mutexed and non-protected timeframe, when one instance is dereferencing and using &gdev->srcu, before the other has initialized it, resulting in crash: [ 4.935481] Unable to handle kernel paging request at virtual address ffff800272bcc000 [ 4.943396] Mem abort info: [ 4.943400] ESR = 0x0000000096000005 [ 4.943403] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.943407] SET = 0, FnV = 0 [ 4.943410] EA = 0, S1PTW = 0 [ 4.943413] FSC = 0x05: level 1 translation fault [ 4.943416] Data abort info: [ 4.943418] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 4.946220] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.955261] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.955268] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000038e6c000 [ 4.961449] [ffff800272bcc000] pgd=0000000000000000 [ 4.969203] , p4d=1000000039739003 [ 4.979730] , pud=0000000000000000 [ 4.980210] phandle (CPU): 0x0000005e, phandle (BE): 0x5e000000 for node "reset" [ 4.991736] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP ... [ 5.121359] pc : __srcu_read_lock+0x44/0x98 [ 5.131091] lr : gpio_name_to_desc+0x60/0x1a0 [ 5.153671] sp : ffff8000833bb430 [ 5.298440] [ 5.298443] Call trace: [ 5.298445] __srcu_read_lock+0x44/0x98 [ 5.309484] gpio_name_to_desc+0x60/0x1a0 [ 5.320692] gpiochip_add_data_with_key+0x488/0xf00 5.946419] ---[ end trace 0000000000000000 ]--- Move initialization code for gdev fields before it is added to gpio_devices, with adjacent initialization code. Adjust goto statements to reflect modified order of operations Fixes: 47d8b4c1d868 ("gpio: add SRCU infrastructure to struct gpio_device") Reviewed-by: Jakub Lewalski <jakub.lewalski@nokia.com> Signed-off-by: Paweł Narewski <pawel.narewski@nokia.com> [Bartosz: fixed a build issue, removed stray newline] Link: https://lore.kernel.org/r/20251224082641.10769-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-02gpio: shared: allow sharing a reset-gpios pin between reset-gpio and gpiolibBartosz Golaszewski
We currently support sharing GPIOs between multiple devices whose drivers use either the GPIOLIB API *OR* the reset control API but not both at the same time. There's an unlikely corner-case where a reset-gpios pin can be shared by one driver using the GPIOLIB API and a second using the reset API. This will currently not work as the reset-gpio consumers are not described in firmware at the time of scanning so the shared GPIO just chooses one of the proxies created for the consumers when the reset-gpio driver performs the lookup. This can of course conflict in the case described above. In order to fix it: if we deal with the "reset-gpios" pin that's shared acconding to the firmware node setup, create a proxy for each described consumer as well as another one for the potential reset-gpio device. To that end: rework the matching to take this into account. Fixes: 7b78b26757e0 ("gpio: shared: handle the reset-gpios corner case") Link: https://lore.kernel.org/r/20251222-gpio-shared-reset-gpio-proxy-v1-3-8d4bba7d8c14@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-02gpio: shared: verify con_id when adding proxy lookupBartosz Golaszewski
When matching the firmware node with the potential consumer, we currently omit the con_id string. This can lead to false positives in the unlikely case of the consumer having been assigned more than one shared GPIO. Check the connector ID before proceeding. Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support") Link: https://lore.kernel.org/r/20251222-gpio-shared-reset-gpio-proxy-v1-2-8d4bba7d8c14@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-02gpiolib: allow multiple lookup tables per consumerBartosz Golaszewski
The GPIO machine lookup mechanism dates back to old ARM board files where lookup tables would all be defined in a single place. Since then, lookup tables have also been used to address various DT and ACPI quirks like missing GPIOs and - as of recently - setting up shared GPIO proxy devices. The lookup itself stops when we find the first matching table for a consumer and - if it doesn't contain the right entry - the lookup fails. Since the tables can now be defined in multiple places and we can't know how many there are, effectively limiting a consumer to only a single lookup table is no longer viable. Rework the code to always look through all tables matching the consumer. Link: https://lore.kernel.org/r/20251222-gpio-shared-reset-gpio-proxy-v1-1-8d4bba7d8c14@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-01pinctrl: qcom: lpass-lpi: mark the GPIO controller as sleepingBartosz Golaszewski
The gpio_chip settings in this driver say the controller can't sleep but it actually uses a mutex for synchronization. This triggers the following BUG(): [ 9.233659] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281 [ 9.233665] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 554, name: (udev-worker) [ 9.233669] preempt_count: 1, expected: 0 [ 9.233673] RCU nest depth: 0, expected: 0 [ 9.233688] Tainted: [W]=WARN [ 9.233690] Hardware name: Dell Inc. Latitude 7455/0FK7MX, BIOS 2.10.1 05/20/2025 [ 9.233694] Call trace: [ 9.233696] show_stack+0x24/0x38 (C) [ 9.233709] dump_stack_lvl+0x40/0x88 [ 9.233716] dump_stack+0x18/0x24 [ 9.233722] __might_resched+0x148/0x160 [ 9.233731] __might_sleep+0x38/0x98 [ 9.233736] mutex_lock+0x30/0xd8 [ 9.233749] lpi_config_set+0x2e8/0x3c8 [pinctrl_lpass_lpi] [ 9.233757] lpi_gpio_direction_output+0x58/0x90 [pinctrl_lpass_lpi] [ 9.233761] gpiod_direction_output_raw_commit+0x110/0x428 [ 9.233772] gpiod_direction_output_nonotify+0x234/0x358 [ 9.233779] gpiod_direction_output+0x38/0xd0 [ 9.233786] gpio_shared_proxy_direction_output+0xb8/0x2a8 [gpio_shared_proxy] [ 9.233792] gpiod_direction_output_raw_commit+0x110/0x428 [ 9.233799] gpiod_direction_output_nonotify+0x234/0x358 [ 9.233806] gpiod_configure_flags+0x2c0/0x580 [ 9.233812] gpiod_find_and_request+0x358/0x4f8 [ 9.233819] gpiod_get_index+0x7c/0x98 [ 9.233826] devm_gpiod_get+0x34/0xb0 [ 9.233829] reset_gpio_probe+0x58/0x128 [reset_gpio] [ 9.233836] auxiliary_bus_probe+0xb0/0xf0 [ 9.233845] really_probe+0x14c/0x450 [ 9.233853] __driver_probe_device+0xb0/0x188 [ 9.233858] driver_probe_device+0x4c/0x250 [ 9.233863] __driver_attach+0xf8/0x2a0 [ 9.233868] bus_for_each_dev+0xf8/0x158 [ 9.233872] driver_attach+0x30/0x48 [ 9.233876] bus_add_driver+0x158/0x2b8 [ 9.233880] driver_register+0x74/0x118 [ 9.233886] __auxiliary_driver_register+0x94/0xe8 [ 9.233893] init_module+0x34/0xfd0 [reset_gpio] [ 9.233898] do_one_initcall+0xec/0x300 [ 9.233903] do_init_module+0x64/0x260 [ 9.233910] load_module+0x16c4/0x1900 [ 9.233915] __arm64_sys_finit_module+0x24c/0x378 [ 9.233919] invoke_syscall+0x4c/0xe8 [ 9.233925] el0_svc_common+0x8c/0xf0 [ 9.233929] do_el0_svc+0x28/0x40 [ 9.233934] el0_svc+0x38/0x100 [ 9.233938] el0t_64_sync_handler+0x84/0x130 [ 9.233943] el0t_64_sync+0x17c/0x180 Mark the controller as sleeping. Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver") Cc: stable@vger.kernel.org Reported-by: Val Packett <val@packett.cool> Closes: https://lore.kernel.org/all/98c0f185-b0e0-49ea-896c-f3972dd011ca@packett.cool/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-01-01pinctrl: pic64gx-gpio2: Add REGMAP_MMIO dependencySander Vanheule
In line with other drivers depending on REGMAP_*, select the required symbol to prevent a linker error when building with COMPILE_TEST=y: ld: drivers/pinctrl/pinctrl-pic64gx-gpio2.o: in function `pic64gx_gpio2_probe': pinctrl-pic64gx-gpio2.c:315:(.text+0x198): undefined reference to `__devm_regmap_init_mmio_clk' Fixes: 38cf9d641314 ("pinctrl: add pic64gx "gpio2" pinmux driver") Signed-off-by: Sander Vanheule <sander@svanheule.net> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-01-01drm/i915/gt: use designated initializers for intel_gt_debugfs_fileSebastian Brzezinka
CONFIG_RANDSTRUCT may reorder structure fields, which makes positional initializers unsafe. The i915 GT debugfs tables were using positional initializers for `struct intel_gt_debugfs_file`, and on configs where the layout differs (e.g., presence/absence of the `.eval` callback), this can lead to fields being initialized incorrectly and trigger randstruct warnings such as: ``` drivers/gpu/drm/i915/gt/intel_gt_debugfs.c:75:51: note: randstruct: casting between randomized structure pointer types (constructor) ``` Switch all the GT debugfs file arrays to designated initializers. This binds each value to the intended member regardless of structure reordering or optional members and removes the warning while preserving the intended initialization. Also drops the '&' from intel_eval_slpc_support so .eval receives the function pointer directly. No functional change, only initialization style is updated. Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/bae491e8098705a87304a7c94573b377e8c8fa37.1765897826.git.sebastian.brzezinka@intel.com
2026-01-01dmaengine: pl08x: Fix comment stating the difference between PL080 and PL081Vladimir Zapolskiy
Fix a trivial typo in the comment, otherwise it takes an effort to understand what it actually means to say. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://patch.msgid.link/20251225173847.1395928-1-vz@mleia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01dmaengine: at_xdmac: get the number of DMA channels from device treeTony Han
In case of kernel runs in non-secure mode, the number of DMA channels can be got from device tree since the value read from GTYPE register is "0" as it's always secured. As the number of channels can never be negative, update them to the type "unsigned". This is required for LAN969x. Signed-off-by: Tony Han <tony.han@microchip.com> Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://patch.msgid.link/20251203121208.1269487-1-robert.marko@sartura.hr Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: qcom: edp: Add Glymur platform supportAbel Vesa
The Qualcomm Glymur platform has the new v8 version of the eDP/DP PHY. So rework the driver to support this new version and add the platform specific configuration data. While at it, add the rest of the AUX_CFG reset values for the v4 and v5 platforms, which makes the handling of the platforms specific array cleaner, as they are single sized now. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-glymur-support-v6-4-4fcba75a6fa9@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: qcom-qmp: qserdes-com: Add v8 DP-specific qserdes register offsetsAbel Vesa
Starting with Glymur, the PCIe and DP PHYs qserdes register offsets differ for the same version number. So in order to be able to differentiate between them, add these ones with DP prefix. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-glymur-support-v6-3-4fcba75a6fa9@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: qcom: edp: Fix the DP_PHY_AUX_CFG registers countAbel Vesa
On all platforms supported by this driver, there are 13 DP_PHY_AUX_CFGx registers. This hasn't been an issue so far on currently supported platforms, because the init sequence never spanned beyond DP_PHY_AUX_CFG9. However, on the new upcoming Glymur platform, these are updated along with the rest of the init sequence. So update the size of the array holding the config to 13. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-glymur-support-v6-2-4fcba75a6fa9@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: qcom: edp: Make the number of clocks flexibleAbel Vesa
On X Elite, the DP PHY needs another clock called ref, while all other platforms do not. The current X Elite devices supported upstream work fine without this clock, because the boot firmware leaves this clock enabled. But we should not rely on that. Also, even though this change breaks the ABI, it is needed in order to make the driver disables this clock along with the other ones, for a proper bring-down of the entire PHY. So in order to handle these clocks on different platforms, make the driver get all the clocks regardless of how many there are provided. Cc: stable@vger.kernel.org # v6.10 Fixes: db83c107dc29 ("phy: qcom: edp: Add v6 specific ops and X1E80100 platform support") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://patch.msgid.link/20251224-phy-qcom-edp-add-missing-refclk-v5-2-3f45d349b5ac@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: qcom: qmp-pcie: Add support for Glymur PCIe Gen4x2 PHYAbel Vesa
Glymur platform has two Gen4 2-lanes controllers, the fourth and sixth instances. Add support for their PHYs. Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20251224-phy-qcom-pcie-add-glymur-v3-2-57396145bc22@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: broadcom: ns-usb3: Fix Wvoid-pointer-to-enum-cast warning (again)Krzysztof Kozlowski
"family" is an enum, thus cast of pointer on 64-bit compile test with clang W=1 causes: phy-bcm-ns-usb3.c:206:17: error: cast to smaller integer type 'enum bcm_ns_family' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] This was already fixed in commit bd6e74a2f0a0 ("phy: broadcom: ns-usb3: fix Wvoid-pointer-to-enum-cast warning") but then got bad in commit 21bf6fc47a1e ("phy: Use device_get_match_data()"). Note that after various discussions the preferred cast is via "unsigned long", not "uintptr_t". Fixes: 21bf6fc47a1e ("phy: Use device_get_match_data()") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251224115533.154162-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: renesas: rcar-gen2: Simplify with scoped for each OF child loopKrzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251224124407.208354-6-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: core: Simplify with scoped for each OF child loopKrzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251224124407.208354-5-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: rockchip: usb: Simplify with scoped for each OF child loopKrzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251224124407.208354-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: spacemit: support K1 USB2.0 PHY controllerZe Huang
The SpacemiT K1 SoC includes three USB ports: - One USB2.0 OTG port - One USB2.0 host-only port - One USB3.0 port with an integrated USB2.0 DRD interface Each of these ports is connected to a USB2.0 PHY responsible for USB2 transmission. This commit adds support for the SpacemiT K1 USB2.0 PHY, which is compliant with the USB 2.0 specification and supports both 8-bit 60MHz and 16-bit 30MHz parallel interfaces. Signed-off-by: Ze Huang <huang.ze@linux.dev> Tested-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Junzhong Pan <panjunzhong@linux.spacemit.com> Link: https://patch.msgid.link/20251017-k1-usb2phy-v6-2-7cf9ea2477a1@linux.dev Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: renesas: phy-rcar-gen2: fix typo in function name referenceJulia Lawall
Replace cmpxcgh by cmpxchg. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251230141050.93856-1-Julia.Lawall@inria.fr Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: adjust function name referenceJulia Lawall
There is no function clk_bulk_prepare_disable. Refer instead to clk_bulk_disable_unprepare, which is called in the function defined just below. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Reviewed-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/20251230140601.93474-1-Julia.Lawall@inria.fr Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01phy: core: Reinstate pm_runtime_enabled() check in phy_pm_runtime_put()Geert Uytterhoeven
On Koelsch (R-Car M2-W), during boot and s2ram: phy phy-e6590100.usb-phy-controller.0: Runtime PM usage count underflow! While phy_pm_runtime_get{,_sync}() and phy_pm_runtime_put_sync() still contain pm_runtime_enabled() checks, the same check in phy_pm_runtime_put() was deemed redundant and removed, causing count underflows with PHY drivers like drivers/phy/renesas/phy-rcar-gen2.c that do not use Runtime PM yet, Fix this by reinstating the check. Fixes: caad07ae07e3fb17 ("phy: core: Discard pm_runtime_put() return values") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3ca9f8166d21685bfbf97535da30172f74822130.1767107014.git.geert+renesas@glider.be Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-01Merge tag 'drm-xe-next-2025-12-30' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Core Changes: - Dynamic pagemaps and multi-device SVM (Thomas) Driver Changes: - Introduce SRIOV scheduler Groups (Daniele) - Configure migration queue as low latency (Francois) - Don't use absolute path in generated header comment (Calvin Owens) - Add SoC remapper support for system controller (Umesh) - Insert compiler barriers in GuC code (Jonathan) - Rebar updates (Lucas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aVOiULyYdnFbq-JB@fedora
2026-01-01Merge tag 'drm-intel-fixes-2025-12-31' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes drm/i915 fixes for v6.19-rc4: - Fix eb_lookup_vmas() failure path Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/4e79f041395bb8bcc9b2a76bb98b5e3df1c1c3eb@intel.com
2026-01-01Merge tag 'drm-misc-fixes-2025-12-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.19-rc4: - Documentation fixes and MODULE_LICENSE fix for shmem helper. - Fix warnings in nouveau prepare_fb(). - Prevent export of protected objects in imagination driver. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/5506492b-02ca-47bc-8712-51e67f0e4b8b@linux.intel.com
2026-01-01Merge tag 'drm-xe-fixes-2025-12-30' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Core Changes: - Ensure a SVM device memory allocation is idle before migration complete (Thomas) Driver Changes: - Fix a SVM debug printout (Thomas) - Use READ_ONCE() / WRITE_ONCE() for g2h_fence (Jonathan) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aVOTf6-whmkgrUuq@fedora
2025-12-31wifi: mt76: Remove blank line after mt792x firmware version dmesgShuah Khan
An extra blank line gets printed after printing firmware version because the build date is null terminated. Remove the "\n" from dev_info() calls to print firmware version and build date to fix the problem. Reported-by: Mario Limonciello <superm1@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>