| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Don't populate the read-only const array regulator_names on the stack
at run time, instead make it static const char * const
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Add the compatible for the SARADC of the Rockchip RV1106, which is
compatible with the RK3588 variant.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
When two commands enter aie2_sched_job_timedout() concurrently, both
check the timeout detection state. The first scheduler thread observes
tdr_status as SIGNALED and updates it to WAIT. The second thread then
observes the updated state instead of the original SIGNALED state, which
may cause the command timeout to be handled incorrectly.
Replace tdr_status with last_signal_ts, which records the timestamp of
the last driver signal. Timeout detection now only reads
last_signal_ts and never modifies it, allowing multiple serialized
detect() calls under dev_lock to evaluate the same signal timestamp
independently. If there is not any new job scheduled or completed
within tdr_timeout_ms, the command will timeout.
Fixes: 9022f010977f ("accel/amdxdna: Check for device hang on job timeout")
Signed-off-by: Wendy Liang <wendy.liang@amd.com>
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260718083409.1825940-1-lizhi.hou@amd.com
|
|
Add support for AES-XTS to the crypto library.
This will be used to provide a streamlined implementation of the
"xts(aes)" crypto_skcipher algorithm. I'm also planning to use this
directly in fscrypt and blk-crypto-fallback.
As usual, the architecture-optimized AES-XTS code will be migrated into
the library as well (using the hooks provided in this commit),
eliminating lots of repetitive boilerplate code. Compared to direct
implementation of "xts(aes)", I've also eliminated the requirement for
architectures to implement ciphertext stealing, as the library just
handles it portably instead. That will simplify things considerably.
Initial test coverage is provided by the crypto_skcipher support added
in a later commit. I'm planning a KUnit test suite as well.
Link: https://patch.msgid.link/20260715221153.246410-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Add support for AES-CTR and AES-XCTR to the crypto library.
These will be used to provide streamlined implementations of the
"ctr(aes)" and "xctr(aes)" crypto_skcipher algorithms. Most users of
"ctr(aes)" will also be able to switch to the library, which as usual
will be simpler and faster, e.g.:
- net/mac80211/fils_aead.c
- net/mac802154/llsec.c
As usual, the architecture-optimized AES-CTR and AES-XCTR code will be
migrated into the library as well (using the hooks provided in this
commit), eliminating lots of repetitive boilerplate code.
This is also a prerequisite for supporting AES-GCM, AES-CCM, and
AES-HCTR2 in the crypto library.
Initial test coverage is provided by the crypto_skcipher support added
in a later commit. I'm planning a KUnit test suite as well.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260715221153.246410-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Add support for AES-CBC and AES-CBC-CTS to the crypto library.
These will be used to provide streamlined implementations of the
"cbc(aes)" and "cts(cbc(aes))" crypto_skcipher algorithms. Most users
of these crypto_skcipher algorithms will also be able to switch to the
library, which as usual will be simpler and faster, e.g.:
- block/blk-crypto-fallback.c (for AES-128-CBC-ESSIV)
- fs/crypto/crypto.c (for AES-128-CBC-ESSIV)
- fs/crypto/fname.c (for AES-256-CTS and AES-128-CBC)
- kernel/bpf/crypto.c
- net/ceph/crypto.c
- security/keys/encrypted-keys/encrypted.c
As usual, the architecture-optimized AES-CBC and AES-CBC-CTS code will
be migrated into the library as well (using the hooks provided in this
commit), eliminating lots of repetitive boilerplate code.
Initial test coverage is provided by the crypto_skcipher support added
in a later commit. I'm planning a KUnit test suite as well.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260715221153.246410-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Add support for AES-ECB to the crypto library.
This will be used to provide a streamlined implementation of the
"ecb(aes)" crypto_skcipher algorithm. fs/crypto/keysetup_v1.c will also
use aes_ecb_encrypt() directly.
As usual, the architecture-optimized AES-ECB code will be migrated into
the library as well (using the hooks provided in this commit),
eliminating lots of repetitive boilerplate code.
ECB is obsolete of course, but we need this for parity with the
traditional API and to support some odd users of ECB in the kernel.
Initial test coverage is provided by the crypto_skcipher support added
in a later commit. I'm planning a KUnit test suite as well.
Create a documentation file libcrypto-unauth-encryption.rst to hold the
documentation for this and other unauthenticated encryption modes.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260715221153.246410-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Make the AES-XTS key verification code callable by the crypto library by
splitting out a helper function that doesn't use crypto_skcipher.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Link: https://patch.msgid.link/20260715221153.246410-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
|
|
Add debugfs register access to the ads112c14 driver. This is a complex
chip and being able to poke registers is useful for debugging and
diagnostic/calibration purposes.
Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Fix the last remaining breakage caused by missing a SoC IO access
update. Commit e1f3a00670d1 ("m68k: coldfire: use ColdFire specifc
IO access in SoC code") missed this read16() call which should be
mcf_read16().
Fixes: e1f3a00670d1 ("m68k: coldfire: use ColdFire specifc IO access in SoC code")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607180731.U4tiwFcQ-lkp@intel.com/
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
|
|
Add support for parsing devicetree properties for measurement channels
and doing direct reads on these.
There are quite a lot of conditions that have to be met for each
measurement to be made, so quite a bit of state and algorithms are
required to handle it.
Channels are created dynamically since the number of possibilities is
unreasonably large.
Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Implement support for the programmable gain amplifier on the internal
short SYS_MON channel. This channel is used for calibration, so it is
useful to be able to set the PGA to the same gain as the external
channels. The gain setting is implemented via the `_scale` attribute.
In the future, we may want to support different reference voltages for
this channel, so the scale_available table is populated during probe
rather than being a static table.
Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Add a new driver for the TI ADS112C14/ADS122C14 ADC chips.
This first step is adding a very basic driver that only supports power
on/reset and reading the system monitor channels.
ADS112C14_SYS_MON_CHANNEL_SHORT is the last channel rather than being in
logical order by address to keep the voltage channels together and in
case we find we need to add variants of this channel with different
voltage reference later.
Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Add new bindings for ti,ads112c14 and similar devices.
This is an ADC that is primarily intended for use with resistive sensors
(RTD, thermocouple, Wheatstone bridge, etc.). There are a few unusual
properties because of this. In particular, the reference voltage source
and current output requirements can be different for each measurement,
so these are included in the channel bindings.
The REFP/REFN reference voltage is usually just connected to a resistor
that is being driven by the ADC's current outputs, so there is special
property for this case rather than requiring a regulator to be defined
to represent that.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Add a generic input-chopping property to adc.yaml. This is a feature
seen frequently in ADCs that are designed to measure resistive loads,
such as RTDs and strain gauges. Enabling this can reduce offset errors
by swapping the positive and negative input channels on every other
conversion. This can have side-effects in timing and filter response, so
it is not always desirable to enable this feature in some applications.
Therefore, it is best to make this a property that can be enabled or
disabled in the device tree.
Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Some ADCs incorporate burn-out current sources that provide current to
the channel's input pins for open-circuit or short-circuit detection.
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Some ADCs incorporate current sources that provide excitation current to
resistive temperature devices (RTDs), thermistors, diodes and other
resistive sensors that require constant current biasing.
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Some ADCs have configurable voltage reference sources for each channel.
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Babanpreet Singh <bbnpreetsingh@gmail.com> says:
Two small cleanups for the Axiado SPI driver, both defects present
since the driver was added in e75a6b00ad79 ("spi: axiado: Add driver
for Axiado SPI DB controller").
Patch 1 addresses the coccinelle cond_no_effect warning reported by
the kernel test robot on 2026-07-12 [1]: the RX-only/full-duplex
else-if arm and the trailing else arm in ax_transfer_one() have
identical bodies, so the second condition has no effect. The arms are
merged; no functional change (on x86_64/gcc 14, only
ax_transfer_one()'s object code changes, dropping the dead condition
evaluation).
Patch 2 fixes the kernel-doc comments in the driver: a copy-pasted
function name on ax_spi_get_rx_byte_for_irq(), a /** block with no
identifier line on ax_spi_process_rx_and_finalize(), and stale/missing
member documentation on struct ax_spi. This silences the driver's two
W=1 kernel-doc warnings plus five more visible when kernel-doc is run
on the header directly.
Both patches are against spi/for-next; they are independent of each
other except for touching the same file.
[1] https://lore.kernel.org/r/202607121827.djB0zLAj-lkp@intel.com/
Link: https://patch.msgid.link/20260713060807.7-1-bbnpreetsingh@gmail.com
|
|
Running kernel-doc -Wall on the driver reports 7 warnings, all present
since the driver was added in commit e75a6b00ad79 ("spi: axiado: Add
driver for Axiado SPI DB controller"). Two are in spi-axiado.c and
also show up in W=1 builds of drivers/spi:
Warning: drivers/spi/spi-axiado.c:226 expecting prototype for
ax_spi_get_rx_byte(). Prototype was for ax_spi_get_rx_byte_for_irq()
instead
Warning: drivers/spi/spi-axiado.c:248 This comment starts with
'/**', but isn't a kernel-doc comment. Refer to
Documentation/doc-guide/kernel-doc.rst
The other five are for struct ax_spi in spi-axiado.h, seen when
kernel-doc is invoked on the header directly (headers are not scanned
by the build-time kernel-doc checks):
Warning: drivers/spi/spi-axiado.h:130 Excess struct member 'rxbuf'
description in 'ax_spi'
Warning: drivers/spi/spi-axiado.h:130 Excess struct member 'txbuf'
description in 'ax_spi'
Warning: drivers/spi/spi-axiado.h:130 struct member 'clk_rate' not
described in 'ax_spi'
Warning: drivers/spi/spi-axiado.h:130 struct member 'rx_buf' not
described in 'ax_spi'
Warning: drivers/spi/spi-axiado.h:130 struct member 'tx_buf' not
described in 'ax_spi'
Fix the three underlying defects:
- The comment on ax_spi_get_rx_byte_for_irq() carries the name of
ax_spi_get_rx_byte(), from which it was evidently copied when the
IRQ variant was split out; fix the function name.
- The comment on ax_spi_process_rx_and_finalize() is opened with the
kernel-doc /** marker but has no identifier line; turn it into
proper kernel-doc (identifier line, @ctlr, Return:) since it
already describes the behavior and the return value.
- The struct ax_spi comment documents @txbuf and @rxbuf while the
members are named tx_buf and rx_buf, and does not document
clk_rate; fix the member names and describe clk_rate.
No functional change.
Assisted-by: Claude:claude-fable-5 [kernel-doc]
Signed-off-by: Babanpreet Singh <bbnpreetsingh@gmail.com>
Acked-By: Tzu-Hao Wei <twei@axiado.com>
Link: https://patch.msgid.link/20260713060807.7-3-bbnpreetsingh@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The else-if arm taken for RX-only and full-duplex transfers and the
trailing else arm in the RX bookkeeping setup of ax_transfer_one()
have identical bodies, so the second condition has no effect:
drivers/spi/spi-axiado.c:433:8-10: WARNING: possible condition with
no effect (if == else)
The trailing else arm (neither TX nor RX buffer) is also unreachable:
the SPI core only calls the ->transfer_one() callback for transfers
that carry at least one buffer, see spi_transfer_one_message().
Merge the two arms into a single else branch and fold their comments.
No functional change. The redundant condition has been present since
the driver was added in commit e75a6b00ad79 ("spi: axiado: Add driver
for Axiado SPI DB controller").
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Closes: https://lore.kernel.org/r/202607121827.djB0zLAj-lkp@intel.com/
Assisted-by: Claude:claude-fable-5 [coccinelle]
Signed-off-by: Babanpreet Singh <bbnpreetsingh@gmail.com>
Link: https://patch.msgid.link/20260713060807.7-2-bbnpreetsingh@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Extend the kunit module for platform devices with test cases verifying
that the same software node can be added to platform devices repeatedly.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-swnode-remove-on-dev-unreg-v8-5-5c2b8cc38c28@oss.qualcomm.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
With no drivers that manually assign software nodes to platform devices
created with platform_device_alloc(), we can now unify the release path
and remove platform_device_release_full().
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-swnode-remove-on-dev-unreg-v8-4-5c2b8cc38c28@oss.qualcomm.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
This driver intentionally uses the fine-grained approach to creating
platform devices. It assigns a software node as the primary firmware
node of the device it creates. Ahead of improving the reference counting
of platform device software nodes, switch to using
device_create_managed_software_node(). This way, we create a dynamic
software node whose life-time is tied to the device to which it's
assigned.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-swnode-remove-on-dev-unreg-v8-3-5c2b8cc38c28@oss.qualcomm.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Creating a software node for a given set of properties and adding it to
a platform device can be achieved with a single call to
platform_device_register_full(). There's nothing in this driver that
suggests using the more fine-grained interfaces was intentional so
switch to using the high-level helper.
Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-swnode-remove-on-dev-unreg-v8-2-5c2b8cc38c28@oss.qualcomm.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Calling platform_device_set_fwnode() (and by extension:
platform_device_set_of_node()) of platform_device_set_of_node_from_dev()
for a dynamically allocated platform device whose primary firmware node
is already assigned and is a software node leads to a resource leak as we
never perform the corresponding call to software_node_notify_remove(). As
there are currently no users for this special case - just disallow it and
warn loudly if it ever happens.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-swnode-remove-on-dev-unreg-v8-1-5c2b8cc38c28@oss.qualcomm.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Allow buffer blocks flagged as cyclic to be submitted as repeating DMA
transfers. For cyclic blocks, use DMA_PREP_REPEAT so the engine keeps
replaying the descriptor.
This is useful for output buffers where the same data should be driven
continuously without userspace having to requeue it. Examples include
continuous RF transmit paths replaying a calibration, test or beacon
pattern.
Skip installing the completion callback for cyclic blocks. Since the
transfer is continuously replayed, the callback would fire on every
period, throwing off the block refcount.
Because nothing prevents a new cyclic transfer from replacing an
already active cyclic one, always set DMA_PREP_LOAD_EOT so the engine
correctly terminates the active transfer before loading the new
descriptor.
Limit the DMA buffer queue to one cyclic DMABUF at a time. There is
currently no known use case for queueing multiple cyclic blocks, and
cyclic blocks stay referenced until the buffer is disabled.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Replace sprintf() with sysfs_emit() for single-value sysfs show
functions, and use sysfs_emit_at() for lux_table_show() which
concatenates multiple values. This ensures buffer safety and
follows the modern kernel sysfs API.
Signed-off-by: Chengrui Liu <OrangeBlack0765@outlook.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Most of the supported devices rely on a GAIN pin to control a 2x
multiplier applied to the output voltage. Other devices, e.g. the
single-channel ones, provides a gain control through a bit field in
the control register. Some designs might have the GAIN pin hardwired
to VDD/VLOGIC or GND, which would have no "gain-gpios" device property,
being able to set "adi,range-double" if it is hardwired to VDD. The
vref_mv field is moved down in the struct ad5686_state, so that the
overall size increase is reduced.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Implement trigger handler by leveraging the LDAC gpio to update all DAC
channels at once when it is available. Also, the multiple channel writes
can be flushed at once with the sync() operation.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Use guarded mutex lock to facilitate code review when adding new
attributes. This will allow for early returns, avoiding error-prone
locking and unlocking in error paths. This also adds missing include
linux/cleanup.h. Gain-control support will allow the scale attribute
to be configurable.
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Use of local SPI bus data to manage a collection of SPI transfers and
flush them to the SPI platform driver with the sync() operation. This
allows for faster handling of multiple channel DAC writes, avoiding kernel
overhead per spi_sync() call, which will be helpful when enabling
triggered buffer support. For consistency, the read operation leverages
the same transfer data rather than a stack-allocated array.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Add sync() to operation to ad5686_bus_ops, which can be used to flush
multiple pending data transfers at once. This is going to be used when
implementing triggered buffer support.
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Replace usage of bit shifting macros for FIELD_PREP(), which would not
ignore bit masking when preparing SPI/I2C commands. This change is a code
hardening measure to be paired with the upcoming triggered buffer support.
For the AD5310 regmap case, 16-bit data coming from the buffer may overlap
with command bits if the data field is unmasked.
*_REF_BIT_MSK and *_PD_MSK bit position macros are renamed (with a DATA
prefix) so to indicate that they are relative to the DATA field.
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/all/20260628143026.EC6CA1F000E9@smtp.kernel.org/
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Verify that chip_info pointer is not NULL. If a user binds the driver
using driver_override via sysfs with a device name not present in the
id_table or of_match_table, match data will be NULL.
Fixes: 0eb1728461a1 ("iio: dac: ad5686: drop enum id")
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/all/20260710113149.53EC51F000E9@smtp.kernel.org/
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Shengjiu Wang <shengjiu.wang@nxp.com> says:
Both fsl_asrc_probe() and fsl_easrc_probe() call fsl_asrc_m2m_init()
near the end of their probe functions. On failure, the original code
did a bare return ret, bypassing the existing error labels that call
pm_runtime_disable(). This leaves runtime PM enabled and the device
in an inconsistent state after a failed probe.
Fix both drivers by replacing the bare return with a goto to the
appropriate cleanup label (err_pm_get_sync for fsl_asrc and
err_pm_disable for fsl_easrc), ensuring pm_runtime_disable() is
always called on the probe error path.
Link: https://patch.msgid.link/20260715024758.1252801-1-shengjiu.wang@oss.nxp.com
|
|
When fsl_asrc_m2m_init() fails in fsl_easrc_probe(), the code did a
bare return ret, bypassing pm_runtime_disable() in err_pm_disable.
Use goto err_pm_disable to ensure proper cleanup on failure.
Fixes: b62eaff0650d ("ASoC: fsl_easrc: register m2m platform device")
Cc: stable@vger.kernel.org
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20260715024758.1252801-3-shengjiu.wang@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When fsl_asrc_m2m_init() fails in fsl_asrc_probe(), the code did a
bare return ret, bypassing pm_runtime_disable() in err_pm_get_sync.
Use goto err_pm_get_sync to ensure proper cleanup on failure.
Fixes: 286d658477a4 ("ASoC: fsl_asrc: register m2m platform device")
Cc: stable@vger.kernel.org
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20260715024758.1252801-2-shengjiu.wang@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Robert Marko <robert.marko@sartura.hr> says:
This series adds QSPI support for the Microchip LAN969x which has two QSPI
controllers based on SAMA7G5.
It requires pad calibration, supports DMA, and supports 100 MHz operation.
It requires a different init sequence to SAMA7G5 so support for custom
.init per controller caps is added, and existing controllers relying on
checking gclk are converted to it.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Link: https://patch.msgid.link/20260709112006.390742-1-robert.marko@sartura.hr
|
|
Microchip LAN969x has two QSPI controllers based on SAMA7G5 QSPI.
It requires pad calibration, supports DMA, and supports 100 MHz operation.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Link: https://patch.msgid.link/20260709112006.390742-5-robert.marko@sartura.hr
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Assign the existing SAMA7G5 initialization routine to every generic
clock variant and dispatch initialization exclusively through the
capability callback.
This keeps hardware capabilities separate from initialization selection
and lets variants override the sequence explicitly.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Link: https://patch.msgid.link/20260709112006.390742-4-robert.marko@sartura.hr
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Allow controller variants to provide a custom initialization callback
through their capability data.
This prepares the driver for variants which require a different hardware
initialization sequence without adding SoC checks to the common path.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Link: https://patch.msgid.link/20260709112006.390742-3-robert.marko@sartura.hr
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
LAN969x has 2 QSPI instances, so document their compatible.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Link: https://patch.msgid.link/20260709112006.390742-2-robert.marko@sartura.hr
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In k1_spi_write, the count variable is intended to represent the number
of slots available for writing into the TX FIFO.
The current implementation uses FIELD_GET(SSP_STATUS_TFL, val) in an
attempt to determine this count, but this register field returns the
number of occupied slots, not the available space. The previous
implementation attempted to handle this via a ternary operator (? :
K1_SPI_FIFO_SIZE), which incorrectly assumed that the hardware returned
0 when the FIFO was empty (meaning all slots were available), leading to
incorrect accounting of the buffer space.
Fix this by calculating the free slots: count = K1_SPI_FIFO_SIZE -
FIELD_GET(SSP_STATUS_TFL, val);
The associated comment has been updated to reflect the logic change: The
old comment reflected an incorrect assumption about the hardware
behavior, which was the root cause of the previous buggy logic.
This patch accurately and concisely describes the purpose of the new
calculation.
Signed-off-by: Peixin Xie <peixin.xie@spacemit.com>
Signed-off-by: Zhengyu He <hezhy472013@gmail.com>
Link: https://patch.msgid.link/20260715-k1-spi-tx-fifo-fix-v1-for-next-v1-1-02024223b08a@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add a DMI quirk for the Asus Vivobook Pro 15 M6500RE fixing the
issue where the internal microphone was not detected.
https://bugzilla.kernel.org/show_bug.cgi?id=220806
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260718080949.157230-1-zhangheng@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Mark Brown <broonie@kernel.org> says:
While reviewing another fix for the tas2562 volume control I noticed a
few issues with the put() operation, this series fixes them.
It's also a bit weird that the volume control is defined with twice as
many values as can actually be set, probably the best fix there is to
regnerate the table of volume values with the intermediate values.
Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-0-97bf467c924e@kernel.org
|
|
The tas2562 digital volume is spread over four registers and is implemented
as lookups into a table so the driver stores the value for the userspace
control in the driver data. This defaults to 0 due to kzalloc() but the
register default is 0x40400000 which maps onto something a bit over the
largest value defined in the lookup table. While it's not an exact match
update the default to the largest value, avoiding user surprise due to a
sudden change on first write.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-3-97bf467c924e@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ALSA put() operations should return 0 for noop updates and 1 if the
value of the control changed, this is used by the ALSA core to generate
events to userspace. tas2562_volume_control_put() does not implement
this, it just writes whatever value userspace wrote to the device and
returns 0 regardless of what the previous value was. Fix this by
suppressing writes if the value is unchanged and returning 1 if the
writes succeed.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-2-97bf467c924e@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
tas2562_volume_control_put() does not do any validation of the control
value written by userspace, it uses it to look up a value in a fixed
size array which can easily be overflowed and then writes whatever value
it gets back to the device. Add validation that we are loading a value
we have in the array.
Cc: stable@vger.kernel.org
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260715-asoc-tas2562-put-retval-v1-1-97bf467c924e@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Haidar Lee <haidar.lee@adlinktech.com> says:
The 'Digital Volume Control' added in v5.7 has never worked correctly:
the driver writes the 32-bit DVC coefficient LSB first, but the device
latches the whole coefficient on the write to the last byte (DVC_CFG4),
so every volume change applies a mix of the previous coefficient's
upper bytes and the new LSB. Depending on the sequence of values this
mutes the output entirely or plays at full volume regardless of the
requested level.
Debugged on a TAS2562 (ADLINK OSM-520 / MT8189): traced the I2C writes
with ftrace to confirm the driver writes the intended bytes, then
reproduced both behaviours by writing the same coefficients manually in
each byte order. Patch 1 fixes the write order; patch 2 fixes two wrong
entries in the volume lookup table found while debugging this.
Link: https://patch.msgid.link/20260715-tas2562-dvc-fix-v1-0-072b13901b20@adlinktech.com
|
Colin Ian King
Simon Glass
Wendy Liang
Eric Biggers
David Lechner (TI)
Greg Ungerer
Kurt Borja
Mark Brown
Babanpreet Singh
Bartosz Golaszewski
Nuno Sá
Chengrui Liu
Rodrigo Alencar
Shengjiu Wang
Robert Marko
Zhengyu He
Zhang Heng