* [PATCH] arm64: dts: aspeed: Fix duplicate pinctrl labels and address scheme
From: Ryan Chen @ 2026-06-11 6:50 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Arnd Bergmann
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Ryan Chen
Fix duplicate pinctrl_tach{0-15} and pinctrl_n{cts,dcd,dsr,ri}5 labels
in aspeed-g7-soc1-pinctrl.dtsi.
Drop the cpu-index from secondary/tertiary container nodes: reduce the
"#address-cells" from 2 to 1 and update ssp_nvic/tsp_nvic unit-address
and reg accordingly. Also remove URL comments from the DTS.
Suggested-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Fixes: e77bb5dc5759 ("arm64: dts: aspeed: Add initial AST27xx SoC device tree")
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
This series contains follow-up fixes for the AST27xx DTS support that
was merged into linux-next (e77bb5dc5759).
Two issues were identified after merge by Andrew Jeffery during review
of the pending v11 series:
1. Duplicate pinctrl state labels in aspeed-g7-soc1-pinctrl.dtsi caused
dtc to abort with fatal label-redefinition errors.
2. The synthetic container nodes (secondary, tertiary) for sub-processor
interrupt controllers used a 2-cell address scheme to encode a
<cpu-index reg-base> tuple. Since the cpu-index adds no value for
nodes that are purely phandle anchors, Andrew requested we drop it
and use the bare register address instead.
---
arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi | 14 ++-
.../boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi | 102 ---------------------
2 files changed, 6 insertions(+), 110 deletions(-)
diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
index ef283d95649a..58193c3c3696 100644
--- a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
+++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
@@ -84,32 +84,30 @@ l2: l2-cache0 {
};
secondary {
- #address-cells = <2>;
- /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n491 */
+ #address-cells = <1>;
#size-cells = <0>;
- /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n430 */
- ssp_nvic: interrupt-controller@1,e000e100 {
+ ssp_nvic: interrupt-controller@e000e100 {
compatible = "arm,v7m-nvic";
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
- reg = <1 0xe000e100>;
+ reg = <0xe000e100>;
arm,num-irq-priority-bits = <3>;
status = "disabled";
};
};
tertiary {
- #address-cells = <2>;
+ #address-cells = <1>;
#size-cells = <0>;
- tsp_nvic: interrupt-controller@2,e000e100 {
+ tsp_nvic: interrupt-controller@e000e100 {
compatible = "arm,v7m-nvic";
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
- reg = <2 0xe000e100>;
+ reg = <0xe000e100>;
arm,num-irq-priority-bits = <3>;
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
index 72d93323593d..6edf14617b09 100644
--- a/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi
@@ -496,87 +496,6 @@ pinctrl_hvi3c15_default: hvi3c15-default-state {
function = "I3C15";
groups = "HVI3C15";
};
-
- pinctrl_tach0_default: tach0-default-state {
- function = "TACH0";
- groups = "TACH0";
- };
-
- pinctrl_tach1_default: tach1-default-state {
- function = "TACH1";
- groups = "TACH1";
- };
-
- pinctrl_tach2_default: tach2-default-state {
- function = "TACH2";
- groups = "TACH2";
- };
-
- pinctrl_tach3_default: tach3-default-state {
- function = "TACH3";
- groups = "TACH3";
- };
-
- pinctrl_tach4_default: tach4-default-state {
- function = "TACH4";
- groups = "TACH4";
- };
-
- pinctrl_tach5_default: tach5-default-state {
- function = "TACH5";
- groups = "TACH5";
- };
-
- pinctrl_tach6_default: tach6-default-state {
- function = "TACH6";
- groups = "TACH6";
- };
-
- pinctrl_tach7_default: tach7-default-state {
- function = "TACH7";
- groups = "TACH7";
- };
-
- pinctrl_tach8_default: tach8-default-state {
- function = "TACH8";
- groups = "TACH8";
- };
-
- pinctrl_tach9_default: tach9-default-state {
- function = "TACH9";
- groups = "TACH9";
- };
-
- pinctrl_tach10_default: tach10-default-state {
- function = "TACH10";
- groups = "TACH10";
- };
-
- pinctrl_tach11_default: tach11-default-state {
- function = "TACH11";
- groups = "TACH11";
- };
-
- pinctrl_tach12_default: tach12-default-state {
- function = "TACH12";
- groups = "TACH12";
- };
-
- pinctrl_tach13_default: tach13-default-state {
- function = "TACH13";
- groups = "TACH13";
- };
-
- pinctrl_tach14_default: tach14-default-state {
- function = "TACH14";
- groups = "TACH14";
- };
-
- pinctrl_tach15_default: tach15-default-state {
- function = "TACH15";
- groups = "TACH15";
- };
-
pinctrl_thru0_default: thru0-default-state {
function = "THRU0";
groups = "THRU0";
@@ -940,27 +859,6 @@ pinctrl_uart3_default: uart3-default-state {
function = "UART3";
groups = "UART3";
};
-
- pinctrl_ncts5_default: ncts5-default-state {
- function = "NCTS5";
- groups = "NCTS5";
- };
-
- pinctrl_ndcd5_default: ndcd5-default-state {
- function = "NDCD5";
- groups = "NDCD5";
- };
-
- pinctrl_ndsr5_default: ndsr5-default-state {
- function = "NDSR5";
- groups = "NDSR5";
- };
-
- pinctrl_nri5_default: nri5-default-state {
- function = "NRI5";
- groups = "NRI5";
- };
-
pinctrl_ndtr5_default: ndtr5-default-state {
function = "NDTR5";
groups = "NDTR5";
---
base-commit: abe651837cb394f76d738a7a747322fca3bf17ba
change-id: 20260611-dtsi_fix-099b11a321b5
Best regards,
--
Ryan Chen <ryan_chen@aspeedtech.com>
^ permalink raw reply related
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Andy Shevchenko @ 2026-06-11 6:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Maxwell Doose, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duszynski
In-Reply-To: <e00caff5-55e4-428f-bc57-3885699b221c@kernel.org>
On Thu, Jun 11, 2026 at 08:37:33AM +0200, Krzysztof Kozlowski wrote:
> On 11/06/2026 00:24, Maxwell Doose wrote:
> > On Wed, Jun 10, 2026 at 4:09 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On Tue, Jun 09, 2026 at 11:03:26AM -0500, Maxwell Doose wrote:
> >>> Tomasz's entry is no longer valid, as he is not active anymore. Add
> >>
> >> Why is not longer valid? I see activity in Feb...
> >
> > Strange. According to git log --author="Tomasz Duszynski" last commit
> > I have from him is 2023. We also did have an RFC open for a month on
> > linux-iio with Tomasz Cced with no response.
>
> So you did not check enough... and no one needs to read RFC :/
Hmm... lore.kernel.org shows last activity November last year (07-11-2025).
What other sources do you suggest to check?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 1/3] dt-bindings: timer: mips,p8700-gcru
From: Krzysztof Kozlowski @ 2026-06-11 6:51 UTC (permalink / raw)
To: aleksa.paunovic, 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,
Chao-ying Fu, Conor Dooley
In-Reply-To: <20260610-riscv-time-mmio-v8-1-a865206675c6@htecgroup.com>
On 10/06/2026 10:22, Aleksa Paunovic via B4 Relay wrote:
> 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>
You keep ignoring reviews you received (14th May!) and sending same mistake.
Can you address the emails?
NAK for this patch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 1/3] dt-bindings: timer: mips,p8700-gcru
From: Krzysztof Kozlowski @ 2026-06-11 6:54 UTC (permalink / raw)
To: aleksa.paunovic, 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,
Chao-ying Fu, Conor Dooley
In-Reply-To: <5e36909c-caf3-4078-b8ec-a77e385d20cf@kernel.org>
On 11/06/2026 08:51, Krzysztof Kozlowski wrote:
> On 10/06/2026 10:22, Aleksa Paunovic via B4 Relay wrote:
>> 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>
>
> You keep ignoring reviews you received (14th May!) and sending same mistake.
>
> Can you address the emails?
>
> NAK for this patch.
Hm, maybe it's b4 relay issue, so here is the report:
https://lore.kernel.org/all/20260514055333.A29B8C2BCB7@smtp.kernel.org/
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Krzysztof Kozlowski @ 2026-06-11 6:58 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Maxwell Doose, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duszynski
In-Reply-To: <aipatjyVcltbspRJ@ashevche-desk.local>
On 11/06/2026 08:50, Andy Shevchenko wrote:
> On Thu, Jun 11, 2026 at 08:37:33AM +0200, Krzysztof Kozlowski wrote:
>> On 11/06/2026 00:24, Maxwell Doose wrote:
>>> On Wed, Jun 10, 2026 at 4:09 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>> On Tue, Jun 09, 2026 at 11:03:26AM -0500, Maxwell Doose wrote:
>>>>> Tomasz's entry is no longer valid, as he is not active anymore. Add
>>>>
>>>> Why is not longer valid? I see activity in Feb...
>>>
>>> Strange. According to git log --author="Tomasz Duszynski" last commit
>>> I have from him is 2023. We also did have an RFC open for a month on
>>> linux-iio with Tomasz Cced with no response.
>>
>> So you did not check enough... and no one needs to read RFC :/
>
> Hmm... lore.kernel.org shows last activity November last year (07-11-2025).
> What other sources do you suggest to check?
No, only lore. As I said, February this year.
https://lore.kernel.org/all/CAObtm8zKUAWNS23nRMhc9ZR-zn7xeVOFPiV4ai_x7Bkd5puiyA@mail.gmail.com/
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: talos: Add passive polling-delay for gpu-thermal zone
From: Haritha S K @ 2026-06-11 7:02 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, manaf.pallikunhi,
gaurav.kohli
In-Reply-To: <20260505-qcs615_gpu_cooling-v2-1-1ba42260b29d@oss.qualcomm.com>
On 05-05-2026 16:56, Haritha S K via B4 Relay wrote:
> From: Haritha S K <haritha.k@oss.qualcomm.com>
>
> Introduce a passive polling delay to ensure more than one
> "passive" thermal point is considered when throttling the GPU
> thermal zone.
>
> Signed-off-by: Haritha S K <haritha.k@oss.qualcomm.com>
> ---
> Changes in v2:
> - Updated commit message.
> - Link to v1: https://patch.msgid.link/20260422-qcs615_gpu_cooling-v1-1-d5a984ac29e3@oss.qualcomm.com
> ---
> arch/arm64/boot/dts/qcom/talos.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
> index ff5afbfce2a4..8a3669b2d062 100644
> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
> @@ -5267,6 +5267,7 @@ cpu-critical {
>
> gpu-thermal {
> thermal-sensors = <&tsens0 9>;
> + polling-delay-passive = <200>;
>
> trips {
> gpu_alert0: trip-point0 {
>
> ---
> base-commit: bee6ea30c48788e18348309f891ed8afbf7702ac
> change-id: 20260422-qcs615_gpu_cooling-39650b7ff41d
>
> Best regards,
> --
> Haritha S K <haritha.k@oss.qualcomm.com>
>
>
Gentle reminder to review this change.
--
Thanks & Regards
Haritha S K
^ permalink raw reply
* RE: [PATCH 3/3] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Paller, Kim Seer @ 2026-06-11 7:04 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Sa, Nuno, Andy Shevchenko, Hennerich, Michael,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux,
devicetree@vger.kernel.org
In-Reply-To: <20260605142428.5cd21b26@jic23-huawei>
> > @@ -445,7 +704,7 @@ static int ad3530r_setup(struct ad3530r_state *st,
> > int external_vref_uV) static const struct regmap_config
> ad3530r_regmap_config = {
> > .reg_bits = 16,
> > .val_bits = 8,
> > - .max_register = AD3530R_MAX_REG_ADDR,
> > + .max_register = AD3532R_MAX_REG_ADDR,
>
> What happens if we read off the end (via debugfs) for the smaller parts?
I tested reading registers at 0x1000 and above on AD3531R it just
returns 0xFF and no crash. Should I add a per-chip regmap_config to limit
the exposed register space?
> > };
> >
> > static const struct iio_info ad3530r_info = { @@ -514,6 +773,8 @@
> > static const struct spi_device_id ad3530r_id[] = {
> > { "ad3530r", (kernel_ulong_t)&ad3530r_chip },
> > { "ad3531", (kernel_ulong_t)&ad3531_chip },
> > { "ad3531r", (kernel_ulong_t)&ad3531r_chip },
> > + { "ad3532", (kernel_ulong_t)&ad3532_chip },
> > + { "ad3532r", (kernel_ulong_t)&ad3532r_chip },
>
> Add a precursor patch to switch this to named initializers. Otherwise this will
> clash with the work Uwe is doing to ensure these are all done that way.
>
> > { }
> > };
> > MODULE_DEVICE_TABLE(spi, ad3530r_id); @@ -523,6 +784,8 @@ static
> > const struct of_device_id ad3530r_of_match[] = {
> > { .compatible = "adi,ad3530r", .data = &ad3530r_chip },
> > { .compatible = "adi,ad3531", .data = &ad3531_chip },
> > { .compatible = "adi,ad3531r", .data = &ad3531r_chip },
> > + { .compatible = "adi,ad3532", .data = &ad3532_chip },
> > + { .compatible = "adi,ad3532r", .data = &ad3532r_chip },
> > { }
> > };
> > MODULE_DEVICE_TABLE(of, ad3530r_of_match);
> >
^ permalink raw reply
* Re: [PATCH 0/2] iio: adc: Add Texas Instruments ADS1220 ADC
From: Andy Shevchenko @ 2026-06-11 7:06 UTC (permalink / raw)
To: Nguyen Minh Tien
Cc: Jonathan Cameron, linux-iio, devicetree, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, David Lechner, Nuno Sá,
Andy Shevchenko, linux-kernel
In-Reply-To: <20260610151342.44274-1-zizuzacker@gmail.com>
On Wed, Jun 10, 2026 at 10:13:40PM +0700, Nguyen Minh Tien wrote:
> This series adds support for the Texas Instruments ADS1220, a 24-bit,
> 2-kSPS, 4-channel delta-sigma ADC with an SPI (mode 1) interface, a
> programmable gain amplifier (1 to 128), an internal 2.048V reference and
> a dedicated DRDY data-ready output.
>
> The driver supports:
> - single-ended and differential voltage channels described as
> device-tree child nodes;
> - per-channel programmable gain (via _scale) and data rate (via
> _sampling_frequency), with the matching *_available attributes;
> - the internal 2.048V reference, an external reference on REFP0/REFN0
> via a regulator, or the analog supply (AVDD) as a ratiometric
> reference for single-supply measurements;
> - single-shot conversions gated on the DRDY interrupt, or on a
> data-rate-derived delay when no interrupt is wired;
> - a DRDY-interrupt-driven triggered buffer for streaming;
> - runtime PM (power-down between conversions).
>
> I tested this on a Lichee Pi Nano (Allwinner F1C100s) running Linux 7.0:
> with a potentiometer on AIN0 (single-ended against AVSS, AVDD as the
> reference), in_voltage0_raw tracks the wiper linearly across the full
> 0..3.3V range (0 to 0x7fffff). Nothing in the driver is board-specific -
> it only uses the SPI and IIO frameworks - so it should work on any SPI
> host.
>
> This is my first kernel contribution. I modelled the driver on the
> existing TI ADS-family IIO drivers - ti-ads1119 for the structure and
> ti-ads124s08 for the SPI side - so I'd welcome any feedback on things
> I've missed.
When adding a brand new driver, answer to the following questions:
- Why a new driver? Can any existed one cover these chips with some refactoring?
- Where to find a datasheet (URL, other means)?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] dt-bindings: vendor-prefixes: add Gira
From: Alexander Dahl @ 2026-06-11 6:57 UTC (permalink / raw)
To: Lucas Stach
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
kernel
In-Reply-To: <20260610213047.500701-1-l.stach@pengutronix.de>
Hello Lucas,
Am Wed, Jun 10, 2026 at 11:30:47PM +0200 schrieb Lucas Stach:
> Add vendor prefix for Gira Giersiepen GmbH & Co. KG
> Link: https://www.gira.de/
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Newline between text and trailers, and no newline in between trailers?
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 28784d66ae7b..2b7bf7d7b9c2 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -656,6 +656,8 @@ patternProperties:
> description: Giantec Semiconductor, Inc.
> "^giantplus,.*":
> description: Giantplus Technology Co., Ltd.
> + "^gira,.*":
> + description: Gira Giersiepen GmbH & Co. KG
Reviewed-by: Alexander Dahl <ada@thorsis.com>
Greets
Alex
> "^glinet,.*":
> description: GL Intelligence, Inc.
> "^globalscale,.*":
> --
> 2.47.3
>
>
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Andy Shevchenko @ 2026-06-11 7:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Maxwell Doose, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duszynski
In-Reply-To: <6c5a657b-f316-4982-8cb8-8c09f1b1669a@kernel.org>
On Thu, Jun 11, 2026 at 08:58:47AM +0200, Krzysztof Kozlowski wrote:
> On 11/06/2026 08:50, Andy Shevchenko wrote:
> > On Thu, Jun 11, 2026 at 08:37:33AM +0200, Krzysztof Kozlowski wrote:
> >> On 11/06/2026 00:24, Maxwell Doose wrote:
> >>> On Wed, Jun 10, 2026 at 4:09 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>> On Tue, Jun 09, 2026 at 11:03:26AM -0500, Maxwell Doose wrote:
> >>>>> Tomasz's entry is no longer valid, as he is not active anymore. Add
> >>>>
> >>>> Why is not longer valid? I see activity in Feb...
> >>>
> >>> Strange. According to git log --author="Tomasz Duszynski" last commit
> >>> I have from him is 2023. We also did have an RFC open for a month on
> >>> linux-iio with Tomasz Cced with no response.
> >>
> >> So you did not check enough... and no one needs to read RFC :/
> >
> > Hmm... lore.kernel.org shows last activity November last year (07-11-2025).
> > What other sources do you suggest to check?
>
> No, only lore.
I used this request:
https://lore.kernel.org/all/?q=f%3A%22Tomasz+Duszynski%22
> As I said, February this year.
>
> https://lore.kernel.org/all/CAObtm8zKUAWNS23nRMhc9ZR-zn7xeVOFPiV4ai_x7Bkd5puiyA@mail.gmail.com/
Okay, you used UTF-8 name, Where did you get it from? MAINTAINERS has no
diacritics.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Andy Shevchenko @ 2026-06-11 7:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Maxwell Doose, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duszynski
In-Reply-To: <aipfPwT4RJGdA4TT@ashevche-desk.local>
On Thu, Jun 11, 2026 at 10:09:57AM +0300, Andy Shevchenko wrote:
> On Thu, Jun 11, 2026 at 08:58:47AM +0200, Krzysztof Kozlowski wrote:
> > On 11/06/2026 08:50, Andy Shevchenko wrote:
> > > On Thu, Jun 11, 2026 at 08:37:33AM +0200, Krzysztof Kozlowski wrote:
> > >> On 11/06/2026 00:24, Maxwell Doose wrote:
> > >>> On Wed, Jun 10, 2026 at 4:09 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >>>> On Tue, Jun 09, 2026 at 11:03:26AM -0500, Maxwell Doose wrote:
> > >>>>> Tomasz's entry is no longer valid, as he is not active anymore. Add
> > >>>>
> > >>>> Why is not longer valid? I see activity in Feb...
> > >>>
> > >>> Strange. According to git log --author="Tomasz Duszynski" last commit
> > >>> I have from him is 2023. We also did have an RFC open for a month on
> > >>> linux-iio with Tomasz Cced with no response.
> > >>
> > >> So you did not check enough... and no one needs to read RFC :/
> > >
> > > Hmm... lore.kernel.org shows last activity November last year (07-11-2025).
> > > What other sources do you suggest to check?
> >
> > No, only lore.
>
> I used this request:
> https://lore.kernel.org/all/?q=f%3A%22Tomasz+Duszynski%22
>
> > As I said, February this year.
> >
> > https://lore.kernel.org/all/CAObtm8zKUAWNS23nRMhc9ZR-zn7xeVOFPiV4ai_x7Bkd5puiyA@mail.gmail.com/
>
> Okay, you used UTF-8 name, Where did you get it from? MAINTAINERS has no
> diacritics.
OTOH, you may have used simply email approach. With
https://lore.kernel.org/all/?q=f%3Atduszyns%40gmail.com
I got it as well.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9 0/3] Add EcoNet EN7528 (and EN751221) PCIe support.
From: Manivannan Sadhasivam @ 2026-06-11 7:12 UTC (permalink / raw)
To: Caleb James DeLisle
Cc: linux-pci, linux-mips, naseefkm, ryder.lee, helgaas, lpieralisi,
kwilczynski, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, ansuelsmth, linux-mediatek, devicetree,
linux-kernel
In-Reply-To: <20260521171951.1495781-1-cjd@cjdns.fr>
On Thu, May 21, 2026 at 05:19:48PM +0000, Caleb James DeLisle wrote:
> Tested on TpLink Archer VR1200V-V2 (EN751221 with Gen2 device)
>
> Changes since v8:
> * guard(rwsem_read)(&pci_bus_sem); in mtk_pcie_retrain
> * v8: https://lore.kernel.org/linux-mips/20260520183827.908243-1-cjd@cjdns.fr
>
> Changes from v7:
> * mtk_pcie_retrain retrain all root ports not just first
> * Include fix from Manivannan Sadhasivam, wrong usage of virt_to_phys()
> * v7: https://lore.kernel.org/linux-mips/20260514151318.3444959-1-cjd@cjdns.fr
>
> Changes from v6:
> * s/reset/resets/ in .yaml
> * s/re-train/retrain/g
> * s/Root bridge/Root port/
> * If module not builtin, log at mtk_pcie_startup_port_en7528()
> * Do not fail if error in mtk_pcie_retrain()
> * v6: https://lore.kernel.org/linux-mips/20260513191652.3200607-1-cjd@cjdns.fr
>
> Changes from v5:
> * s/errno-base.h/errno.h/
> * Breakout mtk_pcie_retrain() into a function
> * Use for_each_pci_bridge() to find root bridge
> * v5: https://lore.kernel.org/linux-mips/20260413140339.16238-1-cjd@cjdns.fr/
>
> Changes from v4:
> * Fixed missing Acked-by
> * Rebased to commit 66672af7a095 ("Add linux-next specific files for 20260410")
> * v4: https://lore.kernel.org/linux-mips/20260404182854.2183651-1-cjd@cjdns.fr/
>
> Changes from v3:
> * s/initiallized/initialized/
> * Use PCIE_T_PVPERL_MS for sleep time
> * Use PCI_PM_D3COLD_WAIT for startup wait time
> * Clarify comment "Activate INTx interrupts"
> * Add MTK_PCIE_RETRAIN quirk for devices which require link re-train
> * Do not retrain *all* bridges, only root bridge
> * Better comments and logging in retraining logic
> * v3: https://lore.kernel.org/linux-mips/20260320094212.696671-1-cjd@cjdns.fr/
>
> Changes from v2:
> * mediatek-pcie.yaml -> s/power-domain/power-domains/ and drop example
> * Patch 3 dropped as it has been applied (Thanks!)
> * v2: https://lore.kernel.org/linux-mips/20260316155157.679533-1-cjd@cjdns.fr/
>
> Changes from v1:
> * mediatek-pcie.yaml slot0 needs device-type = "pci", fix dt_binding_check
> Link: https://lore.kernel.org/linux-mips/177334026016.3889069.9474337544951486443.robh@kernel.org
> * v1: https://lore.kernel.org/linux-mips/20260312165332.569772-1-cjd@cjdns.fr/
>
> This was split from a larger PCIe patchset which crossed multiple
> subsystems. I'm not labeling this a v3 because it's a new patchset, but
> I'm keeping the historical record anyway.
>
> Changes from econet-pcie v2:
> * mediatek-pcie.yaml add missing constraints to PCI node properties
> * econet-pcie v2: https://lore.kernel.org/linux-mips/20260309131818.74467-1-cjd@cjdns.fr
>
> Changes from econet-pcie v1:
> * pcie-mediatek.c Exclude pcie_retrain_link() when building as a module
> * econet-pcie v1: https://lore.kernel.org/linux-mips/20260303190948.694783-1-cjd@cjdns.fr/
>
>
> Caleb James DeLisle (2):
> dt-bindings: PCI: mediatek: Add support for EcoNet EN7528
> PCI: mediatek: Add support for EcoNet EN7528 SoC
Patch 3 doesn't apply cleanly. So I applied patches 1 and 2. Please rebase patch
3 on top of pci/controller/mediatek branch and resend it.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] dt-bindings: mailbox: qcom: Add IPCC support for Maili Platform
From: Manivannan Sadhasivam @ 2026-06-11 7:19 UTC (permalink / raw)
To: Chunkai Deng
Cc: Bjorn Andersson, Jassi Brar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, yijie.yang, Jingyi Wang, Vishnu Santhosh,
Deepak Kumar Singh, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260526-mailbox-qcom-maili-v1-1-1b689a42f33e@oss.qualcomm.com>
On Tue, May 26, 2026 at 11:38:03AM +0800, Chunkai Deng wrote:
> Document the Inter-Processor Communication Controller on the Qualcomm
> Maili Platform, which will be used to route interrupts across various
> subsystems found on the SoC.
>
> Signed-off-by: Chunkai Deng <chunkai.deng@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> index f5c584cf2146..4b69a281971a 100644
> --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml
> @@ -27,6 +27,7 @@ properties:
> - qcom,eliza-ipcc
> - qcom,glymur-ipcc
> - qcom,kaanapali-ipcc
> + - qcom,maili-ipcc
> - qcom,milos-ipcc
> - qcom,qcs8300-ipcc
> - qcom,qdu1000-ipcc
>
> ---
> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> change-id: 20260512-mailbox-qcom-maili-7c5cce6e672f
>
> Best regards,
> --
> Chunkai Deng <chunkai.deng@oss.qualcomm.com>
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 37/37] arm64: dts: qcom: msm8996: Move PCIe phy and GPIOs to root port node
From: sashiko-bot @ 2026-06-11 7:24 UTC (permalink / raw)
To: Krishna Chaitanya Chundru; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260611-wake-v2-37-2744251b1181@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message claims to move both the 'phys' and 'phy-names' properties to the root port nodes, but the patch actually deletes 'phy-names' entirely.
--
commit baa70baca6b8bb3dd12472bf021f252ebb1f4c9c
Author: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
arm64: dts: qcom: msm8996: Move PCIe phy and GPIOs to root port node
This patch moves the PCIe phy reference and GPIO properties to the root port
node from the RC controller node. It adjusts the device tree nodes and adds
labels to allow board-level overrides for the root port context.
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 2f67e665996f3..8db1448e5e610 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -1900,9 +1900,6 @@ pcie0: pcie@600000 {
> <0x0c100000 0x100000>;
> reg-names = "parf", "dbi", "elbi","config";
>
> - phys = <&pciephy_0>;
> - phy-names = "pciephy";
> -
> #address-cells = <3>;
> #size-cells = <2>;
> ranges = <0x01000000 0x0 0x00000000 0x0c200000 0x0 0x100000>,
[ ... ]
> @@ -1951,7 +1948,7 @@ pcie0: pcie@600000 {
> "bus_master",
> "bus_slave";
>
> - pcie@0 {
> + pcie0_port0: pcie@0 {
> device_type = "pci";
> reg = <0x0 0x0 0x0 0x0 0x0>;
> bus-range = <0x01 0xff>;
> @@ -1959,6 +1956,8 @@ pcie@0 {
> #address-cells = <3>;
> #size-cells = <2>;
> ranges;
> +
> + phys = <&pciephy_0>;
> };
[Severity: Medium]
The commit message states "Move phys and phy-names from the controller to
pcie0_port0, pcie1_port0, and pcie2_port0".
However, looking at the removal in pcie0 and the addition in pcie0_port0, it
appears phy-names was deleted but not added to the new port nodes. The same
pattern is present for pcie1_port0 and pcie2_port0.
Is the intention to drop the phy-names property completely because it is no
longer needed by the new bindings? If so, could the commit message be
updated to reflect that phy-names was removed rather than moved?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-wake-v2-0-2744251b1181@oss.qualcomm.com?part=37
^ permalink raw reply
* Re: [PATCH v6 5/6] remoteproc: qcom: pas: Add late attach support for subsystems
From: Mukesh Ojha @ 2026-06-11 7:33 UTC (permalink / raw)
To: Jingyi Wang
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Sibi Sankar, Konrad Dybcio,
shengchao.guo, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Gokul Krishna Krishnakumar
In-Reply-To: <88c161d6-caa3-4fff-afaf-d10cacfe9929@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 11:11:59AM +0800, Jingyi Wang wrote:
>
>
> On 5/21/2026 7:22 PM, Mukesh Ojha wrote:
> > On Thu, May 21, 2026 at 11:42:49AM +0800, Jingyi Wang wrote:
> > >
> > >
> > > On 5/20/2026 4:27 PM, Mukesh Ojha wrote:
> > > > On Tue, May 19, 2026 at 12:24:23AM -0700, Jingyi Wang wrote:
> > > > > Subsystems can be brought out of reset by entities such as bootloaders.
> > > > > As the irq enablement could be later than subsystem bring up, the state
> > > > > of subsystem should be checked by reading SMP2P bits.
> > > > >
> > > > > A new qcom_pas_attach() function is introduced. if a crash state is
> > > > > detected for the subsystem, rproc_report_crash() is called. If the ready
> > > > > state is detected, it will be marked as "attached", otherwise it could
> > > > > be the early boot feature is not supported by other entities. In this
> > > > > case, the state will be marked as RPROC_OFFLINE so that the PAS driver
> > > > > can load the firmware and start the remoteproc.
> > > > >
> > > > > Co-developed-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
> > > > > Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
> > > > > Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> > > > > ---
> > > > > drivers/remoteproc/qcom_q6v5_pas.c | 58 ++++++++++++++++++++++++++++++++++++++
> > > > > 1 file changed, 58 insertions(+)
> > > > >
> > > > > diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> > > > > index da27d1d3c9da..ac2a00aacd2e 100644
> > > > > --- a/drivers/remoteproc/qcom_q6v5_pas.c
> > > > > +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> > > > > @@ -60,6 +60,7 @@ struct qcom_pas_data {
> > > > > int region_assign_count;
> > > > > bool region_assign_shared;
> > > > > int region_assign_vmid;
> > > > > + bool early_boot;
> > > > > };
> > > > > struct qcom_pas {
> > > > > @@ -510,6 +511,57 @@ static unsigned long qcom_pas_panic(struct rproc *rproc)
> > > > > return qcom_q6v5_panic(&pas->q6v5);
> > > > > }
> > > > > +static int qcom_pas_attach(struct rproc *rproc)
> > > > > +{
> > > > > + int ret;
> > > > > + struct qcom_pas *pas = rproc->priv;
> > > > > + bool ready_state;
> > > > > + bool crash_state;
> > > > > +
> > > > > + pas->q6v5.handover_issued = true;
> > > > > + enable_irq(pas->q6v5.handover_irq);
> > > > > +
> > > > > + pas->q6v5.running = true;
> > > > > + ret = irq_get_irqchip_state(pas->q6v5.fatal_irq,
> > > > > + IRQCHIP_STATE_LINE_LEVEL, &crash_state);
> > > > > +
> > > > > + if (ret)
> > > > > + goto disable_running;
> > > > > +
> > > > > + if (crash_state) {
> > > > > + dev_err(pas->dev, "Subsystem has crashed before driver probe\n");
> > > > > + rproc_report_crash(rproc, RPROC_FATAL_ERROR);
> > > >
> > > > I am not sure if this is already discussed, but what if it is the first
> > > > crash with recovery and coredump enabled? What would be in the dump,
> > > > nothing? As there is no segment, is it expected since Linux did not load
> > > > this?
> > > >
> > > > This is even true if it is a crash after a successful attach.
> > > >
> > >
> > > It is suggested by Bjorn:
> > > https://lore.kernel.org/all/qfls6xlvfppqw7p6rjpmzqesh6sbob4myfc6dz47qh3jywqrjk@5xiutkbybk5d/
> > >
> > > I did a hack to test the recovery by setting crash_state true, it can recovery
> > > (stop and start) successfully with below patches:
> > > https://lore.kernel.org/all/20260519-rproc-attach-issue-v2-0-caa1eaf75081@oss.qualcomm.com/
> > >
> > > For coredump, it will return from the first "list_empty(&rproc->dump_segments)" check in
> > > rproc_coredump as segments are not configured in attach.
> >
> >
> > I was not against any of the stuff, but mostly checking, if we agreed on not collecting dump
> > for first crash when soccp minidump is not initialized which falls back to full dump of the soccp.
> > I see soccp minidump id in the downstream but we have not added in 6/6.
> >
>
> Hi Mukesh,
>
> I prefer to add base rproc attach feature only in this patch and skipping the coredump in attach
> workflow.
Should be fine..
>
> Thanks,
> Jingyi
>
> > >
> > > Thanks,
> > > Jingyi
> > >
> > >
> > > > @Sibi, has this series been tested on Glymur with KVM?
> > > > I don't see the iommu property in the below patch.
> > > > https://lore.kernel.org/lkml/20260403-glymur-soccp-v3-1-f0e8d57f11ba@oss.qualcomm.com/
> > > >
> > >
> >
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH V11 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Andy Shevchenko @ 2026-06-11 7:35 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
Chris Morgan
In-Reply-To: <20260610175455.19006-4-macroalpha82@gmail.com>
On Wed, Jun 10, 2026 at 12:54:47PM -0500, Chris Morgan wrote:
> Add the core component of a new inv_icm42607 driver. This includes
> a few setup functions and the full register definition in the
> header file.
...
> 2 files changed, 531 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
I'm not sure this is correct split by files. These files are not:
- being build
- being mentioned in MAINTAINERS
...
> +#ifndef INV_ICM42607_H_
> +#define INV_ICM42607_H_
> +
> +#include <linux/bits.h>
> +#include <linux/iio/iio.h>
> +#include <linux/mutex.h>
mutex_types.h ?
> +#include <linux/regmap.h>
> +#include <linux/types.h>
Do you need forward declaration for regulator data type?
...
> +#define INV_ICM42607_POWER_UP_TIME_US 100000
100 * USEC_PER_MSEC (will require time.h)?
...
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
+ bitfields.h
> +#include <linux/delay.h>
> +#include <linux/dev_printk.h>
+ device/devres.h
+ err.h
> +#include <linux/iio/iio.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/time.h>
Also check if you need types.h.
...
> + fsleep(INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC);
> +
> + /*
> + * No polling interval specified in datasheet, so use reset time as
> + * polling interval and 10x reset time as timeout period.
> + */
> + ret = regmap_read_poll_timeout(st->map, INV_ICM42607_REG_INT_STATUS,
> + val, val & INV_ICM42607_INT_STATUS_RESET_DONE,
> + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC),
> + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC * 10));
Besides too many parentheses, this can be switched to regular patter of "num * what".
Also, TBH, the plain values would be better here
fsleep(1 * USEC_PER_MSEC);
/*
* No polling interval specified in datasheet, so use reset time as
* polling interval and 10x reset time as timeout period.
*/
ret = regmap_read_poll_timeout(st->map, INV_ICM42607_REG_INT_STATUS,
val, val & INV_ICM42607_INT_STATUS_RESET_DONE,
1 * USEC_PER_MSEC, 10 * USEC_PER_MSEC);
And in the similar way in other fsleep() / _read_poll_timeout() cases.
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "reset error, reset done bit not set\n");
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 1/3] dt-bindings: timer: mips,p8700-gcru
From: Aleksa Paunovic @ 2026-06-11 7:39 UTC (permalink / raw)
To: krzk@kernel.org
Cc: Aleksa Paunovic, alex@ghiti.fr, aou@eecs.berkeley.edu,
cfu@mips.com, conor+dt@kernel.org, conor.dooley@microchip.com,
daniel.lezcano@linaro.org, devicetree@vger.kernel.org,
Djordje Todorovic, jstultz@google.com, krzk+dt@kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
palmer@dabbelt.com, paul.walmsley@sifive.com, pjw@kernel.org,
robh@kernel.org, sboyd@kernel.org, tglx@linutronix.de,
wangruikang@iscas.ac.cn
In-Reply-To: <eda67f3d-9395-4386-9311-d6f6b1c62304@kernel.org>
Hi Krzysztof,
On 6/11/26 08:54, Krzysztof Kozlowski wrote:
> On 11/06/2026 08:51, Krzysztof Kozlowski wrote:
>> On 10/06/2026 10:22, Aleksa Paunovic via B4 Relay wrote:
>>> 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>
>> You keep ignoring reviews you received (14th May!) and sending same mistake.
>>
>> Can you address the emails?
I wasn't really sure what the etiquette was for replying to Sashiko reviews, so I decided to
address the comments for other patches and send a v8 without replying.
As for this patch, the GCR.U itself does start at 0x7F000, but the first
actual register (mtime) is at 0x7F050 [1].
I'm not seeing any warnings when running dt_binding_check.
>>
>> NAK for this patch.
> Hm, maybe it's b4 relay issue, so here is the report:
>
> https://lore.kernel.org/all/20260514055333.A29B8C2BCB7@smtp.kernel.org/
>
It did take a while but I noticed the comments.
Will have to check more regularly in the future.
Best regards,
Aleksa
[1] https://mips.com/wp-content/uploads/2026/03/MIPS_P8700_P8700-F_Programmers_Reference_Guide_Rev1.86_2-17-2026.pdf#G7.1528502
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: interrupt-controller: ti,irq-crossbar: Convert to DT schema
From: Bhargav Joshi @ 2026-06-11 7:39 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Sricharan R,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, devicetree, linux-kernel, linux-omap, goledhruva,
m-chawdhry, daniel.baluta, simona.toaca
In-Reply-To: <CAL_Jsq+G83JxXLCL+4jhjTsTKpDSqNde=X2Yzjsg+VSS2iGxtw@mail.gmail.com>
Hi,
On Thu, Jun 11, 2026 at 4:32 AM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Jun 10, 2026 at 4:12 PM Bhargav Joshi <j.bhargav.u@gmail.com> wrote:
> >
> > Hi,
> >
> > On Thu, Jun 11, 2026 at 1:27 AM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Sat, Jun 06, 2026 at 02:26:10AM +0530, Bhargav Joshi wrote:
> > > > Convert TI irq-crossbar binding from text format to DT schema.
> > > >
> > > > As part of conversion following changes are made:
> > > > - Add '#interrupt-cells' as a required property which was missing in
> > > > text binding
> > > > - As irq-crossbar is interrupt-controller. Move binding from
> > > > bindings/arm/omap to bindings/interrupt-controller
> > > > - property ti,irqs-reserved is defined and used as a array but other
> > > > binding ti,pruss-intc.yaml uses same property name as a unit8 bitmask
> > > > which causes erros in dt_binding_check. Update ti,irqs-reserved
> > > > property name to ti,crossbar-irqs-reserved to resolve duplicate naming.
> > >
> > > Defining a new property breaks the ABI. We will need to fix dtschema to
> > > handle it. What's the error?
> > property irqs-reserved is defined in two bindings with different types which
> > causes dt_binding_check to raise following errors:
> > - File "/lib/python3.14/site-packages/dtschema/validator.py", line
> > 522, in check_duplicate_property_types
> > - print(f"{self.schemas[sch_id]['$filename']}: {p}: multiple
> > incompatible types: {v['type']}", file=sys.stderr)
> > - KeyError: 'http://devicetree.org/schemas/interrupt-controller/ti,pruss-intc.yaml#'
> > dtschema version: 2026.4
>
> I pushed a change to dtschema main branch which should fix this.
Thanks, error resolved on 2026.5.dev11+g0d16008e3 , I'll send v2 without the
property name change.
>
> Rob
Best Regards,
Bhargav
^ permalink raw reply
* Re: [PATCH v3 0/3] media: i2c: Add os02g10 camera sensor driver
From: Elgin Perumbilly @ 2026-06-11 7:39 UTC (permalink / raw)
To: sakari.ailus@linux.intel.com, laurent.pinchart@ideasonboard.com
Cc: Tarang Raval, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, Hans de Goede,
Vladimir Zapolskiy, Mehdi Djait, Benjamin Mugnier,
Sylvain Petinot, Bryan O'Donoghue, Heimir Thor Sverrisson,
Hardevsinh Palaniya, Himanshu Bhavani, Svyatoslav Ryhel,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260424092554.26130-1-elgin.perumbilly@siliconsignals.io>
Hi Laurent, Sakari
> The following features are supported:
> - Manual exposure an gain control support.
> - vblank/hblank control support.
> - vflip/hflip control support
> - Test pattern control support.
> - Dynamic mode configuration (e.g. up to 1920 x 1080 @ 30 fps, SBGGR10)
>
> The driver is tested on mainline branch v7.0-rc2 on IMX8MP Debix Model a.
Could you please review the driver now ??
Best Regards,
Elgin
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Krzysztof Kozlowski @ 2026-06-11 7:40 UTC (permalink / raw)
To: joakim.zhang
Cc: mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt, p.zabel,
gary.yang, cix-kernel-upstream, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260610075645.3581145-2-joakim.zhang@cixtech.com>
On Wed, Jun 10, 2026 at 03:56:41PM +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> The Cix Sky1 Audio Subsystem (AUDSS) groups audio-related clock, reset
> and control registers in a dedicated CRU block. Software reset lines are
> exposed on the syscon parent via #reset-cells, following the same model
> as the existing Sky1 FCH and S5 system control bindings.
>
> Add the cix,sky1-audss-system-control compatible to
> cix,sky1-system-control.yaml for the MFD/syscon parent node, and define
> AUDSS software reset indices in
> include/dt-bindings/reset/cix,sky1-audss-system-control.h for I2S, HDA,
> DMAC, mailbox, watchdog and timer blocks.
All this is pretty pointless - you explained the binding, which answers
nothing why you did it that way. Instead you must explain the hardware
design.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> ---
> .../soc/cix/cix,sky1-system-control.yaml | 52 +++++++++++++++++--
> .../reset/cix,sky1-audss-system-control.h | 25 +++++++++
> 2 files changed, 72 insertions(+), 5 deletions(-)
> create mode 100644 include/dt-bindings/reset/cix,sky1-audss-system-control.h
>
> diff --git a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
> index a01a515222c6..61d26a69fd44 100644
> --- a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
> +++ b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
> @@ -15,11 +15,16 @@ description:
>
> properties:
> compatible:
> - items:
> - - enum:
> - - cix,sky1-system-control
> - - cix,sky1-s5-system-control
> - - const: syscon
> + oneOf:
> + - items:
> + - enum:
> + - cix,sky1-system-control
> + - cix,sky1-s5-system-control
> + - const: syscon
> + - items:
> + - const: cix,sky1-audss-system-control
> + - const: simple-mfd
Just so you are aware - this means children do not depend on the parent
for operation. You will not be able to fix it later, if it turns out
that children do depend...
> + - const: syscon
>
> reg:
> maxItems: 1
> @@ -27,6 +32,28 @@ properties:
> '#reset-cells':
> const: 1
>
> + clock-controller:
> + type: object
> + properties:
> + compatible:
> + const: cix,sky1-audss-clock
> + required:
> + - compatible
> + additionalProperties: true
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: cix,sky1-audss-system-control
> + then:
> + required:
> + - clock-controller
> + else:
> + properties:
> + clock-controller: false
> +
> required:
> - compatible
> - reg
> @@ -40,3 +67,18 @@ examples:
> reg = <0x4160000 0x100>;
> #reset-cells = <1>;
> };
> + - |
> + audss_syscon: system-controller@7110000 {
> + compatible = "cix,sky1-audss-system-control", "simple-mfd", "syscon";
> + reg = <0x7110000 0x10000>;
> + #reset-cells = <1>;
> +
> + clock-controller {
> + compatible = "cix,sky1-audss-clock";
> + power-domains = <&smc_devpd 0>;
My questions from v2 from the other patch are still valid - why audss
system clock controller is outside of the power domain? Why the audss
reset is outside, but audss clock not?
This does not feel like correct hardware representation.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: nvmem: consumer: Make 'nvmem' an array of one-item entries
From: Konrad Dybcio @ 2026-06-11 7:41 UTC (permalink / raw)
To: Rob Herring (Arm), Konrad Dybcio
Cc: Conor Dooley, linux-kernel, Srinivas Kandagatla,
Krzysztof Kozlowski, devicetree
In-Reply-To: <178111967044.674793.5974554745587773283.robh@kernel.org>
On 6/10/26 9:28 PM, Rob Herring (Arm) wrote:
>
> On Wed, 10 Jun 2026 14:52:42 +0200, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> 'nvmem' unlike 'nvmem-cells', consumes references to just a single
>> phandle with no arguments (i.e. with 0 cells).
>>
>> Constrain the schema to enforce that, so that the number of such
>> single-item entries can then be regulated by IP block-specific YAMLs.
>>
>> Suggested-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> ---
>> qcom/qcs6490-rb3gen2.dtb: pmic@2 (qcom,pm8350c): pwm:nvmem: [[397, 398]] is too short
>> from schema $id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml
>> qcom/qcs6490-rb3gen2.dtb: pwm (qcom,pm8350c-pwm): nvmem: [[397, 398]] is too short
>> from schema $id: http://devicetree.org/schemas/leds/leds-qcom-lpg.yaml
>> ---
>> Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>
> Given we're close to the merge window I applied so it goes into 7.2.
Thanks!
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Krzysztof Kozlowski @ 2026-06-11 7:41 UTC (permalink / raw)
To: Joakim Zhang, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, p.zabel@pengutronix.de, Gary Yang
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <SEYPR06MB622688915CBD1AA9B65FFB33821D2@SEYPR06MB6226.apcprd06.prod.outlook.com>
On 09/06/2026 08:27, Joakim Zhang wrote:
>
> Hi Krzysztof,
>
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: Friday, June 5, 2026 5:24 PM
>> To: Joakim Zhang <joakim.zhang@cixtech.com>; mturquette@baylibre.com;
>> sboyd@kernel.org; bmasney@redhat.com; robh@kernel.org;
>> krzk+dt@kernel.org; conor+dt@kernel.org; p.zabel@pengutronix.de; Gary Yang
>> <gary.yang@cixtech.com>
>> Cc: cix-kernel-upstream <cix-kernel-upstream@cixtech.com>; linux-
>> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
>> linux-arm-kernel@lists.infradead.org
>> Subject: Re: [PATCH v2 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
>> clock controller
>>
>> EXTERNAL EMAIL
>>
>> On 05/06/2026 05:22, joakim.zhang@cixtech.com wrote:
>>> +description: |
>>> + Clock provider for the Cix Sky1 audio subsystem (AUDSS).
>>> +
>>> + This node is a child of a cix,sky1-audss-system-control MFD/syscon
>>> + node (see cix,sky1-system-control.yaml). It does not have a reg
>>> + property; clock mux, divider and gate fields are accessed through the parent
>> register block.
>>> +
>>> + Software reset lines for AUDSS blocks are exposed on the parent
>>> + syscon via #reset-cells. Reset indices are defined in
>>> + include/dt-bindings/reset/cix,sky1-audss-system-control.h.
>>> +
>>> + Six SoC-level reference clocks listed in clocks/clock-names feed
>>> + the AUDSS clock tree. The provider exposes the internal AUDSS
>>> + clocks to other devices via #clock-cells; indices are defined in cix,sky1-
>> audss.h.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: cix,sky1-audss-clock
>>> +
>>> + '#clock-cells':
>>> + const: 1
>>> + description:
>>> + Clock indices are defined in include/dt-bindings/clock/cix,sky1-audss.h.
>>> +
>>> + clocks:
>>> + minItems: 6
>>
>> Drop
> OK
>
>>> + maxItems: 6
>>> + description:
>>> + Six SoC-level audio reference clocks that feed the audio subsystem,
>>> + in the same order as clock-names.
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: audio_clk0
>>> + - const: audio_clk1
>>> + - const: audio_clk2
>>> + - const: audio_clk3
>>> + - const: audio_clk4
>>> + - const: audio_clk5
>>
>> Pretty pointless names. Names matching indexes have no benefits, drop all of
>> them and instead list items in "clocks" with description.
> Yes, you are right, I will describe these more meaningful.
>
>>> +
>>> + resets:
>>> + maxItems: 1
>>> + description: Audio subsystem NoC (or bus) reset line.
>>> +
>>> + power-domains:
>>> + maxItems: 1
>>> + description: Audio subsystem power domain.
>>
>> So the clock part has power domain but reset part does not? This is odd.
>> Especially that parent is audss (right?) and here you describe that this is audss
>> poer domain.
>>
>> Same question about resets.
>
> The reset and power domain takes effect on the entire subsystem, i.e., audss can be accessed only after powered on and reset released, including the CRU registers which contains clock/reset/control bits for all device within the audss.
>
> Because the reset controller probe does not access the hardware, while the clock controller does, so at that time, the power domain and reset were placed in the clock driver. At present, it does not seem very reasonable either.
>
> Linking the "reset" and "power domain" to the parent node requires us to ensure the order of the probes. We need to perform deferred probes within the child nodes until the parent node has been probed.
>
Please wrap your replies.
You refer here to probe, so driver design, but I did not ask about that.
I asked about hardware design.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Krzysztof Kozlowski @ 2026-06-11 7:42 UTC (permalink / raw)
To: joakim.zhang
Cc: mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt, p.zabel,
gary.yang, cix-kernel-upstream, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260610075645.3581145-4-joakim.zhang@cixtech.com>
On Wed, Jun 10, 2026 at 03:56:43PM +0800, joakim.zhang@cixtech.com wrote:
> + '#clock-cells':
> + const: 1
> + description:
> + Clock indices are defined in include/dt-bindings/clock/cix,sky1-audss.h.
> +
> + clocks:
> + items:
> + - description: I2S parent clock for sampling rates multiple of 8kHz.
> + - description: I2S parent clock for sampling rates multiple of 11.025kHz.
> + - description: clock feeding most devices in audss (NOC, DSP, SRAM, HDA, DMAC, I2S, and Mailbox).
> + - description: clock feeding for HDA, Timer and Watchdog, which is a delicated 48MHz clock.
> +
> + clock-names:
> + items:
> + - const: x8k
> + - const: x11k
> + - const: sys
> + - const: 48m
> +
> + resets:
> + maxItems: 1
> + description: Audio subsystem NoC (or bus) reset line.
> +
> + power-domains:
> + maxItems: 1
> + description: Audio subsystem power domain.
Same comments as last time, but let's keep discussion in previous patch.
> +
> +required:
> + - compatible
> + - '#clock-cells'
> + - clocks
> + - clock-names
> + - resets
> + - power-domains
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/cix,sky1.h>
> +
> + clock-controller {
> + compatible = "cix,sky1-audss-clock";
> + power-domains = <&smc_devpd 0>;
> + #clock-cells = <1>;
> + clocks = <&scmi_clk CLK_TREE_AUDIO_CLK0>, <&scmi_clk CLK_TREE_AUDIO_CLK2>,
> + <&scmi_clk CLK_TREE_AUDIO_CLK4>, <&scmi_clk CLK_TREE_AUDIO_CLK5>;
> + clock-names = "x8k", "x11k", "sys", "48m";
> + resets = <&s5_syscon 31>;
> + };
> diff --git a/include/dt-bindings/clock/cix,sky1-audss.h b/include/dt-bindings/clock/cix,sky1-audss.h
> new file mode 100644
> index 000000000000..033046407dee
> --- /dev/null
> +++ b/include/dt-bindings/clock/cix,sky1-audss.h
Filename must match the compatible.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
From: Ziming Zhu @ 2026-06-11 7:43 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
In-Reply-To: <20260611074335.4415-1-zmzhu0630@163.com>
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>
---
.../bindings/hwmon/pmbus/silergy,sq24860.yaml | 74 +++++++++++++++++++
1 file changed, 74 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
new file mode 100644
index 000000000000..03ef82c11e1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/silergy,sq24860.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silergy SQ24860 eFuse
+
+maintainers:
+ - Ziming Zhu <ziming.zhu@silergycorp.com>
+
+description:
+ The Silergy SQ24860 is an integrated, high-current circuit protection and
+ power management device with PMBus interface.
+
+properties:
+ compatible:
+ const: silergy,sq24860
+
+ reg:
+ maxItems: 1
+
+ silergy,rimon-micro-ohms:
+ description:
+ Micro-ohms value of the resistance installed between the IMON pin and
+ the ground reference.
+
+ interrupts:
+ description: PMBus SMBAlert interrupt.
+ maxItems: 1
+
+ regulators:
+ type: object
+ description:
+ List of regulators provided by this controller.
+
+ properties:
+ vout:
+ $ref: /schemas/regulator/regulator.yaml#
+ type: object
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - silergy,rimon-micro-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hw-monitor@40 {
+ compatible = "silergy,sq24860";
+ reg = <0x40>;
+
+ interrupt-parent = <&gpio>;
+ interrupts = <42 8>;
+ silergy,rimon-micro-ohms = <1600000000>;
+
+ regulators {
+ cpu0_vout: vout {
+ regulator-name = "main_cpu0";
+ };
+ };
+ };
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v3 3/3] hwmon: Add documentation for SQ24860
From: Ziming Zhu @ 2026-06-11 7:43 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
In-Reply-To: <20260611074335.4415-1-zmzhu0630@163.com>
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>
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/sq24860.rst | 96 +++++++++++++++++++++++++++++++++
2 files changed, 97 insertions(+)
create mode 100644 Documentation/hwmon/sq24860.rst
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 8b655e5d6b68..6184b88e2095 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -243,6 +243,7 @@ Hardware Monitoring Kernel Drivers
smsc47m1
sparx5-temp
spd5118
+ sq24860
stpddc60
surface_fan
sy7636a-hwmon
diff --git a/Documentation/hwmon/sq24860.rst b/Documentation/hwmon/sq24860.rst
new file mode 100644
index 000000000000..f0182b955d8a
--- /dev/null
+++ b/Documentation/hwmon/sq24860.rst
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver sq24860
+=====================
+
+Supported chips:
+
+ * Silergy SQ24860
+
+ Prefix: 'sq24860'
+
+Author:
+
+ Ziming Zhu <ziming.zhu@silergycorp.com>
+
+Description
+------------
+
+This driver implements support for the Silergy SQ24860 eFuse. The device is an
+integrated circuit protection and power management device with a PMBus
+interface.
+
+The device supports direct format for reading input voltage, output voltage,
+auxiliary voltage, input current, input power, and temperature.
+
+The current and power measurement scale depends on the resistor connected
+between the IMON pin and ground. The resistor value can be configured with the
+``silergy,rimon-micro-ohms`` device tree property. See
+``Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml`` for details.
+
+Due to the specificities of the chip, all history reset attributes are tied
+together. Resetting the history of one sensor resets the history of all sensors.
+
+Sysfs entries
+-------------
+
+The following attributes are supported. Limits are read-write; all other
+attributes are read-only.
+
+======================= ======================================================
+in1_label "vin"
+in1_input Measured input voltage.
+in1_average Average measured input voltage.
+in1_min Minimum input voltage limit.
+in1_lcrit Critical low input voltage limit.
+in1_max Maximum input voltage limit.
+in1_crit Critical high input voltage limit.
+in1_min_alarm Input voltage low warning alarm.
+in1_lcrit_alarm Input voltage low fault alarm.
+in1_max_alarm Input voltage high warning alarm.
+in1_crit_alarm Input voltage high fault alarm.
+in1_highest Historical maximum input voltage.
+in1_lowest Historical minimum input voltage.
+in1_reset_history Write any value to reset history.
+
+in2_label "vmon"
+in2_input Measured auxiliary input voltage.
+
+in3_label "vout1"
+in3_input Measured output voltage.
+in3_average Average measured output voltage.
+in3_min Minimum output voltage limit.
+in3_min_alarm Output voltage low alarm.
+in3_lowest Historical minimum output voltage.
+in3_reset_history Write any value to reset history.
+
+curr1_label "iin"
+curr1_input Measured input current.
+curr1_average Average measured input current.
+curr1_max Maximum input current warning limit.
+curr1_crit Critical input over-current fault limit.
+curr1_max_alarm Input current warning alarm.
+curr1_crit_alarm Input over-current fault alarm.
+curr1_highest Historical maximum input current.
+curr1_reset_history Write any value to reset history.
+
+power1_label "pin"
+power1_input Measured input power.
+power1_average Average measured input power.
+power1_max Maximum input power warning limit.
+power1_alarm Input power warning alarm.
+power1_input_highest Historical maximum input power.
+power1_reset_history Write any value to reset history.
+
+temp1_input Measured temperature.
+temp1_average Average measured temperature.
+temp1_max Maximum temperature warning limit.
+temp1_crit Critical temperature fault limit.
+temp1_max_alarm Temperature warning alarm.
+temp1_crit_alarm Temperature fault alarm.
+temp1_highest Historical maximum temperature.
+temp1_reset_history Write any value to reset history.
+
+samples Number of samples used for average values.
+======================= ======================================================
+
--
2.25.1
^ 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