Convert the Texas Instruments DA850/AM18x Video Port Interface (VPIF)
device tree binding from text format to YAML dt-schema.
Add power-domains property missing from text.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Link: https://patch.msgid.link/20260813-ti-da850-vpif-v2-1-80ba62ca53d0@gmail.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The "{,N}" regex syntax is non-standard, but happens to be supported by
python re module. It is equivalent to "{0,N}" which is more commonly
supported. This fixes using a rust implementation of the DT schema
tools.
Link: https://patch.msgid.link/20260813174037.2263884-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The $ref "arm,gic.yaml#/properties/#interrupt-cells" doesn't work when
used with another json-schema implementation (rust). The issue is it not
a valid URI due to the 2nd "#" character in the JSON pointer. Though a
"#" is supposed to be valid within a JSON pointer. A possible solution
is to encode the "#" as "%23" instead, but the dtschema tools don't
handle that.
Just avoid all these issues as the $ref only resolves to a "const: 3"
schema and specify it directly.
Link: https://patch.msgid.link/20260813145453.1919998-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The original 'offsetof()' + offset is equal to the new 'offsetof()'. Use
the new 'offsetof()' instead.
Rename two variables btw:
* offsetof_num -> num_off
* percpu_data_sum -> sum
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260814173206.93082-6-leon.hwang@linux.dev
Use array_map_mmap_sz() for PERCPU_ARRAY like ARRAY in bpf_map_mmap_sz().
This lets bpf_map__set_value_size() skip mmap(), memcpy(), and munmap()
when the old and new value sizes occupy the same number of pages.
Fix some typos btw:
* mmapble -> mmapable
* satisified -> satisfied
* relocatin -> relocation
* atach_btf_obj_fd -> attach_btf_obj_fd
* len_secnd -> len_second
* precendence -> precedence
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260814173206.93082-3-leon.hwang@linux.dev
I2C clock frequency for HJMC01 is 200MHz, define a new ACPI
HID for it.
Signed-off-by: Xiangyang Yu <hunter.yu@hj-micro.com>
Signed-off-by: Hongnan Li <clarke.li@hj-micro.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260813064025.45242-1-clarke.li@hj-micro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use HZ_PER_MHZ multiplier for fixed_clk_rate values to
improve readability.
Signed-off-by: Hongnan Li <clarke.li@hj-micro.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260813063005.42925-1-clarke.li@hj-micro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
For IPv4 ERSPAN:
In erspan_xmit(), the driver clears IP_TUNNEL_SEQ_BIT (for version 0)
and IP_TUNNEL_KEY_BIT directly in the shared tunnel->parms.o_flags
structure. Since transmit paths can run locklessly and concurrently,
this leads to a data race.
Furthermore, modifying tunnel->parms.o_flags permanently alters the
tunnel configuration. To work around this, erspan_fill_info() (which
reports config to userspace) was setting IP_TUNNEL_KEY_BIT back. If
erspan_fill_info (running under RTNL) and erspan_xmit (running locklessly)
race, erspan_xmit might see IP_TUNNEL_KEY_BIT set when it shouldn't,
leading to GRE header corruption (injecting a key field into the ERSPAN
GRE header).
Fix this by:
1) Passing flags as an argument to __gre_xmit().
2) Using local stack flags in ipgre_xmit(), gre_tap_xmit(), and erspan_xmit()
to prevent TOCTOU data races with concurrent configuration updates,
and passing them to __gre_xmit().
3) Removing the racy modification of t->parms.o_flags in erspan_fill_info().
4) Forcing IP_TUNNEL_KEY_BIT in the reported flags for ERSPAN locally
in ipgre_fill_info().
For IPv6 ERSPAN:
ip6erspan_tunnel_xmit() was locklessly clearing IP_TUNNEL_KEY_BIT in
t->parms.o_flags even though it does not use these flags for building
the GRE header (it uses local flags). This permanently corrupts the
configuration and races with ip6gre_fill_info() which reads it.
Remove the redundant and racy modification.
This should remove false sharing in a fast path.
Add const qualifiers in ipgre_fill_info(), erspan_fill_info()
and ip6gre_fill_info() to clarify that these methods are not
supposed to write any live parameters.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260812142257.21283-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
fcg_cgroup_set_weight() updates cgc->weight and the parent's
child_weight_sum but doesn't bump hweight_gen, so the hweights cached by
cgrp_refresh_hweight() stay stale until some task activation bumps the
generation. For cgroups whose tasks never go through a 0->n runnable
transition (e.g. persistently busy ones), a cpu.weight change never
propagates to scheduling at all.
Bump hweight_gen on weight changes so the next refresh recomputes with
the new weight.
Verified on a flatcg VM: a live cpu.weight 100->800 change on a busy
cgroup leaves HWT update at 0 and the distribution unchanged; with it,
hweight_gen increments and the refresh recomputes.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
The acpi_get_first_physical_node() usage in acpi_create_video_bus_device()
is generally unsafe because in theory the device returned by it may be
freed at any time.
Address this issues by using acpi_bus_get_primary_device() instead of
acpi_get_first_physical_node() and dropping the device reference
acquired by it after registering the child.
Fixes: 6ab3532b4c ("ACPI: video: Switch over to auxiliary bus type")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/10906414.nUPlyArG6x@rafael.j.wysocki
The acpi_get_first_physical_node() usage in acpi_platform_fill_resource()
and acpi_create_platform_device() is generally unsafe because in theory
the device returned by it may be freed at any time [1].
It is also inefficient because acpi_get_first_physical_node() is called
multiple times for the same argument which can be avoided.
Address these issues by using acpi_bus_get_primary_device() instead of
acpi_get_first_physical_node() and adjusting the code to call it just
once at the beginning of and acpi_create_platform_device() and drop
the device reference acquired by it upon the return from that function.
Fixes: 3b95bd1605 ("ACPI: introduce a function to find the first physical device")
Fixes: a252d881c5 ("ACPI / platform: Pay attention to parent device's resources")
Link: https://sashiko.dev/#/patchset/12955541.O9o76ZdvQC%40rafael.j.wysocki [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/3436112.aeNJFYEL58@rafael.j.wysocki
The function used for obtaining the first "physical" device for which
the given ACPI one is the ACPI companion, acpi_get_first_physical_node(),
may return a stale device pointer (mostly in theory) because
acpi_unbind_one() may run as a whole after dropping the ACPI device's
physical_node_lock in acpi_get_first_physical_node() and before it
returns. The last reference to the "physical" device may be dropped
then before the pointer to it is returned to the caller.
If that happens and the acpi_get_first_physical_node() caller invokes
get_device() on the pointer obtained from it, which is done by the
majority of its callers, a use-after-free will occur.
To prepare for addressing this problem, introduce a new function for
getting the first "physical" device associated with the given ACPI one
(the "primary physical device") that will also reference count the
device in question before returning a pointer to it.
Make that new function and acpi_get_first_physical_node() share the
physical node list lookup code.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/2843318.mvXUDI8C0e@rafael.j.wysocki
When device_add() fails after acpi_device_set_name() has allocated an
instance ID and a new acpi_device_bus_id has been linked into
acpi_bus_id_list, the rollback path only removes wakeup_list and
detaches the ACPI handle data.
That leaves the bus-ID bookkeeping behind and keeps the allocated
instance number consumed.
Move the bus-ID cleanup and wakeup-list removal into a single helper.
Use it from both the normal device teardown path and the device_add()
rollback path. The wakeup list node is initialized before registration,
so it can be deleted without checking whether the device is wakeup-
capable like in the original teardown path.
Fixes: d783156ea3 ("ACPI / scan: Define non-empty device removal handler")
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
[ rjw: Rename acpi_device_del_list() to acpi_device_cleanup() ]
[ rjw: Subject and changelog edits ]
Link: https://patch.msgid.link/20260808085943.526-1-getshell@seu.edu.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
modpost has a lot of error logging with module name, but the module name
is logged in a plethora of ways. Add struct module * parameter to
modpost_log(), and wrappers mod_warn() and mod_error(), to allow logging
with a unified module name, if provided.
If the module is provided, the messages will be of the format:
(ERROR|WARNING): modpost: (modname.ko|vmlinux): message
Actual conversion is done separately.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/f27bd8810f0ef12fb86068f0190e4e0afa81e0fa.1786120005.git.jani.nikula@intel.com
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Signed-off-by: Nicolas Schier <nsc@kernel.org>
The Kconfig frontend should render options that depend on a
previous option in the submenu of that previous option. But
currently, this breaks for negative dependencies. For example,
option FOO may be rendered in the submenu of option BAR, despite
FOO actually depending on !BAR.
Let's fix this ironic rendering by modifying Kconfig to explicitly
check negative dependencies.
I've only tested locally on x86, but as far as I can tell, this only
changes how 2 options are rendered in the menu:
1. NTFS3_FS, no longer in the NTFS_FS submenu, and
2. MTD_BLOCK_RO, no longer in the MTD_BLOCK submenu.
Tested-by: Nathan Chancellor <nathan@kernel.org>
Reported-by: Xi Ruoyao <xry111@xry111.site>
Closes: https://lore.kernel.org/all/cbe95c15d2760f6fce8eaf207c969ce8fd3703aa.camel@xry111.site/
Assisted-by: Claude:claude-4.8-opus
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260801145238.2140291-1-julianbraha@gmail.com
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Tested-by: Nicolas Schier <nsc@kernel.org>
Signed-off-by: Nicolas Schier <nsc@kernel.org>
Newer FW reports the SD group size directly in the NIC vport context
via the sd_group_size field, gated by the sd_group_size capability.
Switch sd_init() to source the group size from there and fall back to
the MPIR-based host_buses query only when the cap is absent.
sd_group_size might return 1 in some FW configuration. Add explicit
check to disable SD creation in this case.
While here, rename host_buses to group_size throughout sd.c to follow
the new name on capable FW.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260810093037.3138197-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEjF9xRqF1emXiQiqU1w0aZmrPKyEFAmp6JRsACgkQ1w0aZmrP
KyG/dQ/+IGRY1T2VT0qP0QpQ717Ml0NC7FzWvK6Fn+7U5u0/AbcyDZkBcMLPv7GV
CjIRbHPr6/1PcF+DkJD1shLE/+gPXckcjzVn/Yw9pXMWsbE2nL/4ASWhB/Knji1J
x3hOrRFBOQFOFJZrsI1kzt34MBYQv82NwHSjuWuY00CqaEIMVa0Sn/1BQrUt6qYK
eQaOTVfzf+br7UF5bVUp5irGDlFTpVMSkBxJUtWCez1Bv9R4YGhQt2bIf5vgep1O
zQ5Dx20+3NowpICGUegik06zYiBYG3F4jA/4ut2r2ofq/p+us6KXd/UfdvgKkw2t
XU1A4+OpM4x0RX9Ac12ti8xI3vNQynL8wh8Ag4RIXXaJPEFoU3n+0z+GXOwHZJS9
yhSHOlksCqD4WLXIJKHaF0rFO+++x3TsNP+aBraj3Pz1lHAzyPjIs0FzS0uj6M7e
7CD4tZkuUoiOQ56wrKyl44J1XAt4zIsSvPJ5iYUIDm7SnV/Q6LwuD1mjgL0zo6i8
AJ6QEmhsCVKXcYO2xfPbSNlmBVKqFD7tVefJxadS+MCWA+J5J6Rudy2kMO74eMo/
TKuJeRDsp5oo1uv/zfMv3y6KFOsqLWx9WFu3robvUSsjIlTooDrQcmPjEMfNNskr
nBQjjoLNvWUHQvwEVEB4cS526Qw3a2XGhmht00uXjR93t7+IUgI=
=DxIh
-----END PGP SIGNATURE-----
Merge tag 'nf-next-26-08-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next
Pablo Neira Ayuso says:
====================
Netfilter updates for net
This includes an enhancement to detect ct memleaks easier via
DEBUG_NET and flowtable preparation patches for IPv4 over IPV6
and vice-versa. This also includes a fix for the nft_ct custom
expectation support.
1) Add DEBUG_NET_WARN_ON_ONCE to nf_ct_set() to spot ct memleaks.
2) Pass struct net_device_path_ctx to dev_fill_forward_path() to
make it easier to pass more parameters to this function.
From Lorenzo Bianconi.
3) Add ether_type field to net_device_path context structucture.
4) Rename tun.l3_proto field to tun.inner_proto.
5) Rename ctx.tun.proto to ctx.tun.inner_proto.
6) Store ether_type in flowtable context.
7) Move IPv4 and IPv6 xmit path to a helper function.
8) Move encapsulation header parser out of the flowtable lookup
function.
9) Rework nft_ct custom expectation support to address a possible
reallocation of ct extension area while expectation list also
contains expectations. Move datapath to a ct helper to fix it.
10) Ensure timeout is always lowered for the non-closing RST case
in the TCP connection tracking.
11) Bail out when inserting already dead expectation, this should
not ever happen, hence report it via DEBUG_NET.
12) Comestic updates for improving the conntrack selftest dump and
flush userspace program, from Qingshuang Fu.
* tag 'nf-next-26-08-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
selftests: netfilter: conntrack_dump_flush: remove unused variables and fix typo
netfilter: nf_conntrack_expect: bail out on insert dead expectations
netfilter: conntrack: always lower timeout for non-closing RST packets
netfilter: nft_ct: move custom expectation support to helper
netfilter: flowtable: detach layer 2 encapsulation parser from lookup
netfilter: flowtable: move ipv4 and ipv6 xmit path to function
netfilter: flowtable: store ethertype in flowtable context
netfilter: flowtable: rename ctx.tun.proto to ctx.tun.inner_proto
netfilter: flowtable: rename tun.l3_proto to tun.inner_proto
net: netfilter: add ether_type to net_device_path_ctx and use it
net: pass net_device_path_ctx to dev_fill_forward_path()
netfilter: add DEBUG_NET_WARN_ON_ONCE to skb_set_nfct()
====================
Link: https://patch.msgid.link/20260810194015.932627-1-pablo@netfilter.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
scx_fork() initializes tasks when scx_init_task_enabled is set, but
scx_cancel_fork() only exits them when scx_enabled() is true. A fork
that fails in the enable window (between releasing scx_fork_rwsem and
setting __scx_enabled) runs ops.init_task() but never ops.exit_task().
Gate scx_cancel_fork() on scx_init_task_enabled.
Fixes: 4269c603cc ("sched_ext: Enable scx_ops_init_task() separately")
Cc: stable@vger.kernel.org # v6.12+
Signed-off-by: fangqiurong <fangqiurong@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
The acpi_battery_get_property() callback calls acpi_battery_get_state()
without any lock held. On some devices, it happens that the property
cache has expired before a uevent reaches userspace, triggering
simultaneous attempts to evaluate _BST. See [1] for an analysis to sysrq
stacktraces on one of the these devices.
In a few cases, including when the AML is sleeping or acquiring a mutex,
ACPICA drops the namespace and interpreter locks and allows the
evaluation of _BST to start while another task is still evaluating it.
This could somehow confuse the interpreter and lead to chaos in AML
mutexes on some devices, see [2] for an example.
Not holding the lock is also prone to race conditions, for example:
CPU0 | CPU1
acpi_battery_get_property() |
acpi_battery_get_state() |
[update_time expired] |
extract_package() | acpi_battery_get_property()
battery->update_time = jiffies | acpi_battery_get_state()
kfree() | [up to date]
| [read capacity_now]
[fix capacity_now due to quirk] |
where CPU1 gets raw capacity_now before CPU0 fixes it to a meaningful
value.
The existing mutex update_lock is not applicapable for
acpi_battery_get_property(), as some code path could call or wait for
acpi_battery_get_property() while holding update_lock.
Therefore, introduce a mutex called property_lock to protect all
accesses to battery properties, so that acpi_battery_get_property() can
take the advantage of the mutex and synchronize itself. With the mutex,
acpi_battery_get_state() are synchronized in all code paths calling it,
and its cache mechanism can always clamp the frequency of _BST
evaluations according to cache_time.
The helper function acpi_battery_handle_discharging() for quirky devices
has to be inlined due to the change, as the mutex must be unlocked
before calling the expensive power_supply_is_system_supplied() helper
function.
Fixes: 86bfd21a0b ("ACPI: battery: Drop redundant locking")
Reported-by: Rick <rickk1166@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221065#c85 [1]
Reported-by: Avraham Hollander <anhollander516@gmail.com>
Tested-by: Avraham Hollander <anhollander516@gmail.com>
Closes: https://lore.kernel.org/linux-acpi/CAP1mzZReJCn6df5DwEPu-JCQUyr=Pu1cg5xKCMttWZkHCQtVmQ@mail.gmail.com [2]
Signed-off-by: Rong Zhang <i@rong.moe>
Cc: All applicable <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260809-b4-acpi-battery-notification-v5-1-788d54fa2e35@rong.moe
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- inlines.h: scx_bpf_dispatch() doesn't exist; the comment means
scx_bpf_sub_dispatch()
- internal.h: name %SCX_DEQ_SCHED_CHANGE instead of the never-defined
%SCX_DEQ_SAVE
- internal.h: @name shows up in the ops file in the scheduler's sysfs
directory, not a "kernel.sched_ext_ops" sysctl
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
The events file is under the scheduler's sysfs kobject
(/sys/kernel/sched_ext/root/events for the root scheduler), not the
nonexistent "<scheduler-name>/events" path. Also add the missing "aborting"
line to the scx_show_state.py example.
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
Although 'commit 2feec5ae5d ("accel/qaic: Handle DBC deactivation if the
owner went away")' fixes the scenario it was intended for by walking the
message and only decoding QAIC_TRANS_DEACTIVATE_FROM_DEV, if present, it
skipped over the bounds checking code that is included in decode_message().
This could lead to issues such as reading past the slab allocation's end,
infinite loops or kernel panics. For those issues to happen, a malformed
wire message is needed to be sent from the device.
Instead of duplicating the bounds checking code already present in
decode_message(), use the function inside resp_worker().
Reported-by: Ruikai Peng <ruikai@pwno.io>
Fixes: 2feec5ae5d ("accel/qaic: Handle DBC deactivation if the owner went away")
Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com>
Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260731152344.1905882-1-youssef.abdulrahman@oss.qualcomm.com
One,
Removed the superfluous backticks in the sentence.
And second,
s/peferred/preferred/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260814095716.2905589-1-unixbhaskar@gmail.com>
test_cgcore_lesser_ns_open runs as root throughout and never changes its
euid, so chowning the two cgroup.procs files to a non-root uid has no
effect on the test.
The ENOENT the test expects comes from the cgroup namespace delegation
check in cgroup_procs_write_permission(): the source and destination
cgroups must both be descendants of the namespace root captured at open
time. That check does not depend on file ownership. In addition, the
permission check only examines the common ancestor's cgroup.procs file
(the test root here), which the chown calls do not touch.
Remove the redundant chown calls and the now unused test_euid and
cg_test_a_procs variables.
Signed-off-by: Shaojie Sun <sunshaojie@kylinos.cn>
Reviewed-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
The ROG Ryujin III White Edition uses the same report layout as the
other supported Ryujin III variants. Add its USB device ID and list it
in the driver documentation.
The device was tested with the driver on the author's hardware.
Link: https://github.com/aleksamagicka/asus_rog_ryujin-hwmon/pull/10
Signed-off-by: Will Smith <github@notthatwillsmith.com>
Assisted-by: Codex:gpt-5.6-sol sparse
Signed-off-by: Arie Miller <renari@arimil.com>
Reviewed-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20260812103532.395049-4-renari@arimil.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ROG Ryujin III uses different report offsets and a different
cooler-duty channel from the Ryujin II. It also lacks the separate
external fan controller supplied with the older model.
Add model data and USB IDs for the Extreme and EVA Edition variants.
Skip controller commands and hide the unavailable controller hwmon
channels for these devices. Update the driver documentation, Kconfig
text, and module description accordingly.
Link: https://github.com/aleksamagicka/asus_rog_ryujin-hwmon/pull/9
Assisted-by: Codex:gpt-5.6-sol sparse
Signed-off-by: Arie Miller <renari@arimil.com>
Reviewed-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20260812103532.395049-3-renari@arimil.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Move model-specific report offsets and capabilities into a device
information structure. This prepares the driver for coolers which use
a different report layout or do not include the external fan
controller, while preserving the existing Ryujin II 360 behavior.
Handles an issue reported by Sashiko where an id could
be missing driver_data.
Link: https://lore.kernel.org/r/5a817284-a9f4-48b2-9f0f-802c5dc6963c@roeck-us.net
Assisted-by: Codex:gpt-5.6-sol sparse
Signed-off-by: Arie Miller <renari@arimil.com>
Reviewed-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20260812103532.395049-2-renari@arimil.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
scx_process_sync_ecaps() sets up the dispatch context for
ops.sub_ecaps_updated() in the target cpu's pcpu context recovered from the
llist node. However, the context is per executing cpu: the dispatch kfuncs
resolve it with this_cpu_ptr() and the dispatch buffer lives in it. What the
dispatches target is determined by the rq recorded in the context, not by
which cpu's context it is. Under core scheduling the pick runs balance_one()
for sibling rqs, so a sync processed for a sibling invokes the op with the
executing cpu's context not set up and its dispatch kfuncs misoperate on a
NULL or stale rq.
Set up the executing cpu's dsp_ctx instead, matching scx_dispatch_sched().
The recorded rq keeps the dispatches targeting the synced cpu.
Fixes: b81a6c018c ("sched_ext: Add sub_ecaps_updated() effective-cap change notifier")
Reported-by: David Carlier <devnexen@gmail.com>
Link: https://lore.kernel.org/all/20260813045931.8691-1-devnexen@gmail.com/
Signed-off-by: Tejun Heo <tj@kernel.org>
A handful of small device-specific quirks, regression fixes, and build
fixes. Nothing really stands out.
- Fix for a potential UAF in in USB-audio MIDI2 endpoint handling
- Fix for a mixer regression on SteelSeries Arctis Nova 5 in USB-audio
- ASoC Intel HDMI-In capture, ACPI match table additions and quirks
- ASoC AMD quirk for HyperX OMEN
- Fix for ASoC Xilinx about crash in pcm formatter IRQ handlers
- Fixes for ASoC Realtek rt1320 and rt5645 codecs
- Fixes for ASoC TI tas2781 and tac5xx2-sdw build errors
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmp+2KkOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE+2nRAAtyZCuZHuWm8ws01CDmLH5bthPVwgW0iBjnHy
mEAA0dRhwsa2lxICsAzcO8C1a+vSN3hOeQS0d+YzbCnaATj6sXMEPXDyy2NvGTWA
lRcv4HIIloDvm+cKw10jJp6p8v6n6OqP80ME34cq8c8LpLoiFDq31yGYqVekRJ+6
JyHEfyqzUCRY1wiZ9TEBnoU0I6112jWbQWhgsJxI/ZURXSBZM8r/nXfyg2cqUwIw
8P/TVhouXEvGSCdbOP7J2r3AglLBnjCcUiGx27cY9T9CJWt0hLzeYIclkZBAFIJV
l8VsiaenCNS0fHGr7fBF7gZx1WooO2724bdHxZiHmWkxNe5wOuWrqa2j66BjbiQM
EUrqpwZRO2fOg3/f2odw8VMIn+XWdszNIdDs75EoNTUZdb31sw3Ac/U1j0NBb3n2
vgXgDrZf+FSfxJ3V5+jwwrt5S2cliynj6qGMa3dObCoCP8dRKrqQoTdYMW+uMmTj
nn4bR2kjdudCJKqe6myqr9HWz8dK6XnfJbnUkYX0zBiFWrvy1yecwcyd9PEF2311
xdpdDbCXXBHvCjSo33e4wIhwd+F/tdwtonIbBpo893pC4ZTKL27Ba9quXJwu6xxB
R8MYBz7sRRlLG93a9Dixrxjp0tRrL6ZnmkW7D524rqD786D2W6sR8FpCTp4uCBwz
bkmGkgM=
=+V0F
-----END PGP SIGNATURE-----
Merge tag 'sound-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai"
"A handful of small device-specific quirks, regression fixes, and build
fixes. Nothing really stands out.
- Fix for a potential UAF in in USB-audio MIDI2 endpoint handling
- Fix for a mixer regression on SteelSeries Arctis Nova 5 in
USB-audio
- ASoC Intel HDMI-In capture, ACPI match table additions and quirks
- ASoC AMD quirk for HyperX OMEN
- Fix for ASoC Xilinx about crash in pcm formatter IRQ handlers
- Fixes for ASoC Realtek rt1320 and rt5645 codecs
- Fixes for ASoC TI tas2781 and tac5xx2-sdw build errors"
* tag 'sound-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: Intel: NVL: Add entry for HDMI-In capture support to non-I2S codec boards.
ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers
ASoC: tac5xx2-sdw: select REGMAP_SOUNDWIRE_MBQ
ASoC: rt1320: run the initialisation preset on the first hardware init
ASoC: rt5645: Perform the initial jack detect at probe
ASoC: Intel: sof_rt5682: Add HDMI-In capture with rt5682 support for NVL.
ASoC: Intel: soc-acpi: Add entry for HDMI_In capture support in NVL match table
ASoC: amd: yc: Add DMI quirk for HyperX OMEN Gaming Laptop 16-ap1xxx
ASoC: tas2781: fix clang build error for goto bypassing cleanup variable
ALSA: usb-audio: Fix mixer regression on SteelSeries Arctis Nova 5
ALSA: usb: Fix UAF at delayed release of MIDI2 EPs
ring_buffer_per_cpu::mapped tracks if a ring-buffer is either mapped by
user-space or if it is a persistent buffer. We already have user_mapped
for the former and ring_meta for the latter. Get rid of mapped and
instead create rb_is_static(). A static ring-buffer cannot be resized,
swapped or have its pages extracted.
Link: https://patch.msgid.link/20260813131152.3589632-10-vdonnefort@google.com
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The 'cpus' field in struct trace_buffer became useless in commit
8e7b58c27b ("ring-buffer: Just update the subbuffers when changing their
allocation order"). Remove it
Link: https://patch.msgid.link/20260813131152.3589632-9-vdonnefort@google.com
Fixes: 8e7b58c27b ("ring-buffer: Just update the subbuffers when changing their allocation order")
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The ring buffer order can be dynamically modified and temporarily
disables writing to do so. It is therefore safe to use the updated value
to calculate the maximum event size which can be written onto the ring
buffer.
However, notice it is hardly making any difference for trace_marker
because of the TRACE_MARKER_MAX_SIZE limit. For an 8KiB subbuf size,
trace_marker can take 4096 characters while it can 'only' take 4054
bytes for smaller subbufs.
Link: https://patch.msgid.link/20260813131152.3589632-8-vdonnefort@google.com
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
ring_buffer_alloc_read_page() is racy with ring_buffer_subbuf_order_set,
it can allocate a reader page with an outdated order. This isn't a big
issue, the user can still re-allocate a new reader page and try again.
However, what is more problematic is if the value of subbuf_order
changes in the middle of ring_buffer_alloc_read_page(). In that case,
bpage->order might not match the actual allocated memory.
Use bpage->order for the allocation to prevent this race.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260813131152.3589632-6-vdonnefort@google.com
Fixes: bce761d757 ("ring-buffer: Read and write to ring buffers with custom sub buffer size")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
trace_buffer subbuf_size is read lockless in ring_buffer_read_page() and
ring_buffer_read_start(), while it can simultaneously be resized with
ring_buffer_subbuf_order_set().
Instead of trace_buffer::subbuf_size, use bpage::order in
ring_buffer_read_start() and ring_buffer_read_page().
In ring_buffer_read_start(), even with resize_disabled, there is still a
possibility of a race with a buffer modification. Hold the trace_buffer
mutex to synchronise with any pending ring buffer order modification.
trace_buffer::subbuf_size is now actually useless, remove it. Also,
create accessors rb_subbuf_capacity() and rb_page_capacity() which
return the actual size available for storing events, while
rb_subbuf_size() returns the actual subbuf page-size.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260813131152.3589632-5-vdonnefort@google.com
Fixes: f9b94daa54 ("ring-buffer: Set new size of the ring buffer sub page")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260805153225.2096152-1-vdonnefort%40google.com # patch 1
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
CEPH_IOC_SET_LAYOUT{,_POLICY} ioctl permissions check that went into
-rc5 and a userspace compatibility fixup. The rest mostly harden
against malformed network input. All marked for stable.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEydHwtzie9C7TfviiSn/eOAIR84sFAmp/SyQTHGlkcnlvbW92
QGdtYWlsLmNvbQAKCRBKf944AhHzi+OMB/9DOUyMrxqGptG9BhzMmHPIMNE7PI+m
jHh0zEnMsE2rKaYfkLNf/p7RrcvcK4PSMCYZKXSUx0D6n3PoEccDW/JTC/rro5B/
3fZIAaZBg8B25o6b0uGjO29e7BY+WouoNAC6fU9F/DtVTnYp4bk40DsvQS6pvFiN
K2sVLIsSBhDZ7czmVlMlpc/er64TRYnWGmaxaAPMuiW5HEhWxvFDav3/r3gsP/fk
mFJ5QU4qcq/q0QmMW7gO9Q+GXjOK2+9eaplNF3wCOSdHIF2nX5knbvgu5n7a4Qoh
GNf0ak7PfFCzUoRdC/4XkMRQAO9IYgzq45EivApJQKvKmETWrzFLQ1uP
=pOld
-----END PGP SIGNATURE-----
Merge tag 'ceph-for-7.2-rc8' of https://github.com/ceph/ceph-client
Pull ceph fixes from Ilya Dryomov:
"A handful of tiny fixes, with the main ones being a follow-up for
CEPH_IOC_SET_LAYOUT{,_POLICY} ioctl permissions check that went into
rc5 and a userspace compatibility fixup. The rest mostly harden
against malformed network input. All marked for stable"
* tag 'ceph-for-7.2-rc8' of https://github.com/ceph/ceph-client:
ceph: use the mount idmap for the owner checks in the SET_LAYOUT ioctls
ceph: fix MDS random selection readiness predicate
libceph: Avoid using invalid osd indices from primary_temp
libceph: fix OOB read in decode_watchers() via missing bounds check
libceph: fix multiple unsafe decodes in decode_locker()
libceph: tolerate addrvecs with multiple entries of the same type
Discarding a cached reader page after a concurrent ring buffer resize
uses the new global subbuf_order for the free_pages() call. This
mismatched order may crashes the kernel or leaks memory because the cached
page was allocated under the old size.
Save the actual free_page order alongside the page address to ensure we
always refer to the correct value and do not rely on the potentially
stalled cpu_buffer->subbuf_order value. The simplest is to make
free_page a buffer_data_read_page which already covers exactly what we
need: a page address and a page order.
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260813131152.3589632-4-vdonnefort@google.com
Fixes: 8e7b58c27b ("ring-buffer: Just update the subbuffers when changing their allocation order")
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
On RV64, the ABI requires sign-extension for signed 1-byte and 2-byte kfunc
args. However, the RV64 JIT currently does not perform sign-extension for
such kfunc args.
Before commit 7ce090afbf ("bpf: Infer zext_dst based on static register
liveness analysis"), state pruning could potentially omit zero-extension
of 32-bit subregisters, which inadvertently masked the above issue by making
the args appear as if they had been properly sign-extended. After that
commit, the problem is exposed, causing the kfunc_call/kfunc_call_test4
selftest to fail.
Fix this by extending the existing sign-extension logic to handle signed
1-byte and 2-byte kfunc args as well.
Fixes: 443574b033 ("riscv, bpf: Fix kfunc parameters incompatibility between bpf and riscv abi")
Signed-off-by: Pu Lehui <pulehui@huawei.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20260814064726.3607615-1-pulehui@huaweicloud.com
arm64 passes zero as the stack pointer while walking BPF frames, so
bpf_throw() leaves stale KASAN stack poison after jumping to the
exception callback.
Use the frame pointer as the fallback stack watermark.
Fixes: e74cb1b422 ("arm64: stacktrace: Implement arch_bpf_stack_walk() for the BPF JIT")
Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Link: https://lore.kernel.org/bpf/20260812-hello_world-v1-1-c3c2ddcb362d@meta.com
pyperf600 has been running into 8K BPF_COMPLEXITY_LIMIT_JMP_SEQ limitations
for a long while now, after some internal compiler changes.
Until BPF verifier is bestowed with scalar evolution logic, make that test
actually work by doing what would anyone should do in such situations: by
moving repeatable per-iteration work into independently verified global
functions.
`void *` argument is a problem for global funcs, but a static function wrapper
doing necessary casts and a bit of __arg_nonnull magic dust is all it takes.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Tested-by: Pu Lehui <pulehui@huawei.com> # riscv
Reviewed-by: Pu Lehui <pulehui@huawei.com>
Link: https://lore.kernel.org/bpf/20260813232943.581283-1-andrii@kernel.org
lwt_ip_encap hardcodes the ping6 binary for its IPv6 pings. iputils
merged ping6 into ping long ago and distros have started dropping the
compat symlink -- Arch's iputils 20250605 ships only arping, clockdiff,
ping and tracepath. There, every lwt_ip_encap subtest fails:
check_ping_ok:FAIL:ip netns exec ns-lwt-ip-encap-1-0101330 ping6 -c 1 \
-W1 -I veth1 fb04::1 > /dev/null unexpected error: 256 (errno 2)
#217/1 lwt_ip_encap_ipv4/egress:FAIL
The IPv4 subtests fail too, because check_ping_ok() pings both families.
SYS() runs the command through system(), so a missing binary is
indistinguishable from an unreachable peer.
network_helpers.c has had ping_command() for exactly this since commit
372642ea83 ("selftests/bpf: Move netcnt test under test_progs"): it
falls back to "ping -6" when ping6 is not present. lwt_ip_encap.c is the
last hardcoded ping6 user. Fix that.
Fixes: f5e288943e ("selftests/bpf: Move test_lwt_ip_encap to test_progs")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Song Liu <song@kernel.org>
Link: https://lore.kernel.org/bpf/20260813213558.3103179-1-andrii@kernel.org
Honghui Jiang <jiang_hh2019@163.com> says:
A partial DMA mapping failure can leave per-transfer mapping flags set
while cur_{tx,rx}_dma_dev are NULL or still refer to the devices used
for an earlier message. The subsequent cleanup may then unmap a
transfer with a NULL or stale device.
Before commit e289df8234 ("spi: Rework per message DMA mapped flag to
be per transfer"), partial-failure handling was already incomplete, but
__spi_unmap_msg() was gated by cur_msg_mapped, which was set only after
the whole message mapped successfully. Earlier mappings could leak, but
cleanup could not unmap them with an unpublished device. The
per-transfer conversion removed that gate: mapping flags can now remain
set while cur_{tx,rx}_dma_dev are still unpublished, turning the leak
into a NULL- or stale-device unmap regression.
Patch 1 publishes the mapping devices before the loop and unwinds every
failure through __spi_unmap_msg(). It keeps the forward declaration so
it is independently buildable and straightforward to backport. Patch 2
then removes the declaration by moving __spi_unmap_msg() above
__spi_map_msg(). Patch 3 clears the current DMA device pointers once the
message has been unmapped, while leaving them intact during partial-map
unwind and DMA-to-PIO fallback. Patch 4 adds the DMA mapping KUnit suite
as a separate translation unit.
Only patch 1 is a stable candidate; patches 2 through 4 are follow-up
cleanup and test changes for mainline.
Testing:
- Patch 1 builds independently with the x86_64 reproducer configuration.
- The spi_dma KUnit suite passes all four cases on x86_64 and UML.
Moving the DMA device assignments back after the mapping loop makes
both failure-path cases fail.
- The default and all-tests KUnit configurations both select the suite.
- All four reproducer cases complete without an oops when run as the
first message, and map/unmap counts are balanced after a successful
first message.
- After message cleanup, cur_{tx,rx}_dma_dev are NULL.
v1: https://lore.kernel.org/r/20260805151456.756579-1-jiang_hh2019@163.com
Link: https://patch.msgid.link/20260814031419.43378-1-jiang_hh2019@163.com
Add KUnit tests for the __spi_map_msg() error paths. The tests verify
that a later TX or RX mapping failure clears the mapping state of
earlier transfers and leaves cur_{tx,rx}_dma_dev identifying the
current mapping device.
A zero-length transfer causes sg_alloc_table() to return -EINVAL,
providing deterministic failure injection without test hooks.
Additional cases cover successful map/unmap and a message which
requires no mapping.
Build the DMA suite as a separate translation unit, exposing the two
internal mapping helpers only for KUnit through the local internal
header. Enable SPI in the default and all-tests KUnit configurations so
the suite is exercised there.
Signed-off-by: Honghui Jiang <jiang_hh2019@163.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260814031419.43378-5-jiang_hh2019@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The current DMA device pointers remain set after a message has been
unmapped. Existing users either check the corresponding mapped flag or
access the pointers before finalizing the message, but retaining stale
device pointers is fragile.
Clear both pointers in spi_unmap_msg() after the internal unmap
completes. Keep them intact in __spi_unmap_msg(), since that helper is
also used during partial-map unwind and the in-message DMA-to-PIO
fallback, before processing of the current message is complete.
Suggested-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Honghui Jiang <jiang_hh2019@163.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260814031419.43378-4-jiang_hh2019@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move __spi_unmap_msg() above __spi_map_msg() so the mapping error path
can call it without a forward declaration. This is a code-only
relocation with no functional change.
Suggested-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Honghui Jiang <jiang_hh2019@163.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260814031419.43378-3-jiang_hh2019@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
