Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v2 3/4] staging: iio: magnetometer: Add QST QMC5883P driver
From: Hardik Phalet @ 2026-04-12  9:55 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Hardik Phalet
  Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brigham Campbell,
	Shuah Khan, linux-iio, devicetree, linux-kernel, linux-staging
In-Reply-To: <2026041027-hatless-swinger-eae1@gregkh>

On Fri Apr 10, 2026 at 10:58 AM IST, Greg Kroah-Hartman wrote:
> On Thu, Apr 09, 2026 at 09:07:41PM +0000, Hardik Phalet wrote:
>> Add an IIO driver for the QST QMC5883P, a 3-axis anisotropic
>> magneto-resistive (AMR) magnetometer with a 16-bit ADC, communicating
>> over I2C. There is no existing upstream driver for this device.
>
> Sorry, but no new iio drivers should be added to staging.  Take the time
> to do it right and put it into drivers/iio/ from the beginning.
> Otherwise this will just take more time and effort to get it into that
> location in the end (i.e. doing it right is simpler/faster.)
>
> thanks,
>
> greg k-h

Noted Greg, I will move it to /drivers/iio in the next version.
Thanks for the review. I appreciate your time.

Regards,
Hardik



^ permalink raw reply

* Re: [PATCH 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Krzysztof Kozlowski @ 2026-04-12  9:55 UTC (permalink / raw)
  To: Jian Hu, Neil Armstrong, Jerome Brunet, Kevin Hilman,
	Michael Turquette, Martin Blumenstingl, robh+dt, Rob Herring
  Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <20260410100329.3167482-3-jian.hu@amlogic.com>

On 10/04/2026 12:03, Jian Hu wrote:
> Add support for the A1 and T7 SoC family in amlogic clk measure.
> 
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
>  drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++++++++
>  1 file changed, 272 insertions(+)
> 
> diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
> index d862e30a244e..083524671b76 100644
> --- a/drivers/soc/amlogic/meson-clk-measure.c
> +++ b/drivers/soc/amlogic/meson-clk-measure.c
> @@ -787,6 +787,258 @@ static const struct meson_msr_id clk_msr_s4[] = {
>  
>  };
>  
> +static struct meson_msr_id clk_msr_a1[] = {

And existing code uses what sort of array? Seems you send us obsolete or
downstream code.

Best regards,
Krzysztof

^ permalink raw reply

* Re: [PATCH v2 3/4] staging: iio: magnetometer: Add QST QMC5883P driver
From: Hardik Phalet @ 2026-04-12  9:54 UTC (permalink / raw)
  To: David Lechner, Hardik Phalet, Greg Kroah-Hartman
  Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Brigham Campbell, Shuah Khan,
	linux-iio, devicetree, linux-kernel, linux-staging
In-Reply-To: <736964f9-1e93-47e7-80ca-1a89f239a353@baylibre.com>

On Sat Apr 11, 2026 at 1:32 AM IST, David Lechner wrote:
> On 4/9/26 4:07 PM, Hardik Phalet wrote:
>
> This is a little bit much to review all in one patch. Could be nice
> to split out power management to a separate patch.
>
> Oversampling/downsampling could be split to a separate patch or two
> as well.
>
Noted David. I will handle it in v3. I think downsampling can be another
patch.

>> +#define QMC5883P_REG_Y_MSB 0x04
>> +#define QMC58
>> 83P_REG_Z_LSB 0x05
>
> Were you manually editing the patch?
No. Maybe it's my email client (AERC). I will make sure the next version
is tight.

>
>> +#define QMC5883P_RSTCTRL_SET_RESET \
>> +	0x00 /* Set and reset on, i.e. the offset of device is renewed */
>> +#define QMC5883P_RSTCTRL_SET_ONLY 0x01 /* Set only on */
>> +#define QMC5883P_RSTCTRL_OFF 0x02 /* Set
>> and reset off */
>
> Or maybe you mail client mangled the patch? These wraps are
> happening in many places.
>
Yes. Exactly this.

>> +	if (regval != QMC5883P_CHIP_ID)
>> +		return dev_err_probe(data->dev, -ENODEV,
>
> We don't consider ID match an error. It has happened too many times
> that there is a compatible part with a different ID. This can just
> be dev_info() and return success.
>
Noted. Will handle in v3.

>> +static int qmc5883p_chip_init(struct qmc5883p_data *data)
>> +{
>> +	int ret;
>> +
>> +	ret = regmap_field_write(data->rf.sftrst, 1);
>> +	if (ret)
>> +		return ret;
>> +
>> +	usleep_range(1000, 2000);
>
> Use fsleep() instead and add a comment explaining why this specific duration
> was selected.
>
Noted, will handle in v3.

>> +	ret = regmap_field_write(data->rf.odr, QMC5883P_DEFAULT_ODR);
>> +	if (ret)
>> +		return ret;
>
> Since we just reset the chip, why do we need to set everything to a
> new default instead of using the chip's default? If there is a good
> reason, add a comment, otherwise we can leave this out.
>
These were simply more aligned with my usecase, so more of a development
artifact. Chip defaults are sufficient. I will leave this out. 

>> +
>> +	return regmap_field_write(data->rf.mode, QMC5883P_MODE_NORMAL);
>
> Does this start sampling? Seems like it could be out of place here.
>
Yes, normal mode starts sampling data. Your point makes sense, I will
remove it in the next version. Incorrect mental model, I apologise.

>> +	ret = regmap_read_poll_timeout(data->regmap, QMC5883P_REG_STATUS,
>> +				       status, status & QMC5883P_STATUS_DRDY,
>> +				       QMC5883P_DRDY_POLL_US, 150000);
>
> Numbers with lots of 0s are easier to read as 150 * (MICRO / MILLI).
>
My bad, will handle in v3.

>> +static IIO_DEVICE_ATTR(downsampling_ratio, 0644, downsampling_ratio_show,
>> +		       downsampling_ratio_store, 0);
>> +static IIO_CONST_ATTR(downsampling_ratio_available, "1 2 4 8");
>
> As mentioned in the cover letter, we'd like to know more about what
> this actually does. If there is a good reason it doesn't fit with
> any existing filter attribute, then we'll need a patch to document
> the sysfs ABI as well.
>
In the device datasheet, OSR2("Down sampling ratio") is mentioned like this:
"Another filter is added for better noise performance; the depth can be
adjusted through OSR2". OSR2's defintion is called "down sampling ratio"
in a table. Nowhere else. I didn't know what attribute to map it to in
this case.

> Could save some dupilcation by making a macro that takes X/Y/Z
> as parameter. e.g.
>
> #define QMC5883P_CHAN(ch) \
> 	...				\
> 	.channel2 = IIO_MOD_##ch,	\
> 	...				\
> 	.address = AXIS_##ch,		\
> 	...
>
Noted. Will do this in v3.

>> +	ret = devm_regulator_get_enable_optional(dev, "vdd");
>> +	if (ret && ret != -ENODEV)
>> +		return dev_err_probe(dev, ret,
>> +				"failed to get vdd regulator\n");
>> +
>> +	/* Datasheet specifies up to 50 ms supply ramp + 250 us POR time. */
>> +	fsleep(50000);
>> +
>> +	i2c_set_clientdata(client, indio_dev);
>> +
>> +	ret = qmc5883p_rf_init(data);
>
> Would be more logical to move this up right after regmap is declared.
>
Makes sense, I will move it up in v3.

>> +	ret = devm_iio_device_register(dev, indio_dev);
>
> Usually, we just return directly here. This pretty much doesn't ever fail.
>
Okay. Will remove the dev_err_probe() in v3. 

>> +	ret = regmap_field_write(data->rf.mode, QMC5883P_MODE_NORMAL);
>> +	if (ret)
>> +		return ret;
>> +
>> +	usleep_range(10000, 11000);
>
> Again, fsleep() and comment.
>
Noted.


>> +static const struct i2c_device_id qmc5883p_id[] = {
>> +	{ "qmc5883p", 0 },
>> +	{},
>
> IIO style for this is:
>
> 	{ }
>
> space between braces and no trailing comma.
>
Noted. Will take it up in v3.

Thanks for the in-depth review David. I really appreciate it.

Regards,
Hardik


^ permalink raw reply

* Re: [PATCH v2] dt-bindings: ARM: arm,vexpress-scc: convert to DT schema
From: Krzysztof Kozlowski @ 2026-04-12  9:50 UTC (permalink / raw)
  To: Khushal Chitturi
  Cc: robh, krzk+dt, conor+dt, liviu.dudau, sudeep.holla, lpieralisi,
	pawel.moll, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260411183355.8847-1-khushalchitturi@gmail.com>

On Sun, Apr 12, 2026 at 12:03:55AM +0530, Khushal Chitturi wrote:
> Convert the ARM Versatile Express Serial Configuration Controller
> bindings to DT schema.
> 
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v2 20/21] dt-bindings: gpio: describe Waveshare GPIO controller
From: Krzysztof Kozlowski @ 2026-04-12  9:48 UTC (permalink / raw)
  To: Dmitry Baryshkov
  Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
	Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
	Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
	Linus Walleij, Bartosz Golaszewski, dri-devel, devicetree,
	linux-kernel, linux-gpio, Riccardo Mereu
In-Reply-To: <20260411-waveshare-dsi-touch-v2-20-75cdbeac5156@oss.qualcomm.com>

On Sat, Apr 11, 2026 at 03:10:40PM +0300, Dmitry Baryshkov wrote:
> The Waveshare DSI TOUCH family of panels has separate on-board GPIO
> controller, which controls power supplies to the panel and the touch
> screen and provides reset pins for both the panel and the touchscreen.
> Also it provides a simple PWM controller for panel backlight.
> 
> Add bindings for these GPIO controllers. As overall integration might be
> not very obvious (and it differs significantly from the bindings used by
> the original drivers), provide complete example with the on-board
> regulators and the DSI panel.
> 
> Tested-by: Riccardo Mereu <r.mereu@arduino.cc>

You cannot test a binding, it is not possible. Otherwise explain me how
did you copy it to the device and what sort of device runs YAML.

The tag was given here explicitly, so I really do not understand this. I
could imagine tags coming from a reply to the cover letter, but adding
tag here? That's just fake test.

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v2 04/21] dt-bindings: display/panel: ilitek,ili9881c: describe Waveshare panel
From: Krzysztof Kozlowski @ 2026-04-12  9:46 UTC (permalink / raw)
  To: Dmitry Baryshkov
  Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
	Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
	Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
	Linus Walleij, Bartosz Golaszewski, dri-devel, devicetree,
	linux-kernel, linux-gpio
In-Reply-To: <20260411-waveshare-dsi-touch-v2-4-75cdbeac5156@oss.qualcomm.com>

On Sat, Apr 11, 2026 at 03:10:24PM +0300, Dmitry Baryshkov wrote:
> Describe Waveshare 7" DSI panel which uses ILI9881 as a panel
> controller. This panel requires two voltags supplies, so add separate
> iovcc supply.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


^ permalink raw reply

* [PATCH v2 4/4] arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling
From: Frank Wunderlich @ 2026-04-12  9:23 UTC (permalink / raw)
  To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley
  Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
	devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260412092333.6371-1-linux@fw-web.de>

From: Frank Wunderlich <frank-w@public-files.de>

The active-high property in base-dt cannot be overwritten and must be
set in separate overlay.

Fixes: f397471a6a8c ("arm64: dts: mediatek: mt7988: Add devicetree for BananaPi R4 Pro")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 arch/arm64/boot/dts/mediatek/Makefile         |  8 ++++++++
 .../mt7988a-bananapi-bpi-r4-pro-cn13.dtso     | 20 +++++++++++++++++++
 .../mt7988a-bananapi-bpi-r4-pro-cn14.dtso     | 20 +++++++++++++++++++
 .../mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi |  2 --
 4 files changed, 48 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
 create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 387faa9c2a09..a86fb313b1a9 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -47,6 +47,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-2g5.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-emmc.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-4e.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn13.dtbo
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn14.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn15.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn18.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-emmc.dtbo
@@ -70,18 +72,24 @@ mt7988a-bananapi-bpi-r4-2g5-sd-dtbs := \
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-2g5-sd.dtb
 mt7988a-bananapi-bpi-r4-pro-8x-emmc-dtbs := \
 	mt7988a-bananapi-bpi-r4-pro-8x.dtb \
+	mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
+	mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
 	mt7988a-bananapi-bpi-r4-pro-emmc.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-emmc.dtb
 mt7988a-bananapi-bpi-r4-pro-8x-sd-dtbs := \
 	mt7988a-bananapi-bpi-r4-pro-8x.dtb \
+	mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
+	mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
 	mt7988a-bananapi-bpi-r4-pro-sd.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb
 mt7988a-bananapi-bpi-r4-pro-8x-sd-cn15-dtbs := \
 	mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb \
+	mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
 	mt7988a-bananapi-bpi-r4-pro-cn15.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd-cn15.dtb
 mt7988a-bananapi-bpi-r4-pro-8x-sd-cn18-dtbs := \
 	mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb \
+	mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
 	mt7988a-bananapi-bpi-r4-pro-cn18.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd-cn18.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8167-pumpkin.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
new file mode 100644
index 000000000000..973b76ba0cbf
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2025 MediaTek Inc.
+ * Author: Frank Wunderlich <frank-w@public-files.de>
+ */
+
+/* This enables key-m slot CN13 on pcie2(11280000 1L0) on BPI-R4-Pro */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	compatible = "bananapi,bpi-r4-pro", "mediatek,mt7988a";
+};
+
+&{/soc/pinctrl@1001f000/pcie-2-hog} {
+	output-high;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
new file mode 100644
index 000000000000..90b2a64459c3
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2025 MediaTek Inc.
+ * Author: Frank Wunderlich <frank-w@public-files.de>
+ */
+
+/* This enables key-m slot CN14 on pcie3(11290000 1L1) on BPI-R4-Pro */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	compatible = "bananapi,bpi-r4-pro", "mediatek,mt7988a";
+};
+
+&{/soc/pinctrl@1001f000/pcie-3-hog} {
+	output-high;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index bbd6c16a8cb0..1eeb72108b9b 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -430,14 +430,12 @@ mux {
 	pcie-2-hog {
 		gpio-hog;
 		gpios = <79 GPIO_ACTIVE_HIGH>;
-		output-high;
 	};
 
 	/* 1L1 0=key-b (CN18), 1=key-m (CN14) */
 	pcie-3-hog {
 		gpio-hog;
 		gpios = <63 GPIO_ACTIVE_HIGH>;
-		output-high;
 	};
 
 	pwm0_pins: pwm0-pins {
-- 
2.43.0


^ permalink raw reply related

* [PATCH v2 0/4] some BPI-R4Pro dts updates
From: Frank Wunderlich @ 2026-04-12  9:23 UTC (permalink / raw)
  To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley
  Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
	devicetree, Daniel Golle, Andrew LaMarche

From: Frank Wunderlich <frank-w@public-files.de>

There are some parts of BPI-R4Pro DTS that need to be changed. Currently
there should be not much users of the mainline-dts and we noticed some
things while openwrt integration.

v2:
- added mgmt port renaming as this patch is still outstanding to keep
  all in one series
  https://patchwork.kernel.org/project/linux-mediatek/patch/20260303202006.37515-1-linux@fw-web.de/
- dropped default-state in gpio-leds patch as suggested by daniel

Frank Wunderlich (4):
  arm64: dts: mediatek: mt7988a-bpi-r4pro: rename mgmt port to lan5
  arm64: dts: mediatek: mt7988a-bpi-r4pro: drop duplicate fan properties
  arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
  arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling

 arch/arm64/boot/dts/mediatek/Makefile         |  8 ++++++++
 .../mt7988a-bananapi-bpi-r4-pro-cn13.dtso     | 20 +++++++++++++++++++
 .../mt7988a-bananapi-bpi-r4-pro-cn14.dtso     | 20 +++++++++++++++++++
 .../mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 15 +++-----------
 4 files changed, 51 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
 create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso

-- 
2.43.0


^ permalink raw reply

* [PATCH v2 2/4] arm64: dts: mediatek: mt7988a-bpi-r4pro: drop duplicate fan properties
From: Frank Wunderlich @ 2026-04-12  9:23 UTC (permalink / raw)
  To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley
  Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
	devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260412092333.6371-1-linux@fw-web.de>

From: Frank Wunderlich <frank-w@public-files.de>

These properties are already set in the original node and do not need
to be defined again.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
 .../boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi     | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 1175ee156cb3..759f608d1081 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -185,13 +185,6 @@ &eth {
 	status = "okay";
 };
 
-&fan {
-	pinctrl-0 = <&pwm0_pins>;
-	pinctrl-names = "default";
-	pwms = <&pwm 0 50000>;
-	status = "okay";
-};
-
 &gmac0 {
 	status = "okay";
 };
-- 
2.43.0


^ permalink raw reply related

* [PATCH v2 1/4] arm64: dts: mediatek: mt7988a-bpi-r4pro: rename mgmt port to lan5
From: Frank Wunderlich @ 2026-04-12  9:23 UTC (permalink / raw)
  To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley
  Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
	devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260412092333.6371-1-linux@fw-web.de>

From: Frank Wunderlich <frank-w@public-files.de>

It turns out that the label mgmt confuses users and now official case is
released where the port is labeled with number 5. So just rename it to
lan5 to follow naming convension (lan1-4 from mxl switch and lan6 for lan-
combo).

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
---
 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index a48132f09411..1175ee156cb3 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -207,7 +207,7 @@ &gsw_phy0_led0 {
 };
 
 &gsw_port0 {
-	label = "mgmt";
+	label = "lan5";
 };
 
 /* R4Pro has only port 0 connected, so disable the others */
-- 
2.43.0


^ permalink raw reply related

* [PATCH v2 3/4] arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
From: Frank Wunderlich @ 2026-04-12  9:23 UTC (permalink / raw)
  To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley
  Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
	devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260412092333.6371-1-linux@fw-web.de>

From: Frank Wunderlich <frank-w@public-files.de>

On the official case the red LED is named ERR, the blue LED is named ACT.​​​​​​​​​​​​​​​​
Reflect these labels in function and set them default off.

Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
v2:
- dropped default-state as suggested by daniel
---
 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 759f608d1081..bbd6c16a8cb0 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -61,14 +61,14 @@ gpio-leds {
 
 		led_red: sys-led-red {
 			color = <LED_COLOR_ID_RED>;
+			function = LED_FUNCTION_FAULT;
 			gpios = <&pca9555 15 GPIO_ACTIVE_HIGH>;
-			default-state = "on";
 		};
 
 		led_blue: sys-led-blue {
 			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_ACTIVITY;
 			gpios = <&pca9555 14 GPIO_ACTIVE_HIGH>;
-			default-state = "on";
 		};
 	};
 
-- 
2.43.0


^ permalink raw reply related

* Re: [PATCH v2 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Krzysztof Kozlowski @ 2026-04-12  9:20 UTC (permalink / raw)
  To: Andrea della Porta
  Cc: Uwe Kleine-König, linux-pwm, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
	Broadcom internal kernel review list, devicetree,
	linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
	Stanimir Varbanov, mbrugger
In-Reply-To: <6f0fa1a817b5af5040b652320daa7268297932a9.1775829499.git.andrea.porta@suse.com>

On Fri, Apr 10, 2026 at 04:09:57PM +0200, Andrea della Porta wrote:
> From: Naushir Patuck <naush@raspberrypi.com>
> 
> Add the devicetree binding documentation for the PWM
> controller found in the Raspberry Pi RP1 chipset.
> 
> Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> ---
>  .../bindings/pwm/raspberrypi,rp1-pwm.yaml     | 54 +++++++++++++++++++
>  1 file changed, 54 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
> 

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v2] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
From: Krzysztof Kozlowski @ 2026-04-12  9:18 UTC (permalink / raw)
  To: Anushka Badhe
  Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Heiko Stuebner, linux-sound, devicetree,
	linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260410055532.60868-1-anushkabadhe@gmail.com>

On Fri, Apr 10, 2026 at 11:25:32AM +0530, Anushka Badhe wrote:
> Convert the rockchip,rk3399-gru-sound.txt DT binding to DT Schema
> format.
> 
> Update rockchip,cpu from a single I2S controller phandle to a
> phandle-array. Add an optional second entry for the SPDIF controller,
> as seen in rk3399-gru.dtsi, required by boards with DisplayPort audio.
> 
> Signed-off-by: Anushka Badhe <anushkabadhe@gmail.com>
> ---
> Changes in v2:
> - Fix subject and body: "YAML Schema" -> "DT Schema"
> - Fix title: "ROCKCHIP" -> "Rockchip"
> - List items for rockchip,cpu with I2S and SPDIF descriptions
> - List items for rockchip,codec
> - Update descriptions for rockchip,cpu, rockchip,codec and
>   dmic-wakeup-delay-ms

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v2 5/5] arm64: dts: qcom: sdm845-xiaomi-beryllium-tianma: Disable MDSS
From: David Heidelberg @ 2026-04-12  9:03 UTC (permalink / raw)
  To: Dmitry Baryshkov
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Sam Day, linux-arm-msm, devicetree, linux-kernel,
	phone-devel, Petr Hodina
In-Reply-To: <eyg2ivnoe7weschcvyuhlzqfnqdfnomxc7b56kuypawj6ui7ds@tkdhm2ckrpq6>

On 12/04/2026 02:36, Dmitry Baryshkov wrote:
> On Fri, Apr 10, 2026 at 03:51:12PM +0200, David Heidelberg wrote:
>> On 18/03/2026 15:47, Dmitry Baryshkov wrote:
>>> On Tue, Mar 17, 2026 at 11:12:35PM +0100, David Heidelberg via B4 Relay wrote:
>>>> From: Petr Hodina <petr.hodina@protonmail.com>
>>>>
>>>> Currently the panel driver for tianma is broken.
>>>> Disable MDSS to prevent DRM taking over the framebuffer.
>>>
>>> I'd still hope that somebody can get it to work. I'd start by using
>>> prepare_prev_first. Sumit reported the panel as working in 2020 and I
>>> have no doubts that it was the case. Another option migt be something
>>> related to the dispcc (see my [1]).
>>
>> Sadly, the prepare_prev_first didn't solve the issue. The framebuffer ->
>> MDSS takover happens, but at greetd (login) loading screen goes black and
>> never restores.
>>
>> Will need more work.
> 
> Do you see a console _while_ it boots, after the handover? I'd check the
> mode programming. Maybe, disabling panel reset would also (temporarily)
> help.

When I get access to the phone for longer period of time I'll try to debug it 
step by step. This time I had only time to flash kernel and test if it boots 
with prepare_prev_first.

David

> 
>>
>> David>
>>> [1] https://lore.kernel.org/linux-arm-msm/20260217-sdm845-hdk-v1-1-866f1965fef7@oss.qualcomm.com/
> 

-- 
David Heidelberg


^ permalink raw reply

* Re: [PATCH v7 2/2] dt-bindings: embedded-controller: Add synology microp devices
From: Krzysztof Kozlowski @ 2026-04-12  8:26 UTC (permalink / raw)
  To: Markus Probst
  Cc: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
	Lee Jones, Pavel Machek, Miguel Ojeda, Boqun Feng, Gary Guo,
	Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
	Trevor Gross, Danilo Krummrich, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Greg Kroah-Hartman, platform-driver-x86, linux-leds,
	devicetree, linux-kernel, rust-for-linux
In-Reply-To: <20260411-synology_microp_initial-v7-2-9a3a094e763a@posteo.de>

On Sat, Apr 11, 2026 at 05:27:35PM +0200, Markus Probst wrote:
> +properties:
> +  compatible:
> +    enum:
> +      - synology,ds923p-microp
> +      - synology,ds918p-microp
> +      - synology,ds214play-microp
> +      - synology,ds225p-microp
> +      - synology,ds425p-microp
> +      - synology,ds710p-microp
> +      - synology,ds1010p-microp
> +      - synology,ds723p-microp
> +      - synology,ds1522p-microp
> +      - synology,rs422p-microp
> +      - synology,ds725p-microp
> +      - synology,ds118-microp
> +      - synology,ds124-microp
> +      - synology,ds223-microp
> +      - synology,ds223j-microp
> +      - synology,ds1823xsp-microp
> +      - synology,rs822p-microp
> +      - synology,rs1221p-microp
> +      - synology,rs1221rpp-microp
> +      - synology,ds925p-microp
> +      - synology,ds1525p-microp
> +      - synology,ds1825p-microp

Previous comment is not resolved. For example you stated that ds723p is
compatible with ds725p, so this should be expressed.

ds918p and ds415p as well. ds925p and several others you EXPLICITLY
wrote they are compatible:

"ds925p, ds1525p, ds1825p, ds1823xsp:
- supports fan rpm report via an adt7475 chip and therefore does not
have gpios for fan failure
- no system current sensor"

Probably many more cases, I did not verify all of them.

If there is going to be new version, please organize the patch
documenting the compatible (DT bindings) before the patch using that
compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46

> +
> +  fan-failure-gpios:
> +    description: GPIOs needed to determine which fans stopped working on a fan failure event.
> +    minItems: 2
> +    maxItems: 3
> +
> +required:
> +  - compatible

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: mmc: dw-mshc-common: add option for configuring DMA threshold
From: Kaustabh Chakraborty @ 2026-04-12  4:46 UTC (permalink / raw)
  To: Kaustabh Chakraborty, Krzysztof Kozlowski, Ulf Hansson,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaehoon Chung,
	Shawn Lin
  Cc: linux-mmc, devicetree, linux-kernel
In-Reply-To: <DHQW60ZTLODV.3C6OG2KUNVSBR@disroot.org>

On 2026-04-12 09:59 +05:30, Kaustabh Chakraborty wrote:
> On 2026-04-11 22:27 +02:00, Krzysztof Kozlowski wrote:
>> On 11/04/2026 21:43, Kaustabh Chakraborty wrote:
>>> Some controllers, such as certain Exynos SDIO ones, are unable to
>>> perform DMA transfers of small amount of bytes properly. Add a property
>>> to configure the DMA transfer threshold.
>>> 
>>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>>> ---
>>>  .../devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml          | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>> 
>>> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>>> index 6f11b2adf1036..1693277957a91 100644
>>> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>>> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>>> @@ -57,6 +57,14 @@ properties:
>>>        force fifo watermark setting accordingly.
>>>      $ref: /schemas/types.yaml#/definitions/flag
>>>  
>>> +  dma-threshold-bytes:
>>> +    description:
>>> +      DMA transfer takes place only if the transfer size is equal to or greater
>>> +      than the number of bytes defined by the threshold value. Some controllers are
>>> +      unable to perform the DMA transfer properly with small amounts of data.
>>
>> Looks like controller specific, thus should be deducible from the
>> compatible.
>
> "samsung,dma-threshold-bytes"? So you also suggest I move it to the
> Samsung's schema? Okay.

Ahh, nevermind I get it. A separate controller compatible which sets a
higher threshold.

>
>>
>> Best regards,
>> Krzysztof


^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: mmc: dw-mshc-common: add option for configuring DMA threshold
From: Kaustabh Chakraborty @ 2026-04-12  4:29 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Kaustabh Chakraborty, Ulf Hansson,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaehoon Chung,
	Shawn Lin
  Cc: linux-mmc, devicetree, linux-kernel
In-Reply-To: <6d692d1f-ab67-463a-9135-520a36977d5d@kernel.org>

On 2026-04-11 22:27 +02:00, Krzysztof Kozlowski wrote:
> On 11/04/2026 21:43, Kaustabh Chakraborty wrote:
>> Some controllers, such as certain Exynos SDIO ones, are unable to
>> perform DMA transfers of small amount of bytes properly. Add a property
>> to configure the DMA transfer threshold.
>> 
>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> ---
>>  .../devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml          | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>> index 6f11b2adf1036..1693277957a91 100644
>> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>> @@ -57,6 +57,14 @@ properties:
>>        force fifo watermark setting accordingly.
>>      $ref: /schemas/types.yaml#/definitions/flag
>>  
>> +  dma-threshold-bytes:
>> +    description:
>> +      DMA transfer takes place only if the transfer size is equal to or greater
>> +      than the number of bytes defined by the threshold value. Some controllers are
>> +      unable to perform the DMA transfer properly with small amounts of data.
>
> Looks like controller specific, thus should be deducible from the
> compatible.

"samsung,dma-threshold-bytes"? So you also suggest I move it to the
Samsung's schema? Okay.

>
> Best regards,
> Krzysztof


^ permalink raw reply

* Re: [PATCH 11/12] ASoC: dt-bindings: google,sc7280-herobrine: Add Radxa Dragon Q6A sound card
From: Xilin Wu @ 2026-04-12  3:47 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
	Judy Hsiao, linux-arm-msm, linux-kernel, devicetree,
	Konrad Dybcio, linux-sound
In-Reply-To: <20260408-pretty-poodle-from-atlantis-dfd1fb@quoll>

On 4/8/2026 4:48 PM, Krzysztof Kozlowski wrote:
> On Tue, Apr 07, 2026 at 11:20:03PM +0800, Xilin Wu wrote:
>> The Radxa Dragon Q6A can boot in EL2, allowing the kernel to access the
>> LPASS hardware directly. Add the compatible for it to the bindings.
> 
> You are not adding compatible for LPASS, but for the sound card. And
> since you mentioned it, what happens when you boot in EL1?
> 
> You need to post bindings for both cases.
> 
> Best regards,
> Krzysztof
> 
> 

Hi Krzysztof,

Thank you for the review. You are right that this patch adds a 
board-specific compatible for the sound card, not for the LPASS block 
itself.

For EL1, the default Dragon Q6A DTS already uses the generic
"qcom,qcs6490-rb3gen2-sndcard" compatible, and for the EL2 LPASS-CPU
variant I can also just keep using the generic
"google,sc7280-herobrine" compatible.

Would it be better if I simply drop this binding patch and keep both
cases on their existing generic compatibles instead of introducing
"radxa,dragon-q6a-sndcard"?

-- 
Best regards,
Xilin Wu <sophon@radxa.com>

^ permalink raw reply

* Re: [PATCH 03/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB 3.0 and HDMI ports
From: Xilin Wu @ 2026-04-12  3:14 UTC (permalink / raw)
  To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
	Liam Girdwood, Mark Brown, Judy Hsiao
  Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <eb745e3f-4bc6-4713-97aa-1a1a584c9a9d@oss.qualcomm.com>

On 4/8/2026 5:03 PM, Konrad Dybcio wrote:
> On 4/7/26 5:19 PM, Xilin Wu wrote:
>> This board doesn't feature a regular Type-C port. The usb_1_qmpphy's
> 
> I guess the receptacle on board is power-only?

Yes. The Type-C port is power only.

> 
>> RX1/TX1 pair is statically connected to the USB-A port, while its RX0/TX0
>> pair is connected to the RA620 DP-to-HDMI bridge.
>>
>> Add and enable the nodes for the features to work.
>>
>> Signed-off-by: Xilin Wu <sophon@radxa.com>
>> ---
>>   .../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts     | 152 +++++++++++++++++++++
>>   1 file changed, 152 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
>> index c961d3ec625f..8d649b3a1cfa 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
>> @@ -111,6 +111,71 @@ usb2_3_connector: endpoint {
>>   		};
>>   	};
>>   
>> +	usb3_con: connector {
> 
> This label is unused

Ack. I will remove the label.

> 
>> +		compatible = "usb-a-connector";
> 
> No vbus-supply?

It's supplied by vcc_5v_peri. I'll add it in v2.

> 
> [...]
> 
>> +&mdss_dp {
>> +	sound-name-prefix = "Display Port0";
> 
> Hmmmmm.. other platforms call it "DisplayPort0" (without a space)..
> But I suppose this name needs to match UCM..
> 
> We'd also normally push this property to the SoC DTSI

Actually I don't think the name is used in UCM. I can rename it and push 
the property to SoC DTSI if necessary.

> 
> Konrad
> 


-- 
Best regards,
Xilin Wu <sophon@radxa.com>

^ permalink raw reply

* Re: [PATCH 11/16] clk: tests: Add Kunit testing for nexus nodes
From: Stephen Boyd @ 2026-04-12  1:40 UTC (permalink / raw)
  To: Miquel Raynal (Schneider Electric), Antoine Tenart,
	Christian Marangi, Conor Dooley, David S. Miller,
	Geert Uytterhoeven, Herbert Xu, Jayesh Choudhary,
	Krzysztof Kozlowski, Magnus Damm, Michael Turquette,
	Olivia Mackall, Rob Herring, Thomas Gleixner
  Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
	devicetree, linux-kernel, linux-crypto, linux-renesas-soc,
	Miquel Raynal (Schneider Electric)
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-11-5e6ff7853994@bootlin.com>

Quoting Miquel Raynal (Schneider Electric) (2026-03-27 13:09:33)
> Add a nexus node with a child requesting a mapped clock in the fake DT
> overlay to verify that the parsing is also correctly working.
> 
> Suggested-by: Stephen Boyd <sboyd@kernel.org>
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
> ---
>  drivers/clk/clk_test.c                   | 20 ++++++++++++++++++++
>  drivers/clk/kunit_clk_parse_clkspec.dtso | 10 ++++++++++
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c
> index 8a17ad0d185f..cb0071955146 100644
> --- a/drivers/clk/clk_test.c
> +++ b/drivers/clk/clk_test.c
> @@ -3660,10 +3660,30 @@ static void clk_parse_and_get_parent_name(struct kunit *test)
>                            clk_parse_clkspec_1_init_data.name);
>  }
>  
> +static void clk_parse_and_get_nexus(struct kunit *test)

of_clk_get_hw_maps_thru_nexus()

> +{
> +       struct clk_parse_clkspec_ctx *ctx = test->priv;
> +       struct clk_hw *hw1, *hw2;
> +       struct device_node *np;
> +
> +       /* Get clocks by index */
> +       np = of_find_node_by_name(NULL, "kunit-clock-nexus-child");
> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> +       hw1 = of_clk_get_hw(np, 0, NULL);
> +       KUNIT_EXPECT_NOT_ERR_OR_NULL(test, hw1);
> +
> +       hw2 = of_clk_get_hw(ctx->cons_np, 1, NULL);
> +       KUNIT_EXPECT_NOT_ERR_OR_NULL(test, hw2);
> +       KUNIT_EXPECT_PTR_EQ(test, hw1, hw2);

I think hw2 is expected? Rewrite it like this?

	struct clk_parse_clkspec_ctx *ctx = test->priv;
	struct clk_hw *expected;
	struct device_node *np;
	
	np = of_find_node_by_name(NULL, "kunit-clock-nexus-child");
	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
	expected = of_clk_get_hw(ctx->cons_np, 1, NULL);
	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, expected);

	KUNIT_EXPECT_PTR_EQ(test, expected, of_clk_get_hw(np, 0, NULL));

We're also leaking the of_node if an assert triggers so we need to use a
kunit wrapper version of of_find_node_by_name() or do a hand code
version of putting the node when kunit asserts.

^ permalink raw reply

* Re: [PATCH 07/16] clk: tests: Add Kunit testing for of_clk_get_parent_name()
From: Stephen Boyd @ 2026-04-12  1:29 UTC (permalink / raw)
  To: Miquel Raynal (Schneider Electric), Antoine Tenart,
	Christian Marangi, Conor Dooley, David S. Miller,
	Geert Uytterhoeven, Herbert Xu, Jayesh Choudhary,
	Krzysztof Kozlowski, Magnus Damm, Michael Turquette,
	Olivia Mackall, Rob Herring, Thomas Gleixner
  Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
	devicetree, linux-kernel, linux-crypto, linux-renesas-soc,
	Miquel Raynal (Schneider Electric)
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-7-5e6ff7853994@bootlin.com>

Quoting Miquel Raynal (Schneider Electric) (2026-03-27 13:09:29)
> diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c
> index b814b45f1f7e..8a17ad0d185f 100644
> --- a/drivers/clk/clk_test.c
> +++ b/drivers/clk/clk_test.c
> @@ -3651,9 +3651,19 @@ static void clk_parse_clkspec_with_incorrect_index_and_name(struct kunit *test)
>         KUNIT_EXPECT_TRUE(test, IS_ERR(hw));
>  }
>  

Add a comment here to tell us what the test is expecting.

> +static void clk_parse_and_get_parent_name(struct kunit *test)
> +{
> +       struct clk_parse_clkspec_ctx *ctx = test->priv;
> +
> +       KUNIT_EXPECT_STREQ(test,
> +                          of_clk_get_parent_name(ctx->cons_np, 0),
> +                          clk_parse_clkspec_1_init_data.name);
> +}

Reading this test is pretty hard because all the context is in the
common setup. Maybe the common setup is too broad in this case and
should be simplified so that tests can show more setup and assert code
for the things it wants to do. For example, if the name can be passed
from this test directly it would clarify by moving context into test
function scope.

	const char *pname = "expected-name";

	KUNIT_ASSERT_EQ(test, 0, setup_parent(pname));

	KUNIT_EXPECT_STREQ(test, pname,
			   of_clk_get_parent_name(ctx->cons_np, 0));

> +
>  static struct kunit_case clk_parse_clkspec_test_cases[] = {
>         KUNIT_CASE(clk_parse_clkspec_with_correct_index_and_name),
>         KUNIT_CASE(clk_parse_clkspec_with_incorrect_index_and_name),
> +       KUNIT_CASE(clk_parse_and_get_parent_name),

Better to call the test something like
of_clk_get_parent_name_gets_parent_name to indicate what we're testing.

^ permalink raw reply

* Re: [PATCH 01/16] dt-bindings: clock: Introduce nexus nodes
From: Stephen Boyd @ 2026-04-12  1:16 UTC (permalink / raw)
  To: Miquel Raynal (Schneider Electric), Antoine Tenart,
	Christian Marangi, Conor Dooley, David S. Miller,
	Geert Uytterhoeven, Herbert Xu, Jayesh Choudhary,
	Krzysztof Kozlowski, Magnus Damm, Michael Turquette,
	Olivia Mackall, Rob Herring, Thomas Gleixner
  Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
	devicetree, linux-kernel, linux-crypto, linux-renesas-soc,
	Miquel Raynal (Schneider Electric)
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-1-5e6ff7853994@bootlin.com>

Quoting Miquel Raynal (Schneider Electric) (2026-03-27 13:09:23)
> diff --git a/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
> new file mode 100644
> index 000000000000..f07e2972e8aa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/clock-nexus-node.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Clock Nexus
> +
> +description: >
> +  A nexus node allows to remap a phandle list in a consumer node through a

Should this say "remap a clock specifier list" instead of "remap a
phandle list"? A phandle list sounds like there are zero cells.

> +  container or a connector node in a generic way. With this remapping,
> +  the consumer node needs to know only about the nexus node. Resources
> +  behind the nexus node are decoupled by the nexus node itself.

^ permalink raw reply

* Re: [PATCH 10/16] clk: Add support for clock nexus dt bindings
From: Stephen Boyd @ 2026-04-12  1:12 UTC (permalink / raw)
  To: Brian Masney, Miquel Raynal
  Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Thomas Gleixner, Olivia Mackall, Herbert Xu, Jayesh Choudhary,
	David S. Miller, Christian Marangi, Antoine Tenart,
	Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
	Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
	linux-kernel, linux-crypto, linux-renesas-soc, Herve Codina
In-Reply-To: <87y0j76p8o.fsf@bootlin.com>

Quoting Miquel Raynal (2026-04-01 01:47:51)
> Hello Brian,
> 
> First, thanks for the whole review.
> 
> On 30/03/2026 at 11:16:44 -04, Brian Masney <bmasney@redhat.com> wrote:
> >> -            ret = of_parse_phandle_with_args(np, "clocks", "#clock-cells",
> >> -                                             index, out_args);
> >> +            ret = of_parse_phandle_with_args_map(np, "clocks", "clock",
> >> +                                                 index, out_args);
> >
> > Before I left my Reviewed-by, I should have double checked Sashiko. It
> > has several questions about this patch. The first is:
> >
> >     Are there other places in the clock framework that need to transition to the
> >     new map API to ensure assigned clocks work?
> >     
> >     For instance, assigned-clocks and assigned-clock-parents are parsed in
> >     drivers/clk/clk-conf.c using of_parse_phandle_with_args(). If a device
> >     specifies an assigned clock that routes through a nexus node, will it fail
> >     to configure because the map is not traversed?
> 
> The goal of the nexus node is to isolate what is behind. Are
> assigned-clocks et al. supposed to traverse a nexus node? I am tempted
> to say "no", but I'm open to discussing this ofc.

Why would assigned-clocks not traverse the nexus node? If I'm a DT
author I would think any clock specifier should be routed properly
through the nexus node.

^ permalink raw reply

* Re: [PATCH v2 19/21] drm/panel: add driver for Waveshare 8.8" DSI TOUCH-A panel
From: Jie Gan @ 2026-04-12  1:09 UTC (permalink / raw)
  To: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
	Simona Vetter, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
	Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski
  Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260411-waveshare-dsi-touch-v2-19-75cdbeac5156@oss.qualcomm.com>



On 4/11/2026 8:10 PM, Dmitry Baryshkov wrote:
> Add driver for the panel found on Waveshare 8.8" DSI TOUCH-A kit. It
> uses ota7290b IC as a controller.
> 
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>   drivers/gpu/drm/panel/Kconfig                    |  12 ++
>   drivers/gpu/drm/panel/Makefile                   |   1 +
>   drivers/gpu/drm/panel/panel-focaltech-ota7290b.c | 208 +++++++++++++++++++++++
>   3 files changed, 221 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index ba527b4d7737..979109c27b9b 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -144,6 +144,18 @@ config DRM_PANEL_FEIYANG_FY07024DI26A30D
>   	  Say Y if you want to enable support for panels based on the
>   	  Feiyang FY07024DI26A30-D MIPI-DSI interface.
>   
> +config DRM_PANEL_FOCALTECH_OTA7290B
> +	tristate "Focaltech OTA7290B"
> +	depends on DRM_MIPI_DSI
> +	depends on I2C
> +	depends on BACKLIGHT_CLASS_DEVICE
> +	select DRM_KMS_HELPER
> +	help
> +	  Enable support for panels using OTA7290B as a controller (for
> +	  example, Waveshare 12.3" DSI TOUCH-A panel). Say Y here if you want
> +	  to enable support for this panel. To compile this driver as a module,
> +	  choose M here.
> +
>   config DRM_PANEL_DSI_CM
>   	tristate "Generic DSI command mode panels"
>   	depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index a4291dc3905b..0d694acbfbb6 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
>   obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
>   obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
>   obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += panel-feiyang-fy07024di26a30d.o
> +obj-$(CONFIG_DRM_PANEL_FOCALTECH_OTA7290B) += panel-focaltech-ota7290b.o
>   obj-$(CONFIG_DRM_PANEL_HIMAX_HX8279) += panel-himax-hx8279.o
>   obj-$(CONFIG_DRM_PANEL_HIMAX_HX83102) += panel-himax-hx83102.o
>   obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
> diff --git a/drivers/gpu/drm/panel/panel-focaltech-ota7290b.c b/drivers/gpu/drm/panel/panel-focaltech-ota7290b.c
> new file mode 100644
> index 000000000000..991d6a4caf17
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-focaltech-ota7290b.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2024 Waveshare International Limited
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +
> +#include <linux/gpio/consumer.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_probe_helper.h>
> +
> +struct ota7290b {
> +	struct drm_panel panel;
> +	struct mipi_dsi_device *dsi;
> +
> +	struct regulator *power;
> +	struct gpio_desc *reset;
> +	struct regulator *avdd;
> +	struct regulator *iovcc;
> +
> +	enum drm_panel_orientation orientation;
> +};
> +
> +static inline struct ota7290b *panel_to_ota(struct drm_panel *panel)
> +{
> +	return container_of(panel, struct ota7290b, panel);
> +}
> +
> +static int ota7290b_prepare(struct drm_panel *panel)
> +{
> +	struct ota7290b *ctx = panel_to_ota(panel);
> +	struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +	int ret;
> +
> +	if (ctx->iovcc) {
> +		ret = regulator_enable(ctx->iovcc);
> +		if (ret)
> +			dev_err(panel->dev, "failed to enable IO regulator: %d\n", ret);
> +	}
> +
> +	if (ctx->avdd) {
> +		ret = regulator_enable(ctx->avdd);
> +		if (ret)
> +			dev_err(panel->dev, "failed to enable AVDD regulator: %d\n", ret);
> +	}
> +
> +	if (ctx->reset) {
> +		gpiod_set_value_cansleep(ctx->reset, 0);
> +		msleep(60);
> +		gpiod_set_value_cansleep(ctx->reset, 1);
> +		msleep(60);
> +		gpiod_set_value_cansleep(ctx->reset, 0);
> +		msleep(60);
> +	}
> +
> +	mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
> +	mipi_dsi_msleep(&dsi_ctx, 120);
> +	mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
> +	mipi_dsi_msleep(&dsi_ctx, 50);
> +
> +	if (dsi_ctx.accum_err < 0)
> +		dev_err(panel->dev, "failed to init panel: %d\n", ret);

better to check dsi_ctx.accum_err instead ret here?

dev_err(panel->dev, "failed to init panel: %d\n", dsi_ctx.accum_err);

Thanks,
Jie

> +
> +	return dsi_ctx.accum_err;
> +}
> +
> +static int ota7290b_unprepare(struct drm_panel *panel)
> +{
> +	struct ota7290b *ctx = panel_to_ota(panel);
> +	struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +
> +	mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
> +	mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
> +
> +	if (ctx->reset) {
> +		gpiod_set_value_cansleep(ctx->reset, 1);
> +		msleep(5);
> +	}
> +
> +	if (ctx->avdd)
> +		regulator_disable(ctx->avdd);
> +
> +	if (ctx->iovcc)
> +		regulator_disable(ctx->iovcc);
> +
> +	return 0;
> +}
> +
> +static const struct drm_display_mode waveshare_dsi_touch_8_8_a_mode = {
> +	.clock = 75000,
> +
> +	.hdisplay = 480,
> +	.hsync_start = 480 + 50,
> +	.hsync_end = 480 + 50 + 50,
> +	.htotal = 480 + 50 + 50 + 50,
> +
> +	.vdisplay = 1920,
> +	.vsync_start = 1920 + 20,
> +	.vsync_end = 1920 + 20 + 20,
> +	.vtotal = 1920 + 20 + 20 + 20,
> +
> +	.width_mm = 68,
> +	.height_mm = 219,
> +	.type = DRM_MODE_TYPE_DRIVER,
> +};
> +
> +static int ota7290b_get_modes(struct drm_panel *panel,
> +			      struct drm_connector *connector)
> +{
> +	return drm_connector_helper_get_modes_fixed(connector, &waveshare_dsi_touch_8_8_a_mode);
> +}
> +
> +static enum drm_panel_orientation ota7290b_get_orientation(struct drm_panel *panel)
> +{
> +	struct ota7290b *ctx = panel_to_ota(panel);
> +
> +	return ctx->orientation;
> +}
> +
> +static const struct drm_panel_funcs ota7290b_funcs = {
> +	.prepare = ota7290b_prepare,
> +	.unprepare = ota7290b_unprepare,
> +	.get_modes = ota7290b_get_modes,
> +	.get_orientation = ota7290b_get_orientation,
> +};
> +
> +static int ota7290b_probe(struct mipi_dsi_device *dsi)
> +{
> +	struct ota7290b *ctx;
> +	int ret;
> +
> +	ctx = devm_drm_panel_alloc(&dsi->dev, struct ota7290b, panel,
> +				   &ota7290b_funcs,
> +				   DRM_MODE_CONNECTOR_DSI);
> +	if (!ctx)
> +		return -ENOMEM;
> +	mipi_dsi_set_drvdata(dsi, ctx);
> +	ctx->dsi = dsi;
> +
> +	ctx->reset = devm_gpiod_get_optional(&dsi->dev, "reset", GPIOD_OUT_HIGH);
> +	if (IS_ERR(ctx->reset))
> +		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
> +				     "Couldn't get our reset GPIO\n");
> +
> +	ctx->iovcc = devm_regulator_get_optional(&dsi->dev, "iovcc");
> +	if (IS_ERR(ctx->iovcc))
> +		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->iovcc),
> +					"Couldn't get our iovcc supply\n");
> +
> +	ctx->avdd = devm_regulator_get_optional(&dsi->dev, "avdd");
> +	if (IS_ERR(ctx->avdd))
> +		return dev_err_probe(&dsi->dev, PTR_ERR(ctx->avdd),
> +					"Couldn't get our avdd supply\n");
> +
> +	ret = of_drm_get_panel_orientation(
> +			dsi->dev.of_node, &ctx->orientation);
> +	if (ret) {
> +		dev_err(&dsi->dev, "%pOF: failed to get orientation: %d\n",
> +			dsi->dev.of_node, ret);
> +		return ret;
> +	}
> +
> +	ret = drm_panel_of_backlight(&ctx->panel);
> +	if (ret)
> +		return ret;
> +
> +	ctx->panel.prepare_prev_first = true;
> +
> +	ret = devm_drm_panel_add(&dsi->dev, &ctx->panel);
> +	if (ret)
> +		return ret;
> +
> +	dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_HSE |
> +		MIPI_DSI_MODE_LPM | MIPI_DSI_CLOCK_NON_CONTINUOUS,
> +	dsi->format = MIPI_DSI_FMT_RGB888,
> +	dsi->lanes = 2;
> +
> +	return devm_mipi_dsi_attach(&dsi->dev, dsi);
> +}
> +
> +static const struct of_device_id ota7290b_of_match[] = {
> +	{ .compatible = "waveshare,8.8-dsi-touch-a", },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, ota7290b_of_match);
> +
> +static struct mipi_dsi_driver ota7290b_driver = {
> +	.probe		= ota7290b_probe,
> +	.driver = {
> +		.name		= "focaltech-ota7290b",
> +		.of_match_table	= ota7290b_of_match,
> +	},
> +};
> +module_mipi_dsi_driver(ota7290b_driver);
> +
> +MODULE_DESCRIPTION("Panel driver for Focaltech OTA7290B panels");
> +MODULE_LICENSE("GPL");
> 


^ permalink raw reply

* Re: [PATCH v2 21/21] gpio: add GPIO controller found on Waveshare DSI TOUCH panels
From: Jie Gan @ 2026-04-12  1:06 UTC (permalink / raw)
  To: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
	Simona Vetter, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
	Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski
  Cc: dri-devel, devicetree, linux-kernel, linux-gpio, Riccardo Mereu
In-Reply-To: <20260411-waveshare-dsi-touch-v2-21-75cdbeac5156@oss.qualcomm.com>



On 4/11/2026 8:10 PM, Dmitry Baryshkov wrote:
> The Waveshare DSI TOUCH family of panels has separate on-board GPIO
> controller, which controls power supplies to the panel and the touch
> screen and provides reset pins for both the panel and the touchscreen.
> Also it provides a simple PWM controller for panel backlight. Add
> support for this GPIO controller.
> 
> Tested-by: Riccardo Mereu <r.mereu@arduino.cc>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
>   drivers/gpio/Kconfig              |  10 ++
>   drivers/gpio/Makefile             |   1 +
>   drivers/gpio/gpio-waveshare-dsi.c | 208 ++++++++++++++++++++++++++++++++++++++
>   3 files changed, 219 insertions(+)
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index dbe7c6e63eab..1b210c451151 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -805,6 +805,16 @@ config GPIO_VISCONTI
>   	help
>   	  Say yes here to support GPIO on Tohisba Visconti.
>   
> +config GPIO_WAVESHARE_DSI_TOUCH
> +	tristate "Waveshare GPIO controller for DSI panels"
> +	depends on BACKLIGHT_CLASS_DEVICE
> +	depends on I2C
> +	select REGMAP_I2C
> +	help
> +	  Enable support for the GPIO and PWM controller found on Waveshare DSI
> +	  TOUCH panel kits. It provides GPIOs (used for regulator control and
> +          resets) and backlight support.
> +
>   config GPIO_WCD934X
>   	tristate "Qualcomm Technologies Inc WCD9340/WCD9341 GPIO controller driver"
>   	depends on MFD_WCD934X
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 20d4a57afdaa..75ce89fc3b93 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -207,6 +207,7 @@ obj-$(CONFIG_GPIO_VIRTUSER)		+= gpio-virtuser.o
>   obj-$(CONFIG_GPIO_VIRTIO)		+= gpio-virtio.o
>   obj-$(CONFIG_GPIO_VISCONTI)		+= gpio-visconti.o
>   obj-$(CONFIG_GPIO_VX855)		+= gpio-vx855.o
> +obj-$(CONFIG_GPIO_WAVESHARE_DSI_TOUCH)	+= gpio-waveshare-dsi.o
>   obj-$(CONFIG_GPIO_WCD934X)		+= gpio-wcd934x.o
>   obj-$(CONFIG_GPIO_WHISKEY_COVE)		+= gpio-wcove.o
>   obj-$(CONFIG_GPIO_WINBOND)		+= gpio-winbond.o
> diff --git a/drivers/gpio/gpio-waveshare-dsi.c b/drivers/gpio/gpio-waveshare-dsi.c
> new file mode 100644
> index 000000000000..f4a1d4d3b872
> --- /dev/null
> +++ b/drivers/gpio/gpio-waveshare-dsi.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2024 Waveshare International Limited
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/err.h>
> +#include <linux/fb.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regmap.h>
> +
> +/* I2C registers of the microcontroller. */
> +#define REG_TP		0x94
> +#define REG_LCD		0x95
> +#define REG_PWM		0x96
> +#define REG_SIZE	0x97
> +#define REG_ID		0x98
> +#define REG_VERSION	0x99
> +
> +enum {
> +	GPIO_AVDD = 0,
> +	GPIO_PANEL_RESET = 1,
> +	GPIO_BL_ENABLE = 2,
> +	GPIO_IOVCC = 4,
> +	GPIO_VCC = 8,
> +	GPIO_TS_RESET = 9,
> +};
> +
> +#define NUM_GPIO 16
> +
> +struct waveshare_gpio {
> +	struct mutex dir_lock;
> +	struct mutex pwr_lock;
> +	struct regmap *regmap;
> +	u16 poweron_state;
> +
> +	struct gpio_chip gc;
> +};
> +
> +static const struct regmap_config waveshare_gpio_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.max_register = REG_PWM,

.max_register = REG_VERSION,

check comments in probe

> +};
> +
> +static int waveshare_gpio_get(struct waveshare_gpio *state, unsigned int offset)
> +{
> +	u16 pwr_state;
> +
> +	guard(mutex)(&state->pwr_lock);
> +	pwr_state = state->poweron_state & BIT(offset);
> +
> +	return !!pwr_state;
> +}
> +
> +static int waveshare_gpio_set(struct waveshare_gpio *state, unsigned int offset, int value)
> +{
> +	u16 last_val;
> +	int err;
> +
> +	guard(mutex)(&state->pwr_lock);
> +
> +	last_val = state->poweron_state;
> +	if (value)
> +		last_val |= BIT(offset);
> +	else
> +		last_val &= ~BIT(offset);
> +
> +	state->poweron_state = last_val;
> +
> +	err = regmap_write(state->regmap, REG_TP, last_val >> 8);
> +	if (!err)
> +		err = regmap_write(state->regmap, REG_LCD, last_val & 0xff);
> +
> +	return err;
> +}
> +
> +static int waveshare_gpio_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
> +{
> +	return GPIO_LINE_DIRECTION_OUT;
> +}
> +
> +static int waveshare_gpio_gpio_get(struct gpio_chip *gc, unsigned int offset)
> +{
> +	struct waveshare_gpio *state = gpiochip_get_data(gc);
> +
> +	return waveshare_gpio_get(state, offset);
> +}
> +
> +static int waveshare_gpio_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
> +{
> +	struct waveshare_gpio *state = gpiochip_get_data(gc);
> +
> +	return waveshare_gpio_set(state, offset, value);
> +}
> +
> +static int waveshare_gpio_update_status(struct backlight_device *bl)
> +{
> +	struct waveshare_gpio *state = bl_get_data(bl);
> +	int brightness = backlight_get_brightness(bl);
> +
> +	waveshare_gpio_set(state, GPIO_BL_ENABLE, brightness);
> +
> +	return regmap_write(state->regmap, REG_PWM, brightness);
> +}
> +
> +static const struct backlight_ops waveshare_gpio_bl = {
> +	.update_status = waveshare_gpio_update_status,
> +};
> +
> +static int waveshare_gpio_probe(struct i2c_client *i2c)
> +{
> +	struct backlight_properties props = {};
> +	struct waveshare_gpio *state;
> +	struct device *dev = &i2c->dev;
> +	struct backlight_device *bl;
> +	struct regmap *regmap;
> +	unsigned int data;
> +	int ret;
> +
> +	state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
> +	if (!state)
> +		return -ENOMEM;
> +
> +	ret = devm_mutex_init(dev, &state->dir_lock);
> +	if (ret)
> +		return ret;
> +
> +	ret = devm_mutex_init(dev, &state->pwr_lock);
> +	if (ret)
> +		return ret;
> +
> +	regmap = devm_regmap_init_i2c(i2c, &waveshare_gpio_regmap_config);

for waveshare_gpio_regmap_config: .max_register = REG_PWM,

> +	if (IS_ERR(regmap))
> +		return dev_err_probe(dev, PTR_ERR(regmap), "Failed to allocate register map\n");
> +
> +	state->regmap = regmap;
> +	i2c_set_clientdata(i2c, state);
> +
> +	ret = regmap_read(regmap, REG_ID, &data);

REG_ID here is 0x98,

in _regmap_read -> regmap_readable will check the max_register, then 
return -EIO.

> +	if (ret < 0)
> +		return dev_err_probe(dev, ret, "Failed to read register\n");
> +
> +	dev_dbg(dev, "waveshare panel hw id = 0x%x\n", data);
> +
> +	ret = regmap_read(regmap, REG_SIZE, &data);

ditto.

Thanks,
Jie

> +	if (ret < 0)
> +		return dev_err_probe(dev, ret, "Failed to read register\n");
> +
> +	dev_dbg(dev, "waveshare panel size = %d\n", data);
> +
> +	ret = regmap_read(regmap, REG_VERSION, &data);
> +	if (ret < 0)
> +		return dev_err_probe(dev, ret, "Failed to read register\n");
> +
> +	dev_dbg(dev, "waveshare panel mcu version = 0x%x\n", data);
> +
> +	ret = waveshare_gpio_set(state, GPIO_TS_RESET, 1);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to program GPIOs\n");
> +
> +	msleep(20);
> +
> +	state->gc.parent = dev;
> +	state->gc.label = i2c->name;
> +	state->gc.owner = THIS_MODULE;
> +	state->gc.base = -1;
> +	state->gc.ngpio = NUM_GPIO;
> +
> +	/* it is output only */
> +	state->gc.get = waveshare_gpio_gpio_get;
> +	state->gc.set = waveshare_gpio_gpio_set;
> +	state->gc.get_direction = waveshare_gpio_gpio_get_direction;
> +	state->gc.can_sleep = true;
> +
> +	ret = devm_gpiochip_add_data(dev, &state->gc, state);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to create gpiochip\n");
> +
> +	props.type = BACKLIGHT_RAW;
> +	props.max_brightness = 255;
> +	props.brightness = 255;
> +	bl = devm_backlight_device_register(dev, dev_name(dev), dev, state,
> +					    &waveshare_gpio_bl, &props);
> +	return PTR_ERR_OR_ZERO(bl);
> +}
> +
> +static const struct of_device_id waveshare_gpio_dt_ids[] = {
> +	{ .compatible = "waveshare,dsi-touch-gpio" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, waveshare_gpio_dt_ids);
> +
> +static struct i2c_driver waveshare_gpio_regulator_driver = {
> +	.driver = {
> +		.name = "waveshare-regulator",
> +		.of_match_table = of_match_ptr(waveshare_gpio_dt_ids),
> +	},
> +	.probe = waveshare_gpio_probe,
> +};
> +
> +module_i2c_driver(waveshare_gpio_regulator_driver);
> +
> +MODULE_DESCRIPTION("GPIO controller driver for Waveshare DSI touch panels");
> +MODULE_LICENSE("GPL");
> 


^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox