| Age | Commit message (Collapse) | Author |
|---|
|
Get notifications for all errors logged in machine check banks. Skip any
that do not indicate a bitfix filter overflow.
Machine check banks are scoped to a hardware unit, so the reset has to be
issued from a CPU within that unit. Use the CPU that reported the error.
Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/20260828153002.10290-6-tony.luck@intel.com
|
|
There are potentially bitfix filters associated with each machine check
bank. Only some banks may implement them.
Machine check banks have varying scope. E.g. there is a separate L2
cache for each module, each instance has its own bitfix filter.
Add information that will be used to map a <cpu,bank> pair to a unique
instance number for a bitfix filter.
Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/20260828153002.10290-5-tony.luck@intel.com
|
|
Check if the platform supports threshold based cache error reporting and
the bitfix filter reset feature.
Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/20260828153002.10290-4-tony.luck@intel.com
|
|
IA32_CORE_CAPABILITIES enumerates the bitfix filter reset feature.
Intel specifies two values for the threshold status field in the
IA32_MCi_STATUS MSR:
1 = GREEN (threshold has not been reached)
2 = YELLOW (threshold exceeded, try bitfix filter reset)
Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/20260828153002.10290-3-tony.luck@intel.com
|
|
get_cpu_cacheinfo_id() is a static inline that requires get_cpu_cacheinfo(),
which is not exported. Modules that need to identify which cache instance
a CPU belongs to therefore cannot use it.
Move it out of line and export it.
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/20260828153002.10290-2-tony.luck@intel.com
|
|
ADXL reports memory errors using memory-controller physical indices,
while the EDAC driver identifies memory controllers using logical
indices. On Granite Rapids systems, BIOS may disable some memory
controllers, causing the physical and logical indices to differ.
As a result, ADXL memory errors may be associated with the wrong memory
controller, preventing EDAC from reporting errors for some DIMMs.
Maintain a physical-to-logical MC mapping so that ADXL memory errors are
decoded correctly regardless of the BIOS memory-controller
configuration.
Fixes: ba987eaaabf9 ("EDAC/i10nm: Add Intel Granite Rapids server support")
Reported-by: Yanhua Wu <yanhua1.wu@intel.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/20260819025259.266201-1-qiuxu.zhuo@intel.com
|
|
To pick the first perf-tools-fixes-for-v7.3 from Namhyung.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
|
After forwarding net-next during the v7.3 merge window we started
seeing:
TRACE EVENT ERROR: Event ice_tx_dim_work has double dereference in TP_printk: REC->q_vector->tx.tx_ring->q_index
WARNING: kernel/trace/trace_events.c:420 at test_double_dereference.cold+0x39/0x4b
this is due to extra checks added in tracing subsystem in
commit b5cc230af5e5 ("tracing: Warn when an event dereferences a pointer in TP_printk()").
Printing happens long after the event was recorded, by which point
the pointers may be invalid (the ring or the dim instance).
Copy the eight scalars into the event instead.
Fixes: 3089cf6d3caa ("ice: add tracepoints")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Commit 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node")
added a sched_node_ids xarray to the port info structure, but never called
xa_destroy on it.
Since xarrays can allocate internal memory, this can result in a memory
leak even if every element in the xarray has been removed.
The xarray is currently embedded in the port_info structure. This appears
to have been done because its use is within functions that take the
port_info as a primary argument.
However, this complicates managing the lifecycle of the field. The
port_info structure is allocated in ice_init_hw() using devm, and it is
not released until the devm cleanup when the driver is unloaded.
The ice_init_hw() function is called in many places, including devlink
reload, and possibly during DDP load after updating the Tx scheduler
layout.
Adding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise
multiple concerns due to potential ordering issues and possible ways that
port_info could be a dangling reference.
To handle this, move the sched_node_ids out of port_info and into the hw
structure. All users of the array already have a pointer to hw anyways, and
there is only one sched_node_ids per adapter. While here, remove the overly
verbose comment explaining the nature of the sched_node_ids xarray.
Add the missing xa_destroy to the cleanup path and to ice_deinit_hw(),
ensuring that we properly release the xarray memory.
This was caught by Sashiko during development of unrelated code.
Fixes: 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
While parsing the header of a Receive Side Coalesced (RSC) packet, check
if a VLAN tag is present and adjust the header parsing accordingly.
Otherwise, Rx TCP traffic is completely broken for any VLAN interface
whose underlying interface has RSC (rx-gro-hw) enabled.
We only need to worry about one VLAN header since Rx packets with
multiple VLAN headers are not candidates for RSC.
Fixes: 3a8845af66edb ("idpf: add RX splitq napi poll support")
Signed-off-by: Joshua Hay <joshua.a.hay@intel.com>
Reviewed-by: Emil Tantilov <emil.s.tantilov@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
idpf_probe() enables PCIe Precision Time Measurement with
pci_enable_ptm(), which takes a reference on the device and on every
PTM-capable device up the path to the PTM Root.
Neither the probe error path nor idpf_remove() drops that reference, so
the PTM enable counts of this device and of its upstream path stay
elevated with no bound driver, and the device's PTM control bits remain
set. pcim_enable_device() only arranges for pci_disable_device() and
does not undo the PTM enable.
Add the matching pci_disable_ptm() to the common unwind path.
pci_enable_ptm() failure is not fatal here, so guard the call with
pcie_ptm_enabled(): pci_disable_ptm() decrements dev->ptm_enable_cnt
unconditionally and then recurses upstream, so calling it after a failed
enable would drive this device's count negative and wrongly decrement
parents shared with other endpoints.
This issue was identified during our ongoing static-analysis research
while reviewing kernel code.
Fixes: 8d5e12c5921c ("idpf: add initial PTP support")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
[TN moved call due to commit 6b284aa2ddf3 ("idpf: refactor idpf to use libie_pci APIs")]
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
idpf never drains the Tx/Rx DIM works before freeing the memory they
live in. tx_dim and rx_dim are embedded in struct idpf_q_vector, they
are queued from the NAPI poll via net_dim(), and idpf_vport_intr_rel()
ends with kfree(rsrc->q_vectors). Nothing in the driver cancels them.
idpf_tx_dim_work() and idpf_rx_dim_work() then run on freed memory:
idpf_vport_intr_write_itr() writes the ITR register through
q_vector->intr_reg.tx_itr / rx_itr, void __iomem pointers loaded out of
the freed q_vector. No configuration is needed to get there --
IDPF_ITR_IS_DYNAMIC() is defined as (itr_mode) and idpf_vport_alloc()
initialises both modes to IDPF_ITR_DYNAMIC.
Draining after idpf_vport_intr_napi_dis_all() is not enough on its own.
idpf_net_dim() is called from inside the
"if (napi_complete_done(napi, work_done))" branch of the poll, and
napi_complete_done() has already cleared NAPIF_STATE_SCHED by then.
napi_disable_locked() waits only while (val & (NAPIF_STATE_SCHED |
NAPIF_STATE_NPSVC)), so napi_disable() can return while the poll tail is
still queueing the work, and a plain cancel_work_sync() would be
re-armed behind the drain.
Use disable_work_sync(): schedule_work() on a work with a non-zero
disable count is dropped by clear_pending_if_disabled() before
__queue_work() is reached.
Move idpf_init_dim() to idpf_vport_intr_alloc() so the works are
initialised on every path that can reach the drain -- the three
"goto intr_deinit" sites between idpf_vport_intr_init() and
idpf_vport_intr_ena() get there without the enable side having run.
Nothing re-enables them: rsrc->q_vectors is freed on every exit from
idpf_vport_open() and on every idpf_vport_stop(), so the count dies with
the object.
It is a race, not a deterministic failure -- net_dim() only schedules
once DIM_NEVENTS events have accumulated and the profile index changes.
A KASAN ifup/ifdown loop under load is the way to see it.
Fixes: c2d548cad150 ("idpf: add TX splitq napi poll support")
Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support")
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.9
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux
* 'for-next/ffa/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Tear down driver during shutdown
* 'for-next/scmi/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Fix typo "upto" in comment
clk: scpi: use PLATFORM_DEVID_NONE for scpi-cpufreq
clk: scpi: register scpi-cpufreq once and clear on failure
clk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rate
firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS
firmware: arm_scpi: fix device_node leak in scpi_dev_domain_id
|
|
Add a V4L2 sub-device driver for Himax HM1246 image sensor.
The Himax HM1246-AWD is a 1/3.7-Inch CMOS image sensor SoC with an active
array size of 1296 x 976. It is programmable through an I2C interface and
connected via parallel bus.
The sensor has an internal ISP with a complete image processing pipeline
including control loops. However, this driver uses the sensor in raw mode
and the entire ISP is bypassed.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Add YAML device tree binding for Himax HM1246 image sensor.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Add a v4l2 subdevice driver for the Omnivision os02g10 sensor.
The Omnivision os02g10 is a CMOS image sensor with an active array size of
1920 x 1080.
The following features are supported:
- Manual exposure an gain control support
- vblank/hblank control support
- vflip/hflip control support
- Test pattern control support
- Supported resolution: 1920 x 1080 @ 30fps (SBGGR10)
Signed-off-by: Elgin Perumbilly <elgin.perumbilly@siliconsignals.io>
Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Add bindings for Omnivision OS02G10 sensor.
Signed-off-by: Elgin Perumbilly <elgin.perumbilly@siliconsignals.io>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Dave Hansen:
"These are fixes for some older AMD device topology and machine check
issues. But, they are issues that are affecting real users and aren't
just cleaning up AI drive-by reports.
These is coming a wee bit later than the usual Sundays because of a
late breaking issue with one of the patches which is now temporarily
kicked out"
* tag 'x86_urgent_for_7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/MCE/AMD: Fix inverted interrupt enablement during storm handling
x86/amd_node: Fix potential NULL pointer dereference
x86/amd_node: Avoid divide by zero on virtualized systems
|
|
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
response_msg is sized as
AUTO_UPDATE_FEATURE_RESP_SIZE * sizeof(*response_msg) by hand in both
call sites. Use kzalloc_objs() instead, matching the kzalloc_obj()
already used elsewhere in this same file for the other allocations in
these functions, and getting the same overflow-checked size
computation kzalloc_obj() already benefits from.
No functional change.
Signed-off-by: Hrushiraj Gandhi <hrushirajg23@gmail.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
cgroup_subtree_control_write() and cgroup_type_write() drain dying csses
from the subtree before re-applying control, so that a controller being
re-enabled gets a fresh css instead of adopting one that is still dying. The
drain waits for offline_css() in TASK_UNINTERRUPTIBLE.
Since 1dffd95575eb ("cgroup: Defer kill_css_finish() in
cgroup_apply_control_disable()"), a disabled css offlines only after every
task that still pins it has finished exiting. The root cause of the hang is
an indefinite wait in a place where indefinite waits should not happen: a
task past exit_signals() can block in its exit path for as long as, say, a
FUSE daemon takes to answer a flush, and nothing can interrupt it because
prepare_signal() drops every signal for an exiting group. The drain then
escalated that into an uninterruptible wait for the writer, which sits in D
state for as long as the exiting task does. That is the hang syzbot reports
as "task hung in cgroup_subtree_control_write".
Make the drain interruptible. Nothing has been modified when it runs, so the
write restarts or fails with EINTR without side effects. cgroup1 mount and
remount drain the same way and become interruptible too.
cgroup_destroy_root() drains from a workqueue where no signal is ever
pending and keeps waiting as before.
This only stops the escalation. The write still waits for the exiting tasks,
and the indefinite wait in the exit path remains a separate problem.
Fixes: 1dffd95575eb ("cgroup: Defer kill_css_finish() in cgroup_apply_control_disable()")
Reported-by: syzbot+bb2e19a1190a556c01b1@syzkaller.appspotmail.com
Link: https://lore.kernel.org/all/6a23a4b4.e4db5ad2.3b7dfb.0000.GAE@google.com/
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
cgroup_kn_lock_live() returns NULL when the cgroup is dead and the callers
translate that into an errno themselves. Return ERR_PTR(-ENODEV) instead and
have the callers pass the errno through, so that failures other than a dead
cgroup can be reported through the same return value. No functional change.
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
cgroup_kn_lock_live() returns NULL when the cgroup behind a kernfs node has
already been removed. Most callers turn that into -ENODEV, but the
cgroup.type, cgroup.max.descendants, cgroup.max.depth, cgroup.pressure,
cgroup.freeze and cgroup.kill writers return -ENOENT. The divergence is
accidental. Return -ENODEV from all of them, matching cgroup.procs and
cgroup.subtree_control.
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
acpi_bus_find_device_by_name() call returns a pointer to the device object
on the ACPI bus, aka the ACPI companion device.
gpio_secondary_fwnode_init() then continues with setting the secondary
fwnode on this device. But this is not the actual physical device for
the GPIO controller (e.g. the GPIO controller platform bus device).
This mismatch is causing GPIO lookups by secondary fwnode to not work.
Modify gpio_secondary_fwnode_init() to instead set the secondary fwnode
of the first physical device associated with the ACPI companion device.
This fixes the GPIO lookups not working.
Fixes: 1448c2d2ca5c ("platform/x86: x86-android-tablets: enable fwnode matching of GPIO chips")
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908185517.49047-1-johannes.goede@oss.qualcomm.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> says:
Move all four LPASS codec macros (rx/tx/va/wsa) from REGCACHE_FLAT to
REGCACHE_MAPLE, and fix a latent v2.5 Compander1 addressing bug that
the flat cache had been absorbing.
REGCACHE_FLAT hides missing-default reads by returning the zero-
initialised cache slot instead of doing a bus read. The caller can't
tell that value apart from a real hardware value, so any un-defaulted,
readable, non-volatile register that gets read silently returns wrong
data. Since commit e062bdfdd6ad ("regmap: warn users about
uninitialized flat cache") regmap dev_warn_once()s the first such
miss, but any subsequent miss stays silent.
REGCACHE_MAPLE reports a cache miss as -ENOENT and the regmap core
falls back to a real bus read, so the caller always gets the true
hardware value. All four macros are switched in the same series
for consistency.
The switch surfaced a latent bug in wsa_macro_set_spkr_mode() on
v2.5+ silicon: two Compander1 register addresses moved on that
generation and the driver was writing to the v2.1 addresses on all
versions, taking a silent bus error. Patch 1/6 fixes that and is
tagged Cc: stable.
Series contents:
1/6: wsa-macro: use v2.5 Compander1 addresses on v2.5+ silicon
(fix, tagged for stable).
2/6: rx-macro + wsa-macro: sort concatenated reg_defaults before
regmap init so regmap does not sort a copy at runtime.
3/6: wsa-macro: switch cache to REGCACHE_MAPLE.
4/6, 5/6, 6/6: rx-macro / tx-macro / va-macro: cache switch,
same rationale as 3/6.
Tested on Glymur (SC8480XP CRD, WCD9378 SDCA compute mode + WSA8845
speakers): HPH playback, mic capture and WSA speaker playback all
work with the full series applied; the "using zero-initialized flat
cache" and "Unsorted reg_defaults" warnings both disappear from the
boot log.
Link: https://patch.msgid.link/20260908082806.648797-1-srinivas.kandagatla@oss.qualcomm.com
|
|
REGCACHE_FLAT hides missing-default reads by returning the zero-
initialised cache slot instead of doing a bus read. The caller
can't tell that value apart from a real hardware value, so any
un-defaulted, readable, non-volatile register that gets read
silently returns wrong data. Since commit e062bdfdd6ad ("regmap:
warn users about uninitialized flat cache") regmap dev_warn_once()s
the first such miss, but any subsequent miss stays silent.
Switch to REGCACHE_MAPLE. A cache miss returns -ENOENT and the
regmap core falls back to a real bus read, so the caller always
gets the true hardware value. Write-cache behaviour is unchanged.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908082806.648797-7-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
REGCACHE_FLAT hides missing-default reads by returning the zero-
initialised cache slot instead of doing a bus read. The caller
can't tell that value apart from a real hardware value, so any
un-defaulted, readable, non-volatile register that gets read
silently returns wrong data. Since commit e062bdfdd6ad ("regmap:
warn users about uninitialized flat cache") regmap dev_warn_once()s
the first such miss, but any subsequent miss stays silent.
Switch to REGCACHE_MAPLE. A cache miss returns -ENOENT and the
regmap core falls back to a real bus read, so the caller always
gets the true hardware value. Write-cache behaviour is unchanged.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908082806.648797-6-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
REGCACHE_FLAT hides missing-default reads by returning the zero-
initialised cache slot instead of doing a bus read. The caller
can't tell that value apart from a real hardware value, so any
un-defaulted, readable, non-volatile register that gets read
silently returns wrong data. Since commit e062bdfdd6ad ("regmap:
warn users about uninitialized flat cache") regmap dev_warn_once()s
the first such miss, but any subsequent miss stays silent.
Switch to REGCACHE_MAPLE. A cache miss returns -ENOENT and the
regmap core falls back to a real bus read, so the caller always
gets the true hardware value. Write-cache behaviour is unchanged.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908082806.648797-5-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
REGCACHE_FLAT hides missing-default reads by returning the zero-
initialised cache slot instead of doing a bus read. The caller
can't tell that value apart from a real hardware value, so any
un-defaulted, readable, non-volatile register that gets read
silently returns wrong data. Since commit e062bdfdd6ad ("regmap:
warn users about uninitialized flat cache") regmap dev_warn_once()s
the first such miss, but any subsequent miss stays silent.
Switch to REGCACHE_MAPLE. A cache miss returns -ENOENT and the
regmap core falls back to a real bus read, so the caller always
gets the true hardware value. Write-cache behaviour is unchanged.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908082806.648797-4-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Both drivers build the reg_defaults array by concatenating a base
table with a codec-version-specific one; the resulting array is not in
register-address order because the version-specific ranges overlap the
base range. Regmap detects this and prints
wsa_macro 6c90000.codec: Driver needs fixing: Unsorted reg_defaults,
sorting the copy
rx_macro 6a70000.codec: Driver needs fixing: Unsorted reg_defaults,
sorting the copy
then sorts its own copy at runtime. Call regcache_sort_defaults() on
the concatenated array before handing it to regmap so the warning goes
away and regmap does not have to sort a second time. Keeping the
base/version-specific split is deliberate for readability, so a static
reorder is not appropriate here.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908082806.648797-3-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
wsa_macro_set_spkr_mode() unconditionally writes CDC_WSA_COMPANDER1_CTL3
(0x5CC) and CDC_WSA_COMPANDER1_CTL7 (0x5DC). On v2.5+ silicon these
registers moved to CDC_2_5_WSA_COMPANDER1_CTL3 (0x5EC) and
CDC_2_5_WSA_COMPANDER1_CTL7 (0x5FC); the v2.1 addresses are dead on
that hardware, so the update_bits() calls take a bus error:
wsa_macro 6c90000.codec: ASoC error (-5): at
snd_soc_component_update_bits() on 6c90000.codec for
register: [0x000005dc]
The flat regcache had been hiding the read side of this by returning
the zero-initialised cache slot instead of doing a bus read, so the
error only becomes visible once the cache reports the miss honestly
and regmap falls back to a real bus read.
Select the correct address for Compander1 CTL3/CTL7 based on
codec_version. The Compander0 and Boost registers used in the same
function have the same address across versions, so they stay
unchanged. Also collapse the two mode branches to a single sequence
with mode-selected values, which is what the switch was doing anyway.
Fixes: 727de4fbc546 ("ASoC: codecs: lpass-wsa-macro: Correct support for newer v2.5 version")
Cc: stable@vger.kernel.org
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260908082806.648797-2-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When the irq-mux and its interrupt-map were added to the mpfs
devicetree, the gpio interrupts became fixed at the SoC level rather
than dependant on the design - the interrupt-map is now what varies.
The beaglev-fire should have had its dts copy of the interrupts removed
but did not. As a result, the mcp3564 driver does not probe, because
even though it doesn't use the interrupt at present, the SPI core still
looks it up. This lookup fails because the second copy of the interrupts
property doesn't resolve to something valid when passed via the
interrupt-map. Remove the second/incorrect set of interrupts properties.
Fixes: b0258f69f1e0 ("riscv: dts: microchip: update mpfs gpio interrupts to better match the SoC")
CC: stable@vger.kernel.org
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
|
|
The create_dsq test creates and destroys queues, but does not check the
-EEXIST contract for duplicate creation or whether the ID remains
accessible after the failed operation.
Extend the existing lifecycle loop to reject duplicate creation and
check that the empty queue is still accessible. After destruction,
require -ENOENT from the queue lookup, then recreate and destroy the
same ID. Check that all 1024 iterations complete.
This exercises empty queues during initialization, without concurrent
enqueueing or destruction of a nonempty queue. The create_dsq test
passes on a two-CPU matching-kernel VM.
Link: https://lore.kernel.org/all/Z-OZ7tJWhRZbUk1l@gpd3/
Assisted-by: LLM
Signed-off-by: Tianyi Chen <hi@tychen.cc>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
toggle_online_status() logs failed CPU state changes but discards the
write result. The hotplug tests can consequently wait indefinitely for
a scheduler exit that the failed operation never triggered.
Return the write result and stop both hotplug tests when a required
CPU state change fails. Release the acquired scheduler resources on
these paths and let the existing cleanup callback retry restoring
CPU1. Also fail the test when its normal CPU restoration fails.
Tested in a two-vCPU VM running a kernel built from the same source
as the selftests. Injecting EIO with strace into each of the ten CPU
state writes makes the fixed test return 1, with CPU1 online and
sched_ext disabled after cleanup. The original test does not finish
within three seconds when either of the first two writes fails.
Normal hotplug tests pass before and after the change. Making the
online file read-only also produces a failure without hanging.
Fixes: a5db7817af78 ("sched_ext: Add selftests")
Assisted-by: LLM
Signed-off-by: Tianyi Chen <hi@tychen.cc>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
SIGINT and SIGTERM set exit_req, causing the runner to stop before
executing the remaining tests. However, the exit status only reflects
the number of failed tests, so an interrupted run returns success when
none of the completed tests failed.
Include exit_req in the failure condition so callers can distinguish
an interrupted run from a successful run. Keep the result counts
limited to the tests that actually ran.
Tested the actual runner under GDB, delivering each signal before the
first test and after the example test passed. The original runner
returns 0 in all four cases; the fixed runner returns 1. Normal -h,
-l and -t example invocations still return 0.
Fixes: 9d851afa4826 ("selftests/sched_ext: Abort test loop on signal")
Assisted-by: LLM
Signed-off-by: Tianyi Chen <hi@tychen.cc>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu
pool_workqueues") fixed unbound workqueue scalability on large machines but
made flush_workqueue() walk one pwq per possible CPU, cycling each pool
lock, up to three times per flush. 85f0d8e39aff ("workqueue: Reduce
expensive locks for unbound workqueue") coalesced same-pool locks for
unbound workqueues but the walk remains. Yao Kai reported the XFS CIL
workqueue, flushed on every log force, spending up to 64us per flush in the
walk on a 128-CPU machine.
Idle pwqs can't just be skipped: the lock-and-advance of every pwq's work
color is what keeps a concurrently queued work item from being stamped with
a retired color unseen by the flusher, which would let a later flush return
before it finishes.
Track active pwqs instead. Each workqueue gets a wq_flush_pnode per node
with a lock, a mirror of wq->work_color and a list of pwqs. Queueing to an
off-list pwq syncs pwq->work_color from the mirror and adds it under
fpn->lock, and flush_workqueue_prep_pwqs() advances the mirror and splices
the list in one fpn->lock section per node before visiting the pwqs under
pool->lock as before. That replaces the fence: a racing queueing either gets
its pwq on the list before the splice or stamps the advanced color. A pwq
stays on the list until a visit finds nothing in flight, so a cascade arming
an older color still finds it, barriers need no separate add as the work
item they follow keeps the pwq on the list, and pwq_release_workfn() removes
a released pwq under wq->mutex.
On a 192-CPU 2-node machine, flushing an idle per-cpu workqueue goes from
40k to 4.2M per second and an idle unbound one from 450k to 4.3M. 16 threads
each queueing a work item and flushing, go from 30k to 110k flushes per
second on a per-cpu workqueue and 60k to 180k on an unbound one. Dense
flushes with every pwq active are unchanged on per-cpu workqueues and 15-20%
slower on unbound ones. The queue path is unchanged.
Reported-by: Yao Kai <yaokai34@huawei.com>
Link: https://lore.kernel.org/all/0a030145-c108-4365-ba2d-ac1973a1e352@huawei.com/
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
pwq_busy() scans all of pwq->nr_in_flight[] to tell whether anything is in
flight. Maintain the sum in pwq->total_in_flight, which fits in existing
padding, and test that instead.
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Per-node arrays in workqueue carry an extra slot at nr_node_ids for
NUMA_NO_NODE, and iterating them open-codes for_each_node() plus separate
handling of that slot. Add for_each_node_with_fallback() and convert
alloc/free_node_nr_active().
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
lp3943_pwm_probe() unconditionally registers a pwmchip with
LP3943_NUM_PWMS(2) hwpwm channels, but lp3943_pwm_parse_dt() only
populates pdata->pwms[i] for the channels whose ti,pwm0/ti,pwm1
property is actually present in the devicetree (the binding
explicitly allows each PWM generator to drive zero or more outputs,
and lp3943_pwm_parse_dt() only fails outright with -ENODATA if
*neither* property is present). A devicetree that configures only one
of the two channels leaves pdata->pwms[] NULL for the other.
lp3943_pwm_request_map() dereferences pdata->pwms[hwpwm] with no NULL
check:
pwm_map->output = pdata->pwms[hwpwm]->output;
pwm_map->num_outputs = pdata->pwms[hwpwm]->num_outputs;
so requesting the unconfigured channel (e.g. exporting it from
sysfs) crashes with a NULL pointer dereference instead of failing
cleanly.
Return -ENODEV from lp3943_pwm_request_map() when the channel was
never configured, before the pointer is dereferenced. The caller,
lp3943_pwm_request(), already propagates an ERR_PTR return correctly
(it does so today for the existing -EBUSY case).
Reported-by: Sashiko AI review <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/6a9d4c6b.79b5ea6e.147aa1.5883@mx.google.com?part=1
Signed-off-by: Manush Prajwal <manushprajwal555@gmail.com>
Link: https://patch.msgid.link/6a9d5187.d63de05c.175391.a17c@mx.google.com
Fixes: af66b3c0934e ("pwm: Add LP3943 PWM driver")
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
|
|
Drop the second 'be', reported by checkpatch.pl as a possible repeated
word. Only touches a comment, no code changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Correct "upto" to "up to", reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
Correct "upto" to "up to", reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
|
|
Because CFLAGS only applies to compilation ($(CC) -c), the link-time
flag -rdynamic is inert during the build. Schedulers do not rely on
exported dynamic symbols, and binaries remain byte-identical without it.
Under -Werror, Clang treats this unused argument as a build error:
$ make CC=clang-21
clang-21: error: argument unused during compilation: '-rdynamic'
[-Werror,-Wunused-command-line-argument]
Drop -rdynamic from CFLAGS to ensure clean builds across Clang versions.
Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
On E825, the TX-CLK and TSPLL DPLL devices are registered as
DPLL_TYPE_GENERIC. Their clock_id was derived from the board-level
PCIe DSN, which is identical for all interfaces sharing the same
NAC/quad. As a result, userspace (e.g. 'dpll device show') reports
several DPLL devices with the same clock_id and no board or signal
label, making it impossible to unambiguously map a DPLL device to
the interface it belongs to.
Since these DPLLs are per-interface, use the permanent port MAC as
the clock_id basis for E825 generic DPLLs:
* TX-CLK uses the plain MAC-derived value.
* TSPLL on the source-timer owner PF uses the same MAC-derived
value with a dedicated tag bit, so it stays distinct from
TX-CLK while remaining stable per interface.
Other DPLL objects (EEC/PPS and non-E825 paths) keep the board
DSN-derived clock_id. When the permanent MAC is not yet valid, fall
back to the existing board-level clock_id to preserve init behavior.
Reviewed-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
This extends the E825 advanced sync-timing support introduced by the
tx-clk series, which added the TXC DPLL device for TX reference clock
control. The TSPLL, the source timer PLL, is now also exposed through
the dpll subsystem so that its lock status and clock source selection
are visible and controllable from userspace.
On E825 devices the TSPLL is the source timer PLL, distinct from the
EEC and PPS DPLLs used on E810. Register it as a DPLL_TYPE_GENERIC
device for owner PFs.
Add struct ice_dplls::tspll_in, a fwnode-backed input pin named
"time_ref". The state_on_dpll_get callback queries ICE_CGU_R23 via
ice_tspll_get_clk_src() and returns CONNECTED when TIME_REF is
selected as clock source, DISCONNECTED otherwise. The state_on_dpll_set
callback switches the source between TIME_REF and TCXO via the new
ice_tspll_set_cfg() helper. Registration is deferred via the dpll
notifier path if the pin is not yet visible in the subsystem at probe
time.
Initialize TSPLL DPLL state from direct clock-source/lock reads so the
first published state reflects hardware and prev_dpll_state matches.
During periodic polling, the DPLL worker consumes
READ_ONCE(pf->ptp.tspll_locked), maintained and recovered by the PTP
periodic worker. When the TSPLL clock source is TCXO (TIME_REF pin not
selected), UNLOCKED is reported unconditionally to reflect the
free-running state of the oscillator regardless of the raw lock bit.
To avoid stale lock-status reads after synchronous source changes, the
set callback now refreshes tspll.dpll_state immediately and emits a DPLL
change notification when the cached state changed.
If a TSPLL reconfiguration is applied but the PLL has not yet
re-acquired lock, treat the internal -EAGAIN result as success so the
PTP periodic worker can complete recovery, while real -EBUSY failures
from reset/SBQ paths still propagate to userspace.
The TSPLL userspace reconfiguration path (state_on_dpll_set) and the
PTP periodic worker (ice_ptp_tspll_monitor) both read TSPLL HW state
and write the pf->ptp.tspll_locked cache consumed by the DPLL worker.
Serialize both with pf->dplls.lock across their HW-read -> cache-write
sequence; otherwise a preempted monitor could overwrite an accurate
cache update from the DPLL callback with stale HW state. The mutex
lifetime is lifted to PF-features scope (initialized in
ice_init_features() before ice_ptp_init(), destroyed in
ice_deinit_features() after ice_ptp_release()) so the PTP monitor
can take it unconditionally regardless of DPLL init state.
Extend ice_dpll_deinit_txclk_pins() with a "flush" parameter so the
E825 init error path for the TSPLL fwnode pin can tear down TXCLK
pins without flushing pf->dplls.wq. If the flush ran here, notifier
work items queued during earlier init steps would be blocked on
pf->dplls.dpll_init, which is only completed at the unregister_pins
label reached after this teardown. destroy_workqueue() at that label
drains the queued items safely. Existing full-teardown callers pass
flush=true and keep current behavior.
Reviewed-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
On E825 devices that own the source timer, the TSPLL can lose lock when
the TCXO or TIME_REF signal is disrupted. Recovery requires re-enabling
the TSPLL via CGU register writes; without it, the PHC keeps running on
a degraded reference indefinitely.
The DPLL periodic worker (ice_dpll_periodic_work()) would be a natural
home for this monitoring, but placing it there has two problems:
1. ice_dpll_init_e825() sets ICE_FLAG_DPLL only after all initialization
steps succeed. If any earlier step fails, the driver would run
without any TSPLL recovery mechanism.
2. When CONFIG_DPLL=n, the DPLL worker is compiled out and TSPLL
recovery would be silently absent.
Add the monitor to ice_ptp_periodic_work() instead, which always runs on
E825 owner PFs regardless of DPLL init state or config. Introduce two
small helpers, ice_tspll_lost_lock_e825c() and ice_tspll_restart_e825c(),
which encapsulate the CGU register reads/writes required to observe and
recover the TSPLL.
Cache the observed lock state in pf->ptp.tspll_locked using
WRITE_ONCE()/READ_ONCE() so a follow-up change can consume it from the
DPLL periodic worker (for user-space notification via
dpll_device_change_ntf()) and drop the redundant poll+recovery from
that path. Precise synchronization is not required: both workers converge
on the same value within one poll period.
Reviewed-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
Merge the mmc fixes for v7.3-rc[n] into the next branch, to allow them to
get tested together with the mmc changes that are targeted for the next
release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
