* Re: [PATCH 04/35] irqchip/qcom-pdc: Replace pdc_version global with a function pointer
From: Dmitry Baryshkov @ 2026-04-14 18:05 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-5-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:41AM +0530, Mukesh Ojha wrote:
> Now that the two enable paths are separate functions, replace the
> pdc_version global with a __pdc_enable_intr function pointer. The
> pointer is assigned once at probe time based on the version register,
> moving the version comparison out of the interrupt enable/disable hot
> path entirely.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 21e2b4b884ee..734576cdce0c 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -51,7 +51,7 @@ static void __iomem *pdc_base;
> static void __iomem *pdc_prev_base;
> static struct pdc_pin_region *pdc_region;
> static int pdc_region_cnt;
> -static unsigned int pdc_version;
> +static void (*__pdc_enable_intr)(int pin_out, bool on);
I'd say, it's more awkward than the current implementation.
> static bool pdc_x1e_quirk;
>
> static void pdc_base_reg_write(void __iomem *base, int reg, u32 i, u32 val)
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 05/35] irqchip/qcom-pdc: Add PDC_VERSION() macro to describe version register fields
From: Dmitry Baryshkov @ 2026-04-14 18:05 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-6-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:42AM +0530, Mukesh Ojha wrote:
> The PDC hardware version register encodes major, minor and step fields
> in byte-sized fields at bits [23:16], [15:8] and [7:0] respectively.
> The existing PDC_VERSION_3_2 constant was a bare magic number (0x30200)
> with no indication of this encoding.
>
> Add GENMASK-based field definitions for each sub-field and a
> PDC_VERSION(maj, min, step) constructor macro using FIELD_PREP, making
> the encoding self-documenting. Replace the magic constant with
> PDC_VERSION(3, 2, 0).
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 06/35] irqchip/qcom-pdc: Use FIELD_GET() to extract bank index and bit position
From: Dmitry Baryshkov @ 2026-04-14 18:06 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-7-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:43AM +0530, Mukesh Ojha wrote:
> The IRQ_ENABLE_BANK register is a bank of 32-bit words where each bit
> represents one PDC pin. The bank index and bit position within the bank
> are encoded in the flat pin number as bits [31:5] and [4:0] respectively.
>
> Replace the open-coded division and modulo with FIELD_GET() and GENMASK()
> to make the bit extraction self-documenting and consistent with the
> FIELD_PREP() style already used in the PDC_VERSION() macro.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 5e1553334103..638b5d89a141 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -110,8 +110,8 @@ static void pdc_enable_intr_bank(int pin_out, bool on)
> unsigned long enable;
> u32 index, mask;
>
> - index = pin_out / 32;
> - mask = pin_out % 32;
> + index = FIELD_GET(GENMASK(31, 5), pin_out);
#define masks
> + mask = FIELD_GET(GENMASK(4, 0), pin_out);
>
> enable = pdc_reg_read(IRQ_ENABLE_BANK, index);
> __assign_bit(mask, &enable, on);
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 2/4] ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver
From: Mark Brown @ 2026-04-14 18:08 UTC (permalink / raw)
To: Sen Wang
Cc: linux-sound, lgirdwood, robh, krzk+dt, conor+dt, devicetree,
perex, tiwai, shenghao-ding, kevin-lu, baojun.xu, niranjan.hy,
l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <a0f50798-3293-4b2b-8d9c-7a85fce9e8e7@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
On Fri, Apr 10, 2026 at 12:56:47PM -0500, Sen Wang wrote:
> On 4/10/26 09:02, Mark Brown wrote:
> > This looks mostly good, but one issue I see is that AFAICT we only stop
> > fault_check_work during runtime suspsend - if runtime PM is disabled, or
> > if the driver is removed, the work will be left running.
> Regarding fault_check_work w/o runtime PM: the device has fault
> conditions that fire regardless of stream state, so the work runs for the
> duration of the active power state (runtime PM) rather than stream state.
> I could add a DAPM event fallback to gate the work when runtime PM is not
> defined, but that's more restrictive; it could miss faults outside of active
> playback, and adds complexity for what is a fairly niche configuration
> (optional check_work with runtime PM disabled).
> Do you think the DAPM fallback would suffice, or is the current approach
> (poll until removal) acceptable given the hardware behavior? Any other
> suggestions would be greatly appreciated!
It's fine to keep on checking for faults if there's faults that can be
generated, the only reason I mentioned runtime PM there was that it's
the only thing that stops the polling in the current version. So long
as everything is stopped when the device is removed it's fine. No need
for a DAPM fallback.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: Enable CAN RX via GPIO expander
From: Dmitry Baryshkov @ 2026-04-14 18:09 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Anup Kulkarni, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-arm-msm, devicetree, linux-kernel, mukesh.savaliya,
viken.dadhaniya
In-Reply-To: <9cf3b035-79c0-4e9b-8ab6-a81f8d27728f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 06:20:14PM +0200, Konrad Dybcio wrote:
> On 4/14/26 6:08 PM, Dmitry Baryshkov wrote:
> > On Thu, Apr 02, 2026 at 04:22:53PM +0530, Anup Kulkarni wrote:
> >> Few CAN controllers, part of RTSS sub-system on LeMans, route
> >> their RX signal through a I2C GPIO expander at address 0x3b.
> >> RTSS subsystem is an MCU like sub-system on LeMans with independent
> >> booting capability through OSPI interface and supports peripherals like
> >> RGMII, CAN-FD, UART, I2C, SPI etc.
> >>
> >> Describe this hardware wiring by configuring the expander GPIO 4 pin as
> >> hog with output-high, asserting the selected line during boot.
> >
> > Missing platform name in the subject.
> >
> >>
> >> Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>
> >> ---
> >> arch/arm64/boot/dts/qcom/lemans-evk.dts | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
> >> index a1ef4eba2a20..b8371bdf9933 100644
> >> --- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
> >> +++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
> >> @@ -615,6 +615,13 @@ expander3: gpio@3b {
> >> interrupts-extended = <&tlmm 39 IRQ_TYPE_LEVEL_LOW>;
> >> pinctrl-0 = <&expander3_int>;
> >> pinctrl-names = "default";
> >> +
> >> + rtss-can-sel-hog {
> >
> > Why is it being described as a hog rather than a pinctrl used by the
> > CAN device?
>
> My understanding is that the CAN bus is managed by SAIL ("RTSS")
So, Linux can affect what is being required for the safety island?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 04/35] irqchip/qcom-pdc: Replace pdc_version global with a function pointer
From: Bjorn Andersson @ 2026-04-14 18:11 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, cros-qcom-dts-watchers, linux-arm-msm,
linux-kernel, devicetree
In-Reply-To: <20260411062343.moksimqxjomts44a@hu-mojha-hyd.qualcomm.com>
On Sat, Apr 11, 2026 at 11:53:43AM +0530, Mukesh Ojha wrote:
> On Fri, Apr 10, 2026 at 09:43:10PM -0500, Bjorn Andersson wrote:
> > On Sat, Apr 11, 2026 at 12:10:41AM +0530, Mukesh Ojha wrote:
> > > Now that the two enable paths are separate functions, replace the
> > > pdc_version global with a __pdc_enable_intr function pointer. The
> > > pointer is assigned once at probe time based on the version register,
> > > moving the version comparison out of the interrupt enable/disable hot
> > > path entirely.
> >
> > That's what the patch does, but why?
>
> I thought, it was odd to compare against the version every time during
> enable/disable instead of clearing the path to take at probe time itself.
> however, I don't have data to prove how hot this path is ?
>
No immediate concerns about this hypothesis, but please start the commit
message with this problem description. Then if someone measures and find
that your assumption wasn't correct, they don't need to guess what you
where thinking when you wrote this.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH V3 2/9] iio: imu: inv_icm42607: Add Core for inv_icm42607 Driver
From: Jonathan Cameron @ 2026-04-14 18:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, Chris Morgan
In-Reply-To: <ad3paMbRXtq6BrCu@ashevche-desk.local>
On Tue, 14 Apr 2026 10:14:48 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Mon, Apr 13, 2026 at 08:06:54PM +0100, Jonathan Cameron wrote:
> > On Mon, 30 Mar 2026 14:58:46 -0500
> > Chris Morgan <macroalpha82@gmail.com> wrote:
>
> ...
>
> > > + if (!conf->temp_en)
> > > + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
> >
> > Could make this
> > val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL,
> > !conf->temp_en);
> > Not particularly important though if you prefer the if.
>
> Isn't this becomes FIELD_MODIFY()?
>
Yes, in this particular case as the bit has never been set before
this line, they end up the same. If the compiler fails to notice it
doesn't need to zero the bit if conf->temp_en is true might make it more
efficient to do it the way I had it but given this isn't a fast
path, FIELD_MODIFY() is fine.
Jonathan
^ permalink raw reply
* [PATCH 0/2] arm64: dts: qcom: msm8916-panasonic-eluga-u2: add initial device tree
From: Lin, Meng-Bo @ 2026-04-14 18:44 UTC (permalink / raw)
To: linux-kernel
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, phone-devel,
~postmarketos/upstreaming, Lin, Meng-Bo
Panasonic ELUGA U2 is a phone using the MSM8916 SoC released in 2015.
Add a device tree for with initial support for:
- GPIO keys
- GPIO LEDs
- pm8916-vibrator
- SDHCI (internal and external storage)
- USB Device Mode
- UART
- Regulators
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: msm8916-panasonic-eluga-u2: add initial device tree
From: Lin, Meng-Bo @ 2026-04-14 18:44 UTC (permalink / raw)
To: linux-kernel
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, phone-devel,
~postmarketos/upstreaming, Lin, Meng-Bo
In-Reply-To: <20260414184429.168612-1-linmengbo06890@proton.me>
Panasonic ELUGA U2 is a phone using the MSM8916 SoC released in 2015.
Add a device tree for with initial support for:
- GPIO keys
- GPIO LEDs
- pm8916-vibrator
- SDHCI (internal and external storage)
- USB Device Mode
- UART
- Regulators
Signed-off-by: "Lin, Meng-Bo" <linmengbo06890@proton.me>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../dts/qcom/msm8916-panasonic-eluga-u2.dts | 149 ++++++++++++++++++
2 files changed, 150 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/msm8916-panasonic-eluga-u2.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4ba8e7306419..4cbb4a079420 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -81,6 +81,7 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-motorola-harpia.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-motorola-osprey.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-motorola-surnia.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM) += msm8916-panasonic-eluga-u2.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-samsung-a3u-eur.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-samsung-a5u-eur.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-samsung-coreprimeltevzw.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8916-panasonic-eluga-u2.dts b/arch/arm64/boot/dts/qcom/msm8916-panasonic-eluga-u2.dts
new file mode 100644
index 000000000000..8eff59119760
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916-panasonic-eluga-u2.dts
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/dts-v1/;
+
+#include "msm8916-pm8916.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "Panasonic ELUGA U2";
+ compatible = "panasonic,eluga-u2", "qcom,msm8916";
+ chassis-type = "handset";
+
+ aliases {
+ mmc0 = &sdhc_1; /* eMMC */
+ mmc1 = &sdhc_2; /* SD card */
+ serial0 = &blsp_uart2;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&gpio_keys_default>;
+ pinctrl-names = "default";
+
+ label = "GPIO Buttons";
+
+ button-volume-up {
+ label = "Volume Up";
+ gpios = <&tlmm 107 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pm8916_mpps_leds_default>;
+ pinctrl-names = "default";
+
+ led-green {
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&pm8916_mpps 2 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-blue {
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_BLUE>;
+ gpios = <&pm8916_mpps 4 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+
+ usb_id: usb-id {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&usb_id_default>;
+ pinctrl-names = "default";
+ };
+};
+
+&blsp_uart2 {
+ status = "okay";
+};
+
+&pm8916_mpps {
+ pm8916_mpps_leds_default: pm8916-mpps-state {
+ pins = "mpp2", "mpp4";
+ function = "digital";
+ output-low;
+ };
+};
+
+&pm8916_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+ status = "okay";
+};
+
+&pm8916_rpm_regulators {
+ pm8916_l17: l17 {
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ };
+};
+
+&pm8916_vib {
+ status = "okay";
+};
+
+&sdhc_1 {
+ status = "okay";
+};
+
+&sdhc_2 {
+ pinctrl-0 = <&sdc2_default &sdc2_cd_default>;
+ pinctrl-1 = <&sdc2_sleep &sdc2_cd_default>;
+ pinctrl-names = "default", "sleep";
+
+ cd-gpios = <&tlmm 38 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+};
+
+&usb {
+ extcon = <&usb_id>, <&usb_id>;
+ status = "okay";
+};
+
+&usb_hs_phy {
+ extcon = <&usb_id>;
+};
+
+&tlmm {
+ gpio_keys_default: gpio-keys-default-state {
+ pins = "gpio107";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sdc2_cd_default: sdc2-cd-default-state {
+ pins = "gpio38";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ usb_id_default: usb-id-default-state {
+ pins = "gpio110";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+};
+
+&venus {
+ status = "okay";
+};
+
+&venus_mem {
+ status = "okay";
+};
--
2.47.3
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: qcom: Document panasonic,eluga-u2
From: Lin, Meng-Bo @ 2026-04-14 18:44 UTC (permalink / raw)
To: linux-kernel
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, phone-devel,
~postmarketos/upstreaming, Lin, Meng-Bo
In-Reply-To: <20260414184429.168612-1-linmengbo06890@proton.me>
Document the new panasonic,eluga-u2 device tree bindings used in
msm8916-panasonic-eluga-u2.
Signed-off-by: "Lin, Meng-Bo" <linmengbo06890@proton.me>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 1335a7bee397..5b60145c80e7 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -183,6 +183,7 @@ properties:
- motorola,harpia
- motorola,osprey
- motorola,surnia
+ - panasonic,eluga-u2
- qcom,msm8916-mtp
- samsung,a3u-eur
- samsung,a5u-eur
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v7 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Jonathan Cameron @ 2026-04-14 18:54 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-iio, devicetree, linux-kernel,
Andy Shevchenko
In-Reply-To: <20260410-dev_ad5706r-v7-2-af93a4caa186@analog.com>
On Fri, 10 Apr 2026 14:48:17 +0800
Alexis Czezar Torreno <alexisczezar.torreno@analog.com> wrote:
> Add support for the Analog Devices AD5706R, a 4-channel 16-bit
> current output digital-to-analog converter with SPI interface.
>
> Features:
> - 4 independent DAC channels
> - Hardware and software LDAC trigger
> - Configurable output range
> - PWM-based LDAC control
> - Dither and toggle modes
> - Dynamically configurable SPI speed
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
>
Hi Alexis,
A few little comments from me.
Thanks,
Jonathan
> diff --git a/drivers/iio/dac/ad5706r.c b/drivers/iio/dac/ad5706r.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..026f871ce121cd63331b2a34da8879491b2d0f3c
> --- /dev/null
> +++ b/drivers/iio/dac/ad5706r.c
> @@ -0,0 +1,253 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * AD5706R 16-bit Current Output Digital to Analog Converter
> + *
> + * Copyright 2026 Analog Devices Inc.
> + */
> +
> +#include <linux/array_size.h>
> +#include <linux/bits.h>
> +#include <linux/dev_printk.h>
> +#include <linux/err.h>
> +#include <linux/iio/iio.h>
> +#include <linux/minmax.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/spi/spi.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>
> +
> +/* SPI frame layout */
> +#define AD5706R_RD_MASK BIT(15)
> +#define AD5706R_ADDR_MASK GENMASK(11, 0)
> +
> +/* Registers */
> +#define AD5706R_REG_DAC_INPUT_A_CH(x) (0x60 + ((x) * 2))
> +#define AD5706R_REG_DAC_DATA_READBACK_CH(x) (0x68 + ((x) * 2))
> +
> +#define AD5706R_DAC_RESOLUTION 16
> +#define AD5706R_DAC_MAX_CODE BIT(16)
Trivial but I'd expect something called MAX_CODE to be GENMASK(15, 0)
not BIT(16). E.g. inclusive limit.
> +#define AD5706R_MULTIBYTE_REG_START 0x14
> +#define AD5706R_MULTIBYTE_REG_END 0x71
> +#define AD5706R_MAX_REG 0x77
> +#define AD5706R_SINGLE_BYTE_LEN 1
> +#define AD5706R_DOUBLE_BYTE_LEN 2
See below. I'm not sure these two defines bring us anything.
> +
> +struct ad5706r_state {
> + struct spi_device *spi;
> + struct regmap *regmap;
> +
> + u8 tx_buf[4] __aligned(IIO_DMA_MINALIGN);
> + u8 rx_buf[4];
> +};
> +
> +static int ad5706r_reg_len(unsigned int reg)
> +{
> + if (reg >= AD5706R_MULTIBYTE_REG_START && reg <= AD5706R_MULTIBYTE_REG_END)
> + return AD5706R_DOUBLE_BYTE_LEN;
What do the defines for 2 == 2-bytes and 1 == 1-byte bring us over using numbers
directly? E.g.
if (reg >= AD5706R_MULTIBYTE_REG_START && reg <= AD5706R_MULTIBYTE_REG_END)
return 2;
return 1;
> +
> + return AD5706R_SINGLE_BYTE_LEN;
> +}
> +
> +static int ad5706r_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct ad5706r_state *st = context;
> + unsigned int num_bytes, val;
> + u16 reg;
> +
> + if (count != 4)
> + return -EINVAL;
> +
> + reg = get_unaligned_be16(data);
> + num_bytes = ad5706r_reg_len(reg);
> +
> + struct spi_transfer xfer = {
> + .tx_buf = st->tx_buf,
> + .len = num_bytes + 2,
> + };
> +
> + val = get_unaligned_be32(data);
> + put_unaligned_be32(val, &st->tx_buf[0]);
> +
> + /* For single byte, copy the data to the correct position */
> + if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
> + st->tx_buf[2] = st->tx_buf[3];
This does feel a bit odd vs using if / else if as you do in the read
case. Also, same as above wrt to single bytes having a length of
1 meaning that just using a 1 might be easier to read.
> +
> + return spi_sync_transfer(st->spi, &xfer, 1);
> +}
> +static int ad5706r_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct ad5706r_state *st = iio_priv(indio_dev);
> + unsigned int reg;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!in_range(val, 0, AD5706R_DAC_MAX_CODE))
I'm not seeing a strong reason to use in_range() here (hopefully
I didn't suggest it in an earlier review ;) It make sense when
we have a val >= base && val < base + length. With base as 0
and MAX_CODE not 'obviously' from it's name being the length
(it only is becauset he base is 0) this seems odd.
if (val < 0 || val >= AD5706R_DAC_MAX_CODE)
Though see above on MAX_CODE not being the maximum code...
> + return -EINVAL;
> +
> + reg = AD5706R_REG_DAC_INPUT_A_CH(chan->channel);
> + return regmap_write(st->regmap, reg, val);
> + default:
> + return -EINVAL;
> + }
> +}
^ permalink raw reply
* Re: [PATCH v4] ASoC: dt-bindings: ti,pcm3060: add descriptions and rename binding
From: Kirill Marinushkin @ 2026-04-14 19:16 UTC (permalink / raw)
To: Padmashree S S
Cc: lgirdwood, broonie, robh, krzk+dt, conor+dt, linux-sound,
devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <CAEjBr-bdNvgBWjHei4K8LLH6QjkgHXCwtmW5qGoeh_36Vy8kWA@mail.gmail.com>
Hello Padmashree,
Allow me to once more propose this description, which
was in the original .txt, and you included into the patch v1, but
removed for v3:
> + reg:
> + maxItems: 1
> + description: The I2C address of the device or SPI chip select number.
You also probably would like to squash patch v4 with the previous patch v3
Best regards,
Kirill
On 4/14/26 3:22 PM, Padmashree S S wrote:
> On Tue, Apr 14, 2026 at 12:09 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Apr 14, 2026 at 09:18:54AM +0530, Padmashree S S wrote:
>>> Add description to reg property and overall binding mentioning that this
>>> driver supports both I2C and SPI. Rename binding to match compatible
>>> naming convention.
>>>
>>> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
>>> ---
>>> Changes in v4:
>>> - Rename binding from pcm3060 to ti,pcm3060
>>> - Add binding description
>>> - Add description to 'reg' property
>>> - Remove unused label in example
>>>
>>> Changes in v3:
>>> - Remove description from 'reg' property
>>> ---
>>> .../bindings/sound/{pcm3060.yaml => ti,pcm3060.yaml} | 10 +++++-----
>> What v4 is that of? There is no such file.
>>
>> Do not attach (thread) your patchsets to some other threads (unrelated
>> or older versions). This buries them deep in the mailbox and might
>> interfere with applying entire sets. See also:
>> https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
>>
>> Best regards,
>> Krzysztof
>>
> Thanks for pointing this out.
>
> Since this is a DT binding patch for the same pcm3060 device, I linked
> it to the previous version. However, I realize the subject changed
> significantly, which made the threading confusing.
>
> I’m planning to resend it as a new patch in a separate thread. Please
> let me know if that works.
^ permalink raw reply
* Re: [RFC PATCH 1/1] dt-bindings: iommu: riscv: Add bindings for Tenstorrent RISC-V IOMMU
From: Drew Fustini @ 2026-04-14 19:26 UTC (permalink / raw)
To: Joerg Roedel
Cc: Joel Stanley, Nicholas Piggin, devicetree, Tomasz Jeznach,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, linux-riscv,
linux-kernel, Michael Ellerman
In-Reply-To: <5tr5kacx27a4g4udx43vemqvwhr4iaflacdrkz3d5tnd6vcldo@s6l34e2xyg5k>
On Mon, Apr 13, 2026 at 01:37:32PM +0200, Joerg Roedel wrote:
> On Thu, Apr 02, 2026 at 01:35:19PM -0700, Drew Fustini wrote:
> > I think it would go through Joerg's iommu tree, but I could if Joerg can
> > an Ack.
>
> I do not have the original patch in my inbox, but looking at it via lore it
> lgtm.
>
> Acked-by: Joerg Roedel <joerg.roedel@amd.com>
Is it okay for me to take it through tenstorrent-dt-for-next or would
you like to take it through iommu tree?
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Nord SoC
From: Dmitry Baryshkov @ 2026-04-14 19:27 UTC (permalink / raw)
To: Shawn Guo
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Kamal Wadhwa, Taniya Das,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20260414035909.652992-4-shengchao.guo@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 11:59:09AM +0800, Shawn Guo wrote:
> From: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
>
> Add RPMh power domains required for Nord SoC. This includes
> new definitions for power domains supplying GFX1 and NSP3 subsystem.
>
> Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> drivers/pmdomain/qcom/rpmhpd.c | 35 ++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: Phandles
From: Kyle Bonnici @ 2026-04-14 19:31 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Herve Codina,
devicetree-compiler@vger.kernel.org, Krzysztof Kozlowski,
Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <CAL_JsqL2bRmX6qeapqqZZx=V7ARA_XbenrTqNk4ru2AAR24VZg@mail.gmail.com>
> On 14 Apr 2026, at 17:24, Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Apr 13, 2026 at 4:50 AM Kyle Bonnici <kylebonnici@hotmail.com> wrote:
>>
>>
>>> You cannot have random values. I quoted the DT spec.
>>
>> Where in the DTS 0.4 spec are property names such as pwms, clocks
>> etc… mandated to be of format <phandle cell …>?
>
> I would not read too much into what is defined in the spec vs. what is
> defined in dtschema. It's a conscious decision that all these
> properties are not in the spec. The goal is the whole spec or at least
> any parts defining properties is just schemas and the spec is
> generated from the schemas. That's the only way new properties will
> get added to the spec (with a few exceptions). However, no one is
> working on generating the spec from schemas.
If that is the intention, then IMO this needs to be documented in the spec at the
very least so that anyone using devicetree knows what rules are mandatory
for that tool/system to comply and use common tools such as the DTC.
If this was documented in the spec I would be claiming zephyr has the bug for
not following the schemas, but with the current status quo if I calmed in the
zephyr issue that all properties named:
“cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”,
“mboxes”, “msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”,
“resets”, “clocks”, “sound_dai” and “thermal_sensors” MUST be of format
<phandle cell …> and the phandle must implement <specifier>-cell. I would
have no justification for my claim.
I have no issue with the rule book being clarified, but the spec cannot be
ambiguous otherwise it is not a specification.
>>> Well, we don't use discord but IRC... but that github issue also uses
>>> "pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;"
>>>
>>> So again - what is "1"?
>>>
>>> I am asking because if you use incorrect value as phandle value, then
>>> DTC warning is obviously expected and nothing to fix here.
>>
>> The warning is only valid if ‘1’ is expected to be a phandle which is what I am
>> Arguing the spec does not mandate this.
>>
>>> You asked why phandle has to be the first entry in phandle-value type? I
>>> responded that DT spec makes it.
>>
>> Which section in DTS 0.4 spec?
>
> Doesn't matter. How would you ever parse the properties if that's not
> the case. You have to have the phandle first to get the number of arg
> cells to find the next phandle. I suppose you could define some other
> convention, but it would have to be pretty much global like this
> convention is. And this convention dates back to the GPIO binding
> which dates back to at least 2005 if not the 1990s. And most of these
> properties you list date back to well before Zephyr existed.
>
> The spec, dtc and the dts format will let you do something like this:
>
> foo = <0x12345678>, "bar", /bits/ 16 <0xabcd>;
>
> You would have to be out of your mind to do something like that when
> the format has zero type information.
By allowing it IMO with the public information on devicetree, the DTS spec
is offloading the responsibility of this property to the bindings system.
Section 4.1.1 makes this split in responsibility very clear IMO. This is why
I am expressing that this is a bug in the DTC as without this discussion with
All of you I cannot determine with certainty if the DTC is overstepping it’s
responsibilities or if zephyr did not follow the rules for these property names.
> Every warning in dtc can be disabled. So if they are a problem, turn them off.
That can be a temporary workaround if accepted upstream in zephyr,
however I also see hardening the specification as more future proof.
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: msm8916-panasonic-eluga-u2: add initial device tree
From: Dmitry Baryshkov @ 2026-04-14 19:41 UTC (permalink / raw)
To: Lin, Meng-Bo
Cc: linux-kernel, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
phone-devel, ~postmarketos/upstreaming
In-Reply-To: <20260414184429.168612-3-linmengbo06890@proton.me>
On Tue, Apr 14, 2026 at 06:44:55PM +0000, Lin, Meng-Bo wrote:
> Panasonic ELUGA U2 is a phone using the MSM8916 SoC released in 2015.
>
> Add a device tree for with initial support for:
>
> - GPIO keys
> - GPIO LEDs
> - pm8916-vibrator
> - SDHCI (internal and external storage)
> - USB Device Mode
> - UART
> - Regulators
>
> Signed-off-by: "Lin, Meng-Bo" <linmengbo06890@proton.me>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../dts/qcom/msm8916-panasonic-eluga-u2.dts | 149 ++++++++++++++++++
> 2 files changed, 150 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/msm8916-panasonic-eluga-u2.dts
>
> +&venus {
> + status = "okay";
Does it work with the standard Venus firmware or do you use a
device-specific one?
> +};
> +
> +&venus_mem {
> + status = "okay";
> +};
> --
> 2.47.3
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: mfd: syscon: add qcom,msm8960-sps-sic
From: Antony Kurniawan Soemardi @ 2026-04-14 18:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio,
linux-arm-msm, linux-clk, devicetree, linux-kernel, phone-devel,
Rudraksha Gupta
In-Reply-To: <20260414-frisky-aloof-koala-4cbfdb@quoll>
On 4/14/2026 2:19 PM, Krzysztof Kozlowski wrote:
> This was also sent. Where is the changelog and versioning? What changed
> here?
Sorry, the cover letter should have referenced the earlier dt-bindings
series [1] and explained about it.
In this patch series, I combined the original 2 patches into a larger 10
patch series to make it more complete. Especially since earlier feedback
noted that the bindings were not used by any in-tree consumers. Since
the scope changed significantly from the original, I resent it as a new
series rather than a v2.
Would you prefer splitting this series into separate series like before,
for example:
1. Dt-binding series:
- dt-bindings: clock: qcom,rpmcc: add msm8960 compatible
- dt-bindings: mfd: syscon: add qcom,msm8960-sps-sic
2. Enable wcnss series:
- mfd: qcom_rpm: add msm8960 QDSS clock resource
- clk: qcom: clk-rpm: add msm8960 compatible
- ARM: dts: qcom: msm8960: add rpm clock controller node
- ARM: dts: qcom: msm8960: add scm node
- ARM: dts: qcom: msm8960: add smem & hwmutex nodes
- ARM: dts: qcom: msm8960: add smsm & sps nodes
- ARM: dts: qcom: msm8960: add riva nodes
- ARM: dts: qcom: msm8960: huashan: add riva node
[1]
https://lore.kernel.org/all/20260218-msm8960-sps-rpm-bindings-v1-0-bbc11c0d4f24@smankusors.com/
--
Thanks,
Antony K. S.
^ permalink raw reply
* [PATCH 0/4] PXA1908 clock controller resets
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
Hello,
This series adds the resets found on Marvell PXA1908's APBC and APBCP
clock controllers.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
Duje Mihanović (4):
dt-bindings: clock: marvell,pxa1908: Add #reset-cells
clk: mmp: pxa1908-apbc: Add reset cells
clk: mmp: pxa1908-apbcp: Add reset cells
arm64: dts: marvell: mmp: pxa1908: Add reset cells
.../devicetree/bindings/clock/marvell,pxa1908.yaml | 34 +++++++++----
arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi | 14 ++++++
drivers/clk/mmp/clk-pxa1908-apbc.c | 58 ++++++++++++++++------
drivers/clk/mmp/clk-pxa1908-apbcp.c | 31 ++++++++++--
4 files changed, 110 insertions(+), 27 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260414-pxa1908-clk-reset-179c3f1d6214
Best regards,
--
Duje Mihanović <duje@dujemihanovic.xyz>
^ permalink raw reply
* [PATCH 1/4] dt-bindings: clock: marvell,pxa1908: Add #reset-cells
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260414-pxa1908-clk-reset-v1-0-94bae5f3a8cf@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
The APBC and APBCP controllers have reset lines exposed. Give them
a #reset-cells so that they may be used as reset controllers.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
.../devicetree/bindings/clock/marvell,pxa1908.yaml | 34 +++++++++++++++-------
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
index 6f3a8578fe2a..0db5504013d5 100644
--- a/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
+++ b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
@@ -37,6 +37,9 @@ properties:
'#power-domain-cells':
const: 1
+ '#reset-cells':
+ const: 1
+
required:
- compatible
- reg
@@ -44,16 +47,27 @@ required:
additionalProperties: false
-if:
- not:
- properties:
- compatible:
- contains:
- const: marvell,pxa1908-apmu
-
-then:
- properties:
- '#power-domain-cells': false
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: marvell,pxa1908-apmu
+ then:
+ properties:
+ '#power-domain-cells': false
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,pxa1908-apbc
+ - marvell,pxa1908-apbcp
+ then:
+ properties:
+ '#reset-cells': false
examples:
# APMU block:
--
2.53.0
^ permalink raw reply related
* [PATCH 2/4] clk: mmp: pxa1908-apbc: Add reset cells
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260414-pxa1908-clk-reset-v1-0-94bae5f3a8cf@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
It has been concluded by comparing the gate clock masks and vendor code
between PXA1908/28 that PXA1908's APBC, similarly to PXA1928's APBC, has
controllable reset lines. Describe these in the driver for correctness.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
drivers/clk/mmp/clk-pxa1908-apbc.c | 58 +++++++++++++++++++++++++++++---------
1 file changed, 44 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/mmp/clk-pxa1908-apbc.c b/drivers/clk/mmp/clk-pxa1908-apbc.c
index 3fd7b5e644f3..438ece4f047d 100644
--- a/drivers/clk/mmp/clk-pxa1908-apbc.c
+++ b/drivers/clk/mmp/clk-pxa1908-apbc.c
@@ -7,6 +7,7 @@
#include <dt-bindings/clock/marvell,pxa1908.h>
#include "clk.h"
+#include "reset.h"
#define APBC_UART0 0x0
#define APBC_UART1 0x4
@@ -44,22 +45,25 @@ static const char * const uart_parent_names[] = {"pll1_117", "uart_pll"};
static const char * const ssp_parent_names[] = {"pll1_d16", "pll1_d48", "pll1_d24", "pll1_d12"};
static struct mmp_param_gate_clk apbc_gate_clks[] = {
- {PXA1908_CLK_TWSI0, "twsi0_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI0, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_TWSI1, "twsi1_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI1, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_TWSI3, "twsi3_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI3, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_GPIO, "gpio_clk", "vctcxo", CLK_SET_RATE_PARENT, APBC_GPIO, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_KPC, "kpc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_KPC, 0x7, 3, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
- {PXA1908_CLK_RTC, "rtc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_RTC, 0x87, 0x83, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
+ {PXA1908_CLK_TWSI0, "twsi0_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI0, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_TWSI1, "twsi1_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI1, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_TWSI3, "twsi3_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI3, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_GPIO, "gpio_clk", "vctcxo", CLK_SET_RATE_PARENT, APBC_GPIO, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_KPC, "kpc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_KPC, 0x3, 3, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
+ {PXA1908_CLK_RTC, "rtc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_RTC, 0x83, 0x83, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
+ {PXA1908_CLK_PWM1, "pwm1_clk", "pwm01_apb_share", CLK_SET_RATE_PARENT, APBC_PWM1, 0x2, 2, 0, 0, NULL},
+ {PXA1908_CLK_PWM3, "pwm3_clk", "pwm23_apb_share", CLK_SET_RATE_PARENT, APBC_PWM3, 0x2, 2, 0, 0, NULL},
+ {PXA1908_CLK_UART0, "uart0_clk", "uart0_mux", CLK_SET_RATE_PARENT, APBC_UART0, 0x3, 3, 0, 0, &uart0_lock},
+ {PXA1908_CLK_UART1, "uart1_clk", "uart1_mux", CLK_SET_RATE_PARENT, APBC_UART1, 0x3, 3, 0, 0, &uart1_lock},
+ {PXA1908_CLK_THERMAL, "thermal_clk", NULL, 0, APBC_THERMAL, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_IPC_RST, "ipc_clk", NULL, 0, APBC_IPC_RST, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_SSP0, "ssp0_clk", "ssp0_mux", 0, APBC_SSP0, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_SSP2, "ssp2_clk", "ssp2_mux", 0, APBC_SSP2, 0x3, 3, 0, 0, NULL},
+};
+
+static struct mmp_param_gate_clk apbc_gate_no_reset_clks[] = {
{PXA1908_CLK_PWM0, "pwm0_clk", "pwm01_apb_share", CLK_SET_RATE_PARENT, APBC_PWM0, 0x2, 2, 0, 0, &pwm0_lock},
- {PXA1908_CLK_PWM1, "pwm1_clk", "pwm01_apb_share", CLK_SET_RATE_PARENT, APBC_PWM1, 0x6, 2, 0, 0, NULL},
{PXA1908_CLK_PWM2, "pwm2_clk", "pwm23_apb_share", CLK_SET_RATE_PARENT, APBC_PWM2, 0x2, 2, 0, 0, NULL},
- {PXA1908_CLK_PWM3, "pwm3_clk", "pwm23_apb_share", CLK_SET_RATE_PARENT, APBC_PWM3, 0x6, 2, 0, 0, NULL},
- {PXA1908_CLK_UART0, "uart0_clk", "uart0_mux", CLK_SET_RATE_PARENT, APBC_UART0, 0x7, 3, 0, 0, &uart0_lock},
- {PXA1908_CLK_UART1, "uart1_clk", "uart1_mux", CLK_SET_RATE_PARENT, APBC_UART1, 0x7, 3, 0, 0, &uart1_lock},
- {PXA1908_CLK_THERMAL, "thermal_clk", NULL, 0, APBC_THERMAL, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_IPC_RST, "ipc_clk", NULL, 0, APBC_IPC_RST, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_SSP0, "ssp0_clk", "ssp0_mux", 0, APBC_SSP0, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_SSP2, "ssp2_clk", "ssp2_mux", 0, APBC_SSP2, 0x7, 3, 0, 0, NULL},
};
static struct mmp_param_mux_clk apbc_mux_clks[] = {
@@ -89,6 +93,30 @@ static void pxa1908_apb_periph_clk_init(struct pxa1908_clk_unit *pxa_unit)
ARRAY_SIZE(apbc_mux_clks));
mmp_register_gate_clks(unit, apbc_gate_clks, pxa_unit->base,
ARRAY_SIZE(apbc_gate_clks));
+ mmp_register_gate_clks(unit, apbc_gate_no_reset_clks, pxa_unit->base,
+ ARRAY_SIZE(apbc_gate_no_reset_clks));
+}
+
+/* Taken from clk-of-pxa1928.c */
+static void pxa1908_clk_reset_init(struct device_node *np,
+ struct pxa1908_clk_unit *pxa_unit)
+{
+ struct mmp_clk_reset_cell *cells;
+ int nr_cells = ARRAY_SIZE(apbc_gate_clks);
+
+ cells = kzalloc_objs(*cells, nr_cells);
+ if (!cells)
+ return;
+
+ for (int i = 0; i < nr_cells; i++) {
+ cells[i].clk_id = apbc_gate_clks[i].id;
+ cells[i].reg = pxa_unit->base + apbc_gate_clks[i].offset;
+ cells[i].bits = BIT(2);
+ cells[i].flags = 0;
+ cells[i].lock = apbc_gate_clks[i].lock;
+ };
+
+ mmp_clk_reset_register(np, cells, nr_cells);
}
static int pxa1908_apbc_probe(struct platform_device *pdev)
@@ -107,6 +135,8 @@ static int pxa1908_apbc_probe(struct platform_device *pdev)
pxa1908_apb_periph_clk_init(pxa_unit);
+ pxa1908_clk_reset_init(pdev->dev.of_node, pxa_unit);
+
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 3/4] clk: mmp: pxa1908-apbcp: Add reset cells
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260414-pxa1908-clk-reset-v1-0-94bae5f3a8cf@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
It has been concluded by comparing the gate clock masks and vendor code
between PXA1908/28 that PXA1908's APBCP, similarly to PXA1928's APBC,
has controllable reset lines. Describe these in the driver for
correctness.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
drivers/clk/mmp/clk-pxa1908-apbcp.c | 31 ++++++++++++++++++++++++++++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mmp/clk-pxa1908-apbcp.c b/drivers/clk/mmp/clk-pxa1908-apbcp.c
index f638d7e89b47..1aa476103553 100644
--- a/drivers/clk/mmp/clk-pxa1908-apbcp.c
+++ b/drivers/clk/mmp/clk-pxa1908-apbcp.c
@@ -7,6 +7,7 @@
#include <dt-bindings/clock/marvell,pxa1908.h>
#include "clk.h"
+#include "reset.h"
#define APBCP_UART2 0x1c
#define APBCP_TWSI2 0x28
@@ -24,9 +25,9 @@ static DEFINE_SPINLOCK(uart2_lock);
static const char * const uart_parent_names[] = {"pll1_117", "uart_pll"};
static struct mmp_param_gate_clk apbcp_gate_clks[] = {
- {PXA1908_CLK_UART2, "uart2_clk", "uart2_mux", CLK_SET_RATE_PARENT, APBCP_UART2, 0x7, 0x3, 0x0, 0, &uart2_lock},
- {PXA1908_CLK_TWSI2, "twsi2_clk", "pll1_32", CLK_SET_RATE_PARENT, APBCP_TWSI2, 0x7, 0x3, 0x0, 0, NULL},
- {PXA1908_CLK_AICER, "ripc_clk", NULL, 0, APBCP_AICER, 0x7, 0x2, 0x0, 0, NULL},
+ {PXA1908_CLK_UART2, "uart2_clk", "uart2_mux", CLK_SET_RATE_PARENT, APBCP_UART2, 0x3, 0x3, 0x0, 0, &uart2_lock},
+ {PXA1908_CLK_TWSI2, "twsi2_clk", "pll1_32", CLK_SET_RATE_PARENT, APBCP_TWSI2, 0x3, 0x3, 0x0, 0, NULL},
+ {PXA1908_CLK_AICER, "ripc_clk", NULL, 0, APBCP_AICER, 0x3, 0x2, 0x0, 0, NULL},
};
static struct mmp_param_mux_clk apbcp_mux_clks[] = {
@@ -43,6 +44,28 @@ static void pxa1908_apb_p_periph_clk_init(struct pxa1908_clk_unit *pxa_unit)
ARRAY_SIZE(apbcp_gate_clks));
}
+/* Taken from clk-of-pxa1928.c */
+static void pxa1908_clk_reset_init(struct device_node *np,
+ struct pxa1908_clk_unit *pxa_unit)
+{
+ struct mmp_clk_reset_cell *cells;
+ int nr_cells = ARRAY_SIZE(apbcp_gate_clks);
+
+ cells = kzalloc_objs(*cells, nr_cells);
+ if (!cells)
+ return;
+
+ for (int i = 0; i < nr_cells; i++) {
+ cells[i].clk_id = apbcp_gate_clks[i].id;
+ cells[i].reg = pxa_unit->base + apbcp_gate_clks[i].offset;
+ cells[i].bits = BIT(2);
+ cells[i].flags = 0;
+ cells[i].lock = apbcp_gate_clks[i].lock;
+ };
+
+ mmp_clk_reset_register(np, cells, nr_cells);
+}
+
static int pxa1908_apbcp_probe(struct platform_device *pdev)
{
struct pxa1908_clk_unit *pxa_unit;
@@ -59,6 +82,8 @@ static int pxa1908_apbcp_probe(struct platform_device *pdev)
pxa1908_apb_p_periph_clk_init(pxa_unit);
+ pxa1908_clk_reset_init(pdev->dev.of_node, pxa_unit);
+
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: marvell: mmp: pxa1908: Add reset cells
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260414-pxa1908-clk-reset-v1-0-94bae5f3a8cf@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
Add the newly implemented reset cells to the SoC dtsi.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi b/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi
index 5778bfdb8567..05b56a759e27 100644
--- a/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi
+++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi
@@ -132,6 +132,7 @@ twsi1: i2c@10800 {
reg = <0x10800 0x64>;
interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_TWSI1>;
+ resets = <&apbc PXA1908_CLK_TWSI1>;
mrvl,i2c-fast-mode;
status = "disabled";
};
@@ -143,6 +144,7 @@ twsi0: i2c@11000 {
reg = <0x11000 0x64>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_TWSI0>;
+ resets = <&apbc PXA1908_CLK_TWSI0>;
mrvl,i2c-fast-mode;
status = "disabled";
};
@@ -154,6 +156,7 @@ twsi3: i2c@13800 {
reg = <0x13800 0x64>;
interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_TWSI3>;
+ resets = <&apbc PXA1908_CLK_TWSI3>;
mrvl,i2c-fast-mode;
status = "disabled";
};
@@ -162,6 +165,7 @@ apbc: clock-controller@15000 {
compatible = "marvell,pxa1908-apbc";
reg = <0x15000 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
uart0: serial@17000 {
@@ -169,6 +173,7 @@ uart0: serial@17000 {
reg = <0x17000 0x1000>;
interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_UART0>;
+ resets = <&apbc PXA1908_CLK_UART0>;
reg-shift = <2>;
};
@@ -177,6 +182,7 @@ uart1: serial@18000 {
reg = <0x18000 0x1000>;
interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_UART1>;
+ resets = <&apbc PXA1908_CLK_UART1>;
reg-shift = <2>;
};
@@ -188,6 +194,7 @@ gpio: gpio@19000 {
gpio-controller;
#gpio-cells = <2>;
clocks = <&apbc PXA1908_CLK_GPIO>;
+ resets = <&apbc PXA1908_CLK_GPIO>;
interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "gpio_mux";
interrupt-controller;
@@ -215,6 +222,7 @@ pwm0: pwm@1a000 {
compatible = "marvell,pxa250-pwm";
reg = <0x1a000 0x10>;
clocks = <&apbc PXA1908_CLK_PWM0>;
+ resets = <&apbc PXA1908_CLK_PWM0>;
#pwm-cells = <1>;
status = "disabled";
};
@@ -223,6 +231,7 @@ pwm1: pwm@1a400 {
compatible = "marvell,pxa250-pwm";
reg = <0x1a400 0x10>;
clocks = <&apbc PXA1908_CLK_PWM1>;
+ resets = <&apbc PXA1908_CLK_PWM1>;
#pwm-cells = <1>;
status = "disabled";
};
@@ -231,6 +240,7 @@ pwm2: pwm@1a800 {
compatible = "marvell,pxa250-pwm";
reg = <0x1a800 0x10>;
clocks = <&apbc PXA1908_CLK_PWM2>;
+ resets = <&apbc PXA1908_CLK_PWM2>;
#pwm-cells = <1>;
status = "disabled";
};
@@ -239,6 +249,7 @@ pwm3: pwm@1ac00 {
compatible = "marvell,pxa250-pwm";
reg = <0x1ac00 0x10>;
clocks = <&apbc PXA1908_CLK_PWM3>;
+ resets = <&apbc PXA1908_CLK_PWM3>;
#pwm-cells = <1>;
status = "disabled";
};
@@ -261,6 +272,7 @@ uart2: serial@36000 {
reg = <0x36000 0x1000>;
interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbcp PXA1908_CLK_UART2>;
+ resets = <&apbcp PXA1908_CLK_UART2>;
reg-shift = <2>;
};
@@ -271,6 +283,7 @@ twsi2: i2c@37000 {
reg = <0x37000 0x64>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbcp PXA1908_CLK_TWSI2>;
+ resets = <&apbcp PXA1908_CLK_TWSI2>;
mrvl,i2c-fast-mode;
status = "disabled";
};
@@ -279,6 +292,7 @@ apbcp: clock-controller@3b000 {
compatible = "marvell,pxa1908-apbcp";
reg = <0x3b000 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
mpmu: clock-controller@50000 {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RESEND] arm64: dts: apple: fix spelling error
From: Sven Peter @ 2026-04-14 20:21 UTC (permalink / raw)
To: asahi, linux-arm-kernel, devicetree, linux-kernel, Axel Flordal
Cc: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <2338500.vFx2qVVIhK@fedora>
On Wed, 08 Apr 2026 07:21:23 +0000, Axel Flordal wrote:
> Change "configiguration" to "configuration".
>
>
Applied to local tree (apple-soc/fixes-7.0), thanks!
[1/1] arm64: dts: apple: fix spelling error
https://github.com/AsahiLinux/linux/commit/c7ff53ef45b2
Best regards,
--
Sven Peter <sven@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/2] Update Sasha Finkelstein's email address
From: Sven Peter @ 2026-04-14 20:21 UTC (permalink / raw)
To: Janne Grunau, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neal Gompa, asahi, Sasha Finkelstein
Cc: Sven Peter, linux-kernel, devicetree
In-Reply-To: <20260411-mailmap-v1-0-5a519f7b00b5@chaosmail.tech>
On Sat, 11 Apr 2026 16:36:06 +0200, Sasha Finkelstein wrote:
> Moving away from gmail
>
>
Applied to local tree (apple-soc/fixes-7.0), thanks!
[1/2] mailmap: Update Sasha Finkelstein's email address
https://github.com/AsahiLinux/linux/commit/b04a4f8ff704
[2/2] dt-bindings: Update Sasha Finkelstein's email address
https://github.com/AsahiLinux/linux/commit/44d9ae042c58
Best regards,
--
Sven Peter <sven@kernel.org>
^ permalink raw reply
* [PATCH v7 0/6] Add support for Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
This series adds initial support for Orange Pi 5 Pro. The PCIe attached
network driver(dwmac-motorcomm) was just added.
The series was tested against Linux 7.0-rc7
Please take a look.
Thank you,
Dennis Gilmore
Changes in v7:
- Fix up whitespace issues identified by checkpatch.pl --strict in
rk3588s-orangepi-5-5b.dtsi
- checkpatch gave a warning for WARNING: phy-mode "rgmii-rxid" without
comment, as this was moved over I left it untouched
- Added lontium,lt8711uxd to the compatible enum in the simple-bridge
binding
- Added lontium,lt8711uxd match entry with DRM_MODE_CONNECTOR_HDMIA to
the simple-bridge driver
- New patch to rename the regulator labels for the es8388 supplies to
match the schematics as they all use vcca_*
- RK806 PLDO1 and PLDO2 outputs are swapped between the 5/5B and pro.
move their definition to the shared 5/5B dtsi and 5 Pro dts
- Fixed ES8388 PVDD-supply — vcca_3v3_s0 → vcca_1v8_s0, 5 Pro is
different to 5 and 5b.
- analog-sound: use CPU-as-clock-master on the Pro. The ES8388 is wired to
i2s2_2ch (the only I2S block physically routed to the codec pins on this
board), which uses the legacy rockchip_i2s driver. That driver's
slave-mode trigger path hangs for 200 µs polling I2S_CLR and bails with
-ETIMEDOUT ("lrclk update failed"). The TDM-capable i2s0/i2s1/i2s5
blocks served by rockchip_i2s_tdm don't have this issue, which is why
other mainline ES8388 boards get away with bitclock-master = masterdai.
Drop bitclock-master/frame-master and the masterdai label to let the I2S
block generate BCLK/LRCK itself
- Added pinctrl entries for all GPIO pins (dp_bridge_en, vcc3v3_phy1_en,
wifi_enable_h, pcie2x1l1_rst, pcie2x1l2_rst)
- DP bridge rework — replaced dp-connector node with proper chain:
- lt8711uxd bridge node (compatible lontium,lt8711uxd, with port@0/port@1
endpoints). Bridge power is gated by the vcc3v3_dp regulator, whose
enable GPIO (GPIO3_PC2) is driven via the dp_bridge_en pinctrl group;
no enable-gpios/vdd-supply on the bridge node itself.
- hdmi1-con connector node (compatible hdmi-connector, type a)
- dp0_out endpoint now points to bridge input instead of old connector
- drop accidentally included, unrelated changes to
drivers/gpu/drm/bridge/synopsys/dw-dp.c and
Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
- link to v6 https://lore.kernel.org/linux-devicetree/20260411024743.195385-1-dennis@ausil.us/
Changes in v6:
- Move the shared configs for the Orange Pi 5 and Orange Pi 5b from each
devices dts to a shared rk3588s-orangepi-5-5b.dtsi to avoid duplication
- Remove empty ports subnodeis from typea_con
- Move i2s2m1_mclk pinctrl from &i2s2 to the es8388 codec node
- Add dp-con, dp0_out, dp0_in, and vp1 nodes, plus the vcc3v3_dp regulator
in order to get the second HDMI port working via its transparent
LT8711UXD DP to HDMI bridge
- link to v5 https://lore.kernel.org/linux-devicetree/20260401010707.2584962-1-dennis@ausil.us/
Changes in v5:
- define a connector node for Type-A port, and list the regulator as its VBUS supply explicitly.
- Requires https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
- link to v4 https://lore.kernel.org/linux-devicetree/20260310031002.3921234-1-dennis@ausil.us/
Changes in v4:
- rename vcc3v3_pcie20 copied from rk3588s-orangepi-5.dts to vcc3v3_phy1 to match the schematic
- use vcc_3v3_s3 as the supply not vcc5v0_sys for PCIe
- remove the definition for vcc3v3_pcie_m2 as it does not really exist
as a regulator
- link to v3 https://lore.kernel.org/linux-devicetree/20260306024634.239614-1-dennis@ausil.us/
Changes in v3:
- moved leds from gpio-leds to pwm-leds
- remove disable-wp from sdio
- rename vcc3v3_pcie_eth regulator to vcc3v3_pcie_m2 to reflect the
purppose
- actually clean up the delete lines and comments missed in v2
- link to v2 https://lore.kernel.org/linux-devicetree/20260304025521.210377-1-dennis@ausil.us/
Changes in v2:
- moved items not shared by orangepi 5/5b/5 Pro from dtsi to 5 and 5b
dts files
- removed all the comments and deleted properties from 5 Pro dts
- Link to v1 https://lore.kernel.org/linux-devicetree/20260228205418.2944620-1-dennis@ausil.us/
Dennis Gilmore (6):
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
dt-bindings: display: bridge: simple: document the Lontium LT8711UXD
DP-to-HDMI bridge
drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels
to match schematic
arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for
Pro
arm64: dts: rockchip: Add Orange Pi 5 Pro board support
.../devicetree/bindings/arm/rockchip.yaml | 1 +
.../display/bridge/simple-bridge.yaml | 1 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 222 +++++++++
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 442 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 235 +---------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
drivers/gpu/drm/bridge/simple-bridge.c | 5 +
9 files changed, 695 insertions(+), 220 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
--
2.53.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox