| Age | Commit message (Collapse) | Author |
|---|
|
It is calling snd_soc_component_initialize() / snd_soc_add_component().
We can now use snd_soc_register_component() instead.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/87o6fyrz7h.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
It is calling snd_soc_component_initialize() / snd_soc_add_component().
We can now use snd_soc_register_component() instead.
It is using container_of() to get avs_soc_component from component, but
will not be able to use it when capsuling has done.
We can now use snd_soc_component_to_priv() instead.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/87pl0erz7k.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
struct snd_soc_component will be capsuled soon, its member will not be
able to access from non soc-component.c.
Basically, each drivers are using dev_{set/get}_drvdata() to set own data,
but it is not enough. Let's add .priv.
Add snd_soc_component_{set/to}_priv() to access priv.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/87qzkurz7o.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
struct snd_soc_component will be capsuled soon, its member will not be
able to access from non soc-component.c.
Add snd_soc_component_{set_}name() to access name.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/87se5arz7s.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We have snd_soc_register_component() (A), but we can't setup component
specific setting, like name, etc from driver, because component
itself is allocated in that function (x).
(A) int snd_soc_register_component(...)
{
...
(x) component = devm_kzalloc(...);
if (!component)
return -ENOMEM;
(B) ret = snd_soc_component_initialize(...);
if (ret < 0)
return ret;
(C) return snd_soc_add_component(...);
}
So each driver needs to use snd_soc_component_{initialize/add}() (= B/C)
instead of using snd_soc_register_component() (A), but it looks
unbalanced with its paired unregiser function.
Let's merge (B) and (C) into new register function, and allows component
as parameter. We can use both
snd_soc_register_component(dev, ...); // already exists
snd_soc_register_component(component, ...); // new function
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/87tspqrz7w.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
struct snd_soc_component will be capsuled soon, then, we will can't alloc
it. Adds snd_soc_component_alloc() to alloc it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/87v7a6rz80.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
soc_component_field_shift() is used from
snd_soc_component_{read/write}_field(). It is better to located around
them.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/87wlumrz83.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
IFLA_MACVLAN_BC_QUEUE_LEN accepts any u32 and becomes
port->bc_queue_len_used, the only bound on port->bc_queue. rtnetlink checks
CAP_NET_ADMIN against the target netns only, so a user who unshares a
user+net namespace, creates a veth and puts a macvlan on it can set the
backlog to 0xffffffff and flood broadcast frames until the host dies:
Out of memory: Killed process 141 (su) UID:0
Kernel panic - not syncing: System is deadlocked on memory
Call Trace:
vpanic (kernel/panic.c:650)
panic (kernel/panic.c:787)
out_of_memory (mm/oom_kill.c:1166)
__alloc_frozen_pages_noprof (mm/page_alloc.c:4914)
alloc_pages_mpol (mm/mempolicy.c:2490)
folio_alloc_noprof (mm/mempolicy.c:2591)
filemap_fault (mm/filemap.c:3565)
A fixed upper bound does not work. Deployments carrying 600-800 real-time
audio streams run bc_queue_len=100000, and no constant serves both cases:
the queue counts skbs, not bytes, and the frame size is attacker-chosen too
(up to ETH_MAX_MTU on a veth the caller creates).
Gate the elevated range on CAP_NET_ADMIN in the initial user namespace
instead. A backlog of that size is a host-wide tuning decision, and an
unprivileged owner of a namespace it created itself should not be able to
make it; privileged configurations keep working unchanged..
Cc: stable+noautosel@kernel.org # local DoS by userns are a dime a dozen
Reported-by: AutonomousCodeSecurity@microsoft.com
Link: https://lore.kernel.org/r/20260706212556.3199234-1-xmei5@asu.edu
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Link: https://patch.msgid.link/20260729200621.2521588-1-xmei5@asu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
A potential invalid storage access issue can occur after replacing a
cgroup bpf prog.
This occurs in the following scenario:
1. prog1 with storage is attached to a cgroup in multi-attach mode.
2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach
mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or
update_effective_progs).
3. A new prog3 is attached to the cgroup in multi-attach mode.
The reason is that __cgroup_bpf_attach overwrites pl->storage with the
new storage prior to attachment completion. When attachment fails
midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to
free the newly allocated storage, but fails to restore pl->storage back
to old_storage.
Consequently, the still-active prog1 holds invalid or dangling storage
pointers, leading to an invalid memory access when prog1 executes and
calls bpf_get_local_storage. Additionally, original pl->flags and
cgrp->bpf.flags[atype] are left unrestored.
Fix this by saving old_pl_flags, old_storage, and old_flags prior to the
update, and properly restoring all of them in the cleanup path on error.
Fixes: 7d9c3427894f ("bpf: Make cgroup storages shared between programs on the same cgroup")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260803013934.4036646-1-pulehui@huaweicloud.com
|
|
When a TRANS2 response is split across multiple secondary packets,
coalesce_t2() assembles the payload into the large response buffer.
Two bugs cause SendReceive() to copy only a small fraction of the
assembled buffer into the caller's output buffer.
This manifests when listing a large directory on an SMB1 share
(observed against Windows XP); the first getdents returns only
partial results, and subsequent getdents returns EINVAL.
Bug 1: coalesce_t2() computes the coalesced size as:
*pdu_len += total_in_src;
cifs_demultiplex_thread() resets *pdu_len to each secondary's own
pdu_length before calling coalesce_t2(), so this accumulates from
the wrong baseline on every secondary after the first.
Bug 2: after reassembly, cifs_demultiplex_thread() sets
mid->resp_buf_size to the final secondary's raw packet size. This
value is later used as the memcpy length, so only a portion of the
coalesced response is copied.
Fix both by replacing the stale *pdu_len arithmetic with
smbCalcSize(), which reads the BCC field that coalesce_t2()
maintains correctly throughout reassembly.
Fixes: 83bfbd0bb902 ("cifs: Remove the RFC1002 header from smb_hdr")
Cc: stable@vger.kernel.org
Signed-off-by: Frank Sorenson <sorenson@redhat.com>
Reviewed-by: Paulo Alcantara <pc@manguebit.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
Use devm_spi_alloc_host() instead of spi_alloc_host() so that the spi
controller is automatically freed on probe failure or device removal.
This lets us eliminate the err_put_host label and goto error path in
probe, as well as the spi_controller_put() call in remove.
It's also a bit weird as everything in probe is using devm except the
first allocating function. Might fix an ordering issue on teardown.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260727201543.18857-1-rosenp@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
I'm transitioning to a new email, add mapping and update MAINTAINERS
entries to keep email up to date.
Signed-off-by: Maxwell Doose <maxwell@maxwelld.cc>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The enable_mask struct member keeps track of which sensors are enabled in
the IMU. When enabling and disabling the sensor fusion functionality, the
driver does not properly update this struct member. This prevents a correct
calculation of the number of samples that should be read from the hardware
FIFO; as a result, reads from the FIFO can be unnecessarily split into
multiple transactions, some of which can read past the FIFO length.
Fixes: cd4e1141bff8 ("iio: imu: st_lsm6dsx: Add support for rotation sensor")
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The write_raw callback is documented to return 0 on success or a
negative error code. However, the IIO_CHAN_INFO_CALIBSCALE case
returns 'val' (the user-supplied value) instead of 0.
Fix it by returning 0 on success, matching the behavior of other
calibscale implementations in the subsystem.
Fixes: 971672c0b3cc ("iio: add Capella CM32181 ambient light sensor driver.")
Signed-off-by: Giorgi Tchankvetadze <giorgi@tchankvetadze.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Add a driver for the Sensirion SLF3S family of digital
liquid-flow sensors on I2C. Currently supported variants are
SLF3S-0600F, SLF3S-1300F and SLF3S-4000B; they share the same
register map and differ only in flow-scale factor and calibrated
measurement range. The variant (and therefore the scale) is
auto-detected from the product-information register at probe time;
a sensor reporting an unknown sub-type falls back to the variant
named in the device tree / I2C table, so a drop-in replacement part
keeps working on a kernel that does not know its sub-type yet.
Each measurement frame returns a 16-bit signed flow value, a
16-bit signed temperature reading and a status word, each
protected by a CRC-8 byte. The driver exposes the flow rate as
IIO_VOLUMEFLOW and the temperature as IIO_TEMP via the standard
IIO read_raw / read_scale interface.
The volume-flow scale is reported in m^3/s. As the per-LSB scale
is on the order of 1e-12 m^3/s, it is emitted as a 64-bit
fixed-point value with femto (1e-15) resolution
(IIO_VAL_DECIMAL64_FEMTO) so the small SI value keeps full
precision. This relies on the IIO_VAL_DECIMAL64_FEMTO format type
added earlier in this series.
The active calibration medium can be switched at runtime between
the factory-calibrated water and isopropyl-alcohol modes via the
in_volumeflow_medium sysfs attribute; the sensor starts in water
mode after probe.
The sensor has no low-power state of its own, so system suspend
stops the measurement and disables the vdd supply; resume powers
the sensor back up, waits out the power-up time and restarts the
measurement with the previously active medium, following the
scd30/scd4x precedent.
This driver also creates the drivers/iio/flow/ subdirectory and
the corresponding Kconfig/Makefile glue.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Extend the IIO_VAL_DECIMAL64_* family with a femto-scaled variant
(scale 15), following the existing MILLI/MICRO/NANO/PICO pattern. Both
the read formatting path in __iio_format_value() and the write parsing
path in iio_write_channel_info() (via kstrtodec64()) already derive
their scale from "type - IIO_VAL_DECIMAL64_BASE", so the new type only
needs to be added to the respective switch cases.
This is needed by drivers reporting very small SI quantities where the
existing pico scale loses precision. For example the Sensirion SLF3S
liquid flow sensor reports its volume-flow scale in m^3/s, where the
SLF3S-0600F scale is ~1.667e-12 m^3/s: at pico scale only a single
significant digit survives, whereas femto scale preserves the full
sensor resolution.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Reviewed-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Document the bindings for the Sensirion SLF3S family of digital
liquid-flow sensors on I2C. The family currently covers the
SLF3S-0600F, SLF3S-1300F and SLF3S-4000B variants.
All variants share the same register map and differ only in the flow
scale factor and the calibrated measurement range, which the driver
reads back from the product-information register. Since that lookup
is needed in any case, a fallback compatible would buy nothing, so
each variant gets its own compatible without a fallback. A future
drop-in compatible part can then claim one of these compatibles and
work on kernels that do not know its product ID yet.
The active calibration medium (water / IPA) is runtime-switchable
via the in_volumeflow_medium sysfs attribute and therefore not a
DT property.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Add a new IIO channel type for liquid volumetric flow sensors. The
unit exposed via the standard _scale attribute is cubic metres per
second (m^3/s), following the SI convention used by the other IIO
channel types.
Update iio-core's name table, the iio_event_monitor whitelist and
the sysfs-bus-iio ABI document to match. The new _scale attribute is
folded into the existing shared _scale block; only the per-type _raw
needs a fresh entry.
Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Build xskxceiver, xdp_hw_metadata, and xdp_features from explicit source
lists instead of reusing helper objects produced by test_progs rules.
Reusing shared objects such as network_helpers.o and xsk.o can pull in
test_progs-only dependency chains and trigger unrelated libarena builds
when invoking a single target.
Keep these standalone binaries self-contained so each target builds only
its own required sources and BPF skeleton dependencies.
Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Tested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20260728115036.2049536-1-tushar.vyavahare@intel.com
|
|
table->offset[i] is a u32 from firmware, but was stored into a signed
int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes
before the table buffer. The subsequent avail check was bypassed
because the negative int was promoted to a large size_t in the
expression "table_sz - offset - sizeof(*hdr)", yielding a large positive
avail and letting the out-of-bounds hdr->type read proceed undetected.
Store the offset as u32 and validate it with unsigned comparisons before
any pointer arithmetic.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Fixes: fd2c15ec1dd3 ("remoteproc: resource table overhaul")
Link: https://lore.kernel.org/r/20260803114331.3277263-6-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
rsc_table.h contains the full BSD-3-Clause license blurb but is missing
an SPDX-License-Identifier tag.
Replace the BSD-3-Clause license blurb with the SPDX-License-Identifier
tag, the standard kernel representation, avoiding duplicate license text.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260803114331.3277263-5-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
remoteproc.h contains the full BSD-3-Clause license blurb but is missing
an SPDX-License-Identifier tag.
Replace the BSD-3-Clause license blurb with the SPDX-License-Identifier
tag, the standard kernel representation, avoiding duplicate license text.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260803114331.3277263-4-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The function pointer declarations for find_loaded_rsc_table() and
get_loaded_rsc_table() had their opening parenthesis at the end of
the line. Move the first argument onto the same line as the opening
parenthesis to fix the checkpatch warning.
Also remove a spurious blank line after the opening brace in
struct rproc_vdev.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260803114331.3277263-3-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
include/linux/rsc_table.h was split out from include/linux/remoteproc.h
to hold the resource table wire-format definitions. Add it to the
REMOTEPROC entry so it is covered by the same maintainers.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260803114331.3277263-2-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
In lm25066_probe(), the PMBus coefficients for current and power are
scaled based on the shunt resistor value. The calculation evaluates the
multiplication using 32-bit arithmetic because info->m is an int and
shunt is a u32:
static int lm25066_probe(struct i2c_client *client) {
...
info->m[PSC_CURRENT_IN] = info->m[PSC_CURRENT_IN] * shunt / 1000;
info->m[PSC_POWER] = info->m[PSC_POWER] * shunt / 1000;
...
}
For large coefficients like 26882 (LM25056) or 15076 (LM5066i), a device
tree shunt-resistor-micro-ohms value exceeding approximately 159,000
(159 mOhm, which is physically valid for low-current applications) causes
the intermediate product to exceed UINT_MAX (4,294,967,295). This results
in a silent wraparound before the division by 1000.
Furthermore, if the wrapped value has the most significant bit set,
converting it back to the signed int info->m results in negative
coefficients. This logic error leads to drastically corrupted current and
power readings, which can cause erratic thermal or power management
behavior in the system.
Fix the problem by using 64-bit operations for the multiply/divide
operations. This can still overflow, but only for unreasonably large
shunt resistor values.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 94ee5fcc240fe ("hwmon: (pmbus/lm25066) Support configurable sense resistor values")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
proc_bus_pci_read() decides how much of the config space is readable based
on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling
read(), not the credentials of the process that opened the file.
The sysfs equivalent, pci_read_config(), has checked the credentials of the
opening process since commit de139a339395 ("pci: check caps from sysfs file
open to read device dependent config space"), so a privileged process can
open the config space file and pass the file descriptor to an unprivileged
process (for example, a process running a KVM guest with an assigned
device), which can then read the entire config space. The check was
subsequently routed through the LSM framework in commit 47970b1b2aa6 ("pci:
use security_capable() when checking capablities during config space read")
and converted to the dedicated helper in commit ab0fa82b2df9 ("pci-sysfs:
use proper file capability helper function").
Thus, the two interfaces check the same capability against different
credentials. Checking the credentials of the task calling read() makes the
outcome depend on who reads rather than who opened, so the restriction is
bypassed whenever a more privileged process reads through the descriptor.
Checking the credentials recorded in file->f_cred settles the decision at
open() time and ties it to the file, where it cannot change with the
caller.
Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in
effect when the file was opened, bringing the procfs interface in line with
the sysfs behaviour.
As a result, a file descriptor opened by a privileged process and passed to
an unprivileged one now allows the entire config space to be read through
procfs, matching sysfs.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260720204145.1500105-1-kwilczynski@kernel.org
|
|
Currently, a driver can claim a region of a device's config space as
exclusive using pci_request_config_region_exclusive(), after which a write
to that region originating from user space is expected to emit a warning
and taint the kernel. The check is advisory only, as the write itself is
still allowed to proceed.
Since commit 278294798ac9 ("PCI: Allow drivers to request exclusive config
regions"), the sysfs config space attribute performs this check in
pci_write_config(), but the procfs interface was never updated. A write
performed through /proc/bus/pci/BB/DD.F therefore bypasses the detection
entirely, even though both interfaces offer the same level of access.
Add the same resource_is_exclusive() check to proc_bus_pci_write().
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260729075413.1215821-1-kwilczynski@kernel.org
|
|
Currently, proc_bus_pci_read() and proc_bus_pci_write() do not return early
for zero-length configuration space accesses at valid offsets.
Such an access invokes pci_config_pm_runtime_get() and
pci_config_pm_runtime_put() around transfer blocks that do nothing.
This is a problem because pci_config_pm_runtime_get() synchronously resumes
the upstream bridge through pm_runtime_get_sync(), and resumes the device
itself through pm_runtime_resume() when it is in D3cold, only for the
handler to return zero immediately afterwards. Such a spurious wakeup
wastes power and adds needless resume latency.
The sysfs core already returns early for in-range zero-length binary
attribute accesses before pci_read_config() or pci_write_config() is
invoked. In contrast, the VFS forwards zero-length requests to the procfs
callbacks, where they continue into runtime PM handling.
Return early from proc_bus_pci_read() and proc_bus_pci_write() when nbytes
is zero, before any runtime PM involvement.
The value returned to userspace at these offsets remains zero,
so the change is not visible to userspace.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: order tags]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260729075909.1219906-1-kwilczynski@kernel.org
|
|
Currently, the static binary attributes for the PCI legacy I/O port
and ISA memory space files (legacy_io, legacy_io_sparse, legacy_mem and
legacy_mem_sparse) are open-coded, with each definition repeating the
same set of properties and callbacks.
Add two macros for declaring such attributes:
- pci_legacy_resource_io_attr(), for legacy I/O port space (read/write)
- pci_legacy_resource_mem_attr(), for legacy memory space (mmap)
Each macro takes the fixed attribute size as a parameter.
Then replace the open-coded definitions with the newly added macros.
No functional changes intended.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: shorten macros to fit in 80 columns]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260721020427.1541197-4-kwilczynski@kernel.org
|
|
I hit the following on one of my machines:
mce: CPU0 BANK15 CMCI inherited storm
------------[ cut here ]------------
ODEBUG: assert_init not available (active state 0) object: (____ptrval____) object type: timer_list hint: 0x0
WARNING: lib/debugobjects.c:632 at debug_object_assert_init+0x178/0x230, CPU#0: swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5 #3 PREEMPTLAZY
RIP: 0010:debug_object_assert_init+0x18f/0x230
Call Trace:
<TASK>
__mod_timer
mce_timer_kick
cmci_discover
intel_init_cmci
mce_intel_feature_init
mcheck_cpu_init
identify_cpu
identify_boot_cpu
arch_cpu_finalize_init
start_kernel
A second splat follows right after, from timer_setup() finding that same
timer already queued:
ODEBUG: init active (active state 0) object: (____ptrval____) object type: timer_list hint: stub_timer+0x0/0x10
This is happening because CMCI storm detection is trying to modify the timer
before latter was properly set up.
Set up the timer first. __mcheck_cpu_setup_timer() only calls timer_setup(),
and depends on neither the generic nor the vendor init.
[ bp: Massage commit message. ]
Fixes: 1f68ce2a0272 ("x86/mce: Handle Intel threshold interrupt storms")
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260803-mce_timer_init-v1-1-9539db424330@debian.org
|
|
Currently, the __pci_dev_resource_attr() helper macro takes the attribute
name suffix as its third parameter, even though the suffix is what
distinguishes the three attribute variants built on top of it.
Additionally, the pci_dev_resource_attr() wrapper passes an empty suffix,
and with the suffix placed in the middle of the parameter list its
invocation contains two consecutive commas, which checkpatch.pl highlights,
as follows:
ERROR: space required after that ',' (ctx:VxO)
Move the suffix to the front so that the variant selector comes first and
the empty argument follows the opening parenthesis, which checkpatch.pl
does not complain about. This also matches the parameter order used by the
PCI legacy I/O and memory attribute macros introduced in a subsequent
change.
No functional changes intended.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260721020427.1541197-3-kwilczynski@kernel.org
|
|
Currently, the static binary attributes for the PCI resource files are
generated with the names dev_resource<N>_io_attr, dev_resource<N>_uc_attr
and dev_resource<N>_wc_attr.
The macros that generate these attributes and the arrays that collect them
already carry the pci_ prefix, as do the sibling legacy I/O and memory
attributes, such as pci_legacy_io_attr. Only the generated variable names
lack it.
Rename the generated variables to pci_dev_resource<N>_io_attr,
pci_dev_resource<N>_uc_attr and pci_dev_resource<N>_wc_attr, and update the
attribute pointer arrays to match.
While at it, re-align the continuation backslashes in the resource
attribute macros to match.
No functional changes intended.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: shorten pci_dev_resource##_bar##_wc_attr to fit in 80 columns]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260721020427.1541197-2-kwilczynski@kernel.org
|
|
Currently, the legacy I/O and memory sysfs handlers do not check
security_locked_down(LOCKDOWN_PCI_ACCESS), leaving the legacy_io and
legacy_mem files unprotected when the kernel is locked down.
Commit eb627e17727e ("PCI: Lock down BAR access when the kernel is locked
down") added the check to pci_write_config(), pci_mmap_resource(), and
pci_write_resource_io() to prevent userspace from programming DMA-capable
hardware that could be used to modify kernel code, but did not cover the
legacy handlers.
As a result, root can still write arbitrary I/O ports and map the legacy
I/O and memory spaces while the kernel is locked down, which is the same
capability the lockdown is meant to remove.
Add the same check to pci_write_legacy_io(), pci_mmap_legacy_mem(), and
pci_mmap_legacy_io().
These generic handlers cover both architectures that define HAVE_PCI_LEGACY
(such as Alpha and PowerPC).
Fixes: eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down")
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: add Link]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260720211541.1509744-1-kwilczynski@kernel.org
|
|
Currently, mmap() of a resourceN file for an I/O BAR fails with -ENODEV on
architectures where arch_can_pci_mmap_io() is 0, such as x86, because the
attribute has no mmap callback there and the error comes from the generic
kernfs dispatch.
This is a side effect of commit e854d8b2a82e ("PCI: Add
arch_can_pci_mmap_io() on architectures which can mmap() I/O space"),
which removed the mmap callback from the I/O resource attribute on
these architectures. Previously the request reached the architecture
mmap code and failed with -EINVAL, and the same commit deliberately
kept -EINVAL for the identical operation on the procfs interface, so
the two PCI userspace interfaces have disagreed ever since.
Add a pci_mmap_resource_io_unsupported() callback that
returns -EINVAL and use it as the mmap handler of the I/O resource
attribute when arch_can_pci_mmap_io() is 0, so the failure is
produced deliberately by PCI code, consistent with the procfs
interface and with the behaviour before e854d8b2a82e.
Architectures where arch_can_pci_mmap_io() is non-zero keep the real
pci_mmap_resource_uc() handler and are unaffected. The mmap() fails
either way. Only the reported error changes from -ENODEV to -EINVAL.
Fixes: e854d8b2a82e ("PCI: Add arch_can_pci_mmap_io() on architectures which can mmap() I/O space")
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260720204624.1503794-1-kwilczynski@kernel.org
|
|
Currently, the boundary checks in pci_read_config() and pci_write_config()
reject only offsets beyond the effective configuration space size.
An access at an offset exactly equal to that size passes the check, has its
length clamped to zero, and then invokes pci_config_pm_runtime_get() and
pci_config_pm_runtime_put() around transfer blocks that do nothing.
This is a problem because pci_config_pm_runtime_get() synchronously resumes
the upstream bridge through pm_runtime_get_sync() and resumes the device
itself through pm_runtime_resume() when it is in D3cold, only for the
handler to return zero immediately afterwards. Such a spurious wakeup
wastes power and adds needless resume latency.
The sysfs core already clamps accesses against the attribute size set
through the bin_size() callback, which reports either 256 or 4096 bytes.
As such, the affected accesses are reads at offset 64 (or 128 for CardBus
devices) through files opened without CAP_SYS_ADMIN, and reads and writes
at the exact configuration space size on devices where a quirk sets a
non-standard size.
Reject accesses at the boundary offset as well, so they return early before
any runtime PM involvement, matching the procfs implementations in
proc_bus_pci_read() and proc_bus_pci_write().
The value returned to userspace at these offsets remains zero, so the
change is not visible to userspace.
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
[bhelgaas: tweak commit log, order tags]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260720204356.1501749-1-kwilczynski@kernel.org
|
|
The KVM clock is an interesting thing. It is defined as "nanoseconds
since the guest was created", but in practice it runs at two *different*
rates — or three different rates, if you count implementation bugs.
Definition A is that it runs synchronously with the CLOCK_MONOTONIC_RAW
of the host, with a delta of kvm->arch.kvmclock_offset.
But that version doesn't actually get used in the common case, where the
host has a reliable TSC and the guest TSCs are all running at the same
rate and in sync with each other, and kvm->arch.use_master_clock is set.
In that common case, definition B is used: There is a reference point in
time at kvm->arch.master_kernel_ns (again a CLOCK_MONOTONIC_RAW time),
and a corresponding host TSC value kvm->arch.master_cycle_now. This
fixed point in time is converted to guest units (the time offset by
kvmclock_offset and the TSC Value scaled and offset to be a guest TSC
value) and advertised to the guest in the pvclock structure. While in
this 'use_master_clock' mode, the fixed point in time never needs to be
changed, and the clock runs precisely in time with the guest TSC, at the
rate advertised in the pvclock structure.
The third definition C is implemented in kvm_get_wall_clock_epoch() and
__get_kvmclock(), using the master_cycle_now and master_kernel_ns fields
but converting the *host* TSC cycles directly to a value in nanoseconds
instead of scaling via the guest TSC.
One might naïvely think that all three definitions are identical, since
CLOCK_MONOTONIC_RAW is not skewed by NTP frequency corrections; all
three are just the result of counting the host TSC at a known frequency,
or the scaled guest TSC at a known precise fraction of the host's
frequency. The problem is with arithmetic precision, and the way that
frequency scaling is done in a division-free way by multiplying by a
scale factor, then shifting right. In practice, all three ways of
calculating the KVM clock will suffer a systemic drift from each other.
Eventually, definition C should just be eliminated. Commit 451a707813ae
("KVM: x86/xen: improve accuracy of Xen timers") worked around it for
the specific case of Xen timers, which are defined in terms of the KVM
clock and suffered from a continually increasing error in timer expiry
times. That commit notes that get_kvmclock_ns() is non-trivial to fix
and says "I'll come back to that", which remains true.
Definitions A and B do need to coexist, the former to handle the case
where the host or guest TSC is suboptimally configured. But KVM should
be more careful about switching between them, and the discontinuity in
guest time which could result.
In particular, KVM_REQ_MASTERCLOCK_UPDATE will take a new snapshot of
time as the reference in master_kernel_ns and master_cycle_now, yanking
the guest's clock back to match definition A at that moment.
When invoked from in 'use_master_clock' mode, kvm_update_masterclock()
should probably *adjust* kvm->arch.kvmclock_offset to account for the
drift, instead of yanking the clock back to definition A. But in the
meantime there are a bunch of places where it just doesn't need to be
invoked at all.
To start with: there is no need to do such an update when a Xen guest
populates the shared_info page. This seems to have been a hangover from
the very first implementation of shared_info which automatically
populated the vcpu_info structures at their default locations, but even
then it should just have raised KVM_REQ_CLOCK_UPDATE on each vCPU
instead of using KVM_REQ_MASTERCLOCK_UPDATE. And now that userspace is
expected to explicitly set the vcpu_info even in its default locations,
there's not even any need for that either.
Fixes: 629b5348841a ("KVM: x86/xen: update wallclock region")
Reviewed-by: Paul Durrant <paul@xen.org>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally
increments its refcount. Device teardown can clear the pointer and drop
the last reference between these operations. The increment then
resurrects an object whose RCU free has already been queued, so callers
can use it after it is freed.
Use refcount_inc_not_zero() and return NULL when the object has already
reached zero. RCU keeps the memory accessible through the attempted
reference acquisition, and a successful increment pins the object for
the caller.
An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3)
kernel reproduced the invalid reference acquisition as UID 1000:
refcount_t: addition on 0; use-after-free.
ip6_mc_source+0xef4/0x17e0
It was followed by the corresponding reference underflow in
ip6_mc_source(). The supplied trace from the same unpatched revision
additionally shows the access after the RCU read-side section ends:
BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0
Write of size 8 at addr ffff888015b50240 by task poc/1219
Bug found and triaged by OpenAI Security Research and
validated by Trail of Bits.
Fixes: 8814c4b53381 ("[IPV6] ADDRCONF: Convert addrconf_lock to RCU.")
Cc: stable@vger.kernel.org
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Co-developed-by: David Lee <david.lee@trailofbits.com>
Signed-off-by: David Lee <david.lee@trailofbits.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260803122758.666112-1-david.lee@trailofbits.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
These so called "safe" initializations aren't needed any more from
sometime, but the unnecessaries are obvious after recent clean up
by Russell. The code will correctly initialize them after getting
the correct stmmac_hwif_entry by calling stmmac_hwif_find().
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260803135745.12600-1-jszhang@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The Endpoint test driver doesn't need to do anything fancy in its error
handlers; just restore the config space that was saved during probe and
report the correct result. This helps in making sure that the AER recovery
succeeds.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260729-pci-port-reset-v9-5-53570b92064d@oss.qualcomm.com
|
|
The PCIe link may go down in cases like firmware crashes or unstable
connections. When this occurs, the Root Port must be reset to restore the
functionality. However, the current driver lacks link down handling,
forcing users to reboot the system to recover.
Implement the .reset_root_port() callback for link down handling for the
Rockchip DWC PCIe host controller. The RC is reset, reconfigured, and link
training initiated to recover from the link down event.
This also by extension fixes issues with sysfs-initiated bus resets.
Currently, the endpoint device is non-functional after a sysfs initiated
bus reset (it may link up with downgraded link status). With the link down
handling support, a sysfs initiated bus reset works as intended. Testing
conducted on a ROCK5B board with an M.2 NVMe drive.
Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: subject]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260727172654.605988-4-cassel@kernel.org
|
|
The PCIe link can go down under circumstances such as the device firmware
crash, link instability, etc. When that happens, the Root Port needs to be
reset to make it operational again. Currently, the driver is not handling
the link down event, so users have to restart the machine to make PCIe link
operational again. Fix it by detecting the link down event and resetting
the Root Port.
Since the Qcom PCIe controllers report the link down event through the
'global' IRQ, enable the link down event by setting PARF_INT_ALL_LINK_DOWN
in the PARF_INT_ALL_MASK register.
In the case of the event, iterate through the available Root Ports and call
pci_host_handle_link_down() API with Root Port 'pci_dev' to let the PCI
core handle the link down condition. Since Qcom PCIe controllers only
support one Root Port per controller instance, the API will be called only
once. But the looping is necessary as there is no PCI API available to
fetch the Root Port instance without the child 'pci_dev'.
The API will internally call the 'pci_host_bridge::reset_root_port()'
callback to reset the Root Port in a platform-specific way. Implement the
callback to reset the Root Port by first resetting the PCIe core, followed
by reinitializing the resources and then finally starting the link again.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
[bhelgaas: subject]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Link: https://patch.msgid.link/20260729-pci-port-reset-v9-4-53570b92064d@oss.qualcomm.com
|
|
Adapt the IRQ registration to work with the Higher-Ranked Lifetime Types
(HRT) device driver architecture introduced in commit 2c7c65933600
("Merge patch series "rust: device: Higher-Ranked Lifetime Types for
device drivers"").
With HRT, driver structs carry a lifetime parameter tied to the device
binding scope, allowing device resources such as pci::Bar<'bar> to be
held directly rather than through Devres indirection. However, the IRQ
abstraction required Handler: Sync + 'static, preventing handlers from
embedding lifetime-parameterized resources.
Remove the 'static bound from Handler and ThreadedHandler and replace
the Devres<RegistrationInner> indirection with direct request_irq() /
free_irq() calls in the constructor and PinnedDrop. Registration<'a, T>
stores the IrqRequest<'a>, which structurally ties it to the device
binding scope.
Also remove the &Device<Bound> parameter from the handler callbacks,
since handlers that need device access can embed it in their own type.
IRQ handlers can now directly own device resources:
struct IrqHandler<'irq> {
bar: pci::Bar<'irq, BAR_SIZE>,
}
impl irq::Handler for IrqHandler<'_> {
fn handle(&self) -> IrqReturn {
let stat = self.bar.read(regs::STAT);
...
}
}
This eliminates the indirection previously required for IRQ handlers to
access device resources and aligns with the broader goal of expressing
every registration scoped to a driver binding through compile-time
lifetime bounds.
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260719153631.559341-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Pull vhost/vdpa fixes from Michael Tsirkin:
"A small number of fixes that seem too important to
wait until the next release"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
vhost-scsi: reject feature changes after endpoint
vhost-scsi: flush backend after device ioctls
vhost: reset the vring metadata cache on vring reconfiguration
vhost-scsi: Validate T10 PI scatterlist counts
vdpa/mlx5: Fix buffer length in create_direct_keys()
vhost/vdpa: reject overflowing PA map page counts on 32-bit
vhost_iotlb: bound map allocation in add_range
|
|
The init_device() call in nzxt_smart2_hid_probe() can fail because it
sends HID output reports to the hardware to detect fans and set the
update interval. If the hardware is not responding or the HID reports
fail, init_device() returns a negative error code.
However, the return value was ignored, causing the probe to continue
and register an hwmon device even though the device was never properly
initialized. This leads to an inconsistent state where the driver
reports stale data or blocks on wait queues that will never be woken.
The same function's return value is already checked in the
reset_resume() handler, confirming the author's intent that errors
should be propagated.
Note that this fix was not possible before commit 59d104b54b0b
("hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop")
because the out_hw_close error path was missing hid_device_io_stop(),
which would have opened a use-after-free risk window.
Fixes: 53e68c20aeb1 ("hwmon: add driver for NZXT RGB&Fan Controller/Smart Device v2.")
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
Link: https://lore.kernel.org/r/20260804074842.505923-1-fffsqian@163.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
When a function-like macro expands to an expression, that expression
doesn't need a semicolon after it. All uses have been verified to
have their own semicolons.
This was found using the following Coccinelle semantic patch:
@r@
identifier i : script:ocaml() { String.lowercase_ascii i = i };
expression e;
@@
*#define i(...) e;
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Link: https://patch.msgid.link/20260801191002.1383835-11-Julia.Lawall@inria.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
A previous patch to headers_install.sh normalized the usage of
__ASSEMBLER__ to __ASSEMBLY__ in the UAPI headers due to two reasons:
1) There was the concern that the UAPI headers might be used with
non-GCC-compatible compilers, which do not define __ASSEMBLER__
automatically.
But other C compilers like PCC (see
https://github.com/IanHarvey/pcc/blob/cvs2git/2018.09.20/cc/cc/cc.1#L405)
and Tiny-C (see https://repo.or.cz/tinycc.git/commitdiff/a25325e9be13e52a),
are defining __ASSEMBLER__ for compiling assembler files, too, so using
it in UAPI header files should really be fine.
2) During the migration phase, the UAPI headers will use a mix of *both*
__ASSEMBLY__ and __ASSEMBLER__ at the same time, which is ugly and
inconsistent.
That's true. But since we already shipped a couple of kernel versions
that used __ASSEMBLER__ in the UAPI headers for certain architectures,
we might now break user space programs that have been developed with
these kernel versions if we switch back to __ASSEMBLY__.
Thus let's better always use the macro that is defined by the compilers
and standardize on __ASSEMBLER__ instead of __ASSEMBLY__ in all of the
UAPI header files now.
Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/all/2030a963-33bc-43fe-9a2b-9c626d7d8360@redhat.com/
Reviewed-by: Nicolas Schier <n.schier@fritz.com>
Tested-by: Nicolas Schier <n.schier@fritz.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260722072928.24500-1-thuth@redhat.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
|
|
bcmbca_hsspi_resume() enables the HSSPI clock, and optionally the PLL
clock, before restarting the SPI controller queue.
If spi_controller_resume() fails, the function currently reports success
and leaves those clocks enabled. Propagate the error and disable the
clocks before returning.
Fixes: a38a2233f23b ("spi: bcmbca-hsspi: Add driver for newer HSSPI controller")
Cc: stable@vger.kernel.org
Signed-off-by: Can Peng <pengcan@kylinos.cn>
Reviewed-by: Kursad Oney <kursad.oney@broadcom.com>
Link: https://patch.msgid.link/20260804071904.860842-1-pengcan@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers
Qualcomm driver updates for v7.3
Add Maili platform bindings for SCM, IMEM, AOSS, and PMIC GLINK. Add
Shikra IMEM, RPM SMD, LLCC, and UBWC support, including handling for
firmware-configured LLCC ECC interrupts.
Add the generic Peripheral Authentication Service with SCM and OP-TEE
backends, and migrate the MSM DRM and IPA drivers to it.
Add SCM SMC-call tracepoints and configurable minidump delivery through
always-on SRAM. Correct SCM download-mode pointer ordering and improve
download-mode probe diagnostics.
Rework the UBWC configuration database and add Milos and Shikra
configuration. Add protection-domain mappings for SA8775P and QCS8300,
support newer ICE versions, Hawi subsystem statistics, and SDM850
identification.
Simplify Qualcomm SoC Kconfig selection and architecture dependencies.
Use managed resources in EBI2 and RPMh RSC probe paths to correct cleanup
on failures.
* tag 'qcom-drivers-for-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (44 commits)
soc: qcom: llcc: Skip ECC interrupt setup on Shikra, pre-configured by DSF
dt-bindings: sram: Document qcom,shikra-imem compatible
net: ipa: Switch to generic PAS TZ APIs
firmware: qcom: scm: Add minidump SRAM support
firmware: qcom: scm: use dev_err_probe() for dload address failure
firmware: qcom: scm: Fix missing smp_load_acquire()
dt-bindings: firmware: qcom,scm: Add minidump SRAM property
drm/msm: Switch to generic PAS TZ APIs
bus: qcom-ebi2: use managed resources for clocks and children
soc: qcom: rpmh-rsc: manage PM notifiers with devres
firmware: qcom: scm: Allow QSEECOM on Honor Magicbook Art 14
firmware: qcom: scm: instrument SMC call path with tracepoints
firmware: qcom: scm: add trace events for the SMC call interface
soc: qcom: Avoid SCM and SPM for cpuidle drivers
soc: qcom: Make important drivers default
soc: qcom: Restrict drivers per ARM/ARM64
soc: qcom: Hide all drivers behind selectable menu
MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
firmware: qcom: Add a PAS TEE service
firmware: qcom_scm: Migrate to generic PAS service
...
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into soc/drivers
aspeed: First batch of driver changes for 7.3
Just the one patch adding MODULE_DEVICE_TABLE() where it was previously missing.
* tag 'aspeed-7.3-drivers-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux:
soc: aspeed: add missing MODULE_DEVICE_TABLE()
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap into soc/drivers
drivers: omap updates for v7.3
- bus: ti-sysc: Fix /chosen node reference leak
* tag 'omap-for-v7.3/drivers-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap:
bus: ti-sysc: Fix /chosen node reference leak
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
