* Re: [PATCH RFC 4/9] net: stmmac: qcom-ethqos: add per-platform NOC clock voting
From: Mohd Ayaan Anwar @ 2026-06-16 16:17 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <45d7faac-7c0f-4f89-808e-06129e8420e4@oss.qualcomm.com>
Hi Konrad,
On Mon, Jun 15, 2026 at 02:13:05PM +0200, Konrad Dybcio wrote:
> On 6/11/26 8:37 PM, Mohd Ayaan Anwar wrote:
> > Some SoCs gate the EMAC's path to the System NOC behind dedicated clocks
> > that must be enabled before the DMA can reach memory. Add
> > ethqos_noc_clk_cfg and the corresponding fields in the driver-data and
> > runtime structs so each compatible can declare its own set with per-clock
> > rates. The clocks are acquired during probe and enabled/disabled
> > alongside the existing link clock in ethqos_clks_config().
>
> Sounds like we should use an OPP table instead, we can't just do
> set_rate() on qcom, as that will not propagate the required perf
> state to the clock controller's supplier power domain (i.e. VDDCX)
>
Understood, I will test this out for v2.
Ayaan
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Conor Dooley @ 2026-06-16 16:11 UTC (permalink / raw)
To: Amit Barzilai
Cc: robh, krzk+dt, conor+dt, javierm, devicetree, dri-devel,
linux-kernel, airlied, maarten.lankhorst, mripard, simona,
tzimmermann
In-Reply-To: <20260615175620.88828-1-amit.barzilai22@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]
On Mon, Jun 15, 2026 at 08:56:20PM +0300, Amit Barzilai wrote:
> Add a device tree binding for the Solomon SSD1351, a 128x128 65k-color
> RGB OLED display controller driven over a 4-wire SPI bus. The binding
> builds on the shared solomon,ssd-common.yaml properties already used by
> the other Solomon display controllers.
>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
> ---
> Changes since v1:
> - Drop solomon,width / solomon,height: both are deducible from the
> compatible and are already declared (as optional) by the referenced
> solomon,ssd-common.yaml, so a local override is unnecessary.
> - Drop the rotation property: it has no consumer (rotation is being removed from the driver).
> - Use dt-bindings/gpio/gpio.h flag defines in the example
> (reset-gpios active-low, dc-gpios active-high).
The user for this appears to be in staging. As far as I understand, the
policy is that we only add bindings for staging things when they move
out of staging.
Sure, this is straightforward but why should an exception be made here?
Are you working on moving this out of staging?
Cheers,
Conor.
>
> .../bindings/display/solomon,ssd1351.yaml | 41 +++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
> new file mode 100644
> index 000000000000..39622d74a41d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/solomon,ssd1351.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Solomon SSD1351 OLED Display Controller
> +
> +maintainers:
> + - Amit Barzilai <amit.barzilai22@gmail.com>
> +
> +allOf:
> + - $ref: solomon,ssd-common.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - solomon,ssd1351
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + oled@0 {
> + compatible = "solomon,ssd1351";
> + reg = <0x0>;
> + reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW>;
> + dc-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>;
> + spi-max-frequency = <10000000>;
> + };
> + };
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v9 1/3] dt-bindings: timer: mips,p8700-gcru
From: sashiko-bot @ 2026-06-16 16:08 UTC (permalink / raw)
To: Aleksa Paunovic via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260616-riscv-time-mmio-v9-1-03af7bc8f2d8@htecgroup.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Usage of deprecated vendor prefix 'mips,' for a new compatible string.
--
commit 26c5e0f809bd1633d85e1be068047d23439d144d
Author: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
dt-bindings: timer: mips,p8700-gcru
Add dt-bindings for the GCR.U memory mapped timer device for RISC-V platforms.
The GCR.U memory region contains shadow copies of the RISC-V mtime register
and the hrtime Global Configuration Register.
> diff --git a/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml b/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml
> new file mode 100644
> index 0000000000000..e6f25e769f461
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml
> @@ -0,0 +1,38 @@
[ ... ]
> +properties:
> + compatible:
> + const: mips,p8700-gcru
[Severity: Low]
Is the mips, vendor prefix deprecated for new device tree bindings?
Looking at Documentation/devicetree/bindings/vendor-prefixes.yaml, the mips
prefix is explicitly marked as deprecated, with recommendations to use mti
or img instead. If this prefix is intended to be reclaimed for new hardware,
does it first need to be formally undeprecated in the vendor prefixes list?
[ ... ]
> +examples:
> + - |
> + timer@1617f050 {
> + compatible = "mips,p8700-gcru";
[Severity: Low]
This example similarly reinforces the use of the potentially deprecated mips,
vendor prefix. Should this be updated to use mti,img, or another approved
vendor prefix to align with subsystem conventions?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-riscv-time-mmio-v9-0-03af7bc8f2d8@htecgroup.com?part=1
^ permalink raw reply
* Re: [PATCH v3 2/2] hwmon: (pmbus/lm25066) add current limit configuration support
From: Guenter Roeck @ 2026-06-16 16:07 UTC (permalink / raw)
To: Potin Lai
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Zev Weiss,
linux-hwmon, devicetree, linux-kernel, Cosmo Chou, Mike Hsieh,
Potin Lai
In-Reply-To: <20260615-lm25066-cl-config-v3-2-decb4f5b0b77@gmail.com>
On Mon, Jun 15, 2026 at 05:49:17PM +0800, Potin Lai wrote:
> Add support for the 'ti,current-range' devicetree property to configure
> the current limit via the DEVICE_SETUP (0xD9) register, overriding the
> physical CL pin setting.
>
> This configuration is supported on all chips in this driver (LM25066,
> LM5064, LM5066, LM5066i) except LM25056.
>
> The property values "low" and "high" map to:
> - LM25066: low = 25 mV, high = 46 mV
> - LM5064, LM5066, LM5066i: low = 26 mV, high = 50 mV
>
> The Bit 4 mapping to High/Low current limit is handled dynamically on
> probe because it is swapped for LM25066 compared to the other supported
> chips.
>
> Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: Conor Dooley @ 2026-06-16 16:07 UTC (permalink / raw)
To: David Lechner (TI)
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260615-iio-adc-ti-ads122c14-v1-1-e6bdadf7cb2b@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 9413 bytes --]
On Mon, Jun 15, 2026 at 04:59:59PM -0500, David Lechner (TI) wrote:
> Add new bindings for ti,ads122c14 and similar devices.
>
> This is an ADC that is primarily intended for use with temperature
> sensors. There are a few unusual properties because of this. In
> particular, the reference voltage source and current output requirements
> can be different for each measurement, so these are included in the
> channel bindings.
>
> The REFP/REFN reference voltage is usually just connected to a resistor
> that is being driven by the ADC's current outputs, so there is special
> property for this case rather than requiring a regulator to be defined
> to represent that.
>
> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
> have preferred an enum of strings).
>
> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
> ---
> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
> MAINTAINERS | 7 +
> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
> 3 files changed, 242 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> new file mode 100644
> index 000000000000..dc7f37cad772
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> @@ -0,0 +1,224 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments' ADS112C14 and similar ADC chips
> +
> +description: |
> + Supports the following Texas Instruments' ADC chips:
> + - ADS112C14 (16-bit)
> + - ADS122C14 (24-bit)
> +
> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
> +
> + These chips are primarily designed for use with temperature sensors such as
> + RTDs and thermocouples. The channel bindings reflect this in that each channel
> + represents the conditions required to make a measurement rather than strictly
> + just the physical input channels.
> +
> +maintainers:
> + - David Lechner <dlechner@baylibre.com>
> +
> +unevaluatedProperties: false
Weird positioning of this.
> +
> +properties:
> + compatible:
> + enum:
> + - ti,ads112c14
> + - ti,ads122c14
> +
> + reg:
> + items:
> + - minimum: 0x40
> + maximum: 0x47
> +
> + clocks:
> + maxItems: 1
> + description: Optional external clock connected to GPIO3 pin.
> +
> + avdd-supply: true
> + dvdd-supply: true
> +
> + refp-supply: true
> + refn-supply: true
> +
> + refp-refn-resistor-ohms:
Missing prefix here and elsewhere.
> + description:
> + The resistance of the external resistor between REFP and REFN when using
> + resistor bridge driven by current outputs for RTD measurements.
> +
> + interrupts:
> + minItems: 1
> + items:
> + - description: FAULT interrupt (GPIO2 pin)
> + - description: DRDY interrupt (GPIO3 pin)
> +
> + interrupt-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + enum: [fault, drdy]
> +
> + gpio-controller: true
> + '#gpio-cells':
> + const: 2
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +patternProperties:
> + ^channel@[0-7]$:
> + $ref: adc.yaml
> +
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + maximum: 16 # arbitrary limit, channel@ can be any combination of AIN0-AIN7
> +
> + single-channel:
> + maximum: 7
> +
> + diff-channels:
> + items:
> + maximum: 7
> +
> + bipolar:
> + description:
> + Set this flag if the differential input can be negative.
> +
> + excitation-channels:
(here)
> + description: AINx pins used as current output.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 2
> + items:
> + maximum: 7
> +
> + excitation-current-microamp:
(here)
> + description: The current output of the excitation channels in microamps.
> + minimum: 1
> + maximum: 1000
> +
> + current-chopping:
(and here)
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + If provided, the two excitation channels are to be used with current
> + chopping enabled.
> +
> + ti,vref-source:
> + description: |
> + Indicates the source for the reference voltage for this channel.
> + 0 - Internal 2.5V reference
> + 1 - Internal 1.25V reference
> + 2 - External reference (REFP-REFN)
> + 3 - AVDD as reference
My usual complaint here about things you have to make macros for, could
these just be strings from the get-go?
> +
> + For convenience, macros for these values are available in
> + dt-bindings/iio/adc/ti,ads112c14.h.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + maximum: 3
> + default: 0
> +
> + dependencies:
> + excitation-channels: [ excitation-current-microamp ]
> + excitation-current-microamp: [ excitation-channels ]
> + current-chopping: [ excitation-channels ]
> +
> + oneOf:
> + - required: [ single-channel ]
> + - required: [ diff-channels ]
> +
> +required:
> + - compatible
> + - reg
> + - avdd-supply
> + - dvdd-supply
> +
> +dependencies:
> + refn-supply: [ refp-supply ]
> +
> +allOf:
> + - oneOf:
"allOf: - oneOf:" is equivalent to just writing "oneOf:"
pw-bot: changes-requested
Thanks,
Conor.
> + - required: [ refp-supply ]
> + - required: [ refp-refn-resistor-ohms ]
> + - properties:
> + refp-supply: false
> + refn-supply: false
> + refp-refn-resistor-ohms: false
> +
> +examples:
> + - |
> + #include <dt-bindings/iio/adc/ti,ads112c14.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc@40 {
> + compatible = "ti,ads112c14";
> + reg = <0x40>;
> +
> + avdd-supply = <&avdd>;
> + dvdd-supply = <&dvdd>;
> +
> + /* 3-Wire RTD: Two IDACs, One Measurement (AIN1-AIN2) */
> +
> + refp-refn-resistor-ohms = <500>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 {
> + reg = <0>;
> + diff-channels = <1>, <2>;
> + excitation-channels = <0>, <3>;
> + excitation-current-microamp = <500>;
> + current-chopping;
> + ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> + label = "rtd";
> + };
> + };
> + };
> + - |
> + #include <dt-bindings/iio/adc/ti,ads112c14.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc@40 {
> + compatible = "ti,ads112c14";
> + reg = <0x40>;
> +
> + avdd-supply = <&avdd>;
> + dvdd-supply = <&dvdd>;
> +
> + /* Resistive Bridge Measurement With a Thermistor for Temperature Compensation*/
> +
> + refp-supply = <&avdd>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 {
> + reg = <0>;
> + diff-channels = <6>, <7>;
> + bipolar;
> + ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> + label = "bridge";
> + };
> +
> + channel@1 {
> + reg = <1>;
> + diff-channels = <1>, <2>;
> + ti,vref-source = <ADS112C14_VREF_SOURCE_INTERNAL_2_5V>;
> + label = "thermistor";
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f1caa6e5198b..9ce7c61b0c14 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -26911,6 +26911,13 @@ S: Maintained
> F: Documentation/devicetree/bindings/iio/adc/ti,ads1119.yaml
> F: drivers/iio/adc/ti-ads1119.c
>
> +TI ADS112C14 ADC DRIVER
> +M: David Lechner <dlechner@baylibre.com>
> +L: linux-iio@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> +F: include/dt-bindings/iio/adc/ti,ads112c14.h
> +
> TI ADS1018 ADC DRIVER
> M: Kurt Borja <kuurtb@gmail.com>
> L: linux-iio@vger.kernel.org
> diff --git a/include/dt-bindings/iio/adc/ti,ads112c14.h b/include/dt-bindings/iio/adc/ti,ads112c14.h
> new file mode 100644
> index 000000000000..96906642fe41
> --- /dev/null
> +++ b/include/dt-bindings/iio/adc/ti,ads112c14.h
> @@ -0,0 +1,11 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +#ifndef _DT_BINDINGS_TI_ADS112C14_H
> +#define _DT_BINDINGS_TI_ADS112C14_H
> +
> +#define ADS112C14_VREF_SOURCE_INTERNAL_2_5V 0
> +#define ADS112C14_VREF_SOURCE_INTERNAL_1_25V 1
> +#define ADS112C14_VREF_SOURCE_EXTERNAL 2
> +#define ADS112C14_VREF_SOURCE_AVDD 3
> +
> +#endif /* _DT_BINDINGS_TI_ADS112C14_H */
>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Guenter Roeck @ 2026-06-16 16:06 UTC (permalink / raw)
To: Potin Lai
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Zev Weiss,
linux-hwmon, devicetree, linux-kernel, Cosmo Chou, Mike Hsieh,
Potin Lai
In-Reply-To: <20260615-lm25066-cl-config-v3-1-decb4f5b0b77@gmail.com>
On Mon, Jun 15, 2026 at 05:49:16PM +0800, Potin Lai wrote:
> Add a 'ti,current-range' string property to configure the device's Current
> Limit (CL) behavior to "high" or "low" via the register, overriding the
> physical CL pin setting.
>
> This configuration is supported on LM25066, LM5064, LM5066, and LM5066i.
> LM25056 is excluded because it does not support configuring the current
> limit via the DEVICE_SETUP register (bit 2 of DEVICE_SETUP is reserved).
>
> The values "low" and "high" map to the respective low/high threshold
> voltages of the chips:
> - LM25066: low = 25 mV, high = 46 mV
> - LM5064, LM5066, LM5066i: low = 26 mV, high = 50 mV
>
> Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 3/3] hwmon: Add documentation for SQ24860
From: Guenter Roeck @ 2026-06-16 16:05 UTC (permalink / raw)
To: Ziming Zhu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
In-Reply-To: <20260612030304.5165-4-zmzhu0630@163.com>
On Fri, Jun 12, 2026 at 11:03:04AM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Document the supported sysfs attributes for the Silergy SQ24860 PMBus
> hwmon driver.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 2/3] hwmon: pmbus: Add support for Silergy SQ24860
From: Guenter Roeck @ 2026-06-16 16:04 UTC (permalink / raw)
To: Ziming Zhu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
In-Reply-To: <20260612030304.5165-3-zmzhu0630@163.com>
On Fri, Jun 12, 2026 at 11:03:03AM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Add PMBus hwmon support for the Silergy SQ24860 eFuse.
>
> The driver reports input voltage, output voltage, auxiliary voltage,
> input current, input power, and temperature. It also exposes peak,
> average, and minimum history attributes, sample count configuration,
> and maps the manufacturer-specific VIREF register to the generic input
> over-current fault limit attribute.
>
> The IMON resistor value is read from the silergy,rimon-micro-ohms device
> property and used to configure the input current calibration gain.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
From: Guenter Roeck @ 2026-06-16 16:03 UTC (permalink / raw)
To: Ziming Zhu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu, Conor Dooley
In-Reply-To: <20260612030304.5165-2-zmzhu0630@163.com>
On Fri, Jun 12, 2026 at 11:03:02AM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Add devicetree binding documentation for the Silergy SQ24860 eFuse.
>
> The device is a PMBus hardware monitoring device which reports voltage,
> current, power, and temperature telemetry. The board-specific IMON
> resistor value is described with silergy,rimon-micro-ohms.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Applied to hwmon-next (after dropping the extra blank line above).
Thanks,
Guenter
^ permalink raw reply
* [PATCH v9 3/3] riscv: clocksource: Add p8700-gcru driver
From: Aleksa Paunovic via B4 Relay @ 2026-06-16 16:03 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Paul Walmsley, John Stultz, Stephen Boyd,
Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Aleksa Paunovic, Chao-ying Fu
In-Reply-To: <20260616-riscv-time-mmio-v9-0-03af7bc8f2d8@htecgroup.com>
From: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
Add a clocksource driver for the P8700 GCRU.
Initialization uses helper functions
provided by clocksource/mmio.c and timer-of.c.
Since the GCRU does not support any kind of interrupts,
the default RISC-V clockevent implementation should suffice.
Signed-off-by: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
---
drivers/clocksource/Kconfig | 9 ++++++++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-p8700.c | 47 +++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index ffcd23668763fe7707a4e917bf240caadbb09a8c..a775a301f3f08ca97699e46aaf3ccfaf99734e6b 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -672,6 +672,15 @@ config CLINT_TIMER
This option enables the CLINT timer for RISC-V systems. The CLINT
driver is usually used for NoMMU RISC-V systems.
+config P8700_TIMER
+ bool "MIPS P8700 timer driver"
+ depends on GENERIC_SCHED_CLOCK && RISCV && RISCV_SBI && 64BIT
+ select CLKSRC_MMIO
+ select TIMER_PROBE
+ select TIMER_OF
+ help
+ Enables support for MIPS P8700 timer driver.
+
config CSKY_MP_TIMER
bool "SMP Timer for the C-SKY platform" if COMPILE_TEST
depends on CSKY
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index ec4452ee958f1a814c708aeba6412bea61d24892..fae9a58d6c8663a7c857b9ab7fdae05782b3551c 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_CLKSRC_LOONGSON1_PWM) += timer-loongson1-pwm.o
obj-$(CONFIG_EP93XX_TIMER) += timer-ep93xx.o
obj-$(CONFIG_RALINK_TIMER) += timer-ralink.o
obj-$(CONFIG_NXP_STM_TIMER) += timer-nxp-stm.o
+obj-$(CONFIG_P8700_TIMER) += timer-p8700.o
diff --git a/drivers/clocksource/timer-p8700.c b/drivers/clocksource/timer-p8700.c
new file mode 100644
index 0000000000000000000000000000000000000000..dd20b4e72fcdd77a6b33775f286d0945c2a2b659
--- /dev/null
+++ b/drivers/clocksource/timer-p8700.c
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2025 MIPS.
+ */
+
+#include <linux/sched_clock.h>
+#include <linux/delay.h>
+#include <linux/of_address.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/clocksource.h>
+
+#include "timer-of.h"
+
+static struct timer_of gcru_of = { .flags = TIMER_OF_BASE };
+static u64 __iomem *p8700_time_val __ro_after_init;
+
+static u64 notrace p8700_timer_sched_read(void)
+{
+ return (u64)readq_relaxed(p8700_time_val);
+}
+
+static int __init p8700_timer_init(struct device_node *node)
+{
+ int error = 0;
+
+ error = timer_of_init(node, &gcru_of);
+ if (error)
+ return error;
+
+ p8700_time_val = timer_of_base(&gcru_of);
+ /* Now init the mmio timer with the address we got from DT */
+ error = clocksource_mmio_init(p8700_time_val, "mips,p8700-gcru",
+ riscv_timebase, 450, 64,
+ clocksource_mmio_readq_up);
+ if (error) {
+ timer_of_cleanup(&gcru_of);
+ return error;
+ }
+
+ /* Sched clock */
+ sched_clock_register(p8700_timer_sched_read, 64, riscv_timebase);
+
+ return error;
+}
+
+TIMER_OF_DECLARE(p8700_timer, "mips,p8700-gcru", p8700_timer_init);
--
2.43.0
^ permalink raw reply related
* [PATCH v9 2/3] riscv: clocksource: Add readq options to clocksource mmio
From: Aleksa Paunovic via B4 Relay @ 2026-06-16 16:03 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Paul Walmsley, John Stultz, Stephen Boyd,
Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Aleksa Paunovic, Chao-ying Fu
In-Reply-To: <20260616-riscv-time-mmio-v9-0-03af7bc8f2d8@htecgroup.com>
From: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
Add read functions for 64-bit register size to the generic
mmio clocksource, covering both up and down counters.
Signed-off-by: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
---
drivers/clocksource/mmio.c | 14 ++++++++++++++
include/linux/clocksource.h | 4 ++++
2 files changed, 18 insertions(+)
diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
index 9de75153183124cc8997c6ab61d0c01d9b2637bc..f3b6f7e93ffbf0ed68e56c58c3d9f711d2193caa 100644
--- a/drivers/clocksource/mmio.c
+++ b/drivers/clocksource/mmio.c
@@ -17,6 +17,20 @@ static inline struct clocksource_mmio *to_mmio_clksrc(struct clocksource *c)
return container_of(c, struct clocksource_mmio, clksrc);
}
+#if defined(CONFIG_64BIT) && defined(readq_relaxed)
+
+u64 clocksource_mmio_readq_up(struct clocksource *c)
+{
+ return (u64)readq_relaxed(to_mmio_clksrc(c)->reg);
+}
+
+u64 clocksource_mmio_readq_down(struct clocksource *c)
+{
+ return ~(u64)readq_relaxed(to_mmio_clksrc(c)->reg) & c->mask;
+}
+
+#endif
+
u64 clocksource_mmio_readl_up(struct clocksource *c)
{
return (u64)readl_relaxed(to_mmio_clksrc(c)->reg);
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 65b7c41471c390463770c2da13694e58e83b84ea..39e0df5a0ab52cbb7016b53a4d7500f2697e2797 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -276,6 +276,10 @@ static inline void clocksource_arch_init(struct clocksource *cs) { }
extern int timekeeping_notify(struct clocksource *clock);
+#if defined(CONFIG_64BIT) && defined(readq_relaxed)
+extern u64 clocksource_mmio_readq_up(struct clocksource *c);
+extern u64 clocksource_mmio_readq_down(struct clocksource *c);
+#endif
extern u64 clocksource_mmio_readl_up(struct clocksource *);
extern u64 clocksource_mmio_readl_down(struct clocksource *);
extern u64 clocksource_mmio_readw_up(struct clocksource *);
--
2.43.0
^ permalink raw reply related
* [PATCH v9 1/3] dt-bindings: timer: mips,p8700-gcru
From: Aleksa Paunovic via B4 Relay @ 2026-06-16 16:03 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Paul Walmsley, John Stultz, Stephen Boyd,
Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Aleksa Paunovic, Chao-ying Fu, Conor Dooley
In-Reply-To: <20260616-riscv-time-mmio-v9-0-03af7bc8f2d8@htecgroup.com>
From: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
Add dt-bindings for the GCR.U memory mapped timer device for RISC-V
platforms. The GCR.U memory region contains shadow copies of the RISC-V
mtime register and the hrtime Global Configuration Register.
Signed-off-by: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../devicetree/bindings/timer/mips,p8700-gcru.yaml | 38 ++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml b/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..e6f25e769f461d58c87194fba3540eee13cb322b
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/mips,p8700-gcru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GCR.U timer device for the MIPS P8700 platform
+
+maintainers:
+ - Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
+
+description:
+ The GCR.U memory region contains memory mapped shadow copies of
+ mtime and hrtime Global Configuration Registers,
+ which software can choose to make accessible from user mode.
+
+properties:
+ compatible:
+ const: mips,p8700-gcru
+
+ reg:
+ items:
+ - description: Read-only shadow copy of the RISC-V mtime register.
+ - description: Read-only shadow copy of the P8700 high resolution timer register.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ timer@1617f050 {
+ compatible = "mips,p8700-gcru";
+ reg = <0x1617f050 0x8>,
+ <0x1617f090 0x8>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v9 0/3] riscv: Use GCR.U timer device as clocksource
From: Aleksa Paunovic via B4 Relay @ 2026-06-16 16:03 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Paul Walmsley, John Stultz, Stephen Boyd,
Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Aleksa Paunovic, Chao-ying Fu, Conor Dooley
This series adds bindings for the GCR.U timer device and corresponding
driver support. Accessing the memory mapped shadow of the mtime register
in the GCR.U region should be faster
than trapping to M mode each time the timer needs to be read.
The timer device does not implement any interrupts, therefore the
timer-riscv clockevent implementation should suffice.
We tested the patchset both on QEMU and the Boston board with the P8700 bitfile:
- v7, v8 testing:
- Coremark and timer kselftests on QEMU emulating an 8 core CPU
- Coremark and timer kselftests on the Boston board with a single core CPU.
Signed-off-by: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
Signed-off-by: Djordje Todorovic <djordje.todorovic@htecgroup.com>
Signed-off-by: Chao-ying Fu <cfu@mips.com>
---
Changes in v9:
- Fix timer base address in dt-bindings
- Link to v8: https://lore.kernel.org/r/20260610-riscv-time-mmio-v8-0-a865206675c6@htecgroup.com
Changes in v8:
- Make the 64 bit timer mmio reads and the main timer driver depend on CONFIG_64BIT
- Add timer_of_cleanup to the driver code
- Link to v7: https://lore.kernel.org/r/20260311-riscv-time-mmio-v7-0-016845a0f808@htecgroup.com
Changes in v7:
- Replace the previous implementation with a new timer driver for mips,p8700-gcru
- Add a patch for 64bit reads for timer mmio
- Link to v6: https://lore.kernel.org/r/20250806-riscv-time-mmio-v6-0-2df0e8219998@htecgroup.com
Changes in v6:
- Rename mti,gcru to mips,p8700-gcru
- Link to v5: https://lore.kernel.org/r/20250711-riscv-time-mmio-v5-0-9ed1f825ad5e@htecgroup.com
Changes in v5:
- Fixed build issues on 32-bit RISC-V and sparse warnings
- Remove clint_time_val and clint.h, replace with riscv_time_val
- Depend on RISCV_TIMER in Kconfig
Changes in v4:
- Remove "select" from mti,gcru.yaml.
- Refactor the driver to use function pointers instead of static keys.
Previous versions:
v1: https://lore.kernel.org/lkml/20241227150056.191794-1-arikalo@gmail.com/#t
v2: https://lore.kernel.org/linux-riscv/20250409143816.15802-1-aleksa.paunovic@htecgroup.com/
v3: https://lore.kernel.org/linux-riscv/DU0PR09MB61968695A2A3146EE83B7708F6BA2@DU0PR09MB6196.eurprd09.prod.outlook.com/
v4: https://lore.kernel.org/r/20250514-riscv-time-mmio-v4-0-cb0cf2922d66@htecgroup.com
v5: https://lore.kernel.org/r/20250711-riscv-time-mmio-v5-0-9ed1f825ad5e@htecgroup.com
v6: https://lore.kernel.org/r/20250806-riscv-time-mmio-v6-0-2df0e8219998@htecgroup.com
v7: https://lore.kernel.org/r/20260311-riscv-time-mmio-v7-0-016845a0f808@htecgroup.com
v8: https://lore.kernel.org/r/20260610-riscv-time-mmio-v8-0-a865206675c6@htecgroup.com
---
Aleksa Paunovic (3):
dt-bindings: timer: mips,p8700-gcru
riscv: clocksource: Add readq options to clocksource mmio
riscv: clocksource: Add p8700-gcru driver
.../devicetree/bindings/timer/mips,p8700-gcru.yaml | 38 +++++++++++++++++
drivers/clocksource/Kconfig | 9 +++++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/mmio.c | 14 +++++++
drivers/clocksource/timer-p8700.c | 47 ++++++++++++++++++++++
include/linux/clocksource.h | 4 ++
6 files changed, 113 insertions(+)
---
base-commit: ac3fd01e4c1efce8f2c054cdeb2ddd2fc0fb150d
change-id: 20250424-riscv-time-mmio-5628e0fca8af
Best regards,
--
Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: aspeed,ast2700-soc1: Add JTAGM1TRST group
From: Conor Dooley @ 2026-06-16 15:59 UTC (permalink / raw)
To: Billy Tsai
Cc: Andrew Jeffery, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, linux-aspeed, openbmc, linux-gpio,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260616-pinctrl-fix-v1-1-621036e45c7c@aspeedtech.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 v2 2/3] hwmon: ina2xx: support ina232
From: Guenter Roeck @ 2026-06-16 15:59 UTC (permalink / raw)
To: Loic Poulain
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Krzysztof Kozlowski, linux-hwmon, devicetree,
linux-kernel, linux-arm-msm, Martino Facchin
In-Reply-To: <20260611-monza-ina232-v2-2-e4375ce652d0@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 04:05:25PM +0200, Loic Poulain wrote:
> From: Martino Facchin <m.facchin@arduino.cc>
>
> The INA232 is a current/power monitor. It shares the same register
> layout as the INA2xx and uses the INA226 default configuration, but
> differs in its electrical characteristics:
>
> Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: hwmon: ina2xx: add ina232 compatible
From: Guenter Roeck @ 2026-06-16 15:58 UTC (permalink / raw)
To: Loic Poulain
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Krzysztof Kozlowski, linux-hwmon, devicetree,
linux-kernel, linux-arm-msm, Martino Facchin
In-Reply-To: <20260611-monza-ina232-v2-1-e4375ce652d0@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 04:05:24PM +0200, Loic Poulain wrote:
> From: Martino Facchin <m.facchin@arduino.cc>
>
> The INA232 is a current/power monitor from Texas Instruments sharing
> the same register map as the other INA2xx.
>
> Signed-off-by: Martino Facchin <m.facchin@arduino.cc>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Applied to hwmon-next. The branch will be updated after the commit window
closes.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 4/4] iio: adc: ti-ads112c14: add measurement channel support
From: David Lechner @ 2026-06-16 15:55 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <ajELGxonxsQp-Ut2@ashevche-desk.local>
On 6/16/26 3:36 AM, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 05:00:02PM -0500, David Lechner (TI) wrote:
>> Add support for parsing devicetree properties for measurement channels
>> and doing direct reads on these.
>>
>> There are quite a lot of conditions that have to be met for each
>> measurement to be made, so quite a bit of state and algorithms are
>> required to handle it.
>>
>> Channels are created dynamically since the number of possibilities is
>> unreasonably large.
>
>> + /* measurement channels */
>> + if (chan->channel < 100) {
>> + struct ads112c14_measurement *measurement =
>> + &data->measurements[chan->scan_index];
>
>> + if (!measurement->label)
>> + return -EINVAL;
>
> Hmm... Can it be true?
Yes. For some channels, label comes from the devicetree, which
may not have provided a label.
>
>> + return sysfs_emit(label, "%s\n", measurement->label);
>> + }
>
...
>> + if (fwnode_property_present(child, "single-channel")) {
>> + ret = fwnode_property_read_u32(child, "single-channel", &spec->channel);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read single-channel property\n");
>> +
>> + if (spec->channel >= 8)
>> + return dev_err_probe(dev, -EINVAL,
>> + "single-channel value must be between 0 and 7\n");
>> + } else if (fwnode_property_present(child, "diff-channels")) {
>> + ret = fwnode_property_read_u32_array(child, "diff-channels", pair, ARRAY_SIZE(pair));
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read diff-channels property\n");
>> +
>> + if (pair[0] >= 8 || pair[1] >= 8)
>> + return dev_err_probe(dev, -EINVAL,
>> + "diff-channels values must be between 0 and 7\n");
>> +
>> + spec->channel = pair[0];
>> + spec->channel2 = pair[1];
>> + spec->differential = 1;
>> + } else {
>> + return dev_err_probe(dev, -EINVAL,
>> + "channel node missing channel type property\n");
>> + }
>
> Looking how it's going to spread (I mean the above pattern), perhaps it's a time to introduce bunch of
>
> fwnode_property_read_*_optional()
>
> and the respective device_property_read_*_optional()?
>
> Let's start from u32 case only, as it will be most used anyway.
I don't think that would be really any different from device_property_read_*
and checking for -EINVAL or ignoring the error completely. TBH, I really like
it this way with fwnode_property_present().
>
>> + if (fwnode_property_present(child, "excitation-channels")) {
>> + ret = fwnode_property_count_u32(child, "excitation-channels");
>> + if (ret < 0)
>> + return dev_err_probe(dev, ret,
>> + "failed to read excitation-channels property\n");
>> +
>> + if (ret < 1 || ret > 2)
>> + return dev_err_probe(dev, -EINVAL,
>> + "excitation-channels property must have 1 or 2 values\n");
>> +
>> + measurement->iadc_count = ret;
>> + pair[1] = 0;
>> +
>> + ret = fwnode_property_read_u32_array(child, "excitation-channels", pair, measurement->iadc_count);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read excitation-channels property\n");
>> +
>> + if (pair[0] >= 8 || pair[1] >= 8)
>> + return dev_err_probe(dev, -EINVAL,
>> + "excitation-channels values must be between 0 and 7\n");
>> +
>> + measurement->idac1_mux = pair[0];
>> + measurement->idac2_mux = measurement->iadc_count > 1 ? pair[1] : 0;
>> +
>> + ret = fwnode_property_read_u32(child, "excitation-current-microamp",
>> + &measurement->idac_current_uA);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read excitation-current-microamp property\n");
>> +
>> + measurement->current_chop = fwnode_property_read_bool(child, "current-chopping");
>> + }
>> +
>> + measurement->bipolar = fwnode_property_read_bool(child, "bipolar");
>> +
>> + fwnode_property_read_u32(child, "ti,vref-source", &measurement->vref_source);
>> + if (measurement->vref_source > ADS112C14_VREF_SOURCE_AVDD)
>> + return dev_err_probe(dev, -EINVAL,
>> + "invalid vref-source value\n");
>> +
>> + if (measurement->vref_source == ADS112C14_VREF_SOURCE_AVDD)
>> + *need_avdd_ref = true;
>> + if (measurement->vref_source == ADS112C14_VREF_SOURCE_EXTERNAL)
>> + *need_ext_ref = true;
>> +
>> + spec->info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE);
>> + spec->info_mask_separate_available = BIT(IIO_CHAN_INFO_SCALE);
>> +
>> + i++;
>> + }
>> +
>> + memcpy(channels + i, ads112c14_sys_mon_channels, sizeof(ads112c14_sys_mon_channels));
>> +
>> + indio_dev->channels = channels;
>> + indio_dev->num_channels = i + ARRAY_SIZE(ads112c14_sys_mon_channels);
>> +
>> + return 0;
>> +}
>
> ...
>
>> +static void ads112c14_populate_scale_available(int scale_avail[][2],
>> + u32 vref_uV, u32 fsr_bits)
>> +{
>> + for (u32 i = 0; i < ARRAY_SIZE(ads112c14_pga_gains_x10); i++) {
>> + int *entry = scale_avail[i];
>> + u32 gain_x10 = ads112c14_pga_gains_x10[i];
>> +
>> + entry[0] = div_u64_rem(div64_u64((u64)(NANO * 10 /
>> + (MICRO / MILLI)) * vref_uV,
>> + (u64)gain_x10 * BIT(fsr_bits)),
>
> Hmm... This differs from the previous implementation. Why?
Probably fixed it during testing and missed that I needed to fix
the original patch too.
>
>> + NANO, &entry[1]);
>> + }
>> +}
>
> ...
>
>> + if (device_property_present(dev, "refp-refn-resistor-ohms")) {
>> + if (refp_uV != 0 || refn_uV != 0)
>> + return dev_err_probe(dev, -EINVAL,
>> + "refp-refn-resistor-ohms property should not be present when refp-supply or refn-supply is present\n");
>> +
>> + ret = device_property_read_u32(dev, "refp-refn-resistor-ohms",
>> + &data->ext_ref_ohms);
>> + if (ret)
>> + return dev_err_probe(dev, ret,
>> + "failed to read refp-refn-resistor-ohms property\n");
>
> Using
>
> const char *propname;
> ...
> propname = "refp-refn-resistor-ohms";
>
> makes this
>
> if (device_property_present(dev, propname)) {
> if (refp_uV != 0 || refn_uV != 0)
> return dev_err_probe(dev, -EINVAL,
> "%s property should not be present when refp-supply or refn-supply is present\n",
> propname);
>
> ret = device_property_read_u32(dev, propname, &data->ext_ref_ohms);
> if (ret)
> return dev_err_probe(dev, ret, "failed to read %s property\n", propname);
>
> Also the rest can be improved in the similar way.
Hmm... maybe less error prone, but makes the code harder to read IMHO.
Will think about it.
>
>> + } else {
>> + if (need_ext_ref && data->ext_ref_uV == 0)
>> + return dev_err_probe(dev, -EINVAL,
>> + "external reference measurements require either refp-supply or refp-refn-resistor-ohms property\n");
>> + }
>
^ permalink raw reply
* Re: [PATCH v7 2/2] hwmon: Add Eswin EIC7700 PVT sensor driver
From: Guenter Roeck @ 2026-06-16 15:55 UTC (permalink / raw)
To: sashiko-reviews, hehuan1; +Cc: robh, devicetree, linux-hwmon, conor+dt
In-Reply-To: <20260611091748.A6EAC1F00898@smtp.kernel.org>
On 6/11/26 02:17, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The IRQ is requested before the PM runtime cleanup action is registered, leading to a possible use-after-disable of the hardware clock in the ISR on driver removal.
> - [Medium] The interrupt handler `eic7700_pvt_hard_isr` does not check the hardware interrupt status bit to verify if the device actually generated the interrupt.
> --
>
> commit 0f4c8aefb83780ee09652639eb2843f01c2baf38
> Author: Huan He <hehuan1@eswincomputing.com>
>
> hwmon: Add Eswin EIC7700 PVT sensor driver
>
> Add support for ESWIN EIC7700 Voltage and Temperature sensor. The driver
> supports temperature and voltage monitoring with polynomial conversion,
> and provides sysfs interface for sensor data access.
>
>> diff --git a/drivers/hwmon/eic7700-pvt.c b/drivers/hwmon/eic7700-pvt.c
>> new file mode 100644
>> index 0000000000000..3b3aed74c3941
>> --- /dev/null
>> +++ b/drivers/hwmon/eic7700-pvt.c
>
> [ ... ]
>
>> +static irqreturn_t eic7700_pvt_hard_isr(int irq, void *data)
>> +{
>> + struct pvt_hwmon *pvt = data;
>> + int active;
>> + u32 val;
>> +
>> + if (IS_ENABLED(CONFIG_PM)) {
>> + active = pm_runtime_get_if_active(pvt->dev);
>> + if (active <= 0)
>> + return IRQ_NONE;
>> + }
>> +
>> + eic7700_pvt_update(pvt->regs + PVT_INT, PVT_INT_CLR, PVT_INT_CLR);
>> + /*
>> + * Read the data, update the cache and notify a waiter of this event.
>> + */
>> + val = readl(pvt->regs + PVT_DATA);
>> + WRITE_ONCE(pvt->data_cache, FIELD_GET(PVT_DATA_OUT, val));
>> + complete(&pvt->conversion);
>
> [Severity: Medium]
> Does this unconditionally process the interrupt without checking if the device
> actually generated it?
>
> If a spurious interrupt occurs, the ISR will prematurely clear the interrupt,
> read whatever stale value is in PVT_DATA, and call complete(&pvt->conversion).
> This will cause the waiting thread in eic7700_pvt_read_data() to wake up early
> and return stale or garbage data to userspace.
>
> Should the ISR read the status register and return IRQ_NONE if its device did
> not assert the interrupt?
>
> [ ... ]
>
>> + ret = eic7700_pvt_request_irq(pvt);
>> + if (ret) {
>> + if (!IS_ENABLED(CONFIG_PM))
>> + clk_disable_unprepare(pvt->clk);
>> + return ret;
>> + }
>> +
>> + pm_runtime_enable(&pdev->dev);
>> + pm_runtime_set_autosuspend_delay(&pdev->dev, 3000);
>> + pm_runtime_use_autosuspend(&pdev->dev);
>> + pm_runtime_get_noresume(&pdev->dev);
>> +
>> + ret = devm_add_action_or_reset(pvt->dev, eic7700_pvt_disable_pm_runtime,
>> + pvt);
>
> [Severity: High]
> Can this devres setup lead to accessing unclocked registers during device
> removal?
>
> Because devres executes teardown callbacks in reverse order of their
> registration, eic7700_pvt_disable_pm_runtime() will run before the IRQ
> is freed by devm_request_threaded_irq()'s teardown.
>
> During removal, eic7700_pvt_disable_pm_runtime() disables the clock:
>
> eic7700_pvt_disable_pm_runtime() {
> ...
> if (!pm_runtime_status_suspended(pvt->dev)) {
> clk_disable_unprepare(pvt->clk);
> pm_runtime_set_suspended(pvt->dev);
> }
> }
>
> If an interrupt fires concurrently and the ISR executes past the
> pm_runtime_get_if_active() check before the clock is disabled, the ISR
> will attempt to access hardware registers while unclocked, which can lead
> to an external abort or kernel panic:
>
> eic7700_pvt_hard_isr() {
> ...
> eic7700_pvt_update(pvt->regs + PVT_INT, ...);
> }
>
> Should the PM runtime cleanup action be registered before the IRQ is requested?
>
If not solved, these questions will at least have to be answered.
Thanks,
Guenter
>> + if (ret) {
>> + pm_runtime_put_noidle(&pdev->dev);
>> + return dev_err_probe(&pdev->dev, ret,
>> + "Can't register PM cleanup\n");
>> + }
>
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: adm1275: ROHM BD12790 hot-swap controller
From: Conor Dooley @ 2026-06-16 15:54 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Matti Vaittinen, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Wensheng Wang, Ashish Yadav, Kim Seer Paller, Cedric Encarnacion,
Chris Packham, Yuxi Wang, Charles Hsu, ChiShih Tsai, linux-hwmon,
devicetree, linux-kernel, linux-doc
In-Reply-To: <ae80a037fa3b03ef5cfb446bf3e9c44efd4f04ec.1781591132.git.mazziesaccount@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 RFC v5 1/6] dt-bindings: iio: add Open Sensor Fusion device
From: Conor Dooley @ 2026-06-16 15:53 UTC (permalink / raw)
To: Jinseob Kim
Cc: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-2-kimjinseob88@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6337 bytes --]
On Tue, Jun 16, 2026 at 04:22:37PM +0900, Jinseob Kim wrote:
> Add the generic Open Sensor Fusion device binding for a serdev-attached
> IIO sensor aggregation hub, and document the opensensorfusion vendor
> prefix.
>
> The opensensorfusion,osf compatible describes the generic Open Sensor
> Fusion host interface. OSF GREEN is not the Linux compatible identity.
> Likewise, OSF0 is the current wire magic and a wire-format detail, not
> the Linux driver identity.
>
> The fixed OSF frame header carries protocol_major and protocol_minor at
> fixed offsets. This driver currently supports protocol_major 0.
> protocol_minor changes are intended to remain backward-compatible within
> that fixed header layout. Incompatible wire-format changes require a new
> protocol_major. If a future device cannot expose compatible version
> discovery through the fixed header layout, it will need a different
> compatible.
>
> Require vcc-supply so the driver can enable device power before starting
> communication.
>
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
> ---
> .../bindings/iio/opensensorfusion,osf.yaml | 59 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 13 ++++
> 3 files changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> new file mode 100644
> index 000000000..012a07fd6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Open Sensor Fusion Sensor Aggregation Hub
> +
> +maintainers:
> + - Jinseob Kim <kimjinseob88@gmail.com>
> +
> +description: |
> + Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
> + protocol data stream over its host interface and may report capabilities and
s/may report/reports/ because mandatory reporting, even if nothing is
actually there, is a requirement for having a compatible describing the
"bus".
> + samples for multiple sensor classes. The Linux driver discovers the actual
s/The Linux driver discovers the actual sensor channels/The actual sensor channels are discovered"
Because although maybe only linux will use this it should not be
specific.
> + sensor channels from OSF capability reports instead of describing those
> + sensors in Device Tree.
> +
> + Open Sensor Fusion is not a generic industry standard. Public project
I would drop this first sentence to be honest.
> + documentation is available at:
> +
> + https://github.com/opensensorfusion
> +
> + The compatible describes the generic Open Sensor Fusion host interface. It
> + is not an OSF GREEN board identity, and it does not encode the OSF0 wire
> + magic. OSF0, protocol_major, and protocol_minor are wire-protocol details
> + exchanged in OSF frames.
I think I move this to the first paragraph and would say something like
| This binding documents the generic Open Sensor Fusion host interface.
|
| Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
| protocol data stream over its host interface and reports capabilities and
| samples for multiple sensor classes. The actual sensor channels are discovered
| at runtime from OSF capability reports instead of describing them in Device
| Tree.
|
| The protocol version is discovered at runtime.
Does that sound about right?
> +
> +allOf:
> + - $ref: /schemas/serial/serial-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + const: opensensorfusion,osf
> +
> + vcc-supply:
> + description:
> + Regulator supplying power to the Open Sensor Fusion device.
> +
> +required:
> + - compatible
> + - vcc-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + vcc_sensor: regulator-0 {
> + compatible = "regulator-fixed";
> + regulator-name = "sensor-vcc";
> + };
Drop this node, the tooling fakes one when running the checks. Only keep
nodes that actually form your device here. Same way you don't need to
actually fill out the serial port.
pw-bot: changes-requested
> +
> + serial {
> + sensor {
> + compatible = "opensensorfusion,osf";
> + vcc-supply = <&vcc_sensor>;
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 28784d66a..88172d4a4 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1237,6 +1237,8 @@ patternProperties:
> description: OpenPandora GmbH
> "^openrisc,.*":
> description: OpenRISC.io
> + "^opensensorfusion,.*":
> + description: Open Sensor Fusion
> "^openwrt,.*":
> description: OpenWrt
> "^option,.*":
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c2c6d7927..2ddefc42d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20011,6 +20011,19 @@ F: Documentation/devicetree/
> F: arch/*/boot/dts/
> F: include/dt-bindings/
>
> +OPEN SENSOR FUSION IIO DRIVER
> +M: Jinseob Kim <kimjinseob88@gmail.com>
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> +F: Documentation/iio/open-sensor-fusion.rst
> +F: drivers/iio/opensensorfusion/Kconfig
> +F: drivers/iio/opensensorfusion/Makefile
> +F: drivers/iio/opensensorfusion/osf_core.*
> +F: drivers/iio/opensensorfusion/osf_iio.*
> +F: drivers/iio/opensensorfusion/osf_protocol.*
> +F: drivers/iio/opensensorfusion/osf_serdev.c
> +F: drivers/iio/opensensorfusion/osf_stream.*
At this stage, only add the binding. The rest should be added when the
files are.
Cheers,
Conor.
> +
> OPENCOMPUTE PTP CLOCK DRIVER
> M: Vadim Fedorenko <vadim.fedorenko@linux.dev>
> L: netdev@vger.kernel.org
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/10] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3L support
From: Conor Dooley @ 2026-06-16 15:44 UTC (permalink / raw)
To: Biju
Cc: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, devicetree,
linux-kernel, linux-renesas-soc, Prabhakar Mahadev Lad
In-Reply-To: <20260616104459.410743-2-biju.das.jz@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]
On Tue, Jun 16, 2026 at 11:44:43AM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Document Renesas RZ/G3L (r9a08g046) USB PHY controller bindings.
> The RZ/G3L USB PHY block is similar to RZ/G3S but differs in that each
> port has its own OTG controller, whereas RZ/G3S only has one on port 1.
> To reflect this, RZ/G3L uses a regulators sub-node with per-port vbus0
> and vbus1 entries instead of the single regulator-vbus property used
> by other compatible SoCs.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v1->v2:
> * Updated commit description.
> * Added enum instead of const in the compatible section.
> * Dropped regulator1-vbus and added a regulators group node.
> * Updated schema check.
> ---
> .../reset/renesas,rzg2l-usbphy-ctrl.yaml | 49 +++++++++++++++++--
> 1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> index c83469a1b379..12da48d069e5 100644
> --- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
> @@ -16,13 +16,17 @@ description:
> properties:
> compatible:
> oneOf:
> + - items:
> + - enum:
> + - renesas,r9a08g045-usbphy-ctrl # RZ/G3S
> + - renesas,r9a08g046-usbphy-ctrl # RZ/G3L
Looks fine, other than the fact that the "- items: - enum:" construct is
the same as just having "- enum".
pw-bot: changes-requested
Fix that problem, and
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: iio: magnetometer: add QST QMC5883L Sensor
From: Conor Dooley @ 2026-06-16 15:42 UTC (permalink / raw)
To: Siratul Islam
Cc: jic23, robh, krzk+dt, conor+dt, dlechner, nuno.sa, andy,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260616114942.37241-3-siratul.islam@linux.dev>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Reviewed-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 v2 2/3] dt-bindings: iio: st,st-sensors: add st,fullscale-milligauss
From: Conor Dooley @ 2026-06-16 15:41 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Denis Ciocca, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Denis Ciocca, Linus Walleij,
linux-iio, linux-kernel, llvm, devicetree
In-Reply-To: <20260616-submit-iio-lsm303dlh-magn-fixes-v2-2-063edcf74e60@herrie.org>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Reviewed-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 v3 1/4] dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADC
From: Conor Dooley @ 2026-06-16 15:41 UTC (permalink / raw)
To: rva333
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260616-mt6323-adc-v3-1-1c27c588185d@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
On Tue, Jun 16, 2026 at 05:15:39PM +0300, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage,
> temperature, and other internal measurements. The IP block is not
> register-compatible with mt6359
Cut this sentence here, whether or not it uses the same driver may
differ per OS.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
>
> Add the devicetree binding documentation and the associated header file
> defining the ADC channel constants.
>
> Also change the description to 'MT6350 series and similar' because
> the binding already includes more than mt635x series PMICs.
>
> Finally, add the MAINTAINERS entry for the header with ADC constants.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: Add GPIO-locked fixed clock
From: Conor Dooley @ 2026-06-16 15:39 UTC (permalink / raw)
To: Brian Masney
Cc: V.Yurkov.EXT, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-clk,
devicetree, Vyacheslav Yurkov
In-Reply-To: <ajB2PhmxvdtsXNnm@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4276 bytes --]
On Mon, Jun 15, 2026 at 06:01:34PM -0400, Brian Masney wrote:
> Hi Vyacheslav,
>
> On Wed, Jun 03, 2026 at 11:16:42AM +0000, Vyacheslav Yurkov via B4 Relay wrote:
> > From: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
> >
> > Some hardware designs provide fixed-frequency clocks generated outside
> > software control, such as by FPGA-resident PLLs. While the clock rate is
> > fixed, a separate GPIO signal indicates whether the clock source is
> > locked and producing a valid output.
> >
> > Describe a GPIO-locked fixed clock provider that exposes a fixed-rate
> > clock whose availability depends on one or more GPIO lock-status
> > signals.
> >
> > Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
> > Signed-off-by: Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
> > ---
> > .../bindings/clock/gpio-locked-fixed-clock.yaml | 70 ++++++++++++++++++++++
> > 1 file changed, 70 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/gpio-locked-fixed-clock.yaml b/Documentation/devicetree/bindings/clock/gpio-locked-fixed-clock.yaml
> > new file mode 100644
> > index 000000000000..9106b800b673
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/gpio-locked-fixed-clock.yaml
> > @@ -0,0 +1,70 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/gpio-locked-fixed-clock.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: GPIO Locked Fixed Clock
> > +
> > +maintainers:
> > + - Vyacheslav Yurkov <V.Yurkov.EXT@bruker.com>
> > +
> > +description: |
> > + Provides a clock output whose availability depends on a set of
> > + prerequisite conditions. These conditions include the presence of
> > + one or more parent clocks and the asserted state of one or more
> > + GPIO lock indicators. An example of such clocks is FPGA clock that
> > + are outside CPU control, with the lock status exposed through GPIO
> > + signal.
> > +
> > + The output clock is considered available only when all configured
> > + prerequisites are satisfied.
>
> I'm stepping outside my usual review of just the clk drivers. Krzysztof
> in v1 and v2 asked for more detailed hardware explanation. This feels to
> me like this is a policy that says to not use these clocks until the
> GPIO says they are ready. My gut feeling is that details like this
> should live in a clk driver instead of a dt-binding.
>
> Alternatively, if this is generic enough, then could
> Documentation/devicetree/bindings/clock/gated-fixed-clock.yaml be
> extended?
FWIW this came up in an earlier revision:
https://lore.kernel.org/all/20260407-fling-scouring-dbe2141cc79b@spud/
IMO it's an inverted gpio-gate-clock, where the gpio is an input rather
than an output. I suppose you could extend gpio-gate-clock with it and
have mutually exclusive enable-gpios and status-gpios?
>
> Brian
>
>
> > +
> > +properties:
> > + compatible:
> > + const: gpio-locked-fixed-clock
> > +
> > + "#clock-cells":
> > + const: 0
> > +
> > + clocks:
> > + description: Input clocks whose validity is monitored by this provider.
> > +
> > + clock-output-names:
> > + description: Names of the clock provided by this controller.
> > + maxItems: 1
> > +
> > + locked-gpios:
> > + description: |
> > + GPIOs to check the lock state.
> > + minItems: 1
> > + maxItems: 32
> > +
> > +required:
> > + - compatible
> > + - "#clock-cells"
> > +
> > +anyOf:
> > + - required:
> > + - clocks
> > + - required:
> > + - locked-gpios
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + clk_gpio_locked: gpio-locked-fixed-clock {
> > + compatible = "gpio-locked-fixed-clock";
> > + #clock-cells = <0>;
> > +
> > + clocks = <&clk0 0>, <&pll 0>;
> > +
> > + locked-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>,
> > + <&gpio0 5 GPIO_ACTIVE_HIGH>,
> > + <&gpio1 2 GPIO_ACTIVE_LOW>;
> > +
> > + clock-output-names = "clkout0";
> > + };
> >
> > --
> > 2.34.1
> >
> >
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox