| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
mmc_spi_data_do() updates data->bytes_xfered after each block has been
transferred successfully. If a later block in the same data request
fails with a CRC error, data->bytes_xfered may therefore contain the
number of bytes completed before the failing block.
mmc_spi_request() has a private recovery path for such CRC failures. It
sends STOP_TRANSMISSION, clears data->error and jumps back to
crc_recover to issue the same command and data request again. However,
it does not clear data->bytes_xfered before the retry.
If the retry succeeds, the request is completed with the bytes from the
failed attempt still included in data->bytes_xfered. For a multi-block
request this can make the completed request report more bytes than were
transferred by the successful retry, and can even exceed the request size
when most blocks completed before the CRC error.
This is most likely to be observed on MMC-over-SPI systems where long
multi-block transfers occasionally hit a data CRC error but the
mmc_spi-internal retry succeeds. The data itself is retried, but the
completion accounting is not.
Clear data->bytes_xfered together with data->error before repeating the
request so the final completion reports only the bytes transferred by the
successful attempt.
Fixes: 061c6c847eeb ("mmc_spi: Recover from CRC errors for r/w operation over SPI.")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
drm_exec_prepare_array() silently returns success without calling
drm_exec_lock_contended() when num_objects is zero. This breaks the
invariant upheld by drm_exec_lock_obj(), where every entry point into
the locking sequence must first attempt to lock any previously
contended object before proceeding.
Drivers that chain multiple drm_exec_prepare_array() calls per
drm_exec_until_all_locked() iteration (e.g. amdgpu's userq signal/wait
ioctls, which prepare separate read and write BO arrays) can pass an
empty array for one of the two calls. If contention is hit while
preparing the non-empty array, exec->contended is set and the loop
retries; on retry, the empty-array call preceding it is a no-op that
never clears exec->contended, so drm_exec_retry_on_contention()
immediately jumps back to the top of the loop without ever reaching
the call that would resolve the contention. This spins forever.
Fix it by having drm_exec_prepare_array() call drm_exec_lock_contended()
directly when num_objects is zero, so a pending contended object dont
loop infinitely.
Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7")
CC: stable@vger.kernel.org # v6.6+
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Link: https://lore.kernel.org/r/20260908091729.2749399-1-sunil.khatri@amd.com
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
|
|
host->sdio_irq is assigned from platform_get_irq_optional(), which
returns a positive IRQ number on success or a negative error code on
failure. Therefore, 0 is not a possible return value from this API.
Check for a positive IRQ number before requesting the SDIO IRQ instead
of treating zero as a valid IRQ.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no optional IRQ is available. Other errors, such as -EPROBE_DEFER
and -EINVAL, should be propagated so that the caller can handle them
appropriately.
However, the driver currently stores the return value directly in
host->sdio_irq and continues probing.
Propagate negative errors other than -ENXIO.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no optional IRQ is available. Other errors, such as -EPROBE_DEFER
and -EINVAL, should be propagated so that the caller can handle them
appropriately.
However, the driver currently stores the return value directly in
cd_irq and continues probing.
Propagate negative errors other than -ENXIO, and only assign the IRQ to
cd_irq when a valid IRQ number is returned.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Add the SoC-specific compatible string and use the generic one as fallback
for the UltraRISC DP1000 SPI controller.
The DP1000 integrates two SPI controllers. SPI0 supports standard, dual
and quad transfers with three native chip-select signals. SPI1 supports
standard transfers with four native chip-select signals.
Both controllers have one register range and separate reference and APB
interface clocks.
Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260907-ultrarisc-dts-v2-5-5eb4c97477c5@ultrarisc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Switch to devm_spi_register_controller() and drop the unneeded
.remove callback and dev_set_drvdata().
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Link: https://patch.msgid.link/20260907-ar934x-v1-1-71327eb482bc@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Madhavan Srinivasan:
- Clear TIF_SYSCALL_RET before syscall error return
- Don't drop _TIF_RESTOREALL on syscall restart
- Do not restore KUAP in arch_exit_to_user_mode_prepare()
- pci-ioda: Fix the stale irq chip reference
- Use inclusive range checks in add_usable_mem() and excluded memory
- Fix irq_soft_mask corruption on replayed interrupt exit
- MAINTAINERS: powerpc: Add Ritesh and Shrikanth
- Misc fixes and cleanups
Thanks to Amit Machhiwal, Christophe Leroy (CS GROUP), Gautam Menghani,
Harsh Prateek Bora, Jiangshan Yi, Mukesh Kumar Chaurasiya (IBM), Ritesh
Harjani (IBM), Shivaprasad G Bhat, Shrikanth Hegde, Sourabh Jain,
Tasmiya Nalatwad, Thorsten Blum, and Venkat Rao Bagalkote.
* tag 'powerpc-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
MAINTAINERS: powerpc: Add Ritesh and Shrikanth
powerpc/ps3: Fix repository.c build failure
powerpc/entry: Fix irq_soft_mask corruption on replayed interrupt exit
powerpc/pseries/pci: Fix misleading VF limit error message
powerpc/kexec_file: Use inclusive range checks for excluded memory
powerpc/kexec: Simplify kdump_extra_elfcorehdr_size()
powerpc/kexec_file: Use inclusive range checks in add_usable_mem()
powerpc/rtas_pci: No hotplug on permanently removed device on pSeries
powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver
powerpc: pci-ioda: Fix the stale irq chip reference
powerpc: Do not restore KUAP in arch_exit_to_user_mode_prepare()
powerpc: Don't drop _TIF_RESTOREALL on syscall restart
powerpc/entry: Clear TIF_SYSCALL_RET before syscall error return
|
|
The "AMDI5682" ACPI HID is matched by two AMD ASoC machine drivers:
cz-da7219-max98357a (this driver, Carrizo/Stoney) and
acp3x-alc5682-max98357 (Raven/Picasso). cz-da7219-max98357a is linked
first and probes the platform device first; its DAI links reference the
Stoney ACP, which is absent on Raven/Picasso, so its card can never be
instantiated there.
This was harmless until commit 42d99857d6f0 ("ASoC: core: Move all users
to deferrable card binding"): devm_snd_soc_register_card() now returns 0
for a card left pending instead of propagating -EPROBE_DEFER, so
cz_probe() succeeds and permanently binds AMDI5682. acp3x-alc5682-max98357
never binds and the internal speakers and headphone jack get no card.
Detect Raven/Picasso (and later) by the ACP3.x audio coprocessor's
dedicated PCI function (1022:15e2); Carrizo/Stoney reach the ACP through
the GPU driver and have no such device. Return -ENODEV so the driver core
continues probing AMDI5682 with acp3x-alc5682-max98357.
Fixes: 42d99857d6f0 ("ASoC: core: Move all users to deferrable card binding")
Cc: stable@vger.kernel.org
Signed-off-by: Yorick Rommers <yorick-rommers@hotmail.com>
Tested-by: Yorick Rommers <yorick-rommers@hotmail.com>
Link: https://patch.msgid.link/20260907121228.13754-1-yorick-rommers@hotmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
"This adds missing vzeroupper instructions to x86/aria"
* tag 'v7.3-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: x86/aria - add missing vzeroupper in AVX-512 code
crypto: x86/aria - add missing vzeroupper in AVX2 code
|
|
Add a per-GT debugfs file, multi_queue_active_lrca, that prints, for
every engine supporting multi-queue, the currently active queue ID
(CSMQDEBUG) and the LRCA of the exec queue occupying that slot within
the running multi-queue group.
RING_CURRENT_LRCA only reports the primary queue's LRCA for the group
and does not update to reflect the active queue in multi-queue mode,
which makes it hard to tell which queue is actually running when
debugging multi-queue CSB/context-switch issues. Resolve the active
LRCA by matching the primary LRCA against each queue's group and
picking the queue at the reported active_id position.
v4:
- Extracted multi_queue_active_lrca into a dedicated
multi_queue_debugfs_list to prevent debugfs node registration on
platforms lacking multi-queue support entirely, via
xe_gt_has_multi_queue() gating. (Tejas)
v3:
- Use xe_exec_queue_get_lrc() instead of raw pointer dereference to
safely handle concurrent multi-queue group creation and avoid race
conditions (Sashiko)
v2:
- Maintain alphabetical order for includes and
pf_only_debugfs_list (Tejas)
- Export and reuse xe_lrc_get_multi_queue_active_queue_id() instead
of duplicate MMIO read (Tejas)
Bspec: 60321, 73976
Signed-off-by: Varun Gupta <varun.gupta@intel.com>
Link: https://patch.msgid.link/20260908033417.1019602-2-varun.gupta@intel.com
Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
|
|
Following up on a prior patch that only fixed w1_netlink.c, sweep
the rest of the w1 subsystem for the same class of comment typos:
"loosing" -> "losing", "deatch" -> "detach", "messagse" -> "messages",
"continusly" -> "continuously", "attribut" -> "attribute",
"deactive" -> "deactivate", "determing" -> "determining",
"discrepency" -> "discrepancy", "rerurn" -> "return".
No functional change.
Signed-off-by: Ivy Lopez <skunkolee@gmail.com>
Link: https://patch.msgid.link/20260906200304.36932-1-skunkolee@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Setting the file type in cf_mode without clearing the existing S_IFMT
bits first is wrong as it corrupts the file type when cf_mode already
has type bits set (e.g. S_IFREG | S_IFLNK == S_IFDIR | S_IFREG).
Clear S_IFMT before setting S_IFLNK for native and SMB1 symlinks.
Closes: https://sashiko.dev/#/patchset/20260906181540.647469-1-pc%40manguebit.org
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Cc: Shyam Prasad N <sprasad@microsoft.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Bharath SM <bharathsm@microsoft.com>
Cc: stable@vger.kernel.org
|
|
Setting the file type in cf_mode without clearing the existing S_IFMT
bits first is wrong as it corrupts the file type when cf_mode already
has type bits set (e.g. S_IFREG | S_IFCHR == S_IFLNK).
Use a local ftype variable to collect the new file type and apply it
after validation succeeds, clearing S_IFMT and setting the new type in
a single assignment. This avoids stripping cf_mode on malformed
reparse points where the function returns false early.
Closes: https://sashiko.dev/#/patchset/20260906172005.627163-1-pc%40manguebit.org
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Cc: Shyam Prasad N <sprasad@microsoft.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Bharath SM <bharathsm@microsoft.com>
Cc: stable@vger.kernel.org
|
|
Setting the file type in cf_mode without clearing the existing S_IFMT
bits first is wrong as it corrupts the file type when cf_mode already
has type bits set (e.g. S_IFREG | S_IFCHR == S_IFLNK).
Clear S_IFMT before the switch statement.
Closes: https://sashiko.dev/#/patchset/20260906172005.627163-1-pc%40manguebit.org
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Cc: Shyam Prasad N <sprasad@microsoft.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Bharath SM <bharathsm@microsoft.com>
Cc: stable@vger.kernel.org
|
|
cifs_posix_to_fattr() ignores the return value of posix_info_parse().
When a malformed POSIX directory entry is encountered (e.g. invalid
SID lengths from an untrusted server), posix_info_parse() returns -1
without populating the 'parsed' struct. The uninitialized stack
memory in parsed.owner and parsed.group is then passed to
sid_to_id(), which processes the garbage bytes and passes them to
request_key() to construct a SID string, potentially leaking kernel
stack contents to the userspace idmap daemon.
Fix this by checking the return value and skipping the SID-to-id
mapping when parsing fails. The remaining fattr fields (timestamps,
mode, etc.) are populated directly from the 'info' pointer so they
are unaffected.
Closes: https://sashiko.dev/#/patchset/20260906172005.627163-1-pc%40manguebit.org
Closes: https://sashiko.dev/#/patchset/20260906181540.647469-1-pc%40manguebit.org
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Cc: Shyam Prasad N <sprasad@microsoft.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Bharath SM <bharathsm@microsoft.com>
Cc: stable@vger.kernel.org
|
|
wsl_to_fattr() unconditionally overwrites cf_uid/cf_gid with values
from WSL extended attributes ($LXUID/$LXGID), ignoring the forceuid
and forcegid mount options.
Fix this by initializing cf_uid/cf_gid to the mount defaults and
gating the $LXUID/$LXGID EA parsing on forceuid/forcegid.
Closes: https://sashiko.dev/#/patchset/20260906190803.667489-1-pc%40manguebit.org
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Cc: Shyam Prasad N <sprasad@microsoft.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Bharath SM <bharathsm@microsoft.com>
Cc: stable@vger.kernel.org
|
|
When the administrator mounts with forceuid or forcegid (uid=/gid=
mount options), they expect all files to appear owned by the specified
user/group. However, several code paths unconditionally called
sid_to_id() to overwrite cf_uid/cf_gid with server-provided values,
ignoring the administrator's explicit override:
- smb311_posix_info_to_fattr() (stat via POSIX extensions)
- cifs_posix_to_fattr() (readdir via POSIX extensions)
- parse_sec_desc() (CIFS ACL ownership mapping)
This allowed an untrusted server to dictate local file ownership even
when the mount was configured to force specific uid/gid values.
Fix all three call sites to check CIFS_MOUNT_OVERR_UID and
CIFS_MOUNT_OVERR_GID before calling sid_to_id(), following the
same pattern already used by cifs_unix_basic_to_fattr() for unix
extensions.
Closes: https://sashiko.dev/#/patchset/20260906155816.603278-1-pc%40manguebit.org
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Cc: Shyam Prasad N <sprasad@microsoft.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Bharath SM <bharathsm@microsoft.com>
Cc: stable@vger.kernel.org
|
|
When mounting with 'multiuser,posix' options, cifs_getattr() overrides
the server-provided uid/gid with the current process's fsuid/fsgid.
This is because the condition only checks for unix extensions
(tcon->unix_ext) but not posix extensions (tcon->posix_extensions).
With SMB3 POSIX extensions, the server provides real uid/gid values
just like with unix extensions, so they should be preserved rather
than replaced with the caller's credentials.
Add a tcon->posix_extensions check to the condition so that uid/gid
from the server are properly reported in stat results.
Reported-by: Arthur Lesuisse <arthur.lesuisse@ulb.be>
Closes: https://lore.kernel.org/r/DB9P190MB2012266F6B8DECBE5D26A1798DB52@DB9P190MB2012.EURP190.PROD.OUTLOOK.COM
Suggested-by: Arthur Lesuisse <arthur.lesuisse@ulb.be>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Cc: Shyam Prasad N <sprasad@microsoft.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Bharath SM <bharathsm@microsoft.com>
Cc: stable@vger.kernel.org
|
|
The put() callback of "IEC958 Playback Default" returns whether the
converted register value moved. The convert_from_spdif_status() helper
reads part of the first two channel status bytes and none of the last
two, while the get() callback returns all four. So a write that lands
only in the bits it does not read changes what userspace reads back and
reports no change. Of the 31 bits above the mode bit, 20 are such bits
in consumer mode and 29 in professional mode. The core notifies only on
a positive return.
Toggling status[2] bit 0 on an HDA HDMI codec moves the read-back from
04 00 00 00 to 04 00 01 00 with no event. Toggling the non-audio bit
in status[0] gives one.
Compare the stored status as well, the way the ac97 code does. The
write to the codec stays gated on the converted value.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Assisted-by: Claude:claude-opus-5
Link: https://patch.msgid.link/20260908134153.1614273-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The hwdep mmap callback rejects read-buffer mappings that are initially
writable, but leaves VM_MAYWRITE set on mappings created with PROT_READ.
A process that can open the hwdep node O_RDWR can later use mprotect() to
make the mapping writable.
The read allocation begins with struct usb_stream. Its read_size member is
used by the fault handler to decide which pages belong to the read buffer.
The read VMA intentionally remains expandable because pcm_usb_stream uses
mremap() after reading that size. Changing read_size first can therefore
map and access pages beyond the allocation. The same member is also
consumed by usb_stream_free(), where changing it can make
free_pages_exact() release pages outside the allocation.
Clear VM_MAYWRITE for read-buffer mappings after rejecting an initially
writable VMA. This keeps the separate output-buffer mapping writable while
preventing later permission upgrades.
Fixes: 030a07e44129 ("ALSA: Add USB US122L driver")
Cc: stable@vger.kernel.org
Signed-off-by: Kazuki Hanai <hnkz.64@gmail.com>
Link: https://patch.msgid.link/20260908110053.2950767-1-hnkz.64@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
bui duc phuc <phucduc.bui@gmail.com> says:
Hi all,
This series fixes and cleans up error handling in the MT6797 ASoC driver.
Compile tested only.
Link: https://patch.msgid.link/20260821122840.41266-1-phucduc.bui@gmail.com
|
|
The errors handled here are already reported by the called functions,
either directly or deeper in the call chain. Therefore, the additional
dev_err() calls are redundant and can be removed.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260821122840.41266-4-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Replace dev_err() with dev_err_probe() to prevent log spam when probe
returns -EPROBE_DEFER.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260821122840.41266-3-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
