* [PATCH v5 6/7] drm/verisilicon: add DCUltraLite chip identity to HWDB
From: Joey Lu @ 2026-06-25 9:44 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
In-Reply-To: <20260625094449.708386-1-a0987203069@gmail.com>
The Nuvoton MA35D1 chip contains a DCUltraLite display controller with
model number 0x0 (sic, the model name contains no number either),
revision 0x5560 and customer ID 0x305. It has a similar register map
with DC8000, only one display output and only 32x32 cursor supported.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
drivers/gpu/drm/verisilicon/vs_hwdb.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c b/drivers/gpu/drm/verisilicon/vs_hwdb.c
index 91524d16f778..7d630a667a3f 100644
--- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
+++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
@@ -129,6 +129,16 @@ static struct vs_chip_identity vs_chip_identities[] = {
.max_cursor_size = 64,
.formats = &vs_formats_no_yuv444,
},
+ {
+ .model = 0x0, /* DCUltraLite */
+ .revision = 0x5560,
+ .customer_id = 0x305,
+
+ .generation = VSDC_GEN_DC8000,
+ .display_count = 1,
+ .max_cursor_size = 32,
+ .formats = &vs_formats_no_yuv444,
+ },
};
int vs_fill_chip_identity(struct regmap *regs,
--
2.43.0
^ permalink raw reply related
* [PATCH v5 7/7] drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms
From: Joey Lu @ 2026-06-25 9:44 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
In-Reply-To: <20260625094449.708386-1-a0987203069@gmail.com>
Add ARCH_MA35 to the platform dependencies to allow the driver to be
built for Nuvoton MA35D1.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
drivers/gpu/drm/verisilicon/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/verisilicon/Kconfig b/drivers/gpu/drm/verisilicon/Kconfig
index 7cce86ec8603..295d246eb4b4 100644
--- a/drivers/gpu/drm/verisilicon/Kconfig
+++ b/drivers/gpu/drm/verisilicon/Kconfig
@@ -2,7 +2,7 @@
config DRM_VERISILICON_DC
tristate "DRM Support for Verisilicon DC-series display controllers"
depends on DRM && COMMON_CLK
- depends on RISCV || COMPILE_TEST
+ depends on RISCV || ARCH_MA35 || COMPILE_TEST
select DRM_BRIDGE_CONNECTOR
select DRM_CLIENT_SELECTION
select DRM_DISPLAY_HELPER
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: sashiko-bot @ 2026-06-25 9:54 UTC (permalink / raw)
To: Joey Lu; +Cc: devicetree, robh, dri-devel, conor+dt
In-Reply-To: <20260625094449.708386-2-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The Nuvoton MA35D1 conditional schema block logically conflicts with top-level constraints, causing validation of valid Nuvoton device trees to unconditionally fail.
- [Medium] The Nuvoton MA35D1 conditional block fails to restrict the `ports` property to a single output port, contradicting the hardware description.
--
commit 6779aa6e54db7988d8c51ba66d2a7972829a44e6
Author: Joey Lu <a0987203069@gmail.com>
dt-bindings: display: verisilicon,dc: generalize for single-output variants
This commit adds the Nuvoton MA35D1 DCUltraLite to the verisilicon,dc
binding. It introduces conditional blocks to express per-variant
constraints for clocks and resets rather than hard-coding the DC8200
topology at the top level.
> diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> index 9dc35ab973f20..1e751f3c7ce83 100644
> --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
[ ... ]
> +allOf:
[ ... ]
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nuvoton,ma35d1-dcu
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 2
> +
> + clock-names:
> + items:
> + - const: core
> + - const: pix0
[Severity: High]
Does this conditional schema conflict with the top-level constraints?
Any device tree node containing the compatible string for the Nuvoton
variant is evaluated against both the top-level schema and this conditional
block concurrently.
The top-level definitions strictly enforce a 5-item array and specific
constant values for clock-names (such as the second item being axi). This
block attempts to override those with a maximum of 2 items and restricts the
second item to pix0.
Since a length cannot be both exactly 5 and a maximum of 2, and an element
cannot be both axi and pix0, this creates an unsatisfiable constraint.
Will this cause validation of valid Nuvoton device trees to unconditionally
fail?
> +
> + resets:
> + minItems: 1
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: core
> +
> + required:
> + - resets
> + - reset-names
[Severity: Medium]
Does this block need to explicitly restrict the ports property to a single
output port?
The commit message states that the Nuvoton MA35D1 DCUltraLite has a single
output port. However, because this conditional block does not explicitly
disallow the second port, it inherits the top-level allowances.
Will malformed device trees incorrectly specifying two output ports for the
Nuvoton variant silently pass schema validation, bypassing the hardware
topology checks?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v5 3/7] drm/verisilicon: introduce per-variant hardware ops table
From: sashiko-bot @ 2026-06-25 10:00 UTC (permalink / raw)
To: Joey Lu; +Cc: conor+dt, devicetree, dri-devel, robh
In-Reply-To: <20260625094449.708386-4-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
New issues:
- [High] CRTC disable hardware operation is called after disabling the pixel clock.
- [High] The register clearing sequence in `vs_dc8200_panel_disable_ex` is inverted compared to the original code, clearing the configuration bit before stopping the panel.
- [Medium] Unknown hardware interrupts are silently filtered out by the irq_ack abstraction, rendering the unknown interrupt diagnostic warning unreachable.
Pre-existing issues:
- [High] Primary plane disable function incorrectly sets the enable bit rather than clearing it.
- [High] The driver requests its IRQ line before it fully initializes its internal state, creating a race condition that can lead to a NULL pointer dereference.
- [High] `vs_dc_irq_handler` unconditionally returns `IRQ_HANDLED` regardless of whether any interrupt bits were set.
--
commit d0e2c6765378754f6b5239526ba6f62ca9de0dd3
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: introduce per-variant hardware ops table
The DC8200 and DCUltraLite share a broadly similar register layout but differ
in how the bridge, CRTC, primary plane and IRQ paths are driven. This commit
introduces a vs_dc_funcs vtable so each variant can supply its own
implementation without scattering conditionals across multiple files.
> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c b/drivers/gpu/drm/verisilicon/vs_crtc.c
> index 0b8a35d09cd2e..1c4aac7086694 100644
> --- a/drivers/gpu/drm/verisilicon/vs_crtc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
[ ... ]
> @@ -30,6 +53,9 @@ static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
> drm_crtc_vblank_off(crtc);
>
> clk_disable_unprepare(dc->pix_clk[output]);
> +
> + if (dc->funcs->crtc_disable_ex)
> + dc->funcs->crtc_disable_ex(dc, output);
> }
[Severity: High]
Is it safe to access hardware registers via crtc_disable_ex() after the pixel
clock has been gated? The teardown order should typically reverse the
initialization order, meaning the hook must be invoked before gating the clock.
[ ... ]
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
> index dad9967bc10b8..9729b693d360e 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -33,7 +31,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void *private)
> struct vs_dc *dc = private;
> u32 irqs;
>
> - regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
> + irqs = dc->funcs->irq_ack(dc);
>
> vs_drm_handle_irq(dc, irqs);
>
> return IRQ_HANDLED;
[Severity: High]
This isn't a bug introduced by this patch, but does unconditionally returning
IRQ_HANDLED prevent the kernel from detecting and disabling a stuck shared
interrupt line? If the handler processes no interrupts, shouldn't it return
IRQ_NONE?
[Severity: High]
This is another pre-existing issue, but in vs_dc_probe(), the IRQ is
requested before vs_drm_initialize() is called. Can the IRQ handler fire
before dc->drm_dev is allocated, resulting in a NULL pointer dereference
when vs_drm_handle_irq() executes?
[ ... ]
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8200.c b/drivers/gpu/drm/verisilicon/vs_dc8200.c
> new file mode 100644
> index 0000000000000..17378f4ef96d1
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8200.c
[ ... ]
> +static void vs_dc8200_panel_disable_ex(struct vs_dc *dc, unsigned int output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
> + VSDC_DISP_PANEL_CONFIG_RUNNING);
> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
> + VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
> + VSDC_DISP_PANEL_START_RUNNING(output));
[Severity: High]
Does reversing the clear order of the configuration and start registers risk
hardware underflows or state desynchronization? In the original
vs_bridge_atomic_disable() implementation, the panel was shut down by first
clearing VSDC_DISP_PANEL_START_RUNNING and then clearing
VSDC_DISP_PANEL_CONFIG_RUNNING.
[ ... ]
> +static void vs_dc8200_primary_plane_disable_ex(struct vs_dc *dc, unsigned int output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_FB_EN);
> +
> + vs_dc8200_plane_commit(dc, output);
> +}
[Severity: High]
This is a pre-existing issue carried over from the original code, but does
the primary plane disable sequence leave the plane enabled by using
regmap_set_bits() instead of clearing the VSDC_FB_CONFIG_EX_FB_EN bit?
[ ... ]
> +static u32 vs_dc8200_irq_ack(struct vs_dc *dc)
> +{
> + u32 hw_irqs, unified = 0;
> + unsigned int i;
> +
> + regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &hw_irqs);
> +
> + for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
> + if (hw_irqs & VSDC_TOP_IRQ_VSYNC(i))
> + unified |= VSDC_IRQ_VSYNC(i);
> + }
> +
> + return unified;
> +}
[Severity: Medium]
Does this filter out unknown hardware interrupts, making the diagnostic
warning in vs_drm_handle_irq() unreachable? By only passing through known
VSDC_IRQ_VSYNC bits, any unmapped hardware interrupt bits are silently
discarded.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v5 4/7] drm/verisilicon: make axi and ahb clocks optional
From: sashiko-bot @ 2026-06-25 10:01 UTC (permalink / raw)
To: Joey Lu; +Cc: devicetree, conor+dt, dri-devel, robh
In-Reply-To: <20260625094449.708386-5-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Possible NULL pointer dereference in the IRQ handler if an interrupt triggers before DRM initialization completes.
--
commit 2cd6077ab2fb5ed065ee2cef55004b713c80f827
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: make axi and ahb clocks optional
The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller whose
AXI and AHB bus clocks share a single gate enable bit with the display
core clock, so the clock driver does not expose them separately. This
patch makes the axi and ahb clocks optional in the probe.
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
> index 9729b693d360e..fd1f5fe67a68b 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
[ ... ]
> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device *pdev)
> return PTR_ERR(dc->core_clk);
> }
>
> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
> if (IS_ERR(dc->axi_clk)) {
[Severity: High]
This is a pre-existing issue, but is it possible for an interrupt to trigger
a NULL pointer dereference during probe if the bootloader left the display
active?
Looking further down in vs_dc_probe(), the IRQ handler is registered before
vs_drm_initialize() is called:
ret = devm_request_irq(dev, irq, vs_dc_irq_handler, 0,
dev_name(dev), dc);
if (ret) {
dev_err(dev, "can't request irq\n");
goto err_rst_assert;
}
dev_set_drvdata(dev, dc);
ret = vs_drm_initialize(dc, pdev);
If a pending interrupt (such as VSYNC) fires immediately after
devm_request_irq() is called, vs_dc_irq_handler() will be triggered and will
eventually call vs_drm_handle_irq().
Looking at vs_drm_handle_irq() in vs_drm.c, it unconditionally dereferences
the drm_dev pointer:
if (dc->drm_dev->crtcs[i])
drm_crtc_handle_vblank(&dc->drm_dev->crtcs[i]->base);
Since vs_drm_initialize() hasn't allocated or assigned dc->drm_dev yet,
could this cause a kernel panic during boot on platforms where the bootloader
leaves interrupts enabled?
Would it be safer to request the IRQ after the DRM device is fully
initialized, or to mask interrupts in the hardware before registering the
handler?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=4
^ permalink raw reply
* RE: [PATCH v9 02/12] reset: Add Realtek basic reset support
From: Yu-Chun Lin [林祐君] @ 2026-06-25 10:02 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <eb03894ae2765a426457238157e474087ea0aaa6.camel@pengutronix.de>
Hi Philipp,
> On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > +static int rtk_reset_deassert(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + const struct rtk_reset_desc *desc;
> > + u32 mask, val;
> > +
> > + desc = rtk_reset_get_desc(data, idx);
> > + mask = desc->write_en ? (0x3U << desc->bit) : BIT(desc->bit);
> > + val = mask;
> > +
> > + return regmap_update_bits(data->regmap, desc->ofs, mask, val);
>
> You can use regmap_set_bits() here.
>
Ack.
> > +}
> > +
> > +static int rtk_reset_status(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + const struct rtk_reset_desc *desc;
> > + u32 val;
>
> unsigned int val;
>
Ack.
> > + int ret;
> > +
> > + desc = rtk_reset_get_desc(data, idx);
> > + ret = regmap_read(data->regmap, desc->ofs, &val);
> > + if (ret)
> > + return ret;
> > +
> > + return !((val >> desc->bit) & 1); }
> > +
> > +static const struct reset_control_ops rtk_reset_ops = {
> > + .assert = rtk_reset_assert,
> > + .deassert = rtk_reset_deassert,
> > + .status = rtk_reset_status,
> > +};
> > +
> > +/* The caller must initialize data->descs, data->rcdev.nr_resets and
> > + * data->rcdev.owner before calling rtk_reset_controller_add().
> > + */
> > +int rtk_reset_controller_add(struct device *dev,
> > + struct rtk_reset_data *data) {
> > + data->regmap = dev_get_platdata(dev);
> > + data->rcdev.ops = &rtk_reset_ops;
> > + data->rcdev.dev = dev;
> > + data->rcdev.of_node = dev->parent->of_node;
>
> This split rcdev initialization is more hassle than it is worth.
> Please just export rtk_reset_ops and duplicate the regmap/ops/dev/of_node
> assignment in the probe functions.
>
> Alternatively, consolidate the probe function and export it from here.
>
Thanks for your suggestion. I will go with your first approach in v10.
Best Regards,
Yu-Chun
> regards
> Philipp
^ permalink raw reply
* RE: [PATCH v9 04/12] reset: realtek: Add RTD1625-ISO reset controller driver
From: Yu-Chun Lin [林祐君] @ 2026-06-25 10:05 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <9db83aa615f43ff6eac090626b43915fcd593a25.camel@pengutronix.de>
Hi Philipp,
> On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Add support for the ISO (Isolation) domain reset controller on the
> > Realtek
> > RTD1625 SoC.
> >
> > The reset controller shares the same register space with the ISO clock
> > controller. To handle this shared register space, the reset driver is
> > implemented as an auxiliary driver. It will be instantiated and probed
> > via the auxiliary bus by the RTD1625-ISO clock controller driver.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v9:
> > - Extract reset-related code from the previous clock driver patch
> > (formerly patch 9 in v8).
> > ---
> > drivers/reset/realtek/Makefile | 2 +-
> > drivers/reset/realtek/reset-rtd1625-iso.c | 99
> > +++++++++++++++++++++++
> > 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644
> > drivers/reset/realtek/reset-rtd1625-iso.c
> >
> > diff --git a/drivers/reset/realtek/Makefile
> > b/drivers/reset/realtek/Makefile index c3f605ffb11c..9007c9d5683b
> > 100644
> > --- a/drivers/reset/realtek/Makefile
> > +++ b/drivers/reset/realtek/Makefile
> > @@ -1,3 +1,3 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > obj-$(CONFIG_RESET_RTK_COMMON) += reset-rtk-common.o
> > -obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > +obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > +reset-rtd1625-iso.o
>
> Is there any benefit to these two being separate modules?
> I suggest you merge them into one: reset-rtd1625.o
>
If I merge them into a single 'reset-rtd1625' module,
both the 'crt' and 'iso' clock drivers would trigger the probe
process for the same reset driver name, which would lead to a
duplicate driver registration error.
Therefore, I would prefer to keep them separate.
> > diff --git a/drivers/reset/realtek/reset-rtd1625-iso.c
> > b/drivers/reset/realtek/reset-rtd1625-iso.c
> > new file mode 100644
> > index 000000000000..78eaabb408f0
> > --- /dev/null
> > +++ b/drivers/reset/realtek/reset-rtd1625-iso.c
> > @@ -0,0 +1,99 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2026 Realtek Semiconductor Corporation */
> > +
> > +#include <dt-bindings/reset/realtek,rtd1625.h>
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/device.h>
> > +#include <linux/errno.h>
> > +#include <linux/of.h>
> > +#include <linux/slab.h>
> > +#include "reset-rtk-common.h"
> > +
> > +#define RTD1625_ISO_RSTN_MAX 29
> > +#define RTD1625_ISO_S_RSTN_MAX 5
>
> These are not necessary, just use ARRAY_SIZE() for nr_resets.
>
Ack.
> > +
[...]
> > +
> > +static int rtd1625_iso_reset_probe(struct auxiliary_device *adev,
> > + const struct auxiliary_device_id *id)
> > +{
> > + struct device *dev = &adev->dev;
> > + struct device *parent = dev->parent;
> > + struct rtk_reset_data *data;
> > +
> > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + if (of_device_is_compatible(parent->of_node,
> "realtek,rtd1625-iso-s-clk")) {
> > + data->descs = rtd1625_iso_s_reset_descs;
> > + data->rcdev.nr_resets = RTD1625_ISO_S_RSTN_MAX;
> > + } else {
> > + data->descs = rtd1625_iso_reset_descs;
> > + data->rcdev.nr_resets = RTD1625_ISO_RSTN_MAX;
> > + }
>
> No need to parse OF compatible again. Store these in a struct, point
> auxiliary_device_id::driver_data to it, and use that here.
>
> regards
> Philipp
Agreed, I will do it in v10. Thanks.
Best Regards,
Yu-Chun
^ permalink raw reply
* RE: [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Paller, Kim Seer @ 2026-06-25 10:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Hennerich, Michael, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux, devicetree@vger.kernel.org
In-Reply-To: <ai_OeEegWavHcNF1@ashevche-desk.local>
> From: Andy Shevchenko <andriy.shevchenko@intel.com>
> Sent: Monday, June 15, 2026 6:06 PM
> To: Paller, Kim Seer <KimSeer.Paller@analog.com>
> Cc: Jonathan Cameron <jic23@kernel.org>; David Lechner
> <dlechner@baylibre.com>; Sa, Nuno <Nuno.Sa@analog.com>; Andy
> Shevchenko <andy@kernel.org>; Hennerich, Michael
> <Michael.Hennerich@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; linux-
> iio@vger.kernel.org; linux-kernel@vger.kernel.org; linux <linux@analog.com>;
> devicetree@vger.kernel.org
> Subject: Re: [PATCH v2 4/4] iio: dac: ad3530r: Add support for
> AD3532R/AD3532
>
> [External]
>
> On Mon, Jun 15, 2026 at 02:20:18PM +0800, Kim Seer Paller wrote:
> > The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
> > dual-bank register architecture (bank 0 at 0x1000 for channels 0-7,
> > bank 1 at 0x3000 for channels 8-15). It shares similar functionality
> > with AD3530R (channel configuration, LDAC triggering, powerdown
> > control), the main difference being the register address map due to
> > the dual-bank architecture, handled by table-driven helpers.
> >
> > Add AD3532R-specific register definitions, channel specs, per-bank
> > register arrays, a dedicated ad3532r_set_dac_powerdown(), and per-chip
> > regmap_config to limit debugfs-exposed register space to each
> > variant's actual address range.
>
> ...
>
>
> > help
> > - Say yes here to build support for Analog Devices AD3530R, AD3531R
> > - Digital to Analog Converter.
> > + Say yes here to build support for Analog Devices AD3530/AD3530R,
> > + AD3531/AD3531R, and AD3532/AD3532R Digital to Analog
> Converters.
>
> This just shows how unscalable the above text is. That's why we usually
> recommend to make the list explicit and separated.
>
> Say yes here to build support for the following Analog Devices
> Digital to Analog Converters:
> - AD3530/AD3530R (8-channel)
> - AD3531/AD3531R (4-channel)
> - AD3532/AD3532R (16-channel)
>
> (and looking into the C-file change, perhaps add here as well distinctive
> information, such as number of channels, in the parentheses).
>
> > To compile this driver as a module, choose M here: the
> > module will be called ad3530r.
>
> ...
>
> > +#define AD3532R_INTERFACE_CONFIG_A_0 0x1000
> > +#define AD3532R_INTERFACE_CONFIG_A_1 0x3000
> > +#define AD3532R_OUTPUT_OPERATING_MODE_0 0x1020
> > +#define AD3532R_OUTPUT_OPERATING_MODE_1 0x1021
> > +#define AD3532R_OUTPUT_OPERATING_MODE_2 0x3020
> > +#define AD3532R_OUTPUT_OPERATING_MODE_3 0x3021
> > +#define AD3532R_OUTPUT_CONTROL_0 0x102A
> > +#define AD3532R_OUTPUT_CONTROL_1 0x302A
> > +#define AD3532R_REFERENCE_CONTROL_0 0x103C
> > +#define AD3532R_REFERENCE_CONTROL_1 0x303C
> > +#define AD3532R_SW_LDAC_TRIG_0 0x10E5
> > +#define AD3532R_SW_LDAC_TRIG_1 0x30E5
> > +#define AD3532R_INPUT_CH_0 0x10EB
> > +#define AD3532R_INPUT_CH_1 0x30EB
> > +#define AD3532R_MAX_REG_ADDR 0x30F9
>
> Hmm... I dunno if it's better to sort by values (so the "bank" 0 goes together
> followed by "bank" 1). Jonathan, what's your preference here? Nuno, David?
>
> ...
>
> > +static ssize_t ad3532r_set_dac_powerdown(struct iio_dev *indio_dev,
> > + uintptr_t private,
> > + const struct iio_chan_spec *chan,
> > + const char *buf, size_t len)
> > +{
> > + struct ad3530r_state *st = iio_priv(indio_dev);
> > + unsigned int reg, pdmode, mask, val, local_ch;
> > + bool powerdown;
> > + int ret;
> > +
> > + ret = kstrtobool(buf, &powerdown);
>
> Do you need to include kstrtox.h?
Yes, kstrtobool() is declared in <linux/kstrtox.h>. I also ran IWYU and
it confirms <linux/kstrtox.h> belongs in the include list.
>
> > + if (ret)
> > + return ret;
> > +
> > + guard(mutex)(&st->lock);
>
> + blank line here.
>
> > + local_ch = chan->channel % AD3530R_CH_PER_BANK;
>
> > + reg = (chan->channel < AD3530R_CH_PER_BANK ?
> AD3532R_OUTPUT_OPERATING_MODE_0 :
> > + AD3532R_OUTPUT_OPERATING_MODE_2) +
> > + local_ch / AD3530R_CH_PER_REG;
>
> This is unreadable. Can you refactor it?
Would this be clearer?
unsigned int bank_base;
local_ch = chan->channel % AD3530R_CH_PER_BANK;
bank_base = chan->channel < AD3530R_CH_PER_BANK ?
AD3532R_OUTPUT_OPERATING_MODE_0 : AD3532R_OUTPUT_OPERATING_MODE_2;
reg = bank_base + local_ch / AD3530R_CH_PER_REG;
>
> > + mask = AD3530R_OP_MODE_CHAN_MSK(local_ch %
> AD3530R_CH_PER_REG);
> > +
> > + pdmode = powerdown ? st->chan[chan->channel].powerdown_mode :
> 0;
> > + val = field_prep(mask, pdmode);
> > +
> > + ret = regmap_update_bits(st->regmap, reg, mask, val);
> > + if (ret)
> > + return ret;
> > +
> > + st->chan[chan->channel].powerdown = powerdown;
> > +
> > + return len;
> > +}
>
> ...
>
> > + .num_banks = ARRAY_SIZE(ad3532r_if_config),
>
> Also check if array_size.h is included.
>
> --
> With Best Regards,
> Andy Shevchenko
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-25 10:07 UTC (permalink / raw)
To: konrad.dybcio
Cc: andersson, devicetree, konradybcio, linux-arm-msm, linux-kernel,
xxsemail
In-Reply-To: <891015c8-68df-4654-b1e7-94d73e74267c@oss.qualcomm.com>
On Wed, 2026-06-24 at 13:00 +0200, Konrad Dybcio wrote:
> On 6/22/26 8:07 PM, Xin Xu wrote:
> > On Mon, 2026-06-22 at 13:40 +0200, Konrad Dybcio wrote:
> > > On 6/19/26 6:07 PM, Xin Xu wrote:
> > > > Add the pm8008 PMIC node on i2c15 with seven LDOs,
> > > > using GPIO84 as interrupt and GPIO76 as reset.
> > > >
> > > > Signed-off-by: Xin Xu <xxsemail@qq.com>
> > > > ---
>
> [...]
>
> > > > + pm8008_default: pm8008-default-state {
> > > > + int-pins {
> > > > + pins = "gpio84";
> > > > + function = "gpio";
> > > > + bias-disable;
> > > > + drive-strength = <2>;
> > > > + input-enable;
> > > > + };
> > > > +
> > > > + reset-pins {
> > > > + pins = "gpio76";
> > > > + function = "gpio";
> > > > + bias-pull-up;
> > > > + drive-strength = <2>;
> > > > + output-high;
> > >
> > > Drop output-high, the driver will take care of setting the output
> > > state
> > >
> > > Konrad
> >
> > Thank you for your review!
> >
> > I will fix the coding style issues (blank line before status,
> > interrupts-extended, property order, and dropping output-high)
> > in the next version.
> >
> > I have verified all LDO voltages against the downstream device
> > tree:
> > https://github.com/MiCode/kernel_devicetree/tree/elish-r-oss/
> > The definitions can be found around lines 209–244 in
> > qcom/elish-sm8250-camera-board.dtsi
>
> Thanks. It's best if you grab the DTB from a running device (which
> has all the overlays applied etc.), which you can grab from
> /sys/firmware/fdt
>
> You can then pass that to DTC directly
>
> Konrad
For additional verification, I have extracted the device tree from
/sys/firmware/fdt on a running device. The voltage values match the
ones in my patch exactly. Below is the relevant pm8008 regulator
portion:
qcom,pm8008-regulator {
compatible = "qcom,pm8008-regulator";
pm8008_en-supply = <0x708>;
qcom,enable-ocp-broadcast;
vdd_l1_l2-supply = <0xad>;
vdd_l3_l4-supply = <0x2cf>;
phandle = <0x7e6>;
qcom,pm8008-l1@4000 {
reg = <0x4000>;
regulator-name = "pm8008_l1";
regulator-min-microvolt = <0x124f80>; /* 1200000 */
regulator-max-microvolt = <0x124f80>; /* 1200000 */
qcom,min-dropout-voltage = <0x186a0>; /* 100000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x71c>;
};
qcom,pm8008-l2@4100 {
reg = <0x4100>;
regulator-name = "pm8008_l2";
regulator-min-microvolt = <0x124f80>; /* 1200000 */
regulator-max-microvolt = <0x124f80>; /* 1200000 */
qcom,min-dropout-voltage = <0x186a0>; /* 100000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x713>;
};
qcom,pm8008-l3@4200 {
reg = <0x4200>;
regulator-name = "pm8008_l3";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2ab980>; /* 2800000 */
qcom,min-dropout-voltage = <0x30d40>; /* 200000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x714>;
};
qcom,pm8008-l4@4300 {
reg = <0x4300>;
regulator-name = "pm8008_l4";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2ab980>; /* 2800000 */
qcom,min-dropout-voltage = <0x30d40>; /* 200000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x70e>;
};
qcom,pm8008-l5@4400 {
reg = <0x4400>;
regulator-name = "pm8008_l5";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2ab980>; /* 2800000 */
qcom,min-dropout-voltage = <0x493e0>; /* 300000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x71b>;
};
qcom,pm8008-l6@4400 {
reg = <0x4500>;
regulator-name = "pm8008_l6";
regulator-min-microvolt = <0x1b7740>; /* 1800000 */
regulator-max-microvolt = <0x1b7740>; /* 1800000 */
qcom,min-dropout-voltage = <0x493e0>; /* 300000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x7e7>;
};
qcom,pm8008-l7@4400 {
reg = <0x4600>;
regulator-name = "pm8008_l7";
regulator-min-microvolt = <0x2ab980>; /* 2800000 */
regulator-max-microvolt = <0x2c4020>; /* 2900000 */
qcom,min-dropout-voltage = <0x493e0>; /* 300000 */
qcom,hpm-min-load = <0x00>;
phandle = <0x712>;
};
};
^ permalink raw reply
* RE: [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Paller, Kim Seer @ 2026-06-25 10:07 UTC (permalink / raw)
To: Jonathan Cameron, Andy Shevchenko
Cc: David Lechner, Sa, Nuno, Andy Shevchenko, Hennerich, Michael,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux,
devicetree@vger.kernel.org
In-Reply-To: <20260621174548.5eca5db6@jic23-huawei>
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Monday, June 22, 2026 12:46 AM
> To: Andy Shevchenko <andriy.shevchenko@intel.com>
> Cc: Paller, Kim Seer <KimSeer.Paller@analog.com>; David Lechner
> <dlechner@baylibre.com>; Sa, Nuno <Nuno.Sa@analog.com>; Andy
> Shevchenko <andy@kernel.org>; Hennerich, Michael
> <Michael.Hennerich@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org; linux
> <linux@analog.com>; devicetree@vger.kernel.org
> Subject: Re: [PATCH v2 4/4] iio: dac: ad3530r: Add support for
> AD3532R/AD3532
>
> [External]
>
> On Mon, 15 Jun 2026 13:05:44 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Mon, Jun 15, 2026 at 02:20:18PM +0800, Kim Seer Paller wrote:
> > > The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
> > > dual-bank register architecture (bank 0 at 0x1000 for channels 0-7,
> > > bank 1 at 0x3000 for channels 8-15). It shares similar functionality
> > > with AD3530R (channel configuration, LDAC triggering, powerdown
> > > control), the main difference being the register address map due to
> > > the dual-bank architecture, handled by table-driven helpers.
> > >
> > > Add AD3532R-specific register definitions, channel specs, per-bank
> > > register arrays, a dedicated ad3532r_set_dac_powerdown(), and
> > > per-chip regmap_config to limit debugfs-exposed register space to
> > > each variant's actual address range.
> >
> > ...
> >
> >
> > > help
> > > - Say yes here to build support for Analog Devices AD3530R, AD3531R
> > > - Digital to Analog Converter.
> > > + Say yes here to build support for Analog Devices AD3530/AD3530R,
> > > + AD3531/AD3531R, and AD3532/AD3532R Digital to Analog
> Converters.
> >
> > This just shows how unscalable the above text is. That's why we
> > usually recommend to make the list explicit and separated.
> >
> > Say yes here to build support for the following Analog Devices
> > Digital to Analog Converters:
> > - AD3530/AD3530R (8-channel)
> > - AD3531/AD3531R (4-channel)
> > - AD3532/AD3532R (16-channel)
> >
> > (and looking into the C-file change, perhaps add here as well
> > distinctive information, such as number of channels, in the parentheses).
> >
> > > To compile this driver as a module, choose M here: the
> > > module will be called ad3530r.
> >
> > ...
> >
> > > +#define AD3532R_INTERFACE_CONFIG_A_0 0x1000
> > > +#define AD3532R_INTERFACE_CONFIG_A_1 0x3000
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_0 0x1020
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_1 0x1021
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_2 0x3020
> > > +#define AD3532R_OUTPUT_OPERATING_MODE_3 0x3021
> > > +#define AD3532R_OUTPUT_CONTROL_0 0x102A
> > > +#define AD3532R_OUTPUT_CONTROL_1 0x302A
> > > +#define AD3532R_REFERENCE_CONTROL_0 0x103C
> > > +#define AD3532R_REFERENCE_CONTROL_1 0x303C
> > > +#define AD3532R_SW_LDAC_TRIG_0 0x10E5
> > > +#define AD3532R_SW_LDAC_TRIG_1 0x30E5
> > > +#define AD3532R_INPUT_CH_0 0x10EB
> > > +#define AD3532R_INPUT_CH_1 0x30EB
> > > +#define AD3532R_MAX_REG_ADDR 0x30F9
> Whilst we are here, Sashiko thinks there is an off by one on that value as it's
> the lower of the two registers that make up channel 15.
> https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260615-iio-
> ad3532r-support-v2-0-
> 84a0af8b83fa*40analog.com__;IyU!!A3Ni8CS0y2Y!88afCOStwucx32wuoeR
> SyZ9GpkZge9YDw5_PIMAf7SLs3OLykUC_qNRDUCnRw7wTwsxiIT1V-
> R8sH17sTg$
> It also suggests an existing bug that it would be good to look into.
I don't think it's off-by-one. INPUT_CHn registers are listed by LSB, so channel 15 is 0x30F8 (LSB) / 0x30F9 (MSB).
The driver addresses the MSB and the part defaults to descending mode, so the access goes 0x30F9 -> 0x30F8.
0x30F9 is also the highest valid address per the datasheet, so max_register looks correct same for AD3530R's 0xF9.
Does that match our understanding, or am I missing a case?
>
> >
> > Hmm... I dunno if it's better to sort by values (so the "bank" 0 goes
> > together followed by "bank" 1). Jonathan, what's your preference here?
> Nuno, David?
> That is how people will typically check them vs the datasheet so I agree with
> numeric order. Maybe with a comment at the top about there effectively
> being two banks. Many of the registers are effectively copies for the new
> channels but not all of them, so a macro approach would probably be even
> more confusing.
>
> Jonathan
^ permalink raw reply
* Re: [PATCH v5 5/7] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: sashiko-bot @ 2026-06-25 10:10 UTC (permalink / raw)
To: Joey Lu; +Cc: conor+dt, devicetree, robh, dri-devel
In-Reply-To: <20260625094449.708386-6-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] The DC8000 panel enable, CRTC begin, and CRTC flush operations use incorrect registers and bits, directly contradicting the commit message and breaking hardware functionality.
- [Medium] The hw_irqs variable is passed to regmap_read() uninitialized and used without checking for read failures.
Pre-existing issues:
- [High] The DC8200 primary plane disable function erroneously sets the enable bit instead of clearing it, keeping the plane active.
- [High] The IRQ handler unconditionally dereferences dc->drm_dev, but the interrupt is enabled before dc->drm_dev is allocated and remains active after it is freed.
--
commit a518460571afb18a0b4ff8e14af894a66907ebde
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: add DC8000 (DCUltraLite) display controller support
The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
controller (DC8000 generation) whose register layout differs from
the DC8200 in several important ways:
> 1. No CONFIG_EX commit path: framebuffer updates use the enable (bit 0)
> and reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
> registers (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT,
> FB_BLEND_CONFIG, PANEL_CONFIG_EX).
>
> 2. No PANEL_START register: panel output starts when
> PANEL_CONFIG.RUNNING is set; there is no multi-display sync start
> register.
[Severity: High]
Do the functions implemented in this patch use the correct registers and bits
as described in the commit message?
In vs_dc8000_panel_enable_ex(), the code sets a reset bit
(VSDC_FB_CONFIG_RESET) in VSDC_FB_CONFIG instead of writing to PANEL_CONFIG.
Additionally, vs_dc8000_crtc_begin() and vs_dc8000_crtc_flush() use an
unmentioned VALID bit (VSDC_FB_CONFIG_VALID), and clear it after updates
complete, which seems to invert normal latch semantics.
Could this mismatch prevent the display panel from enabling properly?
> 3. Different IRQ registers: DCUltraLite uses DISP_IRQ_STA (0x147C) /
> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
> TOP_IRQ_EN (0x0014).
>
> 4. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
> divider) clocks; no axi or ahb clocks required.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> diff --git a/drivers/gpu/drm/verisilicon/Makefile b/drivers/gpu/drm/verisilicon/Makefile
> index 9d4cd16452fa1..d2fd8e4dff242 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o vs_drm.o vs_hwdb.o \
> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o vs_dc8000.o vs_drm.o vs_hwdb.o \
[Severity: High]
This is a pre-existing issue, but while reviewing the driver files included
here, I noticed a potential problem in
vs_dc8200.c:vs_dc8200_primary_plane_disable_ex().
The function appears to call regmap_set_bits() on VSDC_FB_CONFIG_EX_FB_EN
instead of regmap_clear_bits():
vs_dc8200.c:vs_dc8200_primary_plane_disable_ex() {
...
regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
VSDC_FB_CONFIG_EX_FB_EN);
...
}
Does this erroneously keep the primary plane active when the DRM framework
expects it to be turned off, potentially breaking power management?
> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>
> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
[ ... ]
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c b/drivers/gpu/drm/verisilicon/vs_dc.c
> index fd1f5fe67a68b..9499fffbca58e 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device *pdev)
> dev_info(dev, "Found DC%x rev %x customer %x\n", dc->identity.model,
> dc->identity.revision, dc->identity.customer_id);
>
> - dc->funcs = &vs_dc8200_funcs;
> + if (dc->identity.generation == VSDC_GEN_DC8200)
> + dc->funcs = &vs_dc8200_funcs;
> + else
> + dc->funcs = &vs_dc8000_funcs;
[Severity: High]
This is a pre-existing issue, but I noticed a potential lifecycle regression
in vs_dc_probe() just below this block.
The function calls devm_request_irq() to register vs_dc_irq_handler() before
calling vs_drm_initialize(), which is responsible for allocating and assigning
dc->drm_dev.
If an interrupt fires during this window, for example if the bootloader left
VSYNC interrupts enabled, the handler is invoked:
vs_drm.c:vs_drm_handle_irq() {
...
if (dc->drm_dev->crtcs[i])
drm_crtc_handle_vblank(&dc->drm_dev->crtcs[i]->base);
...
}
Will this unconditionally dereference dc->drm_dev and cause a NULL pointer
dereference before vs_drm_initialize() has completed?
>
> if (port_count > dc->identity.display_count) {
> dev_err(dev, "too many downstream ports than HW capability\n");
[ ... ]
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8000.c b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> new file mode 100644
> index 0000000000000..fbe0fa516cac9
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
> @@ -0,0 +1,86 @@
[ ... ]
> +static u32 vs_dc8000_irq_ack(struct vs_dc *dc)
> +{
> + u32 hw_irqs, unified = 0;
> + unsigned int i;
> +
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &hw_irqs);
[Severity: Medium]
Is it safe to use hw_irqs here if regmap_read() fails?
If regmap_read() returns an error code, hw_irqs will remain uninitialized
stack memory.
The function then proceeds to bitwise-AND this uninitialized value to
determine which VSYNC interrupts fired:
for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
if (hw_irqs & VSDC_DISP_IRQ_VSYNC(i))
unified |= VSDC_IRQ_VSYNC(i);
}
Could this result in spurious VSYNC events being dispatched to the DRM core if
a read failure occurs?
> +
> + for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
> + if (hw_irqs & VSDC_DISP_IRQ_VSYNC(i))
> + unified |= VSDC_IRQ_VSYNC(i);
> + }
> +
> + return unified;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-ab2: Enable MU2 for DSP communication
From: Daniel Baluta @ 2026-06-25 10:13 UTC (permalink / raw)
To: shengjiu.wang, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260625054709.301209-1-shengjiu.wang@oss.nxp.com>
On 6/25/26 08:47, shengjiu.wang@oss.nxp.com wrote:
> [You don't often get email from shengjiu.wang@oss.nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: Shengjiu Wang <shengjiu.wang@nxp.com>
>
> Enable the MU2 (Message Unit 2) node on the i.MX8MP Audio Board v2.
> MU2 is required for inter-processor communication between the
> application CPU and the HiFi4 DSP, allowing DSP firmware to exchange
> control and status messages with the Linux host.
>
> Without this change, the DSP driver cannot establish the message
> channel and DSP audio processing is non-functional.
>
> Fixes: bf68c18150efc ("arm64: dts: imx8mp-ab2: add support for NXP i.MX8MP audio board (version 2)")
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Add PCIe PHY and controller nodes
From: Abel Vesa @ 2026-06-25 10:12 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260610-eliza_dt-v1-1-7bb72b75fc5b@oss.qualcomm.com>
On 26-06-10 17:40:09, Krishna Chaitanya Chundru wrote:
> Eliza supports two PCIe instances: one 8GT/s x1 (PCIe0) and one 8GT/s x2
> (PCIe1). Add PCIe controller and PHY nodes for both instances, and update
> the GCC clock references to use the newly added PHY nodes instead of
> placeholder zeros.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> This patch depends on https://lore.kernel.org/all/20260608-eliza-v3-0-9bdeb7434b28@oss.qualcomm.com/
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 359 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 357 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> index 7e97361a5dc5..2a51da62270d 100644
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
> @@ -610,8 +610,8 @@ gcc: clock-controller@100000 {
>
> clocks = <&bi_tcxo_div2>,
> <&sleep_clk>,
> - <0>,
> - <0>,
> + <&pcie0_phy>,
> + <&pcie1_phy>,
> <&ufs_mem_phy 0>,
> <&ufs_mem_phy 1>,
> <&ufs_mem_phy 2>,
> @@ -716,6 +716,361 @@ mmss_noc: interconnect@1780000 {
> #interconnect-cells = <2>;
> };
>
> + pcie0: pcie@1c00000 {
> + device_type = "pci";
> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
> + reg = <0 0x01c00000 0 0x3000>,
> + <0 0x40000000 0 0xf1d>,
> + <0 0x40000f20 0 0xa8>,
> + <0 0x40001000 0 0x1000>,
> + <0 0x40100000 0 0x100000>,
> + <0 0x01c03000 0 0x1000>;
> + reg-names = "parf",
> + "dbi",
> + "elbi",
> + "atu",
> + "config",
> + "mhi";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0 0x00000000 0 0x40200000 0 0x100000>,
> + <0x02000000 0 0x40300000 0 0x40300000 0 0x3d00000>;
> +
> + interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 653 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "msi0",
> + "msi1",
> + "msi2",
> + "msi3",
> + "msi4",
> + "msi5",
> + "msi6",
> + "msi7",
> + "global";
> +
> + clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
> + <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
> + <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> + clock-names = "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave",
> + "slave_q2a",
> + "ddrss_sf_tbu",
> + "noc_aggr",
> + "cnoc_sf_axi";
> +
> + resets = <&gcc GCC_PCIE_0_BCR>,
> + <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
> + reset-names = "pci",
> + "link_down";
> +
> + interconnects = <&pcie_noc MASTER_PCIE_0 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_main SLAVE_PCIE_0 QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "pcie-mem",
> + "cpu-pcie";
> +
> + power-domains = <&gcc GCC_PCIE_0_GDSC>;
> +
> + operating-points-v2 = <&pcie0_opp_table>;
> +
> + iommu-map = <0 &apps_smmu 0x1480 0x1>,
> + <0x100 &apps_smmu 0x1481 0x1>;
> +
> + interrupt-map = <0 0 0 1 &intc 0 0 0 564 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 0 565 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 0 566 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 0 567 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + #interrupt-cells = <1>;
> +
> + linux,pci-domain = <0>;
> + num-lanes = <1>;
> + bus-range = <0 0xff>;
> +
> + dma-coherent;
> +
No pinctrl states?
> +
> + pcie1: pcie@1c08000 {
> + device_type = "pci";
> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
> + reg = <0 0x01c08000 0 0x3000>,
> + <0 0x44000000 0 0xf1d>,
> + <0 0x44000f20 0 0xa8>,
> + <0 0x44001000 0 0x1000>,
> + <0 0x44100000 0 0x100000>,
> + <0 0x01c0b000 0 0x1000>;
> + reg-names = "parf",
> + "dbi",
> + "elbi",
> + "atu",
> + "config",
> + "mhi";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0 0x00000000 0 0x44200000 0 0x100000>,
> + <0x02000000 0 0x44300000 0 0x44300000 0 0x3d00000>;
> +
> + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "msi0",
> + "msi1",
> + "msi2",
> + "msi3",
> + "msi4",
> + "msi5",
> + "msi6",
> + "msi7",
> + "global";
> +
> + clocks = <&gcc GCC_PCIE_1_AUX_CLK>,
> + <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
> + <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
> + <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>,
> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> + clock-names = "aux",
> + "cfg",
> + "bus_master",
> + "bus_slave",
> + "slave_q2a",
> + "ddrss_sf_tbu",
> + "noc_aggr",
> + "cnoc_sf_axi";
> +
> + resets = <&gcc GCC_PCIE_1_BCR>,
> + <&gcc GCC_PCIE_1_LINK_DOWN_BCR>;
> + reset-names = "pci",
> + "link_down";
> +
> + interconnects = <&pcie_noc MASTER_PCIE_1 QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_main SLAVE_PCIE_1 QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "pcie-mem",
> + "cpu-pcie";
> +
> + power-domains = <&gcc GCC_PCIE_1_GDSC>;
> +
> + operating-points-v2 = <&pcie1_opp_table>;
> +
> + iommu-map = <0 &apps_smmu 0x1400 0x1>,
> + <0x100 &apps_smmu 0x1401 0x1>;
> +
> + interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + #interrupt-cells = <1>;
> +
> + linux,pci-domain = <1>;
> + num-lanes = <2>;
> + bus-range = <0 0xff>;
> +
> + dma-coherent;
No pinctrl states?
^ permalink raw reply
* Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
From: Konrad Dybcio @ 2026-06-25 10:18 UTC (permalink / raw)
To: Hans de Goede, Rafael J . Wysocki, Bjorn Andersson, Konrad Dybcio
Cc: Srinivas Kandagatla, Krzysztof Kozlowski, Dmitry Baryshkov,
Bartosz Golaszewski, Abel Vesa, linux-arm-msm, devicetree,
linux-acpi
In-Reply-To: <20260623145225.143218-1-johannes.goede@oss.qualcomm.com>
On 6/23/26 4:52 PM, Hans de Goede wrote:
> Hi All,
>
> Currently as soon as the kernel boots with a populated DT provided then
> the arch/arm64 code sets acpi_disabled=1 and the complete ACPI subsystem
> gets disabled. On WoA Snapdragon laptops where the factory Windows OS
> actually boots using these tables this is not necessarily desirable.
>
> It might still be interesting to at least parse the ACPI tables and make
> the ACPI fwnodes available for device-drivers to use. I call this DT-ACPI
> hybrid mode.
>
> This mainly is an experiment for now and possibly a method for accelerating
> the ongoing effort to run Linux on currently available Snapdragon laptops.
I like the part where the ACPI tables are parsed and are visible to
Linux (so that the user can e.g. do acpidump even though DT is in use,
since the tables are in memory anyway)
I think the 'hybrid enumeration path' is a cool technical experiment,
which lets the user skip _some parts_ of writing a device tree, but
the benefits are too minor - we can only make use of this for devices
that already have ACPI support in Linux and whose nodes fit within the
"describe the actual hw and how it's wired up, not the functions it
exposes" model (because on Windows that all ends up being hijacked by
the PEP driver or something similar in the chain).
This is natural for DT, but not so much for ACPI
The hid-over-i2c example you gave looks useful on the surface, but
if the user already has to have the knowledge and skills to grab and
decompile the tables, assess the right path for the device and still
have to put it in the DT (which again, they would have had to create
at this point) after all, they may as well take the 40 extra seconds
as a single-time cost to fill in the i2c address and interrupt source
to create a valid/full DT node.
The path lookup mechanisms relies on the paths remaining stable,
which I would assume should be the case, but I wouldn't bet money
on it _always_ being the case.
To put it simply, I don't think we should spend time on trying to
forcefully make the incomplete (actually incomplete, since Windows
today loads ACPI fragments sourced from Windows Update at runtime
and relies on many drivers having hardcoded data) DSDTs be any
useful, because in their current form, we would need to rely on
quasi-boardfiles for most things anyway.
If we need to provide the firmware description (DT) externally
anyway, let's just stick to that alone.
Konrad
^ permalink raw reply
* Re: [PATCH v5 6/7] drm/verisilicon: add DCUltraLite chip identity to HWDB
From: sashiko-bot @ 2026-06-25 10:22 UTC (permalink / raw)
To: Joey Lu; +Cc: conor+dt, robh, devicetree, dri-devel
In-Reply-To: <20260625094449.708386-7-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly added DCUltraLite chip restricts the max cursor size to 32x32, but the driver does not configure `drm->mode_config.cursor_width` or `cursor_height`. DRM core defaults to 64x64 when these fields are 0. This incorrectly exposes a `DRM_CAP_CURSOR_WIDTH` of 64 to userspace, causing atomic commits with 64x64 hardware cursors to be rejected with `-EINVAL`, breaking display compositors.
--
commit a3c0d8a714c977c54ec25009535f44e9ded7c881
Author: Joey Lu <a0987203069@gmail.com>
drm/verisilicon: add DCUltraLite chip identity to HWDB
The Nuvoton MA35D1 chip contains a DCUltraLite display controller with
model number 0x0 (sic, the model name contains no number either),
revision 0x5560 and customer ID 0x305. It has a similar register map
with DC8000, only one display output and only 32x32 cursor supported.
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> index 91524d16f7785..7d630a667a3f0 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> @@ -129,6 +129,16 @@ static struct vs_chip_identity vs_chip_identities[] = {
> .max_cursor_size = 64,
> .formats = &vs_formats_no_yuv444,
> },
> + {
> + .model = 0x0, /* DCUltraLite */
> + .revision = 0x5560,
> + .customer_id = 0x305,
> +
> + .generation = VSDC_GEN_DC8000,
> + .display_count = 1,
> + .max_cursor_size = 32,
[Severity: High]
Does this code expose an incorrect DRM_CAP_CURSOR_WIDTH to userspace?
Looking at vs_mode_config_init() in drivers/gpu/drm/verisilicon/vs_drm.c,
the driver does not seem to configure drm->mode_config.cursor_width or
cursor_height:
drivers/gpu/drm/verisilicon/vs_drm.c:vs_mode_config_init() {
...
drm->mode_config.helper_private = &vs_mode_config_helper_funcs;
}
When these fields are 0, the DRM core defaults to 64x64. This means userspace
compositors might query the capability, receive 64x64, and attempt to commit
a 64x64 hardware cursor.
If this new chip restricts the max cursor size to 32x32, will the driver's
atomic check reject the 64x64 state and break display compositors?
> + .formats = &vs_formats_no_yuv444,
> + },
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625094449.708386-1-a0987203069@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v9 04/12] reset: realtek: Add RTD1625-ISO reset controller driver
From: Philipp Zabel @ 2026-06-25 10:22 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], mturquette@baylibre.com,
sboyd@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Edgar Lee [李承諭],
afaerber@suse.com, Jyan Chou [周芷安],
bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <f3b747e20110424c8a434cbd271edb87@realtek.com>
On Do, 2026-06-25 at 10:05 +0000, Yu-Chun Lin [林祐君] wrote:
> Hi Philipp,
>
> > On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > > From: Cheng-Yu Lee <cylee12@realtek.com>
> > >
> > > Add support for the ISO (Isolation) domain reset controller on the
> > > Realtek
> > > RTD1625 SoC.
> > >
> > > The reset controller shares the same register space with the ISO clock
> > > controller. To handle this shared register space, the reset driver is
> > > implemented as an auxiliary driver. It will be instantiated and probed
> > > via the auxiliary bus by the RTD1625-ISO clock controller driver.
> > >
> > > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > > ---
> > > Changes in v9:
> > > - Extract reset-related code from the previous clock driver patch
> > > (formerly patch 9 in v8).
> > > ---
> > > drivers/reset/realtek/Makefile | 2 +-
> > > drivers/reset/realtek/reset-rtd1625-iso.c | 99
> > > +++++++++++++++++++++++
> > > 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644
> > > drivers/reset/realtek/reset-rtd1625-iso.c
> > >
> > > diff --git a/drivers/reset/realtek/Makefile
> > > b/drivers/reset/realtek/Makefile index c3f605ffb11c..9007c9d5683b
> > > 100644
> > > --- a/drivers/reset/realtek/Makefile
> > > +++ b/drivers/reset/realtek/Makefile
> > > @@ -1,3 +1,3 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > obj-$(CONFIG_RESET_RTK_COMMON) += reset-rtk-common.o
> > > -obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > > +obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > > +reset-rtd1625-iso.o
> >
> > Is there any benefit to these two being separate modules?
> > I suggest you merge them into one: reset-rtd1625.o
> >
>
> If I merge them into a single 'reset-rtd1625' module,
> both the 'crt' and 'iso' clock drivers would trigger the probe
> process for the same reset driver name, which would lead to a
> duplicate driver registration error.
What do you mean by duplicate driver registration error?
There would only be one auxiliary_driver, with support for all three
auxiliary_device_id's.
regards
Philipp
^ permalink raw reply
* [PATCH] dt-bindings: arm: qcom: sort compatibles alphabetically by base SoC
From: Kathiravan Thirumoorthy @ 2026-06-25 10:32 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio,
Kathiravan Thirumoorthy
The compatible entries in qcom.yaml were not in alphabetical order by
their base SoC compatible string (the last const: qcom,* in each block),
making the file harder to audit and maintain. Sort the entries for
better maintenance.
No functional change; reordering only.
Assisted-by: Claude:claude-sonnet-4-6
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 490 ++++++++++++------------
1 file changed, 245 insertions(+), 245 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..dfbc82377fcf 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -49,18 +49,31 @@ properties:
- qcom,apq8074-dragonboard
- const: qcom,apq8074
- - items:
- - enum:
- - qcom,apq8060-dragonboard
- - qcom,msm8660-surf
- - const: qcom,msm8660
-
- items:
- enum:
- qcom,apq8084-mtp
- qcom,apq8084-sbc
- const: qcom,apq8084
+ - items:
+ - enum:
+ - sony,karin_windy
+ - const: qcom,apq8094
+
+ - items:
+ - enum:
+ - arrow,apq8096-db820c
+ - inforce,ifc6640
+ - const: qcom,apq8096-sbc
+ - const: qcom,apq8096
+
+ - items:
+ - const: arrow,apq8096sg-db820c
+ - const: arrow,apq8096-db820c
+ - const: qcom,apq8096-sbc
+ - const: qcom,apq8096sg
+ - const: qcom,apq8096
+
- items:
- enum:
- qcom,eliza-mtp
@@ -73,102 +86,126 @@ properties:
- items:
- enum:
- - qcom,mahua-crd
- - const: qcom,mahua
+ - 8dev,jalapeno
+ - alfa-network,ap120c-ac
+ - const: qcom,ipq4018
- items:
- enum:
- - fairphone,fp6
- - nothing,asteroids
- - const: qcom,milos
+ - qcom,ipq4019-ap-dk01.1-c1
+ - qcom,ipq4019-ap-dk04.1-c3
+ - qcom,ipq4019-ap-dk07.1-c1
+ - qcom,ipq4019-ap-dk07.1-c2
+ - qcom,ipq4019-dk04.1-c1
+ - const: qcom,ipq4019
- items:
- enum:
- - microsoft,dempsey
- - microsoft,makepeace
- - microsoft,moneypenny
- - motorola,falcon
- - samsung,ms013g
- - samsung,s3ve3g
- - const: qcom,msm8226
+ - qcom,ipq5018-rdp432-c2
+ - tplink,archer-ax55-v1
+ - const: qcom,ipq5018
- items:
- enum:
- - htc,memul
- - microsoft,superman-lte
- - microsoft,tesla
- - motorola,peregrine
- - samsung,matisselte
- - const: qcom,msm8926
- - const: qcom,msm8226
+ - qcom,ipq5210-rdp504
+ - const: qcom,ipq5210
- items:
- enum:
- - wingtech,wt82918hd
- - const: qcom,msm8929
+ - qcom,ipq5332-ap-mi01.2
+ - qcom,ipq5332-ap-mi01.3
+ - qcom,ipq5332-ap-mi01.6
+ - qcom,ipq5332-ap-mi01.9
+ - const: qcom,ipq5332
- items:
- enum:
- - asus,z00t
- - huawei,kiwi
- - longcheer,l9100
- - samsung,a7
- - sony,kanuti-tulip
- - square,apq8039-t2
- - wingtech,wt82918
- - wingtech,wt82918hdhw39
- - const: qcom,msm8939
+ - qcom,ipq5424-rdp466
+ - const: qcom,ipq5424
- items:
- enum:
- - sony,kugo-row
- - sony,suzu-row
- - const: qcom,msm8956
+ - qcom,ipq6018-cp01
+ - qcom,ipq6018-cp01-c1
+ - const: qcom,ipq6018
- items:
- enum:
- - qcom,msm8960-cdp
- - samsung,expressatt
- - const: qcom,msm8960
+ - mikrotik,rb3011
+ - qcom,ipq8064-ap148
+ - const: qcom,ipq8064
- items:
- enum:
- - sony,huashan
- - const: qcom,msm8960t
- - const: qcom,msm8960
+ - qcom,ipq8074-hk01
+ - qcom,ipq8074-hk10-c1
+ - qcom,ipq8074-hk10-c2
+ - const: qcom,ipq8074
- items:
- enum:
- - lge,hammerhead
- - samsung,hlte
- - sony,xperia-amami
- - sony,xperia-honami
- - sony,xperia-togari
- - const: qcom,msm8974
+ - qcom,ipq9574-ap-al02-c2
+ - qcom,ipq9574-ap-al02-c2-emmc
+ - qcom,ipq9574-ap-al02-c6
+ - qcom,ipq9574-ap-al02-c7
+ - qcom,ipq9574-ap-al02-c7-emmc
+ - qcom,ipq9574-ap-al02-c8
+ - qcom,ipq9574-ap-al02-c9
+ - const: qcom,ipq9574
- items:
- enum:
- - fairphone,fp2
- - htc,m8
- - oneplus,bacon
- - samsung,klte
- - sony,xperia-aries
- - sony,xperia-castor
- - sony,xperia-leo
- - const: qcom,msm8974pro
- - const: qcom,msm8974
+ - qcom,ipq9650-rdp488
+ - const: qcom,ipq9650
- items:
- enum:
- - samsung,kltechn
- - const: samsung,klte
- - const: qcom,msm8974pro
- - const: qcom,msm8974
+ - qcom,kaanapali-mtp
+ - qcom,kaanapali-qrd
+ - const: qcom,kaanapali
- items:
- enum:
- - longcheer,l9360
- - const: qcom,msm8976
+ - qcom,mahua-crd
+ - const: qcom,mahua
+
+ - description: Sierra Wireless MangOH Green with WP8548 Module
+ items:
+ - const: swir,mangoh-green-wp8548
+ - const: swir,wp8548
+ - const: qcom,mdm9615
+
+ - items:
+ - enum:
+ - fairphone,fp6
+ - nothing,asteroids
+ - const: qcom,milos
+
+ - items:
+ - enum:
+ - microsoft,dempsey
+ - microsoft,makepeace
+ - microsoft,moneypenny
+ - motorola,falcon
+ - samsung,ms013g
+ - samsung,s3ve3g
+ - const: qcom,msm8226
+
+ - items:
+ - enum:
+ - htc,memul
+ - microsoft,superman-lte
+ - microsoft,tesla
+ - motorola,peregrine
+ - samsung,matisselte
+ - const: qcom,msm8926
+ - const: qcom,msm8226
+
+ - items:
+ - enum:
+ - qcom,apq8060-dragonboard
+ - qcom,msm8660-surf
+ - const: qcom,msm8660
- items:
- enum:
@@ -217,11 +254,28 @@ properties:
- xiaomi,tiare
- const: qcom,msm8917
+ - items:
+ - enum:
+ - wingtech,wt82918hd
+ - const: qcom,msm8929
+
- items:
- enum:
- xiaomi,land
- const: qcom,msm8937
+ - items:
+ - enum:
+ - asus,z00t
+ - huawei,kiwi
+ - longcheer,l9100
+ - samsung,a7
+ - sony,kanuti-tulip
+ - square,apq8039-t2
+ - wingtech,wt82918
+ - wingtech,wt82918hdhw39
+ - const: qcom,msm8939
+
- items:
- enum:
- flipkart,rimob
@@ -232,6 +286,57 @@ properties:
- xiaomi,vince
- const: qcom,msm8953
+ - items:
+ - enum:
+ - sony,kugo-row
+ - sony,suzu-row
+ - const: qcom,msm8956
+
+ - items:
+ - enum:
+ - qcom,msm8960-cdp
+ - samsung,expressatt
+ - const: qcom,msm8960
+
+ - items:
+ - enum:
+ - sony,huashan
+ - const: qcom,msm8960t
+ - const: qcom,msm8960
+
+ - items:
+ - enum:
+ - lge,hammerhead
+ - samsung,hlte
+ - sony,xperia-amami
+ - sony,xperia-honami
+ - sony,xperia-togari
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - fairphone,fp2
+ - htc,m8
+ - oneplus,bacon
+ - samsung,klte
+ - sony,xperia-aries
+ - sony,xperia-castor
+ - sony,xperia-leo
+ - const: qcom,msm8974pro
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - samsung,kltechn
+ - const: samsung,klte
+ - const: qcom,msm8974pro
+ - const: qcom,msm8974
+
+ - items:
+ - enum:
+ - longcheer,l9360
+ - const: qcom,msm8976
+
- items:
- enum:
- lg,bullhead
@@ -240,11 +345,6 @@ properties:
- xiaomi,libra
- const: qcom,msm8992
- - items:
- - enum:
- - sony,karin_windy
- - const: qcom,apq8094
-
- items:
- enum:
- huawei,angler
@@ -256,20 +356,6 @@ properties:
- sony,suzuran-row
- const: qcom,msm8994
- - items:
- - enum:
- - arrow,apq8096-db820c
- - inforce,ifc6640
- - const: qcom,apq8096-sbc
- - const: qcom,apq8096
-
- - items:
- - const: arrow,apq8096sg-db820c
- - const: arrow,apq8096-db820c
- - const: qcom,apq8096-sbc
- - const: qcom,apq8096sg
- - const: qcom,apq8096
-
- items:
- enum:
- oneplus,oneplus3
@@ -303,86 +389,6 @@ properties:
- xiaomi,sagit
- const: qcom,msm8998
- - items:
- - enum:
- - 8dev,jalapeno
- - alfa-network,ap120c-ac
- - const: qcom,ipq4018
-
- - items:
- - enum:
- - qcom,ipq4019-ap-dk01.1-c1
- - qcom,ipq4019-ap-dk04.1-c3
- - qcom,ipq4019-ap-dk07.1-c1
- - qcom,ipq4019-ap-dk07.1-c2
- - qcom,ipq4019-dk04.1-c1
- - const: qcom,ipq4019
-
- - items:
- - enum:
- - qcom,ipq5018-rdp432-c2
- - tplink,archer-ax55-v1
- - const: qcom,ipq5018
-
- - items:
- - enum:
- - qcom,ipq5210-rdp504
- - const: qcom,ipq5210
-
- - items:
- - enum:
- - qcom,ipq5332-ap-mi01.2
- - qcom,ipq5332-ap-mi01.3
- - qcom,ipq5332-ap-mi01.6
- - qcom,ipq5332-ap-mi01.9
- - const: qcom,ipq5332
-
- - items:
- - enum:
- - qcom,ipq5424-rdp466
- - const: qcom,ipq5424
-
- - items:
- - enum:
- - mikrotik,rb3011
- - qcom,ipq8064-ap148
- - const: qcom,ipq8064
-
- - items:
- - enum:
- - qcom,ipq8074-hk01
- - qcom,ipq8074-hk10-c1
- - qcom,ipq8074-hk10-c2
- - const: qcom,ipq8074
-
- - items:
- - enum:
- - qcom,ipq9574-ap-al02-c2
- - qcom,ipq9574-ap-al02-c2-emmc
- - qcom,ipq9574-ap-al02-c6
- - qcom,ipq9574-ap-al02-c7
- - qcom,ipq9574-ap-al02-c7-emmc
- - qcom,ipq9574-ap-al02-c8
- - qcom,ipq9574-ap-al02-c9
- - const: qcom,ipq9574
-
- - items:
- - enum:
- - qcom,ipq9650-rdp488
- - const: qcom,ipq9650
-
- - items:
- - enum:
- - qcom,kaanapali-mtp
- - qcom,kaanapali-qrd
- - const: qcom,kaanapali
-
- - description: Sierra Wireless MangOH Green with WP8548 Module
- items:
- - const: swir,mangoh-green-wp8548
- - const: swir,wp8548
- - const: qcom,mdm9615
-
- description: Qualcomm Technologies, Inc. Robotics RB1
items:
- enum:
@@ -403,6 +409,20 @@ properties:
- thundercomm,rubikpi3
- const: qcom,qcm6490
+ - items:
+ - enum:
+ - qcom,qcs404-evb-1000
+ - qcom,qcs404-evb-4000
+ - const: qcom,qcs404-evb
+ - const: qcom,qcs404
+
+ - items:
+ - enum:
+ - arduino,monza
+ - qcom,monaco-evk
+ - qcom,qcs8300-ride
+ - const: qcom,qcs8300
+
- description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform
items:
- enum:
@@ -416,6 +436,31 @@ properties:
- qcom,qru1000-idp
- const: qcom,qru1000
+ - items:
+ - enum:
+ - qcom,sa8155p-adp
+ - const: qcom,sa8155p
+
+ - items:
+ - enum:
+ - qcom,sa8295p-adp
+ - qcom,sa8540p-ride
+ - const: qcom,sa8540p
+
+ - items:
+ - enum:
+ - qcom,sa8775p-ride
+ - qcom,sa8775p-ride-r3
+ - const: qcom,sa8775p
+
+ - items:
+ - enum:
+ - qcom,lemans-evk
+ - qcom,qcs9100-ride
+ - qcom,qcs9100-ride-r3
+ - const: qcom,qcs9100
+ - const: qcom,sa8775p
+
- description: Qualcomm AR2 Gen1 platform
items:
- enum:
@@ -828,14 +873,6 @@ properties:
- const: google,zombie-sku514
- const: qcom,sc7280
- - description: Xiaomi Poco F1
- items:
- - enum:
- - xiaomi,beryllium-ebbg
- - xiaomi,beryllium-tianma
- - const: xiaomi,beryllium
- - const: qcom,sdm845
-
- items:
- enum:
- lenovo,flex-5g
@@ -853,6 +890,11 @@ properties:
- qcom,sc8280xp-qrd
- const: qcom,sc8280xp
+ - items:
+ - enum:
+ - inforce,ifc6560
+ - const: qcom,sda660
+
- items:
- enum:
- lenovo,tbx605f
@@ -867,11 +909,6 @@ properties:
- sony,voyager-row
- const: qcom,sdm630
- - items:
- - enum:
- - inforce,ifc6560
- - const: qcom,sda660
-
- items:
- enum:
- fairphone,fp3
@@ -899,74 +936,13 @@ properties:
- const: google,bonito
- const: qcom,sdm670
- - items:
- - enum:
- - qcom,sdx55-mtp
- - qcom,sdx55-telit-fn980-tlb
- - qcom,sdx55-t55
- - const: qcom,sdx55
-
- - items:
- - enum:
- - qcom,sdx65-mtp
- - const: qcom,sdx65
-
- - items:
- - enum:
- - qcom,sdx75-idp
- - const: qcom,sdx75
-
- - items:
- - enum:
- - qcom,ipq6018-cp01
- - qcom,ipq6018-cp01-c1
- - const: qcom,ipq6018
-
- - items:
- - enum:
- - qcom,qcs404-evb-1000
- - qcom,qcs404-evb-4000
- - const: qcom,qcs404-evb
- - const: qcom,qcs404
-
- - items:
- - enum:
- - arduino,monza
- - qcom,monaco-evk
- - qcom,qcs8300-ride
- - const: qcom,qcs8300
-
- - items:
- - enum:
- - qcom,qcs615-ride
- - qcom,talos-evk
- - const: qcom,qcs615
- - const: qcom,sm6150
-
- - items:
- - enum:
- - qcom,sa8155p-adp
- - const: qcom,sa8155p
-
- - items:
- - enum:
- - qcom,sa8295p-adp
- - qcom,sa8540p-ride
- - const: qcom,sa8540p
-
- - items:
- - enum:
- - qcom,sa8775p-ride
- - qcom,sa8775p-ride-r3
- - const: qcom,sa8775p
-
- - items:
+ - description: Xiaomi Poco F1
+ items:
- enum:
- - qcom,lemans-evk
- - qcom,qcs9100-ride
- - qcom,qcs9100-ride-r3
- - const: qcom,qcs9100
- - const: qcom,sa8775p
+ - xiaomi,beryllium-ebbg
+ - xiaomi,beryllium-tianma
+ - const: xiaomi,beryllium
+ - const: qcom,sdm845
- items:
- enum:
@@ -989,6 +965,23 @@ properties:
- xiaomi,polaris
- const: qcom,sdm845
+ - items:
+ - enum:
+ - qcom,sdx55-mtp
+ - qcom,sdx55-telit-fn980-tlb
+ - qcom,sdx55-t55
+ - const: qcom,sdx55
+
+ - items:
+ - enum:
+ - qcom,sdx65-mtp
+ - const: qcom,sdx65
+
+ - items:
+ - enum:
+ - qcom,sdx75-idp
+ - const: qcom,sdx75
+
- items:
- enum:
- oneplus,billie2
@@ -1024,6 +1017,13 @@ properties:
- xiaomi,willow
- const: qcom,sm6125
+ - items:
+ - enum:
+ - qcom,qcs615-ride
+ - qcom,talos-evk
+ - const: qcom,qcs615
+ - const: qcom,sm6150
+
- items:
- enum:
- sony,pdx213
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260623-reorg_qcom_binding-0648bdef8db8
Best regards,
--
Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v6 3/6 RESEND] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: sashiko-bot @ 2026-06-25 10:34 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: dmitry.torokhov, linux-input, lee, linux-leds, robh, conor+dt,
devicetree
In-Reply-To: <20260625081812.33474-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The YAML schema introduces a `ports` wrapper node for the `audio-codec`, which conflicts with the original TXT binding and existing device trees that define `port@X` directly as children.
- [Medium] The schema explicitly expects the power button subnode to be named exactly `key-power`, but the in-tree device tree uses `button`.
- [Medium] The `spi-cs-high` property, which is physically required by the hardware and was explicitly listed as required in the legacy text binding, has been omitted from the `required` list in the YAML schema.
--
commit 30a40e2d4eb937fd9bbca306ed8246e061a54ab4
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: convert to DT schema
Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 0000000000000..76705ea56805a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
[ ... ]
> + audio-codec:
> + type: object
> + additionalProperties: false
> +
> + properties:
[ ... ]
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
[Severity: Medium]
Will this break validation for existing device trees?
The legacy text binding example shows port@0 and port@1 directly under the
audio-codec node, but this schema requires them to be wrapped in a ports
node. Because additionalProperties is set to false on audio-codec, direct
port@X nodes in existing device trees will be rejected.
[ ... ]
> + charger:
> + $ref: /schemas/power/supply/cpcap-charger.yaml#
> +
> + key-power:
> + $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml#
[Severity: Medium]
Is it intentional to restrict the subnode name strictly to key-power?
Existing in-tree device trees use button for this node. By strictly matching
key-power, existing configurations will be rejected as an undocumented
property during schema validation.
[ ... ]
> +patternProperties:
> + "^led(-[a-z]+)?$":
> + $ref: /schemas/leds/motorola,cpcap-leds.yaml#
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> + - spi-max-frequency
[Severity: Medium]
Does this schema incorrectly omit spi-cs-high from the required list?
The legacy text binding explicitly listed spi-cs-high as a required property.
Without it, incomplete device trees lacking this hardware-critical property
will incorrectly pass validation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=3
^ permalink raw reply
* [PATCH v6 0/3] pwm: add support for Andes platform
From: Ben Zong-You Xie via B4 Relay @ 2026-06-25 10:35 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
The ATCPIT100 is a set of compact multi-function timers, which can be
a simple timer or PWM, or a combination of the timer and the PWM. This
IP block is a core component of the Andes AE350 platform, which serves
as a reference architecture for SoC designs. The QiLai SoC also
integrates this controller.
This device driver was previously part of the Linux Kernel, and the
compatible was its IP name "andestech,atcpit100". However, the driver
and its binding were removed due to the deprecation of the NDS32
architecture [1]. Although Andes now dedicates our effort on RISC-V,
ATCPIT100 is still one of our peripheral IPs, and that's why we are
re-introducing it now. Since only using the IP block name as the
compatible is forbidden now, change the compatible to
"andestech,ae350-pwm" and "andestech,qilai-pwm".
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aec499c75cf8e0b599be4d559e6922b613085f8f
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
Changes in v6:
- Rebased on ukleinek/pwm/for-next.
- (2/3)
- Round a too-large period or duty cycle down to the largest achievable
value, and emulate 0%/100% relative duty cycles by parking the channel,
instead of erroring out. (Uwe)
- Choose the period from the requested period alone, so it no longer
depends on the requested duty cycle. (Uwe)
- Convert the period to ticks and compute the high/low phases in the tick
domain to avoid rounding errors. (Uwe)
- Reconstruct the period in .get_state() with a single DIV_ROUND_UP_ULL()
over both phases, shared by both polarities, and read the control
register with FIELD_GET(). (Uwe)
- Set an out-of-range clock rate to 0 so that source cannot be selected,
and name both rates in the "no usable clock" error message. (Uwe)
- Rename to_andes_pwm() to andes_pwm_from_chip(). (Uwe)
- Capitalize error messages. (Uwe)
- Tidy up the in-function comment and the limitations list.
- Link to v5: https://patch.msgid.link/20260330-andes-pwm-v5-0-01c59a659d2c@andestech.com
Changes in v5:
- Rebased on ukleinek/pwm/for-next
- (1/3)
- Added Rob's reviewed-by tag.
- Link to v4: https://patch.msgid.link/20260204-andes-pwm-v4-0-67016bb13555@andestech.com
Changes in v4:
- Updated cover letter title and its commit message.
- (1/3)
- Updated the compatibles and the binding file name.
- Added the description to the binding.
- Corrected device register size.
- Dropped the changes to the MAINTAINERS file.
- (2/3)
- Updated the driver name.
- Made the driver support inversed polarity.
- Changed the clock selection algorithm.
- Made the configuration depend on ARCH_ANDES, instead of RISCV. (Krzysztof)
- Dropped the changes to the MAINTAINERS file.
- (3/3) (new)
- Collected all changes to the MAINTAINERS file into a single patch.
- Link to v3: https://patch.msgid.link/20250123193534.874256-1-ben717@andestech.com
Changes in v3:
- (1/2):
- modified the compatible string. (Krzysztof)
- (2/2):
- added a check for the clock rate to prevent the overflow warning.
(kernel test robot)
- removed the unnecessary check in .apply(). (kernel test robot)
- Link to v2: https://patch.msgid.link/20241202060147.1271264-1-ben717@andestech.com
Changes in v2:
- (1/2):
- changed "title" in the yaml file.
- removed vendor-specific property, and added clocks property.
- (2/2):
- added a description for hardware limitations. (Uwe)
- switched the clock parent depending on the requested setting
instead of statically configuring the clock source in DT. (Uwe)
- Link to v1: https://patch.msgid.link/20241028102721.1961289-1-ben717@andestech.com
---
Ben Zong-You Xie (3):
dt-bindings: pwm: add support for AE350 PWM controller
pwm: add Andes PWM driver support
MAINTAINERS: add an entry for Andes PWM driver
.../bindings/pwm/andestech,ae350-pwm.yaml | 61 ++++
MAINTAINERS | 6 +
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-andes.c | 343 +++++++++++++++++++++
5 files changed, 421 insertions(+)
---
base-commit: 898ab0f30e008e411ce93ddf81c4099abd9d4e46
change-id: 20260204-andes-pwm-10ea6611c3cf
Best regards,
--
Ben Zong-You Xie <ben717@andestech.com>
^ permalink raw reply
* [PATCH v6 1/3] dt-bindings: pwm: add support for AE350 PWM controller
From: Ben Zong-You Xie via B4 Relay @ 2026-06-25 10:35 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
In-Reply-To: <20260625-andes-pwm-v6-0-3aef11711017@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
The ATCPIT100 is a set of compact multi-function timers, which can be
used as pulse width modulators (PWM) as well as simple timers.
ATCPIT100 supports up to 4 PIT channels, and each PIT channel may be
configured as a simple timer or PWM, or a combination of the timer and
the PWM. This IP block is a core component of the Andes AE350 platform,
which serves as a reference architecture for SoC designs. The QiLai SoC
also integrates this controller.
The binding introduces the following compatible strings:
- "andestech,qilai-pwm": For the implementation integrated into the
Andes QiLai SoC.
- "andestech,ae350-pwm": As a fallback compatible string representing
the base IP design used across the AE350 platform architecture.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
.../bindings/pwm/andestech,ae350-pwm.yaml | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
new file mode 100644
index 000000000000..287f3c62965f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/andestech,ae350-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Andes PWM controller on AE350 platform
+
+description:
+ This controller has 4 channels and two clock sources. Each channel can
+ switch the clock source by programming the corresponding register.
+
+maintainers:
+ - Ben Zong-You Xie <ben717@andestech.com>
+
+allOf:
+ - $ref: pwm.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - andestech,qilai-pwm
+ - const: andestech,ae350-pwm
+ - const: andestech,ae350-pwm
+
+ reg:
+ maxItems: 1
+
+ "#pwm-cells":
+ const: 3
+
+ clocks:
+ items:
+ - description: APB bus clock
+ - description: External clock
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: extclk
+
+required:
+ - compatible
+ - reg
+ - "#pwm-cells"
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pwm@f0400000 {
+ compatible = "andestech,ae350-pwm";
+ reg = <0xf0400000 0x100000>;
+ #pwm-cells = <3>;
+ clocks = <&pclk>, <&extclk>;
+ clock-names = "pclk", "extclk";
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v6 2/3] pwm: add Andes PWM driver support
From: Ben Zong-You Xie via B4 Relay @ 2026-06-25 10:36 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
In-Reply-To: <20260625-andes-pwm-v6-0-3aef11711017@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Add a driver for the PWM controller found in Andes AE350 platforms and
QiLai SoCs.
The Andes PWM controller features:
- 4 independent channels.
- Dual clock source support (APB clock and external clock) to provide
a flexible range of frequencies.
- Support for normal and inversed polarity.
The driver implements the .apply() and .get_state() callbacks. Since the
clock source of each channel can be selected by programming the
register, clock selection logic is implemented to prioritize the
external clock to maximize the supported period range, falling back to
the APB clock for higher frequency requirements.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-andes.c | 343 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 354 insertions(+)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index e8886a9b64d9..52dee4b7f081 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -73,6 +73,16 @@ config PWM_AIROHA
To compile this driver as a module, choose M here: the module
will be called pwm-airoha.
+config PWM_ANDES
+ tristate "Andes PWM support"
+ depends on ARCH_ANDES || COMPILE_TEST
+ help
+ Generic PWM framework driver for Andes platform, such as QiLai SoC
+ and AE350 platform.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-andes.
+
config PWM_APPLE
tristate "Apple SoC PWM support"
depends on ARCH_APPLE || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 5630a521a7cf..c92369ee251d 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM) += core.o
obj-$(CONFIG_PWM_AB8500) += pwm-ab8500.o
obj-$(CONFIG_PWM_ADP5585) += pwm-adp5585.o
obj-$(CONFIG_PWM_AIROHA) += pwm-airoha.o
+obj-$(CONFIG_PWM_ANDES) += pwm-andes.o
obj-$(CONFIG_PWM_APPLE) += pwm-apple.o
obj-$(CONFIG_PWM_ARGON_FAN_HAT) += pwm-argon-fan-hat.o
obj-$(CONFIG_PWM_ATMEL) += pwm-atmel.o
diff --git a/drivers/pwm/pwm-andes.c b/drivers/pwm/pwm-andes.c
new file mode 100644
index 000000000000..580e673d2cff
--- /dev/null
+++ b/drivers/pwm/pwm-andes.c
@@ -0,0 +1,343 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Andes PWM, used in Andes AE350 platform and QiLai SoC
+ *
+ * Copyright (C) 2026 Andes Technology Corporation.
+ *
+ * Limitations:
+ * - When disabling a channel, the current period is not completed and the
+ * output is driven to the PARK level (low when ANDES_PWM_CH_CTRL_PARK is
+ * clear, high when it is set).
+ * - The current period will be completed first if reconfiguring.
+ * - Further, if the reconfiguration changes the clock source, the output will
+ * not be the old one nor the new one. And the output will be the new one
+ * after writing to the reload register.
+ * - The hardware cannot run a 0% or 100% relative duty cycle; the driver
+ * emulates these by disabling the channel and parking the output at the
+ * constant level.
+ * - A period or duty cycle larger than the selected clock can represent is
+ * rounded down to the largest achievable value rather than rejected.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/math64.h>
+#include <linux/minmax.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/regmap.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+#define ANDES_PWM_CH_ENABLE 0x1C
+#define ANDES_PWM_CH_ENABLE_PWM(ch) BIT(3 + (4 * (ch)))
+
+#define ANDES_PWM_CH_CTRL(ch) (0x20 + (0x10 * (ch)))
+#define ANDES_PWM_CH_CTRL_MODE_PWM BIT(2)
+#define ANDES_PWM_CH_CTRL_CLK BIT(3)
+#define ANDES_PWM_CH_CTRL_PARK BIT(4)
+#define ANDES_PWM_CH_CTRL_MASK GENMASK(4, 0)
+
+#define ANDES_PWM_CH_RELOAD(ch) (0x24 + (0x10 * (ch)))
+#define ANDES_PWM_CH_RELOAD_HIGH GENMASK(31, 16)
+#define ANDES_PWM_CH_RELOAD_LOW GENMASK(15, 0)
+
+#define ANDES_PWM_CH_COUNTER(ch) (0x28 + (0x10 * (ch)))
+
+#define ANDES_PWM_CH_MAX 4
+#define ANDES_PWM_CYCLE_MIN 1
+#define ANDES_PWM_CYCLE_MAX 0x10000
+
+struct andes_pwm {
+ struct regmap *regmap;
+ struct clk *pclk;
+ struct clk *extclk;
+ unsigned int pclk_rate;
+ unsigned int extclk_rate;
+};
+
+static const struct regmap_config andes_pwm_regmap_config = {
+ .name = "andes_pwm",
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .pad_bits = 0,
+ .max_register = ANDES_PWM_CH_COUNTER(ANDES_PWM_CH_MAX - 1),
+ .cache_type = REGCACHE_NONE,
+};
+
+static inline struct andes_pwm *andes_pwm_from_chip(struct pwm_chip *chip)
+{
+ return pwmchip_get_drvdata(chip);
+}
+
+static int andes_pwm_enable(struct pwm_chip *chip, unsigned int channel,
+ bool enable)
+{
+ struct andes_pwm *ap = andes_pwm_from_chip(chip);
+
+ return regmap_assign_bits(ap->regmap, ANDES_PWM_CH_ENABLE,
+ ANDES_PWM_CH_ENABLE_PWM(channel), enable);
+}
+
+/*
+ * Hold the output at a constant level by parking the disabled channel. A
+ * disabled channel drives its output to the PARK level (low when @high is
+ * false, high when @high is true), which is used to emulate a 0% or 100%
+ * relative duty cycle.
+ */
+static int andes_pwm_park(struct pwm_chip *chip, unsigned int channel,
+ bool high)
+{
+ struct andes_pwm *ap = andes_pwm_from_chip(chip);
+
+ regmap_assign_bits(ap->regmap, ANDES_PWM_CH_CTRL(channel),
+ ANDES_PWM_CH_CTRL_PARK, high);
+
+ return andes_pwm_enable(chip, channel, false);
+}
+
+static int andes_pwm_config(struct pwm_chip *chip, unsigned int channel,
+ const struct pwm_state *state)
+{
+ struct andes_pwm *ap = andes_pwm_from_chip(chip);
+ unsigned int clk_rate = ap->extclk_rate;
+ unsigned int ctrl = ANDES_PWM_CH_CTRL_MODE_PWM;
+ bool use_pclk = false;
+ u64 high_cycles;
+ u64 low_cycles;
+ u64 period_cycles;
+ u64 duty_cycles;
+ u32 reload;
+
+ /*
+ * Reload register for PWM mode:
+ *
+ * 31 : 16 15 : 0
+ * PWM16_Hi | PWM16_Lo
+ *
+ * The high duration is (PWM16_Hi + 1) cycles and the low duration is
+ * (PWM16_Lo + 1) cycles, so each phase spans ANDES_PWM_CYCLE_MIN to
+ * ANDES_PWM_CYCLE_MAX cycles. The hardware period (their sum) can reach
+ * 2 * ANDES_PWM_CYCLE_MAX cycles, but the PWM core requires the period
+ * to be chosen from the requested period alone, independent of the duty
+ * cycle. That holds only while both phases stay within
+ * ANDES_PWM_CYCLE_MAX for every duty split, so the usable period is
+ * capped at ANDES_PWM_CYCLE_MAX + ANDES_PWM_CYCLE_MIN cycles.
+ *
+ * The controller has two clock sources, the APB clock and an external
+ * clock. Since the external clock frequency must be slower than the APB
+ * clock, it is tried first for its wider period range; the APB clock is
+ * used only when the external clock is too fast to represent the period
+ * (it resolves fewer than two cycles) or is absent.
+ */
+ period_cycles = mul_u64_u64_div_u64(clk_rate, state->period,
+ NSEC_PER_SEC);
+ if (period_cycles < 2 * ANDES_PWM_CYCLE_MIN) {
+ use_pclk = true;
+ clk_rate = ap->pclk_rate;
+ period_cycles = mul_u64_u64_div_u64(clk_rate, state->period,
+ NSEC_PER_SEC);
+ if (period_cycles < 2 * ANDES_PWM_CYCLE_MIN)
+ return -EINVAL;
+ }
+
+ /*
+ * Round the period down to the largest value representable for every
+ * duty cycle, so the chosen period depends on the requested period
+ * alone. With both phases capped at ANDES_PWM_CYCLE_MAX, that bound is
+ * ANDES_PWM_CYCLE_MAX + ANDES_PWM_CYCLE_MIN cycles.
+ */
+ period_cycles = min_t(u64, period_cycles,
+ ANDES_PWM_CYCLE_MAX + ANDES_PWM_CYCLE_MIN);
+
+ /* The duty cycle cannot exceed the (possibly clamped) period. */
+ duty_cycles = mul_u64_u64_div_u64(clk_rate, state->duty_cycle,
+ NSEC_PER_SEC);
+ duty_cycles = min_t(u64, duty_cycles, period_cycles);
+ if (state->polarity == PWM_POLARITY_INVERSED) {
+ low_cycles = duty_cycles;
+ high_cycles = period_cycles - low_cycles;
+ } else {
+ high_cycles = duty_cycles;
+ low_cycles = period_cycles - high_cycles;
+ }
+
+ /*
+ * A zero-length phase means a 0% or 100% relative duty cycle, which the
+ * hardware cannot run. Emit the matching constant level by parking the
+ * channel: high_cycles == 0 stays low, low_cycles == 0 stays high.
+ */
+ if (!high_cycles)
+ return andes_pwm_park(chip, channel, false);
+ if (!low_cycles)
+ return andes_pwm_park(chip, channel, true);
+
+ /*
+ * If changing the clock source here, the output will not be the old one
+ * nor the new one. And the output will be the new one after writing to
+ * the reload register.
+ */
+ ctrl |= use_pclk ? ANDES_PWM_CH_CTRL_CLK : 0;
+ ctrl |= (state->polarity == PWM_POLARITY_INVERSED) ?
+ ANDES_PWM_CH_CTRL_PARK : 0;
+ regmap_update_bits(ap->regmap, ANDES_PWM_CH_CTRL(channel),
+ ANDES_PWM_CH_CTRL_MASK, ctrl);
+ reload = FIELD_PREP(ANDES_PWM_CH_RELOAD_HIGH, high_cycles - 1) |
+ FIELD_PREP(ANDES_PWM_CH_RELOAD_LOW, low_cycles - 1);
+ regmap_write(ap->regmap, ANDES_PWM_CH_RELOAD(channel), reload);
+ return andes_pwm_enable(chip, channel, true);
+}
+
+static int andes_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ unsigned int channel = pwm->hwpwm;
+
+ if (!state->enabled) {
+ if (pwm->state.enabled)
+ andes_pwm_enable(chip, channel, false);
+
+ return 0;
+ }
+
+ return andes_pwm_config(chip, channel, state);
+}
+
+static int andes_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct andes_pwm *ap = andes_pwm_from_chip(chip);
+ unsigned int channel = pwm->hwpwm;
+ unsigned int ctrl;
+ unsigned int clk_rate;
+ unsigned int reload;
+ u64 high_cycles;
+ u64 low_cycles;
+
+ regmap_read(ap->regmap, ANDES_PWM_CH_CTRL(channel), &ctrl);
+ clk_rate = FIELD_GET(ANDES_PWM_CH_CTRL_CLK, ctrl) ? ap->pclk_rate
+ : ap->extclk_rate;
+ if (!clk_rate) {
+ /*
+ * The selected clock source is unavailable, so the channel
+ * cannot be running; report it as disabled and avoid the
+ * division by zero below.
+ */
+ state->enabled = false;
+ state->period = 0;
+ state->duty_cycle = 0;
+ return 0;
+ }
+
+ state->enabled = regmap_test_bits(ap->regmap, ANDES_PWM_CH_ENABLE,
+ ANDES_PWM_CH_ENABLE_PWM(channel)) > 0;
+ state->polarity = FIELD_GET(ANDES_PWM_CH_CTRL_PARK, ctrl) ?
+ PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
+ regmap_read(ap->regmap, ANDES_PWM_CH_RELOAD(channel), &reload);
+ high_cycles = FIELD_GET(ANDES_PWM_CH_RELOAD_HIGH, reload) + 1;
+ low_cycles = FIELD_GET(ANDES_PWM_CH_RELOAD_LOW, reload) + 1;
+
+ /*
+ * high_cycles and low_cycles are each at most ANDES_PWM_CYCLE_MAX
+ * (0x10000, 17 bits) and NSEC_PER_SEC is below 2^30, so the products
+ * below are safe from 64-bit overflow.
+ */
+ if (state->polarity == PWM_POLARITY_INVERSED)
+ state->duty_cycle = DIV_ROUND_UP_ULL(low_cycles * NSEC_PER_SEC,
+ clk_rate);
+ else
+ state->duty_cycle = DIV_ROUND_UP_ULL(high_cycles * NSEC_PER_SEC,
+ clk_rate);
+
+ state->period = DIV_ROUND_UP_ULL((high_cycles + low_cycles) *
+ NSEC_PER_SEC, clk_rate);
+
+ return 0;
+}
+
+static const struct pwm_ops andes_pwm_ops = {
+ .apply = andes_pwm_apply,
+ .get_state = andes_pwm_get_state,
+};
+
+static int andes_pwm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct pwm_chip *chip;
+ struct andes_pwm *ap;
+ void __iomem *reg_base;
+ unsigned long pclk_rate;
+ unsigned long extclk_rate;
+ int ret;
+
+ chip = devm_pwmchip_alloc(dev, ANDES_PWM_CH_MAX, sizeof(*ap));
+ if (IS_ERR(chip))
+ return PTR_ERR(chip);
+
+ ap = andes_pwm_from_chip(chip);
+ reg_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(reg_base))
+ return dev_err_probe(dev, PTR_ERR(reg_base),
+ "Failed to map I/O space\n");
+
+ ap->pclk = devm_clk_get_enabled(dev, "pclk");
+ if (IS_ERR(ap->pclk))
+ return dev_err_probe(dev, PTR_ERR(ap->pclk),
+ "Failed to get APB clock\n");
+
+ ap->extclk = devm_clk_get_optional_enabled(dev, "extclk");
+ if (IS_ERR(ap->extclk))
+ return dev_err_probe(dev, PTR_ERR(ap->extclk),
+ "Failed to get external clock\n");
+
+ /*
+ * If the clock rate is greater than 10^9, there may be an overflow when
+ * calculating the cycles in andes_pwm_config()
+ */
+ pclk_rate = clk_get_rate(ap->pclk);
+ extclk_rate = clk_get_rate(ap->extclk);
+
+ ap->pclk_rate = pclk_rate > NSEC_PER_SEC ? 0 : pclk_rate;
+ ap->extclk_rate = extclk_rate > NSEC_PER_SEC ? 0 : extclk_rate;
+
+ if (!ap->pclk_rate && !ap->extclk_rate)
+ return dev_err_probe(dev, -EINVAL,
+ "No usable clock: pclk %lu Hz, extclk %lu Hz\n",
+ pclk_rate, extclk_rate);
+
+ ap->regmap = devm_regmap_init_mmio(dev, reg_base,
+ &andes_pwm_regmap_config);
+ if (IS_ERR(ap->regmap))
+ return dev_err_probe(dev, PTR_ERR(ap->regmap),
+ "Failed to initialize regmap\n");
+
+ chip->ops = &andes_pwm_ops;
+ ret = devm_pwmchip_add(dev, chip);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to add PWM chip\n");
+
+ return 0;
+}
+
+static const struct of_device_id andes_pwm_of_match[] = {
+ { .compatible = "andestech,ae350-pwm" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, andes_pwm_of_match);
+
+static struct platform_driver andes_pwm_driver = {
+ .driver = {
+ .name = "andes_pwm",
+ .of_match_table = andes_pwm_of_match,
+ },
+ .probe = andes_pwm_probe,
+};
+module_platform_driver(andes_pwm_driver);
+
+MODULE_AUTHOR("Ben Zong-You Xie <ben717@andestech.com>");
+MODULE_DESCRIPTION("Andes PWM driver");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH v6 3/3] MAINTAINERS: add an entry for Andes PWM driver
From: Ben Zong-You Xie via B4 Relay @ 2026-06-25 10:36 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-pwm, devicetree, linux-kernel, Ben Zong-You Xie
In-Reply-To: <20260625-andes-pwm-v6-0-3aef11711017@andestech.com>
From: Ben Zong-You Xie <ben717@andestech.com>
Add an entry for the Andes PWM driver to the MAINTAINERS file.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2fb1c75afd16..2461683a5bbb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1874,6 +1874,12 @@ S: Supported
F: Documentation/devicetree/bindings/spi/andestech,ae350-spi.yaml
F: drivers/spi/spi-atcspi200.c
+ANDES PWM DRIVER
+M: Ben Zong-You Xie <ben717@andestech.com>
+S: Supported
+F: Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
+F: drivers/pwm/pwm-andes.c
+
ANDROID DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Arve Hjønnevåg <arve@android.com>
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-25 10:37 UTC (permalink / raw)
To: konrad.dybcio
Cc: andersson, devicetree, konradybcio, linux-arm-msm, linux-kernel,
xxsemail
In-Reply-To: <07fd4bcb-f55f-4856-9b93-7f4569a27b7f@oss.qualcomm.com>
On Wed, 2026-06-24 at 13:57 +0200, Konrad Dybcio wrote:
> On 6/22/26 8:46 PM, Xin Xu wrote:
> > Add the pm8008 PMIC node on i2c15 with seven LDOs,
> > using GPIO84 as interrupt and GPIO76 as reset.
> >
> > Signed-off-by: Xin Xu <xxsemail@qq.com>
> > ---
>
> [...]
>
> > + pm8008_default: pm8008-default-state {
> > + int-pins {
> > + pins = "gpio84";
> > + function = "gpio";
> > + bias-disable;
> > + drive-strength = <2>;
> > + input-enable;
> > + };
> > +
> > + reset-pins {
> > + pins = "gpio76";
> > + function = "gpio";
> > + bias-pull-up;
> > + drive-strength = <2>;
>
> nit: bias properties after drive-strength (I now noticed that 8250
> dtsi
> has it ""wrong"", we'll mass-touch it up once we have a tool for
> that..
> sorry for the trouble)
>
> otherwise
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
On Wed, 2026-06-24 at 14:00 +0200, Konrad Dybcio wrote:
> On 6/22/26 8:46 PM, Xin Xu wrote:
> > Add the pm8008 PMIC node on i2c15 with seven LDOs,
> > using GPIO84 as interrupt and GPIO76 as reset.
> >
> > Signed-off-by: Xin Xu <xxsemail@qq.com>
> > ---
>
> [...]
>
>
> > + pm8008_default: pm8008-default-state {
> > + int-pins {
> > + pins = "gpio84";
> > + function = "gpio";
> > + bias-disable;
> > + drive-strength = <2>;
> > + input-enable;
> > + };
>
> arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-boe.dtb: pinctrl@f100000
> (qcom,sm8250-pinctrl): pm8008-default-state: 'oneOf' conditional
> failed, one must be fixed:
> 'function' is a required property
> 'pins' is a required property
> Unevaluated properties are not allowed ('int-pins', 'reset-
> pins' were unexpected)
> False schema does not allow True
> from schema $id:
> http://devicetree.org/schemas/pinctrl/qcom,sm8250-pinctrl.yaml
>
> Please drop input-enable, it's not a thing on TLMM pins
>
> Konrad
Thank you for the review and the Reviewed-by tag!
I will fix these coding style issues (splitting the pinctrl nodes,
dropping input-enable, and reordering the bias properties) in the next
version.
Best regards,
Xin Xu
^ permalink raw reply
* Re: [PATCH v6 1/3] dt-bindings: pwm: add support for AE350 PWM controller
From: sashiko-bot @ 2026-06-25 10:45 UTC (permalink / raw)
To: Ben Zong-You Xie via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260625-andes-pwm-v6-1-3aef11711017@andestech.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The DT binding defines a specific software use-case (PWM) rather than holistically describing the underlying multi-function hardware block (ATCPIT100), omitting inherent hardware properties like `interrupts`.
--
commit efdd46b6c3b84eb1768cdcc54800ffa3c62afeef
Author: Ben Zong-You Xie <ben717@andestech.com>
dt-bindings: pwm: add support for AE350 PWM controller
This commit adds the device tree binding for the ATCPIT100 PWM controller
used in the Andes AE350 platform and QiLai SoC.
> diff --git a/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/andestech,ae350-pwm.yaml
[ ... ]
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - andestech,qilai-pwm
> + - const: andestech,ae350-pwm
> + - const: andestech,ae350-pwm
[ ... ]
> +required:
> + - compatible
> + - reg
> + - "#pwm-cells"
> + - clocks
> + - clock-names
> +
> +unevaluatedProperties: false
[Severity: Medium]
The commit message mentions that the ATCPIT100 block is a set of
multi-function timers that can be used as PWMs or simple timers. Does
this binding restrict the hardware description to only the PWM software
use-case?
Since unevaluatedProperties is set to false and the properties block omits
inherent hardware properties like interrupts, will dtbs_check fail if a
device tree author attempts to accurately describe the full ATCPIT100
multi-function hardware block by wiring its interrupt lines?
Would it be better to describe the complete hardware capabilities upfront,
such as timer functionality and interrupts, to prevent redesigns breaking
backward compatibility (like transitioning to an MFD or adding #timer-cells)
when timer support is needed later?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-andes-pwm-v6-0-3aef11711017@andestech.com?part=1
^ permalink raw reply
* Re: [PATCH v6 2/3] pwm: add Andes PWM driver support
From: sashiko-bot @ 2026-06-25 10:46 UTC (permalink / raw)
To: Ben Zong-You Xie via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260625-andes-pwm-v6-2-3aef11711017@andestech.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver fails to update the hardware PARK level to the inactive state when disabling the PWM channel, leaving the output stuck ON or at the wrong polarity.
--
commit 6823cc7ba3d3233c8090db2e53dc0a9b52b74a25
Author: Ben Zong-You Xie <ben717@andestech.com>
pwm: add Andes PWM driver support
Add a driver for the PWM controller found in Andes AE350 platforms and
QiLai SoCs.
> diff --git a/drivers/pwm/pwm-andes.c b/drivers/pwm/pwm-andes.c
> new file mode 100644
> index 0000000000000..580e673d2cff0
> --- /dev/null
> +++ b/drivers/pwm/pwm-andes.c
[ ... ]
> +static int andes_pwm_config(struct pwm_chip *chip, unsigned int channel,
> + const struct pwm_state *state)
> +{
[ ... ]
> + /*
> + * A zero-length phase means a 0% or 100% relative duty cycle, which the
> + * hardware cannot run. Emit the matching constant level by parking the
> + * channel: high_cycles == 0 stays low, low_cycles == 0 stays high.
> + */
> + if (!high_cycles)
> + return andes_pwm_park(chip, channel, false);
> + if (!low_cycles)
> + return andes_pwm_park(chip, channel, true);
[Severity: High]
When configuring a 100 percent duty cycle, this code sets the PARK bit to the
active state to emulate the output. If the channel is subsequently disabled,
could the output remain stuck ON?
> +
> + /*
> + * If changing the clock source here, the output will not be the old one
[ ... ]
> +static int andes_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + unsigned int channel = pwm->hwpwm;
> +
> + if (!state->enabled) {
> + if (pwm->state.enabled)
> + andes_pwm_enable(chip, channel, false);
> +
> + return 0;
> + }
[Severity: High]
Does this early return path disable the channel but fail to update the
hardware's PARK bit to reflect the inactive state of the current polarity?
If the PWM was previously configured to 100 percent duty cycle where the PARK
bit was set active, it appears bypassing the PARK bit configuration on the
disable path leaves the output driven at the active level.
Additionally, if the polarity changes while the channel is disabled, will the
hardware's inactive level fail to update?
> +
> + return andes_pwm_config(chip, channel, state);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-andes-pwm-v6-0-3aef11711017@andestech.com?part=2
^ 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