Correct the regulator providing power to the PWM controlled fan.
Without this fix the fan only runs when the audio path is playing
audio (because the speaker amplifier and PWM fan share the same
regulator).
Fixes: 4e946c447a ("arm64: dts: rockchip: Add GameForce Ace")
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260310134648.550006-1-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This reverts commit bdc4d388c6.
While Beelink A1 mostly follows the high-end RK3328 reference design,
it does not in fact have the S/PDIF connector, only HDMI and a 3.5mm
jack for the analog audio/TV codecs - the tiny form factor literally
doesn't have room to fit more!
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Alex Bee <knaerzche@gmail.com>
Fixes: bdc4d388c6 ("arm64: dts: rockchip: add SPDIF audio to Beelink A1")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://patch.msgid.link/0af77a02c2b0806d4ca72066392a5453fcc89a8f.1767111968.git.robin.murphy@arm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The AP6212 WiFi/BT module on the LCKFB TaiShan Pi (RK3566) is prone to
communication timeouts and reset failures (error -110) when operating at
3 Mbps.
This patch stabilizes the Bluetooth interface by:
1. Updating the compatible string to 'brcm,bcm43430a1-bt' to better reflect
the actual chip revision used in the AP6212 module.
2. Lowering the maximum UART baud rate from 3,000,000 to 1,500,000 bps.
Tests show that 1.5 Mbps is the reliable upper limit for this board's
UART configuration, eliminating the initialization timeouts.
Fixes: 251e5ade9b ("arm64: dts: rockchip: add dts for LCKFB Taishan Pi RK3566")
Signed-off-by: Ming Wang <wangming5719@gmail.com>
Link: https://patch.msgid.link/20260206090453.1041919-1-wming126@126.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to nxp,pca953x.yaml, the pattern for the led names should be:
"^led-[0-9a-z]+$".
Change it accordingly to fix the following dt-schema warning"
leddimmer@62 (nxp,pca9533): 'led1', 'led2', 'led3', 'led4' do not match any
of the regexes: '^led-[0-9a-z]+$', '^pinctrl-[0-9]+$'
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
Link: https://patch.msgid.link/20260311135604.21634-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to rockchip-dwmac.yaml, the mdio node should be 'mdio0' and
'wakeup-source' is not a valid property.
Change it accordingly.
This fixes the following dt-schema warning:
Unevaluated properties are not allowed ('mdio0', 'wakeup-source'\
were unexpected)
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260303193855.828892-3-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Node names should be generic, so use 'rtc'.
Remove 'clock-frequency' as is not a valid property.
This fixes the following dt-schema warnings:
'hym8563@51' does not match '^rtc(@.*|-([0-9]|[1-9][0-9]+))?$'
Unevaluated properties are not allowed ('clock-frequency' was unexpected)
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260303193855.828892-2-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to hid-over-i2c.yaml, the correct name for the 3.3V supply
is 'vdd-supply'.
Fix it accordingly.
This fixes the following dt-schema warning:
'vcc-supply' does not match any of the regexes: '^pinctrl-[0-9]+$'
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Charalampos Mitrodimas <charmitro@posteo.net>
Link: https://patch.msgid.link/20260304164448.1024410-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Node names should be generic, so use 'bluetooth' as the node name.
This fixes the following dt-schema warning:
'btmrvl@2' does not match '^bluetooth(@.*)?$'
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260226144842.2727107-2-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The 'regulator-suspend-mem-disabled' property is not documented nor used
anywhere.
Remove this invalid property.
This fixes the following dt-schema warning:
('regulator-suspend-mem-disabled' was unexpected)
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260226144842.2727107-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
'rotation-matrix' is not a valid property.
Use the documented 'mount-matrix' property instead.
This fixes the following dt-schema warning:
accelerometer@29 (st,lis3de): 'rotation-matrix' does not match any of the
regexes: '^pinctrl-[0-9]+$'
accelerometer@29 (st,lis3de): rotation-matrix:
b'1\x000\x000\x000\x00-1\x000\x000\x000\x001\x00' is not of type 'object',
'integer', 'array', 'boolean', 'null'
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260226145916.2729492-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to st,m41t80.yaml, the correct compatible for the RV4162 RTC
is "microcrystal,rv4162".
Fix it accordingly.
This fixes the following dt-schema warning:
rtc@68: failed to match any schema with compatible: ['rv4162']
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260301124156.473862-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to rockchip,emac.yaml, 'phy-reset-duration' and 'phy-reset-gpios'
are not valid properties.
Use the valid 'reset-gpios' and 'reset-assert-us' properties under
the etherne-phy node.
This fixes the following dt-schema warning:
Unevaluated properties are not allowed ('phy-reset-duration',
'phy-reset-gpios' were unexpected)
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260228013257.256973-1-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to rockchip-thermal.yaml, RK3288 does not require rockchip,grf,
so remove this invalid property.
This fixes the following dt-schema warning:
tsadc@ff280000 (rockchip,rk3288-tsadc): False schema does not allow [[53]]
The rockchip_thermal driver also confirms that grf is not needed as
the rk3288_tsadc_data contains:
.grf_required = false,
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20260228013257.256973-2-festevam@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Currently, `CoherentAllocation` is concecptually a DMA coherent container
of a slice of `[T]` of runtime-checked length. Generalize it by creating
`dma::Coherent<T>` which can hold any value of `T`.
`Coherent::alloc_with_attrs` is implemented but not yet exposed, as I
believe we should not expose the way to obtain an uninitialized coherent
region.
`Coherent<[T]>` provides a `len` method instead of the previous `count()`
method to be consistent with methods on slices.
The existing type is re-defined as a type alias of `Coherent<[T]>` to ease
transition. Methods in use are not yet removed.
Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260320194626.36263-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Convert all imports to use "kernel vertical" style.
With this, subsequent patches neither introduce unrelated changes nor
leave an inconsistent import pattern.
While at it, drop unnecessary imports covered by prelude::*.
Link: https://docs.kernel.org/rust/coding-guidelines.html#imports
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260320194626.36263-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The prefix/header of a TLP that caused an error may be recorded in the AER
Capability and emitted to the kernel log in raw hex format. Document the
existence and usage of tlp-tool, which decodes the TLP Header into
human-readable form.
The TLP Header hints at the root cause of an error, yet is often ignored
because of its seeming opaqueness. Instead, PCIe errors are frequently
worked around by a change in the kernel without fully understanding the
actual source of the problem. With more documentation on available tools
we'll hopefully come up with better solutions.
There are also wireshark dissectors for TLPs, but it seems they expect a
complete TLP, not just the header, and they cannot grok the hex format
emitted by the kernel directly. tlp-tool appears to be the most cut and
dried solution out there.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Maciej Grochowski <mx2pg@pm.me>
Link: https://patch.msgid.link/bf826c41b4c1d255c7dcb16e266b52f774d944ed.1774246067.git.lukas@wunner.de
The for_each_endpoint_of_node() macro requires calling of_node_put() on the
endpoint node when breaking out of the loop early.
Add of_node_put(endpoint) before the early return to release the reference.
Fixes: cf3287fb2c ("PCI/pwrctrl: Ensure that remote endpoint node parent has supply requirement")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260323-pwctrl-v1-1-f5c03a2df7fb@gmail.com
Christian Koenig mentioned he'd like to step down from the reviewer
role for the GPU buddy allocator. Joel Fernandes is stepping in as
reviewer with agreement from Matthew Auld and Arun Pravin.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260320045711.43494-3-joelagnelf@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Add safe Rust abstractions over the Linux kernel's GPU buddy
allocator for physical memory management. The GPU buddy allocator
implements a binary buddy system useful for GPU physical memory
allocation. nova-core will use it for physical memory allocation.
Cc: Nikola Djukic <ndjukic@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260320045711.43494-2-joelagnelf@nvidia.com
[ * Use doc-comments for GpuBuddyAllocMode methods and GpuBuddyGuard,
* Fix comma splice in GpuBuddyParams::chunk_size doc-comment,
* Remove redundant summary in GpuBuddy::new doc-comment,
* Drop Rust helper for gpu_buddy_block_size().
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
As reported by AI review [1], if the refillqs allocation fails, refillqs
will be NULL but num_refillqs will be non-zero. The release function
will then dereference refillqs since it thinks the refillqs are present,
resulting in a NULL ptr dereference.
Only assign the num refillqs if the allocation was successful. This will
prevent the release function from entering the loop and accessing
refillqs.
[1] https://lore.kernel.org/netdev/20260227035625.2632753-1-kuba@kernel.org/
Fixes: 95af467d9a ("idpf: configure resources for RX queues")
Signed-off-by: Joshua Hay <joshua.a.hay@intel.com>
Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Deinit calls idpf_idc_deinit_core_aux_device to free the cdev_info
memory, but leaves the adapter->cdev_info field with a stale pointer
value. This will bypass subsequent "if (!cdev_info)" checks if cdev_info
is not reallocated. For example, if idc_init fails after a reset,
cdev_info will already have been freed during the reset handling, but it
will not have been reallocated. The next reset or rmmod will result in a
crash.
[ +0.000008] BUG: kernel NULL pointer dereference, address: 00000000000000d0
[ +0.000033] #PF: supervisor read access in kernel mode
[ +0.000020] #PF: error_code(0x0000) - not-present page
[ +0.000017] PGD 2097dfa067 P4D 0
[ +0.000017] Oops: Oops: 0000 [#1] SMP NOPTI
...
[ +0.000018] RIP: 0010:device_del+0x3e/0x3d0
[ +0.000010] Call Trace:
[ +0.000010] <TASK>
[ +0.000012] idpf_idc_deinit_core_aux_device+0x36/0x70 [idpf]
[ +0.000034] idpf_vc_core_deinit+0x3e/0x180 [idpf]
[ +0.000035] idpf_remove+0x40/0x1d0 [idpf]
[ +0.000035] pci_device_remove+0x42/0xb0
[ +0.000020] device_release_driver_internal+0x19c/0x200
[ +0.000024] driver_detach+0x48/0x90
[ +0.000018] bus_remove_driver+0x6d/0x100
[ +0.000023] pci_unregister_driver+0x2e/0xb0
[ +0.000022] __do_sys_delete_module.isra.0+0x18c/0x2b0
[ +0.000025] ? kmem_cache_free+0x2c2/0x390
[ +0.000023] do_syscall_64+0x107/0x7d0
[ +0.000023] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Pass the adapter struct into idpf_idc_deinit_core_aux_device instead and
clear the cdev_info ptr.
Fixes: f4312e6bfa ("idpf: implement core RDMA auxiliary dev create, init, and destroy")
Signed-off-by: Joshua Hay <joshua.a.hay@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
dma_alloc_noncoherent() returns NULL on failure, but callers of
aie2_alloc_msg_buffer() check for IS_ERR(). Return ERR_PTR(-ENOMEM)
instead of NULL to match the amdxdna_iommu_alloc() path and the
caller's error checking convention.
Fixes: ece3e89809 ("accel/amdxdna: Allow forcing IOVA-based DMA via module parameter")
Signed-off-by: Wendy Liang <wendy.liang@amd.com>
Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260323173719.2311474-1-lizhi.hou@amd.com
ice_repr_get_stats64() and __ice_get_ethtool_stats() call
ice_update_vsi_stats() on the VF's src_vsi. This always returns early
because ICE_VSI_DOWN is permanently set for VF VSIs - ice_up() is never
called on them since queues are managed by iavf through virtchnl.
In __ice_get_ethtool_stats() the original code called
ice_update_vsi_stats() for all VSIs including representors, iterated
over ice_gstrings_vsi_stats[] to populate the data, and then bailed out
with an early return before the per-queue ring stats section. That early
return was necessary because representor VSIs have no rings on the PF
side - the rings belong to the VF driver (iavf), so accessing per-queue
stats would be invalid.
Move the representor handling to the top of __ice_get_ethtool_stats()
and call ice_update_eth_stats() directly to read the hardware GLV_*
counters. This matches ice_get_vf_stats() which already uses
ice_update_eth_stats() for the same VF VSI in legacy mode. Apply the
same fix to ice_repr_get_stats64().
Note that ice_gstrings_vsi_stats[] contains five software ring counters
(rx_buf_failed, rx_page_failed, tx_linearize, tx_busy, tx_restart) that
are always zero for representors since the PF never processes packets on
VF rings. This is pre-existing behavior unchanged by this patch.
Fixes: 7aae80cef7 ("ice: add port representor ethtool ops and stats")
Signed-off-by: Petr Oros <poros@redhat.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Patryk Holda <patryk.holda@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
With the move to explicit pwrctrl power on/off APIs, the caller, i.e., the
PCI controller driver, should manage the power state. The pwrctrl drivers
should not try to clean up or power off when they are removed, as this
might end up disabling an already disabled regulator, causing a big
warning. This can be triggered if a PCI controller driver's .remove()
callback calls pci_pwrctrl_destroy_devices() after
pci_pwrctrl_power_off_devices().
Drop the devm cleanup parts that turn off regulators from the pwrctrl
drivers.
Fixes: b921aa3f8d ("PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIs")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260226092234.3859740-1-wenst@chromium.org
Add GHASH support to the gf128hash module.
This will replace the GHASH support in the crypto_shash API. It will be
used by the "gcm" template and by the AES-GCM library (when an
arch-optimized implementation of the full AES-GCM is unavailable).
This consists of a simple API that mirrors the existing POLYVAL API, a
generic implementation of that API based on the existing efficient and
side-channel-resistant polyval_mul_generic(), and the framework for
architecture-optimized implementations of the GHASH functions.
The GHASH accumulator is stored in POLYVAL format rather than GHASH
format, since this is what most modern GHASH implementations actually
need. The few implementations that expect the accumulator in GHASH
format will just convert the accumulator to/from GHASH format
temporarily. (Supporting architecture-specific accumulator formats
would be possible, but doesn't seem worth the complexity.)
However, architecture-specific formats of struct ghash_key will be
supported, since a variety of formats will be needed there anyway. The
default format is just the key in POLYVAL format.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260319061723.1140720-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Currently, some architectures (arm64 and x86) have optimized code for
both GHASH and POLYVAL. Others (arm, powerpc, riscv, and s390) have
optimized code only for GHASH. While POLYVAL support could be
implemented on these other architectures, until then we need to support
the case where arch-optimized functions are present only for GHASH.
Therefore, update the support for arch-optimized POLYVAL functions to
allow architectures to opt into supporting these functions individually.
The new meaning of CONFIG_CRYPTO_LIB_GF128HASH_ARCH is that some level
of GHASH and/or POLYVAL acceleration is provided.
Also provide an implementation of polyval_mul() based on
polyval_blocks_arch(), for when polyval_mul_arch() isn't implemented.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260319061723.1140720-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Currently, the standalone GHASH code is coupled with crypto_shash. This
has resulted in unnecessary complexity and overhead, as well as the code
being unavailable to library code such as the AES-GCM library. Like was
done with POLYVAL, it needs to find a new home in lib/crypto/.
GHASH and POLYVAL are closely related and can each be implemented in
terms of each other. Optimized code for one can be reused with the
other. But also since GHASH tends to be difficult to implement directly
due to its unnatural bit order, most modern GHASH implementations
(including the existing arm, arm64, powerpc, and x86 optimized GHASH
code, and the new generic GHASH code I'll be adding) actually
reinterpret the GHASH computation as an equivalent POLYVAL computation,
pre and post-processing the inputs and outputs to map to/from POLYVAL.
Given this close relationship, it makes sense to group the GHASH and
POLYVAL code together in the same module. This gives us a wide range of
options for implementing them, reusing code between the two and properly
utilizing whatever instructions each architecture provides.
Thus, GHASH support will be added to the library module that is
currently called "polyval". Rename it to an appropriate name:
"gf128hash". Rename files, options, functions, etc. where appropriate
to reflect the upcoming sharing with GHASH. (Note: polyval_kunit is not
renamed, as ghash_kunit will be added alongside it instead.)
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260319061723.1140720-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Rename trans_drain() to gfs2_trans_drain().
Add a new gfs2_trans_drain_list() helper and use it in
gfs2_trans_drain() to reduce code duplication.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Move gfs2_remove_from_journal() from meta_io.c to log.c and fix a minor
indentation glitch.
With that, gfs2_remove_from_ail() is now only used inside log.c, so it
can be made static.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
These two helpers only hide the locking operation; they do not make
the code more readable.
Created with:
sed -i -e 's:gfs2_log_unlock(sdp):spin_unlock(\&sdp->sd_log_lock):' \
-e 's:gfs2_log_lock(sdp):spin_lock(\&sdp->sd_log_lock):'
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
It turns out that for some workloads, the fix in commit b74cd55aa9
("gfs2: low-memory forced flush fixes") causes the number of forced log
flushes to increase to a degree that the overall filesystem performance
drops significantly. Address that by forcing a log flush only when
gfs2_writepages cannot make any progress rather than when it cannot make
"enough" progress.
Fixes: b74cd55aa9 ("gfs2: low-memory forced flush fixes")
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
When gfs2_evict_inode() is called on an inode with unwritten data in the
page cache, the page cache needs to be written before it can be
truncated. This doesn't always happen. Fix that by changing
gfs2_evict_inode() to always either call evict_linked_inode() or
evict_unlinked_inode().
Inside evict_unlinked_inode(), first check if the inode is dirty. If it
is, make sure the inode glock is held and write back the data and
metadata. If it isn't, skip those steps.
Also, make sure that gfs2_evict_inode() calls gfs2_evict_inode() and
evict_unlinked_inode() only if ip->i_gl is not NULL; this avoids
unnecessary complications there.
Fixes xfstest generic/211.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Add gl helper variables in evict_unlinked_inode() and
evict_linked_inode(). This patch isn't very interesting by itself, but
it makes the next patch more readable.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
In evict_linked_inode(), the truncate_inode_pages() calls are carried
out inside a transaction. This code was added to what was then function
gfs2_delete_inode() in commit 16615be18c ("[GFS2] Clean up journaled
data writing").
These transactions are only used for creating revokes for the jdata
buffers in the journal, so don't create such transactions when we know
that the address space doesn't contain any jdata buffers for this inode
and truncate the metadata address space outside of the transaction.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Commit 0f00a897c9 ("ice: check if SF is ready in ethtool ops")
refactored the VF readiness check into a generic repr->ops.ready()
callback but implemented ice_repr_ready_vf() with inverted logic:
return !ice_check_vf_ready_for_cfg(repr->vf);
ice_check_vf_ready_for_cfg() returns 0 on success, so the negation
makes ready() return non-zero when the VF is ready. All callers treat
non-zero as "not ready, skip", causing ndo_get_stats64, get_drvinfo,
get_strings and get_ethtool_stats to always bail out in switchdev mode.
Remove the erroneous negation. The SF variant ice_repr_ready_sf() is
already correct (returns !active, i.e. non-zero when not active).
Fixes: 0f00a897c9 ("ice: check if SF is ready in ethtool ops")
Signed-off-by: Petr Oros <poros@redhat.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Tested-by: Patryk Holda <patryk.holda@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
When allocating netdevice using alloc_etherdev_mqs() the maximum
supported queues number should be passed. The vsi->alloc_txq/rxq is
storing current number of queues, not the maximum ones.
Use the same function for getting max Tx and Rx queues which is used
during ethtool -l call to set maximum number of queues during netdev
allocation.
Reproduction steps:
$ethtool -l $pf # says current 16, max 64
$ethtool -S $pf # fine
$ethtool -L $pf combined 40 # crash
[491187.472594] Call Trace:
[491187.472829] <TASK>
[491187.473067] netif_set_xps_queue+0x26/0x40
[491187.473305] ice_vsi_cfg_txq+0x265/0x3d0 [ice]
[491187.473619] ice_vsi_cfg_lan_txqs+0x68/0xa0 [ice]
[491187.473918] ice_vsi_cfg_lan+0x2b/0xa0 [ice]
[491187.474202] ice_vsi_open+0x71/0x170 [ice]
[491187.474484] ice_vsi_recfg_qs+0x17f/0x230 [ice]
[491187.474759] ? dev_get_min_mp_channel_count+0xab/0xd0
[491187.474987] ice_set_channels+0x185/0x3d0 [ice]
[491187.475278] ethnl_set_channels+0x26f/0x340
Fixes: ee13aa1a2c ("ice: use netif_get_num_default_rss_queues()")
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Replace devm_clk_get() followed by clk_prepare_enable() with
devm_clk_get_enabled() for the clock. This removes the need for
explicit clock enable/disable calls and the custom cleanup function,
as the managed API automatically handles clock disabling on device
removal or probe failure.
Remove the now-unnecessary sp7021_spi_disable_unprepare() function
and the devm_add_action_or_reset() call.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/fb0bc46107975cfff4eefa9ba96fe7545996ae52.1773885292.git.xiaopei01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace devm_clk_get() followed by clk_prepare_enable() with
devm_clk_get_enabled() for the clock. This removes the need for
explicit clock enable and disable calls, as the managed API automatically
handles clock disabling on device removal or probe failure.
Remove the now-unnecessary clk_disable_unprepare() calls from the probe
error paths and the remove callback. Also simplify error handling by
using dev_err_probe().
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Link: https://patch.msgid.link/c8259f582596fd08541b94dce5dbb4cae513e295.1773885292.git.xiaopei01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace devm_clk_get() followed by clk_prepare_enable() with
devm_clk_get_enabled() for the bus clock. This reduces boilerplate code
and error handling, as the managed API automatically disables the clock
when the device is removed or if probe fails.
Remove the now-unnecessary clk_disable_unprepare() calls from the probe
error path and the remove callback. Adjust the error handling to use the
existing put_host label.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/73d0d8ecb4e1af5a558d6a7866c0f886d94fe3d1.1773885292.git.xiaopei01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace devm_clk_get() followed by clk_prepare_enable() with
devm_clk_get_enabled() for both the "hsspi" and "pll" clocks. This
reduces boilerplate code and error handling, as the managed API
automatically disables the clocks when the device is removed or if
probe fails.
Remove the now-unnecessary clk_disable_unprepare() calls from the
probe error paths and the remove callback. Simplify the error handling
by converting to direct returns with dev_err_probe() where appropriate.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/a3d07ed20d7bdc676fb10c9a73224f80e83b3232.1773885292.git.xiaopei01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace devm_clk_get() followed by clk_prepare_enable() with
devm_clk_get_enabled() for both the "hsspi" and "pll" clocks. This
reduces boilerplate code and error handling, as the managed API
automatically disables the clocks when the device is removed or if
probe fails.
Remove the now-unnecessary clk_disable_unprepare() calls from the
probe error paths and the remove callback. Accordingly, adjust the
error handling labels to direct returns where possible.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/3a187be6d9963645f01caebc1169e06f8804b7a6.1773885292.git.xiaopei01@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
A number of dev_dbg() and dev_err() calls get passed values that are
of __le32 type which does not get noticed by sparse until my variadic
checking patches.
There are a number of these, and we should probably fix these up.
The sparse warnings are numerous so the first few are listed here that
this patch fixes:
sound/soc/soc-topology.c:226:9: warning: incorrect type in argument 4 (different base types)
sound/soc/soc-topology.c:226:9: expected int
sound/soc/soc-topology.c:226:9: got restricted __le32 [usertype] get
sound/soc/soc-topology.c:226:9: warning: incorrect type in argument 5 (different base types)
sound/soc/soc-topology.c:226:9: expected int
sound/soc/soc-topology.c:226:9: got restricted __le32 [usertype] put
sound/soc/soc-topology.c:226:9: warning: incorrect type in argument 6 (different base types)
sound/soc/soc-topology.c:226:9: expected int
sound/soc/soc-topology.c:226:9: got restricted __le32 [usertype] info
sound/soc/soc-topology.c:226:9: warning: incorrect type in argument 4 (different base types)
sound/soc/soc-topology.c:226:9: expected int
sound/soc/soc-topology.c:226:9: got restricted __le32 [usertype] get
sound/soc/soc-topology.c:226:9: warning: incorrect type in argument 5 (different base types)
sound/soc/soc-topology.c:226:9: expected int
sound/soc/soc-topology.c:226:9: got restricted __le32 [usertype] put
sound/soc/soc-topology.c:226:9: warning: incorrect type in argument 6 (different base types)
sound/soc/soc-topology.c:226:9: expected int
sound/soc/soc-topology.c:226:9: got restricted __le32 [usertype] info
sound/soc/soc-topology.c:226:9: warning: incorrect type in argument 4 (different base types)
sound/soc/soc-topology.c:226:9: expected int
sound/soc/soc-topology.c:226:9: got restricted __le32 [usertype] get
sound/soc/soc-topology.c:226:9: warning: incorrect type in argument 5 (different base types)
sound/soc/soc-topology.c:226:9: expected int
sound/soc/soc-topology.c:226:9: got restricted __le32 [usertype] put
sound/soc/soc-topology.c:226:9: warning: incorrect type in argument 6 (different base types)
sound/soc/soc-topology.c:226:9: expected int
sound/soc/soc-topology.c:226:9: got restricted __le32 [usertype] info
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://patch.msgid.link/20260323175604.19315-1-ben.dooks@codethink.co.uk
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a new module `kernel::interop::list` for working with C's doubly
circular linked lists. Provide low-level iteration over list nodes.
Typed iteration over actual items is provided with a `clist_create`
macro to assist in creation of the `CList` type.
Cc: Nikola Djukic <ndjukic@nvidia.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Gary Guo <gary@garyguo.net>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Link: https://patch.msgid.link/20260319210722.1543776-1-joelagnelf@nvidia.com
[ * Remove stray empty comment and double blank line in doctest,
* Improve wording and fix a few typos,
* Use markdown emphasis instead of caps,
* Move interop/mod.rs to interop.rs.
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
UAPI Changes:
amdxdna:
- Add sensors ioctls
Cross-subsystem Changes:
dma-buf:
- clean pages with helpers
Documenatation:
- devicetree: Add lxd vendor prefix
Core Changes:
buddy:
- improve aligned allocations
gem-shmem:
- Track page accessed/dirty status across mmap/vmap
ttm:
- fix fence signalling
Driver Changes:
amdxdna:
- provide NPU power estimate
- support sensor for column utilization
bridge:
- anx7625: Fix USB Type-C handling
- cdns-mhdp8546-core: Handle HDCP state in bridge atomic_check
ivpu:
- fixes
loongson:
- replace custom code with drm_gem_ttm_dumb_map_offset()
mxsfb:
- lcdif: report probing errors with dev_err_probe()
panel:
- ilitek-ili9882t: Allow GPIO calls to sleep
- jadard: Support TAIGUAN XTI05101-01A
- lxd: Support LXD M9189A plus DT bindings
- mantix: Fix pixel clock; Clean up
- motorola: Support Motorola Atrix 4G and Droid X2 plus DT bindings
- novatek: Support Novatek/Tianma NT37700F plus DT bindings
- renesas: Clean up
- simple: Support EDT ET057023UDBA plus DT bindings; Support Powertip
PH800480T032-ZHC19 plus DT bindings; Support Waveshare 13.3"
- clean up DT bindings of various drivers
panthor:
- fix fence handling
vc4:
- check return value of platform_get_irq_byname()
-----BEGIN PGP SIGNATURE-----
iQFPBAABCgA5FiEEchf7rIzpz2NEoWjlaA3BHVMLeiMFAmmycX0bFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJEGgNwR1TC3ojt1cH/1OoLz0cc0wZ0VM/f8t/
Ha81Ff4mVOS5j2x3V0m+SZrljKl4qgfTka6CYfhHn9aqVS27pkB2My4vtq6h3EXQ
apfKIqhgMjVpJxin9fbSb29JGt+/NtuUEFbq+s356SF2L5RZ8fGEWmdETsNfItvj
lLZOkvys/9MWRyCjO4pOD6kyJul2Bg+79hJ1H3IdE62WNyVM1FNVcMWIBsWdigBG
o5wJv+RQ9sffD7zNiw122AI+Zr+elCeXekqMZghIP8Su+JkjfEMsr0AGpsqpvFbJ
TsdFR52ZZR4fEzwZZnrn4gTGN3xPSUIpWcSXrOkm7gp5d4ZVE/X9diavrzJFb0vg
uM8=
=TJlw
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2026-03-12' into drm-rust-next
We need the latest GPU buddy changes from drm-misc-next-2026-03-12 in
drm-rust-next as well, as the Rust abstractions are built on top of it.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Whenever we get an error updating the device stats item for a device in
btrfs_run_dev_stats() we allow the loop to go to the next device, and if
updating the stats item for the next device succeeds, we end up losing
the error we had from the previous device.
Fix this by breaking out of the loop once we get an error and make sure
it's returned to the caller. Since we are in the transaction commit path
(and in the critical section actually), returning the error will result
in a transaction abort.
Fixes: 733f4fbbc1 ("Btrfs: read device stats on mount, write modified ones during commit")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
If overlay is used on top of btrfs, dentry->d_sb translates to overlay's
super block and fsid assignment will lead to a crash.
Use file_inode(file)->i_sb to always get btrfs_sb.
Reviewed-by: Boris Burkov <boris@bur.io>
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
Since commit 3d74a7556f ("btrfs: zlib: introduce zlib_compress_bio()
helper"), there are some reports about different crashes in zlib
compression path. One of the symptoms is list corruption like the
following:
list_del corruption. next->prev should be fffffbb340204a08, but was ffff8d6517cb7de0. (next=fffffbb3402d62c8)
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:65!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 1 UID: 0 PID: 21436 Comm: kworker/u16:7 Not tainted 7.0.0-rc2-jcg+ #1 PREEMPT
Hardware name: LENOVO 10VGS02P00/3130, BIOS M1XKT57A 02/10/2022
Workqueue: btrfs-delalloc btrfs_work_helper [btrfs]
RIP: 0010:__list_del_entry_valid_or_report+0xec/0xf0
Call Trace:
<TASK>
btrfs_alloc_compr_folio+0xae/0xc0 [btrfs]
zlib_compress_bio+0x39d/0x6a0 [btrfs]
btrfs_compress_bio+0x2e3/0x3d0 [btrfs]
compress_file_range+0x2b0/0x660 [btrfs]
btrfs_work_helper+0xdb/0x3e0 [btrfs]
process_one_work+0x192/0x3d0
worker_thread+0x19a/0x310
kthread+0xdf/0x120
ret_from_fork+0x22e/0x310
ret_from_fork_asm+0x1a/0x30
</TASK>
---[ end trace 0000000000000000 ]---
Other symptoms include VM_BUG_ON() during folio_put() but it's rarer.
David Sterba firstly reported this during his CI runs but unfortunately
I'm unable to hit it.
Meanwhile zstd/lzo doesn't seem to have the same problem.
[CAUSE]
During zlib_compress_bio() every time the output buffer is full, we
queue the full folio into the compressed bio, and allocate a new folio
as the output folio.
After the input has finished, we loop through zlib_deflate() with
Z_FINISH to flush all output.
And when that is done, we still need to check if the last folio has any
content, and if so we still need to queue that part into the compressed
bio.
The problem is in the final folio handling, if the final folio is full
(for x86_64 the folio size is 4K), the length to queue is calculated by
u32 cur_len = offset_in_folio(out_folio, workspace->strm.total_out);
But since total_out is 4K aligned, the resulted @cur_len will be 0, then
we hit the bio_add_folio(), which has a quirk that if bio_add_folio()
got an length 0, it will still queue the folio into the bio, but return
false.
In that case we go to out: tag, which calls btrfs_free_compr_folio() to
release @out_folio, which may put the out folio into the btrfs global
pool list.
On the other hand, that @out_folio is already added to the
compressed bio, and will later be released again by
cleanup_compressed_bio(), which results double release.
And if this time we still need to put the folio into the btrfs global
pool list, it will result a list corruption because it's already in the
list.
[FIX]
Instead of offset_inside_folio(), directly use the difference between
strm.total_out and bi_size.
So that if the last folio is completely full, we can still properly
queue the full folio other than queueing zero byte.
Fixes: 3d74a7556f ("btrfs: zlib: introduce zlib_compress_bio() helper")
Reported-by: David Sterba <dsterba@suse.com>
Reported-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Reported-by: syzbot+3c4d8371d65230f852a2@syzkaller.appspotmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221176
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
When create_space_info_sub_group() allocates elements of
space_info->sub_group[], kobject_init_and_add() is called for each
element via btrfs_sysfs_add_space_info_type(). However, when
check_removing_space_info() frees these elements, it does not call
btrfs_sysfs_remove_space_info() on them. As a result, kobject_put() is
not called and the associated kobj->name objects are leaked.
This memory leak is reproduced by running the blktests test case
zbd/009 on kernels built with CONFIG_DEBUG_KMEMLEAK. The kmemleak
feature reports the following error:
unreferenced object 0xffff888112877d40 (size 16):
comm "mount", pid 1244, jiffies 4294996972
hex dump (first 16 bytes):
64 61 74 61 2d 72 65 6c 6f 63 00 c4 c6 a7 cb 7f data-reloc......
backtrace (crc 53ffde4d):
__kmalloc_node_track_caller_noprof+0x619/0x870
kstrdup+0x42/0xc0
kobject_set_name_vargs+0x44/0x110
kobject_init_and_add+0xcf/0x150
btrfs_sysfs_add_space_info_type+0xfc/0x210 [btrfs]
create_space_info_sub_group.constprop.0+0xfb/0x1b0 [btrfs]
create_space_info+0x211/0x320 [btrfs]
btrfs_init_space_info+0x15a/0x1b0 [btrfs]
open_ctree+0x33c7/0x4a50 [btrfs]
btrfs_get_tree.cold+0x9f/0x1ee [btrfs]
vfs_get_tree+0x87/0x2f0
vfs_cmd_create+0xbd/0x280
__do_sys_fsconfig+0x3df/0x990
do_syscall_64+0x136/0x1540
entry_SYSCALL_64_after_hwframe+0x76/0x7e
To avoid the leak, call btrfs_sysfs_remove_space_info() instead of
kfree() for the elements.
Fixes: f92ee31e03 ("btrfs: introduce btrfs_space_info sub-group")
Link: https://lore.kernel.org/linux-block/b9488881-f18d-4f47-91a5-3c9bf63955a5@wdc.com/
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
