* Re: [PATCH v1 05/15] dt-bindings: display: panel-lvds: Add Riverdi RVT70HSLNWCA0 and RVT101HVLNWC00
From: Conor Dooley @ 2026-05-21 16:57 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-22-ivitro@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 01/15] dt-bindings: display: panel: Move Logic Technologies LT170410-2WHC to LVDS
From: Conor Dooley @ 2026-05-21 16:56 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-18-ivitro@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]
On Thu, May 21, 2026 at 04:00:37PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> The Logic Technologies LT170410-2WHC is an LVDS panel, so move it to
> the correct bindings file.
>
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
Am I missing a driver change in the series for this?
v7.1-rc1 has:
rg logictechno,lt170410-2whc
Documentation/devicetree/bindings/display/panel/panel-simple.yaml
210: - logictechno,lt170410-2whc
drivers/gpu/drm/panel/panel-simple.c
5482: .compatible = "logictechno,lt170410-2whc",
Additionally, please add a fixes tag.
Cheers,
Conor.
pw-bot: changes-requested
> ---
> Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 --
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> index b31c67babaa8..9db96dd724b2 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> @@ -58,6 +58,8 @@ properties:
> - hydis,hv070wx2-1e0
> # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
> - jenson,bl-jt60050-01a
> + # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
> + - logictechno,lt170410-2whc
> # Samsung LTN070NL01 7.0" WSVGA (1024x600) TFT LCD LVDS panel
> - samsung,ltn070nl01
> # Samsung LTN101AL03 10.1" WXGA (800x1280) TFT LCD LVDS panel
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 3e41ed0ef5d5..f7e09f5b1b5e 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -206,8 +206,6 @@ properties:
> - logictechno,lt161010-2nhc
> # Logic Technologies LT161010-2NHR 7" WVGA TFT Resistive Touch Module
> - logictechno,lt161010-2nhr
> - # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
> - - logictechno,lt170410-2whc
> # Logic Technologies LTTD800x480 L2RT 7" 800x480 TFT Resistive Touch Module
> - logictechno,lttd800480070-l2rt
> # Logic Technologies LTTD800480070-L6WH-RT 7” 800x480 TFT Resistive Touch Module
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 04/15] dt-bindings: vendor-prefixes: Add Riverdi
From: Conor Dooley @ 2026-05-21 16:54 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-21-ivitro@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 14/15] dt-bindings: display: panel-lvds: Add LG LP156WF1
From: Conor Dooley @ 2026-05-21 16:54 UTC (permalink / raw)
To: Vitor Soares
Cc: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding, Sam Ravnborg, Vitor Soares, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260521150038.103538-31-ivitro@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3611 bytes --]
On Thu, May 21, 2026 at 04:00:50PM +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> Add the compatible string for the LG LP156WF1 15.6" FHD (1920x1080)
> dual-channel TFT LCD LVDS panel.
>
> Assisted-by: Claude:claude-sonnet-4.6
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
> ---
> Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> index 45183a1439ce..a6af2b9cc2f9 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> @@ -58,6 +58,8 @@ properties:
> - hydis,hv070wx2-1e0
> # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
> - jenson,bl-jt60050-01a
> + # LG LP156WF1 15.6" FHD (1920x1080) dual-channel TFT LCD LVDS panel
> + - lg,lp156wf1
> # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
> - logictechno,lt170410-2whc
> # Riverdi RVT101HVLNWC00 10.1" WXGA (1280x800) TFT LCD LVDS panel
Copy pasting a reply from me to sashiko-bot, cos the mail from it only
went to the submitter, dt maintainers and dt list:
|On Thu, May 21, 2026 at 03:27:16PM +0000, sashiko-bot@kernel.org wrote:
|> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
|> - [Medium] The dt-binding fails to enforce the dual-channel requirement (the `ports` property) for the newly added `lg,lp156wf1` compatible string.
|> --
|>
|> commit a568203d1851908daadd835b566099e0a123357a
|> Author: Vitor Soares <vitor.soares@toradex.com>
|> dt-bindings: display: panel-lvds: Add LG LP156WF1
|>
|> This commit adds the compatible string for the LG LP156WF1 15.6" FHD
|> dual-channel TFT LCD LVDS panel to the generic panel-lvds schema.
|>
|> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
|> > index 45183a1439ce9..a6af2b9cc2f9a 100644
|> > --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
|> > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
|> > @@ -58,6 +58,8 @@ properties:
|> > - hydis,hv070wx2-1e0
|> > # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
|> > - jenson,bl-jt60050-01a
|> > + # LG LP156WF1 15.6" FHD (1920x1080) dual-channel TFT LCD LVDS panel
|> > + - lg,lp156wf1
|>
|> [Severity: Medium]
|> Since the commit message indicates this is a dual-channel panel, shouldn't we
|> add an if-then conditional block to require the ports property specifically for
|> this compatible string?
|
|No idea if this is accurate, but if it is accurate, would the
|lvds-dual-ports bindings come into play?
|
|>
|> Currently, the panel-lvds.yaml schema allows panels to be configured with
|> either a single port or multiple ports. Without a specific conditional block
|> enforcing required: [ports] for lg,lp156wf1, a device tree incorrectly
|> configuring this dual-channel hardware with only a single port will silently
|> pass validation.
|>
|> --
|> Sashiko AI review · https://sashiko.dev/#/patchset/20260521150038.103538-17-ivitro@gmail.com?part=14
I don't understand these deviecs enough to know if this is a valid
report.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: mfd: sprd,sc2731: Include SC2730 regulator bindings
From: sashiko-bot @ 2026-05-21 16:52 UTC (permalink / raw)
To: Otto Pflüger; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260521-sc2730-regulators-v4-2-1ac8a3b5ed82@abscue.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Removing the unconditional `$ref` for the `regulators` node without adding conditionals for `sprd,sc2720`, `sprd,sc2721`, and `sprd,sc2723` leaves the `regulators` node unvalidated for those compatible strings.
--
commit 0dc1c5ed599d6def6003f8e26bf5f2c7220c8d77
Author: Otto Pflüger <otto.pflueger@abscue.de>
dt-bindings: mfd: sprd,sc2731: Include SC2730 regulator bindings
The SC2730 PMIC provides a different set of regulators from SC2731 and
requires separate regulator bindings. This commit adds conditionals for
sprd,sc2730 and sprd,sc2731 top-level compatibles to ensure the correct
regulator schemas are applied.
> diff --git a/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml b/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml
> index b023e1ef8d3cc..39d26b6ab4779 100644
> --- a/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml
> +++ b/Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml
> @@ -54,7 +54,6 @@ properties:
>
> regulators:
> type: object
> - $ref: /schemas/regulator/sprd,sc2731-regulator.yaml#
>
> patternProperties:
> "^adc@[0-9a-f]+$":
[ ... ]
> @@ -101,6 +100,26 @@ required:
>
> additionalProperties: false
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: sprd,sc2730
> + then:
> + properties:
> + regulators:
> + $ref: /schemas/regulator/sprd,sc2730-regulator.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: sprd,sc2731
> + then:
> + properties:
> + regulators:
> + $ref: /schemas/regulator/sprd,sc2731-regulator.yaml#
[Severity: Medium]
Does removing the unconditional $ref leave the regulators node unvalidated for
the older compatible strings?
The compatible enum for this schema also includes sprd,sc2720, sprd,sc2721,
and sprd,sc2723. Now that the default $ref has been removed, if one of those
older compatible strings is used, there is no conditional block that applies.
This appears to fall back to an unconstrained type: object schema for those
compatibles, which means invalid or malformed properties within the regulators
node will silently pass dt-binding checks.
Should there be an additional conditional block for these older PMICs to
ensure their regulators are fully validated?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260521-sc2730-regulators-v4-0-1ac8a3b5ed82@abscue.de?part=2
^ permalink raw reply
* Re: [PATCH v1 14/15] dt-bindings: display: panel-lvds: Add LG LP156WF1
From: Conor Dooley @ 2026-05-21 16:52 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Vitor Soares, conor+dt, devicetree, robh
In-Reply-To: <20260521152716.DD2FD1F000E9@smtp.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]
On Thu, May 21, 2026 at 03:27:16PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The dt-binding fails to enforce the dual-channel requirement (the `ports` property) for the newly added `lg,lp156wf1` compatible string.
> --
>
> commit a568203d1851908daadd835b566099e0a123357a
> Author: Vitor Soares <vitor.soares@toradex.com>
> dt-bindings: display: panel-lvds: Add LG LP156WF1
>
> This commit adds the compatible string for the LG LP156WF1 15.6" FHD
> dual-channel TFT LCD LVDS panel to the generic panel-lvds schema.
>
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> > index 45183a1439ce9..a6af2b9cc2f9a 100644
> > --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> > @@ -58,6 +58,8 @@ properties:
> > - hydis,hv070wx2-1e0
> > # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
> > - jenson,bl-jt60050-01a
> > + # LG LP156WF1 15.6" FHD (1920x1080) dual-channel TFT LCD LVDS panel
> > + - lg,lp156wf1
>
> [Severity: Medium]
> Since the commit message indicates this is a dual-channel panel, shouldn't we
> add an if-then conditional block to require the ports property specifically for
> this compatible string?
No idea if this is accurate, but if it is accurate, would the
lvds-dual-ports bindings come into play?
>
> Currently, the panel-lvds.yaml schema allows panels to be configured with
> either a single port or multiple ports. Without a specific conditional block
> enforcing required: [ports] for lg,lp156wf1, a device tree incorrectly
> configuring this dual-channel hardware with only a single port will silently
> pass validation.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260521150038.103538-17-ivitro@gmail.com?part=14
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: serial: rs485: remove deprecated .txt binding stub
From: Conor Dooley @ 2026-05-21 16:48 UTC (permalink / raw)
To: Akash Sukhavasi
Cc: krzk+dt, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
Conor Dooley, Jonathan Corbet, Shuah Khan, linux-kernel,
linux-serial, devicetree, linux-doc
In-Reply-To: <20260521162137.6325-1-akash.sukhavasi@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2590 bytes --]
On Thu, May 21, 2026 at 11:21:35AM -0500, Akash Sukhavasi wrote:
> The plain text binding file was superseded by the YAML schema in
> commit d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings
> to json-schema"). The file now contains only a redirect notice.
> Remove it, and update references in serial_core.c and
> serial-rs485.rst to point to the YAML schema.
>
> Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
Unless I am missing something about how docs.kernel.org redirects
magically work or something along those lines,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Cheers,
Conor.
> ---
> Changes in v2:
> - Update references in serial_core.c and serial-rs485.rst to point
> to rs485.yaml (Sashiko review).
>
> v1: https://lore.kernel.org/all/20260521150748.4816-1-akash.sukhavasi@gmail.com/
>
> Documentation/devicetree/bindings/serial/rs485.txt | 1 -
> Documentation/driver-api/serial/serial-rs485.rst | 2 +-
> drivers/tty/serial/serial_core.c | 2 +-
> 3 files changed, 2 insertions(+), 3 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/serial/rs485.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
> deleted file mode 100644
> index a7fe93efc..000000000
> --- a/Documentation/devicetree/bindings/serial/rs485.txt
> +++ /dev/null
> @@ -1 +0,0 @@
> -See rs485.yaml
> diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst
> index dce061ef7..f53043d21 100644
> --- a/Documentation/driver-api/serial/serial-rs485.rst
> +++ b/Documentation/driver-api/serial/serial-rs485.rst
> @@ -132,4 +132,4 @@ RS485 Serial Communications
> 6. References
> =============
>
> -.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.txt
> +.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.yaml
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 89cebdd27..df4589880 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3496,7 +3496,7 @@ EXPORT_SYMBOL_GPL(uart_try_toggle_sysrq);
> * @port: uart device's target port
> *
> * This function implements the device tree binding described in
> - * Documentation/devicetree/bindings/serial/rs485.txt.
> + * Documentation/devicetree/bindings/serial/rs485.yaml.
> */
> int uart_get_rs485_mode(struct uart_port *port)
> {
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v3 8/8] iio: temperature: ltc2983: Add support for ADT7604
From: Liviu Stan @ 2026-05-21 16:43 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, Liviu Stan, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521164323.770626-1-liviu.stan@analog.com>
The ADT7604 shares the same die as the LTC2984. It repurposes the
custom RTD sensor type (18) as a copper trace resistance sensor
and the custom thermistor type (27) as a leak detector, and
removes thermocouple, diode and direct ADC sensor types.
Two new software sensor type values are introduced
(LTC2983_SENSOR_COPPER_TRACE = 32, LTC2983_SENSOR_LEAK_DETECTOR = 33)
that map to the hardware register values 18 and 27 respectively.
Dedicated structs (ltc2983_copper_trace, ltc2983_leak_detector) and
parser functions are added rather than extending the existing RTD and
thermistor paths, as the hardware configuration bits are fully
hardcoded and several RTD/thermistor properties would need to be
explicitly forbidden or ignored.
Custom RTD (type 18) becomes the copper trace sensor. Sensor
configuration bits are hardcoded to 0b1001 per the datasheet.
Two variants are supported via the adi,copper-trace-sub-ohm DT
property: sub-ohm traces (< 1 ohm) have bits 17:0 cleared with no
excitation current or custom table; standard traces (> 1 ohm) have
a required resistance-to-temperature table.
Custom thermistor (type 27) becomes the leak detector. Sensor
configuration bits are hardcoded to 0b001. The custom table uses
a resolution of 16 instead of 64, and is specified via the
required adi,custom-leak-detector DT property.
Both sensor types expose an IIO_RESISTANCE channel reading from
the resistance result register bank (0x0060-0x00AF). Added a
"base" parameter to the LTC2983_RESULT_ADDR macro and a "base_reg"
parameter to the ltc2983_chan_read function so we can read from
both result register banks. The resistance register encodes the
measured resistance with 10 fractional bits, so dividing by 1024
gives ohms. Since the sense resistor is specified in ohms, the
output is in ohms for both sensor types and a single 1/1024
scale applies to both. For > 1 ohm copper traces and for leak
detectors, a secondary channel also appears: IIO_TEMP
(millidegrees Celsius) for copper trace and IIO_COVERAGE (percent)
for leak detector.
The ltc2983_chip_info struct is extended with a u64 supported_sensors
bitmask using BIT_ULL() to safely represent the new sensor type bits
32 and 33 on 32-bit builds. A LTC2983_SENSOR_NUM sentinel is added
to the enum so that the bounds check uses >= LTC2983_SENSOR_NUM
rather than hardcoding the last sensor type.
Tested on EVAL-ADT7604-AZ connected to Raspberry Pi 5 via SPI.
Signed-off-by: Liviu Stan <liviu.stan@analog.com>
---
Changes in v3:
- Relocated the "base" parameter addition from patch 1 to this one since
the resistance result memory region is (currently) ADT7604-specific
- Updated the commit message to mention the base and base_reg parameters
added to the result-bank read helpers
- Stacked the IIO_RESISTANCE and IIO_COVERAGE case labels in
ltc2983_read_raw()
- Added LTC2983_SENSOR_NUM sentinel at the end of the sensor-type enum
- Changed the sensor-type bounds check from > LTC2983_SENSOR_LEAK_DETECTOR
to >= LTC2983_SENSOR_NUM
- Reordered the ltm2985_chip_info_data struct initializer so has_eeprom
doesn't look like it was added to the ltm2985 in the diff
- Changed the custom leak detector table encoding, users now specify
plain coverage percentage values (0-100) in the device tree and the
driver applies the +273.15 C offset internally before writing the
hardware table
- Changed custom-rtd to custom-copper-trace to better represent the
copper trace custom table, and made it required for > 1 ohm variants
- Made custom-leak-detector required for leak detector sensors, _new
and _assign_chan functions were updated for both sensor types
- Updated commit message to reflect the changes
- Removed "..." from "rsense channel must be configured" error message
from ltc2983_leak_detector_new()
- Removed blank line before hw_type declaration in
__ltc2983_chan_assign_common
drivers/iio/temperature/ltc2983.c | 413 ++++++++++++++++++++++++++++--
1 file changed, 394 insertions(+), 19 deletions(-)
diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
index 326f843f4271..e2ffeee026ee 100644
--- a/drivers/iio/temperature/ltc2983.c
+++ b/drivers/iio/temperature/ltc2983.c
@@ -28,6 +28,8 @@
#define LTC2983_STATUS_REG 0x0000
#define LTC2983_TEMP_RES_START_REG 0x0010
#define LTC2983_TEMP_RES_END_REG 0x005F
+#define ADT7604_RES_RES_START_REG 0x0060
+#define ADT7604_RES_RES_END_REG 0x00AF
#define LTC2983_EEPROM_KEY_REG 0x00B0
#define LTC2983_EEPROM_READ_STATUS_REG 0x00D0
#define LTC2983_GLOBAL_CONFIG_REG 0x00F0
@@ -58,8 +60,8 @@
#define LTC2983_CHAN_ASSIGN_ADDR(chan) \
((((chan) - 1) * 4) + LTC2983_CHAN_ASSIGN_START_REG)
-#define LTC2983_RESULT_ADDR(chan) \
- ((((chan) - 1) * 4) + LTC2983_TEMP_RES_START_REG)
+#define LTC2983_RESULT_ADDR(chan, base) \
+ ((((chan) - 1) * 4) + (base))
#define LTC2983_THERMOCOUPLE_DIFF_MASK BIT(3)
#define LTC2983_THERMOCOUPLE_SGL(x) \
FIELD_PREP(LTC2983_THERMOCOUPLE_DIFF_MASK, x)
@@ -186,17 +188,44 @@ enum {
LTC2983_SENSOR_SENSE_RESISTOR = 29,
LTC2983_SENSOR_DIRECT_ADC = 30,
LTC2983_SENSOR_ACTIVE_TEMP = 31,
+ /* Sensor types for some parts only; map to RTD_CUSTOM/THERMISTOR_CUSTOM in HW */
+ LTC2983_SENSOR_COPPER_TRACE = 32,
+ LTC2983_SENSOR_LEAK_DETECTOR = 33,
+ LTC2983_SENSOR_NUM,
};
+/* Bitmask of sensor types supported by LTC2983/LTC2984 and derivatives */
+#define LTC2983_COMMON_SENSORS \
+ (GENMASK_ULL(LTC2983_SENSOR_THERMOCOUPLE_CUSTOM, LTC2983_SENSOR_THERMOCOUPLE) | \
+ GENMASK_ULL(LTC2983_SENSOR_RTD_CUSTOM, LTC2983_SENSOR_RTD) | \
+ GENMASK_ULL(LTC2983_SENSOR_THERMISTOR_CUSTOM, LTC2983_SENSOR_THERMISTOR) | \
+ BIT_ULL(LTC2983_SENSOR_DIODE) | \
+ BIT_ULL(LTC2983_SENSOR_SENSE_RESISTOR) | \
+ BIT_ULL(LTC2983_SENSOR_DIRECT_ADC))
+
+/* Bitmask of sensor types supported by ADT7604 */
+#define ADT7604_SENSORS \
+ (GENMASK_ULL(LTC2983_SENSOR_RTD_CUSTOM - 1, LTC2983_SENSOR_RTD) | \
+ GENMASK_ULL(LTC2983_SENSOR_THERMISTOR_CUSTOM - 1, LTC2983_SENSOR_THERMISTOR) | \
+ BIT_ULL(LTC2983_SENSOR_SENSE_RESISTOR) | \
+ BIT_ULL(LTC2983_SENSOR_COPPER_TRACE) | \
+ BIT_ULL(LTC2983_SENSOR_LEAK_DETECTOR))
+
#define to_thermocouple(_sensor) \
container_of(_sensor, struct ltc2983_thermocouple, sensor)
#define to_rtd(_sensor) \
container_of(_sensor, struct ltc2983_rtd, sensor)
+#define to_copper_trace(_sensor) \
+ container_of(_sensor, struct ltc2983_copper_trace, sensor)
+
#define to_thermistor(_sensor) \
container_of(_sensor, struct ltc2983_thermistor, sensor)
+#define to_leak_detector(_sensor) \
+ container_of(_sensor, struct ltc2983_leak_detector, sensor)
+
#define to_diode(_sensor) \
container_of(_sensor, struct ltc2983_diode, sensor)
@@ -212,7 +241,7 @@ enum {
struct ltc2983_chip_info {
const char *name;
unsigned int max_channels_nr;
- bool has_temp;
+ u64 supported_sensors;
bool has_eeprom;
};
@@ -247,6 +276,8 @@ struct ltc2983_sensor {
u32 chan;
/* sensor type */
u32 type;
+ /* number of IIO channels this sensor produces */
+ u8 n_iio_chan;
};
struct ltc2983_custom_sensor {
@@ -274,6 +305,25 @@ struct ltc2983_rtd {
u32 rtd_curve;
};
+struct ltc2983_copper_trace {
+ struct ltc2983_sensor sensor;
+ struct ltc2983_custom_sensor *custom;
+ u32 r_sense_chan;
+ u32 excitation_current;
+ /* selects the <1Ω variant: bits 17:0 of the channel word are zeroed,
+ * disabling excitation current and custom table fields (ADT7604
+ * datasheet Table 26)
+ */
+ bool is_sub_ohm;
+};
+
+struct ltc2983_leak_detector {
+ struct ltc2983_sensor sensor;
+ struct ltc2983_custom_sensor *custom;
+ u32 r_sense_chan;
+ u32 excitation_current;
+};
+
struct ltc2983_thermistor {
struct ltc2983_sensor sensor;
struct ltc2983_custom_sensor *custom;
@@ -353,8 +403,14 @@ static int __ltc2983_chan_assign_common(struct ltc2983_data *st,
{
struct device *dev = &st->spi->dev;
u32 reg = LTC2983_CHAN_ASSIGN_ADDR(sensor->chan);
+ u32 hw_type = sensor->type;
- chan_val |= LTC2983_CHAN_TYPE(sensor->type);
+ if (hw_type == LTC2983_SENSOR_COPPER_TRACE)
+ hw_type = LTC2983_SENSOR_RTD_CUSTOM;
+ else if (hw_type == LTC2983_SENSOR_LEAK_DETECTOR)
+ hw_type = LTC2983_SENSOR_THERMISTOR_CUSTOM;
+
+ chan_val |= LTC2983_CHAN_TYPE(hw_type);
dev_dbg(dev, "Assign reg:0x%04X, val:0x%08X\n", reg,
chan_val);
st->chan_val = cpu_to_be32(chan_val);
@@ -486,6 +542,14 @@ __ltc2983_custom_sensor_new(struct ltc2983_data *st, const struct fwnode_handle
for (index = 0; index < n_entries; index++) {
u64 temp = ((u64 *)new_custom->table)[index];
+ /*
+ * Users specify plain coverage percentage (0-100). Convert
+ * to µK so __convert_to_raw() produces the correct hardware
+ * encoding: P + 273.15 K.
+ */
+ if ((index % 2) != 0 && !strcmp(propname, "adi,custom-leak-detector"))
+ temp = temp * 1000000 + 273150000;
+
if ((index % 2) != 0)
temp = __convert_to_raw(temp, 1024);
else if (has_signed && (s64)temp < 0)
@@ -579,6 +643,31 @@ static int ltc2983_rtd_assign_chan(struct ltc2983_data *st,
return __ltc2983_chan_assign_common(st, sensor, chan_val);
}
+static int ltc2983_copper_trace_assign_chan(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_copper_trace *ct = to_copper_trace(sensor);
+ u32 chan_val;
+
+ chan_val = LTC2983_CHAN_ASSIGN(ct->r_sense_chan);
+ /* Sensor config bits 21:18 must be 0b1001 (ADT7604 datasheet Table 26) */
+ chan_val |= LTC2983_RTD_CFG(0x9);
+
+ if (ct->is_sub_ohm) {
+ chan_val &= ~GENMASK(17, 0);
+ } else {
+ int ret;
+
+ chan_val |= LTC2983_RTD_EXC_CURRENT(ct->excitation_current);
+ ret = __ltc2983_chan_custom_sensor_assign(st, ct->custom,
+ &chan_val);
+ if (ret)
+ return ret;
+ }
+
+ return __ltc2983_chan_assign_common(st, sensor, chan_val);
+}
+
static int ltc2983_thermistor_assign_chan(struct ltc2983_data *st,
const struct ltc2983_sensor *sensor)
{
@@ -602,6 +691,25 @@ static int ltc2983_thermistor_assign_chan(struct ltc2983_data *st,
return __ltc2983_chan_assign_common(st, sensor, chan_val);
}
+static int ltc2983_leak_detector_assign_chan(struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct ltc2983_leak_detector *ld = to_leak_detector(sensor);
+ u32 chan_val;
+ int ret;
+
+ chan_val = LTC2983_CHAN_ASSIGN(ld->r_sense_chan);
+ /* bits 21:19 must be 0b001 (ADT7604 datasheet Table 38) */
+ chan_val |= LTC2983_THERMISTOR_CFG(1);
+ chan_val |= LTC2983_THERMISTOR_EXC_CURRENT(ld->excitation_current);
+
+ ret = __ltc2983_chan_custom_sensor_assign(st, ld->custom, &chan_val);
+ if (ret)
+ return ret;
+
+ return __ltc2983_chan_assign_common(st, sensor, chan_val);
+}
+
static int ltc2983_diode_assign_chan(struct ltc2983_data *st,
const struct ltc2983_sensor *sensor)
{
@@ -1037,6 +1145,195 @@ ltc2983_thermistor_new(const struct fwnode_handle *child, struct ltc2983_data *s
return &thermistor->sensor;
}
+static struct ltc2983_sensor *
+ltc2983_copper_trace_new(const struct fwnode_handle *child, struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct device *dev = &st->spi->dev;
+ struct ltc2983_copper_trace *ct;
+ int ret;
+
+ if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
+ return dev_err_ptr_probe(dev, -EINVAL,
+ "Invalid channel %d for copper trace\n",
+ sensor->chan);
+
+ ct = devm_kzalloc(dev, sizeof(*ct), GFP_KERNEL);
+ if (!ct)
+ return ERR_PTR(-ENOMEM);
+
+ struct fwnode_handle *ref __free(fwnode_handle) =
+ fwnode_find_reference(child, "adi,rsense-handle", 0);
+ if (IS_ERR(ref))
+ return dev_err_cast_probe(dev, ref,
+ "Property adi,rsense-handle missing or invalid\n");
+
+ ret = fwnode_property_read_u32(ref, "reg", &ct->r_sense_chan);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret, "Property reg must be given\n");
+
+ ct->is_sub_ohm = fwnode_property_read_bool(child, "adi,copper-trace-sub-ohm");
+
+ if (ct->is_sub_ohm && fwnode_property_present(child, "adi,custom-copper-trace"))
+ return dev_err_ptr_probe(dev, -EINVAL,
+ "sub-ohm copper trace cannot have a custom table\n");
+
+ if (!ct->is_sub_ohm) {
+ u32 excitation_current = 0;
+
+ if (!fwnode_property_present(child, "adi,custom-copper-trace"))
+ return dev_err_ptr_probe(dev, -EINVAL,
+ "adi,custom-copper-trace is required for >1 ohm copper trace\n");
+
+ ct->custom = __ltc2983_custom_sensor_new(st, child, "adi,custom-copper-trace",
+ false, 2048, false);
+ if (IS_ERR(ct->custom))
+ return ERR_CAST(ct->custom);
+
+ if (fwnode_property_present(child, "adi,excitation-current-microamp")) {
+ ret = fwnode_property_read_u32(child, "adi,excitation-current-microamp",
+ &excitation_current);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "Failed to read adi,excitation-current-microamp\n");
+
+ switch (excitation_current) {
+ case 5:
+ ct->excitation_current = 0x01;
+ break;
+ case 10:
+ ct->excitation_current = 0x02;
+ break;
+ case 25:
+ ct->excitation_current = 0x03;
+ break;
+ case 50:
+ ct->excitation_current = 0x04;
+ break;
+ case 100:
+ ct->excitation_current = 0x05;
+ break;
+ case 250:
+ ct->excitation_current = 0x06;
+ break;
+ case 500:
+ ct->excitation_current = 0x07;
+ break;
+ case 1000:
+ ct->excitation_current = 0x08;
+ break;
+ default:
+ return dev_err_ptr_probe(dev, -EINVAL,
+ "Invalid value for excitation current(%u)\n",
+ excitation_current);
+ }
+ } else {
+ /* default to 1mA per datasheet recommendation for copper trace */
+ ct->excitation_current = 0x08;
+ }
+ }
+
+ ct->sensor.fault_handler = ltc2983_common_fault_handler;
+ ct->sensor.assign_chan = ltc2983_copper_trace_assign_chan;
+ if (ct->is_sub_ohm)
+ ct->sensor.n_iio_chan = 1;
+ else
+ ct->sensor.n_iio_chan = 2;
+
+ return &ct->sensor;
+}
+
+static struct ltc2983_sensor *
+ltc2983_leak_detector_new(const struct fwnode_handle *child, struct ltc2983_data *st,
+ const struct ltc2983_sensor *sensor)
+{
+ struct device *dev = &st->spi->dev;
+ struct ltc2983_leak_detector *ld;
+ int ret;
+ u32 excitation_current = 0;
+
+ if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
+ return dev_err_ptr_probe(dev, -EINVAL,
+ "Invalid channel %d for leak detector\n",
+ sensor->chan);
+
+ ld = devm_kzalloc(dev, sizeof(*ld), GFP_KERNEL);
+ if (!ld)
+ return ERR_PTR(-ENOMEM);
+
+ struct fwnode_handle *ref __free(fwnode_handle) =
+ fwnode_find_reference(child, "adi,rsense-handle", 0);
+ if (IS_ERR(ref))
+ return dev_err_cast_probe(dev, ref,
+ "Property adi,rsense-handle missing or invalid\n");
+
+ ret = fwnode_property_read_u32(ref, "reg", &ld->r_sense_chan);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "rsense channel must be configured\n");
+
+ if (!fwnode_property_present(child, "adi,custom-leak-detector"))
+ return dev_err_ptr_probe(dev, -EINVAL,
+ "adi,custom-leak-detector is required for leak detectors\n");
+
+ ld->custom = __ltc2983_custom_sensor_new(st, child, "adi,custom-leak-detector",
+ false, 16, false);
+ if (IS_ERR(ld->custom))
+ return ERR_CAST(ld->custom);
+
+ ret = fwnode_property_read_u32(child, "adi,excitation-current-nanoamp",
+ &excitation_current);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "adi,excitation-current-nanoamp is required for leak detectors\n");
+
+ switch (excitation_current) {
+ case 250:
+ ld->excitation_current = 0x01;
+ break;
+ case 500:
+ ld->excitation_current = 0x02;
+ break;
+ case 1000:
+ ld->excitation_current = 0x03;
+ break;
+ case 5000:
+ ld->excitation_current = 0x04;
+ break;
+ case 10000:
+ ld->excitation_current = 0x05;
+ break;
+ case 25000:
+ ld->excitation_current = 0x06;
+ break;
+ case 50000:
+ ld->excitation_current = 0x07;
+ break;
+ case 100000:
+ ld->excitation_current = 0x08;
+ break;
+ case 250000:
+ ld->excitation_current = 0x09;
+ break;
+ case 500000:
+ ld->excitation_current = 0x0a;
+ break;
+ case 1000000:
+ ld->excitation_current = 0x0b;
+ break;
+ default:
+ return dev_err_ptr_probe(dev, -EINVAL,
+ "Invalid value for excitation current(%u)\n",
+ excitation_current);
+ }
+
+ ld->sensor.fault_handler = ltc2983_common_fault_handler;
+ ld->sensor.assign_chan = ltc2983_leak_detector_assign_chan;
+ ld->sensor.n_iio_chan = 2;
+
+ return &ld->sensor;
+}
+
static struct ltc2983_sensor *
ltc2983_diode_new(const struct fwnode_handle *child, const struct ltc2983_data *st,
const struct ltc2983_sensor *sensor)
@@ -1205,7 +1502,8 @@ static struct ltc2983_sensor *ltc2983_temp_new(struct fwnode_handle *child,
}
static int ltc2983_chan_read(struct ltc2983_data *st,
- const struct ltc2983_sensor *sensor, int *val)
+ const struct ltc2983_sensor *sensor,
+ u32 base_reg, int *val)
{
struct device *dev = &st->spi->dev;
u32 start_conversion = 0;
@@ -1236,13 +1534,23 @@ static int ltc2983_chan_read(struct ltc2983_data *st,
}
/* read the converted data */
- ret = regmap_bulk_read(st->regmap, LTC2983_RESULT_ADDR(sensor->chan),
+ ret = regmap_bulk_read(st->regmap, LTC2983_RESULT_ADDR(sensor->chan, base_reg),
&st->temp, sizeof(st->temp));
if (ret)
return ret;
*val = __be32_to_cpu(st->temp);
+ if (base_reg == ADT7604_RES_RES_START_REG) {
+ /*
+ * Resistance result register gives a plain unsigned value,
+ * D31 is always 0, no valid bit, no fault bits. Read bits[30:0]
+ * directly — the temperature result format does not apply here.
+ */
+ *val &= GENMASK(30, 0);
+ return 0;
+ }
+
if (!(LTC2983_RES_VALID_MASK & *val)) {
dev_err(dev, "Invalid conversion detected\n");
return -EIO;
@@ -1274,7 +1582,16 @@ static int ltc2983_read_raw(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_RAW:
mutex_lock(&st->lock);
- ret = ltc2983_chan_read(st, st->sensors[chan->address], val);
+ switch (chan->type) {
+ case IIO_RESISTANCE:
+ ret = ltc2983_chan_read(st, st->sensors[chan->address],
+ ADT7604_RES_RES_START_REG, val);
+ break;
+ default:
+ ret = ltc2983_chan_read(st, st->sensors[chan->address],
+ LTC2983_TEMP_RES_START_REG, val);
+ break;
+ }
mutex_unlock(&st->lock);
return ret ?: IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
@@ -1291,6 +1608,13 @@ static int ltc2983_read_raw(struct iio_dev *indio_dev,
/* 2^21 */
*val2 = 2097152;
return IIO_VAL_FRACTIONAL;
+ case IIO_RESISTANCE:
+ case IIO_COVERAGE:
+ /* value in ohm/percent */
+ *val = 1;
+ /* 2^10 */
+ *val2 = 1024;
+ return IIO_VAL_FRACTIONAL;
default:
return -EINVAL;
}
@@ -1351,7 +1675,7 @@ static int ltc2983_parse_fw(struct ltc2983_data *st)
if (!st->sensors)
return -ENOMEM;
- st->iio_channels = st->num_channels;
+ st->iio_channels = 0;
device_for_each_child_node_scoped(dev, child) {
struct ltc2983_sensor sensor;
@@ -1379,6 +1703,12 @@ static int ltc2983_parse_fw(struct ltc2983_data *st)
return dev_err_probe(dev, ret,
"adi,sensor-type property must given for child nodes\n");
+ if (sensor.type >= LTC2983_SENSOR_NUM ||
+ !(st->info->supported_sensors & BIT_ULL(sensor.type)))
+ return dev_err_probe(dev, -EINVAL,
+ "sensor type %d not supported on %s\n",
+ sensor.type, st->info->name);
+
dev_dbg(dev, "Create new sensor, type %u, channel %u",
sensor.type, sensor.chan);
@@ -1399,13 +1729,14 @@ static int ltc2983_parse_fw(struct ltc2983_data *st)
} else if (sensor.type == LTC2983_SENSOR_SENSE_RESISTOR) {
st->sensors[chan] = ltc2983_r_sense_new(child, st,
&sensor);
- /* don't add rsense to iio */
- st->iio_channels--;
} else if (sensor.type == LTC2983_SENSOR_DIRECT_ADC) {
st->sensors[chan] = ltc2983_adc_new(child, st, &sensor);
- } else if (st->info->has_temp &&
- sensor.type == LTC2983_SENSOR_ACTIVE_TEMP) {
+ } else if (sensor.type == LTC2983_SENSOR_ACTIVE_TEMP) {
st->sensors[chan] = ltc2983_temp_new(child, st, &sensor);
+ } else if (sensor.type == LTC2983_SENSOR_COPPER_TRACE) {
+ st->sensors[chan] = ltc2983_copper_trace_new(child, st, &sensor);
+ } else if (sensor.type == LTC2983_SENSOR_LEAK_DETECTOR) {
+ st->sensors[chan] = ltc2983_leak_detector_new(child, st, &sensor);
} else {
return dev_err_probe(dev, -EINVAL,
"Unknown sensor type %d\n",
@@ -1420,6 +1751,16 @@ static int ltc2983_parse_fw(struct ltc2983_data *st)
st->sensors[chan]->chan = sensor.chan;
st->sensors[chan]->type = sensor.type;
+ /*
+ * Dedicated functions set n_iio_chan themselves; for all other
+ * sensor types rsense produces 0 channels, everything else 1.
+ */
+ if (!st->sensors[chan]->n_iio_chan) {
+ if (sensor.type != LTC2983_SENSOR_SENSE_RESISTOR)
+ st->sensors[chan]->n_iio_chan = 1;
+ }
+ st->iio_channels += st->sensors[chan]->n_iio_chan;
+
channel_avail_mask |= BIT(sensor.chan);
chan++;
}
@@ -1467,8 +1808,9 @@ static int ltc2983_eeprom_cmd(struct ltc2983_data *st, unsigned int cmd,
static int ltc2983_setup(struct ltc2983_data *st, bool assign_iio)
{
- u32 iio_chan_t = 0, iio_chan_v = 0, chan, iio_idx = 0, status;
struct device *dev = &st->spi->dev;
+ u32 iio_chan_t = 0, iio_chan_v = 0, iio_chan_r = 0, iio_chan_c = 0;
+ u32 chan, iio_idx = 0, status;
int ret;
/* make sure the device is up: start bit (7) is 0 and done bit (6) is 1 */
@@ -1516,12 +1858,33 @@ static int ltc2983_setup(struct ltc2983_data *st, bool assign_iio)
continue;
/* assign iio channel */
- if (st->sensors[chan]->type != LTC2983_SENSOR_DIRECT_ADC) {
- chan_type = IIO_TEMP;
- iio_chan = &iio_chan_t;
- } else {
+ switch (st->sensors[chan]->type) {
+ case LTC2983_SENSOR_COPPER_TRACE:
+ if (st->sensors[chan]->n_iio_chan == 1) {
+ /* sub-ohm copper traces produce only a resistance result */
+ st->iio_chan[iio_idx++] =
+ LTC2983_CHAN(IIO_RESISTANCE, iio_chan_r++, chan);
+ } else {
+ st->iio_chan[iio_idx++] =
+ LTC2983_CHAN(IIO_TEMP, iio_chan_t++, chan);
+ st->iio_chan[iio_idx++] =
+ LTC2983_CHAN(IIO_RESISTANCE, iio_chan_r++, chan);
+ }
+ continue;
+ case LTC2983_SENSOR_LEAK_DETECTOR:
+ st->iio_chan[iio_idx++] =
+ LTC2983_CHAN(IIO_COVERAGE, iio_chan_c++, chan);
+ st->iio_chan[iio_idx++] =
+ LTC2983_CHAN(IIO_RESISTANCE, iio_chan_r++, chan);
+ continue;
+ case LTC2983_SENSOR_DIRECT_ADC:
chan_type = IIO_VOLTAGE;
iio_chan = &iio_chan_v;
+ break;
+ default:
+ chan_type = IIO_TEMP;
+ iio_chan = &iio_chan_t;
+ break;
}
/*
@@ -1538,6 +1901,7 @@ static int ltc2983_setup(struct ltc2983_data *st, bool assign_iio)
static const struct regmap_range ltc2983_reg_ranges[] = {
regmap_reg_range(LTC2983_STATUS_REG, LTC2983_STATUS_REG),
regmap_reg_range(LTC2983_TEMP_RES_START_REG, LTC2983_TEMP_RES_END_REG),
+ regmap_reg_range(ADT7604_RES_RES_START_REG, ADT7604_RES_RES_END_REG),
regmap_reg_range(LTC2983_EEPROM_KEY_REG, LTC2983_EEPROM_KEY_REG),
regmap_reg_range(LTC2983_EEPROM_READ_STATUS_REG,
LTC2983_EEPROM_READ_STATUS_REG),
@@ -1680,26 +2044,35 @@ static DEFINE_SIMPLE_DEV_PM_OPS(ltc2983_pm_ops, ltc2983_suspend,
static const struct ltc2983_chip_info ltc2983_chip_info_data = {
.name = "ltc2983",
.max_channels_nr = 20,
+ .supported_sensors = LTC2983_COMMON_SENSORS,
};
static const struct ltc2983_chip_info ltc2984_chip_info_data = {
.name = "ltc2984",
.max_channels_nr = 20,
.has_eeprom = true,
+ .supported_sensors = LTC2983_COMMON_SENSORS,
};
static const struct ltc2983_chip_info ltc2986_chip_info_data = {
.name = "ltc2986",
.max_channels_nr = 10,
- .has_temp = true,
.has_eeprom = true,
+ .supported_sensors = LTC2983_COMMON_SENSORS | BIT_ULL(LTC2983_SENSOR_ACTIVE_TEMP),
};
static const struct ltc2983_chip_info ltm2985_chip_info_data = {
.name = "ltm2985",
.max_channels_nr = 10,
- .has_temp = true,
.has_eeprom = true,
+ .supported_sensors = LTC2983_COMMON_SENSORS | BIT_ULL(LTC2983_SENSOR_ACTIVE_TEMP),
+};
+
+static const struct ltc2983_chip_info adt7604_chip_info_data = {
+ .name = "adt7604",
+ .max_channels_nr = 20,
+ .has_eeprom = true,
+ .supported_sensors = ADT7604_SENSORS,
};
static const struct spi_device_id ltc2983_id_table[] = {
@@ -1707,6 +2080,7 @@ static const struct spi_device_id ltc2983_id_table[] = {
{ "ltc2984", (kernel_ulong_t)<c2984_chip_info_data },
{ "ltc2986", (kernel_ulong_t)<c2986_chip_info_data },
{ "ltm2985", (kernel_ulong_t)<m2985_chip_info_data },
+ { "adt7604", (kernel_ulong_t)&adt7604_chip_info_data },
{ }
};
MODULE_DEVICE_TABLE(spi, ltc2983_id_table);
@@ -1716,6 +2090,7 @@ static const struct of_device_id ltc2983_of_match[] = {
{ .compatible = "adi,ltc2984", .data = <c2984_chip_info_data },
{ .compatible = "adi,ltc2986", .data = <c2986_chip_info_data },
{ .compatible = "adi,ltm2985", .data = <m2985_chip_info_data },
+ { .compatible = "adi,adt7604", .data = &adt7604_chip_info_data },
{ }
};
MODULE_DEVICE_TABLE(of, ltc2983_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH v3 7/8] dt-bindings: iio: temperature: Add ADT7604 support to adi,ltc2983
From: Liviu Stan @ 2026-05-21 16:43 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Liviu Stan, Francesco Lavra, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521164323.770626-1-liviu.stan@analog.com>
The ADT7604 shares the same die as the LTC2984. It repurposes the
custom RTD sensor type (18) as a copper trace resistance sensor
and the custom thermistor type (27) as a leak detector, and
removes thermocouple, diode and direct ADC sensor types.
Add adi,adt7604 to the compatible list and introduce two new
sensor node types specific to this device:
- copper-trace@: maps to the custom RTD sensor type (18). Two
variants: sub-ohm (< 1 ohm, adi,copper-trace-sub-ohm boolean,
no custom table and excitation current) and standard (> 1 ohm,
required adi,custom-copper-trace table, optional excitation current
defaulting to the datasheet recommended value). Primary output
is resistance in ohms. For > 1 ohm copper traces with a custom table,
the chip also outputs temperature in millidegrees Celsius.
- leak-detector@: maps to the custom thermistor sensor type (27).
Takes a required adi,custom-leak-detector lookup table encoding
resistance (uOhm) against coverage data (%). Two outputs:
resistance in ohms and coverage in percent.
Separate node types are used rather than extending the existing
rtd@ and thermistor@ nodes because adi,custom-rtd is required
for sensor type 18, and several properties (adi,number-of-wires,
adi,rtd-curve, adi,rsense-share, adi,single-ended,
adi,current-rotate) have no meaning for the new sensor types, since
the configuration is hardcoded, and would need to be explicitly
forbidden or ignored in the driver.
allOf conditions are added to restrict thermocouple, diode, direct
ADC and active temperature nodes to non-ADT7604 devices, and to
restrict copper-trace and leak-detector nodes to the ADT7604
(some parts only).
Signed-off-by: Liviu Stan <liviu.stan@analog.com>
---
Changes in v3:
- Changed the custom leak detector table encoding, users now specify
plain coverage percentage values (0-100) in the device tree and the
driver applies the +273.15 C offset internally before writing the
hardware table
- Changed custom-rtd to custom-copper-trace to better represent the
copper trace custom table, and made it required for > 1 ohm variants
- Made custom-leak-detector required for leak detector sensors
- Updated commit message to reflect the changes
- Updated leak detector node description
- Updated adi,custom-leak-detector description
- Modified the example leak detector custom table to match the datasheet
.../bindings/iio/temperature/adi,ltc2983.yaml | 207 +++++++++++++++++-
1 file changed, 204 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
index a22725f7619b..14cfa28809ed 100644
--- a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
+++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
@@ -4,14 +4,18 @@
$id: http://devicetree.org/schemas/iio/temperature/adi,ltc2983.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices LTC2983, LTC2986, LTM2985 Multi-sensor Temperature system
+title: Analog Devices LTC2983 and similar Multi-sensor Temperature systems
maintainers:
- Nuno Sá <nuno.sa@analog.com>
description: |
- Analog Devices LTC2983, LTC2984, LTC2986, LTM2985 Multi-Sensor Digital
- Temperature Measurement Systems
+ Analog Devices Multi-Sensor Digital Temperature Measurement Systems:
+ - ADT7604
+ - LTC2983
+ - LTC2984
+ - LTC2986
+ - LTM2985
https://www.analog.com/media/en/technical-documentation/data-sheets/2983fc.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/2984fb.pdf
@@ -43,6 +47,7 @@ properties:
compatible:
oneOf:
- enum:
+ - adi,adt7604
- adi,ltc2983
- adi,ltc2986
- adi,ltm2985
@@ -436,6 +441,121 @@ patternProperties:
required:
- adi,custom-temp
+ '^copper-trace@':
+ $ref: '#/$defs/sensor-node'
+ unevaluatedProperties: false
+ description: |
+ Copper trace resistance sensor (some parts only). Two variants exist:
+ sub-ohm (< 1 ohm, no custom table allowed) and standard (> 1 ohm,
+ required custom table).
+
+ properties:
+ reg:
+ minimum: 2
+ maximum: 20
+
+ adi,sensor-type:
+ description: Sensor type for copper trace sensors.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ const: 32
+
+ adi,rsense-handle:
+ description: Associated sense resistor sensor.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ adi,copper-trace-sub-ohm:
+ description:
+ Select the sub-ohm (< 1 ohm) copper trace variant. Custom table
+ and excitation current are not allowed in this mode.
+ type: boolean
+
+ adi,excitation-current-microamp:
+ description:
+ Excitation current applied to the copper trace. Not used in
+ sub-ohm mode. The datasheet recommends 1mA for copper trace
+ sensors due to their typically small resistance.
+ enum: [5, 10, 25, 50, 100, 250, 500, 1000]
+ default: 1000
+
+ adi,custom-copper-trace:
+ description:
+ Resistance-to-temperature table for copper trace sensors with
+ resistance > 1 ohm. Required when adi,copper-trace-sub-ohm is not
+ set. See Page 36 of the datasheet.
+ $ref: /schemas/types.yaml#/definitions/uint64-matrix
+ minItems: 3
+ maxItems: 64
+ items:
+ items:
+ - description: Resistance point in uOhms.
+ - description: Temperature point in uK.
+
+ required:
+ - adi,rsense-handle
+
+ allOf:
+ - if:
+ required:
+ - adi,copper-trace-sub-ohm
+ then:
+ properties:
+ adi,custom-copper-trace: false
+ adi,excitation-current-microamp: false
+ - if:
+ not:
+ required:
+ - adi,copper-trace-sub-ohm
+ then:
+ required:
+ - adi,custom-copper-trace
+
+ '^leak-detector@':
+ $ref: '#/$defs/sensor-node'
+ unevaluatedProperties: false
+ description: |
+ Leak detector sensor (some parts only). Outputs resistance in ohms and
+ a coverage percentage via IIO_COVERAGE (raw/1024 = coverage %).
+
+ properties:
+ reg:
+ minimum: 2
+ maximum: 20
+
+ adi,sensor-type:
+ description: Sensor type for leak detector sensors.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ const: 33
+
+ adi,rsense-handle:
+ description: Associated sense resistor sensor.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ adi,excitation-current-nanoamp:
+ description:
+ Excitation current applied to the leak detector. The correct value
+ depends on the electrical characteristics of the liquid being sensed.
+ For example, 10000 (10µA) is recommended for PG25 (see datasheet
+ Table 39).
+ enum: [250, 500, 1000, 5000, 10000, 25000, 50000, 100000, 250000,
+ 500000, 1000000]
+
+ adi,custom-leak-detector:
+ description: |
+ Lookup table mapping resistance to coverage percentage. Entries must
+ be in ascending resistance order.
+ $ref: /schemas/types.yaml#/definitions/uint64-matrix
+ minItems: 3
+ maxItems: 64
+ items:
+ items:
+ - description: Resistance point in uOhms.
+ - description: Coverage data percentage (0 to 100).
+
+ required:
+ - adi,rsense-handle
+ - adi,excitation-current-nanoamp
+ - adi,custom-leak-detector
+
'^rsense@':
$ref: '#/$defs/sensor-node'
unevaluatedProperties: false
@@ -477,6 +597,22 @@ allOf:
patternProperties:
'^temp@': false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,adt7604
+ then:
+ patternProperties:
+ '^thermocouple@': false
+ '^diode@': false
+ '^adc@': false
+ '^temp@': false
+ else:
+ patternProperties:
+ '^copper-trace@': false
+ '^leak-detector@': false
+
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
@@ -556,4 +692,69 @@ examples:
};
};
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@0 {
+ compatible = "adi,adt7604";
+ reg = <0>;
+ interrupt-parent = <&gpio>;
+ interrupts = <25 IRQ_TYPE_EDGE_RISING>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ vdd-supply = <&supply>;
+
+ trace_rsense: rsense@2 {
+ reg = <2>;
+ adi,sensor-type = <29>;
+ adi,rsense-val-milli-ohms = <100000>; // 100 ohm
+ };
+
+ copper-trace@4 {
+ reg = <4>;
+ adi,sensor-type = <32>;
+ adi,rsense-handle = <&trace_rsense>;
+ adi,copper-trace-sub-ohm;
+ };
+
+ r_sense: rsense@12 {
+ reg = <12>;
+ adi,sensor-type = <29>;
+ adi,rsense-val-milli-ohms = <1000000>; // 1 kohm
+ };
+
+ leak-detector@14 {
+ reg = <14>;
+ adi,sensor-type = <33>;
+ adi,rsense-handle = <&r_sense>;
+ adi,excitation-current-nanoamp = <10000>;
+ adi,custom-leak-detector =
+ /bits/ 64 < 0 100>,
+ /bits/ 64 < 202020000 99>,
+ /bits/ 64 < 285710000 70>,
+ /bits/ 64 < 333330000 60>,
+ /bits/ 64 < 400000000 50>,
+ /bits/ 64 < 500000000 40>,
+ /bits/ 64 < 666670000 30>,
+ /bits/ 64 < 1000000000 20>,
+ /bits/ 64 < 2000000000 10>,
+ /bits/ 64 <1000000000000 0>;
+ };
+
+ rtd@18 {
+ reg = <18>;
+ adi,sensor-type = <12>; // PT100
+ adi,rsense-handle = <&r_sense>;
+ adi,number-of-wires = <2>;
+ adi,rsense-share;
+ adi,excitation-current-microamp = <500>;
+ adi,rtd-curve = <0>;
+ };
+ };
+ };
...
--
2.43.0
^ permalink raw reply related
* [PATCH v3 6/8] iio: core: Add IIO_COVERAGE channel type
From: Liviu Stan @ 2026-05-21 16:42 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, Liviu Stan, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521164323.770626-1-liviu.stan@analog.com>
Add a new channel type for sensors that report fractional coverage as
a percentage. The sysfs attribute is in_coverageX_raw; after applying
in_coverageX_scale the value is in percent. The first user is the
ADT7604 leak detector, where the value represents the portion of the
sensing element that is wetted.
Signed-off-by: Liviu Stan <liviu.stan@analog.com>
---
Changes in v3:
- Renamed the sysfs attribute from in_coveragepercentX_raw to
in_coverageX_raw
- Added a _scale ABI documentation entry
- Corrected KernelVersion in the ABI documentation from 6.15 to 7.2
- Added IIO_COVERAGE to the event_is_known() switch in
tools/iio/iio_event_monitor.c
Documentation/ABI/testing/sysfs-bus-iio | 17 +++++++++++++++++
drivers/iio/industrialio-core.c | 1 +
include/uapi/linux/iio/types.h | 1 +
tools/iio/iio_event_monitor.c | 2 ++
4 files changed, 21 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 925a33fd309a..ca20ad5860dc 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1980,6 +1980,23 @@ Description:
Raw (unscaled no offset etc.) resistance reading.
Units after application of scale and offset are ohms.
+What: /sys/bus/iio/devices/iio:deviceX/in_coverageX_raw
+KernelVersion: 7.2
+Contact: linux-iio@vger.kernel.org
+Description:
+ Raw (unscaled no offset etc.) coverage reading. Used for sensors
+ that report fractional coverage as a percentage, such as leak
+ detectors where the value represents what portion of the sensing
+ element is wetted. Units after application of scale and offset are
+ percent.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_coverageX_scale
+KernelVersion: 7.2
+Contact: linux-iio@vger.kernel.org
+Description:
+ Scale to be applied to in_coverageX_raw to obtain coverage
+ in percent.
+
What: /sys/bus/iio/devices/iio:deviceX/heater_enable
KernelVersion: 4.1.0
Contact: linux-iio@vger.kernel.org
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index bd6f4f9f4533..ffe0dc49c4b9 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -98,6 +98,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CHROMATICITY] = "chromaticity",
[IIO_ATTENTION] = "attention",
[IIO_ALTCURRENT] = "altcurrent",
+ [IIO_COVERAGE] = "coverage",
};
static const char * const iio_modifier_names[] = {
diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
index d7c2bb223651..c9295c707041 100644
--- a/include/uapi/linux/iio/types.h
+++ b/include/uapi/linux/iio/types.h
@@ -53,6 +53,7 @@ enum iio_chan_type {
IIO_CHROMATICITY,
IIO_ATTENTION,
IIO_ALTCURRENT,
+ IIO_COVERAGE,
};
enum iio_modifier {
diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
index df6c43d7738d..bc3ef4c77c2b 100644
--- a/tools/iio/iio_event_monitor.c
+++ b/tools/iio/iio_event_monitor.c
@@ -65,6 +65,7 @@ static const char * const iio_chan_type_name_spec[] = {
[IIO_CHROMATICITY] = "chromaticity",
[IIO_ATTENTION] = "attention",
[IIO_ALTCURRENT] = "altcurrent",
+ [IIO_COVERAGE] = "coverage",
};
static const char * const iio_ev_type_text[] = {
@@ -194,6 +195,7 @@ static bool event_is_known(struct iio_event_data *event)
case IIO_CHROMATICITY:
case IIO_ATTENTION:
case IIO_ALTCURRENT:
+ case IIO_COVERAGE:
break;
default:
return false;
--
2.43.0
^ permalink raw reply related
* [PATCH v3 5/8] iio: temperature: ltc2983: Fix n_wires default bypassing rotation check
From: Liviu Stan @ 2026-05-21 16:42 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, Liviu Stan, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521164323.770626-1-liviu.stan@analog.com>
When adi,number-of-wires is absent, n_wires is left at 0. The binding
documents a default of 2 wires, matching the hardware default. However
the current-rotate validation checks n_wires == 2 || n_wires == 3, so
with n_wires = 0 the guard is bypassed and adi,current-rotate is accepted
for a 2-wire RTD.
Initialize n_wires = 2 to match the binding default and ensure the
rotation check fires correctly when the property is absent.
Fixes: f110f3188e56 ("iio: temperature: Add support for LTC2983")
Signed-off-by: Liviu Stan <liviu.stan@analog.com>
---
Changes in v3:
- New patch
drivers/iio/temperature/ltc2983.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
index 10f423fbe9cc..326f843f4271 100644
--- a/drivers/iio/temperature/ltc2983.c
+++ b/drivers/iio/temperature/ltc2983.c
@@ -749,7 +749,7 @@ ltc2983_rtd_new(const struct fwnode_handle *child, struct ltc2983_data *st,
struct ltc2983_rtd *rtd;
int ret = 0;
struct device *dev = &st->spi->dev;
- u32 excitation_current = 0, n_wires = 0;
+ u32 excitation_current = 0, n_wires = 2;
rtd = devm_kzalloc(dev, sizeof(*rtd), GFP_KERNEL);
if (!rtd)
--
2.43.0
^ permalink raw reply related
* [PATCH v3 4/8] iio: temperature: ltc2983: Use fwnode_property_present() for optional properties
From: Liviu Stan @ 2026-05-21 16:42 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, Liviu Stan, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521164323.770626-1-liviu.stan@analog.com>
Checking fwnode_property_read_u32() return value with if (!ret)
silently swallows meaningful error codes when a property is present
but malformed. Use fwnode_property_present() first so that absence
uses the default while a present but unreadable property returns
a proper error.
Signed-off-by: Liviu Stan <liviu.stan@analog.com>
---
Changes in v3:
- Dropped the Fixes: tag
- Fixed other occurrences brought up by sashiko
drivers/iio/temperature/ltc2983.c | 84 +++++++++++++++++++++----------
1 file changed, 58 insertions(+), 26 deletions(-)
diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
index 0b9e5f761bd8..10f423fbe9cc 100644
--- a/drivers/iio/temperature/ltc2983.c
+++ b/drivers/iio/temperature/ltc2983.c
@@ -669,8 +669,14 @@ ltc2983_thermocouple_new(const struct fwnode_handle *child, struct ltc2983_data
if (fwnode_property_read_bool(child, "adi,single-ended"))
thermo->sensor_config = LTC2983_THERMOCOUPLE_SGL(1);
- ret = fwnode_property_read_u32(child, "adi,sensor-oc-current-microamp", &oc_current);
- if (!ret) {
+ if (fwnode_property_present(child, "adi,sensor-oc-current-microamp")) {
+ ret = fwnode_property_read_u32(child,
+ "adi,sensor-oc-current-microamp",
+ &oc_current);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "Failed to read adi,sensor-oc-current-microamp\n");
+
switch (oc_current) {
case 10:
thermo->sensor_config |=
@@ -760,8 +766,12 @@ ltc2983_rtd_new(const struct fwnode_handle *child, struct ltc2983_data *st,
return dev_err_ptr_probe(dev, ret,
"Property reg must be given\n");
- ret = fwnode_property_read_u32(child, "adi,number-of-wires", &n_wires);
- if (!ret) {
+ if (fwnode_property_present(child, "adi,number-of-wires")) {
+ ret = fwnode_property_read_u32(child, "adi,number-of-wires", &n_wires);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "Failed to read adi,number-of-wires\n");
+
switch (n_wires) {
case 2:
rtd->sensor_config = LTC2983_RTD_N_WIRES(0);
@@ -843,12 +853,13 @@ ltc2983_rtd_new(const struct fwnode_handle *child, struct ltc2983_data *st,
rtd->sensor.fault_handler = ltc2983_common_fault_handler;
rtd->sensor.assign_chan = ltc2983_rtd_assign_chan;
- ret = fwnode_property_read_u32(child, "adi,excitation-current-microamp",
- &excitation_current);
- if (ret) {
- /* default to 5uA */
- rtd->excitation_current = 1;
- } else {
+ if (fwnode_property_present(child, "adi,excitation-current-microamp")) {
+ ret = fwnode_property_read_u32(child, "adi,excitation-current-microamp",
+ &excitation_current);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "Failed to read adi,excitation-current-microamp\n");
+
switch (excitation_current) {
case 5:
rtd->excitation_current = 0x01;
@@ -879,9 +890,17 @@ ltc2983_rtd_new(const struct fwnode_handle *child, struct ltc2983_data *st,
"Invalid value for excitation current(%u)\n",
excitation_current);
}
+ } else {
+ /* default to 5uA */
+ rtd->excitation_current = 1;
}
- fwnode_property_read_u32(child, "adi,rtd-curve", &rtd->rtd_curve);
+ if (fwnode_property_present(child, "adi,rtd-curve")) {
+ ret = fwnode_property_read_u32(child, "adi,rtd-curve", &rtd->rtd_curve);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "Failed to read adi,rtd-curve\n");
+ }
return &rtd->sensor;
}
@@ -951,17 +970,13 @@ ltc2983_thermistor_new(const struct fwnode_handle *child, struct ltc2983_data *s
thermistor->sensor.fault_handler = ltc2983_common_fault_handler;
thermistor->sensor.assign_chan = ltc2983_thermistor_assign_chan;
- ret = fwnode_property_read_u32(child, "adi,excitation-current-nanoamp",
- &excitation_current);
- if (ret) {
- /* Auto range is not allowed for custom sensors */
- if (sensor->type >= LTC2983_SENSOR_THERMISTOR_STEINHART)
- /* default to 1uA */
- thermistor->excitation_current = 0x03;
- else
- /* default to auto-range */
- thermistor->excitation_current = 0x0c;
- } else {
+ if (fwnode_property_present(child, "adi,excitation-current-nanoamp")) {
+ ret = fwnode_property_read_u32(child, "adi,excitation-current-nanoamp",
+ &excitation_current);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "Failed to read adi,excitation-current-nanoamp\n");
+
switch (excitation_current) {
case 0:
/* auto range */
@@ -1009,6 +1024,14 @@ ltc2983_thermistor_new(const struct fwnode_handle *child, struct ltc2983_data *s
"Invalid value for excitation current(%u)\n",
excitation_current);
}
+ } else {
+ /* Auto range is not allowed for custom sensors */
+ if (sensor->type >= LTC2983_SENSOR_THERMISTOR_STEINHART)
+ /* default to 1uA */
+ thermistor->excitation_current = 0x03;
+ else
+ /* default to auto-range */
+ thermistor->excitation_current = 0x0c;
}
return &thermistor->sensor;
@@ -1047,9 +1070,13 @@ ltc2983_diode_new(const struct fwnode_handle *child, const struct ltc2983_data *
diode->sensor.fault_handler = ltc2983_common_fault_handler;
diode->sensor.assign_chan = ltc2983_diode_assign_chan;
- ret = fwnode_property_read_u32(child, "adi,excitation-current-microamp",
- &excitation_current);
- if (!ret) {
+ if (fwnode_property_present(child, "adi,excitation-current-microamp")) {
+ ret = fwnode_property_read_u32(child, "adi,excitation-current-microamp",
+ &excitation_current);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "Failed to read adi,excitation-current-microamp\n");
+
switch (excitation_current) {
case 10:
diode->excitation_current = 0x00;
@@ -1070,7 +1097,12 @@ ltc2983_diode_new(const struct fwnode_handle *child, const struct ltc2983_data *
}
}
- fwnode_property_read_u32(child, "adi,ideal-factor-value", &temp);
+ if (fwnode_property_present(child, "adi,ideal-factor-value")) {
+ ret = fwnode_property_read_u32(child, "adi,ideal-factor-value", &temp);
+ if (ret)
+ return dev_err_ptr_probe(dev, ret,
+ "Failed to read adi,ideal-factor-value\n");
+ }
/* 2^20 resolution */
diode->ideal_factor_value = __convert_to_raw(temp, 1048576);
--
2.43.0
^ permalink raw reply related
* [PATCH v3 3/8] iio: temperature: ltc2983: Fix inconsistent channel wording in messages
From: Liviu Stan @ 2026-05-21 16:42 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Liviu Stan, Francesco Lavra, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521164323.770626-1-liviu.stan@analog.com>
Replace occurrences of the abbreviated 'chann' and 'chan' with
'channel' in error and debug messages throughout the driver.
Also changed the diode invalid channel error message from
"thermistor" to "diode".
Signed-off-by: Liviu Stan <liviu.stan@analog.com>
---
Changes in v3:
- Dropped both Fixes: tags
- Removed the "all" from "all occurrences" in the commit message
- Fixed some missed "chan" / "chann" occurrences
drivers/iio/temperature/ltc2983.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
index d9dcf3e86696..0b9e5f761bd8 100644
--- a/drivers/iio/temperature/ltc2983.c
+++ b/drivers/iio/temperature/ltc2983.c
@@ -700,7 +700,7 @@ ltc2983_thermocouple_new(const struct fwnode_handle *child, struct ltc2983_data
if (!(thermo->sensor_config & LTC2983_THERMOCOUPLE_DIFF_MASK) &&
sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
return dev_err_ptr_probe(dev, -EINVAL,
- "Invalid chann:%d for differential thermocouple\n",
+ "Invalid channel %d for differential thermocouple\n",
sensor->chan);
struct fwnode_handle *ref __free(fwnode_handle) =
@@ -798,7 +798,7 @@ ltc2983_rtd_new(const struct fwnode_handle *child, struct ltc2983_data *st,
/*
* rtd channel indexes are a bit more complicated to validate.
* For 4wire RTD with rotation, the channel selection cannot be
- * >=19 since the chann + 1 is used in this configuration.
+ * >=19 since the channel + 1 is used in this configuration.
* For 4wire RTDs with kelvin rsense, the rsense channel cannot be
* <=1 since channel - 1 and channel - 2 are used.
*/
@@ -815,18 +815,18 @@ ltc2983_rtd_new(const struct fwnode_handle *child, struct ltc2983_data *st,
(rtd->r_sense_chan <= min))
/* kelvin rsense*/
return dev_err_ptr_probe(dev, -EINVAL,
- "Invalid rsense chann:%d to use in kelvin rsense\n",
+ "Invalid channel %d for kelvin rsense\n",
rtd->r_sense_chan);
if (sensor->chan < min || sensor->chan > max)
return dev_err_ptr_probe(dev, -EINVAL,
- "Invalid chann:%d for the rtd config\n",
+ "Invalid channel %d for RTD config\n",
sensor->chan);
} else {
/* same as differential case */
if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
return dev_err_ptr_probe(dev, -EINVAL,
- "Invalid chann:%d for RTD\n",
+ "Invalid channel %d for RTD\n",
sensor->chan);
}
@@ -925,7 +925,7 @@ ltc2983_thermistor_new(const struct fwnode_handle *child, struct ltc2983_data *s
if (!(thermistor->sensor_config & LTC2983_THERMISTOR_DIFF_MASK) &&
sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
return dev_err_ptr_probe(dev, -EINVAL,
- "Invalid chann:%d for differential thermistor\n",
+ "Invalid channel %d for differential thermistor\n",
sensor->chan);
/* check custom sensor */
@@ -1040,7 +1040,7 @@ ltc2983_diode_new(const struct fwnode_handle *child, const struct ltc2983_data *
if (!(diode->sensor_config & LTC2983_DIODE_DIFF_MASK) &&
sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
return dev_err_ptr_probe(dev, -EINVAL,
- "Invalid chann:%d for differential thermistor\n",
+ "Invalid channel %d for differential diode\n",
sensor->chan);
/* set common parameters */
@@ -1094,7 +1094,7 @@ static struct ltc2983_sensor *ltc2983_r_sense_new(struct fwnode_handle *child,
/* validate channel index */
if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
return dev_err_ptr_probe(dev, -EINVAL,
- "Invalid chann:%d for r_sense\n",
+ "Invalid channel %d for r_sense\n",
sensor->chan);
ret = fwnode_property_read_u32(child, "adi,rsense-val-milli-ohms", &temp);
@@ -1131,7 +1131,7 @@ static struct ltc2983_sensor *ltc2983_adc_new(struct fwnode_handle *child,
if (!adc->single_ended && sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
return dev_err_ptr_probe(dev, -EINVAL,
- "Invalid chan:%d for differential adc\n",
+ "Invalid channel %d for differential ADC\n",
sensor->chan);
/* set common parameters */
@@ -1157,7 +1157,7 @@ static struct ltc2983_sensor *ltc2983_temp_new(struct fwnode_handle *child,
if (!temp->single_ended && sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
return dev_err_ptr_probe(dev, -EINVAL,
- "Invalid chan:%d for differential temp\n",
+ "Invalid channel %d for differential temp\n",
sensor->chan);
temp->custom = __ltc2983_custom_sensor_new(st, child, "adi,custom-temp",
@@ -1182,7 +1182,7 @@ static int ltc2983_chan_read(struct ltc2983_data *st,
start_conversion = LTC2983_STATUS_START(true);
start_conversion |= LTC2983_STATUS_CHAN_SEL(sensor->chan);
- dev_dbg(dev, "Start conversion on chan:%d, status:%02X\n",
+ dev_dbg(dev, "Start conversion on channel:%d, status:%02X\n",
sensor->chan, start_conversion);
/* start conversion */
ret = regmap_write(st->regmap, LTC2983_STATUS_REG, start_conversion);
@@ -1234,7 +1234,7 @@ static int ltc2983_read_raw(struct iio_dev *indio_dev,
/* sanity check */
if (chan->address >= st->num_channels) {
- dev_err(dev, "Invalid chan address:%ld",
+ dev_err(dev, "Invalid channel address: %ld\n",
chan->address);
return -EINVAL;
}
@@ -1332,14 +1332,14 @@ static int ltc2983_parse_fw(struct ltc2983_data *st)
if (sensor.chan < LTC2983_MIN_CHANNELS_NR ||
sensor.chan > st->info->max_channels_nr)
return dev_err_probe(dev, -EINVAL,
- "chan:%d must be from %u to %u\n",
+ "channel:%d must be from %u to %u\n",
sensor.chan,
LTC2983_MIN_CHANNELS_NR,
st->info->max_channels_nr);
if (channel_avail_mask & BIT(sensor.chan))
return dev_err_probe(dev, -EINVAL,
- "chan:%d already in use\n",
+ "channel:%d already in use\n",
sensor.chan);
ret = fwnode_property_read_u32(child, "adi,sensor-type", &sensor.type);
@@ -1347,7 +1347,7 @@ static int ltc2983_parse_fw(struct ltc2983_data *st)
return dev_err_probe(dev, ret,
"adi,sensor-type property must given for child nodes\n");
- dev_dbg(dev, "Create new sensor, type %u, chann %u",
+ dev_dbg(dev, "Create new sensor, type %u, channel %u",
sensor.type, sensor.chan);
if (sensor.type >= LTC2983_SENSOR_THERMOCOUPLE &&
--
2.43.0
^ permalink raw reply related
* [PATCH v3 2/8] iio: temperature: ltc2983: Use local device pointer consistently
From: Liviu Stan @ 2026-05-21 16:42 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, Liviu Stan, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521164323.770626-1-liviu.stan@analog.com>
Some functions define a local 'dev' pointer but still use bare
'&st->spi->dev' in some code paths, and some don't have it at all.
Replace bare references with the local pointer for consistency.
Signed-off-by: Liviu Stan <liviu.stan@analog.com>
---
Changes in v3:
- Dropped the Fixes: tag
- Fixed one remaining dev_dbg() call in __ltc2983_chan_assign_common()
that was still using the raw device pointer instead of the dev local
variable introduced by this patch
drivers/iio/temperature/ltc2983.c | 83 +++++++++++++++++--------------
1 file changed, 47 insertions(+), 36 deletions(-)
diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
index 67a09934c5bd..d9dcf3e86696 100644
--- a/drivers/iio/temperature/ltc2983.c
+++ b/drivers/iio/temperature/ltc2983.c
@@ -351,10 +351,11 @@ static int __ltc2983_chan_assign_common(struct ltc2983_data *st,
const struct ltc2983_sensor *sensor,
u32 chan_val)
{
+ struct device *dev = &st->spi->dev;
u32 reg = LTC2983_CHAN_ASSIGN_ADDR(sensor->chan);
chan_val |= LTC2983_CHAN_TYPE(sensor->type);
- dev_dbg(&st->spi->dev, "Assign reg:0x%04X, val:0x%08X\n", reg,
+ dev_dbg(dev, "Assign reg:0x%04X, val:0x%08X\n", reg,
chan_val);
st->chan_val = cpu_to_be32(chan_val);
return regmap_bulk_write(st->regmap, reg, &st->chan_val,
@@ -656,11 +657,12 @@ static struct ltc2983_sensor *
ltc2983_thermocouple_new(const struct fwnode_handle *child, struct ltc2983_data *st,
const struct ltc2983_sensor *sensor)
{
+ struct device *dev = &st->spi->dev;
struct ltc2983_thermocouple *thermo;
u32 oc_current;
int ret;
- thermo = devm_kzalloc(&st->spi->dev, sizeof(*thermo), GFP_KERNEL);
+ thermo = devm_kzalloc(dev, sizeof(*thermo), GFP_KERNEL);
if (!thermo)
return ERR_PTR(-ENOMEM);
@@ -687,7 +689,7 @@ ltc2983_thermocouple_new(const struct fwnode_handle *child, struct ltc2983_data
LTC2983_THERMOCOUPLE_OC_CURR(3);
break;
default:
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid open circuit current:%u\n",
oc_current);
}
@@ -697,7 +699,7 @@ ltc2983_thermocouple_new(const struct fwnode_handle *child, struct ltc2983_data
/* validate channel index */
if (!(thermo->sensor_config & LTC2983_THERMOCOUPLE_DIFF_MASK) &&
sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid chann:%d for differential thermocouple\n",
sensor->chan);
@@ -712,7 +714,7 @@ ltc2983_thermocouple_new(const struct fwnode_handle *child, struct ltc2983_data
* This would be caught later but we can just return
* the error right away.
*/
- return dev_err_ptr_probe(&st->spi->dev, ret,
+ return dev_err_ptr_probe(dev, ret,
"Property reg must be given\n");
}
@@ -823,7 +825,7 @@ ltc2983_rtd_new(const struct fwnode_handle *child, struct ltc2983_data *st,
} else {
/* same as differential case */
if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid chann:%d for RTD\n",
sensor->chan);
}
@@ -873,7 +875,7 @@ ltc2983_rtd_new(const struct fwnode_handle *child, struct ltc2983_data *st,
rtd->excitation_current = 0x08;
break;
default:
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid value for excitation current(%u)\n",
excitation_current);
}
@@ -922,7 +924,7 @@ ltc2983_thermistor_new(const struct fwnode_handle *child, struct ltc2983_data *s
/* validate channel index */
if (!(thermistor->sensor_config & LTC2983_THERMISTOR_DIFF_MASK) &&
sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid chann:%d for differential thermistor\n",
sensor->chan);
@@ -964,7 +966,7 @@ ltc2983_thermistor_new(const struct fwnode_handle *child, struct ltc2983_data *s
case 0:
/* auto range */
if (sensor->type >= LTC2983_SENSOR_THERMISTOR_STEINHART)
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Auto Range not allowed for custom sensors\n");
thermistor->excitation_current = 0x0c;
@@ -1003,7 +1005,7 @@ ltc2983_thermistor_new(const struct fwnode_handle *child, struct ltc2983_data *s
thermistor->excitation_current = 0x0b;
break;
default:
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid value for excitation current(%u)\n",
excitation_current);
}
@@ -1016,11 +1018,12 @@ static struct ltc2983_sensor *
ltc2983_diode_new(const struct fwnode_handle *child, const struct ltc2983_data *st,
const struct ltc2983_sensor *sensor)
{
+ struct device *dev = &st->spi->dev;
struct ltc2983_diode *diode;
u32 temp = 0, excitation_current = 0;
int ret;
- diode = devm_kzalloc(&st->spi->dev, sizeof(*diode), GFP_KERNEL);
+ diode = devm_kzalloc(dev, sizeof(*diode), GFP_KERNEL);
if (!diode)
return ERR_PTR(-ENOMEM);
@@ -1036,7 +1039,7 @@ ltc2983_diode_new(const struct fwnode_handle *child, const struct ltc2983_data *
/* validate channel index */
if (!(diode->sensor_config & LTC2983_DIODE_DIFF_MASK) &&
sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid chann:%d for differential thermistor\n",
sensor->chan);
@@ -1061,7 +1064,7 @@ ltc2983_diode_new(const struct fwnode_handle *child, const struct ltc2983_data *
diode->excitation_current = 0x03;
break;
default:
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid value for excitation current(%u)\n",
excitation_current);
}
@@ -1079,23 +1082,24 @@ static struct ltc2983_sensor *ltc2983_r_sense_new(struct fwnode_handle *child,
struct ltc2983_data *st,
const struct ltc2983_sensor *sensor)
{
+ struct device *dev = &st->spi->dev;
struct ltc2983_rsense *rsense;
int ret;
u32 temp;
- rsense = devm_kzalloc(&st->spi->dev, sizeof(*rsense), GFP_KERNEL);
+ rsense = devm_kzalloc(dev, sizeof(*rsense), GFP_KERNEL);
if (!rsense)
return ERR_PTR(-ENOMEM);
/* validate channel index */
if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid chann:%d for r_sense\n",
sensor->chan);
ret = fwnode_property_read_u32(child, "adi,rsense-val-milli-ohms", &temp);
if (ret)
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Property adi,rsense-val-milli-ohms missing\n");
/*
* Times 1000 because we have milli-ohms and __convert_to_raw
@@ -1115,9 +1119,10 @@ static struct ltc2983_sensor *ltc2983_adc_new(struct fwnode_handle *child,
struct ltc2983_data *st,
const struct ltc2983_sensor *sensor)
{
+ struct device *dev = &st->spi->dev;
struct ltc2983_adc *adc;
- adc = devm_kzalloc(&st->spi->dev, sizeof(*adc), GFP_KERNEL);
+ adc = devm_kzalloc(dev, sizeof(*adc), GFP_KERNEL);
if (!adc)
return ERR_PTR(-ENOMEM);
@@ -1125,7 +1130,7 @@ static struct ltc2983_sensor *ltc2983_adc_new(struct fwnode_handle *child,
adc->single_ended = true;
if (!adc->single_ended && sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid chan:%d for differential adc\n",
sensor->chan);
@@ -1140,9 +1145,10 @@ static struct ltc2983_sensor *ltc2983_temp_new(struct fwnode_handle *child,
struct ltc2983_data *st,
const struct ltc2983_sensor *sensor)
{
+ struct device *dev = &st->spi->dev;
struct ltc2983_temp *temp;
- temp = devm_kzalloc(&st->spi->dev, sizeof(*temp), GFP_KERNEL);
+ temp = devm_kzalloc(dev, sizeof(*temp), GFP_KERNEL);
if (!temp)
return ERR_PTR(-ENOMEM);
@@ -1150,7 +1156,7 @@ static struct ltc2983_sensor *ltc2983_temp_new(struct fwnode_handle *child,
temp->single_ended = true;
if (!temp->single_ended && sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
- return dev_err_ptr_probe(&st->spi->dev, -EINVAL,
+ return dev_err_ptr_probe(dev, -EINVAL,
"Invalid chan:%d for differential temp\n",
sensor->chan);
@@ -1169,13 +1175,14 @@ static struct ltc2983_sensor *ltc2983_temp_new(struct fwnode_handle *child,
static int ltc2983_chan_read(struct ltc2983_data *st,
const struct ltc2983_sensor *sensor, int *val)
{
+ struct device *dev = &st->spi->dev;
u32 start_conversion = 0;
int ret;
unsigned long time;
start_conversion = LTC2983_STATUS_START(true);
start_conversion |= LTC2983_STATUS_CHAN_SEL(sensor->chan);
- dev_dbg(&st->spi->dev, "Start conversion on chan:%d, status:%02X\n",
+ dev_dbg(dev, "Start conversion on chan:%d, status:%02X\n",
sensor->chan, start_conversion);
/* start conversion */
ret = regmap_write(st->regmap, LTC2983_STATUS_REG, start_conversion);
@@ -1192,7 +1199,7 @@ static int ltc2983_chan_read(struct ltc2983_data *st,
time = wait_for_completion_timeout(&st->completion,
msecs_to_jiffies(300));
if (!time) {
- dev_warn(&st->spi->dev, "Conversion timed out\n");
+ dev_warn(dev, "Conversion timed out\n");
return -ETIMEDOUT;
}
@@ -1205,7 +1212,7 @@ static int ltc2983_chan_read(struct ltc2983_data *st,
*val = __be32_to_cpu(st->temp);
if (!(LTC2983_RES_VALID_MASK & *val)) {
- dev_err(&st->spi->dev, "Invalid conversion detected\n");
+ dev_err(dev, "Invalid conversion detected\n");
return -EIO;
}
@@ -1222,11 +1229,12 @@ static int ltc2983_read_raw(struct iio_dev *indio_dev,
int *val, int *val2, long mask)
{
struct ltc2983_data *st = iio_priv(indio_dev);
+ struct device *dev = &st->spi->dev;
int ret;
/* sanity check */
if (chan->address >= st->num_channels) {
- dev_err(&st->spi->dev, "Invalid chan address:%ld",
+ dev_err(dev, "Invalid chan address:%ld",
chan->address);
return -EINVAL;
}
@@ -1303,7 +1311,7 @@ static int ltc2983_parse_fw(struct ltc2983_data *st)
st->num_channels = device_get_child_node_count(dev);
if (!st->num_channels)
- return dev_err_probe(&st->spi->dev, -EINVAL,
+ return dev_err_probe(dev, -EINVAL,
"At least one channel must be given!\n");
st->sensors = devm_kcalloc(dev, st->num_channels, sizeof(*st->sensors),
@@ -1391,6 +1399,7 @@ static int ltc2983_eeprom_cmd(struct ltc2983_data *st, unsigned int cmd,
unsigned int wait_time, unsigned int status_reg,
unsigned long status_fail_mask)
{
+ struct device *dev = &st->spi->dev;
unsigned long time;
unsigned int val;
int ret;
@@ -1410,7 +1419,7 @@ static int ltc2983_eeprom_cmd(struct ltc2983_data *st, unsigned int cmd,
time = wait_for_completion_timeout(&st->completion,
msecs_to_jiffies(wait_time));
if (!time)
- return dev_err_probe(&st->spi->dev, -ETIMEDOUT,
+ return dev_err_probe(dev, -ETIMEDOUT,
"EEPROM command timed out\n");
ret = regmap_read(st->regmap, status_reg, &val);
@@ -1418,7 +1427,7 @@ static int ltc2983_eeprom_cmd(struct ltc2983_data *st, unsigned int cmd,
return ret;
if (val & status_fail_mask)
- return dev_err_probe(&st->spi->dev, -EINVAL,
+ return dev_err_probe(dev, -EINVAL,
"EEPROM command failed: 0x%02X\n", val);
return 0;
@@ -1427,6 +1436,7 @@ static int ltc2983_eeprom_cmd(struct ltc2983_data *st, unsigned int cmd,
static int ltc2983_setup(struct ltc2983_data *st, bool assign_iio)
{
u32 iio_chan_t = 0, iio_chan_v = 0, chan, iio_idx = 0, status;
+ struct device *dev = &st->spi->dev;
int ret;
/* make sure the device is up: start bit (7) is 0 and done bit (6) is 1 */
@@ -1434,7 +1444,7 @@ static int ltc2983_setup(struct ltc2983_data *st, bool assign_iio)
LTC2983_STATUS_UP(status) == 1, 25000,
25000 * 10);
if (ret)
- return dev_err_probe(&st->spi->dev, ret,
+ return dev_err_probe(dev, ret,
"Device startup timed out\n");
ret = regmap_update_bits(st->regmap, LTC2983_GLOBAL_CONFIG_REG,
@@ -1535,12 +1545,13 @@ static const struct iio_info ltc2983_iio_info = {
static int ltc2983_probe(struct spi_device *spi)
{
+ struct device *dev = &spi->dev;
struct ltc2983_data *st;
struct iio_dev *indio_dev;
struct gpio_desc *gpio;
int ret;
- indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
if (!indio_dev)
return -ENOMEM;
@@ -1552,7 +1563,7 @@ static int ltc2983_probe(struct spi_device *spi)
st->regmap = devm_regmap_init_spi(spi, <c2983_regmap_config);
if (IS_ERR(st->regmap))
- return dev_err_probe(&spi->dev, PTR_ERR(st->regmap),
+ return dev_err_probe(dev, PTR_ERR(st->regmap),
"Failed to initialize regmap\n");
mutex_init(&st->lock);
@@ -1565,11 +1576,11 @@ static int ltc2983_probe(struct spi_device *spi)
if (ret)
return ret;
- ret = devm_regulator_get_enable(&spi->dev, "vdd");
+ ret = devm_regulator_get_enable(dev, "vdd");
if (ret)
return ret;
- gpio = devm_gpiod_get_optional(&st->spi->dev, "reset", GPIOD_OUT_HIGH);
+ gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
@@ -1579,7 +1590,7 @@ static int ltc2983_probe(struct spi_device *spi)
gpiod_set_value_cansleep(gpio, 0);
}
- st->iio_chan = devm_kzalloc(&spi->dev,
+ st->iio_chan = devm_kzalloc(dev,
st->iio_channels * sizeof(*st->iio_chan),
GFP_KERNEL);
if (!st->iio_chan)
@@ -1589,10 +1600,10 @@ static int ltc2983_probe(struct spi_device *spi)
if (ret)
return ret;
- ret = devm_request_irq(&spi->dev, spi->irq, ltc2983_irq_handler,
+ ret = devm_request_irq(dev, spi->irq, ltc2983_irq_handler,
IRQF_TRIGGER_RISING, st->info->name, st);
if (ret)
- return dev_err_probe(&spi->dev, ret,
+ return dev_err_probe(dev, ret,
"failed to request an irq\n");
if (st->info->has_eeprom) {
@@ -1610,7 +1621,7 @@ static int ltc2983_probe(struct spi_device *spi)
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->info = <c2983_iio_info;
- return devm_iio_device_register(&spi->dev, indio_dev);
+ return devm_iio_device_register(dev, indio_dev);
}
static int ltc2983_resume(struct device *dev)
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/8] iio: temperature: ltc2983: Fix macro parenthesization and rename
From: Liviu Stan @ 2026-05-21 16:42 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, Liviu Stan, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521164323.770626-1-liviu.stan@analog.com>
Wrap the 'chan' parameter in LTC2983_CHAN_START_ADDR() and
LTC2983_CHAN_RES_ADDR() with parentheses to prevent potential
macro argument expansion issues. Also rename LTC2983_CHAN_START_ADDR
to LTC2983_CHAN_ASSIGN_ADDR and LTC2983_CHAN_RES_ADDR to
LTC2983_RESULT_ADDR, to better reflect the datasheet names and avoid
them being confused as related.
Signed-off-by: Liviu Stan <liviu.stan@analog.com>
---
Changes in v3:
- Dropped the Fixes: tag
- Removed the "base" parameter from ADT7604_RES_RES_ADDR(); the resistance
result memory region is (currently) ADT7604-specific so the macro's
modification belongs in the driver patch
drivers/iio/temperature/ltc2983.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
index 38e6f8dfd3b8..67a09934c5bd 100644
--- a/drivers/iio/temperature/ltc2983.c
+++ b/drivers/iio/temperature/ltc2983.c
@@ -56,10 +56,10 @@
#define LTC2983_EEPROM_WRITE_TIME_MS 2600
#define LTC2983_EEPROM_READ_TIME_MS 20
-#define LTC2983_CHAN_START_ADDR(chan) \
- (((chan - 1) * 4) + LTC2983_CHAN_ASSIGN_START_REG)
-#define LTC2983_CHAN_RES_ADDR(chan) \
- (((chan - 1) * 4) + LTC2983_TEMP_RES_START_REG)
+#define LTC2983_CHAN_ASSIGN_ADDR(chan) \
+ ((((chan) - 1) * 4) + LTC2983_CHAN_ASSIGN_START_REG)
+#define LTC2983_RESULT_ADDR(chan) \
+ ((((chan) - 1) * 4) + LTC2983_TEMP_RES_START_REG)
#define LTC2983_THERMOCOUPLE_DIFF_MASK BIT(3)
#define LTC2983_THERMOCOUPLE_SGL(x) \
FIELD_PREP(LTC2983_THERMOCOUPLE_DIFF_MASK, x)
@@ -351,7 +351,7 @@ static int __ltc2983_chan_assign_common(struct ltc2983_data *st,
const struct ltc2983_sensor *sensor,
u32 chan_val)
{
- u32 reg = LTC2983_CHAN_START_ADDR(sensor->chan);
+ u32 reg = LTC2983_CHAN_ASSIGN_ADDR(sensor->chan);
chan_val |= LTC2983_CHAN_TYPE(sensor->type);
dev_dbg(&st->spi->dev, "Assign reg:0x%04X, val:0x%08X\n", reg,
@@ -1197,7 +1197,7 @@ static int ltc2983_chan_read(struct ltc2983_data *st,
}
/* read the converted data */
- ret = regmap_bulk_read(st->regmap, LTC2983_CHAN_RES_ADDR(sensor->chan),
+ ret = regmap_bulk_read(st->regmap, LTC2983_RESULT_ADDR(sensor->chan),
&st->temp, sizeof(st->temp));
if (ret)
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH v3 0/8] iio: temperature: ltc2983: Add support for ADT7604
From: Liviu Stan @ 2026-05-21 16:42 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Francesco Lavra, Liviu Stan, linux-iio,
linux-kernel, linux, devicetree
This series adds support for the ADT7604 multi-sensor temperature
measurement and leak detection system to the existing ltc2983 driver.
The ADT7604 shares the same die as the LTC2984, reusing its register
map and SPI interface. It repurposes the custom RTD sensor type (18)
as a copper trace resistance sensor and the custom thermistor type (27)
as a leak detector, removing thermocouple, diode and direct ADC support.
Patches 1-5 fix pre-existing bugs in the ltc2983 driver: macro
parenthesization and renaming, inconsistent use of the local device
pointer, inconsistent channel wording in log messages, missing
fwnode_property_present() guards for optional properties, and an
n_wires default that silently bypassed the current-rotate validation.
Patch 6 adds IIO_COVERAGE, a new channel type for sensors reporting
fractional surface coverage as a percentage.
Patch 7 updates the device tree bindings: adds adi,adt7604 compatible,
copper-trace@ and leak-detector@ sensor node types with their respective
properties, and an ADT7604 example.
Patch 8 updates the driver: introduces two new software sensor type
values (LTC2983_SENSOR_COPPER_TRACE = 32, LTC2983_SENSOR_LEAK_DETECTOR
= 33) with dedicated structs and parser functions rather than extending
the existing RTD and thermistor paths. The hardware configuration bits
are fully hardcoded for both sensor types, and several RTD/thermistor
DT properties have no meaning for them. A u64 supported_sensors bitmask
in ltc2983_chip_info gates sensor type validation per chip, replacing
the has_temp bool pattern. BIT_ULL() is used for the new type values
at bits 32 and 33 to avoid shifting beyond 32 bits on 32-bit builds.
Tested on EVAL-ADT7604-AZ connected to Raspberry Pi 5 via SPI.
Changes in v3:
Patch 1 - macro parenthesization and rename:
- Dropped the Fixes: tag
- Removed the "base" parameter from ADT7604_RES_RES_ADDR(); the resistance
result memory region is (currently) ADT7604-specific so the macro's
modification belongs in the driver patch
Patch 2 - use local device pointer consistently:
- Dropped the Fixes: tag
- Fixed one remaining dev_dbg() call in __ltc2983_chan_assign_common()
that was still using the raw device pointer instead of the dev local
variable introduced by this patch
Patch 3 - fix inconsistent channel wording in messages:
- Dropped both Fixes: tags
- Removed the "all" from "all occurrences" in the commit message
- Fixed some missed "chan" / "chann" occurrences
Patch 4 - use fwnode_property_present() for optional properties:
- Dropped the Fixes: tag
- Fixed other occurrences brought up by sashiko
Patch 5 - Fix n_wires default bypassing rotation check:
- New patch
Patch 6 - IIO_COVERAGE channel type:
- Renamed the sysfs attribute from in_coveragepercentX_raw to
in_coverageX_raw
- Added a _scale ABI documentation entry
- Corrected KernelVersion in the ABI documentation from 6.15 to 7.2
- Added IIO_COVERAGE to the event_is_known() switch in
tools/iio/iio_event_monitor.c
Patch 7 - DT bindings:
- Changed the custom leak detector table encoding, users now specify
plain coverage percentage values (0-100) in the device tree and the
driver applies the +273.15 C offset internally before writing the
hardware table
- Changed custom-rtd to custom-copper-trace to better represent the
copper trace custom table, and made it required for > 1 ohm variants
- Made custom-leak-detector required for leak detector sensors
- Updated commit message to reflect the changes
- Updated leak detector node description
- Updated adi,custom-leak-detector description
- Modified the example leak detector custom table to match the datasheet
Patch 8 - driver:
- Relocated the "base" parameter addition from patch 1 to this one since
the resistance result memory region is (currently) ADT7604-specific
- Updated the commit message to mention the base and base_reg parameters
added to the result-bank read helpers
- Stacked the IIO_RESISTANCE and IIO_COVERAGE case labels in
ltc2983_read_raw()
- Added LTC2983_SENSOR_NUM sentinel at the end of the sensor-type enum
- Changed the sensor-type bounds check from > LTC2983_SENSOR_LEAK_DETECTOR
to >= LTC2983_SENSOR_NUM
- Reordered the ltm2985_chip_info_data struct initializer so has_eeprom
doesn't look like it was added to the ltm2985 in the diff
- Changed the custom leak detector table encoding, users now specify
plain coverage percentage values (0-100) in the device tree and the
driver applies the +273.15 C offset internally before writing the
hardware table
- Changed custom-rtd to custom-copper-trace to better represent the
copper trace custom table, and made it required for > 1 ohm variants
- Made custom-leak-detector required for leak detector sensors, _new
and _assign_chan functions were updated for both sensor types
- Updated commit message to reflect the changes
- Removed "..." from "rsense channel must be configured" error message
from ltc2983_leak_detector_new()
- Removed blank line before hw_type declaration in
__ltc2983_chan_assign_common
Liviu Stan (8):
iio: temperature: ltc2983: Fix macro parenthesization and rename
iio: temperature: ltc2983: Use local device pointer consistently
iio: temperature: ltc2983: Fix inconsistent channel wording in
messages
iio: temperature: ltc2983: Use fwnode_property_present() for optional
properties
iio: temperature: ltc2983: Fix n_wires default bypassing rotation
check
iio: core: Add IIO_COVERAGE channel type
dt-bindings: iio: temperature: Add ADT7604 support to adi,ltc2983
iio: temperature: ltc2983: Add support for ADT7604
Documentation/ABI/testing/sysfs-bus-iio | 17 +
.../bindings/iio/temperature/adi,ltc2983.yaml | 207 +++++-
drivers/iio/industrialio-core.c | 1 +
drivers/iio/temperature/ltc2983.c | 614 +++++++++++++++---
include/uapi/linux/iio/types.h | 1 +
tools/iio/iio_event_monitor.c | 2 +
6 files changed, 741 insertions(+), 101 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH V8 02/10] dt-bindings: iio: imu: icm42600: Add icm42607 binding
From: Conor Dooley @ 2026-05-21 16:44 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko, Chris Morgan,
Krzysztof Kozlowski
In-Reply-To: <20260520174217.6ca98524@jic23-huawei>
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]
On Wed, May 20, 2026 at 05:42:17PM +0100, Jonathan Cameron wrote:
> On Mon, 18 May 2026 15:05:17 -0500
> Chris Morgan <macroalpha82@gmail.com> wrote:
>
> > From: Chris Morgan <macromorgan@hotmail.com>
> >
> > Add devicetree binding for the Invensense ICM42607 and Invensense
> > ICM42607P inertial measurement unit. This unit is a combined
> > accelerometer, gyroscope, and thermometer available via I2C or SPI.
> >
> > This device is functionally very similar to the icm42600 series with a
> > very different register layout.
> >
> > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Note that Sashiko has highlighted that the binding this being added to
> has a potential problem.
>
> interrupts are required but interrupt-names are not.
> That would be fine but the binding doesn't say there is a default
> ordering for the interrupts - so if we don't have names we have no
> idea which interrupt it is.
>
> This needs fixing - probably by adding a default
Worth pointing out that this isn't an issue with this particular patch,
the problem exists in mainline.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/2] bindings: iio: adc: Add StarFive JHB100 SARADC
From: Conor Dooley @ 2026-05-21 16:41 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Xingyu Wu, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org
In-Reply-To: <20260521123949.20e3c0a8@jic23-huawei>
[-- Attachment #1: Type: text/plain, Size: 6521 bytes --]
On Thu, May 21, 2026 at 12:39:49PM +0100, Jonathan Cameron wrote:
> On Thu, 21 May 2026 11:20:52 +0100
> Conor Dooley <conor@kernel.org> wrote:
>
> > On Thu, May 21, 2026 at 09:54:27AM +0000, Xingyu Wu wrote:
> > > On 2026/5/20 23:15, Conor Dooley wrote:
> > > >
> > > > On Wed, May 20, 2026 at 09:43:02AM +0000, Xingyu Wu wrote:
> > > > > On 2026/5/19 18:00, Conor Dooley wrote:
> > > > > >
> > > > > > On Tue, May 19, 2026 at 09:26:03AM +0000, Xingyu Wu wrote:
> > > > > > > On 2026/5/19 00:24, Conor Dooley wrote:
> > > > > > > >
> > > > > > > > On Mon, May 18, 2026 at 04:18:51PM +0800, Xingyu Wu wrote:
> > > > > > > > > Add the new documentation of SAR-ADC for the StarFive JHB100 SoC.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
> > > > > > > > > ---
> > > > > > > > > .../iio/adc/starfive,jhb100-saradc.yaml | 62 +++++++++++++++++++
> > > > > > > > > 1 file changed, 62 insertions(+) create mode 100644
> > > > > > > > > Documentation/devicetree/bindings/iio/adc/starfive,jhb100-sara
> > > > > > > > > dc.y
> > > > > > > > > aml
> > > > > > > > >
> > > > > > > > > diff --git
> > > > > > > > > a/Documentation/devicetree/bindings/iio/adc/starfive,jhb100-sa
> > > > > > > > > radc
> > > > > > > > > .yam
> > > > > > > > > l
> > > > > > > > > b/Documentation/devicetree/bindings/iio/adc/starfive,jhb100-sa
> > > > > > > > > radc
> > > > > > > > > .yam
> > > > > > > > > l
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000000000000..ba8e19b72ad7
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/Documentation/devicetree/bindings/iio/adc/starfive,jhb10
> > > > > > > > > +++ 0-sa
> > > > > > > > > +++ radc
> > > > > > > > > +++ .yaml
> > > > > > > > > @@ -0,0 +1,62 @@
> > > > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML
> > > > > > > > > +1.2
> > > > > > > > > +---
> > > > > > > > > +$id:
> > > > > > > > > +http://devicetree.org/schemas/iio/adc/starfive,jhb100-saradc.
> > > > > > > > > +yaml
> > > > > > > > > +#
> > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > > > +
> > > > > > > > > +title: Successive Approximation Register (SAR) A/D converter
> > > > > > > > > +for the StarFive JHB100 SoC
> > > > > > > > > +
> > > > > > > > > +maintainers:
> > > > > > > > > + - Xingyu Wu <xingyu.wu@starfivetech.com>
> > > > > > > > > +
> > > > > > > > > +properties:
> > > > > > > > > + compatible:
> > > > > > > > > + const: starfive,jhb100-saradc
> > > > > > > > > +
> > > > > > > > > + reg:
> > > > > > > > > + maxItem: 1
> > > > > > > > > +
> > > > > > > > > + interrupts:
> > > > > > > > > + maxItems: 1
> > > > > > > > > +
> > > > > > > > > + clocks:
> > > > > > > > > + maxItems: 1
> > > > > > > > > +
> > > > > > > > > + resets:
> > > > > > > > > + maxItems: 2
> > > > > > > > > +
> > > > > > > > > + "#io-channel-cells":
> > > > > > > > > + const: 1
> > > > > > > > > +
> > > > > > > > > + upper-bound-mv:
> > > > > > > > > + description: The upper bound voltage value of the monitor.
> > > > > > > > > + $ref: /schemas/types.yaml#/definitions/uint16
> > > > > > > > > +
> > > > > > > > > + lower-bound-mv:
> > > > > > > > > + description: The lower bound voltage value of the monitor.
> > > > > > > > > + $ref: /schemas/types.yaml#/definitions/uint16
> > > > > > > > > +
> > > > > > > > > + scan-freq:
> > > > > > > > > + description: Number of the scan cycle interval.
> > > > > > > > > + $ref: /schemas/types.yaml#/definitions/uint16
> > > > > > > >
> > > > > > > > Can you explain why any of these three properties are something
> > > > > > > > that should be in the devicetree rather than software controlled?
> > > > > > >
> > > > > > > My intention is to be able to obtain the initial values from the
> > > > > > > devicetree during
> > > > > > probe and preset them.
> > > > > > > Do I need to drop them and just set them through sysfs?
> > > > > >
> > > > > > Unless the hardware configuration determines the values (which I
> > > > > > can't really see being the case for scan-freq at least) then yes,
> > > > > > you need to drop and set them via sysfs.
> > > > >
> > > > > The ADC hardware can be set the scan-freq register to determine how frequent it
> > > > should scan its inputs.
> > > > > The calculation is:
> > > > > frequency = 100/((register value) + 5) MHz, The register value should >= 15.
> > > > > The maximum allowable scan frequency is 5MHz.
> > > > >
> > > > > >
> > > > > > > > How are the bounds calculated?
> > > > > > >
> > > > > > > The measurement range of this ADC hardware is from 0 to 1800 mV.
> > > > > > > This set
> > > > > > value cannot exceed it. This explanation will be added later.
> > > > > >
> > > > > > I'm asking how this is calculated so that I can tell if you the
> > > > > > property is permitted or not.
> > > > >
> > > > > The calculation of bound is:
> > > > > bound-mv = 1800mv * (register value) / 0xFFF
> > > >
> > > > These are the formulas, but how does someone know what the value for bound-
> > > > mv needs to be? Why would someone not just want to always use 1800mv?
> > > >
> > >
> > > Can I add the 'maximum' and ' minimum' to provide clarification? And the driver will also check.
> >
> > All that does is repeat the 1800 mV though, what I am interested in is
> > how someone determines if they should use 1600 mV or 200 mV etc. What
> > aspect of the hardware do the bounds depend on?
>
> There are two options here
> 1. This is critical stuff to avoid hardware damage. (If you are relying on
> Linux for that you built your system wrong but if we ignore that...)
> Then userspace control should not be possible - or at least should
> only be able to move boundaries in directions that make them tighter.
> 2. It is advisory only and not related to hardware damage - in that case
> generally doesn't belong in DT.
Per Xingyu's latest response
| These bounds are just for the monitor mode. If the input voltage is outside this range, interrupt will be triggered to report the user space.
| The bounds value (1600mv or 200mv) are determined by the users' applications. Users can freely set them according to the range they want to monitor.
it controls the level at which interrupts occur, and is therefore not
suitable for DT.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: fsl-edma: add optional iommus property
From: Frank Li @ 2026-05-21 16:41 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, imx, dmaengine, devicetree, linux-kernel, Peng Fan
In-Reply-To: <20260521-edma-iommu-v1-1-6eec3f24c306@nxp.com>
On Thu, May 21, 2026 at 12:05:04PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> Add iommus property with each channel could use one IOMMU entry. i.MX95
> supports max 64 channels, so set [minItems,maxItems] to [1,64].
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Documentation/devicetree/bindings/dma/fsl,edma.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
> index fa4248e2f1b9cecd00f1535744bfe6d9ecdba613..bb8de804da53fdc47703f722f18453853742209d 100644
> --- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml
> +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
> @@ -54,6 +54,11 @@ properties:
> minItems: 1
> maxItems: 65
>
> + iommus:
> + minItems: 1
> + maxItems: 64
> + description: Up to 1 IOMMU entry per DMA channel.
> +
If difference channel use difference's iommus, should it use iommu-map?
iommus here suppose all channel share 1 IOMMU entry.
Frank
> "#dma-cells":
> description: |
> Specifies the number of cells needed to encode an DMA channel.
>
> ---
> base-commit: 687da68900cd1a46549f7d9430c7d40346cb86a0
> change-id: 20260521-edma-iommu-c025e1d28eba
>
> Best regards,
> --
> Peng Fan <peng.fan@nxp.com>
>
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: freescale: add Aquila iMX95 support
From: Frank Li @ 2026-05-21 16:38 UTC (permalink / raw)
To: Franz Schnyder; +Cc: sashiko-reviews, robh, Frank.Li, imx, conor+dt, devicetree
In-Reply-To: <3pcmepn2kr2b2gku33mriosmnim4xd7e75pt2j7i7vnt4awhgg@3cptbxl5u4x5>
On Thu, May 21, 2026 at 12:18:41PM +0200, Franz Schnyder wrote:
> > > diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts b/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts
> > > new file mode 100644
> > > index 0000000000000..bb4a3631af9ba
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts
> >
> > [ ... ]
> >
> > > +/* Aquila I2S_1 */
> > > +&sai2 {
> > > + status = "okay";
> > > +};
> > > +
> > > +&som_dsi2dp_bridge {
> > > + status = "okay";
> > > +};
> >
> > [Severity: Medium]
> > Will this bridge fail to probe since the DSI input connection is missing?
> >
> > Looking at the ti-sn65dsi86 driver in ti_sn_bridge_parse_dsi_host(), it uses
> > of_graph_get_remote_node(np, 0, 0) and unconditionally returns -ENODEV if the
> > remote node is missing.
> >
> > Since the upstream i.MX95 SoC DSI controller doesn't appear to be implemented
> > and linked to the dsi2dp_in endpoint yet, should this node remain disabled
> > until the controller is available?
> > --
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260521-add-aquila-imx95-v3-0-621843807def@toradex.com?part=2
>
> Hi Frank,
>
> This is valid point from the bot.
> If there is nothing else, I'll send a v4 that removes '&som_dsi2dp_bridge'
> from the Dev and Clover board, since the node is disabled in the SoM dtsi.
You can post v4 anyway to let sashika check again. It is always quicker then
my manual check.
Frank
>
> Thanks,
>
> Franz
>
>
^ permalink raw reply
* Re: [PATCH v4 5/5] drm/panel: Add driver for Synaptics R63455 DSI panel
From: sashiko-bot @ 2026-05-21 16:30 UTC (permalink / raw)
To: Jun Nie; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260521-sm8650-7-1-bonded-dsi-v4-5-a4dd5e0850f1@linaro.org>
Thank you for your contribution! Sashiko AI review found 10 potential issue(s) to consider:
- [High] Incorrect order of error unwinding labels in `r63455_prepare` causes resource leaks and unbalanced regulator operations.
- [High] The secondary DSI device registered during probe is never unregistered, causing a memory and device leak.
- [High] Endianness extraction macros misuse host-endian functions, resulting in reversed byte order on Big Endian architectures.
- [High] Unconditional access to `ctx->reset_gpios->desc[1]` leads to an out-of-bounds array read if only one reset GPIO is provided.
- [High] Failure of `drm_dsc_setup_rc_params` is logged but ignored, leading to division by zero and uninitialized data usage.
- [High] Backlight updates send DSI commands after the panel has entered sleep mode, risking hardware timeouts.
- [High] Premature publication of backlight and panel interfaces leads to use-before-initialization races.
- [High] Unprotected concurrent read-modify-write on `mode_flags` causes data races.
- [High] Unaligned pointer cast causes unaligned memory access when packing DSC PPS payload.
- [Low] Missing Kconfig dependencies for DRM DSC helpers causes build failures.
--
commit b5b6e09241eeff17cb03a31aac27b70f4e5ca911
Author: Jun Nie <jun.nie@linaro.org>
Subject: drm/panel: Add driver for Synaptics R63455 DSI panel
This commit adds support for the DSI panels used in the virtual reality
device. The device features two physical panels, each providing a MIPI DSI
interface and a built-in LED backlight, and exposes a single logical panel
to the DRM framework.
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
[ ... ]
> @@ -1185,6 +1185,15 @@ config DRM_PANEL_SYNAPTICS_TDDI
> namesake, with varying resolutions and data lanes. They also have a
> built-in LED backlight and a touch controller.
>
> +config DRM_PANEL_SYNAPTICS_R63455
> + tristate "Synaptics R63455-based panels"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y if you want to enable support for panels based on the
> + Synaptics R63455 controller.
[Severity: Low]
Does this need to select DRM_DISPLAY_DSC_HELPER or DRM_DISPLAY_HELPER?
The driver calls drm_dsc_set_const_params and other DSC helpers, which
might cause link-time failures if the helper infrastructure is not built.
[ ... ]
> diff --git a/drivers/gpu/drm/panel/panel-synaptics-r63455.c b/drivers/gpu/drm/panel/panel-synaptics-r63455.c
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-synaptics-r63455.c
[ ... ]
> +#define r63455_dsi_write_buffer(ctx, dsi_ctx, d) \
> + do { \
> + dsi_ctx.dsi = ctx->dsi[0]; \
> + mipi_dsi_dcs_write_buffer_multi(&dsi_ctx, d, ARRAY_SIZE(d)); \
> + dsi_ctx.dsi = ctx->dsi[1]; \
> + mipi_dsi_dcs_write_buffer_multi(&dsi_ctx, d, ARRAY_SIZE(d)); \
> + } while (0)
> +
> +#define LE16_BYTE0(val) (le16_to_cpu(val) & 0xff)
> +#define LE16_BYTE1(val) ((le16_to_cpu(val) >> 8) & 0xff)
[Severity: High]
Are these macros extracting the correct bytes on big endian architectures?
Using le16_to_cpu() on a native integer constant swaps the bytes on big
endian systems. Applying the bitwise operations afterward will extract the
most significant byte instead of the least significant byte. Would standard
bitwise shifts be safer here?
[ ... ]
> +static int r63455_dsi_populate_dsc_params(struct r63455_ctx *ctx)
> +{
> + int ret;
> + struct drm_dsc_config *dsc = &ctx->dsc_cfg;
[ ... ]
> + /* handle only bpp = bpc = 8, pre-SCR panels */
> + ret = drm_dsc_setup_rc_params(dsc, DRM_DSC_1_1_PRE_SCR);
> + if (ret < 0)
> + DRM_DEV_ERROR(ctx->dev, "failed to setup dsc params\n");
> +
> + dsc->initial_scale_value = drm_dsc_initial_scale_value(dsc);
[Severity: High]
Should this return early if drm_dsc_setup_rc_params() fails? If execution
continues, the driver will use uninitialized DSC configuration parameters.
Because values like initial_xmit_delay might remain zero, it can result in
a division by zero when calculating final_scale inside
drm_dsc_compute_rc_parameters().
> + dsc->line_buf_depth = dsc->bits_per_component + 1;
> +
> + return drm_dsc_compute_rc_parameters(dsc);
> +}
[ ... ]
> +static int r63455_panel_on_sharp_ls026b3sa06(struct drm_panel *panel)
> +{
> + struct r63455_ctx *ctx = panel_to_ctx(panel);
> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
> +
> + u8 pps_cmd[1 + sizeof(struct drm_dsc_picture_parameter_set)];
> +
> + drm_dsc_pps_payload_pack((void *)&pps_cmd[1], &ctx->dsc_cfg);
[Severity: High]
Can this unaligned pointer cause alignment faults? Passing &pps_cmd[1] forces
the base address to be odd. Since drm_dsc_pps_payload_pack() treats the
pointer as a struct and performs 16-bit stores to its fields, this might
trigger alignment panics on architectures that strictly enforce memory
alignment.
[ ... ]
> +static int r63455_set_brightness(struct r63455_ctx *ctx, u16 brightness,
> + u16 pulse_offset_rows)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
> + u16 gpo1_tew1;
> +
> + gpo1_tew1 = brightness > BRIGHTNESS_MAX_120 ?
> + BRIGHTNESS_MAX_120 : brightness;
> +
> + ctx->dsi[0]->mode_flags &= ~MIPI_DSI_MODE_LPM;
[Severity: High]
Can this read-modify-write of mode_flags race with the similar modifications
in r63455_enable() and r63455_disable()? Because set_brightness() is called
from sysfs context and enable/disable from DRM commit context, concurrent
access might corrupt mode_flags and drop critical settings like
MIPI_DSI_MODE_VIDEO.
> + ctx->dsi[1]->mode_flags &= ~MIPI_DSI_MODE_LPM;
[ ... ]
> +static int r63455_disable(struct drm_panel *panel)
> +{
> + struct r63455_ctx *ctx = panel_to_ctx(panel);
> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
> +
> + ctx->dsi[0]->mode_flags &= ~MIPI_DSI_MODE_LPM;
> + ctx->dsi[1]->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + r63455_dsi_write_seq(ctx, dsi_ctx, MIPI_DCS_SET_DISPLAY_OFF);
> + r63455_dsi_write_seq(ctx, dsi_ctx, MIPI_DCS_SET_TEAR_OFF);
> + r63455_dsi_write_seq(ctx, dsi_ctx, MIPI_DCS_ENTER_SLEEP_MODE);
> +
> + mipi_dsi_msleep(&dsi_ctx, 200);
> +
> + if (dsi_ctx.accum_err)
> + return dsi_ctx.accum_err;
> +
> + return backlight_disable(ctx->backlight);
[Severity: High]
Is it safe to disable the backlight here? The backlight_disable() function
calls r63455_set_brightness(), which will send DSI configuration commands to
the panel. Doing so after sending MIPI_DCS_ENTER_SLEEP_MODE violates the DSI
hardware contracts and might cause bus timeouts or hardware crashes.
> +}
> +
> +static int r63455_unprepare(struct drm_panel *panel)
> +{
> + struct r63455_ctx *ctx = panel_to_ctx(panel);
> + int ret;
> +
> + gpiod_set_value(ctx->reset_gpios->desc[0], 0);
> + gpiod_set_value(ctx->reset_gpios->desc[1], 0);
[Severity: High]
What happens if the device tree only provides a single reset GPIO? If ndescs
is 1, accessing desc[1] will read past the end of the flexible array,
resulting in a garbage pointer dereference.
[ ... ]
> +static int r63455_prepare(struct drm_panel *panel)
> +{
> + struct r63455_ctx *ctx = panel_to_ctx(panel);
> + int ret;
[ ... ]
> + msleep(20);
> + gpiod_set_value(ctx->reset_gpios->desc[0], 1);
> + gpiod_set_value(ctx->reset_gpios->desc[1], 1);
> +
> + return 0;
> +
> +bl_off:
> + regulator_bulk_disable(ARRAY_SIZE(ctx->reg_bl), ctx->reg_bl);
> +vdda_off:
> + regulator_bulk_disable(ARRAY_SIZE(ctx->reg_vdda), ctx->reg_vdda);
> +bias_off:
> + regulator_bulk_disable(ARRAY_SIZE(ctx->reg_lcd_bias_pos),
> + ctx->reg_lcd_bias_pos);
> + return ret;
[Severity: High]
Are these error labels in the correct order? They appear to fall through
sequentially rather than unwinding in reverse. If reg_vdda fails to enable,
the jump to bl_off will disable the backlight, but then incorrectly fall
through to vdda_off and bias_off. This causes regulators that were never
enabled to be disabled, and completely skips disabling regulators that were
actually enabled.
> +}
[ ... ]
> +static int r63455_probe(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = &dsi->dev;
> + struct r63455_ctx *ctx;
> + struct mipi_dsi_device *dsi1_device;
[ ... ]
> + dsi1_host = of_find_mipi_dsi_host_by_node(dsi1);
> + of_node_put(dsi1);
> + if (!dsi1_host) {
> + DRM_DEV_ERROR(dev, "failed to find secondary dsi host\n");
> + return -EPROBE_DEFER;
> + }
> +
> + dsi1_device = mipi_dsi_device_register_full(dsi1_host, &info);
[Severity: High]
Does this dynamically allocated dsi1_device need to be unregistered? There
is no call to mipi_dsi_device_unregister() in the error paths below or in a
remove callback for the driver, which could cause a permanent device and
memory leak when the module is unloaded or fails to probe.
> + if (IS_ERR(dsi1_device)) {
> + DRM_DEV_ERROR(dev, "failed to create dsi device\n");
> + return PTR_ERR(dsi1_device);
> + }
[ ... ]
> + ret = r63455_panel_add(ctx);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "failed to add panel %d\n", ret);
> + return ret;
> + }
> +
> + for (i = 0; i < 2; i++) {
> + dsi_dev = ctx->dsi[i];
> + dsi_dev->lanes = 3;
> + dsi_dev->format = MIPI_DSI_FMT_RGB888;
> + dsi_dev->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_LPM |
> + MIPI_DSI_CLOCK_NON_CONTINUOUS;
> + ret = devm_mipi_dsi_attach(dev, dsi_dev);
[Severity: High]
Does calling r63455_panel_add() before devm_mipi_dsi_attach() expose the
backlight sysfs interface too early? If userspace writes to the brightness
node before the DSI lanes and formats are configured and attached, it could
trigger a DSI transfer on an unattached device and crash the system.
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "dsi attach failed i = %d\n", i);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260521-sm8650-7-1-bonded-dsi-v4-0-a4dd5e0850f1@linaro.org?part=5
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Lee Jones @ 2026-05-21 16:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Shivendra Pratap, Sebastian Reichel, Mark Rutland,
Lorenzo Pieralisi, Rafael J. Wysocki, Daniel Lezcano,
Christian Loehle, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Arnd Bergmann,
Souvik Chakravarty, Andy Yan, Matthias Brugger, John Stultz,
Moritz Fischer, Sudeep Holla, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-kernel, devicetree, Florian Fainelli,
Krzysztof Kozlowski, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Greg Kroah-Hartman, Kathiravan Thirumoorthy, Srinivas Kandagatla,
Bartosz Golaszewski
In-Reply-To: <CAMRc=Me5QS4xA3PJWXNuRP1N_C+w3sP9ZvqH36GNh2Ebc9hwcw@mail.gmail.com>
On Thu, 21 May 2026, Bartosz Golaszewski wrote:
> On Thu, May 21, 2026 at 3:24 PM Lee Jones <lee@kernel.org> wrote:
> >
> > >
> > > I suggested it because of its flexibility. The alternative I had in
> > > mind is something like a new field in mfd_cell:
> > >
> > > const char *cell_node_name;
> > >
> > > Which - if set - would tell MFD to look up an fwnode that's a child of
> > > the parent device's node by name - as it may not have a compatible.
> >
> > Remind me why the chlid device can't look-up its own fwnode?
> >
>
> Oh sure it can, but should it? I'm not sure it's logically sound to
> have the child device reach into the parent, look up the fwnode and
> then assign it to itself after it's already attached to the driver.
> This should be done at the subsystem level before the device is
> registered.
Leaf drivers reach back into the parent all the time.
--
Lee Jones
^ permalink raw reply
* Re: (subset) [PATCH 0/4] power: sys-off: fix Pixel C shutdown via MAX77620
From: Lee Jones @ 2026-05-21 16:24 UTC (permalink / raw)
To: Diogo Ivo
Cc: Mark Rutland, Lorenzo Pieralisi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, linux-arm-kernel,
linux-kernel, devicetree, linux-tegra
In-Reply-To: <f98bcd81-29c6-4df2-8040-d17686b28f45@tecnico.ulisboa.pt>
On Thu, 21 May 2026, Diogo Ivo wrote:
>
>
> On 5/21/26 12:41, Lee Jones wrote:
> > On Thu, 21 May 2026, Diogo Ivo wrote:
> >
> > > Hi Lee,
> > >
> > > On 5/20/26 18:25, Lee Jones wrote:
> > > > On Thu, 14 May 2026 16:47:18 +0200, Diogo Ivo wrote:
> > > > > This series migrates PSCI and MAX77620 poweroff handling to the
> > > > > sys-off framework and fixes shutdown on the Pixel C (Smaug).
> > > > >
> > > > > The first two patches replace legacy pm_power_off usage in the PSCI
> > > > > and MAX77620 drivers with sys-off handlers. Besides aligning both
> > > > > drivers with the modern poweroff infrastructure, this removes the
> > > > > global callback dependency and allows multiple handlers to coexist
> > > > > with explicit priorities.
> > > > >
> > > > > [...]
> > > >
> > > > Applied, thanks!
> > >
> > > Thanks for applying the patches! Just a question and an observation:
> > >
> > > - I'm assuming you were ok with merging [2/4] despite the possible
> > > deadlock since this risk is already present in mainline in the same
> > > form so we're not actually making things worse, is that so?
> >
> > Did you see the text below?
>
> Yes, but patch 3 is not addressing the possible deadlock hence my
> question.
>
> > Both patches 2 and 3 are applied.
> >
> > > - The observation is that the comment about overriding PSCI is only
> > > true after (and if) a reworked [1/4] is actually merged.
> > > If it isn't then patch [3/4] is actually working around another handler
> > > in soc/tegra/pmc.c where a handler that only does work for the Nexus
> > > 7 is actually registered at FIRMWARE level for all platforms that
> > > probe that driver (I will send out a patch shortly to only register
> > > the handler on the Nexus 7).
> >
> > I assume the other patches will be applied soon.
> >
> > If this causes some kind of issue - let me know later on in the cycle
> > and I'll remove whatever patches you ask me to.
>
> The PSCI patch [1/4] has a fundamental issue and needs a respin to be
> applied.
>
> In connection with this it might then become easier to quirk the PSCI
> driver rather than the PMIC driver, so for the moment I'll ask you to
> drop [3/4] until I propose the changes to the PSCI maintainers and see
> the feedback and at that point we can either completely drop [3/4] or
> reapply it; sorry for the noise.
Done.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v2 14/15] dt-bindings: display/lvds-codec: add ti,sn65lvds93
From: Hugo Villeneuve @ 2026-05-21 16:23 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: krzk, robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
rfoss, Laurent.pinchart, jonas, jernej.skrabec, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, Frank.Li, s.hauer, kernel,
festevam, shawnguo, laurent.pinchart+renesas, antonin.godard,
devicetree, linux-kernel, dri-devel, imx, linux-arm-kernel,
Hugo Villeneuve, Krzysztof Kozlowski
In-Reply-To: <20260511114406.24673c770d112b2ca4aba2eb@hugovil.com>
On Mon, 11 May 2026 11:44:06 -0400
Hugo Villeneuve <hugo@hugovil.com> wrote:
> Hi,
>
> On Thu, 5 Mar 2026 13:06:29 -0500
> Hugo Villeneuve <hugo@hugovil.com> wrote:
>
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Add compatible string for TI SN65LVDS93. Similar to
> > SN65LVDS83 but with an industrial temperature range.
> >
> > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Now that this series landed in linux-next/master, except for this
> patch, we now have an error since it is required:
>
> https://lore.kernel.org/oe-kbuild-all/202605071909.lXKPelNA-lkp@intel.com/
Hi DT folks,
wondering if someone could pick/apply this patch to fix the build error?
Hugo.
> > ---
> > Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > index 4f52e35d02537..f2cb74b86cc05 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > @@ -37,6 +37,7 @@ properties:
> > - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
> > - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
> > - ti,sn75lvds83 # For the TI SN75LVDS83 FlatLink transmitter
> > + - ti,sn75lvds93 # For the TI SN75LVDS93 FlatLink transmitter
> > - const: lvds-encoder # Generic LVDS encoder compatible fallback
> > - items:
> > - enum:
> > --
> > 2.47.3
> >
> >
>
>
> Hugo Villeneuve <hugo@hugovil.com>
--
Hugo Villeneuve
^ permalink raw reply
* [PATCH v2] dt-bindings: serial: rs485: remove deprecated .txt binding stub
From: Akash Sukhavasi @ 2026-05-21 16:21 UTC (permalink / raw)
To: krzk+dt
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-kernel, linux-serial,
devicetree, linux-doc
The plain text binding file was superseded by the YAML schema in
commit d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings
to json-schema"). The file now contains only a redirect notice.
Remove it, and update references in serial_core.c and
serial-rs485.rst to point to the YAML schema.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Changes in v2:
- Update references in serial_core.c and serial-rs485.rst to point
to rs485.yaml (Sashiko review).
v1: https://lore.kernel.org/all/20260521150748.4816-1-akash.sukhavasi@gmail.com/
Documentation/devicetree/bindings/serial/rs485.txt | 1 -
Documentation/driver-api/serial/serial-rs485.rst | 2 +-
drivers/tty/serial/serial_core.c | 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/rs485.txt
diff --git a/Documentation/devicetree/bindings/serial/rs485.txt b/Documentation/devicetree/bindings/serial/rs485.txt
deleted file mode 100644
index a7fe93efc..000000000
--- a/Documentation/devicetree/bindings/serial/rs485.txt
+++ /dev/null
@@ -1 +0,0 @@
-See rs485.yaml
diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst
index dce061ef7..f53043d21 100644
--- a/Documentation/driver-api/serial/serial-rs485.rst
+++ b/Documentation/driver-api/serial/serial-rs485.rst
@@ -132,4 +132,4 @@ RS485 Serial Communications
6. References
=============
-.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.txt
+.. [#DT-bindings] Documentation/devicetree/bindings/serial/rs485.yaml
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 89cebdd27..df4589880 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3496,7 +3496,7 @@ EXPORT_SYMBOL_GPL(uart_try_toggle_sysrq);
* @port: uart device's target port
*
* This function implements the device tree binding described in
- * Documentation/devicetree/bindings/serial/rs485.txt.
+ * Documentation/devicetree/bindings/serial/rs485.yaml.
*/
int uart_get_rs485_mode(struct uart_port *port)
{
--
2.54.0
^ permalink raw reply related
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