* [PATCH v4 0/4] gpio: realtek: Add support for Realtek DHC RTD1625
From: Yu-Chun Lin @ 2026-06-22 9:23 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
This series adds GPIO support for the Realtek DHC RTD1625 SoC.
Unlike the existing driver (gpio-rtd.c) which uses shared bank registers,
the RTD1625 features a per-pin register architecture where each GPIO line
is managed by its own dedicated 32-bit control register. This distinct
hardware design requires a new, separate driver.
Best Regards,
Yu-Chun Lin
---
Patches 1-3 (fix, dt-bindings, and driver) are targeted for the GPIO tree.
Patch 4 (dts) will be taken via the Realtek SoC tree later. It is included
here for context.
Changes in v4:
- Reverted to the v2 approach (without gpio-regmap integration).
As a result, dropped patches 2, 3, and 4 from the v3 series.
Changes in Patch 3 (driver) since v2:
- IRQ handling fixes:
- Added enum rtd1625_irq_index with named constants.
- Documented the hardware quirk.
- Code cleanup and coding style improvements.
- Included the <linux/cleanup.h> header.
- Updated the copyright year.
- Retained Linus Walleij's Reviewed-by tag from v1, as the recent updates are
cleanups and fixes rather than major feature changes.
(Linus, please let me know if you have any concerns regarding this).
v3: https://lore.kernel.org/lkml/20260512033317.1602537-1-eleanor.lin@realtek.com/
v2: https://lore.kernel.org/lkml/20260408025243.1155482-1-eleanor.lin@realtek.com/
v1: https://lore.kernel.org/lkml/20260331113835.3510341-1-eleanor.lin@realtek.com/
Tzuyi Chang (2):
dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
Yu-Chun Lin (2):
gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
arm64: dts: realtek: Add GPIO support for RTD1625
.../bindings/gpio/realtek,rtd1625-gpio.yaml | 71 ++
arch/arm64/boot/dts/realtek/kent.dtsi | 39 ++
drivers/gpio/Kconfig | 14 +-
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rtd1625.c | 611 ++++++++++++++++++
5 files changed, 735 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
create mode 100644 drivers/gpio/gpio-rtd1625.c
--
2.43.0
^ permalink raw reply
* [PATCH v4 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Yu-Chun Lin @ 2026-06-22 9:23 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai
In-Reply-To: <20260622092335.1166876-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
which manages pins via shared bank registers, the RTD1625 introduces
a per-pin register architecture. Each GPIO line now has its own
dedicated 32-bit control register to manage configuration independently,
including direction, output value, input value, interrupt enable, and
debounce. Therefore, this distinct hardware design requires a separate
driver.
Additionally, the RTD1625 GPIO controller has a specific hardware quirk:
it fires both 'assert' and 'de-assert' interrupts simultaneously on any
edge toggle. To handle this, we utilize the polarity register to route
the requested edge (rising/falling) to the 'assert' IRQ line. The driver
then filters out the unwanted 'de-assert' interrupt in the IRQ handler
and pre-clears edge interrupts to prevent interrupt storms caused by
unhandled dropped interrupts.
Interrupt support is optional for this device, matching the dt-bindings.
If the interrupts property is not provided, the driver simply skips IRQ
initialization and operates purely as a basic GPIO controller.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes between v2 and v4:
IRQ Handling Fix
- Added enum rtd1625_irq_index with named constants to replace magic array
indices 0/1/2.
- Documented hardware quirk.
Coding style & cleanup:
- In rtd1625_gpio_irq_set_type(), using return directly in each switch case.
- Changed int loop counters to unsigned int.
- Replaced devm_kzalloc() with devm_kcalloc() in probe.
- Moved of_device_id table closer to its user.
- Added static to DEFINE_NOIRQ_DEV_PM_OPS.
- Formatting consistency: zero-padded hex constants.
New header:
- Added #include <linux/cleanup.h> (required for the guard() / scoped_guard()
macros).
Copyright year updated:
- 2023 -> 2023-2026.
---
drivers/gpio/Kconfig | 12 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rtd1625.c | 611 ++++++++++++++++++++++++++++++++++++
3 files changed, 624 insertions(+)
create mode 100644 drivers/gpio/gpio-rtd1625.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ed2bc3113374..f03c05288376 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -656,6 +656,18 @@ config GPIO_RTD
Say yes here to support GPIO functionality and GPIO interrupt on
Realtek DHC SoCs.
+config GPIO_RTD1625
+ tristate "Realtek DHC RTD1625 GPIO support"
+ depends on ARCH_REALTEK || COMPILE_TEST
+ default ARCH_REALTEK
+ select GPIOLIB_IRQCHIP
+ help
+ This option enables support for the GPIO controller on Realtek
+ DHC (Digital Home Center) RTD1625 SoC.
+
+ Say yes here to support both basic GPIO line functionality
+ and GPIO interrupt handling capabilities for this platform.
+
config GPIO_SAMA5D2_PIOBU
tristate "SAMA5D2 PIOBU GPIO support"
depends on OF
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4d0e900402fc..fa14581e3995 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
obj-$(CONFIG_GPIO_REG) += gpio-reg.o
obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
+obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
new file mode 100644
index 000000000000..409e540bf40b
--- /dev/null
+++ b/drivers/gpio/gpio-rtd1625.c
@@ -0,0 +1,611 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Realtek DHC RTD1625 gpio driver
+ *
+ * Copyright (c) 2023-2026 Realtek Semiconductor Corp.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/cleanup.h>
+#include <linux/gpio/driver.h>
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#define RTD1625_GPIO_DIR BIT(0)
+#define RTD1625_GPIO_OUT BIT(2)
+#define RTD1625_GPIO_IN BIT(4)
+#define RTD1625_GPIO_EDGE_INT_DP BIT(6)
+#define RTD1625_GPIO_EDGE_INT_EN BIT(8)
+#define RTD1625_GPIO_LEVEL_INT_EN BIT(16)
+#define RTD1625_GPIO_LEVEL_INT_DP BIT(18)
+#define RTD1625_GPIO_DEBOUNCE GENMASK(30, 28)
+#define RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
+
+#define RTD1625_GPIO_WREN(x) ((x) << 1)
+
+/* Write-enable masks for all GPIO configs and reserved hardware bits */
+#define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a
+#define RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
+
+#define RTD1625_GPIO_DEBOUNCE_1US 0
+#define RTD1625_GPIO_DEBOUNCE_10US 1
+#define RTD1625_GPIO_DEBOUNCE_100US 2
+#define RTD1625_GPIO_DEBOUNCE_1MS 3
+#define RTD1625_GPIO_DEBOUNCE_10MS 4
+#define RTD1625_GPIO_DEBOUNCE_20MS 5
+#define RTD1625_GPIO_DEBOUNCE_30MS 6
+#define RTD1625_GPIO_DEBOUNCE_50MS 7
+
+#define GPIO_CONTROL(gpio) ((gpio) * 4)
+
+enum rtd1625_irq_index {
+ RTD1625_IRQ_ASSERT,
+ RTD1625_IRQ_DEASSERT,
+ RTD1625_IRQ_LEVEL,
+ RTD1625_MAX_IRQS
+};
+
+/**
+ * struct rtd1625_gpio_info - Specific GPIO register information
+ * @num_gpios: The number of GPIOs
+ * @irq_type_support: Supported IRQ types
+ * @gpa_offset: Offset for GPIO assert interrupt status registers
+ * @gpda_offset: Offset for GPIO deassert interrupt status registers
+ * @level_offset: Offset of level interrupt status register
+ * @write_en_all: Write-enable mask for all configurable bits
+ */
+struct rtd1625_gpio_info {
+ unsigned int num_gpios;
+ unsigned int irq_type_support;
+ unsigned int base_offset;
+ unsigned int gpa_offset;
+ unsigned int gpda_offset;
+ unsigned int level_offset;
+ unsigned int write_en_all;
+};
+
+struct rtd1625_gpio {
+ struct gpio_chip gpio_chip;
+ const struct rtd1625_gpio_info *info;
+ void __iomem *base;
+ void __iomem *irq_base;
+ unsigned int irqs[RTD1625_MAX_IRQS];
+ raw_spinlock_t lock;
+ unsigned int *save_regs;
+};
+
+static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->gpa_offset + ((offset / 32) * 4);
+}
+
+static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->gpda_offset + ((offset / 32) * 4);
+}
+
+static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio *data, unsigned int offset)
+{
+ return data->info->level_offset + ((offset / 32) * 4);
+}
+
+static int rtd1625_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+ unsigned int debounce)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u8 deb_val;
+ u32 val;
+
+ switch (debounce) {
+ case 1:
+ deb_val = RTD1625_GPIO_DEBOUNCE_1US;
+ break;
+ case 10:
+ deb_val = RTD1625_GPIO_DEBOUNCE_10US;
+ break;
+ case 100:
+ deb_val = RTD1625_GPIO_DEBOUNCE_100US;
+ break;
+ case 1000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_1MS;
+ break;
+ case 10000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_10MS;
+ break;
+ case 20000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_20MS;
+ break;
+ case 30000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_30MS;
+ break;
+ case 50000:
+ deb_val = RTD1625_GPIO_DEBOUNCE_50MS;
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+
+ val = FIELD_PREP(RTD1625_GPIO_DEBOUNCE, deb_val) | RTD1625_GPIO_DEBOUNCE_WREN;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+ unsigned long config)
+{
+ u32 debounce;
+
+ if (pinconf_to_config_param(config) == PIN_CONFIG_INPUT_DEBOUNCE) {
+ debounce = pinconf_to_config_argument(config);
+ return rtd1625_gpio_set_debounce(chip, offset, debounce);
+ }
+
+ return gpiochip_generic_config(chip, offset, config);
+}
+
+static int rtd1625_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_OUT);
+
+ if (value)
+ val |= RTD1625_GPIO_OUT;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = readl_relaxed(data->base + GPIO_CONTROL(offset));
+
+ if (val & RTD1625_GPIO_DIR)
+ return !!(val & RTD1625_GPIO_OUT);
+ else
+ return !!(val & RTD1625_GPIO_IN);
+}
+
+static int rtd1625_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = readl_relaxed(data->base + GPIO_CONTROL(offset));
+
+ if (val & RTD1625_GPIO_DIR)
+ return GPIO_LINE_DIRECTION_OUT;
+
+ return GPIO_LINE_DIRECTION_IN;
+}
+
+static int rtd1625_gpio_set_direction(struct gpio_chip *chip, unsigned int offset, bool out)
+{
+ struct rtd1625_gpio *data = gpiochip_get_data(chip);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_DIR);
+
+ if (out)
+ val |= RTD1625_GPIO_DIR;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(val, data->base + GPIO_CONTROL(offset));
+
+ return 0;
+}
+
+static int rtd1625_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
+{
+ return rtd1625_gpio_set_direction(chip, offset, false);
+}
+
+static int rtd1625_gpio_direction_output(struct gpio_chip *chip, unsigned int offset, int value)
+{
+ rtd1625_gpio_set(chip, offset, value);
+
+ return rtd1625_gpio_set_direction(chip, offset, true);
+}
+
+static void rtd1625_gpio_irq_handle(struct irq_desc *desc)
+{
+ unsigned int (*get_reg_offset)(struct rtd1625_gpio *gpio, unsigned int offset);
+ struct rtd1625_gpio *data = irq_desc_get_handler_data(desc);
+ struct irq_domain *domain = data->gpio_chip.irq.domain;
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned int irq = irq_desc_get_irq(desc);
+ unsigned long status;
+ unsigned int reg_offset, i, j;
+ unsigned int girq;
+ irq_hw_number_t hwirq;
+ u32 irq_type;
+
+ if (irq == data->irqs[RTD1625_IRQ_ASSERT])
+ get_reg_offset = &rtd1625_gpio_gpa_offset;
+ else if (irq == data->irqs[RTD1625_IRQ_DEASSERT])
+ get_reg_offset = &rtd1625_gpio_gpda_offset;
+ else if (irq == data->irqs[2])
+ get_reg_offset = &rtd1625_gpio_level_offset;
+ else
+ return;
+
+ chained_irq_enter(chip, desc);
+
+ for (i = 0; i < data->info->num_gpios; i += 32) {
+ reg_offset = get_reg_offset(data, i);
+ status = readl_relaxed(data->irq_base + reg_offset);
+
+ /*
+ * Hardware quirk: The controller fires both "assert" and "de-assert"
+ * interrupts simultaneously on any edge toggle.
+ * We must pre-clear edge interrupts here. If we drop an unwanted
+ * de-assert interrupt below, it will never reach the IRQ core
+ * (generic_handle_domain_irq), meaning ->irq_ack() won't be called.
+ * Failing to clear it here leads to an interrupt storm.
+ */
+ if (irq != data->irqs[RTD1625_IRQ_LEVEL])
+ writel_relaxed(status, data->irq_base + reg_offset);
+
+ for_each_set_bit(j, &status, 32) {
+ hwirq = i + j;
+ girq = irq_find_mapping(domain, hwirq);
+ irq_type = irq_get_trigger_type(girq);
+
+ /*
+ * Filter out the hardware-forced de-assert interrupt unless
+ * the user explicitly requested IRQ_TYPE_EDGE_BOTH.
+ */
+ if (irq == data->irqs[RTD1625_IRQ_DEASSERT] &&
+ irq_type != IRQ_TYPE_EDGE_BOTH)
+ continue;
+
+ generic_handle_domain_irq(domain, hwirq);
+ }
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+static void rtd1625_gpio_ack_irq(struct irq_data *d)
+{
+ struct rtd1625_gpio *data = irq_data_get_irq_chip_data(d);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+ u32 bit_mask = BIT(hwirq % 32);
+ int reg_offset;
+
+ if (irq_type & IRQ_TYPE_LEVEL_MASK) {
+ reg_offset = rtd1625_gpio_level_offset(data, hwirq);
+ writel_relaxed(bit_mask, data->irq_base + reg_offset);
+ }
+}
+
+static void rtd1625_gpio_enable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ int gpda_reg_offset = rtd1625_gpio_gpda_offset(data, hwirq);
+ int gpa_reg_offset = rtd1625_gpio_gpa_offset(data, hwirq);
+ u32 clr_mask = BIT(hwirq % 32);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(clr_mask, data->irq_base + gpa_reg_offset);
+ writel_relaxed(clr_mask, data->irq_base + gpda_reg_offset);
+ val = RTD1625_GPIO_EDGE_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_disable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_enable_level_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ int level_reg_offset = rtd1625_gpio_level_offset(data, hwirq);
+ u32 clr_mask = BIT(hwirq % 32);
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ writel_relaxed(clr_mask, data->irq_base + level_reg_offset);
+ val = RTD1625_GPIO_LEVEL_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_disable_level_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
+{
+ u32 val;
+
+ guard(raw_spinlock_irqsave)(&data->lock);
+
+ val = RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_EN);
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+}
+
+static void rtd1625_gpio_enable_irq(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+
+ gpiochip_enable_irq(gc, hwirq);
+
+ if (irq_type & IRQ_TYPE_EDGE_BOTH)
+ rtd1625_gpio_enable_edge_irq(data, hwirq);
+ else if (irq_type & IRQ_TYPE_LEVEL_MASK)
+ rtd1625_gpio_enable_level_irq(data, hwirq);
+}
+
+static void rtd1625_gpio_disable_irq(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+
+ if (irq_type & IRQ_TYPE_EDGE_BOTH)
+ rtd1625_gpio_disable_edge_irq(data, hwirq);
+ else if (irq_type & IRQ_TYPE_LEVEL_MASK)
+ rtd1625_gpio_disable_level_irq(data, hwirq);
+
+ gpiochip_disable_irq(gc, hwirq);
+}
+
+static int rtd1625_gpio_irq_set_level_type(struct irq_data *d, bool level)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_DP);
+
+ if (!(data->info->irq_type_support & IRQ_TYPE_LEVEL_MASK))
+ return -EINVAL;
+
+ if (level)
+ val |= RTD1625_GPIO_LEVEL_INT_DP;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock)
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+
+ irq_set_handler_locked(d, handle_level_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_edge_type(struct irq_data *d, bool polarity)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct rtd1625_gpio *data = gpiochip_get_data(gc);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_DP);
+
+ if (!(data->info->irq_type_support & IRQ_TYPE_EDGE_BOTH))
+ return -EINVAL;
+
+ if (polarity)
+ val |= RTD1625_GPIO_EDGE_INT_DP;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock)
+ writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
+
+ irq_set_handler_locked(d, handle_edge_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+ switch (type & IRQ_TYPE_SENSE_MASK) {
+ case IRQ_TYPE_EDGE_RISING:
+ return rtd1625_gpio_irq_set_edge_type(d, 1);
+
+ case IRQ_TYPE_EDGE_FALLING:
+ return rtd1625_gpio_irq_set_edge_type(d, 0);
+
+ case IRQ_TYPE_EDGE_BOTH:
+ return rtd1625_gpio_irq_set_edge_type(d, 1);
+
+ case IRQ_TYPE_LEVEL_HIGH:
+ return rtd1625_gpio_irq_set_level_type(d, 0);
+
+ case IRQ_TYPE_LEVEL_LOW:
+ return rtd1625_gpio_irq_set_level_type(d, 1);
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static struct irq_chip rtd1625_iso_gpio_irq_chip = {
+ .name = "rtd1625-gpio",
+ .irq_ack = rtd1625_gpio_ack_irq,
+ .irq_mask = rtd1625_gpio_disable_irq,
+ .irq_unmask = rtd1625_gpio_enable_irq,
+ .irq_set_type = rtd1625_gpio_irq_set_type,
+ .flags = IRQCHIP_IMMUTABLE | IRQCHIP_SKIP_SET_WAKE,
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
+};
+
+static int rtd1625_gpio_setup_irq(struct platform_device *pdev, struct rtd1625_gpio *data)
+{
+ struct gpio_irq_chip *irq_chip;
+ unsigned int num_irqs;
+ int irq;
+
+ /*
+ * Interrupt support is optional. All IRQs must be provided together.
+ * If index 0 is missing, we assume no interrupts are configured in DT
+ * and fall back to basic GPIO operation.
+ */
+ irq = platform_get_irq_optional(pdev, 0);
+ if (irq == -ENXIO)
+ return 0;
+ if (irq < 0)
+ return irq;
+
+ num_irqs = (data->info->irq_type_support & IRQ_TYPE_LEVEL_MASK) ? 3 : 2;
+ data->irqs[RTD1625_IRQ_ASSERT] = irq;
+
+ for (unsigned int i = 1; i < num_irqs; i++) {
+ irq = platform_get_irq(pdev, i);
+ if (irq < 0)
+ return irq;
+ data->irqs[i] = irq;
+ }
+
+ irq_chip = &data->gpio_chip.irq;
+ irq_chip->handler = handle_bad_irq;
+ irq_chip->default_type = IRQ_TYPE_NONE;
+ irq_chip->parent_handler = rtd1625_gpio_irq_handle;
+ irq_chip->parent_handler_data = data;
+ irq_chip->num_parents = num_irqs;
+ irq_chip->parents = data->irqs;
+
+ gpio_irq_chip_set_chip(irq_chip, &rtd1625_iso_gpio_irq_chip);
+
+ return 0;
+}
+
+static int rtd1625_gpio_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct rtd1625_gpio *data;
+ void __iomem *irq_base;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->info = device_get_match_data(dev);
+ if (!data->info)
+ return -EINVAL;
+
+ raw_spin_lock_init(&data->lock);
+
+ irq_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(irq_base))
+ return PTR_ERR(irq_base);
+
+ data->irq_base = irq_base;
+ data->base = irq_base + data->info->base_offset;
+
+ data->save_regs = devm_kcalloc(dev, data->info->num_gpios, sizeof(*data->save_regs),
+ GFP_KERNEL);
+ if (!data->save_regs)
+ return -ENOMEM;
+
+ data->gpio_chip.label = dev_name(dev);
+ data->gpio_chip.base = -1;
+ data->gpio_chip.ngpio = data->info->num_gpios;
+ data->gpio_chip.request = gpiochip_generic_request;
+ data->gpio_chip.free = gpiochip_generic_free;
+ data->gpio_chip.get_direction = rtd1625_gpio_get_direction;
+ data->gpio_chip.direction_input = rtd1625_gpio_direction_input;
+ data->gpio_chip.direction_output = rtd1625_gpio_direction_output;
+ data->gpio_chip.set = rtd1625_gpio_set;
+ data->gpio_chip.get = rtd1625_gpio_get;
+ data->gpio_chip.set_config = rtd1625_gpio_set_config;
+ data->gpio_chip.parent = dev;
+
+ ret = rtd1625_gpio_setup_irq(pdev, data);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, data);
+
+ return devm_gpiochip_add_data(dev, &data->gpio_chip, data);
+}
+
+static const struct rtd1625_gpio_info rtd1625_iso_gpio_info = {
+ .num_gpios = 166,
+ .irq_type_support = IRQ_TYPE_EDGE_BOTH,
+ .base_offset = 0x100,
+ .gpa_offset = 0x000,
+ .gpda_offset = 0x020,
+ .write_en_all = RTD1625_ISO_GPIO_WREN_ALL,
+};
+
+static const struct rtd1625_gpio_info rtd1625_isom_gpio_info = {
+ .num_gpios = 4,
+ .irq_type_support = IRQ_TYPE_EDGE_BOTH | IRQ_TYPE_LEVEL_LOW |
+ IRQ_TYPE_LEVEL_HIGH,
+ .base_offset = 0x20,
+ .gpa_offset = 0x00,
+ .gpda_offset = 0x04,
+ .level_offset = 0x18,
+ .write_en_all = RTD1625_ISOM_GPIO_WREN_ALL,
+};
+
+static int rtd1625_gpio_suspend(struct device *dev)
+{
+ struct rtd1625_gpio *data = dev_get_drvdata(dev);
+ const struct rtd1625_gpio_info *info = data->info;
+
+ for (unsigned int i = 0; i < info->num_gpios; i++)
+ data->save_regs[i] = readl_relaxed(data->base + GPIO_CONTROL(i));
+
+ return 0;
+}
+
+static int rtd1625_gpio_resume(struct device *dev)
+{
+ struct rtd1625_gpio *data = dev_get_drvdata(dev);
+ const struct rtd1625_gpio_info *info = data->info;
+
+ for (unsigned int i = 0; i < info->num_gpios; i++)
+ writel_relaxed(data->save_regs[i] | info->write_en_all,
+ data->base + GPIO_CONTROL(i));
+
+ return 0;
+}
+
+static DEFINE_NOIRQ_DEV_PM_OPS(rtd1625_gpio_pm_ops, rtd1625_gpio_suspend, rtd1625_gpio_resume);
+
+static const struct of_device_id rtd1625_gpio_of_matches[] = {
+ { .compatible = "realtek,rtd1625-iso-gpio", .data = &rtd1625_iso_gpio_info },
+ { .compatible = "realtek,rtd1625-isom-gpio", .data = &rtd1625_isom_gpio_info },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rtd1625_gpio_of_matches);
+
+static struct platform_driver rtd1625_gpio_platform_driver = {
+ .driver = {
+ .name = "gpio-rtd1625",
+ .of_match_table = rtd1625_gpio_of_matches,
+ .pm = pm_sleep_ptr(&rtd1625_gpio_pm_ops),
+ },
+ .probe = rtd1625_gpio_probe,
+};
+module_platform_driver(rtd1625_gpio_platform_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Realtek Semiconductor Corporation");
+MODULE_DESCRIPTION("Realtek DHC SoC RTD1625 gpio driver");
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/4] arm64: dts: realtek: Add GPIO support for RTD1625
From: Yu-Chun Lin @ 2026-06-22 9:23 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai, Bartosz Golaszewski
In-Reply-To: <20260622092335.1166876-1-eleanor.lin@realtek.com>
Add the GPIO node for the Realtek RTD1625 SoC.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v4:
- None.
---
arch/arm64/boot/dts/realtek/kent.dtsi | 39 +++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi b/arch/arm64/boot/dts/realtek/kent.dtsi
index 8d4293cd4c03..228b82dfdb7a 100644
--- a/arch/arm64/boot/dts/realtek/kent.dtsi
+++ b/arch/arm64/boot/dts/realtek/kent.dtsi
@@ -151,6 +151,37 @@ uart0: serial@7800 {
status = "disabled";
};
+ gpio: gpio@31000 {
+ compatible = "realtek,rtd1625-iso-gpio";
+ reg = <0x31000 0x398>;
+ gpio-controller;
+ gpio-ranges = <&isom_pinctrl 0 0 2>,
+ <&ve4_pinctrl 2 0 6>,
+ <&iso_pinctrl 8 0 4>,
+ <&ve4_pinctrl 12 6 2>,
+ <&main2_pinctrl 14 0 2>,
+ <&ve4_pinctrl 16 8 4>,
+ <&main2_pinctrl 20 2 3>,
+ <&ve4_pinctrl 23 12 3>,
+ <&iso_pinctrl 26 4 2>,
+ <&isom_pinctrl 28 2 2>,
+ <&ve4_pinctrl 30 15 6>,
+ <&main2_pinctrl 36 5 6>,
+ <&ve4_pinctrl 42 21 3>,
+ <&iso_pinctrl 45 6 6>,
+ <&ve4_pinctrl 51 24 1>,
+ <&iso_pinctrl 52 12 1>,
+ <&ve4_pinctrl 53 25 11>,
+ <&main2_pinctrl 64 11 28>,
+ <&ve4_pinctrl 92 36 2>,
+ <&iso_pinctrl 94 13 19>,
+ <&iso_pinctrl 128 32 4>,
+ <&ve4_pinctrl 132 38 13>,
+ <&iso_pinctrl 145 36 19>,
+ <&ve4_pinctrl 164 51 2>;
+ #gpio-cells = <2>;
+ };
+
iso_pinctrl: pinctrl@4e000 {
compatible = "realtek,rtd1625-iso-pinctrl";
reg = <0x4e000 0x1a4>;
@@ -161,6 +192,14 @@ main2_pinctrl: pinctrl@4f200 {
reg = <0x4f200 0x50>;
};
+ iso_m_gpio: gpio@89100 {
+ compatible = "realtek,rtd1625-isom-gpio";
+ reg = <0x89100 0x30>;
+ gpio-controller;
+ gpio-ranges = <&isom_pinctrl 0 0 4>;
+ #gpio-cells = <2>;
+ };
+
isom_pinctrl: pinctrl@146200 {
compatible = "realtek,rtd1625-isom-pinctrl";
reg = <0x146200 0x34>;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Yu-Chun Lin @ 2026-06-22 9:23 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, eleanor.lin,
james.tai, Krzysztof Kozlowski
In-Reply-To: <20260622092335.1166876-1-eleanor.lin@realtek.com>
From: Tzuyi Chang <tychang@realtek.com>
Add the device tree bindings for the Realtek DHC (Digital Home Center)
RTD1625 GPIO controllers.
The RTD1625 GPIO controller features a per-pin register architecture
that differs significantly from previous generations. It utilizes
separate register blocks for GPIO configuration and interrupt control.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
Changes in v4:
- None.
---
.../bindings/gpio/realtek,rtd1625-gpio.yaml | 71 +++++++++++++++++++
1 file changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
diff --git a/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
new file mode 100644
index 000000000000..f13c910b73c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Realtek Semiconductor Corporation
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/realtek,rtd1625-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek DHC RTD1625 GPIO controller
+
+maintainers:
+ - Tzuyi Chang <tychang@realtek.com>
+
+description: |
+ GPIO controller for the Realtek RTD1625 SoC, featuring a per-pin register
+ architecture that differs significantly from earlier RTD series controllers.
+ Each GPIO has dedicated registers for configuration (direction, input/output
+ values, debounce), and interrupt control supporting edge and level detection
+ modes.
+
+properties:
+ compatible:
+ enum:
+ - realtek,rtd1625-iso-gpio
+ - realtek,rtd1625-isom-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Interrupt number of the assert GPIO interrupt, which is
+ triggered when there is a rising edge.
+ - description: Interrupt number of the deassert GPIO interrupt, which is
+ triggered when there is a falling edge.
+ - description: Interrupt number of the level-sensitive GPIO interrupt,
+ triggered by a configured logic level.
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-ranges: true
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-ranges
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ gpio@89100 {
+ compatible = "realtek,rtd1625-isom-gpio";
+ reg = <0x89100 0x30>;
+ interrupt-parent = <&iso_m_irq_mux>;
+ interrupts = <0>, <1>, <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-ranges = <&isom_pinctrl 0 0 4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v1] arm64: dts: freescale: imx95-toradex-smarc: add alias for lpuart5
From: Francesco Dolcini @ 2026-06-22 9:35 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Francesco Dolcini, devicetree, imx, linux-arm-kernel,
linux-kernel
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add alias for lpuart5 so the UART gets a stable line number.
Without this alias, the lpuart driver fails:
fsl-lpuart 42590000.serial: failed to get alias id, errno -19
This prevents the Bluetooth controller connected to this UART from
working.
Fixes: 104a391bb6ff ("arm64: dts: freescale: imx95-toradex-smarc: Enable bluetooth on lpuart5")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 7d760470201f..a6c5398a81e3 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -24,6 +24,7 @@ aliases {
serial1 = &lpuart1;
serial2 = &lpuart6;
serial3 = &lpuart3;
+ serial4 = &lpuart5;
};
chosen {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v4 1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: sashiko-bot @ 2026-06-22 9:39 UTC (permalink / raw)
To: Yu-Chun Lin; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260622092335.1166876-2-eleanor.lin@realtek.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The binding defines the GPIO controller as an interrupt controller but fails to include `interrupt-controller` and `#interrupt-cells` in the `required` list.
--
commit c069bdfb1e6325b567084e608f2dc45bf15e2fcf
Author: Tzuyi Chang <tychang@realtek.com>
dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
This commit adds the device tree bindings for the Realtek DHC RTD1625 GPIO
controllers. It introduces support for a new per-pin register architecture
that includes separate register blocks for configuration and interrupt control.
> diff --git a/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
> new file mode 100644
> index 0000000000000..f13c910b73c69
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
[ ... ]
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> +
> + gpio-ranges: true
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - gpio-ranges
> + - gpio-controller
> + - "#gpio-cells"
[Severity: Medium]
Since this binding defines the hardware as an interrupt controller, should
interrupt-controller and #interrupt-cells be included in this required list?
Omitting these provider properties might allow incomplete device tree nodes
to pass schema validation, which could then cause runtime failures for
drivers attempting to use the undocumented functionality.
> +
> +additionalProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622092335.1166876-1-eleanor.lin@realtek.com?part=1
^ permalink raw reply
* Re: [PATCH 2/5] iio: adc: Add ti-ads1262 driver
From: Jonathan Cameron @ 2026-06-22 9:47 UTC (permalink / raw)
To: Kurt Borja
Cc: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, Bartosz Golaszewski, David Lechner,
Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, linux-gpio
In-Reply-To: <DJF5ATR2RPDJ.3LSN8DY58E6RO@gmail.com>
On Sun, 21 Jun 2026 19:18:33 -0500
"Kurt Borja" <kuurtb@gmail.com> wrote:
> On Sun Jun 21, 2026 at 9:33 AM -05, Jonathan Cameron wrote:
> > On Mon, 15 Jun 2026 06:30:28 +0200
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> >> On 14/06/2026 22:56, Kurt Borja wrote:
> >> > On Sat Jun 13, 2026 at 1:59 PM -05, Krzysztof Kozlowski wrote:
> >> >
> >> > [...]
> >> >
> >> >> Functions used by probe() should be before probe(), not somewhere in the
> >> >> middle of the code. IOW, entire probe is together.
> >> >
> >> > I they all are, it's just that regmap stuff takes a huge chunk. I'll
> >> > check how to reorganize.
> >> >
> >> > [...]
> >> >
> >> >>> +static const struct of_device_id ads1262_of_match[] = {
> >> >>> + { .compatible = "ti,ads1262" },
> >> >>> + { .compatible = "ti,ads1263" },
> >> >>
> >> >> So devices are fully compatible? Then it should be expressed in the
> >> >> binding and drop one entry here.
> >> >
> >> > Not fully compatible as Jonathan said. One is a subset of the other.
> >>
> >> This is THE meaning of compatible!
> >
> > This one I'm in agreement with. It is a strict subset, so should be
> > using a fallback. If the fallback is used, you just get support of the
> > stuff in the simpler chip (or if you can override it with a chip ID
> > you might still 'upgrade' to the more complex driver support).
> > If you do end up with properties that only apply to 'new' parts of
> > the more complex chip then they should be verified as part of the
> > binding (assuming you can do that without the verifier complaining
> > - I haven't checked!)
>
> In v1 I had the "adc" subnode which was specific to ADS1263. Then I
> agreed to drop the subnode but I'm having second thoughts...
>
> If we dropped it, then we would still have some specific stuff.
> #io-channel-cells would be "const: 2" in ADS1263 chips. Also ADS1263's
> channels would have an extra ti,vref-adc2 prop, for ADC2 voltage
> reference selection. I should maybe also add a vref-adc2-supply.
>
> Maybe it's better to keep the subnode or, again, go for something like:
>
> spi {
> multi-adc@0 {
> adc@0 {
> ...
> vref-suppy = <&adc1-vref>;
>
> channel@0 {
> ...
> reference-source = <ADS1262_VREF_AIN0_AIN1>;
> };
> };
> adc@1 {
> ...
> vref-suppy = <&adc2-vref>;
>
> channel@0 {
> ...
> reference-source = <ADS1262_VREF_AIN2_AIN3>;
> };
> };
> };
> };
>
> In this case we would have to kinda duplicate channel description, but I
> don't think it's that bad.
>
> Jonathan, Krzysztof, David, thoughts?
>
> IMO the ADC2 specific voltage reference stuff is a strong argument for a
> subnode or the above solution.
Given you end up with channel specific stuff that differs I think it probably
makes sense - though I do wonder a bit if that is real. What's the use case
for using a different reference for the monitoring / debug than the main one?
I could imagine some dynamic use where you want to sanity check against
a wider reference range, but maybe that needs userspace control rather than
in here?
Jonathan
>
> >
> > The SLF3F discussion is about (to me) less obvious case of not a strict
> > subset, but rather being detectable parts with different channel related
> > properties. In that case the ID match is necessary for anything to work.
> > Anyhow, that discussion is in a different thread and not really relevant
> > here.
> >
> > Jonathan
> >
> >>
> >>
> >> Best regards,
> >> Krzysztof
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: install DT overlays via dtbs_install
From: Neil Armstrong @ 2026-06-22 9:47 UTC (permalink / raw)
To: Vishwas Udupa, krzk
Cc: andersson, conor+dt, devicetree, kbajaj, konradybcio, krzk+dt,
linux-arm-msm, robh, snb, vudupa
In-Reply-To: <20260615162739.787779-1-vishwas.udupa@oss.qualcomm.com>
Hi Vishwas or Claude ?
On 6/15/26 18:27, Vishwas Udupa wrote:
> EL2 DTBOs are used at build time to construct DTBs corresponding to
> an EL2 (hypervisor-enabled) boot configuration. These DTBs are included in
> distributions [1] as complete boot configurations (e.g. EL1 and EL2).
>
> The EL2 configuration is not enabled by default and is typically selected
> after the initial boot by updating a UEFI runtime variable from userspace.
> Once set, firmware selects the prebuilt EL2 DTB on subsequent boots.
>
> Although EL2 DTBOs are not used directly at runtime during initial boot,
> they are required to generate and package the EL2 DTBs in the image so that
> firmware can switch to EL2 when the configuration variable is enabled. Hence, el2 dtbo's
> need to be retained.
>
> 1: https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/qcom-next-fitimage.its#L273
Pretty sure we can directly ask the question to an AI assistant ourselves,
and I'm rather sure Krzysztof which is maintaining and reviewing DT for years doesn't
need a lesson from Claude or any AI assistant you use to assist you.
Neil
^ permalink raw reply
* Re: [PATCH v4 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: sashiko-bot @ 2026-06-22 9:48 UTC (permalink / raw)
To: Yu-Chun Lin; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260622092335.1166876-4-eleanor.lin@realtek.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Incorrect hardware configuration and filtering for IRQ_TYPE_EDGE_BOTH causes missed falling edges and spurious double-interrupts.
- [High] Unmapped level interrupts are not masked, causing an infinite interrupt storm.
- [High] Clearing the hardware interrupt status in the .irq_unmask callback causes lost edge interrupts.
- [Medium] The driver uses a global raw_spinlock_irqsave for all register accesses, causing severe unnecessary contention.
--
commit 2c67ad7ec485f951d81fe09ef1853cbf7ebd2d95
Author: Tzuyi Chang <tychang@realtek.com>
gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
The RTD1625 introduces a per-pin register architecture with a dedicated
32-bit control register per GPIO line. Interrupt support is optional.
> diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
> new file mode 100644
> index 0000000000000..409e540bf40b3
> --- /dev/null
> +++ b/drivers/gpio/gpio-rtd1625.c
[ ... ]
> +static int rtd1625_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
> +{
> + struct rtd1625_gpio *data = gpiochip_get_data(chip);
> + u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_OUT);
> +
> + if (value)
> + val |= RTD1625_GPIO_OUT;
> +
> + guard(raw_spinlock_irqsave)(&data->lock);
> +
> + writel_relaxed(val, data->base + GPIO_CONTROL(offset));
> +
> + return 0;
> +}
> +
> +static int rtd1625_gpio_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct rtd1625_gpio *data = gpiochip_get_data(chip);
> + u32 val;
> +
> + guard(raw_spinlock_irqsave)(&data->lock);
> +
> + val = readl_relaxed(data->base + GPIO_CONTROL(offset));
[Severity: Medium]
Since the RTD1625 hardware features a dedicated control register per GPIO
line and uses a Write-Enable bitmask design, do we need this global raw
spinlock?
It seems updates to individual bits are independent and atomic, and
readl_relaxed is inherently an atomic bus operation. Does wrapping these
operations in a single global lock across all 166 GPIOs unnecessarily
serialize all GPIO operations globally?
[ ... ]
> +static void rtd1625_gpio_irq_handle(struct irq_desc *desc)
> +{
[ ... ]
> + for_each_set_bit(j, &status, 32) {
> + hwirq = i + j;
> + girq = irq_find_mapping(domain, hwirq);
> + irq_type = irq_get_trigger_type(girq);
[Severity: High]
If a level interrupt fires on a pin that has no mapping (for example, if it
was left enabled by the bootloader), irq_find_mapping() returns 0 and
generic_handle_domain_irq() will return -EINVAL.
Because the child handler is never invoked, the active level interrupt is
never cleared or masked. Once the parent IRQ is unmasked, will the pending
level interrupt immediately re-trigger and cause an interrupt storm?
> +
> + /*
> + * Filter out the hardware-forced de-assert interrupt unless
> + * the user explicitly requested IRQ_TYPE_EDGE_BOTH.
> + */
> + if (irq == data->irqs[RTD1625_IRQ_DEASSERT] &&
> + irq_type != IRQ_TYPE_EDGE_BOTH)
> + continue;
> +
> + generic_handle_domain_irq(domain, hwirq);
> + }
[Severity: High]
For IRQ_TYPE_EDGE_BOTH, does this filter intentionally let the duplicate
de-assert interrupt through?
Due to the hardware quirk where a single edge triggers both the assert and
de-assert IRQ lines, it appears this would cause generic_handle_domain_irq()
to be called twice sequentially for the exact same physical rising edge.
[ ... ]
> +static void rtd1625_gpio_enable_edge_irq(struct rtd1625_gpio *data, irq_hw_number_t hwirq)
> +{
> + int gpda_reg_offset = rtd1625_gpio_gpda_offset(data, hwirq);
> + int gpa_reg_offset = rtd1625_gpio_gpa_offset(data, hwirq);
> + u32 clr_mask = BIT(hwirq % 32);
> + u32 val;
> +
> + guard(raw_spinlock_irqsave)(&data->lock);
> +
> + writel_relaxed(clr_mask, data->irq_base + gpa_reg_offset);
> + writel_relaxed(clr_mask, data->irq_base + gpda_reg_offset);
> + val = RTD1625_GPIO_EDGE_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
> + writel_relaxed(val, data->base + GPIO_CONTROL(hwirq));
> +}
[Severity: High]
This explicitly clears any pending hardware interrupts. Since this function
is called via the irq_unmask callback (mapped to rtd1625_gpio_enable_irq),
will this cause edge interrupts to be permanently lost if a hardware edge
occurs while the IRQ is temporarily masked?
Could status clearing be restricted to irq_startup or irq_ack?
[ ... ]
> +static int rtd1625_gpio_irq_set_type(struct irq_data *d, unsigned int type)
> +{
> + switch (type & IRQ_TYPE_SENSE_MASK) {
> + case IRQ_TYPE_EDGE_RISING:
> + return rtd1625_gpio_irq_set_edge_type(d, 1);
> +
> + case IRQ_TYPE_EDGE_FALLING:
> + return rtd1625_gpio_irq_set_edge_type(d, 0);
> +
> + case IRQ_TYPE_EDGE_BOTH:
> + return rtd1625_gpio_irq_set_edge_type(d, 1);
[Severity: High]
Does this map IRQ_TYPE_EDGE_BOTH to the exact same hardware polarity
configuration as IRQ_TYPE_EDGE_RISING?
It seems the hardware will only detect rising edges and completely miss
falling edges. When combined with the filter in rtd1625_gpio_irq_handle(),
does EDGE_BOTH miss all falling edges and duplicate all rising edges?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622092335.1166876-1-eleanor.lin@realtek.com?part=3
^ permalink raw reply
* Re: [PATCH v6 2/8] dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
From: Qiang Yu @ 2026-06-22 9:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <20260622-legendary-graceful-goat-3b5d56@quoll>
On Mon, Jun 22, 2026 at 09:32:34AM +0200, Krzysztof Kozlowski wrote:
> On Sun, Jun 21, 2026 at 10:11:25PM -0700, Qiang Yu wrote:
> > Mahua shares the same QREF TX/RPT/RX component naming as Glymur, but
> > has a different topology: a single QREF block fed by REFGEN3 only,
> > rather than the two independent blocks fed by REFGEN3 and REFGEN4 on
> > Glymur.
> >
> > Add qcom,mahua-tcsr compatible and document its required supply
> > properties.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > .../bindings/clock/qcom,glymur-tcsr.yaml | 68 ++++++++++++++++------
> > 1 file changed, 50 insertions(+), 18 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> > index 16fc6ab87f9b..2b6422627165 100644
> > --- a/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> > +++ b/Documentation/devicetree/bindings/clock/qcom,glymur-tcsr.yaml
> > @@ -20,7 +20,9 @@ description: |
> > properties:
> > compatible:
> > items:
> > - - const: qcom,glymur-tcsr
> > + - enum:
> > + - qcom,glymur-tcsr
>
> You could have made this enum in the first patch, so you would avoid
> changing the same line twice. Usually adding line in patch #1 and then
> removing it in patch #2 is indication of something to improve.
>
Okay, will use
- enum:
- qcom,glymur-tcsr
in the first patch in next version.
- Qiang Yu
> > + - qcom,mahua-tcsr
> > - const: syscon
> >
> > clocks:
> > @@ -41,9 +43,11 @@ properties:
> > vdda-qrefrpt2-0p9-supply: true
> > vdda-qrefrpt3-0p9-supply: true
> > vdda-qrefrpt4-0p9-supply: true
> > + vdda-qrefrpt5-0p9-supply: true
> > vdda-qrefrx0-0p9-supply: true
> > vdda-qrefrx1-0p9-supply: true
> > vdda-qrefrx2-0p9-supply: true
> > + vdda-qrefrx3-0p9-supply: true
> > vdda-qrefrx4-0p9-supply: true
> > vdda-qrefrx5-0p9-supply: true
> > vdda-qreftx0-0p9-supply: true
> > @@ -54,26 +58,54 @@ properties:
> > vdda-refgen4-0p9-supply: true
> > vdda-refgen4-1p2-supply: true
> >
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: qcom,glymur-tcsr
> > + then:
> > + required:
> > + - vdda-qrefrpt0-0p9-supply
> > + - vdda-qrefrpt1-0p9-supply
> > + - vdda-qrefrpt2-0p9-supply
> > + - vdda-qrefrpt3-0p9-supply
> > + - vdda-qrefrpt4-0p9-supply
> > + - vdda-qrefrx0-0p9-supply
> > + - vdda-qrefrx1-0p9-supply
> > + - vdda-qrefrx2-0p9-supply
> > + - vdda-qrefrx4-0p9-supply
> > + - vdda-qrefrx5-0p9-supply
> > + - vdda-qreftx0-0p9-supply
> > + - vdda-qreftx0-1p2-supply
> > + - vdda-qreftx1-0p9-supply
> > + - vdda-refgen3-0p9-supply
> > + - vdda-refgen3-1p2-supply
> > + - vdda-refgen4-0p9-supply
> > + - vdda-refgen4-1p2-supply
>
> It is fine, although this you could as well keep like that in first
> patch and mention in commit msg, that binding will grow, thus you
> already define if:then: block to accommodate future changes.
>
Okay, I will add the if:then: block in first patch and add some
description in commit msg. Then I also don't need to remove 'Mark the
relevant supplies as required per compatible using allOf/if/then
conditionals' in commit msg of first patch.
- Qiang Yu
^ permalink raw reply
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Geert Uytterhoeven @ 2026-06-22 9:52 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Marc Zyngier, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-3-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Fri, 19 Jun 2026 at 00:04, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The GIC600 implementation is now known to be used on multiple 64-bit
> SoCs, where it has address width for AXI or APB interface configured
> to 32 bit, and it can access only the first 4GiB of physical address
> space.
>
> Rework the handling of the quirk to work around this limitation such
> that new entries can be added purely as new compatible strings, with
> no need to add additional functions or new its_quirk array entries.
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4890,10 +4890,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
> return true;
> }
>
> -static bool __maybe_unused its_enable_rk3568002(void *data)
> +static const char * const dma_32bit_impaired_platforms[] = {
> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> + "rockchip,rk3566",
> + "rockchip,rk3568",
> +#endif
> + NULL,
> +};
> +
> +static bool __maybe_unused its_enable_dma32(void *data)
__maybe_unused can be dropped...
> {
> - if (!of_machine_is_compatible("rockchip,rk3566") &&
> - !of_machine_is_compatible("rockchip,rk3568"))
> + if (!of_machine_compatible_match(dma_32bit_impaired_platforms))
> return false;
>
> gfp_flags_quirk |= GFP_DMA32;
> @@ -4968,14 +4975,12 @@ static const struct gic_quirk its_quirks[] = {
> .property = "dma-noncoherent",
> .init = its_set_non_coherent,
> },
> -#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
... as the #ifdef is removed.
> {
> - .desc = "ITS: Rockchip erratum RK3568002",
> + .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
> .iidr = 0x0201743b,
> .mask = 0xffffffff,
> - .init = its_enable_rk3568002,
> + .init = its_enable_dma32,
> },
> -#endif
> {
> }
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: Jonathan Cameron @ 2026-06-22 9:55 UTC (permalink / raw)
To: David Lechner
Cc: Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kurt Borja, Nguyen Minh Tien, linux-iio, devicetree,
linux-kernel
In-Reply-To: <da875b00-6f93-444b-982c-30b8001dd8e0@baylibre.com>
On Sun, 21 Jun 2026 16:14:57 -0500
David Lechner <dlechner@baylibre.com> wrote:
> On 6/21/26 1:41 PM, Jonathan Cameron wrote:
> > On Mon, 15 Jun 2026 16:59:59 -0500
> > "David Lechner (TI)" <dlechner@baylibre.com> wrote:
> >
> >> Add new bindings for ti,ads122c14 and similar devices.
> >>
> >> This is an ADC that is primarily intended for use with temperature
> >> sensors. There are a few unusual properties because of this. In
> >> particular, the reference voltage source and current output requirements
> >> can be different for each measurement, so these are included in the
> >> channel bindings.
> >>
> >> The REFP/REFN reference voltage is usually just connected to a resistor
> >> that is being driven by the ADC's current outputs, so there is special
> >> property for this case rather than requiring a regulator to be defined
> >> to represent that.
> >>
> >> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
> >> have preferred an enum of strings).
> >>
> >> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
> >
> > A few queries inline though I'm only just starting to get my head
> > around this device...
> >
> > Thanks
> >
> > Jonathan
> >
> >> ---
> >> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
> >> MAINTAINERS | 7 +
> >> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
> >> 3 files changed, 242 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> new file mode 100644
> >> index 000000000000..dc7f37cad772
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> >> @@ -0,0 +1,224 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Texas Instruments' ADS112C14 and similar ADC chips
> >> +
> >> +description: |
> >> + Supports the following Texas Instruments' ADC chips:
> >> + - ADS112C14 (16-bit)
> >> + - ADS122C14 (24-bit)
> >> +
> >> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
> >> +
> >> + These chips are primarily designed for use with temperature sensors such as
> >> + RTDs and thermocouples. The channel bindings reflect this in that each channel
> >> + represents the conditions required to make a measurement rather than strictly
> >> + just the physical input channels.
> >> +
> >> +maintainers:
> >> + - David Lechner <dlechner@baylibre.com>
> >> +
> >> +unevaluatedProperties: false
> >> +
> >> +properties:
> >> + compatible:
> >> + enum:
> >> + - ti,ads112c14
> >> + - ti,ads122c14
> >> +
> >> + reg:
> >> + items:
> >> + - minimum: 0x40
> >> + maximum: 0x47
> >> +
> >> + clocks:
> >> + maxItems: 1
> >> + description: Optional external clock connected to GPIO3 pin.
> >> +
> >> + avdd-supply: true
> >> + dvdd-supply: true
> >> +
> >> + refp-supply: true
> >> + refn-supply: true
> >> +
> >> + refp-refn-resistor-ohms:
> >> + description:
> >> + The resistance of the external resistor between REFP and REFN when using
> >> + resistor bridge driven by current outputs for RTD measurements.
> >> +
> >> + interrupts:
> >> + minItems: 1
> >> + items:
> >> + - description: FAULT interrupt (GPIO2 pin)
> >> + - description: DRDY interrupt (GPIO3 pin)
> >> +
> >> + interrupt-names:
> >> + minItems: 1
> >> + maxItems: 2
> >> + items:
> >> + enum: [fault, drdy]
> >> +
> >> + gpio-controller: true
> >> + '#gpio-cells':
> >> + const: 2
> >> +
> >> + '#address-cells':
> >> + const: 1
> >> +
> >> + '#size-cells':
> >> + const: 0
> >> +
> >> +patternProperties:
> >> + ^channel@[0-7]$:
> >> + $ref: adc.yaml
> >> +
> >> + unevaluatedProperties: false
> >> +
> >> + properties:
> >> + reg:
> >> + maximum: 16 # arbitrary limit, channel@ can be any combination of AIN0-AIN7
> >> +
> >> + single-channel:
> >> + maximum: 7
> >> +
> >> + diff-channels:
> >> + items:
> >> + maximum: 7
> >> +
> >> + bipolar:
> >> + description:
> >> + Set this flag if the differential input can be negative.
> >
> > I'd leave that description to adc.yaml Maybe that doc could be improved though
> > given it basically says bipolar == bipolar mode ;)
>
> It seems not always obvious to me which properties from adc.yaml apply
> and which ones don't to a given ADC that makes use of it. So I was
> hoping to have some way of saying that bipolar is applicable to this
> chip.
bipolar: true
should be enough I think.
>
> >
> >> +
> >> + excitation-channels:
> >> + description: AINx pins used as current output.
> >> + $ref: /schemas/types.yaml#/definitions/uint32-array
> >> + minItems: 1
> >> + maxItems: 2
> >> + items:
> >> + maximum: 7
> >> +
> >> + excitation-current-microamp:
> >
> > There seem to be separate controls. Are their usecases where this needs
> > to be in array?
>
> I'll have to ask, but probably yes since there are separate controls
> so `maxItems: 2` would be appropriate.
>
> >
> >> + description: The current output of the excitation channels in microamps.
> >> + minimum: 1
> >> + maximum: 1000
> >> +
> >> + current-chopping:
> >> + $ref: /schemas/types.yaml#/definitions/flag
> >> + description:
> >> + If provided, the two excitation channels are to be used with current
> >> + chopping enabled.
> >
> > Can I have a reference for that? My initial read suggests it's the input channels
>
> No. :-)
>
> I must have got two ideas mixed together in my head to come up with
> this. Clearly this should be `input-channel-rotation` or something like
> that (we discussed in another thread already). Also curious if you thing
> any of these properties are common enough to promote to adc.yaml or if we
> should just make them e.g. `ti,input-channel-rotation` (you might not have
> had time to read the threads on that yet).
It's turned up in a couple of drivers and the concept is fairly standard I think
so I'm fine with promoting this to a top level property if the definition can
be generic enough.
For a non TI example, the LTC2893 has this as well for it's thermistor settings.
It might be worth comparing the approach given here with what we have there.
In that case there are specific node types for different types of things that
are wired up with constraints on things like excitation currents.
It kind of constrains things to the sane known use cases. However that is
partly because that device does (I think) more type specific handling than
we have here.
>
> > that are chopped. For GC_EN
> > "When enabled, the device automatically swaps
> > the analog inputs and takes the average of two consecutive conversions to
> > cancel the internal offset voltage"
> >
> >
> >> +
> >> + ti,vref-source:
> >> + description: |
> >> + Indicates the source for the reference voltage for this channel.
> >> + 0 - Internal 2.5V reference
> >> + 1 - Internal 1.25V reference
> >> + 2 - External reference (REFP-REFN)
> >> + 3 - AVDD as reference
> >> +
> >> + For convenience, macros for these values are available in
> >> + dt-bindings/iio/adc/ti,ads112c14.h.
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> + maximum: 3
> >> + default: 0
> >> +
> >> + dependencies:
> >> + excitation-channels: [ excitation-current-microamp ]
> >> + excitation-current-microamp: [ excitation-channels ]
> >> + current-chopping: [ excitation-channels ]
> >> +
> >> + oneOf:
> >> + - required: [ single-channel ]
> >> + - required: [ diff-channels ]
> >
> >> +examples:
> >> + - |
> >> + #include <dt-bindings/iio/adc/ti,ads112c14.h>
> >> +
> >> + i2c {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + adc@40 {
> >> + compatible = "ti,ads112c14";
> >> + reg = <0x40>;
> >> +
> >> + avdd-supply = <&avdd>;
> >> + dvdd-supply = <&dvdd>;
> >> +
> >> + /* 3-Wire RTD: Two IDACs, One Measurement (AIN1-AIN2) */
> >> +
> >> + refp-refn-resistor-ohms = <500>;
> >> +
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + channel@0 {
> >> + reg = <0>;
> >> + diff-channels = <1>, <2>;
> >> + excitation-channels = <0>, <3>;
> >> + excitation-current-microamp = <500>;
> >> + current-chopping;
> >> + ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> + label = "rtd";
> >> + };
> >> + };
> >> + };
> >> + - |
> >> + #include <dt-bindings/iio/adc/ti,ads112c14.h>
> >> +
> >> + i2c {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + adc@40 {
> >> + compatible = "ti,ads112c14";
> >> + reg = <0x40>;
> >> +
> >> + avdd-supply = <&avdd>;
> >> + dvdd-supply = <&dvdd>;
> >> +
> >> + /* Resistive Bridge Measurement With a Thermistor for Temperature Compensation*/
> >> +
> >> + refp-supply = <&avdd>;
> >> +
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + channel@0 {
> >> + reg = <0>;
> >> + diff-channels = <6>, <7>;
> >> + bipolar;
> >> + ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> + label = "bridge";
> >> + };
> >> +
> >> + channel@1 {
> >> + reg = <1>;
> >> + diff-channels = <1>, <2>;
> >> + ti,vref-source = <ADS112C14_VREF_SOURCE_INTERNAL_2_5V>;
> >> + label = "thermistor";
> >
> > Hmm. I'm interested to see where this goes, but generally when we have
> > a thermistor we attempt to ultimately convert it to a temperature
> > channel and I'm not seeing info here to allow us to do that.
>
> Since the hardware doesn't have any special features for handling
> specific sensor types, it seems like a case of the driver trying to
> do things that the hardware doesn't do, which we generally try to
> avoid in the kernel.
>
> For cases where we want a quick and easy (and not necessarily accurate)
> temperature conversion done in the kernel, we could make a generic thermistor
> analog front end binding and driver like we already have for RTDs and
> (linear) temperature transducers. This seems more sensible to me rather
> than having to re-implement such a thing in each ADC that could be used
> with a thermistor.
Agreed. That would cover this case. I'll be honest I thought we had
one already ;)
>
> >
> >> + };
> >> + };
> >> + };
> >
> >
>
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: adc: add Axiado SARADC driver
From: Joshua Crofts @ 2026-06-22 9:55 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Akhila Kavi, Prasad Bolisetty, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah, linux-iio, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260622-axiado-ax3000-ax3005-saradc-v3-2-e57c7c7ae675@axiado.com>
On Mon, 22 Jun 2026 00:47:28 -0700
Petar Stepanovic <pstepanovic@axiado.com> wrote:
> Add support for the SARADC controller found on Axiado AX3000 and
> AX3005 SoCs.
>
> The driver supports single-shot voltage reads through the IIO
> subsystem. The number of available input channels is selected from
> the SoC match data, allowing AX3000 and AX3005 variants to use the
> same driver.
>
> Signed-off-by: Petar Stepanovic <pstepanovic@axiado.com>
> ---
> + info->clk_rate = clk_get_rate(info->clk);
> + if (!info->clk_rate)
> + return dev_err_probe(dev, -EINVAL, "invalid clock rate\n");
> +
> + ret = devm_regulator_get_enable_read_voltage(dev, "vref");
> + if (ret < 0)
> + return dev_err_probe(dev, info->vref_uV,
> + "failed to get vref voltage\n");
Sashiko raised an issue that I've missed on previous reads - why
are you using info->vref_uV in dev_err_probe()? The info struct
is not zeroed out on initialization, which means that dev_err_probe
will return a different value each time when read_voltage() fails.
It was designed to accept the retval from whatever function we're
checking.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH v5 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Krzysztof Kozlowski @ 2026-06-22 10:02 UTC (permalink / raw)
To: linux-kernel-dev, Guillaume La Roque, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Conor Dooley
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-1-9040ca36afe2@aliel.fr>
On 24/04/2026 17:45, Ronald Claveau via B4 Relay wrote:
> + - |
> + temperature-sensor@20000 {
> + compatible = "amlogic,t7-thermal";
> + reg = <0x0 0x20000 0x0 0x50>;
> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
This wasn't ever even built! Really, it fails immediately. I will send
fixes, but quite disappointing that contributor does not test its own code.-
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/4] iio: adc: new ti-ads112c14 driver
From: Jonathan Cameron @ 2026-06-22 10:02 UTC (permalink / raw)
To: Kurt Borja
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nguyen Minh Tien, linux-iio,
devicetree, linux-kernel
In-Reply-To: <DJF5LHOE6368.2QCY5LIPT8098@gmail.com>
On Sun, 21 Jun 2026 19:32:29 -0500
"Kurt Borja" <kuurtb@gmail.com> wrote:
> On Sun Jun 21, 2026 at 2:14 PM -05, Jonathan Cameron wrote:
> > On Tue, 16 Jun 2026 13:16:46 -0500
> > David Lechner <dlechner@baylibre.com> wrote:
> >
> >> On 6/16/26 12:26 PM, Kurt Borja wrote:
> >> > On Tue Jun 16, 2026 at 10:21 AM -05, David Lechner wrote:
> >> >> On 6/15/26 7:18 PM, Kurt Borja wrote:
> >> >>> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
> >>
> >> ...
> >>
> >> >>>> All of these chips have in common that they are designed for use with
> >> >>>> RTDs and thermocouples and so they look very similar to each other in
> >> >>>> terms of wiring and feature set, even if the register maps are
> >> >>>> different. They are in the gray area where we could either keep them
> >> >>>> separate because they are just different enough, or we could do like
> >> >>>> we've done before with ad_sigma_delta and have a bit of an abstraction
> >> >>>> layer for the register differences and otherwise try to share as much
> >> >>>> code as possible. Normally, I would lean towards keeping them separate,
> >> >>>> but in this case, I'm considering trying to share code because the
> >> >>>> devicetree bindings for the inputs is complex and is going to be mostly
> >> >>>> the same across all of these chips.
> >> >>>
> >> >>> The channel configuration is indeed very similar for the three chips.
> >> >>> All three have IDAC, BOC and VREF configurations.
> >> >>
> >> >> Hmm... I forgot to include the burnout current in the DT bindings. Following
> >> >> the channel = "conditions for measurement" pattern that I have set out here
> >> >> I guess that would mean that we would need to have the same inputs twice
> >> >> when using the burnout. One "channel" would be the one used to do a "precision"
> >> >> measurement and the other would be the one to do open/short circuit detection.
> >> >>
> >> >>
> >> >> i2c {
> >> >> #address-cells = <1>;
> >> >> #size-cells = <0>;
> >> >>
> >> >> adc@40 {
> >> >> compatible = "ti,ads112c14";
> >> >> reg = <0x40>;
> >> >>
> >> >> avdd-supply = <&avdd>;
> >> >> dvdd-supply = <&dvdd>;
> >> >>
> >> >> refp-supply = <&avdd>;
> >> >>
> >> >> #address-cells = <1>;
> >> >> #size-cells = <0>;
> >> >>
> >> >> channel@0 {
> >> >> reg = <0>;
> >> >> diff-channels = <1>, <2>;
> >> >> excitation-channels = <0>, <3>;
> >> >> excitation-current-microamp = <500>;
> >> >> current-chopping;
> >> >> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> >> label = "rtd-precision";
> >> >> };
> >> >>
> >> >> channel@1 {
> >> >> reg = <0>;
> >> >> diff-channels = <1>, <2>;
> >> >> excitation-channels = <0>, <3>;
> >> >> excitation-current-microamp = <500>;
> > Maybe use an example with more stuff changing? Do we want same excitation
> > for burn out? I've no idea.
> >
> >> >> burnout-current-nanoamp = <1000>;
> >> >> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> >> >> label = "rtd-diagnostic";
> >> >> };
> >> >
> >> > This would mean we wouldn't be able to use iio_chan_spec .channel and
> >> > .channel2 to describe inputs because of duplicate sysfs attributes, no?
> >> >
> >>
> >> Yes, that is a bit unfortunate. At least there the labels to tell them
> >> apart. I guess we would just need to use consecutive channel and channel2
> >> when dynamically allocating the channels to avoid conflict.
> >
> > From a very initial look, maybe do something similar to the folk have
> > been looking at for the more complex DDS devices where we have lots
> > of channels that are on the same 'wires'. Basically add a numbering
> > scheme to keep them reasonably separate - channel numbers are cheap.
> > Maybe first channel is 10->1f, second 20-2f etc. They are differential
> > so it will get ugly. Perhaps have a play around and see if there is
> > a reasonable channel naming scheme for this 'same inputs, different thing
> > being measured case'
>
> May I also suggest having some sort of IIO_VOLTAGE_DIAGNOSTIC channel
> type? Would that be worth the trouble?
Nope. That would get messy fast as any channel type could have a diagnostic
variant. If we only ever want to poll it from sysfs we could use
an info_mask element so in_voltageX_burnoutraw or something like that.
>
> We could also maybe just drop burn-out current completely from
> dt-bindings and add IIO_CHAN_INFO_BURNOUT_CURRENT. Given that this
> feature is only used ocasionally for diagnostic purposes (I assume...).
I did wonder if we just push this either into debugfs, or into an
events type interface. So poll it every now and then or on demand.
>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: thermal: amlogic: Fix missing header in the example
From: Krzysztof Kozlowski @ 2026-06-22 10:02 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ronald Claveau, linux-pm, linux-amlogic, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Usage of defines from headers requires including relevant header,
otherwise dt_binding_check fails:
Lexical error: Documentation/devicetree/bindings/thermal/amlogic,thermal.example.dts:59.27-34 Unexpected 'GIC_SPI'
Lexical error: Documentation/devicetree/bindings/thermal/amlogic,thermal.example.dts:59.38-57 Unexpected 'IRQ_TYPE_LEVEL_HIGH'
Lexical error: Documentation/devicetree/bindings/thermal/amlogic,thermal.example.dts:60.37-45 Unexpected 'CLKID_TS'
Fixes: b1c8ccdbd4e9 ("dt-bindings: thermal: amlogic: Add support for T7")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Fix for current RC - commit already pulled in merge window.
This should be applied fast to fix current RC, thus maybe Rob?
---
Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index e28612510d67..d8f7f3eb7ae2 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -87,6 +87,9 @@ examples:
amlogic,ao-secure = <&sec_AO>;
};
- |
+ #include <dt-bindings/clock/amlogic,t7-peripherals-clkc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
temperature-sensor@20000 {
compatible = "amlogic,t7-thermal";
reg = <0x0 0x20000 0x0 0x50>;
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: thermal: amlogic: Correct 'reg' in the example
From: Krzysztof Kozlowski @ 2026-06-22 10:02 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ronald Claveau, linux-pm, linux-amlogic, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260622100231.438435-3-krzysztof.kozlowski@oss.qualcomm.com>
The example DTS is tested in a wrapped node with address/size-cells=1,
thus reg had incorrect entry leading to dt_binding_check fails:
thermal/amlogic,thermal.example.dtb: temperature-sensor@20000 (amlogic,t7-thermal): reg: [[0, 131072], [0, 80]] is too long
Fixes: b1c8ccdbd4e9 ("dt-bindings: thermal: amlogic: Add support for T7")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index d8f7f3eb7ae2..8cfa44dcda58 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -92,7 +92,7 @@ examples:
temperature-sensor@20000 {
compatible = "amlogic,t7-thermal";
- reg = <0x0 0x20000 0x0 0x50>;
+ reg = <0x20000 0x50>;
interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clkc_periphs CLKID_TS>;
#thermal-sensor-cells = <0>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 3/5] media: i2c: vd55g1: Fix manual digital gain on color variant
From: Jacopo Mondi @ 2026-06-22 10:09 UTC (permalink / raw)
To: Benjamin Mugnier
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <20260428-vd55g4_and_fixes-v1-3-4f745a83b87e@foss.st.com>
Hi Benjamin
On Tue, Apr 28, 2026 at 10:40:57AM +0200, Benjamin Mugnier wrote:
> Apply digital gain to all channels, each channel representing a color.
>
> Fixes: e138e7f00042 ("media: i2c: vd55g1: Add support for vd65g4 RGB variant")
Also cc stable here
>
> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Thanks
j
> ---
> drivers/media/i2c/vd55g1.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
> index e44174056ace..2c962fcb41d2 100644
> --- a/drivers/media/i2c/vd55g1.c
> +++ b/drivers/media/i2c/vd55g1.c
> @@ -60,7 +60,10 @@
> #define VD55G1_PATGEN_ENABLE BIT(0)
> #define VD55G1_REG_MANUAL_ANALOG_GAIN CCI_REG8(0x0501)
> #define VD55G1_REG_MANUAL_COARSE_EXPOSURE CCI_REG16_LE(0x0502)
> -#define VD55G1_REG_MANUAL_DIGITAL_GAIN CCI_REG16_LE(0x0504)
> +#define VD55G1_REG_MANUAL_DIGITAL_GAIN_CH0 CCI_REG16_LE(0x0504)
> +#define VD55G1_REG_MANUAL_DIGITAL_GAIN_CH1 CCI_REG16_LE(0x0506)
> +#define VD55G1_REG_MANUAL_DIGITAL_GAIN_CH2 CCI_REG16_LE(0x0508)
> +#define VD55G1_REG_MANUAL_DIGITAL_GAIN_CH3 CCI_REG16_LE(0x050a)
> #define VD55G1_REG_APPLIED_COARSE_EXPOSURE CCI_REG16_LE(0x00e8)
> #define VD55G1_REG_APPLIED_ANALOG_GAIN CCI_REG16_LE(0x00ea)
> #define VD55G1_REG_APPLIED_DIGITAL_GAIN CCI_REG16_LE(0x00ec)
> @@ -850,9 +853,16 @@ static int vd55g1_update_expo_cluster(struct vd55g1 *sensor, bool is_auto)
> vd55g1_write(sensor, VD55G1_REG_MANUAL_ANALOG_GAIN,
> sensor->again_ctrl->val, &ret);
>
> - if (!is_auto && sensor->dgain_ctrl->is_new)
> - vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN,
> + if (!is_auto && sensor->dgain_ctrl->is_new) {
> + vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN_CH0,
> sensor->dgain_ctrl->val, &ret);
> + vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN_CH1,
> + sensor->dgain_ctrl->val, &ret);
> + vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN_CH2,
> + sensor->dgain_ctrl->val, &ret);
> + vd55g1_write(sensor, VD55G1_REG_MANUAL_DIGITAL_GAIN_CH3,
> + sensor->dgain_ctrl->val, &ret);
> + }
>
> return ret;
> }
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: PCI: qcom: Document the Hawi PCIe Controller
From: Krzysztof Kozlowski @ 2026-06-22 10:12 UTC (permalink / raw)
To: Matthew Leung
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, linux-arm-msm, linux-pci,
devicetree, linux-kernel
In-Reply-To: <20260618-hawi-pcie-v3-1-f31880bfb3ec@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 10:00:32PM +0000, Matthew Leung wrote:
> Add a dedicated schema for the PCIe controllers found on the Hawi
> platform.
>
> Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
> ---
> .../devicetree/bindings/pci/qcom,hawi-pcie.yaml | 202 +++++++++++++++++++++
> 1 file changed, 202 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,hawi-pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,hawi-pcie.yaml
> new file mode 100644
> index 000000000000..fb3145f89f7f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/qcom,hawi-pcie.yaml
> @@ -0,0 +1,202 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/qcom,hawi-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Hawi PCI Express Root Complex
> +
> +maintainers:
> + - Bjorn Andersson <andersson@kernel.org>
> + - Manivannan Sadhasivam <mani@kernel.org>
> +
> +description:
> + Qualcomm Hawi SoC (and compatible) PCIe root complex controller is based on
> + the Synopsys DesignWare PCIe IP.
> +
> +properties:
> + compatible:
> + const: qcom,hawi-pcie
> +
> + reg:
> + minItems: 5
> + items:
> + - description: Qualcomm specific registers
> + - description: DesignWare PCIe registers
> + - description: External local bus interface registers
> + - description: ATU address space
> + - description: PCIe configuration space
> + - description: MHI registers
Why is MHI optional?
> +
> + reg-names:
> + minItems: 5
> + items:
> + - const: parf
> + - const: dbi
> + - const: elbi
> + - const: atu
> + - const: config
> + - const: mhi
> +
> + clocks:
> + minItems: 6
> + items:
> + - description: PCIe Auxiliary clock
> + - description: PCIe Configuration clock
> + - description: PCIe Master AXI clock
> + - description: PCIe Slave AXI clock
> + - description: PCIe Slave Q2A AXI clock
> + - description: PCIe Aggre NoC AXI clock
> + - description: PCIe Config NoC AXI clock
Same here - does that mean that once instance does not have this clock?
If so, mention this in commit msg.
> +
> + clock-names:
> + minItems: 6
> + items:
> + - const: aux
> + - const: cfg
> + - const: bus_master
> + - const: bus_slave
> + - const: slave_q2a
> + - const: noc_aggr
> + - const: cnoc_sf_axi
> +
> + interrupts:
> + minItems: 8
> + maxItems: 9
> +
> + interrupt-names:
> + minItems: 8
> + items:
> + - const: msi0
> + - const: msi1
> + - const: msi2
> + - const: msi3
> + - const: msi4
> + - const: msi5
> + - const: msi6
> + - const: msi7
> + - const: global
Here as well - why is global optional?
> +
> + resets:
> + minItems: 1
Same here?
> + items:
> + - description: PCIe core reset
> + - description: PCIe link down reset
> +
> + reset-names:
> + minItems: 1
> + items:
> + - const: pci
> + - const: link_down
> +
> +required:
> + - power-domains
> + - resets
> + - reset-names
> +
> +allOf:
> + - $ref: qcom,pcie-common.yaml#
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Krzysztof Kozlowski @ 2026-06-22 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
Cc: Krzysztof Kozlowski
There is no use of double colon '::' in YAML. OTOH, the literal style
block, e.g. using '|' treats all characters as content [1] therefore
single use of ':' in descriptions is perfectly fine, whenever '|' is
used.
Cleanup existing code, so the confusing style won't be re-used in new
contributions.
Link: https://yaml.org/spec/1.2.2/#literal-style [1]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I split the patches to avoid bounces from mailing list due to email size.
This can go via clock tree (no dependencies)... or both could go via
Rob's tree.
---
.../devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-apq8084.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-ipq6018.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-ipq8064.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-mdm9607.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-mdm9615.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8660.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8909.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8916.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8953.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8974.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-sdm660.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,ipq5018-gcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,ipq9574-gcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,qca8k-nsscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sm8350-videocc.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,videocc.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos5260-clock.yaml | 6 +++---
.../devicetree/bindings/clock/samsung,exynos5410-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos5433-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos7-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos850-clock.yaml | 2 +-
.../bindings/clock/samsung,exynosautov9-clock.yaml | 2 +-
.../bindings/clock/samsung,exynosautov920-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,s5pv210-clock.yaml | 2 +-
32 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
index 53a5ab319159..6863db9bd092 100644
--- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm display clock control module provides the clocks, resets and power
domains on SM8150/SM8250/SM8350.
- See also::
+ See also:
include/dt-bindings/clock/qcom,dispcc-sm8150.h
include/dt-bindings/clock/qcom,dispcc-sm8250.h
include/dt-bindings/clock/qcom,dispcc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
index 27df7e3e5bf3..68532244901e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on APQ8064.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8960.h
include/dt-bindings/reset/qcom,gcc-msm8960.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
index 0a0a26d9beab..1c022e75fd71 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on APQ8084.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-apq8084.h
include/dt-bindings/reset/qcom,gcc-apq8084.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
index 4d2614d4f368..c7fb84438db7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ6018.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-ipq6018.h
include/dt-bindings/reset/qcom,gcc-ipq6018.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
index a71557395c01..b4d3175780bc 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ8064.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
include/dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
index d7da30b0e7ee..0a7be7583bdd 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-mdm9607.h
allOf:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
index 418dea31eb62..0656d5ee448d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-mdm9615.h
allOf:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
index e03b6d0acdb6..70c9da1f35c2 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks and resets on
MSM8660
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8660.h
include/dt-bindings/reset/qcom,gcc-msm8660.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
index ce1f5a60bd8c..2edb6c251d99 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8909, MSM8917 or QM215.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8909.h
include/dt-bindings/clock/qcom,gcc-msm8917.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
index 258b6b93deca..af4b639ea8c3 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8916 or MSM8939.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8916.h
include/dt-bindings/clock/qcom,gcc-msm8939.h
include/dt-bindings/reset/qcom,gcc-msm8916.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
index ced3118c8580..fc0360554f68 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8937, MSM8940, MSM8953 or SDM439.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8917.h
include/dt-bindings/clock/qcom,gcc-msm8953.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
index 929fafc84c19..378dfe7854ac 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8974 (all variants) and MSM8226.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
include/dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
index 724ce0491118..72aaf699cf70 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on SDM630, SDM636 and SDM660
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660)
$ref: qcom,gcc.yaml#
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index 4cdff6161bf0..3ac4419009a9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm graphics clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gpucc-sdm845.h
include/dt-bindings/clock/qcom,gpucc-sa8775p.h
include/dt-bindings/clock/qcom,gpucc-sc7180.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
index 489d0fc5607c..9925b931ecad 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ5018
- See also::
+ See also:
include/dt-bindings/clock/qcom,ipq5018-gcc.h
include/dt-bindings/reset/qcom,ipq5018-gcc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
index 27ae9938febc..5b128fa841aa 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ9574
- See also::
+ See also:
include/dt-bindings/clock/qcom,ipq9574-gcc.h
include/dt-bindings/reset/qcom,ipq9574-gcc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
index 61473385da2d..3da10c364a85 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm NSS clock control module provides the clocks and resets
on QCA8386(switch mode)/QCA8084(PHY mode)
- See also::
+ See also:
include/dt-bindings/clock/qcom,qca8k-nsscc.h
include/dt-bindings/reset/qcom,qca8k-nsscc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
index 734880805c1b..bedbdabef672 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm graphics clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,qcm2290-gpucc.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
index ab97d4b7dba8..b6c835bfd0d9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h> and
- come in pairs:: FOO_CLK followed by FOO_A_CLK. The latter clock is
+ come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock is
an "active" clock, which means that the consumer only care that the clock is
available when the apps CPU subsystem is active, i.e. not suspended or in
deep idle. If it is important that the clock keeps running during system
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
index 99ab9106009f..fd06ac9bceb9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm LPASS core and audio clock control module provides the clocks and
power domains on SC7280.
- See also::
+ See also:
include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h
include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
index 273d66e245c5..f235b4e24cc7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm LPASS core and audio clock control module provides the clocks,
and reset on SC8280XP.
- See also::
+ See also:
include/dt-bindings/clock/qcom,lpasscc-sc8280xp.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
index 8cbab3fbb660..d7e1938b5e1b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm LPASS core and audio clock controllers provide audio-related resets
on SM6115 and its derivatives.
- See also::
+ See also:
include/dt-bindings/clock/qcom,sm6115-lpasscc.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
index 5c2ecec0624e..a986ab4ce7c7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm video clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,videocc-sm8350.h
include/dt-bindings/reset/qcom,videocc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
index f4ff9acef9d5..124d259fc85e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm video clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,sm6350-videocc.h
include/dt-bindings/clock/qcom,videocc-sc7180.h
include/dt-bindings/clock/qcom,videocc-sc7280.h
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
index b05f83533e3d..56ab972c3da5 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
@@ -14,17 +14,17 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
- "xrtcxti" - input clock from XRTCXTI
- "ioclk_pcm_extclk" - pcm external operation clock
- "ioclk_spdif_extclk" - spdif external operation clock
- "ioclk_i2s_cdclk" - i2s0 codec clock
- Phy clocks::
+ Phy clocks:
There are several clocks which are generated by specific PHYs. These clocks
are fed into the clock controller and then routed to the hardware blocks.
- These clocks are defined as fixed clocks in the driver with following names::
+ These clocks are defined as fixed clocks in the driver with following names:
- "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3
- "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2
- "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
index b737c9d35a1c..1d907dd8fbf1 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
index 3f9326e09f79..8a289f1e2ace 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "oscclk" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
index c137c6744ef9..a51cd4fafb41 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
index cdc5ded59fe5..68c2fd318765 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
@@ -17,7 +17,7 @@ description: |
Exynos850 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external
+ two external clocks: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external
clocks must be defined as fixed-rate clocks in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
index 32f39e543b36..e9d17d48b4f3 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
@@ -17,7 +17,7 @@ description: |
Exynos Auto v9 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK/XTCXO (26 MHz) and RTCCLK/XrtcXTI (32768 Hz).
+ two external clocks: OSCCLK/XTCXO (26 MHz) and RTCCLK/XrtcXTI (32768 Hz).
The external OSCCLK must be defined as fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
index 6b1fc61a2ff9..475db824d4d3 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
@@ -17,7 +17,7 @@ description: |
ExynosAuto v920 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
+ two external clocks: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
The external OSCCLK must be defined as fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
index 67a33665cf00..b1617d96d3fb 100644
--- a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "xxti" - external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti" - external crystal oscillator connected to XUSBXTI and XUSBXTO
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Krzysztof Kozlowski @ 2026-06-22 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
Cc: Krzysztof Kozlowski
In-Reply-To: <20260622101606.485961-3-krzysztof.kozlowski@oss.qualcomm.com>
There is no use of double colon '::' in YAML. OTOH, the literal style
block, e.g. using '|' treats all characters as content [1] therefore
single use of ':' in descriptions is perfectly fine, whenever '|' is
used.
Cleanup existing code, so the confusing style won't be re-used in new
contributions.
Link: https://yaml.org/spec/1.2.2/#literal-style [1]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Intention for this patch is to go via Rob's tree.
---
.../devicetree/bindings/arm/qcom-soc.yaml | 4 ++--
.../devicetree/bindings/arm/qcom.yaml | 4 ++--
.../bindings/arm/samsung/samsung-soc.yaml | 4 ++--
.../display/msm/dsi-controller-main.yaml | 20 +++++++++----------
.../display/samsung/samsung,fimd.yaml | 4 ++--
.../bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +-
.../interconnect/qcom,msm8998-bwmon.yaml | 2 +-
.../interconnect/samsung,exynos-bus.yaml | 14 ++++++-------
.../bindings/leds/qcom,pm8058-led.yaml | 4 ++--
.../bindings/leds/skyworks,aat1290.yaml | 6 +++---
.../bindings/media/cec/cec-gpio.yaml | 2 +-
.../bindings/mmc/samsung,exynos-dw-mshc.yaml | 2 +-
.../devicetree/bindings/mux/mux-consumer.yaml | 4 ++--
.../bindings/phy/samsung,mipi-video-phy.yaml | 4 ++--
.../bindings/phy/samsung,usb2-phy.yaml | 2 +-
.../bindings/phy/samsung,usb3-drd-phy.yaml | 2 +-
.../bindings/pinctrl/samsung,pinctrl.yaml | 2 +-
.../bindings/power/renesas,rcar-sysc.yaml | 2 +-
.../bindings/power/reset/restart-handler.yaml | 8 ++++----
.../bindings/regulator/maxim,max77802.yaml | 4 ++--
.../bindings/regulator/richtek,rtq2208.yaml | 2 +-
.../bindings/serial/qcom,msm-uartdm.yaml | 2 +-
.../devicetree/bindings/slimbus/slimbus.yaml | 4 ++--
.../bindings/soc/qcom/qcom,apr-services.yaml | 2 +-
.../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 8 ++++----
.../bindings/soc/qcom/qcom,wcnss.yaml | 2 +-
.../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
.../bindings/sound/qcom,q6asm-dais.yaml | 2 +-
.../thermal/samsung,exynos-thermal.yaml | 4 ++--
.../devicetree/bindings/usb/qcom,dwc3.yaml | 12 +++++------
.../bindings/usb/qcom,snps-dwc3.yaml | 12 +++++------
31 files changed, 75 insertions(+), 75 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
index 27261039d56f..37fdd5a080b7 100644
--- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
@@ -11,10 +11,10 @@ maintainers:
description: |
Guidelines for new compatibles for SoC blocks/components.
- When adding new compatibles in new bindings, use the format::
+ When adding new compatibles in new bindings, use the format:
qcom,SoC-IP
- For example::
+ For example:
qcom,sdm845-llcc-bwmon
When adding new compatibles to existing bindings, use the format in the
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..667607ae2c32 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1215,7 +1215,7 @@ properties:
items:
items:
- description: |
- MSM chipset ID - an exact match value consisting of two bitfields::
+ MSM chipset ID - an exact match value consisting of two bitfields:
- bits 0-15 - The unique MSM chipset ID
- bits 16-31 - Reserved; should be 0
- description: |
@@ -1241,7 +1241,7 @@ properties:
- items:
- items:
- description: |
- Board ID consisting of three bitfields::
+ Board ID consisting of three bitfields:
- bits 31-24 - Unused
- bits 23-16 - Platform Version Major
- bits 15-8 - Platform Version Minor
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
index 653f85997643..ab000befe76d 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
@@ -11,10 +11,10 @@ maintainers:
description: |
Guidelines for new compatibles for SoC blocks/components.
- When adding new compatibles in new bindings, use the format::
+ When adding new compatibles in new bindings, use the format:
samsung,SoC-IP
- For example::
+ For example:
samsung,exynos5433-cmu-isp
select:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index dbc0613e427e..395425a70db8 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -73,16 +73,16 @@ properties:
clocks:
description: |
- Several clocks are used, depending on the variant. Typical ones are::
- - bus:: Display AHB clock.
- - byte:: Display byte clock.
- - byte_intf:: Display byte interface clock.
- - core:: Display core clock.
- - core_mss:: Core MultiMedia SubSystem clock.
- - iface:: Display AXI clock.
- - mdp_core:: MDP Core clock.
- - mnoc:: MNOC clock
- - pixel:: Display pixel clock.
+ Several clocks are used, depending on the variant. Typical ones are:
+ - bus: Display AHB clock.
+ - byte: Display byte clock.
+ - byte_intf: Display byte interface clock.
+ - core: Display core clock.
+ - core_mss: Core MultiMedia SubSystem clock.
+ - iface: Display AXI clock.
+ - mdp_core: MDP Core clock.
+ - mnoc: MNOC clock
+ - pixel: Display pixel clock.
minItems: 3
maxItems: 12
diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
index ff685031bb2c..729705f419bb 100644
--- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
@@ -41,7 +41,7 @@ properties:
additionalProperties: false
description: |
Timing configuration for lcd i80 interface support.
- The parameters are defined as::
+ The parameters are defined as:
VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|??
: : : : :
Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX
@@ -132,7 +132,7 @@ patternProperties:
"^port@[0-4]+$":
$ref: /schemas/graph.yaml#/properties/port
description: |
- Contains ports with port with index::
+ Contains ports with port with index:
0 - for CAMIF0 input,
1 - for CAMIF1 input,
2 - for CAMIF2 input,
diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
index a2ddc6803617..07600b49f2f9 100644
--- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
@@ -35,7 +35,7 @@ properties:
gpios:
description: |
- The order of the GPIOs should be the following:: <SDA, SCL>. The GPIO
+ The order of the GPIOs should be the following: <SDA, SCL>. The GPIO
specifier depends on the gpio controller. Required in all cases except
for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are
permanently wired to the respective client.
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
index ff64225e8281..e002e70580f9 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
@@ -13,7 +13,7 @@ description: |
Bandwidth Monitor measures current throughput on buses between various NoC
fabrics and provides information when it crosses configured thresholds.
- Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845::
+ Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845:
- Measuring the bandwidth between CPUs and Last Level Cache Controller -
called just BWMON,
- Measuring the bandwidth between Last Level Cache Controller and memory
diff --git a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
index 5e26e48c7217..0203959c8995 100644
--- a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
+++ b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
@@ -23,7 +23,7 @@ description: |
The each AXI bus has the owned source clock but, has not the only owned power
line. The power line might be shared among one more sub-blocks. So, we can
divide into two type of device as the role of each sub-block. There are two
- type of bus devices as following::
+ type of bus devices as following:
- parent bus device
- passive bus device
@@ -44,8 +44,8 @@ description: |
able to support the bus frequency for all Exynos SoCs.
Detailed correlation between sub-blocks and power line according
- to Exynos SoC::
- - In case of Exynos3250, there are two power line as following::
+ to Exynos SoC:
+ - In case of Exynos3250, there are two power line as following:
VDD_MIF |--- DMC (Dynamic Memory Controller)
VDD_INT |--- LEFTBUS (parent device)
@@ -89,7 +89,7 @@ description: |
|L5 |200000 |200000 |400000 |300000 | ||1000000 |
----------------------------------------------------------
- - In case of Exynos4210, there is one power line as following::
+ - In case of Exynos4210, there is one power line as following:
VDD_INT |--- DMC (parent device, Dynamic Memory Controller)
|--- LEFTBUS
|--- PERIL
@@ -106,7 +106,7 @@ description: |
|--- LCD0
|--- LCD1
- - In case of Exynos4x12, there are two power line as following::
+ - In case of Exynos4x12, there are two power line as following:
VDD_MIF |--- DMC (Dynamic Memory Controller)
VDD_INT |--- LEFTBUS (parent device)
@@ -124,7 +124,7 @@ description: |
|--- LCD0
|--- ISP
- - In case of Exynos5422, there are two power line as following::
+ - In case of Exynos5422, there are two power line as following:
VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
|--- DREX 1
@@ -143,7 +143,7 @@ description: |
|--- FSYS
|--- FSYS2
- - In case of Exynos5433, there is VDD_INT power line as following::
+ - In case of Exynos5433, there is VDD_INT power line as following:
VDD_INT |--- G2D (parent device)
|--- MSCL
|--- GSCL
diff --git a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
index b409b2a8b5c5..5165bfddcd54 100644
--- a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
+++ b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
@@ -10,10 +10,10 @@ maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
- The Qualcomm PM8058 contains an LED block for up to six LEDs:: three normal
+ The Qualcomm PM8058 contains an LED block for up to six LEDs: three normal
LEDs, two "flash" LEDs and one "keypad backlight" LED. The names are quoted
because sometimes these LED drivers are used for wildly different things than
- flash or keypad backlight:: their names are more of a suggestion than a
+ flash or keypad backlight: their names are more of a suggestion than a
hard-wired usecase.
Hardware-wise the different LEDs support slightly different output currents.
diff --git a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
index a6aaa92dbccd..65576dfdca11 100644
--- a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
+++ b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
@@ -11,7 +11,7 @@ maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
- The device is controlled through two pins:: FL_EN and EN_SET. The pins when,
+ The device is controlled through two pins: FL_EN and EN_SET. The pins when,
asserted high, enable flash strobe and movie mode (max 1/2 of flash current)
respectively. In order to add a capability of selecting the strobe signal
source (e.g. CPU or camera sensor) there is an additional switch required,
@@ -39,11 +39,11 @@ properties:
flash-max-microamp:
description: |
Maximum flash LED supply current can be calculated using following
- formula:: I = 1A * 162 kOhm / Rset.
+ formula: I = 1A * 162 kOhm / Rset.
flash-max-timeout-us:
description: |
- Maximum flash timeout can be calculated using following formula::
+ Maximum flash timeout can be calculated using following formula:
T = 8.82 * 10^9 * Ct.
required:
diff --git a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
index 582c6c9cae48..21118e4bae0f 100644
--- a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
+++ b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
@@ -14,7 +14,7 @@ description: |
hooked up to a pull-up GPIO line and - optionally - the HPD line is hooked up
to another GPIO line.
- Please note:: the maximum voltage for the CEC line is 3.63V, for the HPD and
+ Please note: the maximum voltage for the CEC line is 3.63V, for the HPD and
5V lines it is 5.3V. So you may need some sort of level conversion
circuitry when connecting them to a GPIO line.
diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
index 27c4060f2f91..223fcc9f651f 100644
--- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
@@ -85,7 +85,7 @@ properties:
description: |
The value of CIU TX and RX clock phase shift value for HS400 mode
operation.
- Valid values for SDR and DDR CIU clock timing::
+ Valid values for SDR and DDR CIU clock timing:
- valid value for tx phase shift and rx phase shift is 0 to 7.
- when CIU clock divider value is set to 3, all possible 8 phase shift
values can be used.
diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
index 9e2d78a78e40..769243a2bf04 100644
--- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
+++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
@@ -13,8 +13,8 @@ description: |
Mux controller consumers should specify a list of mux controllers that they
want to use with a property containing a 'mux-ctrl-list':
- mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
- single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
+ mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
+ single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
mux-ctrl-phandle : phandle to mux controller node
mux-ctrl-specifier : array of #mux-control-cells specifying the
given mux controller (controller specific)
diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
index 16967ef8e9ec..87b6a35b2626 100644
--- a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
@@ -13,14 +13,14 @@ maintainers:
description: |
For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the
- PHY specifier identifies the PHY and its meaning is as follows::
+ PHY specifier identifies the PHY and its meaning is as follows:
0 - MIPI CSIS 0,
1 - MIPI DSIM 0,
2 - MIPI CSIS 1,
3 - MIPI DSIM 1.
samsung,exynos5420-mipi-video-phy and samsung,exynos5433-mipi-video-phy
- support additional fifth PHY::
+ support additional fifth PHY:
4 - MIPI CSIS 2.
properties:
diff --git a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
index d9f22a801cbf..7db7605a82e2 100644
--- a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
The first phandle argument in the PHY specifier identifies the PHY, its
meaning is compatible dependent. For the currently supported SoCs (Exynos4210
- and Exynos4212) it is as follows::
+ and Exynos4212) it is as follows:
0 - USB device ("device"),
1 - USB host ("host"),
2 - HSIC0 ("hsic0"),
diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
index 4562e0468f4f..a1b3d9e6a094 100644
--- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
compatible PHYs, the second cell in the PHY specifier identifies the
- PHY id, which is interpreted as follows::
+ PHY id, which is interpreted as follows:
0 - UTMI+ type phy,
1 - PIPE3 type phy.
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 7b006009ca0e..5e35686eeed3 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -18,7 +18,7 @@ description: |
All the pin controller nodes should be represented in the aliases node using
the following format 'pinctrl{n}' where n is a unique number for the alias.
- The controller supports three types of interrupts::
+ The controller supports three types of interrupts:
- External GPIO interrupts (see interrupts property in pin controller node);
- External wake-up interrupts - multiplexed (capable of waking up the system
diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
index 347571e2545a..b67aa170b2c1 100644
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
@@ -13,7 +13,7 @@ maintainers:
description: |
The R-Car (RZ/G) System Controller provides power management for the CPU
cores and various coprocessors.
- The power domain IDs for consumers are defined in header files::
+ The power domain IDs for consumers are defined in header files:
include/dt-bindings/power/r8*-sysc.h
properties:
diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
index 965a834a3dbe..00c00ec5ec81 100644
--- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
+++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
@@ -18,12 +18,12 @@ properties:
priority:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
- A priority ranging from 0 to 255 according to the following guidelines::
- 0:: Restart handler of last resort, with limited restart capabilities.
- 128:: Typical, default restart handler; use if no other restart handler
+ A priority ranging from 0 to 255 according to the following guidelines:
+ 0: Restart handler of last resort, with limited restart capabilities.
+ 128: Typical, default restart handler; use if no other restart handler
is expected to be available, and/or if restart functionality is
sufficient to restart the entire system.
- 255:: Highest priority restart handler, will preempt all other restart handlers.
+ 255: Highest priority restart handler, will preempt all other restart handlers.
minimum: 0
maximum: 255
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
index b704f05ea454..b886495c1396 100644
--- a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
+++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
@@ -22,13 +22,13 @@ description: |
Certain regulators support "regulator-initial-mode" and "regulator-mode".
The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h
- and their meaning is::
+ and their meaning is:
1 - Normal regulator voltage output mode.
3 - Low Power which reduces the quiescent current down to only 1uA
The standard "regulator-mode" property can only be used for regulators that
support changing their mode to Low Power Mode during suspend. These
- regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
+ regulators are: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
regulator has been enabled for the given suspend state using
"regulator-on-in-suspend" and has not been disabled for that state using
"regulator-off-in-suspend".
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
index 022c1f197364..b0aa38edf8c2 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
@@ -21,7 +21,7 @@ description: |
conduction mode (FCCM).
The definition of modes is in the datasheet which is available in below link
- and their meaning is::
+ and their meaning is:
0 - Auto mode for power saving, which reducing the switching frequency at light load condition
to maintain high frequency.
1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
index 788ef5c1c446..bc967ead2350 100644
--- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
+++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
@@ -17,7 +17,7 @@ description: |
software perspective it's mostly compatible with the MSM serial UART except
that it supports reading and writing multiple characters at a time.
- Note:: Aliases may be defined to ensure the correct ordering of the UARTs.
+ Note: Aliases may be defined to ensure the correct ordering of the UARTs.
The alias serialN will result in the UART being assigned port N. If any
serialN alias exists, then an alias must exist for each enabled UART. The
serialN aliases should be in a .dts file instead of in a .dtsi file.
diff --git a/Documentation/devicetree/bindings/slimbus/slimbus.yaml b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
index 5a941610ce4e..3910327c8ded 100644
--- a/Documentation/devicetree/bindings/slimbus/slimbus.yaml
+++ b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
@@ -29,7 +29,7 @@ patternProperties:
description: |
Every SLIMbus controller node can contain zero or more child nodes
representing slave devices on the bus. Every SLIMbus slave device is
- uniquely determined by the enumeration address containing 4 fields::
+ uniquely determined by the enumeration address containing 4 fields:
Manufacturer ID, Product code, Device index, and Instance value for the
device.
@@ -48,7 +48,7 @@ patternProperties:
reg:
maxItems: 1
description: |
- Pair of (device index, instande ID), where::
+ Pair of (device index, instande ID), where:
- Device index, which uniquely identifies multiple devices within a
single component.
- Instance ID, can be used for the cases where multiple devices of
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
index bdf482db32aa..b663be3ea5a1 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
@@ -40,7 +40,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/string-array
description: |
Protection domain service name and path for APR service (if supported).
- Possible values are::
+ Possible values are:
"avs/audio", "msm/adsp/audio_pd".
"kernel/elf_loader", "msm/modem/wlan_pd".
"tms/servreg", "msm/adsp/audio_pd".
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
index 26d9bc773ec5..1889139a3f7a 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
@@ -23,7 +23,7 @@ description: |
with a few variations that are captured by the properties here.
A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
- have powered off to facilitate idle power saving. TCS could be classified as::
+ have powered off to facilitate idle power saving. TCS could be classified as:
ACTIVE - Triggered by Linux
SLEEP - Triggered by F/W
WAKE - Triggered by F/W
@@ -76,7 +76,7 @@ properties:
items:
items:
- description: |
- TCS type::
+ TCS type:
- ACTIVE_TCS
- SLEEP_TCS
- WAKE_TCS
@@ -152,7 +152,7 @@ examples:
- |
// For a TCS whose RSC base address is 0x179C0000 and is at a DRV id of
// 2, the register offsets for DRV2 start at 0D00, the register
- // calculations are like this::
+ // calculations are like this:
// DRV0: 0x179C0000
// DRV2: 0x179C0000 + 0x10000 = 0x179D0000
// DRV2: 0x179C0000 + 0x10000 * 2 = 0x179E0000
@@ -182,7 +182,7 @@ examples:
- |
// For a TCS whose RSC base address is 0xAF20000 and is at DRV id of 0, the
// register offsets for DRV0 start at 01C00, the register calculations are
- // like this::
+ // like this:
// DRV0: 0xAF20000
// TCS-OFFSET: 0x1C00
#include <dt-bindings/interrupt-controller/arm-gic.h>
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
index 4fcae6bedfff..72a7f8cb09ba 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
@@ -28,7 +28,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
Reference to a node specifying the wcnss "ccu" and "dxe" register blocks.
- The node must be compatible with one of the following::
+ The node must be compatible with one of the following:
- qcom,riva"
- qcom,pronto"
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
index 5ddd31f30f26..57c9d3c57021 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
@@ -12,10 +12,10 @@ maintainers:
description: |
Guidelines for new compatibles for SoC blocks/components.
- When adding new compatibles in new bindings, use the format::
+ When adding new compatibles in new bindings, use the format:
renesas,SoC-IP
- For example::
+ For example:
renesas,r8a77965-csi2
When adding new compatibles to existing bindings, use the format in the
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
index 47a105a97ecf..bc8c8ba24f9c 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
@@ -45,7 +45,7 @@ patternProperties:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
description: |
- The direction of the dai stream::
+ The direction of the dai stream:
- Q6ASM_DAI_TX_RX (0) for both tx and rx
- Q6ASM_DAI_TX (1) for only tx (Capture/Encode)
- Q6ASM_DAI_RX (2) for only rx (Playback/Decode)
diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
index 29a08b0729ee..3f333db72a71 100644
--- a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
@@ -40,7 +40,7 @@ properties:
description: |
The Exynos TMU supports generating interrupts when reaching given
temperature thresholds. Number of supported thermal trip points depends
- on the SoC (only first trip points defined in DT will be configured)::
+ on the SoC (only first trip points defined in DT will be configured):
- most of SoC: 4
- samsung,exynos5433-tmu: 8
- samsung,exynos7-tmu: 8
@@ -52,7 +52,7 @@ properties:
- description: |
Shared TMU registers.
- Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ Note: On Exynos5420, the TRIMINFO register is misplaced for TMU
channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in
cases, there is a misplaced register, also provide clock to access
that base.
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index a7f58114c02e..90daee616880 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -92,14 +92,14 @@ properties:
clocks:
description: |
- Several clocks are used, depending on the variant. Typical ones are::
- - cfg_noc:: System Config NOC clock.
- - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
+ Several clocks are used, depending on the variant. Typical ones are:
+ - cfg_noc: System Config NOC clock.
+ - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
60MHz for HS operation.
- - iface:: System bus AXI clock.
- - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
+ - iface: System bus AXI clock.
+ - sleep: Sleep clock, used for wakeup when USB3 core goes into low
power mode (U3).
- - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
+ - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
mode. Its frequency should be 19.2MHz.
minItems: 1
maxItems: 9
diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
index 8201656b41ed..d99af9f413d0 100644
--- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
@@ -87,14 +87,14 @@ properties:
clocks:
description: |
- Several clocks are used, depending on the variant. Typical ones are::
- - cfg_noc:: System Config NOC clock.
- - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
+ Several clocks are used, depending on the variant. Typical ones are:
+ - cfg_noc: System Config NOC clock.
+ - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
60MHz for HS operation.
- - iface:: System bus AXI clock.
- - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
+ - iface: System bus AXI clock.
+ - sleep: Sleep clock, used for wakeup when USB3 core goes into low
power mode (U3).
- - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
+ - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
mode. Its frequency should be 19.2MHz.
minItems: 1
maxItems: 9
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 4/5] media: i2c: vd55g1: Add support for vd55g4
From: Jacopo Mondi @ 2026-06-22 10:16 UTC (permalink / raw)
To: Benjamin Mugnier
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <20260428-vd55g4_and_fixes-v1-4-4f745a83b87e@foss.st.com>
Hi Benjamin
On Tue, Apr 28, 2026 at 10:40:58AM +0200, Benjamin Mugnier wrote:
> vd55g4 is the same device as vd65g4 but outputs in monochrome instead of
> RGB. Adapt the driver structure according to this new variant, and add
> its support.
>
> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
> ---
> drivers/media/i2c/vd55g1.c | 110 ++++++++++++++++++++++++++++++---------------
> 1 file changed, 74 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
> index 2c962fcb41d2..9f62fc0428a1 100644
> --- a/drivers/media/i2c/vd55g1.c
> +++ b/drivers/media/i2c/vd55g1.c
> @@ -29,11 +29,7 @@
>
> /* Register Map */
> #define VD55G1_REG_MODEL_ID CCI_REG32_LE(0x0000)
> -#define VD55G1_MODEL_ID_VD55G1 0x53354731 /* Mono */
> -#define VD55G1_MODEL_ID_VD65G4 0x53354733 /* RGB */
> -#define VD55G1_REG_REVISION CCI_REG16_LE(0x0004)
> -#define VD55G1_REVISION_CCB 0x2020
> -#define VD55G1_REVISION_BAYER 0x3030
> +#define VD55G1_REG_COLOR_VERSION CCI_REG32_LE(0x0670)
> #define VD55G1_REG_FWPATCH_REVISION CCI_REG16_LE(0x0012)
> #define VD55G1_REG_FWPATCH_START_ADDR CCI_REG8(0x2000)
> #define VD55G1_REG_SYSTEM_FSM CCI_REG8(0x001c)
> @@ -138,8 +134,39 @@
> #define VD55G1_MIPI_RATE_MIN (250 * MEGA)
> #define VD55G1_MIPI_RATE_MAX (1200 * MEGA)
>
> -#define VD55G1_MODEL_ID_NAME(id) \
> - ((id) == VD55G1_MODEL_ID_VD55G1 ? "vd55g1" : "vd65g4")
> +enum vd55g1_model_id {
> + VD55G1_MODEL_ID_2 = 0x53354731,
> + VD55G1_MODEL_ID_3 = 0x53354733,
> +};
> +
> +enum vd55g1_color_version {
> + VD55G1_COLOR_VERSION_MONO = 0x0,
> + VD55G1_COLOR_VERSION_BAYER = 0x1,
nit: you don't need to initialize the enum members here
> +};
> +
> +struct vd55g1_version {
> + char *name;
> + enum vd55g1_model_id id;
> + enum vd55g1_color_version color;
> +};
> +
> +static const struct vd55g1_version vd55g1_versions[] = {
> + {
> + .name = "vd55g1",
> + .id = VD55G1_MODEL_ID_2,
> + .color = VD55G1_COLOR_VERSION_MONO,
> + },
> + {
> + .name = "vd55g4",
> + .id = VD55G1_MODEL_ID_3,
> + .color = VD55G1_COLOR_VERSION_MONO,
> + },
> + {
> + .name = "vd65g4",
> + .id = VD55G1_MODEL_ID_3,
> + .color = VD55G1_COLOR_VERSION_BAYER,
> + },
> +};
>
> static const u8 vd55g1_patch_array[] = {
> 0x44, 0x03, 0x09, 0x02, 0xe6, 0x01, 0x42, 0x00, 0xea, 0x01, 0x42, 0x00,
> @@ -535,7 +562,7 @@ struct vd55g1_vblank_limits {
>
> struct vd55g1 {
> struct device *dev;
> - unsigned int id;
> + const struct vd55g1_version *version;
> struct v4l2_subdev sd;
> struct media_pad pad;
> struct regulator_bulk_data supplies[ARRAY_SIZE(vd55g1_supply_name)];
> @@ -628,7 +655,7 @@ static u32 vd55g1_get_fmt_code(struct vd55g1 *sensor, u32 code)
> {
> unsigned int i, j;
>
> - if (sensor->id == VD55G1_MODEL_ID_VD55G1)
> + if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER)
> return code;
As pointed out in the previous patch, you seem to have 2 mono formats.
Is this still ok ?
>
> for (i = 0; i < ARRAY_SIZE(vd55g1_mbus_formats_bayer); i++) {
> @@ -1183,8 +1210,8 @@ static int vd55g1_patch(struct vd55g1 *sensor)
> u64 patch;
> int ret = 0;
>
> - /* vd55g1 needs a patch while vd65g4 does not */
> - if (sensor->id == VD55G1_MODEL_ID_VD55G1) {
> + /* Version 2 needs a patch while version 3 does not */
> + if (sensor->version->id == VD55G1_MODEL_ID_2) {
> vd55g1_write_array(sensor, VD55G1_REG_FWPATCH_START_ADDR,
> sizeof(vd55g1_patch_array),
> vd55g1_patch_array, &ret);
You might want to consider renaming vd55g1_patch_array ?
> @@ -1256,7 +1283,7 @@ static int vd55g1_enum_mbus_code(struct v4l2_subdev *sd,
> struct vd55g1 *sensor = to_vd55g1(sd);
> u32 base_code;
>
> - if (sensor->id == VD55G1_MODEL_ID_VD55G1) {
> + if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER) {
> if (code->index >= ARRAY_SIZE(vd55g1_mbus_formats_mono))
> return -EINVAL;
> base_code = vd55g1_mbus_formats_mono[code->index];
> @@ -1372,7 +1399,7 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
> if (ret)
> return ret;
>
> - if (sensor->id == VD55G1_MODEL_ID_VD55G1)
> + if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER)
> code = vd55g1_mbus_formats_mono[VD55G1_MBUS_CODE_IDX_DEF];
> else
> code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF][0];
> @@ -1659,38 +1686,48 @@ static int vd55g1_init_ctrls(struct vd55g1 *sensor)
> return ret;
> }
>
> +static const struct vd55g1_version *
> + vd55g1_get_version(enum vd55g1_model_id id,
> + enum vd55g1_color_version color)
Should you indent one tab left ?
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(vd55g1_versions); i++) {
You can declare i inside the for loop
> + if (vd55g1_versions[i].id == id &&
> + vd55g1_versions[i].color == color)
> + return &vd55g1_versions[i];
> + }
> +
> + return NULL;
> +}
> +
> static int vd55g1_detect(struct vd55g1 *sensor)
> {
> - unsigned int dt_id = (uintptr_t)device_get_match_data(sensor->dev);
> - u64 rev, id;
> - int ret;
> + const struct vd55g1_version *dt_version =
> + device_get_match_data(sensor->dev);
> + const struct vd55g1_version *version;
> + u64 color, id;
> + int ret = 0;
>
> - ret = vd55g1_read(sensor, VD55G1_REG_MODEL_ID, &id, NULL);
> + vd55g1_read(sensor, VD55G1_REG_MODEL_ID, &id, &ret);
> + vd55g1_read(sensor, VD55G1_REG_COLOR_VERSION, &color, &ret);
> if (ret)
> return ret;
>
> - if (id != VD55G1_MODEL_ID_VD55G1 && id != VD55G1_MODEL_ID_VD65G4) {
> - dev_warn(sensor->dev, "Unsupported sensor id 0x%x\n",
> - (u32)id);
> + version = vd55g1_get_version(id, color);
> + if (!version) {
> + dev_warn(sensor->dev, "Unsupported sensor version, expected %s\n",
> + dt_version->name);
> return -ENODEV;
> }
> - if (id != dt_id) {
> - dev_err(sensor->dev, "Probed sensor %s and device tree definition (%s) mismatch",
> - VD55G1_MODEL_ID_NAME(id), VD55G1_MODEL_ID_NAME(dt_id));
> + if (version->id != dt_version->id ||
> + version->color != dt_version->color) {
> + dev_err(sensor->dev, "Probed sensor version %s and device tree definition %s mismatch",
> + version->name, dt_version->name);
> return -ENODEV;
> }
> - sensor->id = id;
>
> - ret = vd55g1_read(sensor, VD55G1_REG_REVISION, &rev, NULL);
> - if (ret)
> - return ret;
> -
> - if ((id == VD55G1_MODEL_ID_VD55G1 && rev != VD55G1_REVISION_CCB) &&
> - (id == VD55G1_MODEL_ID_VD65G4 && rev != VD55G1_REVISION_BAYER)) {
> - dev_err(sensor->dev, "Unsupported sensor revision 0x%x for sensor %s\n",
> - (u16)rev, VD55G1_MODEL_ID_NAME(id));
> - return -ENODEV;
> - }
> + sensor->version = version;
>
> return 0;
> }
> @@ -2048,8 +2085,9 @@ static void vd55g1_remove(struct i2c_client *client)
> }
>
> static const struct of_device_id vd55g1_dt_ids[] = {
> - { .compatible = "st,vd55g1", .data = (void *)VD55G1_MODEL_ID_VD55G1 },
> - { .compatible = "st,vd65g4", .data = (void *)VD55G1_MODEL_ID_VD65G4 },
> + { .compatible = "st,vd55g1", .data = (void *)&vd55g1_versions[0] },
> + { .compatible = "st,vd55g4", .data = (void *)&vd55g1_versions[1] },
> + { .compatible = "st,vd65g4", .data = (void *)&vd55g1_versions[2] },
> { /* sentinel */ }
> };
All minors
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Thanks
j
> MODULE_DEVICE_TABLE(of, vd55g1_dt_ids);
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 10:17 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260622102722.5900592f@jic23-huawei>
On Mon, Jun 22, 2026 at 10:27:22AM +0100, Jonathan Cameron wrote:
> On Mon, 22 Jun 2026 10:07:01 +0100
> Nuno Sá <noname.nuno@gmail.com> wrote:
>
> > On Sun, Jun 21, 2026 at 07:35:42PM +0100, Conor Dooley wrote:
> > > On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
> > > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > >
> > > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > > >
> > > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > > ...
> > > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > > >
> > > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + required:
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +required:
> > > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > > + - |
> > > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > ...
> > > > > > > > > > > > >
> > > > > > > > > > > > > spi {
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > > };
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > > >
> > > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > > >
> > > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > > >
> > > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > > >
> > > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > > >
> > > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > > >
> > > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > > see if I can find what I am thinking of...
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > > slightly different properties.
> > > > > > > >
> > > > > > > > microchip,device-addr:
> > > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > enum: [0, 1, 2, 3]
> > > > > > > > default: 0
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,hw-device-address:
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > minimum: 0
> > > > > > > > maximum: 3
> > > > > > > > description:
> > > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > > The device address is part of the device markings to avoid
> > > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > > which is first one on the wire).
> > > > > > > >
> > > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > > here?
> > > > > > > >
> > > > > > >
> > > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > > about solving this at the spi level.
> > > > > > >
> > > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > > together in the same bus.
> > > > > >
> > > > > > I'm definitely missing something, because that property for the
> > > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > > are completely different devices with different drivers. They have
> > > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > > spi bus.
> > > > >
> > > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > > devices on the same CS right? Because for this chip we would need
> > > > > something like:
> > > > >
> > > > > spi {
> > > > > dac@0 {
> > > > > reg = <0>;
> > > > > adi,pin-id = <0>;
> > > > > };
> > > > >
> > > > > dac@1 {
> > > > > reg = <0>; // which seems already problematic?
> > > > > adi,pin-id <1>;
> > > > > };
> > > > >
> > > > > ...
> > > > >
> > > > > //up to 4
> > > > > };
> > > > Yeah. It's not clear to me how that works for the microchip devices
> > > > (I suspect it doesn't!)
> > > >
> > > > Just thinking as I type, but could we do something a bit nasty with
> > > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > > shared? Given this is all tied to the spi bus that should all happen
> > > > under serializing locks.
> > > >
> > > > Agreed though that this would be nicer as an SPI thing that let
> > > > us specify that a single CS is share by multiple devices and their
> > > > is some other signal acting to select which one we are talking to.
> > >
> > > Whether it works or not, I think it is the more correct approach. Messing
> > > with gpio muxes seems completely wrong, given the chip select may not be
> > > a gpio at all.
> > >
> > > Why do you think the microchip devices won't work? Does the spi core
> > > reject multiple devices with the same chip select being registered or
> > > something like that?
> >
> > Not sure how things work atm. But I'm fairly sure it used to be like
> > that. SPI would reject devices on the same controller and CS. Now that
> > we support more than one CS per controller, not sure how things work.
> We always supported more than one per CS per controller. I guess you mean
> per device.
Obviously :)
>
> >
> > Janani, maybe you can give it a try?
>
> I think we'd need to get it to work with shared gpio proxy which maybe
> will just get set up under the hood. This used to be opt in, but seems
> that changed fairly recently so maybe some of us are working with out
> of date knowledge! I haven't played with it yet, so might not be
> that simple.
>
What I meant for Janani was basically testing two devices on the same CS
as in my pseudo DT. For the GPIO, you mean having a way to select
between devices on the same CS?
For these devices the pin id numbers get's setted up as part of the spi message
so my assumption is that all of them will receive the message but only one acks it.
- Nuno Sá
> Jonathan
>
> >
> > - Nuno Sá
> >
>
^ permalink raw reply
* Re: [PATCH v5 1/4] arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
From: Geert Uytterhoeven @ 2026-06-22 10:16 UTC (permalink / raw)
To: John Madieu
Cc: magnus.damm, robh, krzk+dt, conor+dt, linux-renesas-soc,
devicetree, linux-kernel, biju.das.jz, john.madieu
In-Reply-To: <20260610074702.1743334-2-john.madieu.xa@bp.renesas.com>
Hi John,
On Wed, 10 Jun 2026 at 09:47, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> Add the snd_rzg3e node for the RZ/G3E SoC with all sub-components:
>
> - SSI (Serial Sound Interface) units 0-9
> - SSIU (Serial Sound Interface Unit) units 0-27
> - SRC (Sample Rate Converter) units 0-9
> - CTU (Channel Transfer Unit) units 0-7
> - DVC (Digital Volume Control) units 0-1
> - MIX (Mixer) units 0-1
>
> Sub-node names follow the new RZ/G3E sound binding: unprefixed
> 'ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu' wrapper nodes instead of
> the legacy 'rcar_sound,xxx' R-Car prefix.
>
> Wire up all 5 DMA controllers (dmac0-dmac4) for each audio sub-node
> with repeated channel names, so that the DMA core can pick the first
> available controller.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v5:
> - Use hexadecimal CPG module clock numbers, for easier matching with the
> documentation.
> - Use hexadecimal CPG module reset numbers.
> - Lowercase the SSI reg size: 0x1F000 -> 0x1f000.
> - Extend the SCU reg region from 0x10000 to 0x20000 to cover the SCU DMAC.
> - Drop the per-line clock/reset comments now that the numbers are hex and
> the names are self-documenting, and pack clocks/resets two entries per
> line so each line lines up with its clock-names/reset-names counterpart.
Thanks for the update!
> --- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> @@ -912,6 +912,468 @@ rsci9: serial@12803000 {
> status = "disabled";
> };
>
> + snd_rzg3e: sound@13c00000 {
> + compatible = "renesas,r9a09g047-sound";
> + reg = <0 0x13c00000 0 0x10000>, /* SCU */
> + <0 0x13c20000 0 0x10000>, /* ADG */
> + <0 0x13c30000 0 0x1000>, /* SSIU */
> + <0 0x13c31000 0 0x1f000>, /* SSI */
> + <0 0x13c50000 0 0x10000>; /* Audio DMAC peri peri */
> + reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
> + clocks = <&cpg CPG_MOD 0xf5>,
> + <&cpg CPG_MOD 0x181>, <&cpg CPG_MOD 0x182>,
Please align the opening braces with the previous line...
> + <&cpg CPG_MOD 0x183>, <&cpg CPG_MOD 0x184>,
> + <&cpg CPG_MOD 0x185>, <&cpg CPG_MOD 0x186>,
> + <&cpg CPG_MOD 0x187>, <&cpg CPG_MOD 0x188>,
> + <&cpg CPG_MOD 0x189>, <&cpg CPG_MOD 0x18a>,
> + <&cpg CPG_MOD 0x174>, <&cpg CPG_MOD 0x175>,
> + <&cpg CPG_MOD 0x176>, <&cpg CPG_MOD 0x177>,
> + <&cpg CPG_MOD 0x178>, <&cpg CPG_MOD 0x179>,
> + <&cpg CPG_MOD 0x17a>, <&cpg CPG_MOD 0x17b>,
> + <&cpg CPG_MOD 0x17c>, <&cpg CPG_MOD 0x17d>,
> + <&cpg CPG_MOD 0x172>, <&cpg CPG_MOD 0x173>,
> + <&cpg CPG_MOD 0x172>, <&cpg CPG_MOD 0x173>,
> + <&cpg CPG_MOD 0x170>, <&cpg CPG_MOD 0x171>,
> + <&cpg CPG_MOD 0xfb>, <&cpg CPG_MOD 0xfc>,
> + <&cpg CPG_MOD 0xfd>, <&cpg CPG_MOD 0xfa>,
> + <&cpg CPG_MOD 0x180>,
> + <&cpg CPG_MOD 0xf6>, <&cpg CPG_MOD 0xf7>,
> + <&cpg CPG_MOD 0x17e>,
> + <&cpg CPG_MOD 0x160>, <&cpg CPG_MOD 0x161>,
> + <&cpg CPG_MOD 0x162>, <&cpg CPG_MOD 0x163>,
> + <&cpg CPG_MOD 0x164>, <&cpg CPG_MOD 0x165>,
> + <&cpg CPG_MOD 0x166>, <&cpg CPG_MOD 0x167>,
> + <&cpg CPG_MOD 0x168>, <&cpg CPG_MOD 0x169>,
> + <&cpg CPG_MOD 0xf8>, <&cpg CPG_MOD 0xf9>;
> + clock-names = "ssi-all",
> + "ssi-0", "ssi-1",
... and the double quotes...
> + "ssi-2", "ssi-3",
> + "ssi-4", "ssi-5",
> + "ssi-6", "ssi-7",
> + "ssi-8", "ssi-9",
> + "src-0", "src-1",
> + "src-2", "src-3",
> + "src-4", "src-5",
> + "src-6", "src-7",
> + "src-8", "src-9",
> + "mix-0", "mix-1",
> + "ctu-0", "ctu-1",
> + "dvc-0", "dvc-1",
> + "audio-clka", "audio-clkb",
> + "audio-clkc", "audio-clki",
> + "ssif_supply",
> + "scu", "scu_x2",
> + "scu_supply",
> + "adg-ssi-0", "adg-ssi-1",
> + "adg-ssi-2", "adg-ssi-3",
> + "adg-ssi-4", "adg-ssi-5",
> + "adg-ssi-6", "adg-ssi-7",
> + "adg-ssi-8", "adg-ssi-9",
> + "audmapp", "adg";
> + power-domains = <&cpg>;
> + resets = <&cpg 0xe1>,
> + <&cpg 0xe2>, <&cpg 0xe3>,
> + <&cpg 0xe4>, <&cpg 0xe5>,
> + <&cpg 0xe6>, <&cpg 0xe7>,
> + <&cpg 0xe8>, <&cpg 0xe9>,
> + <&cpg 0xea>, <&cpg 0xeb>,
> + <&cpg 0xec>, <&cpg 0xee>,
> + <&cpg 0xed>;
> + reset-names = "ssi-all",
> + "ssi-0", "ssi-1",
... here too.
> + "ssi-2", "ssi-3",
> + "ssi-4", "ssi-5",
> + "ssi-6", "ssi-7",
> + "ssi-8", "ssi-9",
> + "scu", "adg",
> + "audmapp";
> + status = "disabled";
> +
> + ctu {
> + ctu00: ctu-0 { };
> + ctu01: ctu-1 { };
> + ctu02: ctu-2 { };
> + ctu03: ctu-3 { };
> + ctu10: ctu-4 { };
> + ctu11: ctu-5 { };
> + ctu12: ctu-6 { };
> + ctu13: ctu-7 { };
> + };
> +
> + dvc {
> + dvc0: dvc-0 {
> + dmas = <&dmac0 0x1db3>, <&dmac1 0x1db3>,
> + <&dmac2 0x1db3>, <&dmac3 0x1db3>,
> + <&dmac4 0x1db3>;
> + dma-names = "tx", "tx", "tx", "tx", "tx";
> + };
> + dvc1: dvc-1 {
> + dmas = <&dmac0 0x1db4>, <&dmac1 0x1db4>,
> + <&dmac2 0x1db4>, <&dmac3 0x1db4>,
> + <&dmac4 0x1db4>;
> + dma-names = "tx", "tx", "tx", "tx", "tx";
> + };
> + };
> +
> + mix {
> + mix0: mix-0 { };
> + mix1: mix-1 { };
> + };
> +
> + src {
> + src0: src-0 {
> + interrupts = <GIC_SPI 902 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&dmac0 0x1d9f>, <&dmac0 0x1da9>,
> + <&dmac1 0x1d9f>, <&dmac1 0x1da9>,
> + <&dmac2 0x1d9f>, <&dmac2 0x1da9>,
> + <&dmac3 0x1d9f>, <&dmac3 0x1da9>,
> + <&dmac4 0x1d9f>, <&dmac4 0x1da9>;
> + dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
These lines are way too long (checkpatch?).
[...]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 1/4] arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
From: Geert Uytterhoeven @ 2026-06-22 10:19 UTC (permalink / raw)
To: John Madieu
Cc: magnus.damm, robh, krzk+dt, conor+dt, linux-renesas-soc,
devicetree, linux-kernel, john.madieu, biju.das.jz
In-Reply-To: <20260619083951.3777556-2-john.madieu.xa@bp.renesas.com>
On Fri, 19 Jun 2026 at 10:40, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> Add the snd_rzg3e node for the RZ/G3E SoC with all sub-components:
>
> - SSI (Serial Sound Interface) units 0-9
> - SSIU (Serial Sound Interface Unit) units 0-27
> - SRC (Sample Rate Converter) units 0-9
> - CTU (Channel Transfer Unit) units 0-7
> - DVC (Digital Volume Control) units 0-1
> - MIX (Mixer) units 0-1
>
> Sub-node names follow the new RZ/G3E sound binding: unprefixed
> 'ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu' wrapper nodes instead of
> the legacy 'rcar_sound,xxx' R-Car prefix.
>
> Wire up all 5 DMA controllers (dmac0-dmac4) for each audio sub-node
> with repeated channel names, so that the DMA core can pick the first
> available controller.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Chqnges:
>
> v6: No changes.
So same stylistic issues as v5.
No need to resend just for this (every resend consumes review time on
my side), I may fix it while applying.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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