I got some build warnings with W=1:
arch/x86/coco/sev/core.c:
arch/x86/crypto/aria_aesni_avx2_glue.c:
warning: EXPORT_SYMBOL() is used,
but #include <linux/export.h> is missing
arch/x86/crypto/aria_aesni_avx_glue.c:
warning: EXPORT_SYMBOL() is used,
but #include <linux/export.h> is missing
arch/x86/crypto/camellia_aesni_avx_glue.c:
warning: EXPORT_SYMBOL() is used,
but #include <linux/export.h> is missing
arch/x86/crypto/camellia_glue.c: warning:
EXPORT_SYMBOL() is used,
but #include <linux/export.h> is missing
arch/x86/crypto/curve25519-x86_64.c:
warning: EXPORT_SYMBOL() is used,
but #include <linux/export.h> is missing
arch/x86/crypto/serpent_avx_glue.c:
warning: EXPORT_SYMBOL() is used,
but #include <linux/export.h> is missing
arch/x86/crypto/sm4_aesni_avx_glue.c:
warning: EXPORT_SYMBOL() is used,
but #include <linux/export.h> is missing
arch/x86/crypto/twofish_glue.c:
warning: EXPORT_SYMBOL() is used,
but #include <linux/export.h> is missing
arch/x86/crypto/twofish_glue_3way.c:
warning: EXPORT_SYMBOL() is used,
but #include <linux/export.h> is missing
so I fixed these build warnings for x86_64.
Signed-off-by: ChengZhenghan <chengzhenghan@uniontech.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
I get a very rare -Wstringop-overread warning with gcc-15 for one function
in aesbs_ctr_encrypt():
arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt':
arch/arm/crypto/aes-neonbs-glue.c:212:1446: error: '__builtin_memcpy' offset [17, 2147483647] is out of the bounds [0, 16] of object 'buf' with type 'u8[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds=]
212 | src = dst = memcpy(buf + sizeof(buf) - bytes,
arch/arm/crypto/aes-neonbs-glue.c: In function 'ctr_encrypt':
arch/arm/crypto/aes-neonbs-glue.c:218:17: error: 'aesbs_ctr_encrypt' reading 1 byte from a region of size 0 [-Werror=stringop-overread]
218 | aesbs_ctr_encrypt(dst, src, ctx->rk, ctx->rounds, bytes, walk.iv);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 2 of type 'const u8[0]' {aka 'const unsigned char[]'}
arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 3 of type 'const u8[0]' {aka 'const unsigned char[]'}
arch/arm/crypto/aes-neonbs-glue.c:218:17: note: referencing argument 6 of type 'u8[0]' {aka 'unsigned char[]'}
arch/arm/crypto/aes-neonbs-glue.c:36:17: note: in a call to function 'aesbs_ctr_encrypt'
36 | asmlinkage void aesbs_ctr_encrypt(u8 out[], u8 const in[], u8 const rk[],
This could happen in theory if walk.nbytes is larger than INT_MAX and gets
converted to a negative local variable.
Keep the type unsigned like the orignal nbytes to be sure there is no
integer overflow.
Fixes: c8bf850e99 ("crypto: arm/aes-neonbs-ctr - deal with non-multiples of AES block size")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Use the Crypto API partial block handling.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The drm panel funcs should be static, fix it.
Fixes: 3fdd5bfbd6 ("drm/i915/panel: register drm_panel and call prepare/unprepare for ICL+ DSI")
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250612124617.626958-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The drm_writeback_connector_cleanup have the signature:
static void drm_writeback_connector_cleanup(
struct drm_device *dev,
struct drm_writeback_connector *wb_connector)
But it is stored and used as a drmres_release_t
typedef void (*drmres_release_t)(struct drm_device *dev, void *res);
While the current code is valid and does not produce any warning, the
CFI runtime check (CONFIG_CFI_CLANG) can fail because the function
signature is not the same as drmres_release_t.
In order to fix this, change the function signature to match what is
expected by drmres_release_t.
Fixes: 1914ba2b91 ("drm: writeback: Create drmm variants for drm_writeback_connector initialization")
Suggested-by: Mark Yacoub <markyacoub@google.com>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://lore.kernel.org/r/20250429-drm-fix-writeback-cleanup-v2-1-548ff3a4e284@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250619-gpiochip-set-rv-gpio-v2-10-74abf689fbd8@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The lines on this chip are input-only. GPIO core can handle the missing
.set() callback so there's no need to implement a dummy here. Drop it.
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Link: https://lore.kernel.org/r/20250619-gpiochip-set-rv-gpio-v2-5-74abf689fbd8@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250619-gpiochip-set-rv-gpio-v2-4-74abf689fbd8@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250619-gpiochip-set-rv-gpio-v2-3-74abf689fbd8@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Daniel Sullivan <danieljsullivan7@gmail.com>
Link: https://lore.kernel.org/r/aFdKce3Go9iF4A6m@danv-Standard-PC-Q35-ICH9-2009
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
When invoking device_create_with_groups(), its return value is stored
in `data->cdev_base`. However, in case of faiure, `data` is first freed
and then derefernced in order to return `data->cdev_base`.
Fix the use-after-free by extracting the error code before free'ing
`data`.
Fixes: fd19792851 ("gpio: sysfs: remove the mockdev pointer from struct gpio_device")
Addresses-Coverity-ID: 1644512 ("Memory - illegal accesses (USE_AFTER_FREE)")
Signed-off-by: Antonio Quartulli <antonio@mandelbit.com>
Link: https://lore.kernel.org/r/20250622220221.28025-1-antonio@mandelbit.com
[Bartosz: added Fixes: tag, tweaked commit message]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The RSA functions moved by the below commit to 8250_rsa.c are used in
8250_base.c. Since that can be a module (when CONFIG_SERIAL_8250=m),
this causes build failures:
ERROR: modpost: "rsa_autoconfig" [drivers/tty/serial/8250/8250_base.ko] undefined!
ERROR: modpost: "rsa_reset" [drivers/tty/serial/8250/8250_base.ko] undefined!
ERROR: modpost: "rsa_disable" [drivers/tty/serial/8250/8250_base.ko] undefined!
ERROR: modpost: "rsa_enable" [drivers/tty/serial/8250/8250_base.ko] undefined!
Fix them by exporting the functions. But only to the base module using
EXPORT_SYMBOL_GPL_FOR_MODULES(). (And not to the whole world.)
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/all/20250619165607.33403e19@canb.auug.org.au/
Fixes: 5a128fb475 ("serial: 8250: move RSA functions to 8250_rsa.c")
Link: https://lore.kernel.org/r/20250623061035.436414-1-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We need the driver-core fixes that are in 6.16-rc3 into here as well
to build on top of.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
An earlier patch marked one of the two CPU masks as 'static' to reduce stack
usage, but if CONFIG_NR_CPUS is large enough, the function still produces
a warning for compile testing:
drivers/cpufreq/armada-8k-cpufreq.c: In function 'armada_8k_cpufreq_init':
drivers/cpufreq/armada-8k-cpufreq.c:203:1: error: the frame size of 1416 bytes is larger than 1408 bytes [-Werror=frame-larger-than=]
Normally this should be done using alloc_cpumask_var(), but since the
driver already has a static mask and the probe function is not called
concurrently, use the same trick for both.
Fixes: 1ffec650d0 ("cpufreq: armada-8k: Avoid excessive stack usage")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmhYZ9AeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGPdcIAIR01BnZbU7knvkI
QSMlJR4zl8IDIu+9P35v5jmoklJFqYtIGQUnNTxrWK0i/NGj6+FAmA8xgAzeJZ7d
Kv0Qs0fkgwQWxFbbM9Xg9Vob8gxSZ6Qyo5ETz8UDupCNWyUPpMaRDLv8IRtF/19I
YAgXJqCXC4LuJJNROSkk3wiLqg+CerzJ/m7GJtBQdCmbv6h87HETaeQpKVgEwTkR
uEn99CDnOryovIYWoDaBbqLRF5AQr2JA6lqmQAr57wyjzuj1Ul2BNgLC/dlnuSQl
G8kv0+Kf+l1X3UJy1w8V4lkSLyjpTko7QIgv3AVDLDvOobCtZglWD4vPJ1OGvw4m
cHDrPg4=
=thw2
-----END PGP SIGNATURE-----
Merge tag 'v6.16-rc3' into perf-tools-next
To get the fixes in libbpf and perf tools.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The DMA map functions can fail and should be tested for errors.
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250620075602.12575-1-fourier.thomas@gmail.com
If we always align the vmemmap start to PAGE_SIZE, there is a
chance that we may end up allocating page-sized vmemmap backing
pages in RAM in the altmap not present case, because a PAGE_SIZE
aligned address is not PMD_SIZE-aligned.
In this patch, we are aligning the vmemmap start address to
PMD_SIZE if altmap is not present. This ensures that a PMD_SIZE
page is always allocated for the vmemmap mapping if altmap is
not present.
If altmap is present, Make sure we align the start vmemmap addr to
PAGE_SIZE so that we calculate the correct start_pfn in altmap
boundary check to decide whether we should use altmap or RAM based
backing memory allocation. Also the address need to be aligned for
set_pte operation. If the start addr is already PMD_SIZE aligned
and with in the altmap boundary then we will try to use a pmd size
altmap mapping else we go for page size mapping.
So if altmap is present, we try to use the maximum number of
altmap pages; otherwise, we allocate a PMD_SIZE RAM page.
Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/895c4afd912c85d344a2065e348fac90529ed48f.1750593372.git.donettom@linux.ibm.com
Error conditions are not handled properly if altmap is not present
and PMD_SIZE vmemmap_alloc_block_buf fails.
In this patch, if vmemmap_alloc_block_buf fails in the non-altmap
case, we will fall back to the base mapping.
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/7f95fe91c827a2fb76367a58dbea724e811fb152.1750593372.git.donettom@linux.ibm.com
IO hotplug add event is handled in the user space with drmgr tool.
After the device is enabled, the user space uses /sys/kernel/dlpar
interface with “dt add index <drc_index>” to update the device tree.
The kernel interface (dlpar_hp_dt_add()) finds the parent node for
the specified ‘drc_index’ from ibm,drc-info property. The recent FW
provides this property from 2017 onwards. But KVM guest code in
some releases is still using the older SLOF firmware which has
ibm,drc-indexes property instead of ibm,drc-info.
If the ibm,drc-info is not available, this patch adds changes to
search ‘drc_index’ from the indexes array in ibm,drc-indexes
property to support old FW.
Fixes: 02b98ff44a ("powerpc/pseries/dlpar: Add device tree nodes for DLPAR IO add")
Reported-by: Kowshik Jois <kowsjois@linux.ibm.com>
Signed-off-by: Haren Myneni <haren@linux.ibm.com>
Tested-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250531235002.239213-1-haren@linux.ibm.com
The macro kvm_trace_symbol_exit is used for providing the mappings
for the trap vectors and their names. Add mapping for H_VIRT so that
trap reason is displayed as string instead of a vector number when using
the kvm_guest_exit tracepoint.
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250516121225.276466-1-gautam@linux.ibm.com
use guard(mutex) for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161713@infradead.org/T/#u
Reviewed-by: Srikar Dronamraju <srikar@linux.ibm.com>
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250505075333.184463-6-sshegde@linux.ibm.com
use lock guards for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161713@infradead.org/T/#u
This shows the use of both guard and scoped_guard
Reviewed-by: Srikar Dronamraju <srikar@linux.ibm.com>
Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250505075333.184463-5-sshegde@linux.ibm.com
use scoped_guard for scope based resource management of mutex.
This would make the code simpler and easier to maintain.
More details on lock guards can be found at
https://lore.kernel.org/all/20230612093537.614161713@infradead.org/T/#u
Reviewed-by: Srikar Dronamraju <srikar@linux.ibm.com>
Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250505075333.184463-4-sshegde@linux.ibm.com
The kernel uses 3100 to indicate ISA version 3.1, not 3010, so
fix the Microwatt device tree to use 3100.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/aB6taMDWvJwOl9xj@bruin
Commit 030bdc3fd0 ("powerpc/defconfigs: Set HZ=100 on pseries and ppc64
defconfigs") lowered CONFIG_HZ from 250 to 100, citing reduced need for a
higher tick rate due to high-resolution timers and concerns about timer
interrupt overhead and cascading effects in the timer wheel.
However, improvements have been made to the timer wheel algorithm since
then, particularly in eliminating cascading effects at the cost of minor
timekeeping inaccuracies. More details are available here
https://lwn.net/Articles/646950/. This removes the original concern about
cascading, and the reliance on high-resolution timers is not applicable
to the scheduler, which still depends on periodic ticks set by CONFIG_HZ.
With the introduction of the EEVDF scheduler, users can specify custom
slices for workloads. The default base_slice is 3ms, but with CONFIG_HZ=100
(10ms tick interval), base_slice is ineffective. Workloads like stress-ng
that do not voluntarily yield the CPU run for ~10ms before switching out.
Additionally, setting a custom slice below 3ms (e.g., 2ms) should lower
task latency, but this effect is lost due to the coarse 10ms tick.
By increasing CONFIG_HZ to 1000 (1ms tick), base_slice is properly honored,
and user-defined slices work as expected. Benchmark results support this
change:
Latency improvements in schbench with EEVDF under stress-ng-induced noise:
Scheduler CONFIG_HZ Custom Slice 99th Percentile Latency (µs)
--------------------------------------------------------------------
EEVDF 1000 No 0.30x
EEVDF 1000 2 ms 0.29x
EEVDF (default) 100 No 1.00x
Switching to HZ=1000 reduces the 99th percentile latency in schbench by
~70%. This improvement occurs because, with HZ=1000, stress-ng tasks run
for ~3ms before yielding, compared to ~10ms with HZ=100. As a result,
schbench gets CPU time sooner, reducing its latency.
Daytrader Performance:
Daytrader results show minor variation within standard deviation,
indicating no significant regression.
Workload (Users/Instances) Throughput 1000HZ vs 100HZ (Std Dev%)
--------------------------------------------------------------------------
30 u, 1 i +3.01% (1.62%)
60 u, 1 i +1.46% (2.69%)
90 u, 1 i –1.33% (3.09%)
30 u, 2 i -1.20% (1.71%)
30 u, 3 i –0.07% (1.33%)
Avg. Response Time: No Change (=)
pgbench select queries:
Metric 1000HZ vs 100HZ (Std Dev%)
------------------------------------------------------------------
Average TPS Change +2.16% (1.27%)
Average Latency Change –2.21% (1.21%)
Average TPS: Higher the better
Average Latency: Lower the better
pgbench shows both throughput and latency improvements beyond standard
deviation.
Given these results and the improvements in timer wheel implementation,
increasing CONFIG_HZ to 1000 ensures that powerpc benefits from EEVDF’s
base_slice and allows fine-tuned scheduling for latency-sensitive
workloads.
Signed-off-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.ibm.com>
Reviewed-by: Mukesh Kumar Chaurasiya <mchauras@linux.ibm.com>
Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250330074734.16679-1-vineethr@linux.ibm.com
This adds all symbols required for use case like
livepatching. Distros already enable this config
and enabling this increases build time by 3%
(in a power9 128 cpu setup) and almost no size
changes for vmlinux.
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250116073419.344453-1-maddy@linux.ibm.com
Update OPP FFI callback signatures to use `c_int` from the `kernel::prelude`,
instead of accessing it via `kernel::ffi::c_int`.
Although these types are defined in a crate named `ffi`, they are re-exported
via the `kernel::prelude` and should be used from there. This aligns with the
Rust-for-Linux coding guidelines and ensures ABI correctness when interfacing
with C code.
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Abhinav Ananthu <abhinav.ogl@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Update cpufreq FFI callback signatures to use `c_int` from the `kernel::prelude`,
rather than accessing it explicitly through `kernel::ffi::c_int`.
Although these types are defined in the `ffi` crate, they are re-exported
via `kernel::prelude`. This aligns with the Rust-for-Linux coding
guidelines and ensures proper C ABI compatibility across platforms.
Signed-off-by: Abhinav Ananthu <abhinav.ogl@gmail.com>
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
[ Viresh: Fixed rustfmtcheck errors ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
On ChromiumOS devices, the `ecc_size` is set to 0 (check dmesg | grep ecc
to see `ecc: 0`): this disables ECC for ramoops region, even when
`ramoops.ecc=1` is given to kernel command line parameter.
Introduce `ecc_size` module parameter to provide a method to turn on ECC
for ramoops and set different values of ecc_size per devices.
A large `ecc_size` value can cause a kernel panic due to a constraint in
Reed-Solomon code library. The validation for this constraint should
belong to the common pstore RAM layer, not in each individual driver. So
this check is handled by a separate patch [1].
[1] https://lore.kernel.org/lkml/20250620054757.1006729-1-naoyatezuka@chromium.org
Signed-off-by: Naoya Tezuka <naoyatezuka@chromium.org>
Link: https://lore.kernel.org/r/20250620062822.1018798-1-naoyatezuka@chromium.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
drm/i915 feature pull for v6.17:
Features and functionality:
- Add support for DSC fractional link bpp on DP MST (Imre)
- Add support for simultaneous Panel Replay and Adaptive Sync (Jouni)
- Add support for PTL+ double buffered LUT registers (Chaitanya, Ville)
- Add PIPEDMC event handling in preparation for flip queue (Ville)
Refactoring and cleanups:
- Rename lots of DPLL interfaces to unify them (Suraj)
- Allocate struct intel_display dynamically (Jani)
- Abstract VLV IOSF sideband better (Jani)
- Use str_true_false() helper (Yumeng Fang)
- Refactor DSB code in preparation for flip queue (Ville)
- Use drm_modeset_lock_assert_held() instead of open coding (Luca)
- Remove unused arg from skl_scaler_get_filter_select() (Luca)
- Split out a separate display register header (Jani)
- Abstract DRAM detection better (Jani)
- Convert LPT/WPT SBI sideband to struct intel_display (Jani)
Fixes:
- Fix DSI HS command dispatch with forced pipeline flush (Gareth Yu)
- Fix BMG and LNL+ DP adaptive sync SDP programming (Ankit)
- Fix error path for xe display workqueue allocation (Haoxiang Li)
- Disable DP AUX access probe where not required (Imre)
- Fix DKL PHY access if the port is invalid (Luca)
- Fix PSR2_SU_STATUS access on ADL+ (Jouni)
- Add sanity checks for porch and sync on BXT/GLK DSI (Ville)
DRM core changes:
- Change AUX DPCD access probe address (Imre)
- Refactor EDID quirks, amd make them available to drivers (Imre)
- Add quirk for DPCD access probe (Imre)
- Add DPCD definitions for Panel Replay capabilities (Jouni)
Merges:
- Backmerges to sync with v6.15-rcs and v6.16-rc1 (Jani)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/fff9f231850ed410bd81b53de43eff0b98240d31@intel.com
Previous commit 548d770c33 ("regulator: pca9450: Add support for mode
operations") added support for setting forced PWM mode on the buck
regulators for pca9450a and pca9450bc parts. However part pca9451a also
supports this feature, thus add support for it.
Fixes: 548d770c33 ("regulator: pca9450: Add support for mode operations")
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
Link: https://patch.msgid.link/20250618063339.2508893-1-primoz.fiser@norik.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We currently log parse failures for ELD data and some disconnection events
as errors without rate limiting. These log messages can be triggered very
frequently in some situations, especially ELD parsing when there is nothing
connected to a HDMI port which will generate:
hdmi-audio-codec hdmi-audio-codec.1.auto: HDMI: Unknown ELD version 0
While there's doubtless work that could be done on reducing the number of
connection notification callbacks it's possible these may be legitimately
generated by poor quality physical connections so let's use rate limiting
to mitigate the log spam for the parse errors and lower the severity for
disconnect logging to debug level.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250613-asoc-hdmi-eld-logging-v1-1-76d64154d969@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch supports to add a HID device for SDCA HIDE entity.
The codec driver could call 'hid_input_report' to report events.
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250616114929.855496-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The value used to identify chip variant is not an enumeration, but raw
value used to compare registers with. The 'enum' is not used in the
code at all, so simplify and make it a raw hex value define, so
intention will be explicit.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250616-asoc-wcd93xx-enum-v1-3-a20a1b538509@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The value used to identify chip variant is not an enumeration, but raw
value used to compare registers with. The 'enum' is not used in the
code at all, so simplify and make it a raw hex value define, so
intention will be explicit.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250616-asoc-wcd93xx-enum-v1-2-a20a1b538509@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The value used to identify chip variant is not an enumeration, but raw
value used to compare registers with. The 'enum' is not used in the
code at all, so simplify and make it a raw hex value define, so
intention will be explicit.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250616-asoc-wcd93xx-enum-v1-1-a20a1b538509@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
