| Age | Commit message (Collapse) | Author |
|---|
|
drm_gem_put_pages(), which we rely on for returning BO pages to shmem,
assume per-folio refcounting and not per-page. If we call
shmem_read_mapping_page() per-page, we break this assumption and leak
pages every time we get a huge page allocated.
v2:
- Rework the logic for() loop to better match the folio-granular
allocation scheme
Cc: Loïc Molinari <loic.molinari@collabora.com>
Fixes: c12e9fcb5a5a ("drm/panfrost: Introduce huge tmpfs mountpoint option")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20260108123325.1088195-1-boris.brezillon@collabora.com
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
|
|
If a switch port has more than one decoder that is using the same
downstream port, the enumeration of the target lists may fail with:
# dmesg | grep target.list
update_decoder_targets: cxl decoder1.0: dport3 found in target list, index 3
update_decoder_targets: cxl decoder1.0: dport2 found in target list, index 2
update_decoder_targets: cxl decoder1.0: dport0 found in target list, index 0
update_decoder_targets: cxl decoder2.0: dport3 found in target list, index 1
update_decoder_targets: cxl decoder4.0: dport3 found in target list, index 1
cxl_mem mem6: failed to find endpoint12:0000:00:01.4 in target list of decoder2.1
cxl_mem mem8: failed to find endpoint13:0000:20:01.4 in target list of decoder4.1
The case, that the same downstream port can be used in multiple target
lists, is allowed and possible.
Fix the update of the target list. Enumerate all children of the
switch port and do not stop the iteration after the first matching
target was found.
With the fix applied:
# dmesg | grep target.list
update_decoder_targets: cxl decoder1.0: dport2 found in target list, index 2
update_decoder_targets: cxl decoder1.0: dport0 found in target list, index 0
update_decoder_targets: cxl decoder1.0: dport3 found in target list, index 3
update_decoder_targets: cxl decoder2.0: dport3 found in target list, index 1
update_decoder_targets: cxl decoder2.1: dport3 found in target list, index 1
update_decoder_targets: cxl decoder4.0: dport3 found in target list, index 1
update_decoder_targets: cxl decoder4.1: dport3 found in target list, index 1
Analyzing the conditions when this happens:
1) A dport is shared by multiple decoders.
2) The decoders have interleaving configured (ways > 1).
The configuration above has the following hierarchy details (fixed
version):
root0
|_
| |
| decoder0.1
| ways: 2
| target_list: 0,1
|_______________________________________
| |
| dport0 | dport1
| |
port2 port4
| |
|___________________ |_____________________
| | | | | |
| decoder2.0 decoder2.1 | decoder4.0 decoder4.1
| ways: 2 ways: 2 | ways: 2 ways: 2
| target_list: 2,3 target_list: 2,3 | target_list: 2,3 target_list: 2,3
|___________________ |___________________
| | | |
| dport2 | dport3 | dport2 | dport3
| | | |
endpoint7 endpoint12 endpoint9 endpoint13
|_ |_ |_ |_
| | | | | | | |
| decoder7.0 | decoder12.0 | decoder9.0 | decoder13.0
| decoder7.2 | decoder12.2 | decoder9.2 | decoder13.2
| | | |
mem3 mem5 mem6 mem8
Note: Device numbers vary for every boot.
Current kernel fails to enumerate endpoint12 and endpoint13 as the
target list is not updated for the second decoder.
Fixes: 4f06d81e7c6a ("cxl: Defer dport allocation for switch ports")
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Robert Richter <rrichter@amd.com>
Link: https://patch.msgid.link/20260108101324.509667-1-rrichter@amd.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
|
|
When renaming this function, the name in the docs was not updated. This
causes a KernelDoc warning. Thus, fix it.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601091113.0b0WuRML-lkp@intel.com/
Fixes: 9bf4ca1e699c ("drm/gpuvm: drm_gpuvm_bo_obtain() requires lock and staged mode")
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260109082019.3999814-1-aliceryhl@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI support fix from Rafael Wysocki:
"This fixes the ACPI/PCI legacy interrupts (INTx) parsing in the case
when the ACPI Global System Interrupt (GSI) value is a 32-bit one with
the MSB set.
That was interpreted as a negative integer and caused
acpi_pci_link_allocate_irq() to fail and acpi_irq_get_penalty() to
trigger an out-of-bounds array dereference (Lorenzo Pieralisi)"
* tag 'acpi-6.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: PCI: IRQ: Fix INTx GSIs signedness
|
|
The guc_hw_reg_state array is not exported, so make it static.
Fixes the following sparse warning:
drivers/gpu/drm/i915/i915_gpu_error.c:692:3: warning: symbol 'guc_hw_reg_state' was not declared. Should it be static?
Fixes: ba391a102ec11 ("drm/i915/guc: Include the GuC registers in the error state")
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260108201202.59250-2-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
"There are several ordinary driver fixes and a fix to a race between
the registration of two chips that causes a crash in GPIO core.
The bulk of the changed lines however, concerns the management of
shared GPIOs that landed in v6.19-rc1. Enabling it for ARCH_QCOM
enabled it in defconfig which effectively enabled it for all arm64
platforms and exposed the code to quite a lot of testing (which is
good, right? :)).
As a resukt, I received a number of bug reports, which I progressively
fixed over the course of last weeks. This explains the number of lines
higher than what I normally aim for at this stage.
- balance superio enter/exit calls in error path in gpio-it87
- fix a race where we try to take the SRCU read lock of the GPIO
device before it's been initialized causing a NULL-pointer
dereference
- fix handling of short-pulse interrupts in gpio-pca053x
- fix a reference leak in error path in gpio-mpsse
- mark the GPIO controller as sleeping (it calls sleeping functions)
in gpio-rockchip
- fix several issues in management of shared GPIOs"
* tag 'gpio-fixes-for-v6.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: shared: fix a false-positive sharing detection with reset-gpios
gpiolib: fix lookup table matching
gpio: shared: don't allocate the lookup table until we really need it
gpio: shared: fix a race condition
gpio: shared: assign the correct firmware node for reset-gpio use-case
gpio: rockchip: mark the GPIO controller as sleeping
gpio: mpsse: fix reference leak in gpio_mpsse_probe() error paths
gpio: pca953x: handle short interrupt pulses on PCAL devices
gpiolib: fix race condition for gdev->srcu
gpio: shared: allow sharing a reset-gpios pin between reset-gpio and gpiolib
gpio: shared: verify con_id when adding proxy lookup
gpiolib: allow multiple lookup tables per consumer
gpio: it87: balance superio enter/exit calls in error path
|
|
Pull drm fixes from Dave Airlie:
"I missed the drm-rust fixes tree for last week, so this catches up on
that, along with amdgpu, and then some misc fixes across a few
drivers. I hadn't got an xe pull by the time I sent this, I suspect
one will arrive 10 mins after, but I don't think there is anything
that can't wait for next week.
Things seem to have picked up a little with people coming back from
holidays,
MAINTAINERS:
- Fix Nova GPU driver git links
- Fix typo in TYR driver entry preventing correct behavior of
scripts/get_maintainer.pl
- Exclude TYR driver from DRM MISC
nova-core:
- Correctly select RUST_FW_LOADER_ABSTRACTIONS to prevent build
errors
- Regenerate nova-core bindgen bindings with '--explicit-padding' to
avoid uninitialized bytes
- Fix length of received GSP messages, due to miscalculated message
payload size
- Regenerate bindings to derive MaybeZeroable
- Use a bindings alias to derive the firmware version
exynos:
- hdmi: replace system_wq with system_percpu_wq
pl111:
- Fix error handling in probe
mediatek/atomic/tidss:
- Fix tidss in another way and revert reordering of pre-enable and
post-disable operations, as it breaks other bridge drivers
nouveau:
- Fix regression from fwsec s/r fix
pci/vga:
- Fix multiple gpu's being reported a 'boot_display'
fb-helper:
- Fix vblank timeout during suspend/reset
amdgpu:
- Clang fixes
- Navi1x PCIe DPM fixes
- Ring reset fixes
- ISP suspend fix
- Analog DC fixes
- VPE fixes
- Mode1 reset fix
radeon:
- Variable sized array fix"
* tag 'drm-fixes-2026-01-09' of https://gitlab.freedesktop.org/drm/kernel: (32 commits)
Reapply "Revert "drm/amd: Skip power ungate during suspend for VPE""
drm/amd/display: Check NULL before calling dac_load_detection
drm/amd/pm: Disable MMIO access during SMU Mode 1 reset
drm/exynos: hdmi: replace use of system_wq with system_percpu_wq
drm/fb-helper: Fix vblank timeout during suspend/reset
PCI/VGA: Don't assume the only VGA device on a system is `boot_vga`
drm/amdgpu: Fix query for VPE block_type and ip_count
drm/amd/display: Add missing encoder setup to DACnEncoderControl
drm/amd/display: Correct color depth for SelectCRTC_Source
drm/amd/amdgpu: Fix SMU warning during isp suspend-resume
drm/amdgpu: always backup and reemit fences
drm/amdgpu: don't reemit ring contents more than once
drm/amd/pm: force send pcie parmater on navi1x
drm/amd/pm: fix wrong pcie parameter on navi1x
drm/radeon: Remove __counted_by from ClockInfoArray.clockInfo[]
drm/amd/display: Reduce number of arguments of dcn30's CalculateWatermarksAndDRAMSpeedChangeSupport()
drm/amd/display: Reduce number of arguments of dcn30's CalculatePrefetchSchedule()
drm/amd/display: Apply e4479aecf658 to dml
nouveau: don't attempt fwsec on sb on newer platforms
drm/tidss: Fix enable/disable order
...
|
|
gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
- Remove incorrect __user annotation from struct xattr_args::value
- Documentation fix: Add missing kernel-doc description for the @isnew
parameter in ilookup5_nowait() to silence Sphinx warnings
- Documentation fix: Fix kernel-doc comment for __start_dirop() - the
function name in the comment was wrong and the @state parameter was
undocumented
- Replace dynamic folio_batch allocation with stack allocation in
iomap_zero_range(). The dynamic allocation was problematic for
ext4-on-iomap work (didn't handle allocation failure properly) and
triggered lockdep complaints. Uses a flag instead to control batch
usage
- Re-add #ifdef guards around PIDFD_GET_<ns-type>_NAMESPACE ioctls.
When a namespace type is disabled, ns->ops is NULL, causes crashes
during inode eviction when closing the fd. The ifdefs were removed in
a recent simplification but are still needed
- Fixe a race where a folio could be unlocked before the trailing zeros
(for EOF within the page) were written
- Split out a dedicated lease_dispose_list() helper since lease code
paths always know they're disposing of leases. Removes unnecessary
runtime flag checks and prepares for upcoming lease_manager
enhancements
- Fix userland delegation requests succeeding despite conflicting
opens. Previously, FL_LAYOUT and FL_DELEG leases bypassed conflict
checks (a hack for nfsd). Adds new ->lm_open_conflict() lease_manager
operation so userland delegations get proper conflict checking while
nfsd can continue its own conflict handling
- Fix LOOKUP_CACHED path lookups incorrectly falling through to the
slow path. After legitimize_links() calls were conditionally elided,
the routine would always fail with LOOKUP_CACHED regardless of
whether there were any links. Now the flag is checked at the two
callsites before calling legitimize_links()
- Fix bug in media fd allocation in media_request_alloc()
- Fix mismatched API calls in ecryptfs_mknod(): was calling
end_removing() instead of end_creating() after
ecryptfs_start_creating_dentry()
- Fix dentry reference count leak in ecryptfs_mkdir(): a dget() of the
lower parent dir was added but never dput()'d, causing BUG during
lower filesystem unmount due to the still-in-use dentry
* tag 'vfs-6.19-rc5.fixes' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs:
pidfs: protect PIDFD_GET_* ioctls() via ifdef
ecryptfs: Release lower parent dentry after creating dir
ecryptfs: Fix improper mknod pairing of start_creating()/end_removing()
get rid of bogus __user in struct xattr_args::value
VFS: fix __start_dirop() kernel-doc warnings
fs: Describe @isnew parameter in ilookup5_nowait()
fs: make sure to fail try_to_unlazy() and try_to_unlazy() for LOOKUP_CACHED
netfs: Fix early read unlock of page with EOF in middle
filelock: allow lease_managers to dictate what qualifies as a conflict
filelock: add lease_dispose_list() helper
iomap: replace folio_batch allocation with stack allocation
media: mc: fix potential use-after-free in media_request_alloc()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fix from Herbert Xu:
- Fix duplicate restart messages in qat
* tag 'v6.19-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: qat - fix duplicate restarting msg during AER error
|
|
freq_to_idx() is used to map a channel to a survey index. Commit
acc152f9be20 ("wifi: ath12k: combine channel list for split-phy devices in
single-wiphy") adds radio specific frequency range check in this helper to
make sure an invalid index is returned if the channel falls outside that
range. However, this check introduces a race, resulting in below warnings
as reported in [1].
ath12k_pci 0000:08:00.0: chan info: invalid frequency 6455 (idx 101 out of bounds)
ath12k_pci 0000:08:00.0: chan info: invalid frequency 6535 (idx 101 out of bounds)
ath12k_pci 0000:08:00.0: chan info: invalid frequency 6615 (idx 101 out of bounds)
ath12k_pci 0000:08:00.0: chan info: invalid frequency 6695 (idx 101 out of bounds)
ath12k_pci 0000:08:00.0: chan info: invalid frequency 6775 (idx 101 out of bounds)
ath12k_pci 0000:08:00.0: chan info: invalid frequency 6855 (idx 101 out of bounds)
ath12k_pci 0000:08:00.0: chan info: invalid frequency 6935 (idx 101 out of bounds)
ath12k_pci 0000:08:00.0: chan info: invalid frequency 7015 (idx 101 out of bounds)
ath12k_pci 0000:08:00.0: chan info: invalid frequency 7095 (idx 101 out of bounds)
ath12k_pci 0000:08:00.0: chan info: invalid frequency 6435 (idx 101 out of bounds)
Race scenario:
1) A regdomain covering below frequency range is uploaded to host via
WMI_REG_CHAN_LIST_CC_EXT_EVENTID event:
Country 00, CFG Regdomain UNSET FW Regdomain 0, num_reg_rules 6
1. (2402 - 2472 @ 40) (0, 20) (0 ms) (FLAGS 360448) (0, 0)
2. (2457 - 2477 @ 20) (0, 20) (0 ms) (FLAGS 360576) (0, 0)
3. (5170 - 5330 @ 160) (0, 20) (0 ms) (FLAGS 264320) (0, 0)
4. (5490 - 5730 @ 160) (0, 20) (0 ms) (FLAGS 264320) (0, 0)
5. (5735 - 5895 @ 160) (0, 20) (0 ms) (FLAGS 264320) (0, 0)
6. (5925 - 7125 @ 320) (0, 24) (0 ms) (FLAGS 2056) (0, 255)
As a result, radio frequency range is updated as [2402, 7125]
ath12k_pci 0000:08:00.0: mac pdev 0 freq limit updated. New range 2402->7125 MHz
If no scan in progress or after scan finished, command
WMI_SCAN_CHAN_LIST_CMDID is sent to firmware notifying that firmware
is allowed to do scan on all channels within that range.
The running path is:
/* redomain uploaded */
1. WMI_REG_CHAN_LIST_CC_EXT_EVENTID
2. ath12k_reg_chan_list_event()
3. ath12k_reg_handle_chan_list()
4. queue_work(..., &ar->regd_update_work)
5. ath12k_regd_update_work()
6. ath12k_regd_update()
/* update radio frequency range */
7. ath12k_mac_update_freq_range()
8. regulatory_set_wiphy_regd()
9. ath12k_reg_notifier()
10. ath12k_reg_update_chan_list()
11. queue_work(..., &ar->regd_channel_update_work)
12. ath12k_regd_update_chan_list_work()
/* wait scan finishes */
13. wait_for_completion_timeout(&ar->scan.completed, ...)
/* command notifying list of valid channels */
14. ath12k_wmi_send_scan_chan_list_cmd()
2) Hardware scan is triggered on all allowed channels.
3) Before scan completed, 11D mechanism detects a new country code
ath12k_pci 0000:08:00.0: wmi 11d new cc GB
With this code sent to firmware, firmware uploads a new regdomain
Country GB, CFG Regdomain ETSI FW Regdomain 2, num_reg_rules 9
1. (2402 - 2482 @ 40) (0, 20) (0 ms) (FLAGS 360448) (0, 0)
2. (5170 - 5250 @ 80) (0, 23) (0 ms) (FLAGS 264192) (0, 0)
3. (5250 - 5330 @ 80) (0, 23) (0 ms) (FLAGS 264216) (0, 0)
4. (5490 - 5590 @ 80) (0, 30) (0 ms) (FLAGS 264208)
5. (5590 - 5650 @ 40) (0, 30) (600000 ms) (FLAGS 264208)
6. (5650 - 5730 @ 80) (0, 30) (0 ms) (FLAGS 264208)
7. (5735 - 5875 @ 80) (0, 14) (0 ms) (FLAGS 264192) (0, 0)
8. (5855 - 5875 @ 20) (0, 14) (0 ms) (FLAGS 264192) (0, 0)
9. (5945 - 6425 @ 320) (0, 24) (0 ms) (FLAGS 2056) (0, 11)
Then radio frequency range is updated as [2402, 6425]
ath12k_pci 0000:08:00.0: mac pdev 0 freq limit updated. New range 2402->6425 MHz
Please note this is a smaller range than the previous one. Later host
runs the same path for the purpose of notifying the new channel list.
However since scan not completed, host just waits there. Meanwhile,
firmware is possibly scanning channels outside the new range. As a
result, WMI_CHAN_INFO_EVENTID events for those channels fail
freq_to_idx() check and triggers warnings above.
Fix this issue by removing radio frequency check in freq_to_idx(). This is
valid because channels being scanned do not synchronize with frequency
range update. Besides, this won't cause any problem, since freq_to_idx()
is only used for survey data. Even out-of-range channels filled in the
survey, they won't get delivered to userspace due to the range check
already there in ath12k_mac_op_get_survey().
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: acc152f9be20 ("wifi: ath12k: combine channel list for split-phy devices in single-wiphy")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220871 # 1
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260108-ath12k-fix-freq-to-idx-v1-1-b2458cf7aa0d@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
dma_alloc_coherent() allocates a DMA mapped buffer and stores the
addresses in XXX_unaligned fields. Those should be reused when freeing
the buffer rather than the aligned addresses.
Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260106084905.18622-2-fourier.thomas@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
dma_alloc_coherent() allocates a DMA mapped buffer and stores the
addresses in XXX_unaligned fields. Those should be reused when freeing
the buffer rather than the aligned addresses.
Fixes: 2a1e1ad3fd37 ("ath10k: Add support for 64 bit ce descriptor")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260105210439.20131-2-fourier.thomas@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
The __alloc_percpu() fails when the number of IDs are greater than 959
because size parameter of __alloc_percpu() must be less than 32768 (aka
PCPU_MIN_UNIT_SIZE). This failure is observed with KVMTOOL when AIA is
trap-n-emulated by in-kernel KVM because in this case KVM guest has 2047
interrupt IDs.
To address this issue, don't embed vector array in struct imsic_local_priv
until __alloc_percpu() support size parameter greater than 32768.
This reverts commit 79eaabc61dfb ("irqchip/riscv-imsic: Embed the vector
array in lpriv").
Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20251223143544.1504217-1-anup.patel@oss.qualcomm.com
|
|
Kbuild bot (through sparse) reported that the ITTE read to carry out
a valid check in gicv5_its_map_event() lacks proper endianness handling.
Add the missing endianess conversion.
Fixes: 57d72196dfc8 ("irqchip/gic-v5: Add GICv5 ITS support")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20251222102250.435460-1-lpieralisi@kernel.org
Closes: https://lore.kernel.org/oe-kbuild-all/202512131849.30ZRTBeR-lkp@intel.com/
|
|
nvme_fabrics creates an NVMe/FC controller in following path:
nvmf_dev_write()
-> nvmf_create_ctrl()
-> nvme_fc_create_ctrl()
-> nvme_fc_init_ctrl()
nvme_fc_init_ctrl() allocates the admin blk-mq resources right after
nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing
the controller state, scheduling connect work, etc.), we jump to the
fail_ctrl path, which tears down the controller references but never
frees the admin queue/tag set. The leaked blk-mq allocations match the
kmemleak report seen during blktests nvme/fc.
Check ctrl->ctrl.admin_tagset in the fail_ctrl path and call
nvme_remove_admin_tag_set() when it is set so that all admin queue
allocations are reclaimed whenever controller setup aborts.
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Reviewed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Chaitanya Kulkarni <ckulkarnilinux@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,nvme-ans2" anymore [1]. Add
"apple,t8103-nvme-ans2" as fallback compatible as it is the SoC the
driver and bindings were written for.
[1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/
Cc: stable@vger.kernel.org # v6.18+
Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver")
Reviewed-by: Neal Gompa <neal@gompa.dev>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")
added ttag bounds checking and data_offset
validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate
whether the command's data structures (cmd->req.sg and cmd->iov) have
been properly initialized before processing H2C_DATA PDUs.
The nvmet_tcp_build_pdu_iovec() function dereferences these pointers
without NULL checks. This can be triggered by sending H2C_DATA PDU
immediately after the ICREQ/ICRESP handshake, before
sending a CONNECT command or NVMe write command.
Attack vectors that trigger NULL pointer dereferences:
1. H2C_DATA PDU sent before CONNECT → both pointers NULL
2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL
3. H2C_DATA PDU for uninitialized command slot → both pointers NULL
The fix validates both cmd->req.sg and cmd->iov before calling
nvmet_tcp_build_pdu_iovec(). Both checks are required because:
- Uninitialized commands: both NULL
- READ commands: cmd->req.sg allocated, cmd->iov NULL
- WRITE commands: both allocated
Fixes: efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length")
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Shivam Kumar <kumar.shivam43666@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Improve header check: Remove unused -DHDRTEST. Include the header twice
to check for include guards. Run kernel-doc on the header.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260107155401.2379127-5-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Fix kernel-doc warnings on xe_vm_validation_exec():
Warning: ../drivers/gpu/drm/xe/xe_vm.h:392 expecting prototype for
xe_vm_set_validation_exec(). Prototype was for xe_vm_validation_exec()
instead
Fixes: 0131514f9789 ("drm/xe: Pass down drm_exec context to validation")
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260107155401.2379127-4-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Fix kernel-doc warnings on enum xe_late_bind_fw_id:
Warning: ../drivers/gpu/drm/xe/xe_late_bind_fw_types.h:19 cannot
understand function prototype: 'enum xe_late_bind_fw_id'
Fixes: 45832bf9c10f ("drm/xe/xe_late_bind_fw: Initialize late binding firmware")
Cc: Badal Nilawar <badal.nilawar@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patch.msgid.link/20260107155401.2379127-3-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Fix kernel-doc warnings on struct xe_gt_sriov_vf_migration:
Warning: ../drivers/gpu/drm/xe/xe_gt_sriov_vf_types.h:47 cannot
understand function prototype: 'struct xe_gt_sriov_vf_migration'
Fixes: e1d2e2d878bf ("drm/xe/vf: Add xe_gt_recovery_pending helper")
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260107155401.2379127-2-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Fix kernel-doc warnings on struct guc_lfd_file_header:
Warning: ../drivers/gpu/drm/xe/abi/guc_lfd_abi.h:168 expecting prototype
for struct guc_logfile_header. Prototype was for struct
guc_lfd_file_header instead
Fixes: 7eeb0e5408bd ("drm/xe/guc: Add LFD related abi definitions")
Cc: Zhanjun Dong <zhanjun.dong@intel.com>
Cc: Julia Filipchuk <julia.filipchuk@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Zhanjun Dong <zhanjun.dong@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260107155401.2379127-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
On Xe3_LPD, there is no instruction to program the CD2X divider anymore
and the hardware is expected to always use the default value of 0b00,
meaning "divide by 1".
With that, the CDCLK_CTL register was changed so that:
(1) The field "CD2X Divider Select" became a debug-only field.
Because we are programming CDCLK_CTL with a direct write instead
of read-modify-write operation, we still need to program "CD2X
Divider Select" in order to keep the field from deviating from its
default value. Let's, however, throw a warning if we encounter a
CDCLK value that would result in an unexpected value for that
field.
(2) The field "CD2X Pipe Select" has been removed. In fact, some
debugging in a PTL machine showed that such field comes back as
zero after writing a non-zero value to it. As such, do not
program it starting with Xe3_LPD.
v2:
- Add missing "val |= " when calling bxt_cdclk_cd2x_pipe().
(Dnyaneshwar)
Bspec: 68864, 69090
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patch.msgid.link/20260106-xe3_lpd-no-cd2x-divider-v2-1-06e5cbc9dabb@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
A race condition exists between the async partition scan work and device
teardown that can lead to a use-after-free of ub->ub_disk:
1. ublk_ctrl_start_dev() schedules partition_scan_work after add_disk()
2. ublk_stop_dev() calls ublk_stop_dev_unlocked() which does:
- del_gendisk(ub->ub_disk)
- ublk_detach_disk() sets ub->ub_disk = NULL
- put_disk() which may free the disk
3. The worker ublk_partition_scan_work() then dereferences ub->ub_disk
leading to UAF
Fix this by using ublk_get_disk()/ublk_put_disk() in the worker to hold
a reference to the disk during the partition scan. The spinlock in
ublk_get_disk() synchronizes with ublk_detach_disk() ensuring the worker
either gets a valid reference or sees NULL and exits early.
Also change flush_work() to cancel_work_sync() to avoid running the
partition scan work unnecessarily when the disk is already detached.
Fixes: 7fc4da6a304b ("ublk: scan partition in async way")
Reported-by: Ruikai Peng <ruikai@pwno.io>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Since commit 98e48cd9283d ("regulator: core: resolve supply for
boot-on/always-on regulators"), the regulator core returns
-EPROBE_DEFER if a supply can not be resolved at regulator_register()
time due to set_machine_constraints() requiring that supply (e.g.
because of always-on or boot-on).
In some hardware designs, multiple PMICs are used where individual
rails of each act as supplies for rails of the other, and vice-versa.
In such a design no PMIC driver can probe when registering one top-
level regulator device (as is common practice for almost all regulator
drivers in Linux) since that commit. Supplies are only considered when
their driver has fully bound, but because in a design like the above
two drivers / devices depend on each other, neither will have fully
bound while the other probes. The Google Pixel 6 and 6 Pro (oriole and
raven) are examples of such a design.
One way to make this work would be to register each rail as an
individual device, rather than just one top-level regulator device.
Then, fw-devlink and Linux' driver core could do their usual handling
of deferred device probe as each rail would be probed individually.
This approach was dismissed in [1] as each regulator driver would have
to take care of this itself.
Alternatively, we can change the regulator core to not fail
regulator_register() if a rail's required supply can not be resolved
while keeping the intended change from above mentioned commit, and
instead retry whenever a new rail is registered. This commit implements
such an approach:
If set_machine_constraints() requests probe deferral,
regulator_register() still succeeds and we retry setting
constraints as part of regulator_resolve_supply().
We still do not enable the regulator or allow consumers to use it
until constraints have been set (including resolution of the
supply) to prevent enabling of a regulator before its supply.
With this change, we keep track of regulators with missing required
supplies and can therefore try to resolve them again and try to set
the constraints again once more regulators become available.
Care has to be taken to not allow consumers to use regulators that
haven't had their constraints set yet. regulator_get() ensures that
and now returns -EPROBE_DEFER in that case.
The implementation is straight-forward, thanks to our newly introduced
regulator-bus. Locking in regulator_resolve_supply() has to be done
carefully, as a combination of regulator_(un)lock_two() and
regulator_(un)lock_dependent() is needed. The reason is that
set_machine_constraints() might call regulator_enable() which needs
rdev and all its dependents locked, but everything else requires to
only have rdev and its supply locked.
Link: https://lore.kernel.org/all/aRn_-o-vie_QoDXD@sirena.co.uk/ [1]
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-8-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When a regulator A and its supply B are provided by different devices,
the driver implementing B might be last to probe (with A still
pending resolution of its supply B). While we try to resolve all
pending supplies for all regulators (including A) during
regulator_register() of B via regulator_register_resolve_supply(),
supply resolution will still not work for A as the driver for B hasn't
finished binding to the PMIC device corresponding to B at that stage
yet. The regulator core explicitly only allows supplies from other
devices to be used once the relevant driver has fully bound, mainly to
avoid having to deal with cases where B itself might -EPROBE_DEFER.
In this case, A's supply will only be resolved as part of the core's
regulator_init_complete_work_function(), which currently is scheduled
to run after 30s. This was added as a work-around in
commit 3827b64dba27 ("regulator: core: Resolve supplies before
disabling unused regulators") to cover this situation.
There are two problems with that approach:
* it potentially runs long after all our consumers have probed
* an upcoming change will allow regulator_register() to complete
successfully even when required supplies (e.g. due to always-on or
boot-on) are missing at register time, deferring full configuration
of the regulator (and usability by consumers, i.e. usually consumer
probe) until the supply becomes available.
Resolving supplies in the late work func can therefore make it
impossible for consumers to probe at all, as the driver core will not
know to reprobe consumers when supplies have resolved.
We could schedule an earlier work to try to resolve supplies sooner,
but that'd be racy as consumers of A might try to probe before A's
supply gets fully resolved via this extra work.
Instead, add a very simple regulator bus and add a dummy device with a
corresponding driver to it for each regulator that is missing its
supply during regulator_register(). This way, the driver core will call
our bus' probe whenever a new (regulator) device was successfully
bound, allowing us to retry resolving the supply during (our bus) probe
and to bind this dummy device if successful. In turn this means the
driver core will see a newly bound device and retry probing of all
pending consumers, if any.
With that in place, we can avoid walking the full list of all known
regulators to try resolve missing supplies during regulator_register(),
as the driver core will invoke the bus probe for regulators that are
still pending their supplies. We can also drop the code trying to
resolve supplies one last time before unused regulators get disabled,
as all supplies should have resolved at that point in time, and if they
haven't then there's no point in trying again, as the outcome won't
change.
Note: We can not reuse the existing struct device created for each
rail, as a device can not be part of a class and a bus simultaneously.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-7-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Receiving and forwarding critical supply events seems like they're
important information and we shouldn't ignore errors occurring during
registration for such events.
With this change the supply is unset on event registration failure,
allowing us to potentially retry another time.
Fixes: 433e294c3c5b ("regulator: core: forward undervoltage events downstream by default")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-6-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Since commit 98e48cd9283d ("regulator: core: resolve supply for
boot-on/always-on regulators") we require that a regulator's supply has
been resolved before enabling the regulator. Furthermore,
regulator_get() also fails if the supply hasn't been resolved yet
(preventing consumers from enabling a regulator without its supply
known). In combination this means that regulator_resolve_supply() now
always runs before the regulator has been enabled via
set_machine_constraints().
The code here was meant to run after enabling the regulator in case the
supply hadn't been resolved at that time and can therefore never
execute anymore since that commit.
Remove it.
No functional change intended.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-5-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For always-on and boot-on regulators, regulator_register() is currently
trying to anticipate the requirement to resolve a supply early.
Unfortunately, this code executes too early, before we have potentially
updated the regulator's always_on constraint as part of
set_machine_constraints(), causing it to miss cases.
Rather than trying to hack it more, just defer to the outcome of
set_machine_constraints(). The latter returns early (without doing any
regulator initialisation) with -EPROBE_DEFER as of commit 'regulator:
core: move supply check earlier in set_machine_constraints()' and is
therefore safe to call multiple times to determine if supplies need to
be resolved early.
Commit 8a866d527ac0 ("regulator: core: Resolve supply name earlier to
prevent double-init") (later updated by
commit 520fb178212d ("regulator: core: Fix regulator supply
registration with sysfs")) added these tests originally to avoid
calling set_machine_constraints() multiple times to try to avoid
voltage glitches due to all the regulator initialisation happening each
time. This isn't an issue anymore as per above.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-4-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Since commit 98e48cd9283d ("regulator: core: resolve supply for
boot-on/always-on regulators"), set_machine_constraints() can return
-EPROBE_DEFER very late, after it has done a lot of work and
configuration of the regulator.
This means that configuration will happen multiple times for no
benefit in that case. Furthermore, this can lead to timing-dependent
voltage glitches as mentioned e.g. in commit 8a866d527ac0 ("regulator:
core: Resolve supply name earlier to prevent double-init").
We can know that it's going to fail very early, in particular before
going through the complete regulator configuration by moving some code
around a little.
Do so to avoid re-configuring the regulator multiple times, also
avoiding the voltage glitches if we can.
Fixes: 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-3-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
If late enabling of a supply regulator fails in
regulator_resolve_supply(), the code currently triggers a lockdep
warning:
WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596
...
Call trace:
_regulator_put+0x80/0xa0 (P)
regulator_resolve_supply+0x7cc/0xbe0
regulator_register_resolve_supply+0x28/0xb8
as the regulator_list_mutex must be held when calling _regulator_put().
To solve this, simply switch to using regulator_put().
While at it, we should also make sure that no concurrent access happens
to our rdev while we clear out the supply pointer. Add appropriate
locking to ensure that.
While the code in question will be removed altogether in a follow-up
commit, I believe it is still beneficial to have this corrected before
removal for future reference.
Fixes: 36a1f1b6ddc6 ("regulator: core: Fix memory leak in regulator_resolve_supply()")
Fixes: 8e5356a73604 ("regulator: core: Clear the supply pointer if enabling fails")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-2-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
1)
In print_constraints_debug(), the power budget is printed as:
lldo2: 450 <--> 1300 mV at 900 mV 2147483647 mW budge, enabled
(note the missing t in budget). This is because there is a --count just
below the call to scnprintf(), to make space for the comma. All similar
calls to scnprintf() above add an extra space to the format string to
allow for that, but this one doesn't, so the last character t is
stripped instead. Update the format string to fix the message.
2)
Add the name of the supply to the failure message printed when the
supply can not be resolved when debug messages are enabled to help with
debug.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-1-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Discovering a phandle to an AST2400 or AST2600 LPC node indicates an
error for the purpose of the AST2500 pinctrl driver.
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
The Secondary Sample Point Source field has been
set to an incorrect value by some mistake in the
past
0b01 - SSP_SRC_NO_SSP - SSP is not used.
for data bitrates above 1 MBit/s. The correct/default
value already used for lower bitrates is
0b00 - SSP_SRC_MEAS_N_OFFSET - SSP position = TRV_DELAY
(Measured Transmitter delay) + SSP_OFFSET.
The related configuration register structure is described
in section 3.1.46 SSP_CFG of the CTU CAN FD
IP CORE Datasheet.
The analysis leading to the proper configuration
is described in section 2.8.3 Secondary sampling point
of the datasheet.
The change has been tested on AMD/Xilinx Zynq
with the next CTU CN FD IP core versions:
- 2.6 aka master in the "integration with Zynq-7000 system" test
6.12.43-rt12+ #1 SMP PREEMPT_RT kernel with CTU CAN FD git
driver (change already included in the driver repo)
- older 2.5 snapshot with mainline kernels with this patch
applied locally in the multiple CAN latency tester nightly runs
6.18.0-rc4-rt3-dut #1 SMP PREEMPT_RT
6.19.0-rc3-dut
The logs, the datasheet and sources are available at
https://canbus.pages.fel.cvut.cz/
Signed-off-by: Ondrej Ille <ondrej.ille@gmail.com>
Signed-off-by: Pavel Pisa <pisa@fel.cvut.cz>
Link: https://patch.msgid.link/20260105111620.16580-1-pisa@fel.cvut.cz
Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.")
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
The Axiado SPI controller is present in AX3000 SoC and Evaluation Board.
This controller is operating in Host only mode.
Co-developed-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Vladimir Moravcevic <vmoravcevic@axiado.com>
Link: https://patch.msgid.link/20260107-axiado-ax3000-soc-spi-db-controller-driver-v3-2-726e70cf19ad@axiado.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
drm_gem_object_lookup_at_offset() can return a valid object with
filp or filp->f_op->get_unmapped_area set to NULL. Make sure we still
release the ref we acquired on such objects.
Cc: Loïc Molinari <loic.molinari@collabora.com>
Fixes: 99bda20d6d4c ("drm/gem: Introduce drm_gem_get_unmapped_area() fop")
Reviewed-by: Loïc Molinari <loic.molinari@collabora.com>
Link: https://patch.msgid.link/20260106164935.409765-1-boris.brezillon@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
|
|
Convert uses of AtomicBool, AtomicUsize, and AtomicU32.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Acked-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20251230093718.1852322-4-fujita.tomonori@gmail.com
|
|
Setting up an IRQ would normally be done in the .activate() and
.deactivate() ops of the IRQ domain, but for hierarchical IRQ domains
the .activate() and .deactivate() ops are overridden in the
gpiochip_hierarchy_setup_domain_ops() function.
As such, activating and deactivating need to be done in the .translate()
and .free() ops of the IRQ domain.
For RZ/T2H and RZ/N2H, interrupts go through the pin controller, into
the ICU, which level-translates them and forwards them to the GIC.
To use a GPIO as an interrupt it needs to be put into peripheral
function mode 0, which will connect it to the IRQ lines of the ICU.
The IRQ chip .child_to_parent_hwirq() callback is called as part of the
IRQ fwspec parsing logic (as part of irq_create_of_mapping()) which
happens before the IRQ is requested (as part of gpiochip_lock_as_irq()).
gpiochip_lock_as_irq() calls gpiod_get_direction() if the
.get_direction() callback is provided to ensure that the GPIO line is
set up as input.
In our case, IRQ function is separate from GPIO, and both cannot be true
at the same time.
Return GPIO_LINE_DIRECTION_IN even if pin is in IRQ function to allow
this setup to work.
Hold the spinlock to ensure atomicity between reading the PMC register
(which determines whether the pin is in GPIO mode or not) and reading
the function of the pin when it is not in GPIO mode.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251205150234.2958140-3-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
GPIO is enabled or disabled in multiple places, simplify code by moving
this logic into a separate function.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251205150234.2958140-2-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
On the RK3506 platform, there is no iommu hardware. And even on
platform that have iommu hardware, it should be possible to use
VOP without enabling iommu. In this case, a contiguous memory
space like CMA should be used.
So this patch removes the dependency on ROCKCHIP_IOMMU
with an 'optional-dependency'.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
[added reference to optional-dependies description]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251106020632.92-9-kernel@airkyi.com
|
|
If the assert() fails due to timeout error, set the reset register bit
back to deasserted state. This change is needed especially for handling
assert error in suspend() callback that expect the device to be in
operational state in case of failure.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260108123433.104464-3-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
If the assert() fails due to timeout error, set the reset register bit
back to deasserted state. This change is needed especially for handling
assert error in suspend() callback that expect the device to be in
operational state in case of failure.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260108123433.104464-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Move spin_unlock_irqrestore() before verifying the reset result and
printing errors. The verification condition only uses local variables
and does not require locking.
Reported-by: Pavel Machek <pavel@nabladev.com>
Closes: https://lore.kernel.org/all/aVujAQJSDn6WyORK@duo.ucw.cz/
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260105140625.2590685-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add clock and reset entries for the CANFD IP.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224165049.3384870-5-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add clock and reset entries for the CANFD IP.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224165049.3384870-4-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs have a CANFD
peripheral which has three input clocks PCLKM (peripheral clock),
PCLKH (RAM clock) and PCLKCAN (CANFD clock).
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224165049.3384870-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The register layout for RZ/T2H is not handled inside
cpg_mssr_suspend_noirq() and cpg_mssr_resume_noirq(), causing a memory
abort because the wrong code path is taken, as shown below.
Explicitly handle the RZ/T2H register layout in cpg_mssr_suspend_noirq()
and cpg_mssr_resume_noirq(), similar to how it is done inside
cpg_mstp_clock_is_enabled() and cpg_mstp_clock_endisable().
[ 90.052296] Mem abort info:
[ 90.055420] ESR = 0x0000000096000007
[ 90.059553] EC = 0x25: DABT (current EL), IL = 32 bits
[ 90.065697] SET = 0, FnV = 0
[ 90.069211] EA = 0, S1PTW = 0
[ 90.072834] FSC = 0x07: level 3 translation fault
[ 90.078109] Data abort info:
[ 90.081405] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
[ 90.087427] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 90.093169] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 90.099008] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000c60b4000
[ 90.106756] [ffff800082816318] pgd=0000000000000000, p4d=10000000c69ef003, pud=10000000c69f0003, pmd=100000024002b403, pte=0000000000000000
[ 90.120727] Internal error: Oops: 0000000096000007 [#1] SMP
[ 90.127058] Modules linked in: sha256 cfg80211 spi_nor at24 renesas_usbhs bluetooth ecdh_generic ecc rfkill rzt2h_adc spi_rzv2h_rspi industrialio_adc gpio_keys fuse drm backlight ipv6
[ 90.145201] CPU: 0 UID: 0 PID: 307 Comm: sh Not tainted 6.18.0-rc1-next-20251016+ #47 PREEMPT
[ 90.155006] Hardware name: Renesas RZ/T2H EVK Board based on r9a09g077m44 (DT)
[ 90.163041] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 90.170777] pc : cpg_mssr_suspend_noirq+0x4c/0xc0
[ 90.175983] lr : device_suspend_noirq+0x6c/0x22c
[ 90.181309] sp : ffff8000838d3af0
[ 90.185026] x29: ffff8000838d3af0 x28: ffff8000825c016f x27: ffff8000825c01a0
[ 90.192973] x26: ffff8000809feeec x25: ffff8000827bebb8 x24: 0000000000000002
[ 90.200815] x23: ffff8000825c0190 x22: 0000000000000002 x21: 0000000000000000
[ 90.209058] x20: ffff8000827bebb8 x19: ffff000180128010 x18: ffff00033ef92a80
[ 90.217100] x17: ffff000180051700 x16: 0000000000000001 x15: ffff000187afc310
[ 90.224847] x14: 0000000000000254 x13: 0000000000000001 x12: 0000000000000001
[ 90.232793] x11: 00000000000000c0 x10: 0000000000000ab0 x9 : ffff8000838d38b0
[ 90.240540] x8 : ffff000186387410 x7 : 0000000000000001 x6 : 0000000000000000
[ 90.248600] x5 : ffff0001803240d4 x4 : 0000000000000003 x3 : ffff0001803240d0
[ 90.256460] x2 : ffff800082816318 x1 : 000000000000000c x0 : ffff000180324000
[ 90.264208] Call trace:
[ 90.267019] cpg_mssr_suspend_noirq+0x4c/0xc0 (P)
[ 90.272450] device_suspend_noirq+0x6c/0x22c
[ 90.277375] dpm_noirq_suspend_devices+0x1a8/0x2a0
[ 90.282902] dpm_suspend_noirq+0x24/0xa0
[ 90.287428] suspend_devices_and_enter+0x310/0x590
[ 90.292790] pm_suspend+0x1b4/0x200
[ 90.296811] state_store+0x80/0xf4
[ 90.300676] kobj_attr_store+0x18/0x34
[ 90.305002] sysfs_kf_write+0x7c/0x94
[ 90.309232] kernfs_fop_write_iter+0x12c/0x200
[ 90.314115] vfs_write+0x240/0x380
[ 90.318041] ksys_write+0x64/0x100
[ 90.321862] __arm64_sys_write+0x18/0x24
[ 90.326013] invoke_syscall.constprop.0+0x40/0xf0
[ 90.331445] el0_svc_common.constprop.0+0xb8/0xd8
[ 90.336554] do_el0_svc+0x1c/0x28
[ 90.340375] el0_svc+0x34/0xe8
[ 90.343900] el0t_64_sync_handler+0xa0/0xe4
[ 90.348426] el0t_64_sync+0x198/0x19c
[ 90.352609] Code: 8b040042 b9409004 7100049f 54000240 (b9400042)
[ 90.359639] ---[ end trace 0000000000000000 ]---
Fixes: 065fe720eec6 ("clk: renesas: Add support for R9A09G077 SoC")
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251127145654.3253992-3-cosmin-gabriel.tanislav.xa@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The GPIO controller is configured as non-sleeping but it uses generic
pinctrl helpers which use a mutex for synchronization. This will cause
lockdep splats when used together with shared GPIOs going through the
GPIO shared proxy driver.
Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs")
Cc: stable@vger.kernel.org
Reported-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Closes: https://lore.kernel.org/all/CAFBinCAc7CO8gfNQakCu3LfkYXuyTd2iRpMRm8EKXSL0mwOnJw@mail.gmail.com/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
In gs_can_open(), the URBs for USB-in transfers are allocated, added to the
parent->rx_submitted anchor and submitted. In the complete callback
gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In
gs_can_close() the URBs are freed by calling
usb_kill_anchored_urbs(parent->rx_submitted).
However, this does not take into account that the USB framework unanchors
the URB before the complete function is called. This means that once an
in-URB has been completed, it is no longer anchored and is ultimately not
released in gs_can_close().
Fix the memory leak by anchoring the URB in the
gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.
Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260105-gs_usb-fix-memory-leak-v2-1-cc6ed6438034@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
We currently only build these drivers on ARM but there's nothing that
should stop us from building it with allmodconfig on other
architectures. Extend the build coverage for all meson drivers.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
