* Re: [PATCH v5 07/14] mfd: lm3533: Use dev_groups in struct device_driver
From: Andy Shevchenko @ 2026-06-25 7:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-8-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:24AM +0300, Svyatoslav Ryhel wrote:
> Instead of creating and removing the device sysfs attributes directly
> during probe and remove of the driver, respectively, use dev_groups in
> struct device_driver to point to the attribute definitions and let the
> core take care of creating and removing them.
>
> No intentional functional impact.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
And thanks for doing that!
...
> .attrs = lm3533_attributes
> };
>
> +static const struct attribute_group *lm3533_attribute_groups[] = {
> + &lm3533_attribute_group,
> + NULL,
> +};
We have ATTRIBUTE_GROUPS() macro.
...
> +++ b/drivers/video/backlight/lm3533_bl.c
Same as per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Krzysztof Kozlowski @ 2026-06-25 7:22 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <9175804c-956d-41eb-9995-05a7b3bf3fcc@oss.qualcomm.com>
On 25/06/2026 09:09, Fenglin Wu wrote:
>>
>> That is not what I meant and you did not follow maintainer process. And
>> why did you ignore second binding? Identify how many separate
>> maintainers are here and act like them. I looked again at your patchset
>> and I am sure about that - patchset is unmergeable by Lee.
>
> I see. So I should mention below sentence at the beginning of the cover
> letter, is that right?
>
> Dependencies:
>
> - [patch 2/4] depends on [patch 1/4] and they should be applied together.
>
Yes.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: adm1275: ROHM BD12780 hot-swap controller
From: Krzysztof Kozlowski @ 2026-06-25 7:21 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: <bd9419aa-1a21-4ca2-990b-ad1bebf5c9c8@gmail.com>
On 25/06/2026 09:05, Matti Vaittinen wrote:
>>> + - adi,adm1075
>>> + - adi,adm1272
>>> + - adi,adm1273
>>> + - adi,adm1275
>>> + - adi,adm1276
>>> + - adi,adm1278
>>> + - adi,adm1281
>>> + - adi,adm1293
>>> + - adi,adm1294
>>> + - rohm,bd12780
>>> + - silergy,mc09c
>>> +
>>> +# Require BD12780 as a fall-back for BD12780A.
>>
>> No need for the comment, schema is quite explicit.
>
> Eh... I know it is explicit for one who fluently reads yaml. Not all of
> us do that :| (See my reply to the previous comment...) I am not sure
> the comment hurts - while I am sure it helps occasional binding reader
> like me. Can you please reconsider keeping the comment?
This one does not, but if people take the existing code as a starting
point or even as an example in arguments ("he did like that, so I am
allowed as well"), it gets multiplied and we have more bindings with
redundant data.
That's said, if you insist then fine with me, keep it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Fenglin Wu @ 2026-06-25 7:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <91cc96b0-d25f-436d-a0c7-fec39bf72393@kernel.org>
On 6/25/2026 2:19 PM, Krzysztof Kozlowski wrote:
> On 25/06/2026 03:41, Fenglin Wu wrote:
>> On 6/24/2026 6:05 PM, Krzysztof Kozlowski wrote:
>>> No. Act as maintainer. Clone Linus tree, apply the patch and see if
>>> everything works. My claim is that nothing works and maintainer tree is
>>> broken.
>>>
>>> Best regards,
>>> Krzysztof
>> Thanks for the explanation. I just did that and I didn't see conflict
>> when applying the binding and driver changes, but I did see a conflict
>> when applying the DTS change. I will drop the DTS change 1st and resend
>> them after the driver and binding changes get accepted.
>
> That is not what I meant and you did not follow maintainer process. And
> why did you ignore second binding? Identify how many separate
> maintainers are here and act like them. I looked again at your patchset
> and I am sure about that - patchset is unmergeable by Lee.
I see. So I should mention below sentence at the beginning of the cover
letter, is that right?
Dependencies:
- [patch 2/4] depends on [patch 1/4] and they should be applied together.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: adm1275: ROHM BD12780 hot-swap controller
From: Matti Vaittinen @ 2026-06-25 7:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
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: <20260617-uptight-sexy-hippo-f4bc62@quoll>
I think I (almost) missed this review... Sorry for the belated reply.
On 17/06/2026 13:28, Krzysztof Kozlowski wrote:
> On Tue, Jun 16, 2026 at 09:35:35AM +0300, Matti Vaittinen wrote:
> +
>> + Datasheets:
>> + https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780muv-lb-e.pdf
>> + https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780amuv-lb-e.pdf
>> +
>> properties:
>> compatible:
>> - enum:
>> - - adi,adm1075
>> - - adi,adm1272
>> - - adi,adm1273
>> - - adi,adm1275
>> - - adi,adm1276
>> - - adi,adm1278
>> - - adi,adm1281
>> - - adi,adm1293
>> - - adi,adm1294
>> - - silergy,mc09c
>> + oneOf:
>> + - items:
>> + enum:
>
>
> s/items/enum/, so:
>
> oneOf:
> - enum:
> ....
Thanks Krzysztof. I am always so lost with these bindings. Giving the
concrete suggestion(s) helps a lot!
>
>> + - adi,adm1075
>> + - adi,adm1272
>> + - adi,adm1273
>> + - adi,adm1275
>> + - adi,adm1276
>> + - adi,adm1278
>> + - adi,adm1281
>> + - adi,adm1293
>> + - adi,adm1294
>> + - rohm,bd12780
>> + - silergy,mc09c
>> +
>> +# Require BD12780 as a fall-back for BD12780A.
>
> No need for the comment, schema is quite explicit.
Eh... I know it is explicit for one who fluently reads yaml. Not all of
us do that :| (See my reply to the previous comment...) I am not sure
the comment hurts - while I am sure it helps occasional binding reader
like me. Can you please reconsider keeping the comment?
Although, I am not sure if Guenter suggested me to drop the compatible
for the bd12780a and only use the bd12780 - or if his comment only
applied to the i2c IDs.
https://lore.kernel.org/all/751cd5eb-104f-4445-a6d2-8119ad5d5660@roeck-us.net/
Well, I will keep the bd12780a compatible and drop the I2C ID unless
something else is suggested. Again, the BD12780 and BD12780A do have
different hardware properties (at least in I2C slave address selection
pins), and while it doesn't really matter for the Linux drivers, the DT
bindings should ideally be generic and not Linux specific.
Yours,
-- Matti.
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: sashiko-bot @ 2026-06-25 7:04 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260625065329.20274-3-muhammad.nazim.amirul.nazle.asmade@altera.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing CPU topology and relative capacity metrics (`capacity-dmips-mhz`) for the heterogeneous Cortex-A520/A720 cluster.
- [Medium] Malformed reserved-memory nodes for firmware regions mixing static and dynamic properties, and improperly exposing secure memory as a DMA pool.
--
commit 24c23f8ecc00caa97660929277c73ae2d495bf92
Author: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
arm64: dts: socfpga: agilex72: Add initial device tree
This commit adds initial device tree support for the Intel SoCFPGA Agilex72
platform. The Agilex72 SoC features a heterogeneous CPU cluster with
Cortex-A520 and Cortex-A720 cores, and includes an SMMU v3 for memory
management.
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
> new file mode 100644
> index 0000000000000..c29c2afcaab70
> --- /dev/null
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
> @@ -0,0 +1,156 @@
[ ... ]
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + atf_reserved: atf@80000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x80000000 0x0 0x100000>;
> + alignment = <0x1000>;
> + no-map;
> + };
[Severity: Medium]
Does this node improperly mix static and dynamic allocation properties?
The reg property implies static allocation, while alignment is for
dynamic allocation, and according to the bindings, these are mutually
exclusive.
Also, should ATF memory be exposed as a shared-dma-pool? Secure firmware
memory generally shouldn't be exposed as a pool for the kernel's DMA
subsystem to manage, as it could lead to exceptions if the non-secure kernel
attempts to map or allocate from it.
> +
> + service_reserved: svcbuffer@80100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x80100000 0x0 0xf00000>;
> + alignment = <0x1000>;
> + no-map;
> + };
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a520";
> + device_type = "cpu";
> + enable-method = "psci";
> + reg = <0x0>;
> + };
[Severity: Medium]
Will the scheduler treat these heterogeneous cores as having equal compute
capacity?
Without a cpu-map topology and capacity-dmips-mhz properties, the Linux
scheduler may default to treating the Cortex-A520 and Cortex-A720 cores
as having equal capacity.
This could lead to suboptimal task placement for the big.LITTLE
architecture.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625065329.20274-1-muhammad.nazim.amirul.nazle.asmade@altera.com?part=2
^ permalink raw reply
* [PATCH v3 0/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-25 6:53 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
This series introduces basic device tree support for the Intel/Altera
Agilex72 SoCFPGA platform, which is a new SoC featuring a heterogeneous
CPU cluster (Cortex-A520 and Cortex-A720 cores).
Patch 1 adds the new compatible strings for Agilex72 to the arm/altera
DT bindings documentation.
Patch 2 introduces the initial DTSI and board-level DTS for the Agilex72
SoCDK. The DTSI covers the core SoC nodes: CPUs, GIC-v3 interrupt
controller with ITS, ARM architectural timer, PSCI, SMMU-v3, OCRAM, and
two UART serial controllers backed by a fixed-clock placeholder. The clock
manager driver for this platform is not yet upstream, so a fixed-clock
at 125 MHz is used as an interim solution for the UART clock, matching
the hardware-confirmed LSP_SP_CLK frequency.
Changes in v3:
- Add UART serial console (uart0, uart1) with fixed-clock placeholder at 125 MHz
- Add aliases and chosen nodes in board DTS for serial console
Changes in v2:
- Applied relevant feedback from Shahsiko's review
- Re-add arm,armv8-timer node which is mandatory for kernel boot
- Rename platform from agilex7-gen2 to agilex72
Nazim Amirul (2):
dt-bindings: arm: altera: Add Agilex72 SoCFPGA compatible strings
arm64: dts: socfpga: agilex72: Add initial device tree
.../devicetree/bindings/arm/altera.yaml | 6 +
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex72.dtsi | 156 ++++++++++++++++++
.../boot/dts/intel/socfpga_agilex72_socdk.dts | 27 +++
4 files changed, 190 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
--
2.43.7
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: arm: altera: Add Agilex72 SoCFPGA compatible strings
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-25 6:53 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260625065329.20274-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add the SoC and board compatible strings for the Intel SoCFPGA
Agilex72 platform.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v3:
- no changes
---
Documentation/devicetree/bindings/arm/altera.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 4b096e52243e..cc03fb437a9a 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -115,6 +115,12 @@ properties:
- intel,socfpga-agilex5-socdk-nand
- const: intel,socfpga-agilex5
+ - description: Agilex72 boards
+ items:
+ - enum:
+ - intel,socfpga-agilex72-socdk
+ - const: intel,socfpga-agilex72
+
- description: Agilex7m boards
items:
- enum:
--
2.43.7
^ permalink raw reply related
* [PATCH v3 2/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-25 6:53 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260625065329.20274-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add initial device tree support for the Intel SoCFPGA Agilex72
platform. This introduces the SoC DTSI and the SoCDK board DTS as
the first upstream submission for this platform.
The Agilex72 SoC features a heterogeneous CPU cluster with
Cortex-A520 and Cortex-A720 cores, and includes an SMMU v3 for
memory management.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v3:
- Add UART serial console (uart0, uart1) with fixed-clock placeholder at 125 MHz
- Add aliases and chosen nodes in board DTS for serial console
Changes in v2:
- Re-add arm,armv8-timer node which is mandatory for kernel boot
- Rename platform from agilex7-gen2 to agilex72
---
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex72.dtsi | 156 ++++++++++++++++++
.../boot/dts/intel/socfpga_agilex72_socdk.dts | 27 +++
3 files changed, 184 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 088a03b89c99..270c70fdf084 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
socfpga_agilex5_socdk_013b.dtb \
socfpga_agilex5_socdk_modular.dtb \
socfpga_agilex5_socdk_nand.dtb \
+ socfpga_agilex72_socdk.dtb \
socfpga_agilex7m_socdk.dtb \
socfpga_n5x_socdk.dtb
dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
new file mode 100644
index 000000000000..c29c2afcaab7
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ compatible = "intel,socfpga-agilex72";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ atf_reserved: atf@80000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80000000 0x0 0x100000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ service_reserved: svcbuffer@80100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80100000 0x0 0xf00000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x0>;
+ };
+
+ cpu1: cpu@100 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x100>;
+ };
+
+ cpu2: cpu@200 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x200>;
+ };
+
+ cpu3: cpu@300 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x300>;
+ };
+ };
+
+ clocks {
+ uart_clk: uart-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ intc: interrupt-controller@7000000 {
+ compatible = "arm,gic-v3";
+ reg = <0x0 0x7000000 0x0 0x10000>,
+ <0x0 0x7080000 0x0 0x100000>;
+ ranges;
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-controller;
+ #redistributor-regions = <1>;
+ redistributor-stride = <0x0 0x40000>;
+
+ its: msi-controller@7040000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x7040000 0x0 0x20000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ soc: soc@0 {
+ compatible = "simple-bus";
+ ranges = <0 0 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ interrupt-parent = <&intc>;
+
+ smmu: iommu@c100000 {
+ compatible = "arm,smmu-v3";
+ reg = <0x0c100000 0x30000>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "eventq", "gerror", "priq";
+ dma-coherent;
+ #iommu-cells = <1>;
+ };
+
+ ocram: sram@0 {
+ compatible = "mmio-sram";
+ reg = <0x00000000 0x80000>;
+ ranges = <0 0 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+ uart0: serial@9038000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x9038000 0x100>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&uart_clk>;
+ status = "disabled";
+ };
+
+ uart1: serial@9039000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x9039000 0x100>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&uart_clk>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
new file mode 100644
index 000000000000..998f19f492b3
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+#include "socfpga_agilex72.dtsi"
+
+/ {
+ model = "Altera SoCFPGA Agilex72 SoCDK";
+ compatible = "intel,socfpga-agilex72-socdk", "intel,socfpga-agilex72";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x80000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.43.7
^ permalink raw reply related
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Krzysztof Kozlowski @ 2026-06-25 6:48 UTC (permalink / raw)
To: Daniel Lezcano, Gaurav Kohli
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi,
Dmitry Baryshkov
In-Reply-To: <ae0ec05e-607b-4022-a006-2eb1a283144d@oss.qualcomm.com>
On 24/06/2026 17:56, Daniel Lezcano wrote:
> On 6/24/26 12:42, Krzysztof Kozlowski wrote:
>
> [ ... ]
>
>> Therefore I still do not see the need of tmd-names. You know the name of
>> cooling device, because you have strict one-to-one mapping.
>
>
> There is one remote proc with one or multiple cooling devices attached.
>
> We describe those in the remoteproc node with the tmd-names.
>
> Anyway, we should be able to list the tmd names in the driver itself if
> we ensure a consistency with the index by defining them in a shared
> header eg. include/dt-bindings/firmware/qcom,cdsp.h
>
> #define HAMOA_TMD_CDSP_SW 0
> #define HAMOA_TMD_CDSP_HW 1
> #define HAMOA_TMD_CP0UV_RESTRICTION_COLD 2
>
> In the driver:
>
> struct tmd_name {
> const char *name;
> int id;
> bool disabled;
> };
>
> static struct tmd_name tmd_names[] = {
> { .name = "cdsp_sw", HAMOA_TMD_CDSP_SW },
> { .name = "cdsp_hw", HAMOA_TMD_CDSP_HW, .disabled = true },
> { .name = "cpuv_restriction_cold", HAMOA_TMD_CP0UV_RESTRICTION_COLD,
> .disabled = true },
> };
>
> ...
> for (int i = 0; i < ARRAY_SIZE(tmd_names); i++) {
>
> if (tmd_names[i].disabled)
> continue;
> devm_cooling_of_device_register(rprocdev,
> tmd_names[i].name, tmd_names[i].id, ...);
> }
>
>
> In the device tree:
>
> cooling-maps = <&rproc HAMOA_TMD_CDSP_SW min max>;
>
> I think that is somehow what Konrad and Dmitry were suggesting
>
> Does it sound better ?
Yes and I am surprised that it came now. So you had TMD index available
thus the ID was defined. If device has unique and fixed ID, you should
not have any more properties defining it, because that ID is enough. Any
names could be only for users, e.g. label, but that is not the case here.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: limits: Describe Qualcomm SPEL hardware
From: Krzysztof Kozlowski @ 2026-06-25 6:45 UTC (permalink / raw)
To: Daniel Lezcano, Manaf Meethalavalappu Pallikunhi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Bjorn Andersson, Konrad Dybcio, Gaurav Kohli, linux-arm-msm,
devicetree, linux-kernel, linux-pm
In-Reply-To: <63d42dd6-862f-4a9c-a950-5bc90ffab391@oss.qualcomm.com>
On 24/06/2026 22:41, Daniel Lezcano wrote:
> It allows power capping and read the average power consumption for a
> specific device (or/and an energy counter)
>
> Basically you can set a power constraint (power limit) to a device and
> this one won't consume more than that power (the power limitation
> strategy is managed under the hood by the firmware depending on the
> device - lower OPP, idle injection, modem weaker signal, etc ...).
>
> The RAPL or the SPEL have a hierarchical power limitation. For example:
>
> SoC
> |
> ------------------------
> | |
> Cluster0 Cluster1
> | |
> ----------------- -----------------
> | | | | | | | |
> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
>
>
> If you specify a power limit to 'SoC', then the power consumption of
> Cluster0 + Cluster1 <= SoC
>
> If Cluster0 power consumption decreases, then Cluster1 is allowed to use
> more power until Cluster0 + Cluster1 <= SoC
>
> For me it sounds reasonable to put the device description under power/limits
Yes, can go there. Some pieces of above explanation could be captured in
commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Krzysztof Kozlowski @ 2026-06-25 6:43 UTC (permalink / raw)
To: Gerald Loacker
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-2-323356c2cc2e@wolfvision.net>
On Fri, Jun 19, 2026 at 11:13:40AM +0200, Gerald Loacker wrote:
> Add support for the optional rockchip,clk-lane-phase device tree property
> to allow board-specific tuning of the clock lane sampling phase for
> improved signal integrity across supported data rates.
>
> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
> ---
> .../devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> index 03950b3cad08c..010950a8a8856 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> @@ -56,6 +56,15 @@ properties:
> description:
> Some additional phy settings are access through GRF regs.
>
> + rockchip,clk-lane-phase:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 7
Missing default here. If default is unknown, explain that in commit msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: edac: Add bindings for Xilinx Versal XilSEM
From: Krzysztof Kozlowski @ 2026-06-25 6:39 UTC (permalink / raw)
To: Rama devi Veggalam
Cc: bp, tony.luck, michal.simek, robh, krzk+dt, conor+dt,
linux-kernel, linux-edac, devicetree, james.morse, mchehab, rric,
git
In-Reply-To: <20260624212545.2850787-2-rama.devi.veggalam@amd.com>
On Thu, Jun 25, 2026 at 02:55:42AM +0530, Rama devi Veggalam wrote:
> Update versal edac device tree bindings for
> Versal Soft Error Mitigation (XilSEM).
>
> Signed-off-by: Rama devi Veggalam <rama.devi.veggalam@amd.com>
> ---
> Changes in v3:
> - Merged XilSEM edac with Versal Edac
One more thing: There is no xilsem here... or commit msg is just missing
the main point. This is very confusing or heavily incorrect patch. No
clue which one.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: edac: Add bindings for Xilinx Versal XilSEM
From: Krzysztof Kozlowski @ 2026-06-25 6:37 UTC (permalink / raw)
To: Rama devi Veggalam
Cc: bp, tony.luck, michal.simek, robh, krzk+dt, conor+dt,
linux-kernel, linux-edac, devicetree, james.morse, mchehab, rric,
git
In-Reply-To: <20260624212545.2850787-2-rama.devi.veggalam@amd.com>
On Thu, Jun 25, 2026 at 02:55:42AM +0530, Rama devi Veggalam wrote:
> Update versal edac device tree bindings for
Everything is update. Pretty useless commit msg.
> Versal Soft Error Mitigation (XilSEM).
A nit, subject: drop second/last, redundant "bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
>
> Signed-off-by: Rama devi Veggalam <rama.devi.veggalam@amd.com>
> ---
> Changes in v3:
> - Merged XilSEM edac with Versal Edac
>
> Changes in v2:
> - Changed "xlnx,versal-xilsem-edac" to constant
> - Removed "compatible: in required section
> - Removed "|" in description
> - Removed "items" in compatible
> - Fixed indentation in examples
> - Updated title and description
> ---
> .../xlnx,versal-ddrmc-edac.yaml | 22 ++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml b/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml
> index 12f8e9f350bc..568d2af7de81 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml
> +++ b/Documentation/devicetree/bindings/memory-controllers/xlnx,versal-ddrmc-edac.yaml
> @@ -4,17 +4,31 @@
> $id: http://devicetree.org/schemas/memory-controllers/xlnx,versal-ddrmc-edac.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Xilinx Versal DDRMC (Integrated DDR Memory Controller)
> +title: Xilinx Versal DDRMC (Integrated DDR Memory Controller) and Soft Error Mitigation (XilSEM)
>
> maintainers:
> - Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> + - Rama Devi Veggalam <rama.devi.veggalam@amd.com>
>
> description:
> The integrated DDR Memory Controllers (DDRMCs) support both DDR4 and LPDDR4/
> 4X memory interfaces. Versal DDR memory controller has an optional ECC support
> which correct single bit ECC errors and detect double bit ECC errors.
>
> + Xilinx Versal Soft Error Mitigation (XilSEM) is part of the
> + Platform Loader and Manager (PLM) which runs on the
> + Platform Management Controller (PMC). XilSEM is responsible for reporting
> + and optionally correcting soft errors in Configuration Memory of Versal.
> + The Configuration Memory includes Configuration RAM and
> + Network on Chip (NoC) peripheral interconnect (NPI) Registers.
> +
> + The memory is scanned by a hardware controller in the Versal Programmable
> + Logic (PL). During the scan, if the controller detects any error, be it
> + correctable or uncorrectable, it reports the error to PLM.
> + The XilSEM on PLM performs the error validation and notifies the errors to user application.
> +
> +
> properties:
> compatible:
> const: xlnx,versal-ddrmc
> @@ -23,11 +37,13 @@ properties:
> items:
> - description: DDR Memory Controller registers
> - description: NOC registers corresponding to DDR Memory Controller
> + - description: SEM RTCA Controller registers
>
> reg-names:
> items:
> - const: base
> - const: noc
> + - const: semrtca
You break ABI without any explanation.
NAK, I think I made this point many times already... Please read
writing-bindings doc.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Krzysztof Kozlowski @ 2026-06-25 6:36 UTC (permalink / raw)
To: Grégoire Layet
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAFi2wKbKr8FMcJeGWA5e1UZUTh2=LwYNkLEj6exd2as7=AcvVQ@mail.gmail.com>
On 24/06/2026 14:48, Grégoire Layet wrote:
> Hi Krzysztof,
>
>> What does that mean? How UART can be accessible over PCI bus?
>
> It's a Virtual UART. Internally, it's two FIFOs accessible via
> 8250-compatible register sets on both ends.
I do not know what is Virtual UART...
> There is 4 Virtuals UARTs on the LPC bus of the AST2600 and 2 of them
> are bridged over the PCI bus.
> So, from the host, you can access the 8250 register set on the PCI bus.
You mean these appear (or are) as PCI devices?
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: iio: health: add adi,max86150
From: Krzysztof Kozlowski @ 2026-06-25 6:33 UTC (permalink / raw)
To: Md Shofiqul Islam
Cc: linux-iio, jic23, lars, conor, conor+dt, robh, krzk+dt,
devicetree, linux-kernel
In-Reply-To: <20260623201124.18271-2-shofiqtest@gmail.com>
On Tue, Jun 23, 2026 at 11:11:21PM +0300, Md Shofiqul Islam wrote:
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Active-low interrupt line. Asserted when the FIFO almost-full
> + threshold is reached or when a new PPG sample is ready.
> +
> + vdd-supply:
vdddig? Which supply is this?
> + description: Digital core power supply (1.8 V).
> +
> + avdd-supply:
I cannot find it in datasheet.
> + description: Analog core power supply (1.8 V).
> +
> + vref-supply:
> + description: ECG reference voltage supply.
> +
> + leds-supply:
Datasheet calls this VLED. Don't invent names.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8] arm64: dts: qcom: kodiak: Add EL2 overlay
From: Mukesh Ojha @ 2026-06-25 6:33 UTC (permalink / raw)
To: Miaoqing Pan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel, Sumit Garg
In-Reply-To: <8fbfa82f-aae7-48d6-9406-d04e719f028d@oss.qualcomm.com>
On Thu, Jun 25, 2026 at 09:14:41AM +0800, Miaoqing Pan wrote:
>
>
> On 6/24/2026 2:39 PM, Mukesh Ojha wrote:
> > All the existing variants Kodiak boards are using Gunyah hypervisor
> > which means that, so far, Linux-based OS could only boot in EL1 on those
> > devices. However, it is possible for us to boot Linux at EL2 on these
> > devices [1].
> >
> > When running under Gunyah, the remote processor firmware IOMMU
> > streams are controlled by Gunyah. However, without Gunyah, the IOMMU is
> > managed by the consumer of this DeviceTree. Therefore, describe the
> > firmware streams for each remote processor.
> >
> > Add a EL2-specific DT overlay and apply it to Kodiak IOT variant
> > devices to create -el2.dtb for each of them alongside "normal" dtb.
> >
> > Note that modem and media subsystems haven't been supported yet due
> > to missing dependencies. For GPU to work, zap shader is disabled and
> > in EL2 mode the kernel owns hardware watchdog which is enabled here.
> > And for wifi to work wpss copy engine memory need to be mapped for
> > WPSS firmware to work which is aligning with sc7280 chrome.
> >
> > [1]
> > https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi
> >
> > Co-developed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
> > Changes in v8: https://lore.kernel.org/lkml/20260522115936.201208-2-sumit.garg@kernel.org/
> > - Added a wpss copy engine memory similar to chrome for Wifi to work.
> > - WPSS does not have firmware Stream, so that was removed.
> > - Added wifi streams similar to chrome for wifi to work.
> > - Removed this patch from Generic Pas patch series, can be followed
> > separately.
> > - Moved Sumit as co-author as part of modification done to the patch
> > in the past.
> > - Added some more kodiak's board variants in the makefile.
> >
> > Changes in v1-v7:
> > - mpss was disabled and will be enabled once the dependencies patches
> > get merged.
> >
> > arch/arm64/boot/dts/qcom/Makefile | 12 ++++++
> > arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 52 ++++++++++++++++++++++++
> > arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
> > 3 files changed, 65 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> >
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index 6f33c4e2f09c..d2cee1190954 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -164,7 +164,11 @@ purwa-iot-evk-el2-dtbs := purwa-iot-evk.dtb x1-el2.dtbo
> > dtb-$(CONFIG_ARCH_QCOM) += purwa-iot-evk-el2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcm6490-fairphone-fp5.dtb
> > +
> > dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp.dtb
> > +qcm6490-idp-el2-dtbs := qcm6490-idp.dtb kodiak-el2.dtbo
> > +dtb-$(CONFIG_ARCH_QCOM) += qcm6490-idp-el2.dtb
> > +
> > dtb-$(CONFIG_ARCH_QCOM) += qcm6490-particle-tachyon.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcm6490-shift-otter.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb
> > @@ -176,12 +180,20 @@ qcs615-ride-el2-dtbs := qcs615-ride.dtb talos-el2.dtbo
> > dtb-$(CONFIG_ARCH_QCOM) += qcs615-ride-el2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-radxa-dragon-q6a.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > +qcs6490-rb3gen2-el2-dtbs := qcs6490-rb3gen2.dtb kodiak-el2.dtbo
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-el2.dtb
> > qcs6490-rb3gen2-vision-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-vision-mezzanine.dtbo
> > qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtb
> > +qcs6490-rb3gen2-industrial-mezzanine-el2-dtbs := qcs6490-rb3gen2-industrial-mezzanine.dtb kodiak-el2.dtbo
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine-el2.dtb
> > +
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtb
> > +qcs6490-rb3gen2-vision-mezzanine-el2-dtbs := qcs6490-rb3gen2-vision-mezzanine.dtb kodiak-el2.dtbo
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine-el2.dtb
> > +
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-minipc-g1iot.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-rubikpi3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > diff --git a/arch/arm64/boot/dts/qcom/kodiak-el2.dtso b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> > new file mode 100644
> > index 000000000000..91e4cda45b49
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/kodiak-el2.dtso
> > @@ -0,0 +1,52 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > + *
> > + * Kodiak specific modifications required to boot in EL2.
> > + */
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +
> > +&gpu_zap_shader {
> > + status = "disabled";
> > +};
> > +
> > +&remoteproc_adsp {
> > + iommus = <&apps_smmu 0x1800 0x0>;
> > +};
> > +
> > +&remoteproc_cdsp {
> > + iommus = <&apps_smmu 0x11a0 0x0400>;
> > +};
> > +
> > +&remoteproc_mpss {
> > + status = "disabled";
> > +};
> > +
> > +&reserved_memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + wlan_ce_mem: wlan-ce@4cd000 {
> > + no-map;
> > + reg = <0x0 0x004cd000 0x0 0x1000>;
> > + };
> > +};
> > +
> Is it necessary to redefine |wlan_ce_mem|? Can we consider updating
> |qcs6490-rb3gen2.dts|?
> I have verified that with the following changes, *NON-KVM works fine*, and
> |wlan_ce_mem| is only used by the WCN6750 firmware.
Thanks for the review.
I was unsure about it, hence kept it as how Chrome kept it; I am
fine to keep as suggested as it seems to me these regions were
only needed for wifi-firmware mentioned, and we should not have deleted
it for qcs6490-rb3gen2.dts and idp too, will do the change that
will make this much cleaner.
>
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -26,7 +26,6 @@
> /delete-node/ &adsp_mem;
> /delete-node/ &cdsp_mem;
> /delete-node/ &video_mem;
> -/delete-node/ &wlan_ce_mem;
> /delete-node/ &wpss_mem;
> /delete-node/ &xbl_mem;
>
> @@ -1686,7 +1685,6 @@ &venus {
> };
>
> &wifi {
> - memory-region = <&wlan_fw_mem>;
> qcom,calibration-variant = "Qualcomm_rb3gen2";
>
>
> > +&venus {
> > + status = "disabled";
> > +};
> > +
> > +&watchdog {
> > + status = "okay";
> > +};
> > +
> > +&wifi {
> > + memory-region = <&wlan_fw_mem>, <&wlan_ce_mem>;
> > + status = "okay";
> > +
> > + wifi-firmware {
> > + iommus = <&apps_smmu 0x1c02 0x1>;
> > + };
> > +};
> > diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > index fa540d8c2615..2486d15fa2ba 100644
> > --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> > @@ -91,7 +91,7 @@ sleep_clk: sleep-clk {
> > };
> > };
> > - reserved-memory {
> > + reserved_memory: reserved-memory {
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Krzysztof Kozlowski @ 2026-06-25 6:28 UTC (permalink / raw)
To: Nas Chung
Cc: Conor Dooley, mchehab@kernel.org, hverkuil@xs4all.nl,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
linux-arm-kernel@lists.infradead.org, jackson.lee, lafley.kim,
marek.vasut@mailbox.org
In-Reply-To: <SL2P216MB2441BB9DC91CCBE494F2B45BFBEC2@SL2P216MB2441.KORP216.PROD.OUTLOOK.COM>
On Thu, Jun 25, 2026 at 01:43:33AM +0000, Nas Chung wrote:
> >> + sram:
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> + description:
> >> + phandle to the SRAM node used to store reference data, reducing DMA
> >> + memory bandwidth.
> >> +
> >> + iommus:
> >> + maxItems: 1
> >> +
> >> + "#cooling-cells":
> >> + const: 2
> >> +
> >> + "#address-cells":
> >> + const: 2
> >> +
> >> + "#size-cells":
> >> + const: 2
> >> +
> >> + ranges: true
> >> +
> >> +patternProperties:
> >> + "^interface@[0-9a-f]+$":
> >
> >I have to wonder if this interface business is required at all.
> >Why can this not go into the parent, with each region fetchable via
> >reg-names, interrupt-names and iommu-names?
>
> Thanks for your feedback.
>
> I did try the flat model, but the blocker is the IOMMU.
>
> The control region and four interface regions are independent DMA requesters
> with distinct stream IDs, and each interface can be assigned to a different VM,
> driving the video core with its own isolated memory.
>
> If all stream IDs are listed under the parent's iommus, they bind to a
> single device and share one domain, so the isolation is lost.
> This is the main reason I added the interface nodes.
Feels similar to issue Qualcomm has. I rejected such subnodes and
Qualcomm came with a solution in DMA IOMMU code, but that solution was
rejected by DMA folks:
https://lore.kernel.org/all/c7b956a9-d3e8-4e18-b780-5d08f5cd2ca1@kernel.org/
I don't have proper arguments to convince DMA folks, thus I agree for
Qualcomm for the subnodes. It should be fine here as well, in such case.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: input: Add Qualcomm SPMI PMIC haptics
From: Krzysztof Kozlowski @ 2026-06-25 6:23 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260624-qcom-spmi-haptics-v2-1-b9118e60f3e3@oss.qualcomm.com>
On 25/06/2026 04:00, Fenglin Wu wrote:
> Add binding document for the haptics module inside Qualcomm PMIC
> PMIH0108.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> .../bindings/input/qcom,spmi-haptics.yaml | 132 +++++++++++++++++++++
> 1 file changed, 132 insertions(+)
You did not test this before sending, therefore this fits in to AI slop
category. I do not accept AI slop to be sent to mailing list.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 2/2] hwmon: Add Eswin EIC7700 PVT sensor driver
From: sashiko-bot @ 2026-06-25 6:22 UTC (permalink / raw)
To: hehuan1; +Cc: linux-hwmon, devicetree, robh, conor+dt
In-Reply-To: <20260625061214.1648-1-hehuan1@eswincomputing.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing Hardware State Restoration after System Sleep / Runtime PM
--
commit 90e30b4d9c6082a265da7f7091bf9e2cd31aec81
Author: Huan He <hehuan1@eswincomputing.com>
hwmon: Add Eswin EIC7700 PVT sensor driver
This commit introduces support for the ESWIN EIC7700 Voltage and
Temperature (PVT) sensor. The driver implements temperature and voltage
monitoring using polynomial conversion and provides a sysfs interface
for accessing the sensor data.
> diff --git a/drivers/hwmon/eic7700-pvt.c b/drivers/hwmon/eic7700-pvt.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/hwmon/eic7700-pvt.c
[ ... ]
> +static int __maybe_unused eic7700_pvt_runtime_resume(struct device *dev)
> +{
> + struct pvt_hwmon *pvt = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_bulk_prepare_enable(PVT_CLK_NUM, pvt->clks);
> + if (ret) {
> + dev_err(dev, "Failed to enable clocks: %d\n", ret);
> + return ret;
> + }
> +
[Severity: Medium]
Does this code need to restore the hardware trim value after resuming?
The driver initializes the sensor mode and trim configuration via
eic7700_pvt_init_iface() during probe.
If the device enters system suspend or runtime suspend and the power domain
is disabled, the hardware configuration could be lost. Since the driver
utilizes pm_runtime_force_resume() for system suspend paths, should this
callback re-apply the trim values to prevent incorrect sensor readings
upon wake?
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625061049.1614-1-hehuan1@eswincomputing.com?part=2
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: mfd: qcom,spmi-pmic: Document haptics device
From: Krzysztof Kozlowski @ 2026-06-25 6:21 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260624-qcom-spmi-haptics-v2-2-b9118e60f3e3@oss.qualcomm.com>
On 25/06/2026 04:00, Fenglin Wu wrote:
> Some of the Qualcomm SPMI PMIC has haptics device in it, add it in the
> device list.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
Still nothing about merging issue/dependency I asked to explain. You did
not solve it, you did not mention it how I asked. We speak about basics
of Linux kernel development process. If you cannot get this, even after
I directed you in v1, then you need to attend internal trainings or read
internal docs (go/upstream) where this is explained.
I drop the patches from DT Patchwork.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Krzysztof Kozlowski @ 2026-06-25 6:19 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <36043887-6bbd-4b2d-941c-bf222786b80d@oss.qualcomm.com>
On 25/06/2026 03:41, Fenglin Wu wrote:
>
> On 6/24/2026 6:05 PM, Krzysztof Kozlowski wrote:
>> No. Act as maintainer. Clone Linus tree, apply the patch and see if
>> everything works. My claim is that nothing works and maintainer tree is
>> broken.
>>
>> Best regards,
>> Krzysztof
>
> Thanks for the explanation. I just did that and I didn't see conflict
> when applying the binding and driver changes, but I did see a conflict
> when applying the DTS change. I will drop the DTS change 1st and resend
> them after the driver and binding changes get accepted.
That is not what I meant and you did not follow maintainer process. And
why did you ignore second binding? Identify how many separate
maintainers are here and act like them. I looked again at your patchset
and I am sure about that - patchset is unmergeable by Lee.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] iio: dac: dac8163: Add driver for DAC8163
From: Andy Shevchenko @ 2026-06-25 6:18 UTC (permalink / raw)
To: Lukas
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
linux-iio, devicetree
In-Reply-To: <ajvt5J5Cs5cOdTLt@berta-MS-7693>
On Wed, Jun 24, 2026 at 04:47:00PM +0200, Lukas wrote:
> On Tue, Jun 23, 2026 at 10:39:23PM +0300, Andy Shevchenko wrote:
>
> > > + dev_dbg(dev, "%s: val=%d val2=%d\n", __func__, val, val2);
> >
> > No. Is it RFC? PoC? Or production-ready? If not the latter, come when it will
> > be production-ready.
>
> I will remove the debug print. I tried my best to make this driver production-ready.
> I saw that other drivers also have similar debug messages so i didnt
> remove it after my first tests and thought it is ok to leave it in
> there.
Debug messages are different. And in IIO we don't have them (perhaps some
historical leftovers or corner cases, dunno). If you have an example, share
the pointer, I will check that. Perhaps we can drop them in that driver.
(The debug prints like above are fine in the drivers in staging, but staging
is not really accepting much nowadays, so it's not the point.)
> My intention was to try to apply the suggestions and comments i
> get and send a second revision. Do you think thats the right way?
That's the way how it goes. You address all or almost all comments,
send a new version where in the comments you need to explain the
non-addressed pieces ("why?" they haven't been addressed).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 1/2] dt-bindings: hwmon: Add Eswin EIC7700 PVT sensor
From: sashiko-bot @ 2026-06-25 6:17 UTC (permalink / raw)
To: hehuan1; +Cc: conor+dt, devicetree, robh, linux-hwmon
In-Reply-To: <20260625061147.1631-1-hehuan1@eswincomputing.com>
> From: Huan He <hehuan1@eswincomputing.com>
>
> Add device tree binding documentation for ESWIN EIC7700 Voltage and
> Temperature sensor.
>
> The EIC7700 SoC integrates two PVT instances for monitoring SoC and DDR
> power domains respectively.
>
> Signed-off-by: Yulin Lu <luyulin@eswincomputing.com>
> Signed-off-by: Huan He <hehuan1@eswincomputing.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625061049.1614-1-hehuan1@eswincomputing.com?part=1
^ permalink raw reply
* [PATCH v8 2/2] hwmon: Add Eswin EIC7700 PVT sensor driver
From: hehuan1 @ 2026-06-25 6:12 UTC (permalink / raw)
To: linux, robh, krzk+dt, conor+dt, p.zabel, linux-hwmon, devicetree,
linux-kernel
Cc: ningyu, linmin, pinkesh.vaghela, luyulin, dongxuyang, Huan He
In-Reply-To: <20260625061049.1614-1-hehuan1@eswincomputing.com>
From: Huan He <hehuan1@eswincomputing.com>
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.
The PVT IP contains one temperature sensor and one voltage sensor.
Signed-off-by: Yulin Lu <luyulin@eswincomputing.com>
Signed-off-by: Huan He <hehuan1@eswincomputing.com>
---
drivers/hwmon/Kconfig | 12 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/eic7700-pvt.c | 507 ++++++++++++++++++++++++++++++++++++
drivers/hwmon/eic7700-pvt.h | 99 +++++++
4 files changed, 619 insertions(+)
create mode 100644 drivers/hwmon/eic7700-pvt.c
create mode 100644 drivers/hwmon/eic7700-pvt.h
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5c2d3ff5fce8..6375c5f1136e 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2067,6 +2067,18 @@ config SENSORS_DME1737
This driver can also be built as a module. If so, the module
will be called dme1737.
+config SENSORS_EIC7700_PVT
+ tristate "Eswin EIC7700 Voltage, Temperature sensor driver"
+ depends on ARCH_ESWIN || COMPILE_TEST
+ depends on HWMON
+ select POLYNOMIAL
+ help
+ If you say yes here you get support for Eswin EIC7700 PVT sensor
+ embedded into the SoC.
+
+ This driver can also be built as a module. If so, the module will be
+ called eic7700-pvt.
+
config SENSORS_EMC1403
tristate "SMSC EMC1403/23 thermal sensor"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 63effc0ab8d1..e49cfdda970c 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_SENSORS_DME1737) += dme1737.o
obj-$(CONFIG_SENSORS_DRIVETEMP) += drivetemp.o
obj-$(CONFIG_SENSORS_DS620) += ds620.o
obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
+obj-$(CONFIG_SENSORS_EIC7700_PVT) += eic7700-pvt.o
obj-$(CONFIG_SENSORS_EMC1403) += emc1403.o
obj-$(CONFIG_SENSORS_EMC1812) += emc1812.o
obj-$(CONFIG_SENSORS_EMC2103) += emc2103.o
diff --git a/drivers/hwmon/eic7700-pvt.c b/drivers/hwmon/eic7700-pvt.c
new file mode 100644
index 000000000000..f694259258a9
--- /dev/null
+++ b/drivers/hwmon/eic7700-pvt.c
@@ -0,0 +1,507 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ESWIN EIC7700 Voltage, Temperature sensor driver
+ *
+ * Copyright 2026, Beijing ESWIN Computing Technology Co., Ltd.
+ *
+ * Authors:
+ * Yulin Lu <luyulin@eswincomputing.com>
+ * Huan He <hehuan1@eswincomputing.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/polynomial.h>
+#include <linux/reset.h>
+#include "eic7700-pvt.h"
+
+static const struct pvt_sensor_info pvt_info[] = {
+ PVT_SENSOR_INFO(0, "Temperature", hwmon_temp, TEMP),
+ PVT_SENSOR_INFO(0, "Voltage", hwmon_in, VOLT),
+};
+
+static const char * const pvt_clk_names[PVT_CLK_NUM] = {"enable", "apb"};
+
+/*
+ * The original translation formulae of the temperature (in degrees of Celsius)
+ * to PVT data and vice-versa are following:
+ * N = 6.0818e-8*(T^4) +1.2873e-5*(T^3) + 7.2244e-3*(T^2) + 3.6484*(T^1) +
+ * 1.6198e2,
+ * T = -1.8439e-11*(N^4) + 8.0705e-8*(N^3) + -1.8501e-4*(N^2) +
+ * 3.2843e-1*(N^1) - 4.8690e1,
+ * where T = [-40, 125]C and N = [27, 771].
+ * They must be accordingly altered to be suitable for the integer arithmetics.
+ * The technique is called 'factor redistribution', which just makes sure the
+ * multiplications and divisions are made so to have a result of the operations
+ * within the integer numbers limit. In addition we need to translate the
+ * formulae to accept millidegrees of Celsius. Here what they look like after
+ * the alterations:
+ * N = (60818e-20*(T^4) + 12873e-14*(T^3) + 72244e-9*(T^2) + 36484e-3*T +
+ * 16198e2) / 1e4,
+ * T = -18439e-12*(N^4) + 80705e-9*(N^3) - 185010e-6*(N^2) + 328430e-3*N -
+ * 48690,
+ * where T = [-40000, 125000] mC and N = [27, 771].
+ */
+static const struct polynomial poly_N_to_temp = {
+ .total_divider = 1,
+ .terms = {
+ {4, -18439, 1000, 1},
+ {3, 80705, 1000, 1},
+ {2, -185010, 1000, 1},
+ {1, 328430, 1000, 1},
+ {0, -48690, 1, 1}
+ }
+};
+
+/*
+ * Similar alterations are performed for the voltage conversion equations.
+ * The original formulae are:
+ * N = 1.3905e3*V - 5.7685e2,
+ * V = (N + 5.7685e2) / 1.3905e3,
+ * where V = [0.72, 0.88] V and N = [424, 646].
+ * After the optimization they looks as follows:
+ * N = (13905e-3*V - 5768.5) / 10,
+ * V = (N * 10^5 / 13905 + 57685 * 10^3 / 13905) / 10.
+ * where V = [720, 880] mV and N = [424, 646].
+ */
+static const struct polynomial poly_N_to_volt = {
+ .total_divider = 10,
+ .terms = {
+ {1, 100000, 13905, 1},
+ {0, 57685000, 1, 13905}
+ }
+};
+
+static inline u32 eic7700_pvt_update(void __iomem *reg, u32 mask, u32 data)
+{
+ u32 old;
+
+ old = readl_relaxed(reg);
+ writel((old & ~mask) | (data & mask), reg);
+
+ return old & mask;
+}
+
+static inline void eic7700_pvt_set_mode(struct pvt_hwmon *pvt, u32 mode)
+{
+ u32 old;
+
+ mode = FIELD_PREP(PVT_MODE_MASK, mode);
+
+ old = eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, 0);
+ eic7700_pvt_update(pvt->regs + PVT_MODE, PVT_MODE_MASK, mode);
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, old);
+}
+
+static inline void eic7700_pvt_set_trim(struct pvt_hwmon *pvt, u32 val)
+{
+ u32 old;
+
+ old = eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, 0);
+ writel(val, pvt->regs + PVT_TRIM);
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, old);
+}
+
+static irqreturn_t eic7700_pvt_hard_isr(int irq, void *data)
+{
+ struct pvt_hwmon *pvt = data;
+ u32 stat, val;
+ int active;
+
+ if (IS_ENABLED(CONFIG_PM)) {
+ active = pm_runtime_get_if_active(pvt->dev);
+ if (active <= 0)
+ return IRQ_NONE;
+ }
+
+ stat = readl(pvt->regs + PVT_INT);
+ if (!(stat & PVT_INT_STAT)) {
+ if (IS_ENABLED(CONFIG_PM))
+ pm_runtime_put(pvt->dev);
+ 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);
+
+ if (IS_ENABLED(CONFIG_PM))
+ pm_runtime_put(pvt->dev);
+
+ return IRQ_HANDLED;
+}
+
+static int eic7700_pvt_read_data(struct pvt_hwmon *pvt,
+ enum pvt_sensor_type type, long *val)
+{
+ unsigned long timeout;
+ u32 data;
+ int ret;
+
+ /*
+ * Wait for PVT conversion to complete and update the data cache. The
+ * data read procedure is following: set the requested PVT sensor mode,
+ * enable conversion, wait until conversion is finished, then disable
+ * conversion and IRQ, and read the cached data.
+ */
+ reinit_completion(&pvt->conversion);
+
+ eic7700_pvt_set_mode(pvt, pvt_info[type].mode);
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, PVT_ENA_EN);
+
+ /*
+ * Wait with timeout since in case if the sensor is suddenly powered
+ * down the request won't be completed and the caller will hang up on
+ * this procedure until the power is back up again. Multiply the
+ * timeout by the factor of two to prevent a false timeout.
+ */
+ timeout = 2 * usecs_to_jiffies(ktime_to_us(pvt->timeout));
+ ret = wait_for_completion_timeout(&pvt->conversion, timeout);
+
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, 0);
+ eic7700_pvt_update(pvt->regs + PVT_INT, PVT_INT_CLR, PVT_INT_CLR);
+
+ if (!ret)
+ synchronize_irq(pvt->irq);
+
+ data = READ_ONCE(pvt->data_cache);
+
+ if (!ret)
+ return -ETIMEDOUT;
+
+ if (type == PVT_TEMP)
+ *val = polynomial_calc(&poly_N_to_temp, data);
+ else
+ *val = polynomial_calc(&poly_N_to_volt, data);
+
+ return 0;
+}
+
+static const struct hwmon_channel_info *pvt_channel_info[] = {
+ HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_LABEL),
+ HWMON_CHANNEL_INFO(in, HWMON_I_INPUT | HWMON_I_LABEL),
+ NULL
+};
+
+static umode_t eic7700_pvt_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int ch)
+{
+ switch (type) {
+ case hwmon_temp:
+ switch (attr) {
+ case hwmon_temp_input:
+ case hwmon_temp_label:
+ return 0444;
+ }
+ break;
+ case hwmon_in:
+ switch (attr) {
+ case hwmon_in_input:
+ case hwmon_in_label:
+ return 0444;
+ }
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static int eic7700_pvt_hwmon_read(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int ch, long *val)
+{
+ struct pvt_hwmon *pvt = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_get_sync(pvt->dev);
+ if (ret < 0) {
+ dev_err(pvt->dev, "Failed to resume PVT device: %d\n", ret);
+ pm_runtime_put_noidle(pvt->dev);
+ return ret;
+ }
+
+ switch (type) {
+ case hwmon_temp:
+ switch (attr) {
+ case hwmon_temp_input:
+ ret = eic7700_pvt_read_data(pvt, ch, val);
+ break;
+ default:
+ ret = -EOPNOTSUPP;
+ }
+ break;
+ case hwmon_in:
+ if (attr == hwmon_in_input)
+ ret = eic7700_pvt_read_data(pvt, PVT_VOLT + ch, val);
+ else
+ ret = -EOPNOTSUPP;
+ break;
+ default:
+ ret = -EOPNOTSUPP;
+ }
+
+ pm_runtime_mark_last_busy(pvt->dev);
+ pm_runtime_put_autosuspend(pvt->dev);
+ return ret;
+}
+
+static int eic7700_pvt_hwmon_read_string(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int ch, const char **str)
+{
+ switch (type) {
+ case hwmon_temp:
+ if (attr == hwmon_temp_label) {
+ *str = pvt_info[ch].label;
+ return 0;
+ }
+ break;
+ case hwmon_in:
+ if (attr == hwmon_in_label) {
+ *str = pvt_info[PVT_VOLT + ch].label;
+ return 0;
+ }
+ break;
+ default:
+ break;
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static const struct hwmon_ops pvt_hwmon_ops = {
+ .is_visible = eic7700_pvt_hwmon_is_visible,
+ .read = eic7700_pvt_hwmon_read,
+ .read_string = eic7700_pvt_hwmon_read_string
+};
+
+static const struct hwmon_chip_info pvt_hwmon_info = {
+ .ops = &pvt_hwmon_ops,
+ .info = pvt_channel_info
+};
+
+static struct pvt_hwmon *eic7700_pvt_create_data(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct pvt_hwmon *pvt;
+
+ pvt = devm_kzalloc(dev, sizeof(*pvt), GFP_KERNEL);
+ if (!pvt)
+ return ERR_PTR(-ENOMEM);
+
+ pvt->dev = dev;
+ init_completion(&pvt->conversion);
+
+ return pvt;
+}
+
+static int eic7700_pvt_init_iface(struct pvt_hwmon *pvt)
+{
+ /*
+ * Make sure controller are disabled so not to accidentally have ISR
+ * executed before the driver data is fully initialized. Clear the IRQ
+ * status as well.
+ */
+ eic7700_pvt_update(pvt->regs + PVT_ENA, PVT_ENA_EN, 0);
+ eic7700_pvt_update(pvt->regs + PVT_INT, PVT_INT_CLR, PVT_INT_CLR);
+ readl(pvt->regs + PVT_INT);
+ readl(pvt->regs + PVT_DATA);
+
+ /* Setup default sensor mode and temperature trim. */
+ eic7700_pvt_set_mode(pvt, pvt_info[PVT_TEMP].mode);
+
+ /*
+ * Max conversion latency (~333 µs) derived from PVT spec:
+ * maximum sampling rate = 3000 samples/sec.
+ */
+ pvt->timeout = ns_to_ktime(PVT_TOUT_MIN);
+
+ eic7700_pvt_set_trim(pvt, PVT_TRIM_DEF);
+
+ return 0;
+}
+
+static int eic7700_pvt_request_irq(struct pvt_hwmon *pvt)
+{
+ struct platform_device *pdev = to_platform_device(pvt->dev);
+ int ret;
+
+ pvt->irq = platform_get_irq(pdev, 0);
+ if (pvt->irq < 0)
+ return pvt->irq;
+
+ ret = devm_request_threaded_irq(pvt->dev, pvt->irq,
+ eic7700_pvt_hard_isr, NULL,
+ IRQF_TRIGGER_HIGH, "pvt", pvt);
+ if (ret) {
+ dev_err(pvt->dev, "Couldn't request PVT IRQ\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int eic7700_pvt_create_hwmon(struct pvt_hwmon *pvt)
+{
+ pvt->hwmon = devm_hwmon_device_register_with_info(pvt->dev, "pvt",
+ pvt, &pvt_hwmon_info,
+ NULL);
+ if (IS_ERR(pvt->hwmon)) {
+ dev_err(pvt->dev, "Couldn't create hwmon device\n");
+ return PTR_ERR(pvt->hwmon);
+ }
+
+ return 0;
+}
+
+static void eic7700_pvt_disable_pm_runtime(void *data)
+{
+ struct pvt_hwmon *pvt = data;
+
+ pm_runtime_dont_use_autosuspend(pvt->dev);
+ pm_runtime_disable(pvt->dev);
+
+ if (!pm_runtime_status_suspended(pvt->dev)) {
+ clk_bulk_disable_unprepare(PVT_CLK_NUM, pvt->clks);
+ pm_runtime_set_suspended(pvt->dev);
+ }
+}
+
+static int eic7700_pvt_probe(struct platform_device *pdev)
+{
+ struct reset_control *rst;
+ struct pvt_hwmon *pvt;
+ int i, ret;
+
+ pvt = eic7700_pvt_create_data(pdev);
+ if (IS_ERR(pvt))
+ return PTR_ERR(pvt);
+
+ platform_set_drvdata(pdev, pvt);
+
+ pvt->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(pvt->regs))
+ return PTR_ERR(pvt->regs);
+
+ for (i = 0; i < PVT_CLK_NUM; i++)
+ pvt->clks[i].id = pvt_clk_names[i];
+
+ ret = devm_clk_bulk_get(&pdev->dev, PVT_CLK_NUM, pvt->clks);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "Couldn't get clock descriptors\n");
+
+ rst = devm_reset_control_get_exclusive_deasserted(&pdev->dev, NULL);
+ if (IS_ERR(rst))
+ return dev_err_probe(pvt->dev, PTR_ERR(rst),
+ "Couldn't get reset control\n");
+
+ ret = clk_bulk_prepare_enable(PVT_CLK_NUM, pvt->clks);
+ if (ret)
+ return dev_err_probe(pvt->dev, ret,
+ "Failed to enable clocks\n");
+
+ ret = eic7700_pvt_init_iface(pvt);
+ if (ret) {
+ clk_bulk_disable_unprepare(PVT_CLK_NUM, pvt->clks);
+ return ret;
+ }
+
+ if (IS_ENABLED(CONFIG_PM))
+ clk_bulk_disable_unprepare(PVT_CLK_NUM, pvt->clks);
+
+ 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);
+ if (ret) {
+ pm_runtime_put_noidle(&pdev->dev);
+ return dev_err_probe(&pdev->dev, ret,
+ "Can't register PM cleanup\n");
+ }
+
+ ret = eic7700_pvt_request_irq(pvt);
+ if (ret)
+ goto err_put_pm_runtime;
+
+ ret = eic7700_pvt_create_hwmon(pvt);
+ if (ret)
+ goto err_put_pm_runtime;
+
+ pm_runtime_put_autosuspend(&pdev->dev);
+
+ return 0;
+
+err_put_pm_runtime:
+ pm_runtime_put_noidle(&pdev->dev);
+ return ret;
+}
+
+static int __maybe_unused eic7700_pvt_runtime_resume(struct device *dev)
+{
+ struct pvt_hwmon *pvt = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_bulk_prepare_enable(PVT_CLK_NUM, pvt->clks);
+ if (ret) {
+ dev_err(dev, "Failed to enable clocks: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused eic7700_pvt_runtime_suspend(struct device *dev)
+{
+ struct pvt_hwmon *pvt = dev_get_drvdata(dev);
+
+ clk_bulk_disable_unprepare(PVT_CLK_NUM, pvt->clks);
+
+ return 0;
+}
+
+static const struct dev_pm_ops eic7700_pvt_pm_ops = {
+ SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
+ RUNTIME_PM_OPS(eic7700_pvt_runtime_suspend, eic7700_pvt_runtime_resume,
+ NULL)
+};
+
+static const struct of_device_id pvt_of_match[] = {
+ { .compatible = "eswin,eic7700-pvt"},
+ { }
+};
+MODULE_DEVICE_TABLE(of, pvt_of_match);
+
+static struct platform_driver pvt_driver = {
+ .probe = eic7700_pvt_probe,
+ .driver = {
+ .name = "eic7700-pvt",
+ .of_match_table = pvt_of_match,
+ .pm = pm_ptr(&eic7700_pvt_pm_ops),
+ },
+};
+module_platform_driver(pvt_driver);
+
+MODULE_AUTHOR("Yulin Lu <luyulin@eswincomputing.com>");
+MODULE_AUTHOR("Huan He <hehuan1@eswincomputing.com>");
+MODULE_DESCRIPTION("Eswin eic7700 PVT driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hwmon/eic7700-pvt.h b/drivers/hwmon/eic7700-pvt.h
new file mode 100644
index 000000000000..fb10f9e4e93a
--- /dev/null
+++ b/drivers/hwmon/eic7700-pvt.h
@@ -0,0 +1,99 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * ESWIN EIC7700 Voltage, Temperature sensor driver
+ *
+ * Copyright 2026, Beijing ESWIN Computing Technology Co., Ltd.
+ */
+#ifndef __HWMON_EIC7700_PVT_H__
+#define __HWMON_EIC7700_PVT_H__
+
+#include <linux/completion.h>
+#include <linux/hwmon.h>
+#include <linux/kernel.h>
+#include <linux/time.h>
+
+/* ESWIN EIC7700 PVT registers and their bitfields */
+#define PVT_TRIM 0x04
+#define PVT_MODE 0x08
+#define PVT_MODE_MASK GENMASK(2, 0)
+#define PVT_CTRL_MODE_TEMP 0x0
+#define PVT_CTRL_MODE_VOLT 0x4
+#define PVT_ENA 0x0c
+#define PVT_ENA_EN BIT(0)
+#define PVT_INT 0x10
+#define PVT_INT_STAT BIT(0)
+#define PVT_INT_CLR BIT(1)
+#define PVT_DATA 0x14
+#define PVT_DATA_OUT GENMASK(9, 0)
+
+/*
+ * PVT sensors-related limits and default values
+ * @PVT_TEMP_CHS: Number of temperature hwmon channels.
+ * @PVT_VOLT_CHS: Number of voltage hwmon channels.
+ * @PVT_TRIM_DEF: Default temperature sensor trim value (set a proper value
+ * when one is determined for ESWIN EIC7700 SoC).
+ * @PVT_TOUT_MIN: Minimal timeout between samples in nanoseconds.
+ */
+#define PVT_TEMP_CHS 1
+#define PVT_VOLT_CHS 1
+#define PVT_TRIM_DEF 0
+#define PVT_TOUT_MIN (NSEC_PER_SEC / 3000)
+
+/*
+ * enum pvt_sensor_type - ESWIN EIC7700 PVT sensor types (correspond to each PVT
+ * sampling mode)
+ * @PVT_TEMP: PVT Temperature sensor.
+ * @PVT_VOLT: PVT Voltage sensor.
+ */
+enum pvt_sensor_type {
+ PVT_TEMP = 0,
+ PVT_VOLT
+};
+
+#define PVT_CLK_NUM 2
+
+/*
+ * struct pvt_sensor_info - ESWIN EIC7700 PVT sensor informational structure
+ * @channel: Sensor channel ID.
+ * @label: hwmon sensor label.
+ * @mode: PVT mode corresponding to the channel.
+ * @type: Sensor type.
+ */
+struct pvt_sensor_info {
+ int channel;
+ const char *label;
+ u32 mode;
+ enum hwmon_sensor_types type;
+};
+
+#define PVT_SENSOR_INFO(_ch, _label, _type, _mode) \
+ { \
+ .channel = _ch, \
+ .label = _label, \
+ .mode = PVT_CTRL_MODE_ ##_mode, \
+ .type = _type, \
+ }
+
+/*
+ * struct pvt_hwmon - Eswin EIC7700 PVT private data
+ * @dev: device structure of the PVT platform device.
+ * @hwmon: hwmon device structure.
+ * @regs: pointer to the Eswin EIC7700 PVT registers region.
+ * @irq: PVT events IRQ number.
+ * @clks: PVT clock descriptors.
+ * @data_cache: data cache in raw format.
+ * @conversion: data conversion completion.
+ * @timeout: conversion timeout.
+ */
+struct pvt_hwmon {
+ struct device *dev;
+ struct device *hwmon;
+ void __iomem *regs;
+ int irq;
+ struct clk_bulk_data clks[PVT_CLK_NUM];
+ u32 data_cache;
+ struct completion conversion;
+ ktime_t timeout;
+};
+
+#endif /* __HWMON_EIC7700_PVT_H__ */
--
2.34.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