* [PATCH 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Ronald Claveau @ 2026-04-02 14:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260402-add-mcu-fan-khadas-vim4-v1-0-2b12eb4ac7b0@aliel.fr>
Add the T7 SOC compatible which fallback to AXG compatible.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../devicetree/bindings/i2c/amlogic,meson6-i2c.yaml | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
index c4cc8af182807..7b59b60b62e5b 100644
--- a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
@@ -16,10 +16,15 @@ allOf:
properties:
compatible:
- enum:
- - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
- - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
- - amlogic,meson-axg-i2c # AXG and compatible SoCs
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,t7-i2c
+ - const: amlogic,meson-axg-i2c
+ - enum:
+ - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
+ - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
+ - amlogic,meson-axg-i2c # AXG and compatible SoCs
reg:
maxItems: 1
--
2.49.0
^ permalink raw reply related
* [PATCH 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Ronald Claveau @ 2026-04-02 14:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260402-add-mcu-fan-khadas-vim4-v1-0-2b12eb4ac7b0@aliel.fr>
The Khadas VIM4 MCU register is slightly different
from previous boards' MCU.
This board also features a switchable power source for its fan.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 084960fd5a1fd..67769ef5d58b1 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- khadas,mcu # MCU revision is discoverable
+ - khadas,vim4-mcu
"#cooling-cells": # Only needed for boards having FAN control feature
const: 2
@@ -25,6 +26,10 @@ properties:
reg:
maxItems: 1
+ fan-supply:
+ description: Phandle to the regulator that powers the fan.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
required:
- compatible
- reg
--
2.49.0
^ permalink raw reply related
* [PATCH 0/8] Add VIM4 MCU/FAN support
From: Ronald Claveau @ 2026-04-02 14:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
The Khadas VIM4 board features a different MCU variant compared to
previous VIM boards.
While it shares the same I2C-based communication model,
it differs in some ways:
- A distinct register map with its own volatile/writeable register set
- A fan control with 0–100 levels instead of the 0–3 levels previously
- A fan power supply gated through a regulator
This series adds support for this new variant by:
1. Refactoring the khadas-mcu MFD driver to use per-variant data
structures (regmap config, cells, fan platform data),
and adding the khadas,vim4-mcu compatible string.
2. Extending the fan thermal driver to retrieve the fan register
and maximum level from platform_data,
and to optionally manage a power regulator for the fan supply.
3. Adding the corresponding DTS node for the VIM4, wiring the MCU to
the I2C AO_A bus and exposing it as a thermal cooling device.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Ronald Claveau (8):
dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
dt-bindings: i2c: amlogic: Add compatible for T7 SOC
mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
mfd: khadas-mcu: Add support for VIM4 MCU variant
thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
arm64: dts: amlogic: t7: Add i2c pinctrl node
arm64: dts: amlogic: t7: Add i2c controller node
arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node
.../bindings/i2c/amlogic,meson6-i2c.yaml | 13 ++-
.../devicetree/bindings/mfd/khadas,mcu.yaml | 5 +
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 13 +++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 20 ++++
drivers/mfd/khadas-mcu.c | 106 ++++++++++++++++++---
drivers/thermal/khadas_mcu_fan.c | 43 +++++++--
include/linux/mfd/khadas-mcu.h | 39 +++++++-
7 files changed, 216 insertions(+), 23 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* Re: [PATCH v2 2/3] riscv: dts: spacemit: enable USB3 on OrangePi R2S
From: Michael Opdenacker @ 2026-04-02 14:24 UTC (permalink / raw)
To: Chukun Pan, Yixun Lan
Cc: michael.opdenacker, Rob Herring, Paul Walmsley, Alexandre Ghiti,
Albert Ou, Conor Dooley, Palmer Dabbelt, Krzysztof Kozlowski,
linux-riscv, linux-kernel, devicetree, spacemit
In-Reply-To: <20260402100007.110201-3-amadeus@jmu.edu.cn>
Hi Chukun
On 4/2/26 12:00 PM, Chukun Pan wrote:
> Enable the DWC3 USB3.0 controller and its associated PHY on the
> OrangePi R2S. The USB regulator provides VBUS for USB2 and USB3
> ports, but the USB2 ports are handled by a separate controller.
>
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> .../boot/dts/spacemit/k1-orangepi-r2s.dts | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
> index 409a6db269ae..bc68721e6263 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
> +++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-r2s.dts
> @@ -40,6 +40,20 @@ vcc4v0: regulator-vcc4v0 {
> regulator-max-microvolt = <4000000>;
> vin-supply = <&vcc_5v0>;
> };
> +
> + vcc5v0_usb: regulator-vcc5v0-usb {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio K1_GPIO(126) GPIO_ACTIVE_HIGH>;
> + regulator-name = "vcc5v0_usb";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc_5v0>;
> + };
> +};
> +
> +&combo_phy {
> + status = "okay";
> };
>
> &emmc {
> @@ -109,3 +123,13 @@ &uart0 {
> pinctrl-0 = <&uart0_2_cfg>;
> status = "okay";
> };
> +
> +&usbphy2 {
> + status = "okay";
> +};
> +
> +&usb_dwc3 {
> + dr_mode = "host";
> + vbus-supply = <&vcc5v0_usb>;
> + status = "okay";
> +};
Thanks a lot for the patch!
Would you mind sharing your configuration with me (in PM?).
I can list the USB 3 hub, but I can't see the USB mass storage device
plugged in the USB3 port.
# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Thanks in advance
Cheers
Michael.
--
Root Commit
Embedded Linux Training and Consulting
https://rootcommit.com
^ permalink raw reply
* RE: [PATCH 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Biju Das @ 2026-04-02 14:10 UTC (permalink / raw)
To: Krzysztof Kozlowski, biju.das.au, Fabrizio Castro, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, magnus.damm
Cc: linux-spi@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <dde6b95c-2d18-4a44-9127-bce26c99901e@kernel.org>
Hi Krzysztof Kozlowski,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 04 March 2026 15:43
> Subject: Re: [PATCH 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
>
> On 04/03/2026 16:18, Biju Das wrote:
> > Hi Krzysztof Kozlowski,
> >
> > Thanks for the review.
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzk@kernel.org>
> >> Sent: 04 March 2026 15:04
> >> Subject: Re: [PATCH 1/2] dt-bindings: spi: renesas,rzv2h-rspi:
> >> Document RZ/G3L SoC
> >>
> >> On 04/03/2026 08:49, Biju wrote:
> >>> From: Biju Das <biju.das.jz@bp.renesas.com>
> >>>
> >>> Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible
> >>> with the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
> >>>
> >>> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> >>> ---
> >>> .../bindings/spi/renesas,rzv2h-rspi.yaml | 26 +++++++++++++++++++
> >>> 1 file changed, 26 insertions(+)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> >>> b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> >>> index cf8b733b766d..599c06ff08e5 100644
> >>> --- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> >>> +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> >>> @@ -13,6 +13,7 @@ properties:
> >>> compatible:
> >>> oneOf:
> >>> - enum:
> >>> + - renesas,r9a08g046-rspi # RZ/G3L
> >>> - renesas,r9a09g057-rspi # RZ/V2H(P)
> >>> - renesas,r9a09g077-rspi # RZ/T2H
> >>> - items:
> >>> @@ -85,6 +86,31 @@ required:
> >>>
> >>> allOf:
> >>> - $ref: spi-controller.yaml#
> >>> + - if:
> >>> + properties:
> >>> + compatible:
> >>> + contains:
> >>> + enum:
> >>> + - renesas,r9a08g046-rspi
> >>> + then:
> >>> + properties:
> >>> + clocks:
> >>> + maxItems: 2
> >>> +
> >>> + clock-names:
> >>> + items:
> >>> + - const: pclk
> >>> + - const: tclk
> >>> + dmas:
> >>> + maxItems: 2
> >>> +
> >>> + dma-names:
> >>> + maxItems: 2
> >>
> >> So even after my objections here:
> >> https://lore.kernel.org/all/9d08ddda-403e-458d-95e4-4e76915df85d@kern
> >> el.org/
> >>
> >> this was not fixed and Renesas did not provide actual cross-patch review.
> >
> > That patch is not correct. See below.
> >
> >>
> >> This is still probably wrong as pointed out by other patches by Renesas.
> >> Also, you cannot have flexible names.
> >
> > You can have "rx", "tx" in any order and {rx, tx} should be unique dma
> > specifier
>
> No. You cannot. I just told you so. Please read writing-bindings for arguments.
<snippet from writing-bindings >
- DO define properties in terms of constraints. How many entries? What are
possible values? What is the order? All these constraints represent the ABI
as well.
</snippet>
Is that the reason you're saying we cannot have flexible names for DMAs?
Are you expecting the RZ/G3L DMA entries to be like below? Please let me know.
This is not flexible — the user always needs to specify RX first, followed by TX.
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v2 2/2] hwmon:(pmbus/xdp720) Add support for efuse xdp720
From: ashish yadav @ 2026-04-02 14:09 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-hwmon,
devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <258dd77a-a8d9-4540-a32a-91a3f13c6ed5@roeck-us.net>
Hi Guenter,
Thanks for your valuable feedback and time.
Please find my response in-line.
With Best Regards,
Ashish Yadav
On Wed, Apr 1, 2026 at 9:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Hi,
>
> On 4/1/26 03:45, ASHISH YADAV wrote:
> > From: Ashish Yadav <ashish.yadav@infineon.com>
> >
> > Add the pmbus driver for Infineon XDP720 Digital eFuse Controller.
> >
> > Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
> > ---
> > XDP720 Digital eFuse Controller provides accurate system telemetry
> > (V, I, P, T) and reports analog current at the IMON pin for post-processing.
> >
> > The Current and Power measurement depends on the RIMON and GIMON values.
> > Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
> > https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
> >
> > The GIMON (microA/A) depends on the 10th bit of TELEMETRY_AVG PMBUS Register.
> > The value of RIMON (kohm) can be provided by the user through device tree using
> > infineon,rimon-micro-ohms property.
>
> Please have a look at
>
> https://sashiko.dev/#/patchset/20260401104550.115715-1-Ashish.Yadav%40infineon.com
>
> Main concern is the power measurement range, but also please use 1000000000000ULL
> as suggested.
Sure, We will look into it and get back to you.
> Thanks,
> Guenter
>
> > ---
> > drivers/hwmon/pmbus/Kconfig | 9 +++
> > drivers/hwmon/pmbus/Makefile | 1 +
> > drivers/hwmon/pmbus/xdp720.c | 123 +++++++++++++++++++++++++++++++++++
> > 3 files changed, 133 insertions(+)
> > create mode 100644 drivers/hwmon/pmbus/xdp720.c
> >
> > diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> > index fc1273abe357..c419e3ecce90 100644
> > --- a/drivers/hwmon/pmbus/Kconfig
> > +++ b/drivers/hwmon/pmbus/Kconfig
> > @@ -702,6 +702,15 @@ config SENSORS_XDP710
> > This driver can also be built as a module. If so, the module will
> > be called xdp710.
> >
> > +config SENSORS_XDP720
> > + tristate "Infineon XDP720 family"
> > + help
> > + If you say yes here you get hardware monitoring support for Infineon
> > + XDP720.
> > +
> > + This driver can also be built as a module. If so, the module will
> > + be called xdp720.
> > +
> > config SENSORS_XDPE152
> > tristate "Infineon XDPE152 family"
> > help
> > diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> > index d6c86924f887..1cac7ccae79f 100644
> > --- a/drivers/hwmon/pmbus/Makefile
> > +++ b/drivers/hwmon/pmbus/Makefile
> > @@ -68,6 +68,7 @@ obj-$(CONFIG_SENSORS_TPS546D24) += tps546d24.o
> > obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
> > obj-$(CONFIG_SENSORS_UCD9200) += ucd9200.o
> > obj-$(CONFIG_SENSORS_XDP710) += xdp710.o
> > +obj-$(CONFIG_SENSORS_XDP720) += xdp720.o
> > obj-$(CONFIG_SENSORS_XDPE122) += xdpe12284.o
> > obj-$(CONFIG_SENSORS_XDPE152) += xdpe152c4.o
> > obj-$(CONFIG_SENSORS_ZL6100) += zl6100.o
> > diff --git a/drivers/hwmon/pmbus/xdp720.c b/drivers/hwmon/pmbus/xdp720.c
> > new file mode 100644
> > index 000000000000..382dc3f9ce80
> > --- /dev/null
> > +++ b/drivers/hwmon/pmbus/xdp720.c
> > @@ -0,0 +1,123 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Hardware monitoring driver for Infineon XDP720 Digital eFuse Controller
> > + *
> > + * Copyright (c) 2026 Infineon Technologies. All rights reserved.
> > + */
> > +
> > +#include <linux/i2c.h>
> > +#include <linux/module.h>
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/of_device.h>
> > +#include <linux/bitops.h>
> > +#include <linux/math64.h>
> > +#include "pmbus.h"
> > +
> > +/*
> > + * The IMON resistor required to generate the system overcurrent protection.
> > + * Arbitrary default Rimon value: 2k Ohm
> > + */
> > +#define XDP720_DEFAULT_RIMON 2000000000 /* 2k ohm */
> > +#define XDP720_TELEMETRY_AVG 0xE9
> > +
> > +static struct pmbus_driver_info xdp720_info = {
> > + .pages = 1,
> > + .format[PSC_VOLTAGE_IN] = direct,
> > + .format[PSC_VOLTAGE_OUT] = direct,
> > + .format[PSC_CURRENT_OUT] = direct,
> > + .format[PSC_POWER] = direct,
> > + .format[PSC_TEMPERATURE] = direct,
> > +
> > + .m[PSC_VOLTAGE_IN] = 4653,
> > + .b[PSC_VOLTAGE_IN] = 0,
> > + .R[PSC_VOLTAGE_IN] = -2,
> > + .m[PSC_VOLTAGE_OUT] = 4653,
> > + .b[PSC_VOLTAGE_OUT] = 0,
> > + .R[PSC_VOLTAGE_OUT] = -2,
> > + /*
> > + * Current and Power measurement depends on the RIMON (kOhm) and
> > + * GIMON(microA/A) values.
> > + */
> > + .m[PSC_CURRENT_OUT] = 24668,
> > + .b[PSC_CURRENT_OUT] = 0,
> > + .R[PSC_CURRENT_OUT] = -4,
> > + .m[PSC_POWER] = 4486,
> > + .b[PSC_POWER] = 0,
> > + .R[PSC_POWER] = -1,
> > + .m[PSC_TEMPERATURE] = 54,
> > + .b[PSC_TEMPERATURE] = 22521,
> > + .R[PSC_TEMPERATURE] = -1,
> > +
> > + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT | PMBUS_HAVE_PIN |
> > + PMBUS_HAVE_TEMP | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_INPUT |
> > + PMBUS_HAVE_STATUS_TEMP,
> > +};
> > +
> > +static int xdp720_probe(struct i2c_client *client)
> > +{
> > + struct pmbus_driver_info *info;
> > + int ret;
> > + u32 rimon;
> > + int gimon;
> > +
> > + info = devm_kmemdup(&client->dev, &xdp720_info, sizeof(*info),
> > + GFP_KERNEL);
> > + if (!info)
> > + return -ENOMEM;
> > +
> > + ret = i2c_smbus_read_word_data(client, XDP720_TELEMETRY_AVG);
> > + if (ret < 0) {
> > + dev_err(&client->dev, "Can't get TELEMETRY_AVG\n");
> > + return ret;
> > + }
> > +
> > + ret >>= 10; /* 10th bit of TELEMETRY_AVG REG for GIMON Value */
> > + ret &= GENMASK(0, 0);
> > + if (ret == 1)
> > + gimon = 18200; /* output gain 18.2 microA/A */
> > + else
> > + gimon = 9100; /* output gain 9.1 microA/A */
> > +
> > + if (of_property_read_u32(client->dev.of_node,
> > + "infineon,rimon-micro-ohms", &rimon))
> > + rimon = XDP720_DEFAULT_RIMON; /* Default if not set via DT */
> > + if (rimon == 0)
> > + return -EINVAL;
> > +
> > + /* Adapt the current and power scale for each instance */
> > + info->m[PSC_CURRENT_OUT] = DIV64_U64_ROUND_CLOSEST((u64)
> > + info->m[PSC_CURRENT_OUT] * rimon * gimon, 1000000000000);
> > + info->m[PSC_POWER] = DIV64_U64_ROUND_CLOSEST((u64)
> > + info->m[PSC_POWER] * rimon * gimon, 1000000000000);
> > +
> > + return pmbus_do_probe(client, info);
> > +}
> > +
> > +static const struct of_device_id xdp720_of_match[] = {
> > + { .compatible = "infineon,xdp720" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, xdp720_of_match);
> > +
> > +static const struct i2c_device_id xdp720_id[] = {
> > + { "xdp720" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(i2c, xdp720_id);
> > +
> > +static struct i2c_driver xdp720_driver = {
> > + .driver = {
> > + .name = "xdp720",
> > + .of_match_table = xdp720_of_match,
> > + },
> > + .probe = xdp720_probe,
> > + .id_table = xdp720_id,
> > +};
> > +
> > +module_i2c_driver(xdp720_driver);
> > +
> > +MODULE_AUTHOR("Ashish Yadav <ashish.yadav@infineon.com>");
> > +MODULE_DESCRIPTION("PMBus driver for Infineon XDP720 Digital eFuse Controller");
> > +MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("PMBUS");
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: Krzysztof Kozlowski @ 2026-04-02 14:01 UTC (permalink / raw)
To: ashish yadav
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <CAJKbuCbs42aMKBXypkQeMNoBwp03aK2rzJp9as0NpZo==Ospng@mail.gmail.com>
On 02/04/2026 15:58, ashish yadav wrote:
>
>>> + The value of the RIMON resistor, in micro ohms, required to enable
>>> + the system overcurrent protection.
>>> +
>>
>> Missing supply
> Could you please provide more info here.
Your device has a supply, no? At least I found one in the datasheet.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: ashish yadav @ 2026-04-02 13:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260402-enlightened-analytic-leopard-ddc512@quoll>
Hi Krzysztof,
Thanks for your valuable feedback and time.
Please find my response in-line.
With Best Regards,
Ashish Yadav
On Thu, Apr 2, 2026 at 1:14 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Wed, Apr 01, 2026 at 04:15:49PM +0530, ASHISH YADAV wrote:
> > From: Ashish Yadav <ashish.yadav@infineon.com>
> >
> > Add documentation for the device tree binding of the XDP720 eFuse.
> >
> > Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
> > ---
> > This patch introduces a YAML schema describing the required and optional
> > properties for the XDP720 eFuse device node. It includes details on the
> > compatible string, register mapping, and rimon-micro-ohms(RIMON).
> >
> > The RIMON resistance is installed between the Imon pin and the ground
> > reference.
>
> Why are you adding second commit msg? Hardware description goes to
> commit msg. Redundant parts go to /dev/null.
>
>
ACK.
> > ---
> > .../bindings/hwmon/pmbus/infineon,xdp720.yaml | 51 +++++++++++++++++++
> > 1 file changed, 51 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
> > new file mode 100644
> > index 000000000000..bbde8ff92ae9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
> > @@ -0,0 +1,51 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +
> > +$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,xdp720.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Infineon XDP720 Digital eFuse Controller
> > +
> > +maintainers:
> > + - Ashish Yadav <ashish.yadav@infineon.com>
> > +
> > +description: |
> > + The XDP720 is an eFuse with integrated current sensor and digital
> > + controller. It provides accurate system telemetry (V, I, P, T) and
> > + reports analog current at the IMON pin for post-processing.
> > +
> > + Datasheet:
> > + https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - infineon,xdp720
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + infineon,rimon-micro-ohms:
> > + description: |
>
> Do not need '|' unless you need to preserve formatting.
>
ACK
> > + The value of the RIMON resistor, in micro ohms, required to enable
> > + the system overcurrent protection.
> > +
>
> Missing supply
Could you please provide more info here.
> > +required:
> > + - compatible
> > + - reg
>
> Here as well, most likely.
>
Could you please provide more info here.
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 6/7] MAINTAINERS: add exynos850-pmu.c to Exynos850 entry
From: Alexey Klimov @ 2026-04-02 13:57 UTC (permalink / raw)
To: Sam Protsenko, Krzysztof Kozlowski
Cc: linux-samsung-soc, Peter Griffin, André Draszik,
Conor Dooley, Alim Akhtar, Tudor Ambarus, Rob Herring,
Krzysztof Kozlowski, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <CAPLW+4=H_UkjwY2RJFPD9ekJh05MyuhKrymeuUYC4dX1WzF0wg@mail.gmail.com>
On Wed Apr 1, 2026 at 5:16 PM BST, Sam Protsenko wrote:
> Hi Krzysztof,
>
> On Wed, Apr 1, 2026 at 9:28 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 01/04/2026 06:51, Alexey Klimov wrote:
>> > Update Exynos850 entry to include new file
>> > drivers/soc/samsung/exynos850-pmu.c. Add myself as M
>> > there.
>> >
>> > Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> > ---
>> > MAINTAINERS | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index e14e6f874e05..4b28e92b4d9b 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -23601,6 +23601,7 @@ F: include/dt-bindings/clock/samsung,exynos2200-cmu.h
>> >
>> > SAMSUNG EXYNOS850 SoC SUPPORT
>> > M: Sam Protsenko <semen.protsenko@linaro.org>
>> > +M: Alexey Klimov <alexey.klimov@linaro.org>
>>
>> I am surprised to see this because I did not find many reviews from your
>> side before.
>>
>
> It was me who advised Alexey to add himself on the list, as he's doing
> a lot of Exynos850 related work nowadays, and we expect him to
> continue doing that. If you think it's too early, let's get back to
> this once there are more patches submitted under his name.
>
> Thanks!
>
>> Please first engage in reviewing of this platform, before assigning
>> yourself as a maintainer.
Okay, so it was done after Sam's advice. I can do one of these options:
- drop this patch;
- move it into separate entry in maintainers file;
- something else, please suggest.
I don't fancy having loose files (first option).
Best regards,
Alexey.
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Frank Li @ 2026-04-02 13:50 UTC (permalink / raw)
To: Florijan Plohl
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel, upstream
In-Reply-To: <20260402070826.970012-1-florijan.plohl@norik.com>
On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
what's means PEB-AV-18? Is it random board name?
> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
>
> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 4 +
> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
Any difference between 91 and 93, can use one overlay file?
Frank
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v4 0/5] Add initial Milk-V Duo S board support
From: Michael Opdenacker @ 2026-04-02 13:47 UTC (permalink / raw)
To: Joshua Milas
Cc: michael.opdenacker, tglx, robh, krzk+dt, conor+dt, pjw,
samuel.holland, unicorn_wang, inochiama, daniel.lezcano, palmer,
aou, alex, liujingqi, alexander.sverdlin, rabenda.cn, dlan,
chao.wei, anup, linux-kernel, devicetree, linux-riscv, sophgo,
hanguidong02
In-Reply-To: <ac5hFgLav_4oB2QA@sleek>
Hi Joshua
On 4/2/26 2:29 PM, Joshua Milas wrote:
> Hi Michael,
>
> Thanks for testing this. I am not seeing that issue on my arm64 or riscv side.
> I am able to add an IP and do anything I can think of on the arm64 side.
>
> [ 96.618687] stmmaceth 4070000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> [ 96.633977] stmmaceth 4070000.ethernet eth0: PHY [mdio_mux-0.0:01] driver [Generic PHY] (irq=POLL)
> [ 96.676436] dwmac1000: Master AXI performs any burst length
> [ 96.702852] stmmaceth 4070000.ethernet eth0: No Safety Features support found
> [ 96.748740] stmmaceth 4070000.ethernet eth0: IEEE 1588-2002 Timestamp supported
> [ 96.772880] stmmaceth 4070000.ethernet eth0: configuring for phy/internal link mode
> [ 1359.377528] stmmaceth 4070000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
>
> I can do the same on the riscv side but get a unhandled signal for TLS traffic
> which I believe is unrelated as it doesn't happen on adding an IP.
>
> I'll send over my configs to see if that helps.
I confirmed I managed to test the eth0 network interface on the riscv
side using the configuration you shared. It would take me more time to
test on arm64 :D|
You can send a update with your checkpatch fixes.
Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Thanks for everything!
Cheers
Michael.
--
Root Commit
Embedded Linux Training and Consulting
https://rootcommit.com
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: ashish yadav @ 2026-04-02 13:40 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Krzysztof Kozlowski, Ashish Yadav, Guenter Roeck, linux-hwmon,
devicetree, Conor Dooley, linux-kernel
In-Reply-To: <177487146147.2070608.2849563543220120287.robh@kernel.org>
Hi Rob,
Thanks for your feedback and time.
'make dt_binding_check' issue is address in:
https://lore.kernel.org/all/20260401104550.115715-1-Ashish.Yadav@infineon.com/
With Best Regards
Ashish Yadav
On Mon, Mar 30, 2026 at 5:21 PM Rob Herring (Arm) <robh@kernel.org> wrote:
>
>
> On Mon, 30 Mar 2026 15:53:44 +0530, ASHISH YADAV wrote:
> > From: Ashish Yadav <ashish.yadav@infineon.com>
> >
> > Add documentation for the device tree binding of the XDP720 eFuse.
> >
> > Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
> > ---
> >
> > This patch introduces a YAML schema describing the required and optional
> > properties for the XDP720 eFuse device node. It includes details on the
> > compatible string, register mapping, and rimon-micro-ohms(RIMON).
> >
> > The RIMON resistance is installed between the Imon pin and the ground
> > reference.
> > ---
> > .../bindings/hwmon/pmbus/infineon,xdp720.yaml | 52 +++++++++++++++++++
> > 1 file changed, 52 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml: properties:infineon,rimon-micro-ohms: '$ref' should not be valid under {'const': '$ref'}
> hint: Standard unit suffix properties don't need a type $ref
> from schema $id: http://devicetree.org/meta-schemas/core.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml: properties:infineon,rimon-micro-ohms: '$ref' should not be valid under {'const': '$ref'}
> hint: Standard unit suffix properties don't need a type $ref
> from schema $id: http://devicetree.org/meta-schemas/core.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.example.dtb: hwmon@11 (infineon,xdp720): infineon,rimon-micro-ohms: 1098000000 is not of type 'array'
> from schema $id: http://devicetree.org/schemas/property-units.yaml
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.example.dtb: hwmon@11 (infineon,xdp720): infineon,rimon-micro-ohms: 1098000000 is not of type 'array'
> from schema $id: http://devicetree.org/schemas/property-units.yaml
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260330102345.37065-2-Ashish.Yadav@infineon.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>
^ permalink raw reply
* Re: [PATCH v12 00/15] arm64/riscv: Add support for crashkernel CMA reservation
From: Borislav Petkov @ 2026-04-02 13:36 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <c6eb858c-5275-6fdc-b6e9-bd6d4b169e05@huawei.com>
On Thu, Apr 02, 2026 at 07:47:53PM +0800, Jinjie Ruan wrote:
> Thank you for the reminder and for your patience. I apologize for the
> frequent updates; I am becoming more familiar with the community's
> workflow.
Yap, and you can use that time while waiting to learn about it:
Documentation/process/
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* RE: [PATCH 0/2] Add Renesas RZ/G3L RSPI support
From: Biju Das @ 2026-04-02 13:32 UTC (permalink / raw)
To: Mark Brown, Krzysztof Kozlowski
Cc: biju.das.au, Fabrizio Castro, Rob Herring, Conor Dooley,
Geert Uytterhoeven, magnus.damm, linux-spi@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Prabhakar Mahadev Lad
In-Reply-To: <f6fd2e18-d5f8-40fe-a4d2-7894bd232da7@sirena.org.uk>
Hi Mark Brown,
Thanks for the feedback
> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> Sent: 02 April 2026 14:20
> Subject: Re: [PATCH 0/2] Add Renesas RZ/G3L RSPI support
>
> On Thu, Apr 02, 2026 at 01:00:28PM +0000, Biju Das wrote:
>
> > Gentle ping.
>
> There's strongly negative feedback from Krzysztof...
I believe Krzysztof is complaining about patch [1] and his
comments were addressed in [2].
>
> Please don't send content free pings and please allow a reasonable time for review. People get busy,
> go on holiday, attend conferences and so on so unless there is some reason for urgency (like critical
> bug fixes) please allow at least a couple of weeks for review. If there have been review comments then
> people may be waiting for those to be addressed.
>
> Sending content free pings adds to the mail volume (if they are seen at
> all) which is often the problem and since they can't be reviewed directly if something has gone wrong
> you'll have to resend the patches anyway, so sending again is generally a better approach though there
> are some other maintainers who like them - if in doubt look at how patches for the subsystem are
> normally handled.
There is no pending points, everything addressed in [2]. that is the reason for
sending gentle reminder.
if Krzysztof has any comments related to [3], I am happy to address.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml?h=next-20260401&id=4d28f38f64ef69ab27839069ef3346c3c878d137
[2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml?h=next-20260401&id=c2edd7841f58cf228347b91256f0d9efcc1a1f50
[3] https://lore.kernel.org/all/20260304074907.9697-2-biju.das.jz@bp.renesas.com/
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: exynos850: Add ap2apm mailbox
From: Krzysztof Kozlowski @ 2026-04-02 13:32 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <DHIPEQ4XDUI6.297HDXTP84FFP@linaro.org>
On 02/04/2026 15:30, Alexey Klimov wrote:
> On Thu Apr 2, 2026 at 9:01 AM BST, Krzysztof Kozlowski wrote:
>> On Thu, Apr 02, 2026 at 03:20:16AM +0100, Alexey Klimov wrote:
>>> Add mailbox node that describes AP-to-APM mailbox, that can be
>>> used for communicating with APM co-processor on Exynos850 SoCs.
>>>
>>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 9 +++++++++
>>
>> What DTS is doing in the middle of the patchset? If there is going to be
>> resend, then fix the order. If the order is intended, then most likely
>> NAK but I need somewhere explanation (but I really do not see the need
>> for it).
>>
>> Please read submitting patches (both documents).
>
> The dts change goes last in this series, the commit 3 out of 3.
> There is no DTS changes in the middle of the patchset as far as I can
> trust my eyes.
>
> If the order in this series is NACK, please explain why.
> I suspect that potential confusion is because 2 clock patches from
> prev series were accepted/merged, so dts change shifted from its 5th
> place to 3-rd place.
Oops, It is at the end! mutt does not order them by default when loaded
via b4, so it appeared in the middle and I did not pay attention enough.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1 07/22] dt-bindings: clock: Add StarFive JHB100 System-1 clock and reset generator
From: Changhuang Liang @ 2026-04-02 10:55 UTC (permalink / raw)
To: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Kees Cook,
Gustavo A . R . Silva, Richard Cochran
Cc: linux-clk, linux-kernel, devicetree, linux-riscv, linux-hardening,
netdev, Sia Jee Heng, Hal Feng, Ley Foon Tan, Changhuang Liang
In-Reply-To: <20260402105523.447523-1-changhuang.liang@starfivetech.com>
Add bindings for the System-1 clocks and reset generator (SYS1CRG) on
JHB100 SoC.
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
---
.../clock/starfive,jhb100-sys1crg.yaml | 71 +++++++++++++++++++
.../dt-bindings/clock/starfive,jhb100-crg.h | 20 ++++++
.../dt-bindings/reset/starfive,jhb100-crg.h | 13 ++++
3 files changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/starfive,jhb100-sys1crg.yaml
diff --git a/Documentation/devicetree/bindings/clock/starfive,jhb100-sys1crg.yaml b/Documentation/devicetree/bindings/clock/starfive,jhb100-sys1crg.yaml
new file mode 100644
index 000000000000..0cfeb8400b58
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/starfive,jhb100-sys1crg.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/starfive,jhb100-sys1crg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: StarFive JHB100 System-1 Clock and Reset Generator
+
+maintainers:
+ - Changhuang Liang <changhuang.liang@starfivetech.com>
+
+properties:
+ compatible:
+ const: starfive,jhb100-sys1crg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Main Oscillator (25 MHz)
+ - description: PLL0
+ - description: PLL1
+ - description: PLL2
+ - description: PLL4
+ - description: PLL5
+ - description: System-1 NPU 600MHz
+
+ clock-names:
+ items:
+ - const: osc
+ - const: pll0
+ - const: pll1
+ - const: pll2
+ - const: pll4
+ - const: pll5
+ - const: sys1_npu_600
+
+ '#clock-cells':
+ const: 1
+ description:
+ See <dt-bindings/clock/starfive,jhb100-crg.h> for valid indices.
+
+ '#reset-cells':
+ const: 1
+ description:
+ See <dt-bindings/reset/starfive-jhb100-crg.h> for valid indices.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@13004000 {
+ compatible = "starfive,jhb100-sys1crg";
+ reg = <0x13004000 0x4000>;
+ clocks = <&osc>, <&pll0>, <&pll1>,
+ <&syspll 0>, <&syspll 2>,
+ <&syspll 3>, <&sys0crg 61>;
+ clock-names = "osc", "pll0", "pll1", "pll2",
+ "pll4", "pll5", "sys1_npu_600";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
diff --git a/include/dt-bindings/clock/starfive,jhb100-crg.h b/include/dt-bindings/clock/starfive,jhb100-crg.h
index b257cd104a10..510a5c6fa89a 100644
--- a/include/dt-bindings/clock/starfive,jhb100-crg.h
+++ b/include/dt-bindings/clock/starfive,jhb100-crg.h
@@ -53,4 +53,24 @@
#define JHB100_SYS0CLK_GPU0_600 73
#define JHB100_SYS0CLK_GPU1_600 74
+/* SYS1CRG clocks */
+#define JHB100_SYS1CLK_APB_MAIN_SYS1 0
+#define JHB100_SYS1CLK_APB_SENSOR_ICG_BUF 1
+
+#define JHB100_SYS1CLK_GPIO_ESPI1_66 5
+
+#define JHB100_SYS1CLK_HOSTSS1_100 7
+#define JHB100_SYS1CLK_HOSTSS1_PHY_SCAN_1000_ICG_BUF 8
+#define JHB100_SYS1CLK_NPU_200 9
+#define JHB100_SYS1CLK_NPU_CORE_DIV 10
+#define JHB100_SYS1CLK_DOM_NPU_CORE_CLK 11
+#define JHB100_SYS1CLK_DOM_NPU_BUS_CLK 12
+#define JHB100_SYS1CLK_DOM_NPU_INIT_CLK 13
+#define JHB100_SYS1CLK_DOM_NPU_OSC_CLK 14
+#define JHB100_SYS1CLK_VOUT_100 15
+#define JHB100_SYS1CLK_VOUT_PIX0 16
+#define JHB100_SYS1CLK_VOUT_PIX1 17
+#define JHB100_SYS1CLK_BMCPER3_100 18
+#define JHB100_SYS1CLK_BMCPER3_125 19
+
#endif /* __DT_BINDINGS_CLOCK_STARFIVE_JHB100_H__ */
diff --git a/include/dt-bindings/reset/starfive,jhb100-crg.h b/include/dt-bindings/reset/starfive,jhb100-crg.h
index 71affdcdf733..9a0ab64abafa 100644
--- a/include/dt-bindings/reset/starfive,jhb100-crg.h
+++ b/include/dt-bindings/reset/starfive,jhb100-crg.h
@@ -27,4 +27,17 @@
#define JHB100_SYS0RST_BMCUSB_RSTN_BUS 23
#define JHB100_SYS0RST_BMCUSB_RSTN_CRG 24
+/* SYS1CRG resets */
+#define JHB100_SYS1RST_SYS1_IOMUX_PRESETN 1
+
+#define JHB100_SYS1RST_MAIN_RSTN_CHIPTOP_SENSOR 5
+
+#define JHB100_SYS1RST_VOUT_RSTN_HOST0 8
+#define JHB100_SYS1RST_VOUT_RSTN_HOST1 9
+#define JHB100_SYS1RST_HOSTSS1_RSTN_BUS_ESPI 10
+#define JHB100_SYS1RST_HOSTSS1_RSTN_BUS_PCIE 11
+#define JHB100_SYS1RST_HOSTSS1_RSTN_CRG 12
+#define JHB100_SYS1RST_BMCPERIPH3_RSTN_CRG 13
+#define JHB100_SYS1RST_BMCPERIPH3_RSTN_BUS 14
+
#endif /* __DT_BINDINGS_RESET_STARFIVE_JHB100_CRG_H__ */
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 3/3] arm64: dts: exynos850: Add ap2apm mailbox
From: Alexey Klimov @ 2026-04-02 13:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260402-free-foamy-gibbon-acad72@quoll>
On Thu Apr 2, 2026 at 9:01 AM BST, Krzysztof Kozlowski wrote:
> On Thu, Apr 02, 2026 at 03:20:16AM +0100, Alexey Klimov wrote:
>> Add mailbox node that describes AP-to-APM mailbox, that can be
>> used for communicating with APM co-processor on Exynos850 SoCs.
>>
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 9 +++++++++
>
> What DTS is doing in the middle of the patchset? If there is going to be
> resend, then fix the order. If the order is intended, then most likely
> NAK but I need somewhere explanation (but I really do not see the need
> for it).
>
> Please read submitting patches (both documents).
The dts change goes last in this series, the commit 3 out of 3.
There is no DTS changes in the middle of the patchset as far as I can
trust my eyes.
If the order in this series is NACK, please explain why.
I suspect that potential confusion is because 2 clock patches from
prev series were accepted/merged, so dts change shifted from its 5th
place to 3-rd place.
BR,
Alexey.
^ permalink raw reply
* Re: [RFC PATCH] dt-bindings: incomplete-devices: allow additional properties
From: Krzysztof Kozlowski @ 2026-04-02 13:26 UTC (permalink / raw)
To: Wolfram Sang, linux-renesas-soc
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260402123444.14177-2-wsa+renesas@sang-engineering.com>
On 02/04/2026 14:27, Wolfram Sang wrote:
> Linux test infrastructure is rightfully handled as 'incomplete devices.'
> It may need additional properties, though, like this mailbox test entry:
>
> mailbox_test_send_to_recv@c1000000 {
> compatible = "mailbox-test";
> broken-usage-of-incorrect-compatible;
Ah, and this part of your code should stop you right there. You cannot
have broken incorrect usage of DTS and claim that is reason to do any
change. The property is pretty clear - your DTS has broken way of using
incorrect compatible :).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH] dt-bindings: incomplete-devices: allow additional properties
From: Krzysztof Kozlowski @ 2026-04-02 13:24 UTC (permalink / raw)
To: Wolfram Sang, linux-renesas-soc
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260402123444.14177-2-wsa+renesas@sang-engineering.com>
On 02/04/2026 14:27, Wolfram Sang wrote:
> Linux test infrastructure is rightfully handled as 'incomplete devices.'
> It may need additional properties, though, like this mailbox test entry:
>
> mailbox_test_send_to_recv@c1000000 {
> compatible = "mailbox-test";
> broken-usage-of-incorrect-compatible;
> reg = <0x0 0xc1000000 0x0 0x100>;
> mboxes = <&mfis 0 (MFIS_CHANNEL_IICR | MFIS_CHANNEL_TX)>,
> <&mfis 0 (MFIS_CHANNEL_EICR | MFIS_CHANNEL_RX)>;
> mbox-names = "tx", "rx";
> };
>
> So, allow additional properties to prevent:
>
> .../arch/arm64/boot/dts/renesas/r8a78000-ironhide.dtb: mailbox_test_send_to_recv@c1000000 (mailbox-test): 'broken-usage-of-incorrect-compatible', 'mbox-names', 'mboxes', 'reg' do not match any of the regexes: '^pinctrl-[0-9]+$'
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
And with your patch how does the warning look like?
This solves nothing - the entire point is to have warning for
'broken-usage-of-incorrect-compatible'. If there are warnings for
mboxes, does not really matter.
> ---
>
> Maybe this is not worth the hazzle because these testing bindings should
> never be used in production DTs. During development, however, this is
> useful because it reduces noise, so real bugs become more visible.
>
> If this is not applicable for reasons I overlooked, another approach
> could be to use 'broken-usage-of-incorrect-compatible' as an early exit
> in fixup_node_props() of the validator?
>
> RFC because of all of the above. Is this worth it?
>
> Documentation/devicetree/bindings/incomplete-devices.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/incomplete-devices.yaml b/Documentation/devicetree/bindings/incomplete-devices.yaml
> index 4bb6c0141e9f..8f6df738f5e9 100644
> --- a/Documentation/devicetree/bindings/incomplete-devices.yaml
> +++ b/Documentation/devicetree/bindings/incomplete-devices.yaml
> @@ -282,4 +282,4 @@ required:
> - compatible
> - broken-usage-of-incorrect-compatible
>
> -additionalProperties: false
> +additionalProperties: true
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/2] Add Renesas RZ/G3L RSPI support
From: Mark Brown @ 2026-04-02 13:20 UTC (permalink / raw)
To: Biju Das
Cc: biju.das.au, Fabrizio Castro, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, magnus.damm,
linux-spi@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <TY3PR01MB1134614237922A87C70AA685C8651A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
On Thu, Apr 02, 2026 at 01:00:28PM +0000, Biju Das wrote:
> Gentle ping.
There's strongly negative feedback from Krzysztof...
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: clock: qcom: document the Milos GX clock controller
From: Krzysztof Kozlowski @ 2026-04-02 13:19 UTC (permalink / raw)
To: Luca Weiss
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm, linux-clk,
devicetree, linux-kernel
In-Reply-To: <DHIO0VFBOHNX.381P06A2CRHAZ@fairphone.com>
On 02/04/2026 14:24, Luca Weiss wrote:
>>>> + '#power-domain-cells':
>>>> + const: 1
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>
>>> reg should be the second property, like you have it in "required" part.
>>> I guess you copied it from kaanapali-gxclkctl.yaml, so lesson - qcom
>>> bindings have acceptable quality, but not good enough to take as correct
>>> starting point.
>>>
>>
>> OTOH, why this entire binding cannot be squashed in Kaanapali one?
>> What's the difference?
>
> There's no GMXC power domain on Milos. Apart from that they're
> compatible from a bindings perspective.
Ah, right, I missed only two items here.
>
> However it can re-use include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
> because the GX_CLKCTL_GX_GDSC definition would be identical.
Indeed and you use the same driver, so the header can be re-used. This
should be explained in the commit msg.
>
> And also the driver (which can be used as-is) would be identical. In
> that driver qcom,kaanapali-gxclkctl.h is used so it makes sense to keep
> with the kaanapali header, or not? Making a qcom,milos-gxclkctl.h with
> the same definition is not wanted?
>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1 0/5] Initial device tree support for StarFive JHB100 SoC
From: Changhuang Liang @ 2026-04-02 8:40 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Samuel Holland, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Daniel Lezcano, Emil Renner Berthing
Cc: Yixun Lan, Joel Stanley, Drew Fustini, Darshan Prajapati,
Guodong Xu, Michal Simek, Junhui Liu, Heinrich Schuchardt,
E Shattow, Icenowy Zheng, Anup Patel, linux-kernel, devicetree,
linux-riscv, Ji Sheng Teoh, Hal Feng, Ley Foon Tan,
Changhuang Liang, Michael Zhu
StarFive JHB100 SoC consists of 4 RISC-V low power Cores (Dubhe-70). It
also features various interfaces such as I2C, SPI, CAN, USB, MMC, Uart,
etc.
This patch series introduces initial SoC DTSI support for the StarFive
JHB100 SoC. The relevant dt-binding documentation has been updated
accordingly. Below is the list of IP blocks added in the initial SoC DTSI.
- StarFive Dubhe-70 CPU
- PMU
- PLIC
- CLINT
- UART
This patch series is based on tag 7.0-rc5 and has been tested on the
StarFive JHB100 EVB-1.
Ji Sheng Teoh (1):
dt-bindings: riscv: Add StarFive Dubhe-70 compatibles
Ley Foon Tan (4):
dt-bindings: timer: Add StarFive JHB100 clint
dt-bindings: interrupt-controller: Add StarFive JHB100 plic
dt-bindings: riscv: Add StarFive JHB100 SoC
riscv: dts: starfive: jhb100: Add JHB100 base DT
.../sifive,plic-1.0.0.yaml | 1 +
.../devicetree/bindings/riscv/cpus.yaml | 1 +
.../devicetree/bindings/riscv/starfive.yaml | 5 +
.../bindings/timer/sifive,clint.yaml | 1 +
MAINTAINERS | 6 +
arch/riscv/boot/dts/starfive/Makefile | 2 +
.../boot/dts/starfive/jhb100-evb1-eth.dts | 6 +
arch/riscv/boot/dts/starfive/jhb100-evb1.dtsi | 32 ++
arch/riscv/boot/dts/starfive/jhb100.dtsi | 326 ++++++++++++++++++
9 files changed, 380 insertions(+)
create mode 100644 arch/riscv/boot/dts/starfive/jhb100-evb1-eth.dts
create mode 100644 arch/riscv/boot/dts/starfive/jhb100-evb1.dtsi
create mode 100644 arch/riscv/boot/dts/starfive/jhb100.dtsi
base-commit: c369299895a591d96745d6492d4888259b004a9e
prerequisite-patch-id: 5735e71493da6858decc510a0e75967744b66b39
--
2.25.1
^ permalink raw reply
* [PATCH net-next v4 1/3] dt-bindings: net: document Microchip PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-04-02 13:12 UTC (permalink / raw)
To: netdev
Cc: Charles Perry, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree, linux-kernel
In-Reply-To: <20260402131229.319599-1-charles.perry@microchip.com>
This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely different
with pic64hpsc, hence the need for separate documentation.
The hardware supports C22 and C45.
The documentation recommends an input clock of 156.25MHz and a prescaler
of 39, which yields an MDIO clock of 1.95MHz.
The hardware supports an interrupt pin to signal transaction completion
which is not strictly needed as the software can also poll a "TRIGGER"
bit for this.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
---
Notes:
Changes in v4: none
Changes in v3: none
Changes in v2:
- Make "clocks" and "interrupts" required (Andrew)
- Add a default value to "clock-frequency" (Andrew)
.../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
diff --git a/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
new file mode 100644
index 000000000000..d690afe3d3cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,pic64hpsc-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC64-HPSC/HX MDIO controller
+
+maintainers:
+ - Charles Perry <charles.perry@microchip.com>
+
+description: |
+ Microchip PIC64-HPSC/HX SoCs have two MDIO bus controller. This MDIO bus
+ controller supports C22 and C45 register access. It is named "MDIO Initiator"
+ in the documentation.
+
+allOf:
+ - $ref: mdio.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: microchip,pic64hpsc-mdio
+ - items:
+ - const: microchip,pic64hx-mdio
+ - const: microchip,pic64hpsc-mdio
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ default: 2500000
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mdio@4000C21E000 {
+ compatible = "microchip,pic64hpsc-mdio";
+ reg = <0x400 0x0C21E000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&svc_clk>;
+ interrupt-parent = <&saplic0>;
+ interrupts = <168 IRQ_TYPE_LEVEL_HIGH>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v4 0/3] Add support for PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-04-02 13:12 UTC (permalink / raw)
To: netdev
Cc: Charles Perry, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Russell King, devicetree
Hello,
This series adds a driver for the two MDIO controllers of PIC64-HPSC/HX.
The hardware supports C22 and C45 but only C22 is implemented for now.
This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely different
with pic64hpsc, hence the need for a separate driver.
The documentation recommends an input clock of 156.25MHz and a prescaler of
39, which yields an MDIO clock of 1.95MHz.
This was tested on Microchip HB1301 evalkit which has a VSC8574 and a
VSC8541 with clock frequencies of 0.6, 1.95 and 2.5 MHz.
This series also adds a PHY write barrier when disabling PHY interrupts as
discussed in [1].
Thanks,
Charles
[1]: https://lore.kernel.org/all/acvUqDgepCIScs8M@shell.armlinux.org.uk/
Changes in v4:
- 3/3: Add the PHY barrier patch (Russell, Andrew)
- 2/3: return FIELD_GET() directly instead of using "ret" (Russell)
Changes in v3:
- 2/2: Add a MAINTAINERS entry (Jakub)
Changes in v2:
- 1/2: Make "clocks" and "interrupts" required (Andrew)
- 1/2: Add a default value to "clock-frequency" (Andrew)
- 2/2: Remove #define for unused registers (Maxime)
- 2/2: Add "c22" to clause 22 read/write ops (Maxime)
- 2/2: Remove the call to platform_set_drvdata() (Andrew)
- 2/2: Make the clock mandatory (Andrew)
- 2/2: Use 2.5MHz if no clock-frequency was specified (Andrew)
- 2/2: Change the error message for bad clock-frequency (Andrew)
- 2/2: Fix a use without initialization on bus_freq (Andrew)
CC: Andrew Lunn <andrew+netdev@lunn.ch>
CC: "David S. Miller" <davem@davemloft.net>
CC: Eric Dumazet <edumazet@google.com>
CC: Jakub Kicinski <kuba@kernel.org>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Rob Herring <robh@kernel.org>
CC: Krzysztof Kozlowski <krzk+dt@kernel.org>
CC: Conor Dooley <conor+dt@kernel.org>
CC: Heiner Kallweit <hkallweit1@gmail.com>
CC: Russell King <linux@armlinux.org.uk>
CC: netdev@vger.kernel.org
CC: devicetree@vger.kernel.org
Charles Perry (3):
dt-bindings: net: document Microchip PIC64-HPSC/HX MDIO controller
net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
net: phy: add a PHY write barrier when disabling interrupts
.../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++
MAINTAINERS | 6 +
drivers/net/mdio/Kconfig | 7 +
drivers/net/mdio/Makefile | 1 +
drivers/net/mdio/mdio-pic64hpsc.c | 190 ++++++++++++++++++
drivers/net/phy/phy.c | 27 ++-
6 files changed, 298 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
create mode 100644 drivers/net/mdio/mdio-pic64hpsc.c
--
2.47.3
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Biju @ 2026-04-02 13:10 UTC (permalink / raw)
To: Fabrizio Castro, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-spi, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260402131020.143123-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible with
the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* Collected tag
---
.../bindings/spi/renesas,rzv2h-rspi.yaml | 26 +++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
index 2c9045fd51de..b4358922487f 100644
--- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
+++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
@@ -13,6 +13,7 @@ properties:
compatible:
oneOf:
- enum:
+ - renesas,r9a08g046-rspi # RZ/G3L
- renesas,r9a09g057-rspi # RZ/V2H(P)
- renesas,r9a09g077-rspi # RZ/T2H
- items:
@@ -90,6 +91,31 @@ required:
allOf:
- $ref: spi-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a08g046-rspi
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: tclk
+ dmas:
+ maxItems: 2
+
+ dma-names:
+ maxItems: 2
+
+ required:
+ - resets
+ - reset-names
+
- if:
properties:
compatible:
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox