* Re: [PATCH 1/1] clk: nuvoton: ma35d1: fix PLL frequency calculation
From: Joey Lu @ 2026-05-12 3:49 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette, sboyd, ychuang3, schung, yclu4, linux-arm-kernel,
linux-clk, linux-kernel
In-Reply-To: <agH7qJypv48vkZOr@redhat.com>
On 5/11/2026 11:54 PM, Brian Masney wrote:
> Hi Joey,
>
> On Mon, May 11, 2026 at 11:15:59AM +0800, Joey Lu wrote:
>> Fix four bugs in the MA35D1 PLL driver:
>>
>> 1. PLL_CTL1_FRAC was defined as GENMASK(31, 24) (8 bits), but the
>> hardware fractional field spans bits [31:8] (24 bits). This caused
>> wrong frequency calculation in fractional and spread-spectrum modes.
>>
>> 2. div_u64() does not modify its argument in-place; the quotient must
>> be assigned from the return value. Both ma35d1_calc_smic_pll_freq()
>> and ma35d1_calc_pll_freq() discarded the return value, leaving
>> pll_freq undivided and orders of magnitude too high.
>>
>> 3. The fractional-mode calculation divided x by FIELD_MAX(PLL_CTL1_FRAC)
>> to get 2 decimal digits. After correcting the mask to 24 bits, update
>> the arithmetic to use 3 decimal digits with proper 24-bit fixed-point
>> rounding.
>>
>> 4. ma35d1_clk_pll_determine_rate() called ma35d1_pll_find_closest()
>> unconditionally before the switch, but then overwrote its result by
>> reading the current hardware registers for every PLL type. Move the
>> find_closest() call inside the configurable-PLL branch (APLL, EPLL,
>> VPLL). CAPLL and DDRPLL do not support runtime rate changes and
>> correctly return the current hardware rate.
>>
>> Fixes: 691521a367cf ("clk: nuvoton: Add clock driver for ma35d1 clock controller")
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> Thanks for the patch, however this should really be broken up into more
> patches. If possible, one patch for each of the fixes.
>
> Brian
Thanks for the feedback.🙂
I understand your point and will split the changes into several patches,
with each patch addressing one fix.
>
>> ---
>> drivers/clk/nuvoton/clk-ma35d1-pll.c | 34 +++++++++++++--------------
>> 1 file changed, 17 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/clk/nuvoton/clk-ma35d1-pll.c b/drivers/clk/nuvoton/clk-ma35d1-pll.c
>> index 4620acfe47e8..314b81e7727c 100644
>> --- a/drivers/clk/nuvoton/clk-ma35d1-pll.c
>> +++ b/drivers/clk/nuvoton/clk-ma35d1-pll.c
>> @@ -48,7 +48,7 @@
>> #define PLL_CTL1_PD BIT(0)
>> #define PLL_CTL1_BP BIT(1)
>> #define PLL_CTL1_OUTDIV GENMASK(6, 4)
>> -#define PLL_CTL1_FRAC GENMASK(31, 24)
>> +#define PLL_CTL1_FRAC GENMASK(31, 8)
>> #define PLL_CTL2_SLOPE GENMASK(23, 0)
>>
>> #define INDIV_MIN 1
>> @@ -92,7 +92,7 @@ static unsigned long ma35d1_calc_smic_pll_freq(u32 pll0_ctl0,
>> p = FIELD_GET(SPLL0_CTL0_OUTDIV, pll0_ctl0);
>> outdiv = 1 << p;
>> pll_freq = (u64)parent_rate * n;
>> - div_u64(pll_freq, m * outdiv);
>> + pll_freq = div_u64(pll_freq, m * outdiv);
>> return pll_freq;
>> }
>>
>> @@ -110,12 +110,12 @@ static unsigned long ma35d1_calc_pll_freq(u8 mode, u32 *reg_ctl, unsigned long p
>>
>> if (mode == PLL_MODE_INT) {
>> pll_freq = (u64)parent_rate * n;
>> - div_u64(pll_freq, m * p);
>> + pll_freq = div_u64(pll_freq, m * p);
>> } else {
>> x = FIELD_GET(PLL_CTL1_FRAC, reg_ctl[1]);
>> - /* 2 decimal places floating to integer (ex. 1.23 to 123) */
>> - n = n * 100 + ((x * 100) / FIELD_MAX(PLL_CTL1_FRAC));
>> - pll_freq = div_u64(parent_rate * n, 100 * m * p);
>> + /* x is 24-bit fractional part, convert to 3 decimal digits */
>> + n = n * 1000 + (u32)(((u64)x * 1000 + 500) >> 24);
>> + pll_freq = div_u64((u64)parent_rate * n, 1000 * m * p);
>> }
>> return pll_freq;
>> }
>> @@ -255,32 +255,32 @@ static int ma35d1_clk_pll_determine_rate(struct clk_hw *hw,
>> if (req->best_parent_rate < PLL_FREF_MIN_FREQ || req->best_parent_rate > PLL_FREF_MAX_FREQ)
>> return -EINVAL;
>>
>> - ret = ma35d1_pll_find_closest(pll, req->rate, req->best_parent_rate,
>> - reg_ctl, &pll_freq);
>> - if (ret < 0)
>> - return ret;
>> -
>> switch (pll->id) {
>> case CAPLL:
>> + case DDRPLL:
>> + /* Read-only PLLs: return current rate */
>> reg_ctl[0] = readl_relaxed(pll->ctl0_base);
>> - pll_freq = ma35d1_calc_smic_pll_freq(reg_ctl[0], req->best_parent_rate);
>> + if (pll->id == CAPLL) {
>> + pll_freq = ma35d1_calc_smic_pll_freq(reg_ctl[0], req->best_parent_rate);
>> + } else {
>> + reg_ctl[1] = readl_relaxed(pll->ctl1_base);
>> + pll_freq = ma35d1_calc_pll_freq(pll->mode, reg_ctl, req->best_parent_rate);
>> + }
>> req->rate = pll_freq;
>> -
>> return 0;
>> - case DDRPLL:
>> case APLL:
>> case EPLL:
>> case VPLL:
>> - reg_ctl[0] = readl_relaxed(pll->ctl0_base);
>> - reg_ctl[1] = readl_relaxed(pll->ctl1_base);
>> - pll_freq = ma35d1_calc_pll_freq(pll->mode, reg_ctl, req->best_parent_rate);
>> + /* Configurable PLLs: find closest achievable rate */
>> + ret = ma35d1_pll_find_closest(pll, req->rate, req->best_parent_rate,
>> + reg_ctl, &pll_freq);
>> + if (ret < 0)
>> + return ret;
>> req->rate = pll_freq;
>> -
>> return 0;
>> }
>>
>> req->rate = 0;
>> -
>> return 0;
>> }
>>
>> --
>> 2.49.0
^ permalink raw reply
* [PATCH v3 1/7] gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
From: Yu-Chun Lin @ 2026-05-12 3:33 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, linux-iio, cy.huang, stanley_chang,
eleanor.lin, james.tai
In-Reply-To: <20260512033317.1602537-1-eleanor.lin@realtek.com>
Replace "default y" with "default ARCH_REALTEK" to avoid bloating the build
for non-Realtek platforms when COMPILE_TEST is enabled on other platforms.
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 020e51e30317..504b4bdd75d4 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -637,7 +637,7 @@ config GPIO_ROCKCHIP
config GPIO_RTD
tristate "Realtek DHC GPIO support"
depends on ARCH_REALTEK || COMPILE_TEST
- default y
+ default ARCH_REALTEK
select GPIOLIB_IRQCHIP
help
This option enables support for GPIOs found on Realtek DHC(Digital
--
2.34.1
^ permalink raw reply related
* [PATCH v3 6/7] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Yu-Chun Lin @ 2026-05-12 3:33 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, linux-iio, cy.huang, stanley_chang,
eleanor.lin, james.tai
In-Reply-To: <20260512033317.1602537-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.
The driver leverages the gpio-regmap framework, utilizing the recently
introduced write-enable and operation-specific mask translation features.
Additionally, because the controller utilizes multiple independent IRQ
status registers (assert, de-assert, and level) which cannot be mapped
via standard regmap_irq_chip, the driver implements a custom irq_domain.
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>
---
drivers/gpio/Kconfig | 13 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-rtd1625.c | 608 ++++++++++++++++++++++++++++++++++++
3 files changed, 622 insertions(+)
create mode 100644 drivers/gpio/gpio-rtd1625.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 504b4bdd75d4..4449b288dfd5 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -647,6 +647,19 @@ 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
+ select GPIO_REGMAP
+ 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 b267598b517d..d837061d2df7 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -158,6 +158,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..0eae4bb5577d
--- /dev/null
+++ b/drivers/gpio/gpio-rtd1625.c
@@ -0,0 +1,608 @@
+// 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/gpio/driver.h>
+#include <linux/gpio/regmap.h>
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/irqdomain.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.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)
+
+/**
+ * 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;
+ struct regmap *regmap;
+ unsigned int irqs[3];
+ raw_spinlock_t lock;
+ struct irq_domain *domain;
+ 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_reg_mask_xlate(struct gpio_regmap *gpio, enum gpio_regmap_operation op,
+ unsigned int base, unsigned int offset, unsigned int *reg,
+ unsigned int *mask)
+{
+ /* Each GPIO has its own dedicated 32-bit register */
+ *reg = base + offset * 4;
+
+ switch (op) {
+ case GPIO_REGMAP_IN:
+ *mask = RTD1625_GPIO_IN;
+ break;
+ case GPIO_REGMAP_OUT:
+ *mask = RTD1625_GPIO_OUT;
+ break;
+ case GPIO_REGMAP_SET_WREN_OP:
+ *mask = RTD1625_GPIO_WREN(RTD1625_GPIO_OUT);
+ break;
+ case GPIO_REGMAP_SET_WITH_CLEAR_OP:
+ case GPIO_REGMAP_SET_OP:
+ *mask = RTD1625_GPIO_OUT;
+ break;
+ case GPIO_REGMAP_SET_DIR_WREN_OP:
+ *mask = RTD1625_GPIO_WREN(RTD1625_GPIO_DIR);
+ break;
+ case GPIO_REGMAP_GET_OP:
+ case GPIO_REGMAP_GET_DIR_OP:
+ *mask = RTD1625_GPIO_DIR;
+ break;
+ default:
+ *mask = 0;
+ break;
+ }
+
+ return 0;
+}
+
+static unsigned 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;
+ regmap_write(data->regmap, GPIO_CONTROL(offset), val);
+
+ return 0;
+}
+
+static int rtd1625_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+ unsigned long config)
+{
+ int 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 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_chip *chip = irq_desc_get_chip(desc);
+ unsigned int irq = irq_desc_get_irq(desc);
+ struct irq_domain *domain = data->domain;
+ unsigned int reg_offset, i, j, val;
+ irq_hw_number_t hwirq;
+ unsigned long status;
+ unsigned int girq;
+ u32 irq_type;
+
+ if (irq == data->irqs[0])
+ get_reg_offset = &rtd1625_gpio_gpa_offset;
+ else if (irq == data->irqs[1])
+ 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);
+ regmap_read(data->regmap, reg_offset, &val);
+
+ status = val;
+
+ /* Clear edge interrupts; level interrupts are cleared in ->irq_ack() */
+ if (irq != data->irqs[2])
+ regmap_write(data->regmap, reg_offset, status);
+
+ for_each_set_bit(j, &status, 32) {
+ hwirq = i + j;
+ girq = irq_find_mapping(domain, hwirq);
+ irq_type = irq_get_trigger_type(girq);
+
+ if (irq == data->irqs[1] && 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 gpio_chip *gc = 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);
+ struct rtd1625_gpio *data;
+ struct gpio_regmap *gpio;
+ int reg_offset;
+
+ gpio = gpiochip_get_data(gc);
+ data = gpio_regmap_get_drvdata(gpio);
+
+ if (irq_type & IRQ_TYPE_LEVEL_MASK) {
+ reg_offset = rtd1625_gpio_level_offset(data, hwirq);
+ regmap_write(data->regmap, reg_offset, bit_mask);
+ }
+}
+
+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);
+ regmap_write(data->regmap, gpa_reg_offset, clr_mask);
+ regmap_write(data->regmap, gpda_reg_offset, clr_mask);
+ val = RTD1625_GPIO_EDGE_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_EN);
+ regmap_write(data->regmap, data->info->base_offset + GPIO_CONTROL(hwirq), val);
+}
+
+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);
+ regmap_write(data->regmap, data->info->base_offset + GPIO_CONTROL(hwirq), val);
+}
+
+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);
+ regmap_write(data->regmap, level_reg_offset, clr_mask);
+ val = RTD1625_GPIO_LEVEL_INT_EN | RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_EN);
+ regmap_write(data->regmap, data->info->base_offset + GPIO_CONTROL(hwirq), val);
+}
+
+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);
+ regmap_write(data->regmap, data->info->base_offset + GPIO_CONTROL(hwirq), val);
+}
+
+static void rtd1625_gpio_enable_irq(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+ struct rtd1625_gpio *data;
+ struct gpio_regmap *gpio;
+
+ gpio = gpiochip_get_data(gc);
+ data = gpio_regmap_get_drvdata(gpio);
+
+ 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);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ u32 irq_type = irqd_get_trigger_type(d);
+ struct rtd1625_gpio *data;
+ struct gpio_regmap *gpio;
+
+ gpio = gpiochip_get_data(gc);
+ data = gpio_regmap_get_drvdata(gpio);
+
+ 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)
+{
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_LEVEL_INT_DP);
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ struct rtd1625_gpio *data;
+ struct gpio_regmap *gpio;
+
+ gpio = gpiochip_get_data(gc);
+ data = gpio_regmap_get_drvdata(gpio);
+ if (!(data->info->irq_type_support & IRQ_TYPE_LEVEL_MASK))
+ return -EINVAL;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock) {
+ if (level)
+ val |= RTD1625_GPIO_LEVEL_INT_DP;
+ regmap_write(data->regmap, data->info->base_offset + GPIO_CONTROL(hwirq), val);
+ }
+
+ irq_set_handler_locked(d, handle_level_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_edge_type(struct irq_data *d, bool polarity)
+{
+ u32 val = RTD1625_GPIO_WREN(RTD1625_GPIO_EDGE_INT_DP);
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ irq_hw_number_t hwirq = irqd_to_hwirq(d);
+ struct rtd1625_gpio *data;
+ struct gpio_regmap *gpio;
+
+ gpio = gpiochip_get_data(gc);
+ data = gpio_regmap_get_drvdata(gpio);
+ if (!(data->info->irq_type_support & IRQ_TYPE_EDGE_BOTH))
+ return -EINVAL;
+
+ scoped_guard(raw_spinlock_irqsave, &data->lock) {
+ if (polarity)
+ val |= RTD1625_GPIO_EDGE_INT_DP;
+ regmap_write(data->regmap, data->info->base_offset + GPIO_CONTROL(hwirq), val);
+ }
+
+ irq_set_handler_locked(d, handle_edge_irq);
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+ int ret;
+
+ switch (type & IRQ_TYPE_SENSE_MASK) {
+ case IRQ_TYPE_EDGE_RISING:
+ ret = rtd1625_gpio_irq_set_edge_type(d, 1);
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ ret = rtd1625_gpio_irq_set_edge_type(d, 0);
+ break;
+ case IRQ_TYPE_EDGE_BOTH:
+ ret = rtd1625_gpio_irq_set_edge_type(d, 1);
+ break;
+ case IRQ_TYPE_LEVEL_HIGH:
+ ret = rtd1625_gpio_irq_set_level_type(d, 0);
+ break;
+ case IRQ_TYPE_LEVEL_LOW:
+ ret = rtd1625_gpio_irq_set_level_type(d, 1);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+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)
+{
+ int num_irqs, irq, i;
+
+ 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;
+
+ for (i = 0; i < num_irqs; i++) {
+ irq = platform_get_irq(pdev, i);
+ if (irq < 0)
+ return irq;
+
+ data->irqs[i] = irq;
+ irq_set_chained_handler_and_data(data->irqs[i], rtd1625_gpio_irq_handle, data);
+ }
+
+ return 0;
+}
+
+static int rtd1625_gpio_irq_map(struct irq_domain *domain, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ struct rtd1625_gpio *data = domain->host_data;
+
+ irq_set_chip_data(irq, data->gpio_chip);
+
+ irq_set_chip_and_handler(irq, &rtd1625_iso_gpio_irq_chip, handle_bad_irq);
+
+ irq_set_noprobe(irq);
+
+ return 0;
+}
+
+static const struct irq_domain_ops rtd1625_gpio_irq_domain_ops = {
+ .map = rtd1625_gpio_irq_map,
+ .xlate = irq_domain_xlate_twocell,
+};
+
+static const struct regmap_config rtd1625_gpio_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .disable_locking = true,
+};
+
+static int rtd1625_gpio_probe(struct platform_device *pdev)
+{
+ struct gpio_regmap_config config = {0};
+ struct device *dev = &pdev->dev;
+ struct gpio_regmap *gpio_reg;
+ 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;
+
+ irq_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(irq_base))
+ return PTR_ERR(irq_base);
+
+ data->regmap = devm_regmap_init_mmio(dev, irq_base,
+ &rtd1625_gpio_regmap_config);
+ if (IS_ERR(data->regmap))
+ return PTR_ERR(data->regmap);
+
+ data->save_regs = devm_kzalloc(dev, data->info->num_gpios *
+ sizeof(*data->save_regs), GFP_KERNEL);
+ if (!data->save_regs)
+ return -ENOMEM;
+
+ config.parent = dev;
+ config.regmap = data->regmap;
+ config.ngpio = data->info->num_gpios;
+ config.reg_dat_base = data->info->base_offset;
+ config.reg_set_base = data->info->base_offset;
+ config.reg_mask_xlate = rtd1625_reg_mask_xlate;
+ config.set_config = rtd1625_gpio_set_config;
+ config.reg_dir_out_base = data->info->base_offset;
+
+ data->domain = irq_domain_add_linear(dev->of_node,
+ data->info->num_gpios,
+ &rtd1625_gpio_irq_domain_ops,
+ data);
+ if (!data->domain)
+ return -ENOMEM;
+
+ ret = rtd1625_gpio_setup_irq(pdev, data);
+ if (ret) {
+ irq_domain_remove(data->domain);
+ return ret;
+ }
+
+ config.irq_domain = data->domain;
+ config.drvdata = data;
+ platform_set_drvdata(pdev, data);
+
+ gpio_reg = devm_gpio_regmap_register(dev, &config);
+ if (IS_ERR(gpio_reg)) {
+ irq_domain_remove(data->domain);
+ return PTR_ERR(gpio_reg);
+ }
+
+ data->gpio_chip = gpio_regmap_get_gpiochip(gpio_reg);
+
+ return 0;
+}
+
+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 = 0x0,
+ .gpda_offset = 0x20,
+ .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 = 0x0,
+ .gpda_offset = 0x4,
+ .level_offset = 0x18,
+ .write_en_all = RTD1625_ISOM_GPIO_WREN_ALL,
+};
+
+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 int rtd1625_gpio_suspend(struct device *dev)
+{
+ struct rtd1625_gpio *data = dev_get_drvdata(dev);
+ const struct rtd1625_gpio_info *info = data->info;
+ int i;
+
+ for (i = 0; i < info->num_gpios; i++)
+ regmap_read(data->regmap, data->info->base_offset + GPIO_CONTROL(i),
+ &data->save_regs[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;
+ int i;
+
+ for (i = 0; i < info->num_gpios; i++)
+ regmap_write(data->regmap, data->info->base_offset + GPIO_CONTROL(i),
+ data->save_regs[i] | info->write_en_all);
+
+ return 0;
+}
+
+DEFINE_NOIRQ_DEV_PM_OPS(rtd1625_gpio_pm_ops, rtd1625_gpio_suspend, rtd1625_gpio_resume);
+
+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.34.1
^ permalink raw reply related
* [PATCH v3 7/7] arm64: dts: realtek: Add GPIO support for RTD1625
From: Yu-Chun Lin @ 2026-05-12 3:33 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, linux-iio, cy.huang, stanley_chang,
eleanor.lin, james.tai, Bartosz Golaszewski
In-Reply-To: <20260512033317.1602537-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>
---
The changes are based on commit 856540ac9b441a8c0e39f1f1787277edc4097c9b,
which was merged into the soc/for-next branch.
---
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.34.1
^ permalink raw reply related
* [PATCH v3 0/7] gpio: realtek: Add support for Realtek DHC RTD1625
From: Yu-Chun Lin @ 2026-05-12 3:33 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, linux-iio, cy.huang, stanley_chang,
eleanor.lin, james.tai
Hi all,
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.
To accommodate this, we extend the gpio-regmap core framework to handle
per-pin register operations, write-enable mechanisms, and add custom
set_config callback.
Best Regards,
Yu-Chun Lin
---
Changes in v3:
patch 1 (gpio: Replace "default y" with "default ARCH_REATLEK" in Kconfig):
- Chang "remove default y" to "replace it with default ARCH_REALTEK".
patch 2 (gpio: regmap: add gpio_regmap_get_gpiochip() accessor):
- New patch
patch 3 (gpio: regmap: Add gpio_regmap_operation and write-enable support):
- New patch
- Update all drivers utilizing the gpio-regmap framework to accommodate
the new reg_mask_xlate function signature.
patch 4 (gpio: regmap: Add set_config callback):
- New patch
patch 5 (dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio):
- Remove description for reg.
- Add Reviewed-by tag from Krzysztof.
patch 6 (gpio: realtek: Add driver for Realtek DHC RTD1625 SoC):
- Refactor to utilize the gpio-regmap framework.
- Create a custom irqdomain.
patch 7(arm64: dts: realtek: Add GPIO support for RTD1625):
- Add Reviewed-by tag from Bartosz.
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 (5):
gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
gpio: regmap: add gpio_regmap_get_gpiochip() accessor
gpio: regmap: Add gpio_regmap_operation and write-enable support
gpio: regmap: Add set_config callback
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 | 15 +-
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-104-idi-48.c | 18 +-
drivers/gpio/gpio-i8255.c | 13 +-
drivers/gpio/gpio-idio-16.c | 16 +-
drivers/gpio/gpio-max7360.c | 10 +
drivers/gpio/gpio-pcie-idio-24.c | 15 +-
drivers/gpio/gpio-regmap.c | 80 ++-
drivers/gpio/gpio-rtd1625.c | 608 ++++++++++++++++++
drivers/iio/adc/ad7173.c | 32 +-
drivers/iio/addac/stx104.c | 17 +-
drivers/pinctrl/bcm/pinctrl-bcm63xx.c | 12 +-
drivers/pinctrl/pinctrl-tps6594.c | 10 +
include/linux/gpio/regmap.h | 51 +-
16 files changed, 963 insertions(+), 45 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/realtek,rtd1625-gpio.yaml
create mode 100644 drivers/gpio/gpio-rtd1625.c
--
2.34.1
^ permalink raw reply
* [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Yu-Chun Lin @ 2026-05-12 3:33 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, linux-iio, cy.huang, stanley_chang,
eleanor.lin, james.tai
In-Reply-To: <20260512033317.1602537-1-eleanor.lin@realtek.com>
Expose an accessor function to retrieve the gpio_chip pointer from
a gpio_regmap instance.
This is needed by drivers that use gpio_regmap but also manage their
own irq_chip, where gpiochip_enable_irq()/gpiochip_disable_irq() must
be called with the gpio_chip pointer.
Add gpio_regmap_get_gpiochip() to allow drivers with complex custom IRQ
implementations.
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
drivers/gpio/gpio-regmap.c | 6 ++++++
include/linux/gpio/regmap.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
index 9ae4a41a2427..deb9eebb58de 100644
--- a/drivers/gpio/gpio-regmap.c
+++ b/drivers/gpio/gpio-regmap.c
@@ -230,6 +230,12 @@ void *gpio_regmap_get_drvdata(struct gpio_regmap *gpio)
}
EXPORT_SYMBOL_GPL(gpio_regmap_get_drvdata);
+struct gpio_chip *gpio_regmap_get_gpiochip(struct gpio_regmap *gpio)
+{
+ return &gpio->gpio_chip;
+}
+EXPORT_SYMBOL_GPL(gpio_regmap_get_gpiochip);
+
/**
* gpio_regmap_register() - Register a generic regmap GPIO controller
* @config: configuration for gpio_regmap
diff --git a/include/linux/gpio/regmap.h b/include/linux/gpio/regmap.h
index 12d154732ca9..e4a95f805a81 100644
--- a/include/linux/gpio/regmap.h
+++ b/include/linux/gpio/regmap.h
@@ -113,5 +113,6 @@ void gpio_regmap_unregister(struct gpio_regmap *gpio);
struct gpio_regmap *devm_gpio_regmap_register(struct device *dev,
const struct gpio_regmap_config *config);
void *gpio_regmap_get_drvdata(struct gpio_regmap *gpio);
+struct gpio_chip *gpio_regmap_get_gpiochip(struct gpio_regmap *gpio);
#endif /* _LINUX_GPIO_REGMAP_H */
--
2.34.1
^ permalink raw reply related
* [PATCH v3 4/7] gpio: regmap: Add set_config callback
From: Yu-Chun Lin @ 2026-05-12 3:33 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, linux-iio, cy.huang, stanley_chang,
eleanor.lin, james.tai
In-Reply-To: <20260512033317.1602537-1-eleanor.lin@realtek.com>
Add a new set_config callback to struct gpio_regmap_config to allow drivers
to implement hardware-specific configuration such as debounce settings,
or other platform-specific GPIO properties.
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
---
drivers/gpio/gpio-regmap.c | 2 ++
include/linux/gpio/regmap.h | 7 +++++++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
index c76eef20e412..490a35fe8768 100644
--- a/drivers/gpio/gpio-regmap.c
+++ b/drivers/gpio/gpio-regmap.c
@@ -371,6 +371,8 @@ struct gpio_regmap *gpio_regmap_register(const struct gpio_regmap_config *config
if (!gpio->reg_mask_xlate)
gpio->reg_mask_xlate = gpio_regmap_simple_xlate;
+ chip->set_config = config->set_config;
+
ret = gpiochip_add_data(chip, gpio);
if (ret < 0)
goto err_free_bitmap;
diff --git a/include/linux/gpio/regmap.h b/include/linux/gpio/regmap.h
index 519fc81add8a..0660fd9be928 100644
--- a/include/linux/gpio/regmap.h
+++ b/include/linux/gpio/regmap.h
@@ -89,6 +89,9 @@ enum gpio_regmap_operation {
* domain will be set accordingly.
* @regmap_irq_line: (Optional) The IRQ the device uses to signal interrupts.
* @regmap_irq_flags: (Optional) The IRQF_ flags to use for the interrupt.
+ * @set_config: (Optional) Callback for setting GPIO configuration such
+ * as debounce, drive strength, or other hardware specific
+ * settings.
*
* The ->reg_mask_xlate translates a given base address and GPIO offset to
* register and mask pair. The base address is one of the given register
@@ -142,6 +145,10 @@ struct gpio_regmap_config {
unsigned long *valid_mask,
unsigned int ngpios);
+ int (*set_config)(struct gpio_chip *gc,
+ unsigned int offset,
+ unsigned long config);
+
void *drvdata;
};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 5/7] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Yu-Chun Lin @ 2026-05-12 3:33 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang
Cc: linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, linux-iio, cy.huang, stanley_chang,
eleanor.lin, james.tai, Krzysztof Kozlowski
In-Reply-To: <20260512033317.1602537-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>
---
.../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.34.1
^ permalink raw reply related
* Re: [PATCH v1] arm: dts: imx: Add watchdog support for early boot stages
From: Fabio Estevam @ 2026-05-12 3:01 UTC (permalink / raw)
To: alice.guo; +Cc: Frank.Li, s.hauer, kernel, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512024850.904551-1-alice.guo@oss.nxp.com>
On Mon, May 11, 2026 at 11:46 PM <alice.guo@oss.nxp.com> wrote:
> --- a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> +++ b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
> @@ -325,6 +325,17 @@ smc1: clock-controller@40410000 {
> clock-names = "divcore", "hsrun_divcore";
> };
>
> + wdog2: watchdog@40430000 {
> + compatible = "fsl,imx7ulp-wdt";
> + reg = <0x40430000 0x10000>;
> + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&pcc2 IMX7ULP_CLK_WDG2>;
> + assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG2>;
> + assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
> + timeout-sec = <40>;
> + status = "disabled";
You missed passing bootph-all here.
Adding wdog2 would probably make more sense on a separate patch.
^ permalink raw reply
* [PATCH v3] dt-bindings: i2c: convert davinci i2c to dt-schema
From: Chaitanya Sabnis @ 2026-05-12 3:00 UTC (permalink / raw)
To: andi.shyti, robh, krzk+dt, conor+dt, brgl
Cc: linux-i2c, devicetree, linux-kernel, linux-arm-kernel,
Chaitanya Sabnis, kernel test robot
Convert the Texas Instruments DaVinci and Keystone I2C controller
bindings from legacy text format to modern dt-schema (YAML).
During the conversion, the `interrupts` property was made required
to match the strict requirement in the driver probe function. The
custom `ti,has-pfunc` and `power-domains` properties were also
properly defined to match SoC-specific hardware features.
Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605120133.lQ1F3qlY-lkp@intel.com/
---
Changes in v3:
- Fixed a typo in the author's email address within the YAML maintainers block.
Changes in v2:
- Updated MAINTAINERS file to point to the new ti,davinci-i2c.yaml file instead of the deleted .txt file.
.../devicetree/bindings/i2c/i2c-davinci.txt | 43 -------------
.../bindings/i2c/ti,davinci-i2c.yaml | 62 +++++++++++++++++++
MAINTAINERS | 2 +-
3 files changed, 63 insertions(+), 44 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-davinci.txt
create mode 100644 Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
deleted file mode 100644
index 6590501c53d4..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-* Texas Instruments Davinci/Keystone I2C
-
-This file provides information, what the device node for the
-davinci/keystone i2c interface contains.
-
-Required properties:
-- compatible: "ti,davinci-i2c" or "ti,keystone-i2c";
-- reg : Offset and length of the register set for the device
-- clocks: I2C functional clock phandle.
- For 66AK2G this property should be set per binding,
- Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
-
-SoC-specific Required Properties:
-
-The following are mandatory properties for Keystone 2 66AK2G SoCs only:
-
-- power-domains: Should contain a phandle to a PM domain provider node
- and an args specifier containing the I2C device id
- value. This property is as per the binding,
- Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
-
-Recommended properties :
-- interrupts : standard interrupt property.
-- clock-frequency : desired I2C bus clock frequency in Hz.
-- ti,has-pfunc: boolean; if defined, it indicates that SoC supports PFUNC
- registers. PFUNC registers allow to switch I2C pins to function as
- GPIOs, so they can be toggled manually.
-
-Example (enbw_cmc board):
- i2c@1c22000 {
- compatible = "ti,davinci-i2c";
- reg = <0x22000 0x1000>;
- clock-frequency = <100000>;
- interrupts = <15>;
- interrupt-parent = <&intc>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- dtt@48 {
- compatible = "national,lm75";
- reg = <0x48>;
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml
new file mode 100644
index 000000000000..e8064bd1fcf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/ti,davinci-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DaVinci/Keystone I2C
+
+maintainers:
+ - Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,davinci-i2c
+ - ti,keystone-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ ti,has-pfunc:
+ description:
+ Indicates that the SoC supports PFUNC registers, allowing I2C pins
+ to function as GPIOs for manual toggling.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c@1c22000 {
+ compatible = "ti,davinci-i2c";
+ reg = <0x01c22000 0x1000>;
+ clocks = <&i2c_clk>;
+ clock-frequency = <100000>;
+ interrupts = <15>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index bc3bcc641663..50a11a8d71a2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26396,7 +26396,7 @@ M: Bartosz Golaszewski <brgl@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
-F: Documentation/devicetree/bindings/i2c/i2c-davinci.txt
+F: Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml
F: arch/arm/boot/dts/ti/davinci/
F: arch/arm/mach-davinci/
F: drivers/i2c/busses/i2c-davinci.c
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 8/8] unwind: arm64: Use sframe to unwind interrupt frames
From: Dylan Hatch @ 2026-05-12 3:00 UTC (permalink / raw)
To: Mark Rutland
Cc: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Jens Remus, Prasanna Kumar T S M, Puranjay Mohan,
Song Liu, joe.lawrence, linux-toolchains, linux-kernel,
live-patching, linux-arm-kernel, Randy Dunlap
In-Reply-To: <afTYzAF_x41pyilu@J2N7QTR9R3>
Hi Mark,
Thanks for all the feedback and help on this. I'm planning on getting
your comments addressed in the coming days, but I have some initial
clarifying questions.
On Fri, May 1, 2026 at 9:46 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> Hi Dylan,
>
> Thanks for putting this together. I think this is looking pretty good.
> However, there are some things that aren't quite right and need some
> work, which I've commented on below.
>
> More generally, there are a few things that aren't addressed by this
> series that we will also need to address. Importantly:
>
> (1) For correctness, we'll need to address a latent issue with unwinding
> across an fgraph return trampoline, where the return address is
> transiently unrecoverable.
>
> Before this series, that doesn't matter for livepatching because the
> livepatching code isn't called synchronously within the fgraph
> handler, and unwinds which cross an exception boundary are marked as
> unreliable.
>
> After this series, that does matter as we can unwind across an
> exception boundary, and might happen to interrupt that transient
> window.
>
> I think we can solve that with some restructuring of that code,
> restoring the original address *before* removing that from the
> fgraph return stack, and ensuring that the unwinder can find it.
If my understanding is correct, the issue arrises in return_to_handler
as the return address is recovered:
mov x0, sp
bl ftrace_return_to_handler // addr = ftrace_return_to_hander(fregs);
mov x30, x0 // restore the original return address
Because ftrace_return_to_handler pops the return address from the
return stack before it can be restored into the LR, it cannot be
recovered.
Based on this, I believe you are suggesting to restructure this code
path such that the return address is removed from the return stack
only after it has been restored to LR. But since kernel/trace/fgraph.c
is core kernel code, will this end up requiring either (1) a similar
restructuring of other arches supporting ftrace, or (2) an
arm64-specific implementation of this recovery logic?
It looks to me like there is essentially the same recovery pattern on
other arches; is there a reason this transient unrecoverability isn't
an issue for reliable unwind on other platforms?
>
> I'm not immediately sure whether kretprobes has a similar issue.
>
> (2) To make unwinding generally possible, we'll need to annotate some
> assembly functions as unwindable. We'll need to do that for string
> routines under lib/, and probably some crypto code, but we don't
> need to do that for most code in head.S, entry.S, etc.
>
> The vast majority of relevant assembly functions are leaf functions
> (where the return address is never moved out of the LR), so we can
> probably get away with a simple annotation for those that avoids the
> need for open-coded CFI directives everywhere.
Are you suggesting something like a SYM_LEAF_FUNC_(START|END), that
wraps CFI directives for leaf functions?
>
> I've pushed some reliable stacktrace tests to:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git stacktrace/tests
>
> That finds the fgraph issue (regardless of this series). When merged
> with this series triggers a warning in kunwind_next_frame_record_meta(),
> where unwind_next_frame_sframe() calls that erroneously as a fallback.
Thanks for the pointer on these tests, they're super useful! I've been
able to reproduce the fgraph failure you mentioned.
Thanks,
Dylan
^ permalink raw reply
* [syzbot] [arm?] WARNING in delayed_work_timer_fn (2)
From: syzbot @ 2026-05-12 2:53 UTC (permalink / raw)
To: catalin.marinas, linux-arm-kernel, linux-kernel, syzkaller-bugs,
will
Hello,
syzbot found the following issue on:
HEAD commit: 5cbb61bf4168 arm64/fpsimd: ptrace: zero target's fpsimd_st..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=10e45a73980000
kernel config: https://syzkaller.appspot.com/x/.config?x=a834c6344141a58b
dashboard link: https://syzkaller.appspot.com/bug?extid=48fc5b35b350240fd465
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
userspace arch: arm64
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/04156ec16593/disk-5cbb61bf.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6bfa041e2c79/vmlinux-5cbb61bf.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a92d82d8a79e/Image-5cbb61bf.gz.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+48fc5b35b350240fd465@syzkaller.appspotmail.com
------------[ cut here ]------------
workqueue: cannot queue hci_cmd_timeout on wq hci4
WARNING: kernel/workqueue.c:2298 at __queue_work+0xf6c/0x12f8 kernel/workqueue.c:2296, CPU#1: syz.3.1091/10273
Modules linked in:
CPU: 1 UID: 0 PID: 10273 Comm: syz.3.1091 Tainted: G L syzkaller #0 PREEMPT
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
pstate: 634000c5 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : __queue_work+0xf6c/0x12f8 kernel/workqueue.c:2296
lr : __queue_work+0xf6c/0x12f8 kernel/workqueue.c:2296
sp : ffff80008e8e7b10
x29: ffff80008e8e7b50 x28: dfff800000000000 x27: ffff700011d1cf84
x26: ffff0000c9d69800 x25: 0000000000000008 x24: ffff0000c9d699c0
x23: dfff800000000000 x22: ffff0000db3fba08 x21: 0000000000000100
x20: ffff800089f06000 x19: ffff0000d915ca70 x18: 1fffe00035c25820
x17: ffff8001258ac000 x16: ffff80008e8e0000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000001f53 x10: 0000000000ff0100 x9 : 48aa0a8f34ab2700
x8 : 48aa0a8f34ab2700 x7 : ffff8000804886d0 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff8000802f13b0
x2 : 0000000000000101 x1 : ffff0000db3fba00 x0 : 0000000000000000
Call trace:
__queue_work+0xf6c/0x12f8 kernel/workqueue.c:2296 (P)
delayed_work_timer_fn+0x74/0x90 kernel/workqueue.c:2527
call_timer_fn+0x19c/0xa4c kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1794 [inline]
__run_timers kernel/time/timer.c:2374 [inline]
__run_timer_base+0x554/0x74c kernel/time/timer.c:2386
run_timer_base+0x84/0x1b8 kernel/time/timer.c:2395
run_timer_softirq+0x20/0x48 kernel/time/timer.c:2405
handle_softirqs+0x2e4/0xd34 kernel/softirq.c:622
__do_softirq+0x14/0x20 kernel/softirq.c:656
____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:68
call_on_irq_stack+0x30/0x48 arch/arm64/kernel/entry.S:889
do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:73
invoke_softirq kernel/softirq.c:503 [inline]
__irq_exit_rcu+0x1ac/0x428 kernel/softirq.c:735
irq_exit_rcu+0x14/0x84 kernel/softirq.c:752
__el1_irq arch/arm64/kernel/entry-common.c:497 [inline]
el1_interrupt+0x40/0x60 arch/arm64/kernel/entry-common.c:509
el1h_64_irq_handler+0x18/0x24 arch/arm64/kernel/entry-common.c:514
el1h_64_irq+0x6c/0x70 arch/arm64/kernel/entry.S:590
__daif_local_irq_restore arch/arm64/include/asm/irqflags.h:175 [inline] (P)
arch_local_irq_restore arch/arm64/include/asm/irqflags.h:195 [inline] (P)
__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:178 [inline] (P)
_raw_spin_unlock_irqrestore+0x44/0x98 kernel/locking/spinlock.c:198 (P)
spin_unlock_irqrestore include/linux/spinlock.h:408 [inline]
__wake_up_common_lock+0x5c/0x78 kernel/sched/wait.c:127
__wake_up_sync_key+0x20/0x2c kernel/sched/wait.c:192
__unix_dgram_recvmsg+0x2bc/0x898 net/unix/af_unix.c:2612
unix_dgram_recvmsg+0xcc/0xe4 net/unix/af_unix.c:2686
sock_recvmsg_nosec+0x90/0xe8 net/socket.c:1137
____sys_recvmsg+0x4f8/0x604 net/socket.c:2916
___sys_recvmsg+0x16c/0x1f4 net/socket.c:2960
do_recvmmsg+0x2a8/0x7e8 net/socket.c:3055
__sys_recvmmsg+0x1e0/0x270 net/socket.c:3129
__do_sys_recvmmsg net/socket.c:3152 [inline]
__se_sys_recvmmsg net/socket.c:3145 [inline]
__arm64_sys_recvmmsg+0xd0/0xf8 net/socket.c:3145
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x244 arch/arm64/kernel/syscall.c:49
el0_svc_common+0xe8/0x23c arch/arm64/kernel/syscall.c:121
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:140
el0_svc+0x60/0x25c arch/arm64/kernel/entry-common.c:723
el0t_64_sync_handler+0x48/0x148 arch/arm64/kernel/entry-common.c:742
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:594
irq event stamp: 1293
hardirqs last enabled at (1292): [<ffff80008030866c>] handle_softirqs+0x1cc/0xd34 kernel/softirq.c:606
hardirqs last disabled at (1293): [<ffff800086743ef0>] __raw_spin_lock_irq include/linux/spinlock_api_smp.h:140 [inline]
hardirqs last disabled at (1293): [<ffff800086743ef0>] _raw_spin_lock_irq+0x28/0x70 kernel/locking/spinlock.c:174
softirqs last enabled at (24): [<ffff800080139e6c>] local_bh_enable+0x10/0x34 include/linux/bottom_half.h:32
softirqs last disabled at (1291): [<ffff8000800204b0>] __do_softirq+0x14/0x20 kernel/softirq.c:656
---[ end trace 0000000000000000 ]---
IPVS: lc: UDP 224.0.0.2:0 - no destination available
IPVS: lc: UDP 224.0.0.2:0 - no destination available
IPVS: lc: UDP 224.0.0.2:0 - no destination available
IPVS: lc: UDP 224.0.0.2:0 - no destination available
IPVS: lc: UDP 224.0.0.2:0 - no destination available
IPVS: lc: UDP 224.0.0.2:0 - no destination available
IPVS: lc: UDP 224.0.0.2:0 - no destination available
IPVS: lc: UDP 224.0.0.2:0 - no destination available
IPVS: lc: UDP 224.0.0.2:0 - no destination available
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [PATCH v2] dt-bindings: i2c: convert davinci i2c to dt-schema
From: Chaitanya Sabnis @ 2026-05-12 2:48 UTC (permalink / raw)
To: andi.shyti, robh, krzk+dt, conor+dt, brgl
Cc: linux-i2c, devicetree, linux-kernel, linux-arm-kernel,
Chaitanya Sabnis, kernel test robot
Convert the Texas Instruments DaVinci and Keystone I2C controller
bindings from legacy text format to modern dt-schema (YAML).
During the conversion, the `interrupts` property was made required
to match the strict requirement in the driver probe function. The
custom `ti,has-pfunc` and `power-domains` properties were also
properly defined to match SoC-specific hardware features.
Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605120133.lQ1F3qlY-lkp@intel.com/
---
Changes in v2:
- Updated MAINTAINERS file to point to the new ti,davinci-i2c.yaml file instead of the deleted .txt file.
.../devicetree/bindings/i2c/i2c-davinci.txt | 43 -------------
.../bindings/i2c/ti,davinci-i2c.yaml | 62 +++++++++++++++++++
MAINTAINERS | 2 +-
3 files changed, 63 insertions(+), 44 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-davinci.txt
create mode 100644 Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
deleted file mode 100644
index 6590501c53d4..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-* Texas Instruments Davinci/Keystone I2C
-
-This file provides information, what the device node for the
-davinci/keystone i2c interface contains.
-
-Required properties:
-- compatible: "ti,davinci-i2c" or "ti,keystone-i2c";
-- reg : Offset and length of the register set for the device
-- clocks: I2C functional clock phandle.
- For 66AK2G this property should be set per binding,
- Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
-
-SoC-specific Required Properties:
-
-The following are mandatory properties for Keystone 2 66AK2G SoCs only:
-
-- power-domains: Should contain a phandle to a PM domain provider node
- and an args specifier containing the I2C device id
- value. This property is as per the binding,
- Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
-
-Recommended properties :
-- interrupts : standard interrupt property.
-- clock-frequency : desired I2C bus clock frequency in Hz.
-- ti,has-pfunc: boolean; if defined, it indicates that SoC supports PFUNC
- registers. PFUNC registers allow to switch I2C pins to function as
- GPIOs, so they can be toggled manually.
-
-Example (enbw_cmc board):
- i2c@1c22000 {
- compatible = "ti,davinci-i2c";
- reg = <0x22000 0x1000>;
- clock-frequency = <100000>;
- interrupts = <15>;
- interrupt-parent = <&intc>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- dtt@48 {
- compatible = "national,lm75";
- reg = <0x48>;
- };
- };
diff --git a/Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml
new file mode 100644
index 000000000000..89c639d023a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/ti,davinci-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments DaVinci/Keystone I2C
+
+maintainers:
+ - Chaitanya Sabnis <chaitanya.msabni@gmail.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ti,davinci-i2c
+ - ti,keystone-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ ti,has-pfunc:
+ description:
+ Indicates that the SoC supports PFUNC registers, allowing I2C pins
+ to function as GPIOs for manual toggling.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c@1c22000 {
+ compatible = "ti,davinci-i2c";
+ reg = <0x01c22000 0x1000>;
+ clocks = <&i2c_clk>;
+ clock-frequency = <100000>;
+ interrupts = <15>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sensor@48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index bc3bcc641663..50a11a8d71a2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26396,7 +26396,7 @@ M: Bartosz Golaszewski <brgl@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
-F: Documentation/devicetree/bindings/i2c/i2c-davinci.txt
+F: Documentation/devicetree/bindings/i2c/ti,davinci-i2c.yaml
F: arch/arm/boot/dts/ti/davinci/
F: arch/arm/mach-davinci/
F: drivers/i2c/busses/i2c-davinci.c
--
2.43.0
^ permalink raw reply related
* [PATCH v1] arm: dts: imx: Add watchdog support for early boot stages
From: alice.guo @ 2026-05-12 2:48 UTC (permalink / raw)
To: Frank.Li, s.hauer; +Cc: kernel, festevam, imx, linux-arm-kernel, linux-kernel
From: Alice Guo <alice.guo@nxp.com>
Add bootph-all property to watchdog nodes to enable them in U-Boot's
early boot phases. This allows U-Boot to utilize these watchdogs for
system monitoring and reset functionality during boot.
The bootph-all property ensures these watchdog devices are available
across all U-Boot boot phases (TPL, SPL, and U-Boot proper).
Signed-off-by: Alice Guo <alice.guo@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi | 11 +++++++++++
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 1 +
arch/arm64/boot/dts/freescale/imx91_93_common.dtsi | 3 +++
arch/arm64/boot/dts/freescale/imx94.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/freescale/imx95.dtsi | 11 +++++++++++
arch/arm64/boot/dts/freescale/imx952.dtsi | 11 +++++++++++
6 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
index 1355feda1aa7..c29a767df925 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi
@@ -325,6 +325,17 @@ smc1: clock-controller@40410000 {
clock-names = "divcore", "hsrun_divcore";
};
+ wdog2: watchdog@40430000 {
+ compatible = "fsl,imx7ulp-wdt";
+ reg = <0x40430000 0x10000>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc2 IMX7ULP_CLK_WDG2>;
+ assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG2>;
+ assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>;
+ timeout-sec = <40>;
+ status = "disabled";
+ };
+
pcc3: clock-controller@40b30000 {
compatible = "fsl,imx7ulp-pcc3";
reg = <0x40b30000 0x10000>;
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 1de3ad60c6aa..df06f03624d6 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -302,6 +302,7 @@ wdog3: watchdog@292a0000 {
assigned-clocks = <&pcc3 IMX8ULP_CLK_WDOG3>;
assigned-clock-parents = <&cgc1 IMX8ULP_CLK_SOSC_DIV2>;
timeout-sec = <40>;
+ bootph-all;
};
cgc1: clock-controller@292c0000 {
diff --git a/arch/arm64/boot/dts/freescale/imx91_93_common.dtsi b/arch/arm64/boot/dts/freescale/imx91_93_common.dtsi
index 46a5d2df074d..a1a7e6a0571b 100644
--- a/arch/arm64/boot/dts/freescale/imx91_93_common.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx91_93_common.dtsi
@@ -525,6 +525,7 @@ wdog3: watchdog@42490000 {
clocks = <&clk IMX93_CLK_WDOG3_GATE>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
};
wdog4: watchdog@424a0000 {
@@ -534,6 +535,7 @@ wdog4: watchdog@424a0000 {
clocks = <&clk IMX93_CLK_WDOG4_GATE>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
};
wdog5: watchdog@424b0000 {
@@ -543,6 +545,7 @@ wdog5: watchdog@424b0000 {
clocks = <&clk IMX93_CLK_WDOG5_GATE>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
};
tpm3: pwm@424e0000 {
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index c460ece6070f..9420519b5be1 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -1283,6 +1283,18 @@ wdog3: watchdog@49220000 {
timeout-sec = <40>;
fsl,ext-reset-output;
status = "disabled";
+ bootph-all;
+ };
+
+ wdog4: watchdog@49230000 {
+ compatible = "fsl,imx94-wdt", "fsl,imx93-wdt";
+ reg = <0x49230000 0x10000>;
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&scmi_clk IMX94_CLK_BUSWAKEUP>;
+ timeout-sec = <40>;
+ fsl,ext-reset-output;
+ status = "disabled";
+ bootph-all;
};
};
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 71394871d8dd..7caacdc819c4 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -795,6 +795,17 @@ wdog3: watchdog@42490000 {
clocks = <&scmi_clk IMX95_CLK_BUSWAKEUP>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
+ };
+
+ wdog4: watchdog@424a0000 {
+ compatible = "fsl,imx93-wdt";
+ reg = <0x424a0000 0x10000>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&scmi_clk IMX95_CLK_BUSWAKEUP>;
+ timeout-sec = <40>;
+ status = "disabled";
+ bootph-all;
};
tpm3: pwm@424e0000 {
diff --git a/arch/arm64/boot/dts/freescale/imx952.dtsi b/arch/arm64/boot/dts/freescale/imx952.dtsi
index b30707837f35..59f829004000 100644
--- a/arch/arm64/boot/dts/freescale/imx952.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx952.dtsi
@@ -349,6 +349,17 @@ wdog3: watchdog@420b0000 {
clocks = <&scmi_clk IMX952_CLK_BUSWAKEUP>;
timeout-sec = <40>;
status = "disabled";
+ bootph-all;
+ };
+
+ wdog4: watchdog@420c0000 {
+ compatible = "fsl,imx93-wdt";
+ reg = <0x420c0000 0x10000>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&scmi_clk IMX952_CLK_BUSWAKEUP>;
+ timeout-sec = <40>;
+ status = "disabled";
+ bootph-all;
};
tpm3: pwm@42100000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v7] drm/bridge: imx8qxp-pxl2dpi: avoid ERR_PTR with device_node cleanup
From: Liu Ying @ 2026-05-12 2:24 UTC (permalink / raw)
To: Guangshuo Li
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Luca Ceresoli, dri-devel, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <20260507100604.667731-1-lgs201920130244@gmail.com>
On Thu, May 07, 2026 at 06:06:03PM +0800, Guangshuo Li wrote:
> imx8qxp_pxl2dpi_get_available_ep_from_port() returns ERR_PTR()
> on errors. imx8qxp_pxl2dpi_find_next_bridge() stores its return
> value in a __free(device_node) variable before checking IS_ERR().
> When the function returns on the error path, the cleanup action calls
> of_node_put() on the ERR_PTR() value.
>
> Do not let a device_node cleanup variable hold error pointers. Change
> imx8qxp_pxl2dpi_get_available_ep_from_port() to return an int and pass
> the endpoint node through an output argument. Initialize the output
> argument to NULL so callers hold either NULL on error paths or a valid
> device_node pointer on successful path.
>
> Fixes: ceea3f7806a10 ("drm/bridge: imx8qxp-pxl2dpi: simplify put of device_node pointers")
> Cc: stable@vger.kernel.org
> Reviewed-by: Liu Ying <victor.liu@nxp.com>
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> v7:
> - Rephrase the commit message sentence about output argument
> initialization as suggested by Liu Ying.
> - Drop the unnecessary sentence about keeping explicit of_node_put()
> usage.
> - Add Liu Ying's Reviewed-by tag.
> - No code changes.
>
> v6:
> - Change imx8qxp_pxl2dpi_get_available_ep_from_port() to return int
> and pass the endpoint through an output argument.
> - Keep using __free(device_node) in imx8qxp_pxl2dpi_find_next_bridge().
> - Keep ep initialized to NULL in imx8qxp_pxl2dpi_find_next_bridge()
> to satisfy the __free pointer initialization requirement.
> - Do not add cleanup action usage in
> imx8qxp_pxl2dpi_get_available_ep_from_port() or
> imx8qxp_pxl2dpi_set_pixel_link_sel().
>
> v5:
> - Make the fix minimal for stable by avoiding __free(device_node)
> for the endpoint node in imx8qxp_pxl2dpi_find_next_bridge().
> - Keep imx8qxp_pxl2dpi_get_available_ep_from_port() unchanged.
> - Do not change imx8qxp_pxl2dpi_set_pixel_link_sel().
> - Drop Frank's Reviewed-by tag due to the implementation change.
>
> v4:
> - Drop the sentence mentioning the custom static analysis tool.
> - Add Frank's Reviewed-by tag.
> - No functional code changes.
>
> v3:
> - Do not change DEFINE_FREE(device_node, ...).
> - Fix the driver pattern by making
> imx8qxp_pxl2dpi_get_available_ep_from_port() return an int and
> pass the endpoint via an output argument.
> - Update both callers so __free(device_node) never holds ERR_PTR().
>
> v2:
> - Fix DEFINE_FREE(device_node, ...) directly.
>
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 40 +++++++++++---------
> 1 file changed, 23 insertions(+), 17 deletions(-)
Applied to misc/kernel.git (drm-misc-fixes), thanks!
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH net-next v4 00/13] net: lan966x: add support for PCIe FDMA
From: Jakub Kicinski @ 2026-05-12 2:20 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260508-lan966x-pci-fdma-v4-0-14e0c89d8d63@microchip.com>
On Fri, 8 May 2026 09:35:24 +0200 Daniel Machon wrote:
> When lan966x operates as a PCIe endpoint, the driver currently uses
> register-based I/O for frame injection and extraction. This approach is
> functional but slow, topping out at around 33 Mbps on an Intel x86 host
> with a lan966x PCIe card.
Looks like sashiko-bot responded but only CCed bpf@
Please let us know if all the issues are false positives,
I'm going to assume for now that at least one of the issues
is real :)
^ permalink raw reply
* RE: [PATCH v6 1/2] media: dt-bindings: Add CSI Pixel Formatter DT bindings
From: G.N. Zhou (OSS) @ 2026-05-12 2:15 UTC (permalink / raw)
To: Marco Felsch, G.N. Zhou (OSS)
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Laurent Pinchart, Frank Li, imx@lists.linux.dev,
Krzysztof Kozlowski, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, G.N. Zhou,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <yez4p77eclr4hfhb5ytyr64ponp4plpefxhfszqfvdinpvamuv@jod7fsgilowq>
Hi Macro,
Thank you for the review and the valid point!
> -----Original Message-----
> From: Marco Felsch <m.felsch@pengutronix.de>
> Sent: Monday, May 11, 2026 7:46 PM
> To: G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <s.hauer@pengutronix.de>; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Laurent
> Pinchart <laurent.pinchart@ideasonboard.com>; Frank Li <frank.li@nxp.com>;
> imx@lists.linux.dev; Krzysztof Kozlowski
> <krzysztof.kozlowski@oss.qualcomm.com>; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; G.N. Zhou <guoniu.zhou@nxp.com>; linux-arm-
> kernel@lists.infradead.org; linux-media@vger.kernel.org
> Subject: Re: [PATCH v6 1/2] media: dt-bindings: Add CSI Pixel Formatter DT
> bindings
>
> [You don't often get email from m.felsch@pengutronix.de. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On 26-05-11, Guoniu Zhou wrote:
> > From: Guoniu Zhou <guoniu.zhou@nxp.com>
> >
> > The i.MX9 CSI pixel formatting module uses packet info, pixel and
> > non-pixel data from the CSI-2 host controller and reformat them to
> > match Pixel Link(PL) definition.
>
> Sorry for chiming in very late, but can you please provide on which
> i.MX9 devices this formatting module is present? I've checked the i.MX93
> reference manual and found no info instead I found a CAMERA_MUX register
> which does something similiar but is not the same. Please provide a more
> specific compatible if this IP is only be present on i.MX95 devices.
You're right. I initially used "imx9" because this CSI formatter IP is present on
both i.MX95 and i.MX952 (not on i.MX93 as you correctly noted). However, I
agree this naming is confusing and could mislead people into thinking it's available
across all i.MX9 series devices.
I'll change the compatible to "fsl,imx95-csi-formatter" as the current driver
only supports i.MX95. When i.MX952 support is added in the future, we can
extend the compatible string accordingly (e.g., using "fsl,imx952-csi-formatter"
with "fsl,imx95-csi-formatter" as fallback if they're compatible).
Thanks again for catching this!
Best Regards
G.N Zhou
>
> Regards,
> Marco
>
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > Reviewed-by: Krzysztof Kozlowski
> > <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> > ---
> > .../bindings/media/fsl,imx9-csi-formatter.yaml | 87
> ++++++++++++++++++++++
> > 1 file changed, 87 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/media/fsl,imx9-csi-formatter.yaml
> > b/Documentation/devicetree/bindings/media/fsl,imx9-csi-formatter.yaml
> > new file mode 100644
> > index 000000000000..774d37d2b987
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/fsl,imx9-csi-formatter.y
> > +++ aml
> > @@ -0,0 +1,87 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/fsl,imx9-csi-formatter.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: i.MX9 CSI Pixel Formatter
> > +
> > +maintainers:
> > + - Guoniu Zhou <guoniu.zhou@nxp.com>
> > +
> > +description:
> > + The CSI pixel formatting module uses packet info, pixel and
> > +non-pixel
> > + data from the CSI-2 host controller and reformat them to match
> > +Pixel
> > + Link(PL) definition.
> > +
> > +properties:
> > + compatible:
> > + const: fsl,imx9-csi-formatter
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > +
> > + properties:
> > + port@0:
> > + $ref: /schemas/graph.yaml#/$defs/port-base
> > + unevaluatedProperties: false
> > + description: MIPI CSI-2 RX IDI interface
> > +
> > + properties:
> > + endpoint:
> > + $ref: video-interfaces.yaml#
> > + unevaluatedProperties: false
> > +
> > + port@1:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: Pixel Link Interface
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - power-domains
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/nxp,imx95-clock.h>
> > +
> > + formatter@20 {
> > + compatible = "fsl,imx9-csi-formatter";
> > + reg = <0x20 0x100>;
> > + clocks = <&cameramix_csr IMX95_CLK_CAMBLK_CSI2_FOR0>;
> > + power-domains = <&scmi_devpd 3>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + endpoint {
> > + remote-endpoint = <&mipi_csi_0_out>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + endpoint {
> > + remote-endpoint = <&isi_in_2>;
> > + };
> > + };
> > + };
> > + };
> >
> > --
> > 2.34.1
> >
> >
> >
>
> --
> #gernperDu
> #CallMeByMyFirstName
>
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | https://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* Re: [PATCH v4 1/4] kernel: param: initialize module_kset before do_initcalls()
From: Shashank Balaji @ 2026-05-12 2:12 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter
Cc: Gary Guo, Suzuki K Poulose, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Richard Cochran, Jonathan Corbet, Shuah Khan,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Mike Leach, Leo Yan, Rahul Bukte, linux-kernel,
coresight, linux-arm-kernel, driver-core, rust-for-linux,
linux-doc, Daniel Palmer, Tim Bird, linux-modules, linux-tegra
In-Reply-To: <afCxHUrjr3Z22U6V@JPC00244420>
Hi Thierry, Jonathan,
Just following up on the below, would moving tegra194_cbb_driver and
tegra234_cbb_driver from pure_initcall to core_initcall work for you?
Thanks,
Shashank
On Tue, Apr 28, 2026 at 10:07:41PM +0900, Shashank Balaji wrote:
> Adding Tegra maintainers.
>
> On Tue, Apr 28, 2026 at 12:10:50PM +0100, Gary Guo wrote:
> > On Tue Apr 28, 2026 at 1:37 AM BST, Shashank Balaji wrote:
> > > Hi Gary,
> > >
> > > On Mon, Apr 27, 2026 at 02:29:55PM +0100, Gary Guo wrote:
> > >> On Mon Apr 27, 2026 at 3:41 AM BST, Shashank Balaji wrote:
> > >> > module_kset is initialized in param_sysfs_init(), a subsys_initcall. A number
> > >> > of platform drivers register themselves prior to subsys_initcalls
> > >> > (tegra194_cbb_driver registers in a pure_initcall, for example). With an
> > >> > upcoming patch ("driver core: platform: set mod_name in driver registration")
> > >> > that sets their mod_name in struct device_driver, lookup_or_create_module_kobject()
> > >> > will be called for those drivers, which calls kset_find_obj(module_kset, mod_name).
> > >> > This causes a null deref because module_kset isn't alive yet.
> > >> >
> > >> > Fix this by initializing module_kset in do_basic_setup() before do_initcalls().
> > >> > Modernize the pr_warn while we're at it.
> > >> >
> > >> > Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >> > Suggested-by: Gary Guo <gary@garyguo.net>
> > >>
> > >> I didn't suggest this change :)
> > >>
> > >> I suggested `pure_initcall`, which is just a one line change.
> > >
> > > Oops, sorry about the misattribution.
> > >
> > >> diff --git a/kernel/params.c b/kernel/params.c
> > >> index 74d620bc2521..ac088d4b09a9 100644
> > >> --- a/kernel/params.c
> > >> +++ b/kernel/params.c
> > >> @@ -957,7 +957,7 @@ static int __init param_sysfs_init(void)
> > >>
> > >> return 0;
> > >> }
> > >> -subsys_initcall(param_sysfs_init);
> > >> +pure_initcall(param_sysfs_init);
> > >>
> > >> /*
> > >> * param_sysfs_builtin_init - add sysfs version and parameter
> > >>
> > >> pure_initcall is level 0 so it happens before all other init calls. Does it not
> > >> work?
> > >
> > > tegra194_cbb_driver registers itself in a pure_initcall too. We wouldn't
> > > want the ordering of its registration and module_kset init to be link order
> > > dependent.
> >
> > It's the only device driver that does this. And I don't think it's supposed to.
> >
> > >From documentation:
> >
> > > A "pure" initcall has no dependencies on anything else, and purely
> > > initializes variables that couldn't be statically initialized.
> >
> > I understand that given large amount of drivers registering themselves during
> > core/arch_initcall that there might be regressions if all of them are moved, but
> > surely we can demote these two specific tegra driver to core/postcore_initcall?
> > This will still be called earlier than init_machine call which happens during
> > arch_initcall.
> >
> > Looks like the tegra CBB driver is just doing error logging anyway.
>
> That's a good point, Gary. Thanks!
>
> Hi Thierry and Jonathan,
>
> You can find the context for this email in this patch:
> https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/
>
> TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
> registering themselves as early as in a pure_initcall. This is a problem
> on two fronts:
> 1. Philosophical: As Gary pointed out, pure_initcalls are intended to purely
> initialize variables that couldn't be statically initialized. But these
> are doing driver registrations.
> 2. module_kset not initialized at pure_initcall stage: This is needed to
> set the module sysfs symlink. Since module_kset is not alive yet during
> pure_initcalls, registering these drivers panics the kernel.
>
> We would like to do the tegra cbb driver registration in a core_initcall
> (or some later initcall works too), and move module_kset initialization
> to a pure_initcall. Like this:
>
> diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c b/drivers/soc/tegra/cbb/tegra194-cbb.c
> index ab75d50cc85c..2f69e104c838 100644
> --- a/drivers/soc/tegra/cbb/tegra194-cbb.c
> +++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
> @@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
> {
> return platform_driver_register(&tegra194_cbb_driver);
> }
> -pure_initcall(tegra194_cbb_init);
> +core_initcall(tegra194_cbb_init);
>
> static void __exit tegra194_cbb_exit(void)
> {
> diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c b/drivers/soc/tegra/cbb/tegra234-cbb.c
> index fb26f085f691..785072fa4e85 100644
> --- a/drivers/soc/tegra/cbb/tegra234-cbb.c
> +++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
> @@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
> {
> return platform_driver_register(&tegra234_cbb_driver);
> }
> -pure_initcall(tegra234_cbb_init);
> +core_initcall(tegra234_cbb_init);
>
> static void __exit tegra234_cbb_exit(void)
> {
>
> Would this work?
>
> Thanks,
> Shashank
>
^ permalink raw reply
* Re: [PATCH v12 2/5] regulator: Add support for MediaTek MT6373 SPMI PMIC Regulators
From: Mark Brown @ 2026-05-12 2:04 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <20260511101355.122478-3-angelogioacchino.delregno@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
On Mon, May 11, 2026 at 12:13:52PM +0200, AngeloGioacchino Del Regno wrote:
> +static int mt6373_buck_unlock(struct regmap *map, bool unlock)
> +{
> + u16 buf = unlock ? MT6373_BUCK_TOP_UNLOCK_VALUE : 0;
> +
> + return regmap_bulk_write(map, MT6373_BUCK_TOP_KEY_PROT_LO, &buf, sizeof(buf));
regmap_bulk_write() takes a number of registers.
> +static irqreturn_t mt6373_oc_isr(int irq, void *data)
> +{
> + struct regulator_dev *rdev = (struct regulator_dev *)data;
> + struct mt6373_regulator_info *info = rdev_get_drvdata(rdev);
> +
> + disable_irq_nosync(info->virq);
> +
> + if (regulator_is_enabled_regmap(rdev))
> + regulator_notifier_call_chain(rdev, REGULATOR_EVENT_OVER_CURRENT, NULL);
If the hardware is reporting an error we should report an error.
> + INIT_DELAYED_WORK(&info->oc_work, mt6373_oc_irq_enable_work);
What stops this work on driver removal/unbind?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v4] coresight: fix missing error code when trace ID is invalid
From: Jie Gan @ 2026-05-12 1:56 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, Richard Cheng, Jie Gan
When coresight_path_assign_trace_id() cannot assign a valid trace ID,
coresight_enable_sysfs() takes the err_path goto with ret still 0,
returning success to the caller despite no trace session being started.
Change coresight_path_assign_trace_id() to return int, moving the
IS_VALID_CS_TRACE_ID() check inside it so it returns -EINVAL on failure
and 0 on success. Update both callers to propagate this return value
directly instead of inspecting path->trace_id after the call.
Fixes: d87d76d823d1 ("Coresight: Allocate trace ID after building the path")
Reviewed-by: James Clark <james.clark@linaro.org>
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v4:
- Refactor the coresight_path_assign_trace_id according to Leo's suggestion.
- Link to v3: https://lore.kernel.org/r/20260511-fix-trace-id-error-v3-1-ac4c8356efff@oss.qualcomm.com
Changes in v3:
- directly return the value for clear expression.
- Link to v2: https://lore.kernel.org/r/20260509-fix-trace-id-error-v2-1-c900bcbab3e9@oss.qualcomm.com
Changes in v2:
- Refactor the coresight_path_assign_trace_id function.
- Link to v1: https://lore.kernel.org/r/20260508-fix-trace-id-error-v1-1-5f11a5456fdf@oss.qualcomm.com
---
drivers/hwtracing/coresight/coresight-core.c | 23 +++++++++++++----------
drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +++--
drivers/hwtracing/coresight/coresight-priv.h | 2 +-
drivers/hwtracing/coresight/coresight-sysfs.c | 4 ++--
4 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 46f247f73cf6..2105bb813940 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -739,8 +739,8 @@ static int coresight_get_trace_id(struct coresight_device *csdev,
* Call this after creating the path and before enabling it. This leaves
* the trace ID set on the path, or it remains 0 if it couldn't be assigned.
*/
-void coresight_path_assign_trace_id(struct coresight_path *path,
- enum cs_mode mode)
+int coresight_path_assign_trace_id(struct coresight_path *path,
+ enum cs_mode mode)
{
struct coresight_device *sink = coresight_get_sink(path);
struct coresight_node *nd;
@@ -750,15 +750,18 @@ void coresight_path_assign_trace_id(struct coresight_path *path,
/* Assign a trace ID to the path for the first device that wants to do it */
trace_id = coresight_get_trace_id(nd->csdev, mode, sink);
- /*
- * 0 in this context is that it didn't want to assign so keep searching.
- * Non 0 is either success or fail.
- */
- if (trace_id != 0) {
- path->trace_id = trace_id;
- return;
- }
+ /* 0 means the device has no ID assignment, so keep searching */
+ if (trace_id == 0)
+ continue;
+
+ if (!IS_VALID_CS_TRACE_ID(trace_id))
+ return -EINVAL;
+
+ path->trace_id = trace_id;
+ return 0;
}
+
+ return -EINVAL;
}
/**
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f85dedf89a3f..89ba7c9a6613 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -324,6 +324,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
struct coresight_device *sink = NULL;
struct coresight_device *user_sink = NULL, *last_sink = NULL;
struct etm_event_data *event_data = NULL;
+ int ret;
event_data = alloc_event_data(cpu);
if (!event_data)
@@ -420,8 +421,8 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
}
/* ensure we can allocate a trace ID for this CPU */
- coresight_path_assign_trace_id(path, CS_MODE_PERF);
- if (!IS_VALID_CS_TRACE_ID(path->trace_id)) {
+ ret = coresight_path_assign_trace_id(path, CS_MODE_PERF);
+ if (ret) {
cpumask_clear_cpu(cpu, mask);
coresight_release_path(path);
continue;
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 1ea882dffd70..34c7e792adbd 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -153,7 +153,7 @@ int coresight_make_links(struct coresight_device *orig,
void coresight_remove_links(struct coresight_device *orig,
struct coresight_connection *conn);
u32 coresight_get_sink_id(struct coresight_device *csdev);
-void coresight_path_assign_trace_id(struct coresight_path *path,
+int coresight_path_assign_trace_id(struct coresight_path *path,
enum cs_mode mode);
#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM3X)
diff --git a/drivers/hwtracing/coresight/coresight-sysfs.c b/drivers/hwtracing/coresight/coresight-sysfs.c
index d2a6ed8bcc74..b6a870399e83 100644
--- a/drivers/hwtracing/coresight/coresight-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-sysfs.c
@@ -211,8 +211,8 @@ int coresight_enable_sysfs(struct coresight_device *csdev)
goto out;
}
- coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
- if (!IS_VALID_CS_TRACE_ID(path->trace_id))
+ ret = coresight_path_assign_trace_id(path, CS_MODE_SYSFS);
+ if (ret)
goto err_path;
ret = coresight_enable_path(path, CS_MODE_SYSFS);
---
base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
change-id: 20260508-fix-trace-id-error-dbfdd4d8f2d1
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v12 1/5] dt-bindings: regulator: Document MediaTek MT6373 PMIC Regulators
From: Mark Brown @ 2026-05-12 1:39 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <20260511101355.122478-2-angelogioacchino.delregno@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Mon, May 11, 2026 at 12:13:51PM +0200, AngeloGioacchino Del Regno wrote:
> Add bindings for the regulators found in the MediaTek MT6363 PMIC,
> usually found in board designs using the MT6991 Dimensity 9400 and
> on MT8196 Kompanio SoC for Chromebooks, along with the MT6316 and
> MT6363 PMICs.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers: altera_edac: Guard SDRAM irq2 retrieval for Arria10 only
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-05-12 1:37 UTC (permalink / raw)
To: Dinh Nguyen, bp@alien8.de, tony.luck@intel.com
Cc: linux-edac@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <cc767b60-3b91-40d5-aa70-c5f252d1d39b@kernel.org>
On 11/5/2026 7:54 pm, Dinh Nguyen wrote:
>
>
> On 5/8/26 02:52, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>
>> Guard the irq2 retrieval with an of_machine_is_compatible() check so
>> that platform_get_irq(pdev, 1) is only called on Arria10 platforms.
>>
>> Signed-off-by: Nazim Amirul
>> <muhammad.nazim.amirul.nazle.asmade@altera.com>
>> Signed-off-by: Niravkumar L Rabara <nirav.rabara@altera.com>
>> ---
>> drivers/edac/altera_edac.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
>> index 4edd2088c2db..b30302198cd4 100644
>> --- a/drivers/edac/altera_edac.c
>> +++ b/drivers/edac/altera_edac.c
>> @@ -348,7 +348,8 @@ static int altr_sdram_probe(struct platform_device
>> *pdev)
>> }
>> /* Arria10 has a 2nd IRQ */
>> - irq2 = platform_get_irq(pdev, 1);
>> + if (of_machine_is_compatible("altr,socfpga-arria10"))
>> + irq2 = platform_get_irq(pdev, 1);
>> layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
>> layers[0].size = 1;
>
> Why? We already switch on arria10 later in the same function.
>
> Sorry, but NAK.
>
> Dinh
This driver were used by cyclone5 and arria10. Cyclone5 only has one
interrupt whereby arria10 has 2 interrupt. That is the reason why the
interrupt was guard by (of_machine_is_compatible("altr,socfpga-arria10"))
Nazim
^ permalink raw reply
* Re: [PATCH PARTIAL-RESEND v12 0/5] Add support MT6316/6363/MT6373 PMICs regulators and MFD
From: Mark Brown @ 2026-05-12 1:25 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <20260511101355.122478-1-angelogioacchino.delregno@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Mon, May 11, 2026 at 12:13:50PM +0200, AngeloGioacchino Del Regno wrote:
> Changes in v12:
> - This is a partial resend. MT6373 regulators and MFD patches were not picked.
> - Rebased over next-20260508
Is there a reason why this is a single patch series, are there any
interdependencies here?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 0/8] unwind, arm64: add sframe unwinder for kernel
From: Dylan Hatch @ 2026-05-12 1:10 UTC (permalink / raw)
To: Jens Remus
Cc: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Mark Rutland, Prasanna Kumar T S M, Puranjay Mohan,
Song Liu, joe.lawrence, linux-toolchains, linux-kernel,
live-patching, linux-arm-kernel, Randy Dunlap, Heiko Carstens
In-Reply-To: <549d10b6-ba2b-4ae9-86ef-6157e13b6ee3@linux.ibm.com>
On Thu, Apr 30, 2026 at 3:11 AM Jens Remus <jremus@linux.ibm.com> wrote:
>
> On 4/28/2026 8:36 PM, Dylan Hatch wrote:
> > Implement a generic kernel sframe-based [1] unwinder. The main goal is
> > to improve reliable stacktrace on arm64 by unwinding across exception
> > boundaries.
>
> Please add support to initialize the optional sframe unwinder debug
> information. Either in the appropriate patches in this series or as a
> separate patch.
Sounds good, I'll add this in as a separate patch in the next version.
>
> Note that for the module case I wonder whether it would be preferable
> to somehow indicate that it is a module name in the string, e.g.
> "(<module-name>)" or "<module-name> (module)"?
I don't have a strong preference, though I agree it makes sense to
indicate that the section is from a module. For now I'll add the
parentheses "(<module-name>)".
>
> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> --- a/kernel/unwind/sframe.c
> +++ b/kernel/unwind/sframe.c
> @@ -1028,6 +1028,8 @@ void __init init_sframe_table(void)
> kernel_sfsec.text_start = (unsigned long)_stext;
> kernel_sfsec.text_end = (unsigned long)_etext;
>
> + dbg_init(&kernel_sfsec);
> +
> if (WARN_ON(sframe_read_header(&kernel_sfsec)))
> return;
> if (WARN_ON(sframe_validate_section(&kernel_sfsec)))
> @@ -1047,6 +1049,8 @@ void sframe_module_init(struct module *mod, void *sframe, size_t sframe_size,
> sec->text_start = (unsigned long)text;
> sec->text_end = (unsigned long)text + text_size;
>
> + dbg_init(sec);
> +
> if (WARN_ON(sframe_read_header(sec)))
> return;
> if (WARN_ON(sframe_validate_section(sec)))
> diff --git a/kernel/unwind/sframe_debug.h b/kernel/unwind/sframe_debug.h
> --- a/kernel/unwind/sframe_debug.h
> +++ b/kernel/unwind/sframe_debug.h
> @@ -32,6 +32,18 @@ static inline void dbg_init(struct sframe_section *sec)
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
>
> + if (sec->sec_type == SFRAME_KERNEL) {
> + if (sec == &kernel_sfsec) {
> + sec->filename = kstrdup("(vmlinux)", GFP_KERNEL);
> + } else {
> + struct module *mod = container_of(sec, struct module,
> + arch.sframe_sec);
> + sec->filename = kstrdup(mod->name, GFP_KERNEL);
> + }
> +
> + return;
> + }
> +
> guard(mmap_read_lock)(mm);
> vma = vma_lookup(mm, sec->sframe_start);
> if (!vma)
>
> Regards,
> Jens
> --
> Jens Remus
> Linux on Z Development (D3303)
> jremus@de.ibm.com / jremus@linux.ibm.com
>
> IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
> IBM Data Privacy Statement: https://www.ibm.com/privacy/
>
Thanks for the suggestion,
Dylan
^ permalink raw reply
* Re: [PATCH 1/2] drm/rockchip: dsi: Add maximum per lane bit rate calculation
From: Chaoyi Chen @ 2026-05-12 1:07 UTC (permalink / raw)
To: Heiko Stübner
Cc: Chaoyi Chen, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Guochun Huang, dri-devel, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260324085838.90-1-kernel@airkyi.com>
Hi,
On 3/24/2026 4:58 PM, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> Different chips have varying support for the maximum bit rate per lane.
>
> Add calculation for the maximum per lane bit rate for various chip
> platforms, and relax the bandwidth margin requirements.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> ---
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 21 +++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 3547d91b25d3..d3bacfae174e 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -268,6 +268,7 @@ struct rockchip_dw_dsi_chip_data {
>
> unsigned int flags;
> unsigned int max_data_lanes;
> + unsigned long max_bit_rate_per_lane;
> };
>
> struct dw_mipi_dsi_rockchip {
> @@ -565,7 +566,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
> int bpp;
> unsigned long mpclk, tmp;
> unsigned int target_mbps = 1000;
> - unsigned int max_mbps = dppa_map[ARRAY_SIZE(dppa_map) - 1].max_mbps;
> + unsigned int max_mbps;
> unsigned long best_freq = 0;
> unsigned long fvco_min, fvco_max, fin, fout;
> unsigned int min_prediv, max_prediv;
> @@ -573,6 +574,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
> unsigned long _fbdiv, best_fbdiv;
> unsigned long min_delta = ULONG_MAX;
>
> + max_mbps = dsi->cdata->max_bit_rate_per_lane;
> dsi->format = format;
> bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> if (bpp < 0) {
> @@ -584,8 +586,8 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
>
> mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
> if (mpclk) {
> - /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
> - tmp = mpclk * (bpp / lanes) * 10 / 8;
> + /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
> + tmp = mpclk * (bpp / lanes) * 10 / 9;
> if (tmp < max_mbps)
> target_mbps = tmp;
> else
> @@ -595,7 +597,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
>
> /* for external phy only a the mipi_dphy_config is necessary */
> if (dsi->phy) {
> - phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 8,
> + phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 9,
> bpp, lanes,
> &dsi->phy_opts.mipi_dphy);
> dsi->lane_mbps = target_mbps;
> @@ -1503,6 +1505,7 @@ static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
> PX30_DSI_FORCETXSTOPMODE), 0),
>
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1000000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1515,6 +1518,7 @@ static const struct rockchip_dw_dsi_chip_data rk3128_chip_data[] = {
> RK3128_DSI_FORCERXMODE |
> RK3128_DSI_FORCETXSTOPMODE), 0),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1000000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1527,6 +1531,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
> .lcdsel_lit = FIELD_PREP_WM16_CONST(RK3288_DSI0_LCDC_SEL, 1),
>
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> {
> .reg = 0xff964000,
> @@ -1535,6 +1540,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
> .lcdsel_lit = FIELD_PREP_WM16_CONST(RK3288_DSI1_LCDC_SEL, 1),
>
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1547,6 +1553,7 @@ static const struct rockchip_dw_dsi_chip_data rk3368_chip_data[] = {
> RK3368_DSI_FORCETXSTOPMODE |
> RK3368_DSI_FORCERXMODE), 0),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1634,6 +1641,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
>
> .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> {
> .reg = 0xff968000,
> @@ -1658,6 +1666,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
>
> .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1500000000UL,
>
> .dphy_rx_init = rk3399_dphy_tx1rx1_init,
> .dphy_rx_power_on = rk3399_dphy_tx1rx1_power_on,
> @@ -1674,6 +1683,7 @@ static const struct rockchip_dw_dsi_chip_data rk3506_chip_data[] = {
> FIELD_PREP_WM16_CONST(RK3506_DSI_FORCERXMODE, 0) |
> FIELD_PREP_WM16_CONST(RK3506_DSI_FORCETXSTOPMODE, 0)),
> .max_data_lanes = 2,
> + .max_bit_rate_per_lane = 1500000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1687,6 +1697,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
> FIELD_PREP_WM16_CONST(RK3568_DSI0_TURNDISABLE, 0) |
> FIELD_PREP_WM16_CONST(RK3568_DSI0_FORCERXMODE, 0)),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1200000000UL,
> },
> {
> .reg = 0xfe070000,
> @@ -1696,6 +1707,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
> FIELD_PREP_WM16_CONST(RK3568_DSI1_TURNDISABLE, 0) |
> FIELD_PREP_WM16_CONST(RK3568_DSI1_FORCERXMODE, 0)),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1200000000UL,
> },
> { /* sentinel */ }
> };
> @@ -1708,6 +1720,7 @@ static const struct rockchip_dw_dsi_chip_data rv1126_chip_data[] = {
> FIELD_PREP_WM16_CONST(RV1126_DSI_FORCERXMODE, 0) |
> FIELD_PREP_WM16_CONST(RV1126_DSI_FORCETXSTOPMODE, 0)),
> .max_data_lanes = 4,
> + .max_bit_rate_per_lane = 1000000000UL,
> },
> { /* sentinel */ }
> };
Gentle ping about this.
Thanks!
--
Best,
Chaoyi
^ 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