* [PATCH v6 16/16] docs: iio: add documentation for ad9910 driver
From: Rodrigo Alencar via B4 Relay @ 2026-06-18 13:27 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
In-Reply-To: <20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com>
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add documentation for the AD9910 DDS IIO driver, which describes channels,
DDS modes, attributes and ABI usage examples.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
Documentation/iio/ad9910.rst | 759 +++++++++++++++++++++++++++++++++++++++++++
Documentation/iio/index.rst | 1 +
MAINTAINERS | 1 +
3 files changed, 761 insertions(+)
diff --git a/Documentation/iio/ad9910.rst b/Documentation/iio/ad9910.rst
new file mode 100644
index 000000000000..113521fead3e
--- /dev/null
+++ b/Documentation/iio/ad9910.rst
@@ -0,0 +1,759 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+AD9910 driver
+=============
+
+Direct Digital Synthesizer (DDS) driver for the Analog Devices Inc. AD9910.
+The module name is ``ad9910``.
+
+* `AD9910 <https://www.analog.com/en/products/ad9910.html>`_
+
+The AD9910 is a 1 GSPS DDS with a 14-bit DAC, controlled over SPI. The driver
+exposes the device through a hierarchy of typed IIO output channels. The root
+``phy`` channel controls the system clock and full-scale output current.
+Sub-channels provide independent control over single tone profiles, parallel
+port modulation, digital ramp generation (DRG), RAM playback and output shift
+keying (OSK).
+
+
+Channel hierarchy
+=================
+
+The driver exposes the following IIO output channels, each identified by a
+unique channel number and a human-readable label. The ``phy`` channel is the
+root of the hierarchy. Changing its ``sampling_frequency`` reconfigures the
+system clock (SYSCLK) which affects all other channels.
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Channel
+ - Label
+ - Parent
+ - Description
+
+ * - ``out_altcurrent100``
+ - ``phy``
+ -
+ - Physical output: system clock and full-scale output current (:math:`I_{FS}`).
+ See `Physical channel`_.
+
+ * - ``out_altcurrent110`` ... ``out_altcurrent117``
+ - ``profile0`` ... ``profile7``
+ - ``phy``
+ - Single tone control: frequency, phase, amplitude, enable.
+ See `Single Tone mode`_.
+
+ * - ``out_altcurrent120``
+ - ``parallel_amplitude``
+ - ``phy``
+ - Parallel port amplitude channel.
+ See `Parallel Port mode`_.
+
+ * - ``out_phase120``
+ - ``parallel_phase``
+ - ``phy``
+ - Parallel port phase channel.
+
+ * - ``out_frequency120``
+ - ``parallel_frequency``
+ - ``phy``
+ - Parallel port frequency channel: ``scale`` sets the FM gain
+ (power-of-2 multiplier), ``offset`` sets the base FTW.
+
+ * - ``out_altcurrent121``
+ - ``parallel_polar_amplitude``
+ - ``phy``
+ - Parallel polar amplitude channel: ``scale`` is the amplitude
+ resolution, ``offset`` is the amplitude bias (lower 6 bits of ASF).
+
+ * - ``out_phase121``
+ - ``parallel_polar_phase``
+ - ``phy``
+ - Parallel polar phase channel: ``scale`` is the phase resolution,
+ ``offset`` is the phase bias (lower 8 bits of POW).
+
+ * - ``out_frequency130``
+ - ``drg_frequency``
+ - ``phy``
+ - DRG frequency channel: ``en`` selects and enables the DRG with
+ frequency as the ramp target.
+
+ * - ``out_phase130``
+ - ``drg_phase``
+ - ``phy``
+ - DRG phase channel: ``en`` selects and enables the DRG with phase
+ as the ramp target.
+
+ * - ``out_altcurrent130``
+ - ``drg_amplitude``
+ - ``phy``
+ - DRG amplitude channel: ``en`` selects and enables the DRG with
+ amplitude as the ramp target.
+ See `Digital ramp generator (DRG)`_.
+
+ * - ``out_altcurrent131``
+ - ``drg_rising``
+ - ``drg_amplitude``
+ - DRG rising-ramp parameters: limit code, dwell enable, ramp clock,
+ rate of change.
+
+ * - ``out_altcurrent132``
+ - ``drg_falling``
+ - ``drg_amplitude``
+ - DRG falling-ramp parameters: limit code, dwell enable, ramp clock,
+ rate of change.
+
+ * - ``out_altcurrent140``
+ - ``ram``
+ - ``phy``
+ - RAM playback: enable, frequency, phase and sampling frequency for
+ the active profile. See `RAM mode`_.
+
+ * - ``out_altcurrent150``
+ - ``osk``
+ - ``phy``
+ - Output shift keying (OSK): enable, amplitude code, ramp rate,
+ rate of change. See `Output Shift Keying (OSK)`_.
+
+DDS modes
+=========
+
+The AD9910 supports multiple modes of operation that can be configured
+independently or in combination. Each DDS core parameter (frequency, phase
+and amplitude) can come from different sources, but only one is active at a
+time. This activation depends on a priority list, which is based on the enable
+and destination configurations for such modes. The following tables are
+extracted from the AD9910 datasheet and summarize the control parameters for
+each mode and their priority when multiple sources are enabled simultaneously:
+
+.. flat-table:: DDS Frequency Control
+ :header-rows: 1
+
+ * - Priority
+ - Data Source
+ - Conditions
+
+ * - Highest Priority
+ - RAM
+ - RAM enabled and data destination is frequency
+
+ * -
+ - DRG
+ - DRG enabled and data destination is frequency
+
+ * -
+ - Parallel data and Frequency Tuning Word, FTW (frequency_offset)
+ - Parallel data port enabled and data destination is frequency
+
+ * -
+ - FTW register (frequency)
+ - RAM enabled and data destination is not frequency
+
+ * - Lowest Priority
+ - FTW (frequency) in single tone channel for the active profile
+ - All other cases
+
+.. flat-table:: DDS Phase Control
+ :header-rows: 1
+
+ * - Priority
+ - Data Source
+ - Conditions
+
+ * - Highest Priority
+ - RAM
+ - RAM enabled and data destination is phase or polar
+
+ * -
+ - DRG
+ - DRG enabled and data destination is phase
+
+ * -
+ - Parallel data port
+ - Parallel data port enabled and data destination is phase
+
+ * -
+ - Parallel data port and Phase Offset Word, POW register LSBs (phase_offset)
+ - Parallel data port enabled and data destination is polar
+
+ * -
+ - POW register (phase)
+ - RAM enabled and destination is not phase nor polar
+
+ * - Lowest Priority
+ - POW (phase) in single tone channel for the active profile
+ - All other cases
+
+.. flat-table:: DDS Amplitude Control
+ :header-rows: 1
+
+ * - Priority
+ - Data Source
+ - Conditions
+
+ * - Highest Priority
+ - Amplitude Scale Factor, ASF register and OSK generator
+ - OSK enabled
+
+ * -
+ - RAM
+ - RAM enabled and data destination is amplitude or polar
+
+ * -
+ - DRG
+ - DRG enabled and data destination is amplitude
+
+ * -
+ - Parallel data port
+ - Parallel data port enabled and data destination is amplitude
+
+ * -
+ - Parallel data port and ASF register LSBs (scale_offset)
+ - Parallel data port enabled and data destination is polar
+
+ * - Lowest Priority
+ - ASF (scale) in single tone channel for the active profile
+ - (Amplitude scale is already enabled by default)
+
+While debugging or testing, the debug attributes ``frequency_source``,
+``phase_source`` and ``amplitude_source`` can be used to read the label of
+the channel that is actively controlling the correspondent DDS parameter,
+which reflects the priority list described above.
+
+Single Tone mode
+----------------
+
+Single tone is the baseline operating mode. The ``profileY`` channels
+provide enable, frequency, phase and amplitude control:
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``en``
+ - boolean (0 or 1)
+ - Enable/disable profile Y. Only one profile can be active at a
+ time. When enabling a profile it disables the current active profile.
+ Disabling an active profile brings the device to a powered down state.
+
+ * - ``frequency``
+ - Hz
+ - Output frequency. Range :math:`[0, f_{SYSCLK}/2)`. Stored in the
+ profile's frequency tuning word (FTW).
+
+ * - ``phase``
+ - rad
+ - Phase offset. Range :math:`[0, 2\pi)`. Stored in the profile's phase
+ offset word (POW).
+
+ * - ``raw``
+ - integer
+ - Amplitude scale factor code. Range :math:`[0, 16383]`. Stored in the
+ profile's amplitude scale factor (ASF) register. The physical output
+ amplitude is ``raw * scale`` where ``scale`` is read from the ``phy``
+ channel.
+
+Profile switching is allowed while RAM mode is enabled. In that case single
+tone parameters are stored in a shadow register and are not written to
+hardware until RAM mode is disabled.
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Configure a 100 MHz tone in profile 2 and set it as the active profile:
+
+.. code-block:: bash
+
+ echo 100000000 > /sys/bus/iio/devices/iio\:device0/out_altcurrent112_frequency
+ echo 0 > /sys/bus/iio/devices/iio\:device0/out_altcurrent112_phase
+ echo 16383 > /sys/bus/iio/devices/iio\:device0/out_altcurrent112_raw
+
+ # Activate profile 2
+ echo 1 > /sys/bus/iio/devices/iio\:device0/out_altcurrent112_en
+
+Read back the current single tone frequency:
+
+.. code-block:: bash
+
+ cat /sys/bus/iio/devices/iio\:device0/out_altcurrent112_frequency
+
+Parallel Port mode
+------------------
+
+The parallel port allows real-time modulation of DDS parameters through a
+16-bit external data bus. The driver exposes separate typed channels for each
+modulation target.
+
+Non-polar modulation
+^^^^^^^^^^^^^^^^^^^^
+
+In non-polar mode each DDS parameter is controlled by an independent 16-bit bus
+input. The parallel port channels expose the resolution and base offset of their
+respective bus inputs:
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Channel
+ - Attribute
+ - Unit
+ - Description
+
+ * - ``out_phase120``
+ - ``scale``
+ - rad
+ - Phase resolution per parallel bus LSB. Fixed at :math:`\pi / 2^{15}`
+ rad/LSB (full 16-bit POW resolution).
+
+ * - ``out_frequency120``
+ - ``scale``
+ - Hz
+ - Outputs the frequency scale evaluated as
+ :math:`f_{SYSCLK} \cdot FM / 2^{32}`. Assuming that :math:`f_{SYSCLK}` is
+ fixed, it is used to configure the modulation gain :math:`FM`, which is a
+ power-of-2 multiplier in range :math:`[1, 32768]`. Writing to this
+ attribute rounds up to the nearest :math:`FM` power of 2.
+
+ * - ``out_frequency120``
+ - ``offset``
+ - Hz
+ - Outputs the frequency offset in raw units evaluated as :math:`FTW / FM`.
+ Assuming that :math:`FM` is fixed, it is used to configure the FTW
+ register, which is a 32-bit unsigned integer.
+
+Polar modulation
+^^^^^^^^^^^^^^^^
+
+In polar mode a single 16-bit bus word carries both amplitude (high byte)
+and phase (low byte). The ``parallel_polar_amplitude`` and
+``parallel_polar_phase`` channels configure the bias applied to the low-order
+bits of the ASF and POW registers respectively:
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Channel
+ - Attribute
+ - Unit
+ - Description
+
+ * - ``out_altcurrent121``
+ - ``scale``
+ - mA/LSB
+ - Full-scale amplitude resolution (read-only, fixed at :math:`I_{FS} / 2^{8}`).
+
+ * - ``out_altcurrent121``
+ - ``offset``
+ - fractional (raw units)
+ - Amplitude bias. Lower 6 bits of ASF register. Range :math:`[0, 1)`.
+
+ * - ``out_phase121``
+ - ``scale``
+ - rad/LSB
+ - Phase resolution (read-only, fixed at :math:`\pi / 2^{7}`).
+
+ * - ``out_phase121``
+ - ``offset``
+ - fractional (raw units)
+ - Phase bias. Lower 8 bits of POW register. Range :math:`[0, 1)`.
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Set parallel port frequency modulation with a modulation gain of 16 and a 50 MHz
+offset:
+
+.. code-block:: bash
+
+ # f_SYSCLK = 1 GHz, FM = 16
+ # frequency scale = f_SYSCLK * FM / 2^32 = 3.725290298
+ echo 3.725290298 > /sys/bus/iio/devices/iio\:device0/out_frequency120_scale
+ # frequency offset = 50 MHz / scale = 50e6 / 13421772.8
+ echo 13421772.8 > /sys/bus/iio/devices/iio\:device0/out_frequency120_offset
+
+One should choose a frequency scale that allows all the desired frequencies
+to be represented in the 16-bit bus range, i.e.,
+:math:`scale = (f_{max} - f_{min}) / 2^{16}`.
+
+
+Digital ramp generator (DRG)
+----------------------------
+
+The DRG produces linear frequency, phase or amplitude sweeps using dedicated
+hardware. The active ramp target (destination) is selected by enabling the
+corresponding typed channel at channel number 130:
+
+- ``out_frequency130`` (label ``drg_frequency``) — ramp targets frequency
+- ``out_phase130`` (label ``drg_phase``) — ramp targets phase
+- ``out_altcurrent130`` (label ``drg_amplitude``) — ramp targets amplitude
+
+Writing ``en=1`` to one of these channels enables the DRG and switches its
+destination. Writing ``en=0`` disables the DRG if the channel is the current
+active destination; writing to an already-inactive destination is a no-op.
+
+Each destination channel also exposes a read-only ``scale`` attribute
+reporting the physical quantity per ramp register LSB, which allows converting
+raw limit codes to physical values.
+
+The two ramp channels ``out_altcurrent131`` (``drg_rising``) and
+``out_altcurrent132`` (``drg_falling``) configure ascending and descending
+ramp parameters independently.
+
+Destination channel attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``en``
+ - boolean
+ - Enable the DRG with this channel as the active destination. Only one
+ destination can be active at a time.
+
+ * - ``scale``
+ - Hz/LSB, rad/LSB or mA/LSB
+ - Read-only. Physical quantity per raw units. Multiply a ramp
+ rising/falling channel ``raw`` value by this scale to get the physical
+ ramp target.
+
+Ramp channel attributes
+^^^^^^^^^^^^^^^^^^^^^^^
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``dwell_en``
+ - boolean
+ - Enable dwell at the ramp limit. When disabled, the ramp
+ auto-transitions at this limit without waiting for the DRCTL pin.
+ Disabling both creates a bidirectional continuous ramp (triangular
+ pattern). Other combinations create single-shot ramps at the DRCTL
+ pin transition.
+
+ * - ``raw``
+ - integer (64-bit)
+ - Ramp limit expressed as a raw DRG register code in
+ :math:`[0, 2^{32}-1]`. The physical value is ``raw * scale`` where
+ ``scale`` is read from the active destination channel.
+
+ * - ``sampling_frequency``
+ - Hz
+ - Ramp clock rate. Controlled by an integer divider; the written value
+ is adjusted to the nearest supported rate.
+
+ * - ``raw_roc``
+ - /s
+ - Rate of change. Number of register codes advanced per second, computed
+ from the hardware step size and the current ramp clock. Writing
+ requires ``sampling_frequency`` to be configured first.
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Configure a frequency sweep from 40 MHz to 60 MHz with a rate of change of
+25 GHz/s:
+
+.. code-block:: bash
+
+ # Disable dwell on both limits for a bidirectional continuous ramp
+ echo 0 > /sys/bus/iio/devices/iio\:device0/out_altcurrent131_dwell_en
+ echo 0 > /sys/bus/iio/devices/iio\:device0/out_altcurrent132_dwell_en
+
+ # Set ramp rate at 250 MHz
+ echo 250000000 > /sys/bus/iio/devices/iio\:device0/out_altcurrent131_sampling_frequency
+ echo 250000000 > /sys/bus/iio/devices/iio\:device0/out_altcurrent132_sampling_frequency
+
+ # read the frequency scale to convert physical values to raw units
+ cat /sys/bus/iio/devices/iio\:device0/out_frequency130_scale
+ 0.232830643650
+
+ # 40 MHz / 0.232830643650 = 171798692
+ echo 171798692 > /sys/bus/iio/devices/iio\:device0/out_altcurrent131_raw
+ # 60 MHz / 0.232830643650 = 257698038
+ echo 257698038 > /sys/bus/iio/devices/iio\:device0/out_altcurrent132_raw
+
+ # 25 GHz/s / 0.232830643650 = 107374182402
+ echo 107374182402 > /sys/bus/iio/devices/iio\:device0/out_altcurrent131_raw_roc
+ echo 107374182402 > /sys/bus/iio/devices/iio\:device0/out_altcurrent132_raw_roc
+
+ # Enable the DRG with frequency as the destination
+ echo 1 > /sys/bus/iio/devices/iio\:device0/out_frequency130_en
+
+RAM mode
+--------
+
+The AD9910 contains a 1024 x 32-bit RAM that can be loaded with waveform data
+and played back to modulate frequency, phase, amplitude, or polar (phase +
+amplitude) parameters.
+
+RAM control channel attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``en``
+ - boolean
+ - Enable/disable RAM playback. Toggling swaps profile registers between
+ single tone and RAM configurations across all 8 profiles.
+
+ * - ``frequency``
+ - Hz
+ - Frequency tuning word used as the single tone frequency when
+ RAM destination is not ``frequency``. Range: :math:`[0, f_{SYSCLK}/2)`.
+
+ * - ``phase``
+ - rad
+ - Phase offset word used as the single tone phase when RAM destination
+ is not ``phase``. Range: :math:`[0, 2\pi)`.
+
+ * - ``sampling_frequency``
+ - Hz
+ - RAM playback step rate of the active profile, which controls how fast
+ the address counter advances. Controlled by an integer divider; the
+ written value is adjusted to the nearest supported rate.
+
+Loading RAM data
+^^^^^^^^^^^^^^^^
+
+RAM data is loaded through the firmware upload framework. The driver registers
+a firmware upload sysfs entry named ``iio_deviceX:ram``. The firmware data
+follows a binary format (version 1) with an 80-byte header followed by data
+words. All fields are big-endian.
+
+.. flat-table:: RAM firmware header (80 bytes)
+ :header-rows: 1
+
+ * - Offset
+ - Size
+ - Field
+ - Description
+
+ * - 0
+ - 4
+ - ``magic``
+ - Magic number: ``0x00AD9910``
+
+ * - 4
+ - 2
+ - ``version``
+ - Format version: ``0x0001``
+
+ * - 6
+ - 2
+ - ``wcount``
+ - Number of 32-bit RAM data words (0--1024)
+
+ * - 8
+ - 4
+ - ``crc``
+ - CRC32 checksum over ``cfr1``, ``profiles`` and ``words``
+
+ * - 12
+ - 4
+ - ``cfr1``
+ - CFR1 register value. Only RAM-relevant bits are used:
+ bits [30:29] set data destination (00: frequency, 01: phase,
+ 10: amplitude, 11: polar); bits [20:17] set internal profile
+ control (see datasheet Table 14)
+
+ * - 16
+ - 64
+ - ``profiles[0..7]``
+ - 8 sets of 8-byte RAM profile configurations (see below)
+
+ * - 80
+ - 4 x wcount
+ - ``words[]``
+ - RAM data words in reverse order
+
+Each 8-byte profile entry contains:
+
+.. flat-table:: RAM profile entry (8 bytes)
+ :header-rows: 1
+
+ * - Bits
+ - Field
+ - Description
+
+ * - [55:40]
+ - Address step rate
+ - Controls playback speed for this profile
+
+ * - [39:30]
+ - End address
+ - Last RAM address for this profile
+
+ * - [23:14]
+ - Start address
+ - First RAM address for this profile
+
+ * - [5]
+ - No-dwell high
+ - No-dwell at high limit (ramp-up mode)
+
+ * - [3]
+ - Zero-crossing
+ - Zero-crossing enable (direct-switch mode)
+
+ * - [2:0]
+ - Operating mode
+ - 000: direct switch, 001: ramp-up, 010: bidirectional,
+ 011: bidirectional continuous, 100: ramp-up continuous
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Configure RAM mode with firmware data and enable it:
+
+.. code-block:: bash
+
+ # Load RAM data via firmware upload
+ echo 1 > /sys/class/firmware/iio\:device0\:ram/loading
+ cat ad9910-ram.bin > /sys/class/firmware/iio\:device0\:ram/data
+ echo 0 > /sys/class/firmware/iio\:device0\:ram/loading
+
+ # Enable RAM mode
+ echo 1 > /sys/bus/iio/devices/iio\:device0/out_altcurrent140_en
+
+Output Shift Keying (OSK)
+-------------------------
+
+OSK controls the output amplitude envelope, allowing the output to be ramped
+on/off rather than switched abruptly.
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``en``
+ - boolean (0 or 1)
+ - Enable/disable OSK.
+
+ * - ``raw``
+ - integer
+ - Target amplitude code. 14-bit ASF field. Range: :math:`[0, 16383]`.
+ The physical output amplitude is ``raw * scale`` where ``scale`` is read
+ from the ``phy`` channel.
+
+ * - ``raw_roc``
+ - /s
+ - Amplitude ramp rate. Writing a non-zero value enables automatic OSK
+ and selects the closest hardware step size. Writing ``0`` disables
+ automatic ramping (manual control via ``raw``). Writing the maximum
+ available value enables pin-controlled immediate transition.
+
+ * - ``raw_roc_available``
+ - /s
+ - Lists the available ``raw_roc`` values based on the current
+ ``sampling_frequency``. The first value is always ``0`` (disabled) and
+ the last value corresponds to pin-controlled immediate mode.
+
+ * - ``sampling_frequency``
+ - Hz
+ - OSK ramp clock. Controlled by an integer divider; the written value
+ is adjusted to the nearest supported rate.
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Enable OSK with automatic ramping:
+
+.. code-block:: bash
+
+ # Set ramp rate 1MHz
+ echo 1000000 > /sys/bus/iio/devices/iio\:device0/out_altcurrent150_sampling_frequency
+
+ # Check available rate of change values
+ cat /sys/bus/iio/devices/iio\:device0/out_altcurrent150_raw_roc_available
+ 0 1000000 2000000 4000000 8000000 16383000000
+
+ # Enable automatic OSK with a rate of change of 8000000 raw units/s
+ echo 8000000 > /sys/bus/iio/devices/iio\:device0/out_altcurrent150_raw_roc
+
+ # Enable OSK
+ echo 1 > /sys/bus/iio/devices/iio\:device0/out_altcurrent150_en
+
+Enable pin-controlled immediate OSK:
+
+.. code-block:: bash
+
+ # Enable OSK in manual mode (no ramp)
+ echo 0 > /sys/bus/iio/devices/iio\:device0/out_altcurrent150_raw_roc
+ echo 1 > /sys/bus/iio/devices/iio\:device0/out_altcurrent150_en
+
+ # Set target amplitude to full scale
+ echo 16383 > /sys/bus/iio/devices/iio\:device0/out_altcurrent150_raw
+
+Physical channel
+================
+
+The ``phy`` channel provides device-level control:
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``sampling_frequency``
+ - Hz
+ - System clock (SYSCLK) frequency. When the internal PLL is enabled
+ (via the ``adi,pll-enable`` devicetree property), configures the PLL
+ multiplier (Range: :math:`[420, 1000]` MHz). Without PLL, the reference
+ clock can only be divided by 2.
+
+ * - ``scale``
+ - mA/LSB
+ - Full-scale DAC output current per amplitude code LSB, which is evaluated
+ as :math:`I_{FS}/2^{14}`. Shared across all ``altcurrent`` channels.
+ Setting this attribute reconfigures the auxiliary DAC full-scale code and
+ updates the effective amplitude resolution for single tone profiles,
+ DRG amplitude ramps and OSK.
+
+ * - ``powerdown``
+ - boolean (0 or 1)
+ - Software power-down. Writing 1 powers down the digital core, DAC,
+ reference clock input and auxiliary DAC simultaneously.
+
+Usage examples
+--------------
+
+Set the system clock to 1 GHz:
+
+.. code-block:: bash
+
+ echo 1000000000 > /sys/bus/iio/devices/iio\:device0/out_altcurrent100_sampling_frequency
+
+Read current system clock frequency:
+
+.. code-block:: bash
+
+ cat /sys/bus/iio/devices/iio\:device0/out_altcurrent100_sampling_frequency
+
+Power down the device:
+
+.. code-block:: bash
+
+ echo 1 > /sys/bus/iio/devices/iio\:device0/out_altcurrent100_powerdown
\ No newline at end of file
diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
index b02b879b053a..4c30ef033685 100644
--- a/Documentation/iio/index.rst
+++ b/Documentation/iio/index.rst
@@ -30,6 +30,7 @@ Industrial I/O Kernel Drivers
ad7606
ad7625
ad7944
+ ad9910
ade9000
adf41513
adis16475
diff --git a/MAINTAINERS b/MAINTAINERS
index a76a15f02183..38e7fd5e3c34 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1652,6 +1652,7 @@ S: Supported
W: https://ez.analog.com/linux-software-drivers
F: Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910
F: Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
+F: Documentation/iio/ad9910.rst
F: drivers/iio/frequency/ad9910.c
ANALOG DEVICES INC MAX22007 DRIVER
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 12/12] rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
From: Lad, Prabhakar @ 2026-06-18 13:28 UTC (permalink / raw)
To: Wolfram Sang
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <ajKAqn1F074JJazF@shikoro>
Hi Wolfram,
Thank you for the review.
On Wed, Jun 17, 2026 at 12:10 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> On Mon, Jun 15, 2026 at 04:48:05PM +0100, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Add a new compatible string "renesas,r9a09g077-rtc" to the OF match table
> > to support the RTC IP variant found on the RZ/T2H and RZ/N2H SoCs.
> >
> > These newer SoCs integrate a closely related variant of the RZ/N1 RTC IP.
> > The RZ/T2H and RZ/N2H variants lack the RTCA0SUBU and RTCA0TCR registers,
>
> The RTCA0TCR is also not on RZ/N1.
>
Ah, right I missed "Not available in this LSI.", I will update the
description accordingly in v2.
Cheers,
Prabhakar
> > those registers are not accessed or used when operating under the
> > rzn1_rtc_ops_scmp configurations, making the current infrastructure
> > compatible.
> >
> > The RZ/T2H RTC variant also supports a 1 Hz output signal on the
> > RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
> > marked as reserved in the RZ/N1 hardware manual, making RZ/T2H a
> > distinct RTC variant despite its overall compatibility with the RZ/N1
> > implementation.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> With that fixed:
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sc8280xp: add missing QUP pinctrl states
From: Konrad Dybcio @ 2026-06-18 13:29 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260507-sc8280xp-qup-pinctrl-v1-1-8950644af141@radxa.com>
On 5/7/26 4:44 PM, Xilin Wu wrote:
> Add the missing tlmm pinctrl states for the SC8280XP QUP engines so common
> I2C, SPI and UART pinmux definitions are available from the SoC dtsi.
> Populate all 24 engines using the SC8280XP lane-to-GPIO mapping, including
> the non-linear QUP instances, and keep the mux function names aligned with
> the driver-supported qup0..qup23 names.
>
> Move UART electrical settings out of the shared SoC pinctrl states and
> into the board dts files that need them. Update the boards that currently
> duplicate uart2 pinctrl definitions to reference qup_uart2_default and
> override only the required bias and drive properties locally, and do the
> same for Arcata's uart18 configuration. This reduces duplicated pinctrl
> data and keeps the shared SC8280XP states reusable for future QUP users.
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
[...]
> + qup_uart0_default: qup-uart0-default-state {
> + qup_uart0_cts: cts-pins {
> + pins = "gpio135";
> + function = "qup0";
> + };
> + qup_uart0_rts: rts-pins {
> + pins = "gpio136";
> + function = "qup0";
> + };
> + qup_uart0_tx: tx-pins {
> + pins = "gpio137";
> + function = "qup0";
> + };
> + qup_uart0_rx: rx-pins {
> + pins = "gpio138";
> + function = "qup0";
> + };
> + };
I find this overly verbose. Let's go for something like in glymur.dtsi,
where the common defaults are defined. I think we can even keep the
bluetooth/4way-uart configuration default as 99.999% boards will use
that
Konrad
^ permalink raw reply
* Re: [RFC PATCH net-next v8 11/12] net: pcs: airoha: add PCS driver for Airoha AN7581 SoC
From: Benjamin Larsson @ 2026-06-18 13:30 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm, Maxime Chevallier
In-Reply-To: <20260618125752.1223-12-ansuelsmth@gmail.com>
Hi.
On 18/06/2026 14:57, Christian Marangi wrote:
> Add PCS driver for Airoha AN7581 SoC for Ethernet/PON/PCIe/USB SERDES
> and permit usage of external PHY or connected SFP cage. Supported modes
> are USXGMII, 10G-BASER, 2500BASE-X, 1000BASE-X and SGMII.
>
> The driver probe and register the various needed registers and register as
> a PCS provider for fwnode usage.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/pcs/Kconfig | 2 +
> drivers/net/pcs/Makefile | 2 +
> drivers/net/pcs/airoha/Kconfig | 12 +
> drivers/net/pcs/airoha/Makefile | 7 +
> drivers/net/pcs/airoha/pcs-airoha-common.c | 1324 +++++++++++++
> drivers/net/pcs/airoha/pcs-airoha.h | 1311 ++++++++++++
> drivers/net/pcs/airoha/pcs-an7581.c | 2093 ++++++++++++++++++++
> 7 files changed, 4751 insertions(+)
> create mode 100644 drivers/net/pcs/airoha/Kconfig
> create mode 100644 drivers/net/pcs/airoha/Makefile
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha-common.c
> create mode 100644 drivers/net/pcs/airoha/pcs-airoha.h
> create mode 100644 drivers/net/pcs/airoha/pcs-an7581.c
My comment that the files should be renamed now instead of later when
support for other airoha platforms are added still stands. The common
code is not common among other platforms (EN7523 as example).
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH v6 07/16] iio: core: add hierarchical channel relationships
From: sashiko-bot @ 2026-06-18 13:33 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260618-ad9910-iio-driver-v6-7-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message claims the new attribute returns the 'parent channel label', but the implementation actually returns the parent channel's sysfs prefix.
--
commit 1d085ae0a672cb964aa54dcb759867393a24b06b
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: core: add hierarchical channel relationships
This commit adds a parent-child relationship between IIO channels. It
introduces a parent pointer field in the iio_chan_spec struct and exposes a
sysfs attribute for userspace to read the parent channel information.
> Add parent-child relationship between iio channels by creating a parent
> pointer field in iio_chan_spec struct and exposing a sysfs attribute that
> returns the parent channel label.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 9373006235c87..3d12269f26f4a 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -854,6 +854,21 @@ static ssize_t iio_read_channel_label(struct device *dev,
> to_iio_dev_attr(attr)->c, buf);
> }
>
> +static ssize_t iio_read_channel_parent(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + const struct iio_chan_spec *parent = to_iio_dev_attr(attr)->c->parent;
> + int len;
> +
> + len = __iio_chan_prefix_emit(parent, IIO_SEPARATE, buf, PAGE_SIZE - 1);
[Severity: Medium]
Is the commit description accurate regarding what this attribute returns?
The commit message states it returns the parent channel label. However,
looking at iio_read_channel_parent() in drivers/iio/industrialio-core.c,
this implementation uses __iio_chan_prefix_emit() to return the parent
channel's sysfs prefix instead (e.g., in_voltage0).
While returning the sysfs prefix makes sense for userspace to locate the
parent channel, using the term label in the commit message breaks IIO API
terminology. Could the commit message be updated to state that it returns
the sysfs prefix rather than the label?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=7
^ permalink raw reply
* Re: [PATCH v6 08/16] dt-bindings: iio: frequency: add ad9910
From: sashiko-bot @ 2026-06-18 13:35 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260618-ad9910-iio-driver-v6-8-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `#clock-cells` property is missing from the `required` list and the `examples` section, violating Device Tree subsystem guidelines.
- [Medium] The commit message claims to include 'DAC current' configurations, but no such property exists in the schema.
- [Low] The `reset-gpios` property is missing the `maxItems: 1` constraint.
--
commit 14de29fc570f7c4ee9b2e39250151ecb7c9edb56
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
dt-bindings: iio: frequency: add ad9910
DT-bindings for AD9910, a 1 GSPS DDS with 14-bit DAC. It includes
configurations for clocks, DAC current, reset and basic GPIO control.
> DT-bindings for AD9910, a 1 GSPS DDS with 14-bit DAC. It includes
> configurations for clocks, DAC current, reset and basic GPIO control.
[Severity: Medium]
The commit message states the binding includes configurations for
"DAC current". Does the schema actually define this property?
Looking at the schema, there is adi,charge-pump-current-microamp for the
PLL charge pump, but no property appears to configure the DAC current.
Could the commit message be updated to match the schema, or is the DAC current
property missing from the YAML?
> diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
> new file mode 100644
> index 0000000000000..a78fe33ba21f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
[ ... ]
> + avdd18-supply:
> + description: 1.8V Analog Core supply.
> +
> + reset-gpios:
> + description:
> + GPIOs controlling the Main Device reset.
[Severity: Low]
Should reset-gpios have a maxItems: 1 constraint?
Unlike io-reset-gpios and powerdown-gpios below, this property lacks a
maxItems constraint. In dt-schema, properties ending in -gpios allow an
array of GPIOs unless explicitly constrained.
This omission allows invalid device tree configurations with multiple reset
GPIOs to pass schema validation.
> + io-reset-gpios:
> + maxItems: 1
> + description:
> + GPIO controlling the I/O_RESET pin.
[ ... ]
> +required:
> + - compatible
> + - reg
> + - clocks
> + - dvdd-io33-supply
> + - avdd33-supply
> + - dvdd18-supply
> + - avdd18-supply
[Severity: High]
Should #clock-cells be included in this required list?
According to the Device Tree Bindings subsystem guidelines, when hardware
defines provider capabilities (acting as a clock provider as indicated by
the #clock-cells: const: 1 property defined earlier in this schema), the
corresponding standard properties must be explicitly included in the
required list.
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dds@0 {
> + compatible = "adi,ad9910";
> + reg = <0>;
[Severity: High]
Does this example need the #clock-cells property?
The example device tree node is missing the #clock-cells property.
Subsystem guidelines dictate that the examples section must demonstrate
all required properties to pass dt_binding_check validation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=8
^ permalink raw reply
* Re: [PATCH v3 3/3] media: i2c: os02g10: implement crop handling with set_selection
From: Sakari Ailus @ 2026-06-18 13:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Elgin Perumbilly, Tarang Raval, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hans Verkuil,
Hans de Goede, Vladimir Zapolskiy, Mehdi Djait, Sylvain Petinot,
Benjamin Mugnier, Bryan O'Donoghue, Heimir Thor Sverrisson,
Hardevsinh Palaniya, linux-media, devicetree, linux-kernel
In-Reply-To: <20260618130253.GF3345533@killaraus.ideasonboard.com>
Hi Laurent,
On Thu, Jun 18, 2026 at 04:02:53PM +0300, Laurent Pinchart wrote:
> On Thu, Jun 18, 2026 at 02:47:23PM +0300, Sakari Ailus wrote:
> > Hi Elgin,
> >
> > On Fri, Apr 24, 2026 at 02:55:47PM +0530, Elgin Perumbilly wrote:
> > > From: Tarang Raval <tarang.raval@siliconsignals.io>
> > >
> > > Add crop support to os02g10 by implementing .set_selection() and
> > > storing the crop rectangle in subdev state.
> > >
> > > Initialize the default crop to the active area, make set_fmt() use the
> > > current crop, and update the output format when the crop size changes.
> > > Also program the sensor window from the active crop/format state instead
> > > of using the fixed supported_modes entry.
> > >
> > > This allows userspace to configure the sensor crop window explicitly.
> >
> > Please wait for the Common Raw Sensor Model patches to be merged before
> > adding this -- we don't have an established way to configure cropping
> > before that. Some drivers might do something but it's all a bit haphazard.
>
> Does it mean we should wait for the raw sensor model to merge this
> driver ?
I only suggested this for the 3rd patch.
>
> Many existing drivers configure analog crop the same way, through the
> crop selection rectangle on the source pad. Is there harm in doing so
> already ? I wouldn't enable binning and skipping yet, that I agree with.
Which ones?
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v6 09/16] iio: frequency: ad9910: initial driver implementation
From: sashiko-bot @ 2026-06-18 13:37 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260618-ad9910-iio-driver-v6-9-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hardware sequencing violation: reference clock and GPIO powerdown action are initialized before device regulators, causing backpowering.
--
commit 71fb9226243ea37baeab1cd6841703ff6cde346d
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
Subject: iio: frequency: ad9910: initial driver implementation
This commit adds the core AD9910 DDS driver infrastructure with single tone
mode support, including SPI register access, profile management via GPIO pins,
and PLL/DAC configuration from firmware properties.
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> new file mode 100644
> index 0000000000000..95b01295e4a0a
> --- /dev/null
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> +static int ad9910_probe(struct spi_device *spi)
> +{
[ ... ]
> + st->refclk = devm_clk_get_enabled(dev, "ref_clk");
> + if (IS_ERR(st->refclk))
> + return dev_err_probe(dev, PTR_ERR(st->refclk),
> + "Failed to get reference clock\n");
[ ... ]
> + st->gpio_pwdown = devm_gpiod_get_optional(dev, "powerdown",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(st->gpio_pwdown))
> + return dev_err_probe(dev, PTR_ERR(st->gpio_pwdown),
> + "failed to get powerdown gpio\n");
> +
> + ret = devm_add_action_or_reset(dev, ad9910_hw_powerdown_action, st);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "failed to add hw powerdown action\n");
> +
> + ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(supplies), supplies);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to get regulators\n");
[Severity: High]
Could this initialization order cause the device to be backpowered?
In ad9910_probe(), the reference clock is enabled and the hardware powerdown
cleanup action is registered before the device's regulators are enabled. This
might drive an active clock signal into the unpowered IC during the probe
sequence.
Additionally, because devres executes cleanup actions in reverse order (LIFO),
if a probe failure occurs later or the driver unbinds, the regulators will be
turned off first. The powerdown GPIO would then be driven high and the
reference clock would continue to toggle into an unpowered chip until they
are subsequently disabled.
Driving active digital signals into an unpowered CMOS device forward-biases
its internal ESD protection diodes, which can lead to latch-up or permanent
hardware damage. Should the regulators be enabled prior to applying any
clock or active GPIO signals?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=9
^ permalink raw reply
* [PATCH v2 0/2] Add driver for TI BQ25630 charger
From: Waqar Hameed @ 2026-06-18 13:37 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, linux-kernel, linux-pm, devicetree
This patch series contains a fully working driver for the basic
functionality for the new TI BQ25630 charger (see datasheet [1]). The
other "advanced" functionalities such as USB OTG, BATFET control and
liquid detection, will be handled in separate patches (after necessary
framework changes) according to the design discussions in the first RFC
version.
[1] https://www.ti.com/lit/gpn/bq25630
Changes in v2:
[power]
* Fix return value check for `data->regmap16be` initialization in probe
(check was wrongly for `data->regmap16le`).
* Remove TODO-comment about BATFET `sysfs` ABI (we will add a new sysfs
ABI entry in the framework for this).
* Check registers `BQ25630_REG_CHARGER_STATUS_X` as well in IRQ handler.
Because there might be changes that is not necessarily *only*
triggered from hardware faults. For example, manually
enabling/disabling with `echo 0 > /online`.
[dt-bindings]
* Rename file with `ti,` prefix.
* Remove battery-node in example.
Link to v1: https://lore.kernel.org/lkml/cover.1772201049.git.waqar.hameed@axis.com/
Waqar Hameed (2):
dt-bindings: power: supply: Add TI BQ25630 charger
power: supply: Add driver for TI BQ25630 charger
.../bindings/power/supply/ti,bq25630.yaml | 59 +
drivers/power/supply/Kconfig | 7 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/bq25630_charger.c | 1073 +++++++++++++++++
4 files changed, 1140 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml
create mode 100644 drivers/power/supply/bq25630_charger.c
base-commit: e771677c937da5808f7b6c1f0e4a97ec1a84f8a8
prerequisite-patch-id: 7dfa938b45374a748d43880f3e8416e665134104
prerequisite-patch-id: c22d643d2a260a8dbcc92df0754cfdb480879578
prerequisite-patch-id: 12e94680b398a795657d3d2addcf55bed5ce62de
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: power: supply: Add TI BQ25630 charger
From: Waqar Hameed @ 2026-06-18 13:37 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, linux-pm, devicetree, linux-kernel
In-Reply-To: <cover.1781789320.git.waqarh@axis.com>
Add devicetree bindings for the TI BQ25630 battery charger. It's I2C
controlled and sends interrupts.
Signed-off-by: Waqar Hameed <waqar.hameed@axis.com>
---
.../bindings/power/supply/ti,bq25630.yaml | 59 +++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml b/Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml
new file mode 100644
index 0000000000000..1e2c7aacb26d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/ti,bq25630.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/ti,bq25630.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI BQ25630 battery charger
+
+maintainers:
+ - Waqar Hameed <waqar.hameed@axis.com>
+
+description: |
+ I2C controlled single cell Li-ion and Li-polymer 5A buck charger.
+ Datasheet: https://www.ti.com/lit/gpn/bq25630
+
+allOf:
+ - $ref: power-supply.yaml#
+
+properties:
+ compatible:
+ const: ti,bq25630
+
+ reg:
+ const: 0x6b
+ description:
+ Device I2C address.
+
+ interrupts:
+ maxItems: 1
+ description: |
+ Device sends active low 256 µs pulse. Type should therefore be
+ IRQ_TYPE_EDGE_FALLING.
+
+ monitored-battery: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - monitored-battery
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ charger@6b {
+ compatible = "ti,bq25630";
+ reg = <0x6b>;
+ interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+ monitored-battery = <&bat>;
+ };
+ };
+...
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 10/16] iio: frequency: ad9910: add basic parallel port support
From: sashiko-bot @ 2026-06-18 13:41 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260618-ad9910-iio-driver-v6-10-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [Medium] 32-bit truncation in the parallel frequency scale calculation causes incorrect readback.
- [Medium] 64-bit integer overflow in parallel frequency offset calculation circumvents U32_MAX capping.
- [Medium] `roundup_pow_of_two` truncates 64-bit scale calculation on 32-bit architectures.
- [Medium] Integer overflow when reading and writing the frequency offset for the parallel frequency channel.
Pre-existing issues:
- [High] Kernel panic due to division by zero if the reference clock rate is zero.
--
commit 5740831576c6dff0dd6ca6d5b5930978950cfff8
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: ad9910: add basic parallel port support
Add parallel port support with amplitude, phase and frequency channels.
Those will be buffered capable channels, but only basic control of offset
and scale are implemented at this point.
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> index 95b01295e4a0a..262702b62738d 100644
> --- a/drivers/iio/frequency/ad9910.c
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> @@ -640,11 +702,60 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
> return -EINVAL;
> }
> case IIO_CHAN_INFO_SCALE:
> - tmp64 = (u64)st->data.output_current_uA *
> - AD9910_NANO_MILLIAMP_PER_MICROAMP;
> - *val = 0;
> - *val2 = tmp64 >> 14;
> - return IIO_VAL_INT_PLUS_NANO;
> + switch (chan->address) {
> + case AD9910_CHAN_IDX_PHY:
> + tmp64 = (u64)st->data.output_current_uA *
> + AD9910_NANO_MILLIAMP_PER_MICROAMP;
> + *val = 0;
> + *val2 = tmp64 >> 14;
> + return IIO_VAL_INT_PLUS_NANO;
> + case AD9910_CHAN_IDX_PARALLEL_PHASE:
> + *val = 0;
> + *val2 = AD9910_PI_NANORAD >> 15;
> + return IIO_VAL_INT_PLUS_NANO;
> + case AD9910_CHAN_IDX_PARALLEL_FREQ:
> + tmp32 = FIELD_GET(AD9910_CFR2_FM_GAIN_MSK,
> + st->reg[AD9910_REG_CFR2].val32);
> + tmp64 = st->data.sysclk_freq_hz << tmp32;
[Severity: Medium]
Will this 32-bit shift overflow before being assigned to the 64-bit tmp64?
Since sysclk_freq_hz is typically around 1 GHz and tmp32 can be up to 15,
this operation appears to be strictly 32-bit and could wrap around, resulting
in a corrupted readback.
> + tmp64 = ad9910_rational_scale(tmp64, NANO, BIT_ULL(32));
> + *val = div_s64_rem(tmp64, NANO, val2);
> + return IIO_VAL_INT_PLUS_NANO;
> + case AD9910_CHAN_IDX_PARALLEL_POLAR_AMP:
[ ... ]
> + case IIO_CHAN_INFO_OFFSET:
> + switch (chan->address) {
> + case AD9910_CHAN_IDX_PARALLEL_FREQ:
> + tmp64 = (u64)st->reg[AD9910_REG_FTW].val32 * MICRO;
> + tmp64 >>= FIELD_GET(AD9910_CFR2_FM_GAIN_MSK,
> + st->reg[AD9910_REG_CFR2].val32);
> + *val = div_s64_rem(tmp64, MICRO, val2);
[Severity: Medium]
Does this operation overflow the signed 32-bit pointer val?
The Frequency Tuning Word (FTW) is an unsigned 32-bit register capable of
holding values up to 4,294,967,295. If the offset exceeds INT_MAX, the
assignment could overflow, leading to a negative value on readback.
> + return IIO_VAL_INT_PLUS_MICRO;
> + case AD9910_CHAN_IDX_PARALLEL_POLAR_AMP:
[ ... ]
> @@ -737,12 +848,63 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_SAMP_FREQ:
> return ad9910_set_sysclk_freq(st, val, true);
> case IIO_CHAN_INFO_SCALE:
> - if (val != 0 || val2 < 0)
> + switch (chan->address) {
> + case AD9910_CHAN_IDX_PHY:
> + if (val != 0 || val2 < 0)
> + return -EINVAL;
> +
> + tmp32 = DIV_U64_ROUND_CLOSEST((u64)val2 << 14,
> + AD9910_NANO_MILLIAMP_PER_MICROAMP);
> + return ad9910_set_dac_current(st, tmp32, true);
> + case AD9910_CHAN_IDX_PARALLEL_FREQ:
> + if (val < 0 || val2 < 0)
> + return -EINVAL;
> +
> + tmp64 = ad9910_rational_scale((u64)val * NANO + val2, BIT_ULL(32),
> + (u64)st->data.sysclk_freq_hz * NANO);
[Severity: High]
This is a pre-existing issue, but can sysclk_freq_hz be zero here? If the
reference clock returns 0 from clk_get_rate(), the driver initializes
sysclk_freq_hz to 0 without validation.
If sysclk_freq_hz is 0, the denominator passed to ad9910_rational_scale()
is 0:
drivers/iio/frequency/ad9910.c:ad9910_rational_scale() {
return mul_u64_add_u64_div_u64(input, scale, reference >> 1, reference);
}
This forwards the zero denominator into mul_u64_add_u64_div_u64(), leading
to a kernel panic from division by zero, which is now triggerable from user
space via the newly added parallel frequency scale attribute.
> + tmp64 = roundup_pow_of_two(max(tmp64, 1ULL));
[Severity: Medium]
Will roundup_pow_of_two() truncate the 64-bit tmp64 calculation on 32-bit
architectures?
The roundup_pow_of_two() macro explicitly casts its argument to unsigned
long. On 32-bit systems, this will drop the upper 32 bits, causing the scale
input to be incorrectly configured.
> + tmp32 = min_t(u32, ilog2(tmp64), FIELD_MAX(AD9910_CFR2_FM_GAIN_MSK));
> + tmp32 = FIELD_PREP(AD9910_CFR2_FM_GAIN_MSK, tmp32);
> + return ad9910_reg32_update(st, AD9910_REG_CFR2,
> + AD9910_CFR2_FM_GAIN_MSK,
> + tmp32, true);
> + default:
> + return -EINVAL;
> + }
> + case IIO_CHAN_INFO_OFFSET:
> + if (val < 0 || val2 < 0)
> return -EINVAL;
>
> - tmp32 = DIV_U64_ROUND_CLOSEST((u64)val2 << 14,
> - AD9910_NANO_MILLIAMP_PER_MICROAMP);
> - return ad9910_set_dac_current(st, tmp32, true);
> + switch (chan->address) {
> + case AD9910_CHAN_IDX_PARALLEL_FREQ:
> + tmp64 = (u64)val * MICRO + val2;
[Severity: Medium]
Is it possible to set the Frequency Tuning Word to its full unsigned 32-bit
range?
The IIO subsystem's parser restricts the val parameter to INT_MAX. This
limitation seems to prevent users from accessing or configuring the upper
half of the device's tuning word range when FM_GAIN is 0.
> + tmp64 <<= FIELD_GET(AD9910_CFR2_FM_GAIN_MSK,
> + st->reg[AD9910_REG_CFR2].val32);
[Severity: Medium]
Can this unbounded left shift trigger a 64-bit overflow?
If val is a large value up to INT_MAX, tmp64 can be around 5.63e14. Shifting
this left by an FM_GAIN of 15 would yield a value greater than UINT64_MAX,
which wraps around to a small positive value.
Because the wrapped value is small, it would bypass the subsequent U32_MAX
cap check below, resulting in arbitrary wrapped-around garbage being written
to the hardware.
> + tmp64 = min_t(u64, DIV_U64_ROUND_CLOSEST(tmp64, MICRO),
> + U32_MAX);
> + return ad9910_reg32_write(st, AD9910_REG_FTW, tmp64, true);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=10
^ permalink raw reply
* Re: [PATCH v6 11/16] iio: frequency: ad9910: add digital ramp generator support
From: sashiko-bot @ 2026-06-18 13:42 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260618-ad9910-iio-driver-v6-11-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Negative values written to DRG_RAMP_UP or DRG_RAMP_DOWN raw attributes are silently converted and clamped to U32_MAX instead of returning an error.
--
commit add95ac7476587b7d5eda18e659f33df4cc8cb31
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: ad9910: add digital ramp generator support
This patch adds support for Digital Ramp Generator channels to the AD9910
driver. It includes configuration for destination selection, dwell mode,
limits, step sizes, and step rates.
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> index 262702b62738d..3fe97aa887c3a 100644
> --- a/drivers/iio/frequency/ad9910.c
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> @@ -831,22 +1108,62 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
> return -EINVAL;
> }
> case IIO_CHAN_INFO_RAW:
> - if (val < 0)
> - return -EINVAL;
> -
> switch (chan->channel) {
> case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
> + if (val < 0)
> + return -EINVAL;
> +
> tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
> tmp64 = FIELD_PREP(AD9910_PROFILE_ST_ASF_MSK,
> min_t(u64, val, AD9910_ASF_MAX));
> return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
> AD9910_PROFILE_ST_ASF_MSK,
> tmp64, true);
> + case AD9910_CHANNEL_DRG_RAMP_UP:
> + tmp64 = iio_val_s64_compose(val, val2);
> + tmp64 = min_t(u64, tmp64, U32_MAX);
[Severity: Medium]
When a negative value is written to the DRG_RAMP_UP or DRG_RAMP_DOWN raw
attributes, does this bypass error checking?
Since iio_val_s64_compose() returns an s64, a negative input will be
implicitly cast to u64 when assigned to tmp64. This causes it to wrap to a
large positive number, which min_t() will then clamp to U32_MAX rather than
rejecting the invalid negative input.
Should we check for negative values before calling iio_val_s64_compose(),
similar to what is done for the profile channels?
> + tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_UPPER_MSK, tmp64);
> + return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
> + AD9910_DRG_LIMIT_UPPER_MSK,
> + tmp64, true);
> + case AD9910_CHANNEL_DRG_RAMP_DOWN:
> + tmp64 = iio_val_s64_compose(val, val2);
> + tmp64 = min_t(u64, tmp64, U32_MAX);
> + tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_LOWER_MSK, tmp64);
> + return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
> + AD9910_DRG_LIMIT_LOWER_MSK,
> + tmp64, true);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=11
^ permalink raw reply
* Re: [PATCH 5/7] riscv: dts: eswin: add hsp power domain
From: Pinkesh Vaghela @ 2026-06-18 13:42 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20260615123122.A624D1F0155D@smtp.kernel.org>
Hi Sashiko,
Thanks for your time to review this patch.
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s)
> to consider:
> - [High] The HSP CFG clock will never be enabled, causing a hardware hang
> during register access, because `simple-pm-bus` requires children to use
> `pm_runtime` but `syscon` bypasses it.
> - [Medium] The node is labeled and described as a 'power domain' but is
> modeled as a simple bus without the ability to act as a power domain
> provider.
> --
>
> commit 0dad730760e600f73d118515b1907e14ac735dad
> Author: Pinkesh Vaghela <pinkesh.vaghela@einfochips.com>
>
> riscv: dts: eswin: add hsp power domain
>
> This commit adds an HSP power domain node to manage the HSP CFG clock,
> which is required to access the HSP CSR registers. The CSR is defined as a
> syscon child node within a simple-pm-bus.
>
> > diff --git a/arch/riscv/boot/dts/eswin/eic7700.dtsi
> > b/arch/riscv/boot/dts/eswin/eic7700.dtsi
> > --- a/arch/riscv/boot/dts/eswin/eic7700.dtsi
> > +++ b/arch/riscv/boot/dts/eswin/eic7700.dtsi
> > @@ -252,6 +252,19 @@ plic: interrupt-controller@c000000 {
> > #interrupt-cells = <1>;
> > };
> >
> > + hsp_power_domain: bus@50400000 {
> > + compatible = "simple-pm-bus";
>
> [Severity: Medium]
> The commit message and node label describe this as a power domain, but
> the node uses simple-pm-bus and lacks a #power-domain-cells property. Can
> other devices actually reference this as a power domain?
>
> simple-pm-bus acts as a transparent bus for managing clocks or resets for its
> direct children, rather than a genpd provider. If this is meant to act as a power
> domain that other IP blocks depend on via power-domains = <...>, does it
> need a dedicated driver and the #power-domain-cells property?
>
> If it is strictly meant to manage the syscon clock, should the wrapper be
> removed entirely?
This node is not intended to be a generic power domain (genpd) provider and is
Not expected to be referenced by other devices via a `power-domains` property.
The `simple-pm-bus` wrapper is used to manage the HSP CFG clock, which must
Be enabled before accessing the HSP CSR registers and the register spaces of
the HSP child devices.
The current label is misleading. To avoid confusion with a genpd provider,
we will rename it in v2:
hsp_power_domain: bus@50400000 to hsp: bus@50400000
>
> > + ranges = <0x0 0x50400000 0x0 0x50400000 0x0 0xa0000>;
> > + clocks = <&clk EIC7700_CLK_GATE_HSP_CFG_CLK>;
>
> [Severity: High]
> Since the child node uses the generic syscon compatible, will this clock ever
> be enabled?
>
> The syscon framework in drivers/mfd/syscon.c does not register a platform
> driver, does not probe a device, and does not invoke pm_runtime_get_sync().
> Because the child device is never probed or runtime-resumed, the parent
> simple-pm-bus will remain suspended.
>
> Would this cause a system hang when accessing the syscon registers since the
> clock would remain disabled?
>
> Additionally, of_syscon_register() natively expects the clocks property to be
> directly in the syscon node. Should the clocks property be moved to the
> hsp_sp_csr node and the simple-pm-bus wrapper removed?
The HSP CFG clock is required not only for accessing the HSP CSR registers, but
also for accessing the register spaces of all HSP peripherals.
In this series, we have not yet submitted the DTS patches for the HSP peripheral
devices. The intention is for all HSP peripherals to be placed under this
simple-pm-bus node so that the HSP CFG clock can be managed centrally.
A simplified example is shown below:
hsp: bus@50400000 {
compatible = "simple-pm-bus";
clocks = <&clk EIC7700_CLK_GATE_HSP_CFG_CLK>;
hsp_sp_csr: hsp-sp-top-csr@50440000 {
compatible = "eswin,eic7700-syscfg", "syscon";
reg = <0x0 0x50440000 0x0 0x2000>;
};
sdhci_emmc: mmc@50450000 {
...
};
};
The purpose of this node is not solely to provide access to the HSP CSR
registers but to act as the common parent bus for HSP peripherals that
depend on the HSP CFG clock.
The current commit message is misleading because it suggests that the node
exists only for the CSR access.
We will update the commit message in v2 as below:
riscv: dts: eswin: add HSP bus node
Add an HSP bus node to manage the HSP CFG clock used by HSP
peripherals. This clock is required for accessing both the HSP CSR
registers and the register spaces of HSP peripheral devices.
Is this acceptable?
Regards,
Pinkesh
>
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + hsp_sp_csr: hsp-sp-top-csr@50440000 {
> > + compatible = "eswin,eic7700-syscfg", "syscon";
> > + reg = <0x0 0x50440000 0x0 0x2000>;
> > + };
> > + };
> > +
> > uart0: serial@50900000 {
> > compatible = "snps,dw-apb-uart";
> > reg = <0x0 0x50900000 0x0 0x10000>;
>
> --
> Sashiko AI review *
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsashik
> o.dev%2F%23%2Fpatchset%2F20260615122016.1110206-1-
> pinkesh.vaghela%40einfochips.com%3Fpart%3D5&data=05%7C02%7Cpinkesh
> .vaghela%40einfochips.com%7Cd647a45fb159406b1be408decada02f7%7C0b
> eb0c359cbb4feb99e5589e415c7944%7C1%7C0%7C639171234888553198%7C
> Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA
> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=zdGzcGOEAAOetK3OWTF5JjYPXpfvcIgMARFEP7DI39I%3D&reserved
> =0
^ permalink raw reply
* Re: [PATCH v6 12/16] iio: frequency: ad9910: add RAM mode support
From: sashiko-bot @ 2026-06-18 13:43 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260618-ad9910-iio-driver-v6-12-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Hardware and software profile states become permanently desynchronized if an error occurs while enabling or disabling the RAM channel.
- [High] Firmware upload cancellation requests can be silently ignored due to unconditionally resetting the cancel flag.
- [Low] Selecting the `FW_UPLOAD` boolean config symbol from a tristate driver causes an unmet dependency warning when built as a module.
--
commit 75d72698ebee0a7f4f951b2be1d393940055952b
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: ad9910: add RAM mode support
Add RAM control channel, which includes RAM data loading via firmware upload
interface and per-profile configuration.
> diff --git a/drivers/iio/frequency/Kconfig b/drivers/iio/frequency/Kconfig
> index 6033f9155b4f7..994d199080ebf 100644
> --- a/drivers/iio/frequency/Kconfig
> +++ b/drivers/iio/frequency/Kconfig
> @@ -29,6 +29,9 @@ config AD9910
> tristate "Analog Devices AD9910 Direct Digital Synthesizer"
> depends on SPI
> depends on GPIOLIB
> + select CRC32
> + select FW_LOADER
> + select FW_UPLOAD
[Severity: Low]
Does selecting FW_UPLOAD from a tristate driver trigger an unmet dependency
warning when built as a module?
Because FW_UPLOAD is a boolean symbol that depends on FW_LOADER, and
FW_LOADER can resolve to 'm', selecting FW_UPLOAD forces it to 'y'. Could
this be avoided by using "depends on FW_UPLOAD" instead?
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> index 3fe97aa887c3a..c4e179dda715e 100644
> --- a/drivers/iio/frequency/ad9910.c
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> @@ -1066,6 +1167,41 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
> AD9910_CFR2_DRG_DEST_MSK |
> AD9910_CFR2_DRG_ENABLE_MSK,
> tmp32, true);
> + case AD9910_CHANNEL_RAM:
> + if (AD9910_RAM_ENABLED(st) == !!val)
> + return 0;
> +
> + /* swap profile configs */
> + for (i = 0; i < AD9910_NUM_PROFILES; i++) {
> + tmp64 = st->reg[AD9910_REG_PROFILE(i)].val64;
> + ret = ad9910_reg64_write(st,
> + AD9910_REG_PROFILE(i),
> + st->reg_profile[i],
> + false);
> + if (ret)
> + break;
> + st->reg_profile[i] = tmp64;
> + }
> +
> + if (ret) {
> + /*
> + * After the write failure, profiles 0..i-1 were
> + * already swapped in SW, but Hw registers are
> + * still pending an IO update, so swap them back
> + * in SW to keep the state consistent.
> + */
> + while (i--) {
> + tmp64 = st->reg[AD9910_REG_PROFILE(i)].val64;
> + st->reg[AD9910_REG_PROFILE(i)].val64 = st->reg_profile[i];
> + st->reg_profile[i] = tmp64;
> + }
> + return ret;
> + }
> +
> + tmp32 = FIELD_PREP(AD9910_CFR1_RAM_ENABLE_MSK, !!val);
> + return ad9910_reg32_update(st, AD9910_REG_CFR1,
> + AD9910_CFR1_RAM_ENABLE_MSK,
> + tmp32, true);
[Severity: High]
Can the hardware and software states become permanently desynchronized if an
error occurs during this transition?
If a write fails midway through the profile loop, the rollback loop restores
the software cache but doesn't seem to rewrite the original values to the
hardware SPI buffers. This leaves the successfully written swapped profiles
still pending in the hardware.
Additionally, if the entire profile swap completes but the subsequent
ad9910_reg32_update() for CFR1 fails, the function returns immediately
without any rollback.
Would the next unrelated operation that triggers an IO update unintentionally
commit these partially or completely swapped profiles to the active registers?
[ ... ]
> @@ -1335,6 +1506,126 @@ static int ad9910_read_label(struct iio_dev *indio_dev,
> return sysfs_emit(label, "%s\n", ad9910_channel_str[chan->address]);
> }
>
> +static enum fw_upload_err ad9910_ram_fwu_prepare(struct fw_upload *fw_upload,
> + const u8 *data, u32 size)
> +{
> + struct ad9910_state *st = fw_upload->dd_handle;
> + const struct ad9910_ram_fw *fw_data = (const struct ad9910_ram_fw *)data;
> + size_t wcount, bcount;
> +
> + if (size < sizeof(struct ad9910_ram_fw))
> + return FW_UPLOAD_ERR_INVALID_SIZE;
> +
> + if (get_unaligned_be32(&fw_data->magic) != AD9910_RAM_FW_MAGIC)
> + return FW_UPLOAD_ERR_FW_INVALID;
> +
> + if (get_unaligned_be16(&fw_data->version) != AD9910_RAM_FW_V1)
> + return FW_UPLOAD_ERR_FW_INVALID;
> +
> + wcount = get_unaligned_be16(&fw_data->wcount);
> + bcount = size - sizeof(struct ad9910_ram_fw);
> + if (wcount > AD9910_RAM_SIZE_MAX_WORDS ||
> + bcount != (wcount * AD9910_RAM_WORD_SIZE))
> + return FW_UPLOAD_ERR_INVALID_SIZE;
> +
> + bcount += sizeof(fw_data->cfr1) + sizeof(fw_data->profiles);
> + if (crc32(0, &fw_data->cfr1, bcount) != get_unaligned_be32(&fw_data->crc))
> + return FW_UPLOAD_ERR_FW_INVALID;
> +
> + guard(mutex)(&st->lock);
> + st->ram_fwu_cancel = false;
[Severity: High]
Does unconditionally clearing the cancellation flag here introduce a race
condition where cancellations requested prior to the worker thread starting
are lost?
If a user cancels the upload via sysfs immediately after triggering it, the
framework calls ad9910_ram_fwu_cancel(), which correctly sets
st->ram_fwu_cancel = true.
However, when the background worker thread begins and calls
ad9910_ram_fwu_prepare(), it will overwrite the cancellation state with
false. Could this allow the firmware upload to proceed and flash the device
instead of aborting?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=12
^ permalink raw reply
* Re: [PATCH v6 15/16] iio: ABI: add docs for ad9910 sysfs entries
From: sashiko-bot @ 2026-06-18 13:44 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260618-ad9910-iio-driver-v6-15-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The device tree binding defines the hardware as a clock provider but omits `#clock-cells` from the `required` list.
- [Low] The newly added ABI documentation file is missing the mandatory 'Date:' field and has empty 'KernelVersion:' fields.
--
commit 87a63b1a571e4fe2e7cfbfd552bf448b474a11d0
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: ABI: add docs for ad9910 sysfs entries
Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
control some parameters from the Digital Ramp Generator and OSK engine.
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910
> new file mode 100644
> index 0000000000000..a54afeb643029
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910
> @@ -0,0 +1,27 @@
> +What: /sys/bus/iio/devices/iio:deviceX/out_altcurrentY_dwell_en
> +KernelVersion:
> +Contact: linux-iio@vger.kernel.org
[Severity: Low]
Does this new ABI documentation file omit the mandatory 'Date:' field?
According to Documentation/ABI/README, every file in the ABI directories
must contain a 'Date:' field specifying when the interface was created.
Additionally, the 'KernelVersion:' fields appear to be left empty, which
might trip automated ABI parsers.
[ ... ]
While reviewing this commit, I also noticed a related issue in the device
tree binding file introduced earlier in this series:
Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml:
> required:
> - compatible
> - reg
> - clocks
> - dvdd-io33-supply
> - avdd33-supply
> - dvdd18-supply
> - avdd18-supply
[Severity: Medium]
Should '#clock-cells' be included in this required block?
Since the device tree binding defines the hardware as a clock provider with
'#clock-cells' and 'clock-output-names', omitting it from the required list
could allow incomplete device tree nodes to pass schema validation. This
might cause dependent subsystems or drivers to fail unexpectedly at runtime
when they attempt to use the undocumented functionality.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=15
^ permalink raw reply
* Re: [PATCH v6 14/16] iio: frequency: ad9910: show channel priority in debugfs
From: sashiko-bot @ 2026-06-18 13:45 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260618-ad9910-iio-driver-v6-14-79125ffbe430@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The parallel data port logic in the debugfs source attributes is dead code because the driver does not configure IIO buffers and omits `.scan_index` for the parallel channels.
--
commit 1430aa5467e635315d439ae21891376a98143557
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: ad9910: show channel priority in debugfs
Expose frequency_source, phase_source and amplitude_source attributes in
debugfs. The implementation follows the priority table found in the
datasheet.
> diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> index 890499f67bd56..b39eeb8d9cd45 100644
> --- a/drivers/iio/frequency/ad9910.c
> +++ b/drivers/iio/frequency/ad9910.c
[ ... ]
> @@ -1960,6 +1974,158 @@ static int ad9910_setup(struct device *dev, struct ad9910_state *st,
> return ad9910_io_update(st);
> }
>
> +static inline const char *ad9910_frequency_source_get(struct iio_dev *indio_dev)
> +{
[ ... ]
> + /* Parallel data port enabled and data destination is frequency */
> + mode_en = FIELD_GET(AD9910_CFR2_PARALLEL_DATA_PORT_EN_MSK,
> + st->reg[AD9910_REG_CFR2].val32);
> + if (mode_en && indio_dev->active_scan_mask &&
> + test_bit(AD9910_SCAN_IDX_FREQ, indio_dev->active_scan_mask))
> + return ad9910_channel_str[AD9910_CHAN_IDX_PARALLEL_FREQ];
[Severity: Medium]
Is this logic effectively dead code?
The driver configures INDIO_DIRECT_MODE without setting up any IIO buffers,
so the IIO core will never allocate active_scan_mask. This means
indio_dev->active_scan_mask will permanently evaluate to NULL and the
condition will evaluate to false.
Furthermore, even if buffers were enabled, the channel specifications for
the parallel channels do not populate the .scan_index field, so the bits
would never be set by the IIO core anyway:
drivers/iio/frequency/ad9910.c:ad9910_channels[] = {
...
[AD9910_CHAN_IDX_PARALLEL_FREQ] = {
.type = IIO_FREQUENCY,
.indexed = 1,
.output = 1,
.channel = AD9910_CHANNEL_PARALLEL,
.address = AD9910_CHAN_IDX_PARALLEL_FREQ,
...
}
Could this debugfs output silently fail to report the parallel data port and
fall through to incorrect fallback states?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260618-ad9910-iio-driver-v6-0-79125ffbe430@analog.com?part=14
^ permalink raw reply
* Re: [PATCH 2/2] media: i2c: og0va1b: Add OmniVision OG0VA1B camera sensor
From: Wenmeng Liu @ 2026-06-18 14:00 UTC (permalink / raw)
To: Kieran Bingham, Conor Dooley, Krzysztof Kozlowski,
Mauro Carvalho Chehab, Rob Herring, Sakari Ailus,
Vladimir Zapolskiy
Cc: linux-media, devicetree, linux-kernel
In-Reply-To: <178178854034.861173.9780571180496261859@ping.linuxembedded.co.uk>
On 6/18/2026 9:15 PM, Kieran Bingham wrote:
> Quoting Wenmeng Liu (2026-06-18 13:36:27)
>>
>>
>> On 6/18/2026 6:50 PM, Vladimir Zapolskiy wrote:
>>> Hello Wenmeng.
>>>
>>> On 6/18/26 13:37, Wenmeng Liu wrote:
>>>> Add V4L2 sub device driver for OmniVision OG0VA1B image sensor.
>>>> OmniVision OG0VA1B is an image sensor, which produces frames in 10-bit
>>>> raw output format (Y10) over a 1-lane MIPI CSI-2 interface and supports
>>>> the 640x480 (VGA) resolution.
>>>>
>>>> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
>>>> ---
>>>> MAINTAINERS | 1 +
>>>> drivers/media/i2c/Kconfig | 10 +
>>>> drivers/media/i2c/Makefile | 1 +
>>>> drivers/media/i2c/og0va1b.c | 867 ++++++++++++++++++++++++++++++++++
>>>> ++++++++++
>>>> 4 files changed, 879 insertions(+)
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index
>>>> 5aa846c8479b20651291d5bd2e316308310f826c..85a06eb9eacc410a565b80d56979eaa565515d0e 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -19891,6 +19891,7 @@ M: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
>>>> L: linux-media@vger.kernel.org
>>>> S: Maintained
>>>> F: Documentation/devicetree/bindings/media/i2c/ovti,og0va1b.yaml
>>>> +F: drivers/media/i2c/og0va1b.c
>>>> OMNIVISION OG0VE1B SENSOR DRIVER
>>>> M: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>>>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>>>> index
>>>> 5d173e0ecf424f2f204f8d426be818e44357f8e4..56680772f5f47b4629c4e17f5a5feba08b1d94fc 100644
>>>> --- a/drivers/media/i2c/Kconfig
>>>> +++ b/drivers/media/i2c/Kconfig
>>>> @@ -363,6 +363,16 @@ config VIDEO_OG01A1B
>>>> To compile this driver as a module, choose M here: the
>>>> module will be called og01a1b.
>>>> +config VIDEO_OG0VA1B
>>>> + tristate "OmniVision OG0VA1B sensor support"
>>>> + select V4L2_CCI_I2C
>>>> + help
>>>> + This is a Video4Linux2 sensor driver for the OmniVision
>>>> + OG0VA1B camera.
>>>> +
>>>> + To compile this driver as a module, choose M here: the
>>>> + module will be called og0va1b.
>>>> +
>>>> config VIDEO_OG0VE1B
>>>> tristate "OmniVision OG0VE1B sensor support"
>>>> select V4L2_CCI_I2C
>>>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>>>> index
>>>> e45359efe0e41e13e3c0869e5ead7d6cf4aca3a7..c60851c7fe07e3bdc511c5f482525ba7a044f48e 100644
>>>> --- a/drivers/media/i2c/Makefile
>>>> +++ b/drivers/media/i2c/Makefile
>>>> @@ -83,6 +83,7 @@ obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
>>>> obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
>>>> obj-$(CONFIG_VIDEO_MT9V111) += mt9v111.o
>>>> obj-$(CONFIG_VIDEO_OG01A1B) += og01a1b.o
>>>> +obj-$(CONFIG_VIDEO_OG0VA1B) += og0va1b.o
>>>> obj-$(CONFIG_VIDEO_OG0VE1B) += og0ve1b.o
>>>> obj-$(CONFIG_VIDEO_OS05B10) += os05b10.o
>>>> obj-$(CONFIG_VIDEO_OV01A10) += ov01a10.o
>>>> diff --git a/drivers/media/i2c/og0va1b.c b/drivers/media/i2c/og0va1b.c
>>>> new file mode 100644
>>>> index
>>>> 0000000000000000000000000000000000000000..f0505b7ba7f329ad57ffafa8f90a24204f002d3c
>>>> --- /dev/null
>>>> +++ b/drivers/media/i2c/og0va1b.c
>>>> @@ -0,0 +1,867 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * OmniVision OG0VA1B Camera Sensor Driver
>>>> + *
>>>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries
>>>> + */
>>>> +
>>>> +#include <linux/clk.h>
>>>> +#include <linux/delay.h>
>>>> +#include <linux/gpio/consumer.h>
>>>> +#include <linux/i2c.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/pm_runtime.h>
>>>> +#include <linux/regulator/consumer.h>
>>>> +
>>>> +#include <media/v4l2-cci.h>
>>>> +#include <media/v4l2-ctrls.h>
>>>> +#include <media/v4l2-device.h>
>>>> +#include <media/v4l2-fwnode.h>
>>>> +#include <media/v4l2-subdev.h>
>>>> +
>>>> +#define OG0VA1B_REG_CHIP_ID CCI_REG16(0x300a)
>>>> +#define OG0VA1B_CHIP_ID 0xC756
>>>
>>> This is the same chip id as of the OG0VE1B sensor device.
>>>
>>> What's the difference between these two sensors, and do you find it
>>> possible
>>> to add support of OG0VA1B sensor/modes into OG0VE1B sensor driver? Or is
>>> it just the same device?
>>>
>>> Hardware specifics described in dt changes also does not show a difference
>>> in comparison to ovti,og0ve1b.yaml.
>>>
>>
>>
>> Hi Vladimir,
>>
>>
>> Both OG0VE1B and OG0VA1B belong to the same OmniVision VGA monochrome
>> sensor family. They share the same resolution, power rails, reset GPIO
>> behavior and power management framework.
>>
>> But they are different:
>> OG0VE1B: 8-bit RAW, lower FPS
>> OG0VA1B: 10-bit RAW, higher FPS
>> and some registers are not same.
>
> Can you identify which registers are not the same?
>
For example, regarding the CHIP_ID,
OG0VE1B is 0xc75645, while OG0VA1B is 0xc75641, including the test
pattern registers.
Since I do not have the specification for OG0VE1B, I cannot perform a
detailed comparison. However, based on the current observations, OG0VA1B
can be integrated into the OG0VE1B driver.
> Mapping between 8bit and 10 bit or different frame rates could easily be
> managed in a single driver with exposing different capabilities based on
> the variant.
>
> We should really work towards reducing the huge duplication that is
> happening with copy/paste sensor drivers.
Indeed, will do so.
Thanks,
Wenmeng
^ permalink raw reply
* Re: (subset) [PATCH V7 0/6] Add Anbernic RG Vita-Pro
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: linux-rockchip, Chris Morgan
Cc: devicetree, xsf, sre, simona, airlied, tzimmermann, mripard,
maarten.lankhorst, jesszhan0024, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260610144407.438846-1-macroalpha82@gmail.com>
Hi,
On Wed, 10 Jun 2026 09:44:01 -0500, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for the Anbernic RG Vita-Pro, based on the Rockchip RK3576 SoC.
>
> Changes Since V1:
> - Updated documentation filename to matche compatible string.
> - Corrected order of allocating IRQ in charger driver and switched
> to using devm managed function to allocate work queue.
> Changes Since V2:
> - Corrected issue with naming of panel binding document and added
> fallback compatible string.
> - Switched to devm helpers in panel driver. Note that
> devm_drm_panel_add() is currently only in the drm-next branch.
> - Optimized setting GPIOs for panel driver.
> Changes Since V3:
> - Fixed numerous issues identifed by Sashiko bot, mainly relating
> to unclamped or improperly clamped values from within the
> charger driver.
> - Corrected hard-coded values in the panel driver unprepare routine
> as well as correcting an improperly checked return condition.
> Changes Since V4:
> - Fixed errors identified by Sashiko bot on charger driver that could
> result in an improper value being written to the registers.
> - Corrected some error handling in the panel driver.
> Changes Since V5:
> - Corrected minor errors in documentation and added default values.
> - Further corrected clamping behavior in charger driver.
> Changes Since V6:
> - Additional corrections as suggested by Sashiko bot to fix potential
> edge cases during probe for sgm41542.
> - Corrected an improperly shifted value being written to register for
> sgm41542.
> - Changed a MV value to UV in sgm41542 driver to simplify function.
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[3/6] dt-bindings: display: panel: Add Anbernic TD4310 panel
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0fd6ead8270270d859a28d0196a4b47e7d6845b8
[4/6] drm/panel: anbernic-td4310: Add RG Vita Pro panel
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/a81b4fe69e7bd2667524182e76c635f04c1ead7e
--
Neil
^ permalink raw reply
* Re: [PATCH v4 0/2] drm/panel: Add panel driver for Chipone ICNA35XX based panels
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: Jessica Zhang, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Aaron Kling
Cc: dri-devel, devicetree, linux-kernel, Krzysztof Kozlowski,
Teguh Sobirin
In-Reply-To: <20260607-icna35xx-v4-0-64de514add34@gmail.com>
Hi,
On Sun, 07 Jun 2026 15:11:43 -0500, Aaron Kling wrote:
> This driver is based on the one by Teguh Sobirin [0].
>
> Due to [1], the AYN vendor description patch has been folded into the
> AYN QCS8550 dt series. Which means this series depends on said series
> and it must be picked up before this.
>
> [0] https://github.com/AYNTechnologies/linux/commit/4c5e76e974db7cca853619ca138eecd8f004622f
> [1] https://lore.kernel.org/linux-arm-msm/c7fb3f89-6574-4761-9ef2-2fdf6d4801b5@kernel.org
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/2] dt-bindings: display: panel: Add Chipone ICNA3512 OLED driver bindings
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/392313ce84a8498164137c6941d5c6a3f7740f1a
[2/2] drm/panel: Add panel driver for Chipone ICNA35XX based panels
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/f747473a838ecc25e842e3c60ea95a5175be932e
--
Neil
^ permalink raw reply
* Re: [PATCH v6 0/2] drm/panel: Add support for the FocusLCDs E35GH-I-MW800CB
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Lad Prabhakar,
Manivannan Sadhasivam, Kael D'Alcamo, Kever Yang,
Igor Reznichenko
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260617143245.372182-1-igor@reznichenko.net>
Hi,
On Wed, 17 Jun 2026 07:32:43 -0700, Igor Reznichenko wrote:
> Add support for E35GH-I-MW800CB 320x480 MIPI DSI panel by FocusLCDs.
> The panel uses Ilitek ILI9488 driver IC in DSI mode specifically.
> ILI9488 also appears in DBI/SPI panels, but those require different bus drivers.
>
> This panel driver has been tested on STM32MP157D-DK1 in addition to TI AM62P EVK.
> The panel works in video mode on both platforms. Additional panels using
> ILI9488 DSI can be added later with their own timings.
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/2] dt-bindings: display: panel: Add Ilitek ILI9488 panel controller
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/532701ad6e239f1b47bebaa597e159c282c6c6ac
[2/2] drm/panel: Add Ilitek ILI9488 controller driver
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/99e9aca83bfb867ae780f58d076bb89dd5c2681d
--
Neil
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: panel: himax,hx83121a: add optional bl supply
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Pengyu Luo, Icenowy Zheng
Cc: Liam Girdwood, Mark Brown, dri-devel, devicetree, linux-kernel
In-Reply-To: <20260608162622.403713-1-zhengxingda@iscas.ac.cn>
Hi,
On Tue, 09 Jun 2026 00:26:20 +0800, Icenowy Zheng wrote:
> When the backlight is managed by the panel controller IC, an external
> power rail might be powering the backlight.
>
> Add an optional `bl-supply` property to describe such power rail, thus
> allow disabling the backlight.
>
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/3] dt-bindings: display: panel: himax,hx83121a: add optional bl supply
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/b817a59c2afcfbf1594b9be6c4136d9d7d613eee
[2/3] drm/panel: himax-hx83121a: pass the panel pointer when creating BL
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/ae8dbbe8955d7470dd41e101b852fd1a70f62930
[3/3] drm/panel: himax-hx83121a: add backlight regulator support
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/98b46e693b912eef0e6d497327489113845cbd15
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH v8 0/6] arm64: dts: qcom: Support AYN QCS8550 Devices
From: Neil Armstrong @ 2026-06-18 14:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Aaron Kling
Cc: linux-arm-msm, devicetree, linux-kernel, Xilin Wu,
Krzysztof Kozlowski, Teguh Sobirin, Konrad Dybcio
In-Reply-To: <20260503-ayn-qcs8550-v8-0-d733f5e57446@gmail.com>
Hi,
On Sun, 03 May 2026 16:48:42 -0500, Aaron Kling wrote:
> This specifically includes:
> * Odin 2 Mini
> * Odin 2 Portal
> * Thor
>
> The original Odin 2 dts is not currently included as it has not yet
> been verified.
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
[1/6] dt-bindings: vendor-prefixes: Add AYN Technologies
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/fc917a533da47a5d0fd2f3df9052ee6dc5e6adad
--
Neil
^ permalink raw reply
* Re: (subset) [PATCH v8 0/6] arm64: dts: qcom: Support AYN QCS8550 Devices
From: Neil Armstrong @ 2026-06-18 14:02 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Aaron Kling
Cc: linux-arm-msm, devicetree, linux-kernel, Xilin Wu,
Krzysztof Kozlowski, Teguh Sobirin, Konrad Dybcio
In-Reply-To: <178179131851.245596.10889069443600186081.b4-ty@b4>
On 6/18/26 16:01, Neil Armstrong wrote:
> Hi,
>
> On Sun, 03 May 2026 16:48:42 -0500, Aaron Kling wrote:
>> This specifically includes:
>> * Odin 2 Mini
>> * Odin 2 Portal
>> * Thor
>>
>> The original Odin 2 dts is not currently included as it has not yet
>> been verified.
>>
>> [...]
>
> Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next)
>
> [1/6] dt-bindings: vendor-prefixes: Add AYN Technologies
> https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/fc917a533da47a5d0fd2f3df9052ee6dc5e6adad
>
Applied it for the panel bindings,
Thanks
Neil
^ permalink raw reply
* Re: [PATCH v2 03/10] tests: asm: Introduce treehdr_vers macro
From: David Gibson @ 2026-06-18 10:15 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20260409115426.352214-4-herve.codina@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]
On Thu, Apr 09, 2026 at 01:54:19PM +0200, Herve Codina wrote:
> tree.S is used to generate custom dtbs. It uses the treehdr macro to
> build the header part.
>
> The current definition of this macro doesn't allow to set custom
> settings related to version fields.
>
> In order to easily generate some dtb with custom version values without
> duplicating the full header computation, introduce the treehdr_vers
> macro.
>
> The modification doesn't introduce any functional changes.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
I just killed the not-very-portable trees.S in the main git tree, so
this will need reworking for the new treegen.c system.
> ---
> tests/trees.S | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tests/trees.S b/tests/trees.S
> index d69f7f1..4db2b9b 100644
> --- a/tests/trees.S
> +++ b/tests/trees.S
> @@ -8,7 +8,7 @@
> .byte (\val) & 0xff
> .endm
>
> - .macro treehdr tree
> + .macro treehdr_vers tree vers last_comp_vers
> .balign 8
> .globl \tree
> \tree :
> @@ -17,13 +17,17 @@
> fdtlong (\tree\()_struct - \tree)
> fdtlong (\tree\()_strings - \tree)
> fdtlong (\tree\()_rsvmap - \tree)
> - fdtlong 0x11
> - fdtlong 0x10
> + fdtlong \vers
> + fdtlong \last_comp_vers
> fdtlong 0
> fdtlong (\tree\()_strings_end - \tree\()_strings)
> fdtlong (\tree\()_struct_end - \tree\()_struct)
> .endm
>
> + .macro treehdr tree
> + treehdr_vers \tree 0x11 0x10
> + .endm
> +
> .macro rsvmape addrh, addrl, lenh, lenl
> fdtlong \addrh
> fdtlong \addrl
> --
> 2.53.0
>
>
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 02/10] libfdt: Don't assume that a FDT_BEGIN_NODE tag is available at offset 0
From: David Gibson @ 2026-06-18 10:13 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20260409115426.352214-3-herve.codina@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]
On Thu, Apr 09, 2026 at 01:54:18PM +0200, Herve Codina wrote:
> In several places, libfdt assumes that a FDT_BEGIN_NODE tag is present
> at the offset 0 of the structure block.
>
> This assumption is not correct. Indeed, a FDT_NOP can be present at the
> offset 0 and this is a legit case.
>
> fdt_first_node() has been introduced recently to get the offset of the
> first node (first FDT_BEGIN_NODE) in a fdt blob.
>
> Use this function to get the first node offset instead of looking for
> this node at offset 0.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
The problem is real, of course. But this approach to solving it with
a special case just for the root node is really ugly.
Granted, it's a problem of my own making - I chose not to create an
fdt_root_offset() function in the first place, instead making it part
of the API that offset 0 means the root node. Nonetheless, here we
are and the question is whether we can do better.
# Straightforward things first
- This patch should be folded with 1/10, they're both harder to
understand without the context of the other.
- If it must exist, the function should be fdt_root_offset(), not
fdt_first_node(), for at least three reasons:
* "first" in what sense?
* "first" amongst what set of nodes?
* We have a strong convention to always explicitly say "offset",
not just referring to offset values as "node" or "property".
This is deliberate: it's an attempt to discourage the otherwise
likely misunderstanding that a function getting a "node" gives
you some sort of persistent handle. "offset" makes it clearer
that the value will no longer be valid after a modification to
the tree.
- The situation described is subtle enough that this *really* needs a
testcase. It shouldn't be that hard: change the existing
'nopulate' test tool to add an FDT_NOP before the first tag, not
just after
# Is FDT_NOP before the root node actually legitimate?
Arguably the simplest solution here would be to explicitly ban this.
Yes, it would be a slightly odd restriction in the spec. However,
avoiding the mess in the library might be worth it. Note that this
situation can never arise from fdt_nop_node(), unless you apply it to
the root node, in which case there's no tree left.
# Less special casery
Even if we accept the need for FDT_NOP before the root node, I think
we can do better. The below implements this as a special case, just
for offset 0. Instead, we could allow all node operations on a
FDT_NOP offset, automatically advancing to the next FDT_BEGIN_NODE
tag. We may be able to do that in check_node_offset_() minimising
code duplication.
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox