* Re: [PATCH v5 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: sashiko-bot @ 2026-06-17 8:18 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: devicetree, conor+dt, dri-devel, robh
In-Reply-To: <20260617080031.99156-15-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Out-of-bounds bitmask shift causes regcache pollution and unnecessary I2C bus writes for LM3533_REG_OUTPUT_CONF1.
--
commit a74553be2d2b60a05a193e9dc35527d3d4a425da
Author: Svyatoslav Ryhel <clamor95@gmail.com>
video: leds: backlight: lm3533: Support getting LED sources from DT
This commit adds Control Bank to HVLED/LVLED muxing support based on
the led-sources defined in the device tree.
> diff --git a/drivers/leds/leds-lm3533.c b/drivers/leds/leds-lm3533.c
> index ed810c23f30f3..9e07953814fdd 100644
> --- a/drivers/leds/leds-lm3533.c
> +++ b/drivers/leds/leds-lm3533.c
[ ... ]
> @@ -623,8 +631,36 @@ static const struct attribute_group *lm3533_led_attribute_groups[] = {
>
> static int lm3533_led_setup(struct lm3533_led *led)
> {
> + u32 output_cfg_shift = 0;
> + u32 output_cfg_val = 0;
> + u32 output_cfg_mask = 0;
> int ret;
>
> + if (led->num_leds) {
> + for (int i = 0; i < led->num_leds; i++) {
> + if (led->leds[i] >= LM3533_LVCTRLBANK_MAX)
> + continue;
> +
> + output_cfg_shift = led->leds[i] * 2;
> + output_cfg_val |= led->id << output_cfg_shift;
> + output_cfg_mask |= OUTPUT_LVLED_MASK << output_cfg_shift;
> + }
> +
> + /* LVLED1, LVLED2 and LVLED3 */
> + ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF1,
> + output_cfg_mask << OUTPUT_CONF1_SHIFT,
> + output_cfg_val << OUTPUT_CONF1_SHIFT);
[Severity: Low]
Can this shift cause bits to fall outside the 8-bit register width?
When led-sources specifies LVLED4 or LVLED5, output_cfg_mask accumulates
bits that, when shifted left by OUTPUT_CONF1_SHIFT (which is 2), will exceed
8 bits (for example, forming masks like 0x300 or 0xC00).
Because regmap_update_bits operates on unsigned int internally, these
out-of-bounds bits are applied to the cached register value. This causes
the internal comparison (tmp != orig) to incorrectly evaluate to true,
triggering an unnecessary I2C write.
Although the I2C subsystem harmlessly truncates the value to 8 bits so the
hardware state is not corrupted, does it make sense to apply an explicit
8-bit mask (e.g., & 0xFF) before passing the shifted mask and value to
regmap_update_bits() to prevent regcache pollution and redundant bus traffic?
> + if (ret)
> + return ret;
> +
> + /* LVLED4 and LVLED5 */
> + ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF2,
> + output_cfg_mask >> OUTPUT_CONF2_SHIFT,
> + output_cfg_val >> OUTPUT_CONF2_SHIFT);
> + if (ret)
> + return ret;
> + }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617080031.99156-1-clamor95@gmail.com?part=14
^ permalink raw reply
* [PATCH v3 0/3] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Jun Yan @ 2026-06-17 8:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
- Disable nfc node by default ahead of nand_rb0 pin addition.
- Add missing nand_rb0 pin to fix incomplete NAND pinctrl.
- Disable pcie_phy by default to suppress probe warning.
- Re-enable pcie_phy on S400 board to preserve PCIe functionality.
Changes in v3:
- squash "disable pcie_phy node by default" and "enable pcie_phy in
meson-axg-s400" patches
- Link to v2:
https://lore.kernel.org/all/20260617071604.635627-1-jerrysteve1101@gmail.com/
Changes in v2:
- Add patch to disable nfc node by default.
- Link to v1:
https://lore.kernel.org/all/20260529140605.1070764-1-jerrysteve1101@gmail.com/
Jun Yan (3):
arm64: dts: amlogic: meson-axg: Disable nfc node by default
arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to
nand_all_pins
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 ++++-
2 files changed, 8 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* [PATCH v3 1/3] arm64: dts: amlogic: meson-axg: Disable nfc node by default
From: Jun Yan @ 2026-06-17 8:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617082239.645562-1-jerrysteve1101@gmail.com>
nand_rb0 and emmc_ds share one pad. Before enabling nand_rb0 for nfc,
disable nfc nodes by default to resolve pinctrl resource contention.
No mainline AXG boards enable nfc currently thus no extra DTS adjustments
are needed.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index f1f53fd98ae2..6457667d974e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1999,6 +1999,7 @@ nfc: nand-controller@7800 {
clocks = <&clkc CLKID_SD_EMMC_C>,
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "device";
+ status = "disabled";
};
usb2_phy1: phy@9020 {
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
From: Jun Yan @ 2026-06-17 8:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617082239.645562-1-jerrysteve1101@gmail.com>
The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy)
pin description, which is required for NAND controller operation.
Add it to the pinmux list.
Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 6457667d974e..8ca3ac09b306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -481,7 +481,8 @@ mux {
"nand_ale",
"nand_cle",
"nand_wen_clk",
- "nand_ren_wr";
+ "nand_ren_wr",
+ "nand_rb0";
function = "nand";
input-enable;
bias-pull-up;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/3] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: Jun Yan @ 2026-06-17 8:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617082239.645562-1-jerrysteve1101@gmail.com>
Set the pcie_phy node to "disabled" as it is not used on some boards
and should be enabled per-board when necessary.
This change suppresses the deferred probe warning:
platform ff644000.phy: deferred probe pending: (reason unknown)
The meson-axg dtsi now disables pcie_phy by default, so enable it
for the s400 board to support PCIe functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 285c6ac1dd61..7ba249cc3d56 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -448,6 +448,10 @@ &pcieB {
status = "okay";
};
+&pcie_phy {
+ status = "okay";
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_x20_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 8ca3ac09b306..5b8ef98f6d03 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -328,6 +328,7 @@ pcie_phy: phy@ff644000 {
phys = <&mipi_pcie_analog_dphy>;
phy-names = "analog";
#phy-cells = <0>;
+ status = "disabled";
};
pdm: audio-controller@ff632000 {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Geert Uytterhoeven @ 2026-06-17 8:26 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260617030008.154449-1-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Wed, 17 Jun 2026 at 05:00, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> In case MSI are enabled, but DWC built-in iMSI-RX is not in use, the
> MSI are handled via GIC ITS. Configure all controller MSI registers
> fully.
>
> Set or clear MSI capability register MSICAP0 MSI enable MSIE bit and
> PCIe Interrupt Status 0 Enable register PCIEINTSTS0EN MSI interrupt
> enable MSI_CTRL_INT bit according to MSI enable state, set both bits
> if MSI are enabled, clear both bits if MSI are disabled.
>
> If MSI are disabled, or MSI are enabled and iMSI-RX is used, then
> deconfigure AXIINTCADDR and AXIINTCCONT to 0, which disables any
> pass through of MSI TLPs onto the AXI bus and then further into
> GIC ITS translation registers.
>
> If MSI are enabled and iMSI-RX is not used, the configure AXIINTCADDR
> with target address of GIC ITS translation registers, and configure
> AXIINTCCONT to enable MSI TLP pass through onto AXI bus and into the
> GIC ITS. This specific configuration allows handling of MSI via the
> GIC ITS instead of integrated iMSI-RX.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> @@ -31,6 +31,10 @@
> #define DEVICE_TYPE_RC BIT(4)
> #define BIFUR_MOD_SET_ON BIT(0)
>
> +/* MSI Capability */
> +#define MSICAP0 0x0050
> +#define MSICAP0_MSIE BIT(16)
> +
> /* PCIe Interrupt Status 0 */
> #define PCIEINTSTS0 0x0084
>
> @@ -55,6 +59,16 @@
> #define APP_HOLD_PHY_RST BIT(16)
> #define APP_LTSSM_ENABLE BIT(0)
>
> +/* INTC address */
> +#define AXIINTCADDR 0x0a00
> +/* GITS GIC ITS translation register */
> +#define AXIINTCADDR_VAL 0xf1050000
> +
> +/* INTC control & mask */
> +#define AXIINTCCONT 0x0a04
> +#define INTC_EN BIT(31)
> +#define INTC_MASK GENMASK(11, 2)
> +
> /* PCIe Power Management Control */
> #define PCIEPWRMNGCTRL 0x0070
> #define APP_CLK_REQ_N BIT(11)
> @@ -305,6 +319,39 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
> return rcar;
> }
>
> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> + u32 val;
> +
> + /* Make sure MSICAP0 MSIE is configured. */
> + val = dw_pcie_readl_dbi(dw, MSICAP0);
> + if (pci_msi_enabled())
> + val |= MSICAP0_MSIE;
> + else
> + val &= ~MSICAP0_MSIE;
> + dw_pcie_writel_dbi(dw, MSICAP0, val);
> +
> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
> + /* Clear AXIINTC mapping. */
> + writel(0, rcar->base + AXIINTCADDR);
> + writel(0, rcar->base + AXIINTCCONT);
> + } else {
> + /* Point AXIINTC to GIC ITS and enable. */
> + writel(AXIINTCADDR_VAL, rcar->base + AXIINTCADDR);
> + writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
> + }
> +
> + /* Configure MSI interrupt signal */
> + val = readl(rcar->base + PCIEINTSTS0EN);
> + if (pci_msi_enabled())
> + val |= MSI_CTRL_INT;
> + else
> + val &= ~MSI_CTRL_INT;
> + writel(val, rcar->base + PCIEINTSTS0EN);
> +}
> +
> static int rcar_gen4_pcie_enable_device(struct pci_host_bridge *bridge,
FTR, this has a contextual dependency on "[PATCH v2] PCI: rcar-gen4:
Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes"
(https://lore.kernel.org/all/20260519195219.189323-1-marek.vasut+renesas@mailbox.org).
> struct pci_dev *dev)
> {
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] spi: dt-bindings: microchip,pic32mzda-spi: Convert to DT schema
From: Uday Kiran @ 2026-06-17 8:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: tsbogend, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260617-sturdy-silver-bison-bfb6ba@quoll>
> > Convert Microchip PIC32 SPI controller devicetree binding
> > from legacy text format to DT schema.
>
> Please mention here that you dropped requirement of 'cs-gpios' because
> it is not a mandatory in hardware design nor in current Linux driver...
> and then CHECK it actually against drivers, which will lead you to
> conclusion that maybe it is wrong decision...
Thank you Krzysztof
I rechecked the driver and found that it uses spi_get_csgpiod() for
chip-select handling and sets host->num_chipselect = 1. Therefore, dropping
the cs-gpios requirement during the conversion was not justified.
I'll restore cs-gpios as a required property and resend the series with an
updated changelog.
Regards,
Udaya Kiran Challa
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: sashiko-bot @ 2026-06-17 8:34 UTC (permalink / raw)
To: Jun Yan; +Cc: devicetree, conor+dt, linux-amlogic, robh, neil.armstrong
In-Reply-To: <20260617082239.645562-4-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Enabling `pcie_phy` on `meson-axg-s400.dts` is insufficient to support PCIe functionality because its hardware dependency `mipi_pcie_analog_dphy` remains disabled.
--
commit cd94d06969e9f9a23ea319f406b8e86e8ed9ec44
Author: Jun Yan <jerrysteve1101@gmail.com>
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
This patch disables the pcie_phy node by default in the meson-axg dtsi file
to suppress deferred probe warnings on boards that do not use it. It then
explicitly enables pcie_phy in the meson-axg-s400 board device tree to
preserve its PCIe functionality.
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 285c6ac1dd613..7ba249cc3d569 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
[ ... ]
> @@ -448,6 +448,10 @@ &pcieB {
> status = "okay";
> };
>
> +&pcie_phy {
> + status = "okay";
> +};
[Severity: High]
This is a pre-existing issue, but is it sufficient to only enable pcie_phy
to restore PCIe functionality on the s400 board?
The pcie_phy node depends on the mipi_pcie_analog_dphy analog PHY via its
phys property. Looking at meson-axg.dtsi, mipi_pcie_analog_dphy is disabled
by default:
arch/arm64/boot/dts/amlogic/meson-axg.dtsi:
mipi_pcie_analog_dphy: phy {
compatible = "amlogic,axg-mipi-pcie-analog-phy";
#phy-cells = <0>;
status = "disabled";
};
If the analog PHY is not also overridden to "okay" here in meson-axg-s400.dts,
will the analog PHY driver fail to probe, causing devm_phy_get(dev, "analog")
in the pcie_phy driver to continually return -EPROBE_DEFER?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617082239.645562-1-jerrysteve1101@gmail.com?part=3
^ permalink raw reply
* RE: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Yu-Chun Lin [林祐君] @ 2026-06-17 8:36 UTC (permalink / raw)
To: Michael Walle, Bartosz Golaszewski, Andy Shevchenko
Cc: linusw@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <DJ3QVMZ6XLW9.1M9W541O92QWJ@kernel.org>
Hi Andy, Michael and Bartosz,
> Hi,
>
>On Mon Jun 8, 2026 at 4:10 PM CEST, Bartosz Golaszewski wrote:
>>> On Wed, 3 Jun 2026 02:34:40 +0200, Andy Shevchenko
>>> <andriy.shevchenko@intel.com> said:
>
>>> On Mon, May 25, 2026 at 12:04:09PM +0000, Yu-Chun Lin [林祐君] wrote:
>>>> > On Tue, May 12, 2026 at 11:33:12AM +0800, Yu-Chun Lin wrote:
>>>> > > 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.
>>>> >
>>>> > Hmm... Can't we rather add
>>>> > gpio_regmap_enable_irq()/gpio_regmap_disable_irq()
>>>> > that take regmap or GPIO regmap (whatever suits better for the
>>>> > purpose) and do the magic inside GPIO regmap library code?
>>>
>>>> Thanks for the review! I apologize for the misleading commit message.
>>>> The real reason I need the struct gpio_chip pointer is to properly
>>>> set up a custom IRQ domain. Our SoC GPIO controller is quite
>>>> complex. It routes different trigger types to multiple parent IRQs,
>>>> which doesn't fit the generic regmap_irq framework.
>>>> Therefore, we have to create our own irq_domain and pass it to
>>>> gpio_regmap_config.irq_domain.
>>>>
>>>> The core problem occurs inside our custom irq_domain_ops.map() callback:
>>>>
>>>> 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;
>>>> struct gpio_chip *gc = data->gpio_chip;
>>>>
>>>> /*
>>>> * The second argument MUST be struct gpio_chip *.
>>>> * If we pass our custom data structure here, the kernel will panic later
>>>> * in gpiochip_irq_reqres() when it calls irq_data_get_irq_chip_data()
>>>> * and strictly expects it to be a gpio_chip.
>>>> */
>>>> irq_set_chip_data(irq, gc);
>>>>
>>>> irq_set_lockdep_class(irq, &rtd1625_gpio_irq_lock_class,
>>>> &rtd1625_gpio_irq_request_class);
>>>>
>>>> irq_set_chip_and_handler(irq, &rtd1625_iso_gpio_irq_chip, handle_bad_irq);
>>>> irq_set_noprobe(irq);
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot
>>>> retrieve the gpio_chip instantiated inside gpio-regmap.c to fulfill
>>>> these requirements in our
>>>> map() function.
>
> Why is gpiochip_irq_reqres() called in the first place? Isn't that only
> called if the irq handling is set up via gc->irq.chip and not via
> gpiochip_irqchip_add_domain() like in gpio-regmap?
>
The panic was caused by my driver including 'GPIOCHIP_IRQ_RESOURCE_HELPERS',
which forced the call to 'gpiochip_irq_reqres()' and crashed.
>>> This is all good and needs to be depicted in the cover-letter and/or commit message.
Yes, I will do it.
>>>
>>>> Before I send a v4, I see 3 possible paths:
>>>>
>>>> Option 1: Keep the accessor (Current v3 approach) We keep
>>>> gpio_regmap_get_gpiochip() but I will completely rewrite the commit
>>>> message to explain the custom irq_domain_ops.map and lockdep requirements.
>>>>
>>>> Option 2: Let gpiolib create the irq_domain via gpio_regmap_config
>>>> Instead of creating the irq_domain in our driver, we add all
>>>> necessary IRQ fields (irq_chip, irq_handler, irq_parents, etc.) into
>>>> struct gpio_regmap_config. Then gpio-regmap.c populates the
>>>> gpio_irq_chip structure before calling gpiochip_add_data(). This
>>>> prevents an early return and allows the core gpiolib
>>>> (gpiochip_add_irqchip()) to automatically create the irq_domain for us.
>>>> Drawback: This adds a lot of fields to gpio_regmap_config and might
>>>> violate the original design philosophy of gpio-regmap.c (commit
>>>> ebe363197e52), which explicitly states that it does not implement
>>>> its own IRQ chip and delegates it to the parent driver.
>>>>
>>>> Option 3: Drop gpio-regmap entirely (Revert to v2 approach)
>>>> Currently, all drivers using gpio-regmap (mostly simple CPLDs and
>>>> external I/O cards) use regmap-irq to get their domain. Since our
>>>> SoC has a complex IRQ routing scheme with multiple parents, maybe
>>>> gpio-regmap is simply not the right tool for this hardware, and we
>>>> should just implement a standard GPIO driver directly using gpiolib.
>>>>
>>>> Which approach would you prefer upstream?
>>>
>>> This question to Bart, Linus, and poissibly gpio-regmap stakeholders.
>>> I'm not sure that my personal opinion will be the best fit here.
>>>
>>
>> My preference would be for #2 but I understand that this could risk
>> getting stuck in endless bikeshedding so I'm fine with going #3 with
>> potential for future refactoring if we have more similar users.
>
> Yeah, I'd like to keep that stuff out of gpio-regmap. But I'm on the same boat
> regarding the refactoring if we have more data and potential users.
>
> -michael
Got it. I will go with Option #3 in the upcoming v4 patch.
Therefore, I will drop the patches 2, 3 and 4 from this series, and address
Andy's feedback on patch 6.
Best-regards,
Yu Chun
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Michael Walle @ 2026-06-17 8:44 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], Bartosz Golaszewski,
Andy Shevchenko
Cc: linusw@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <39de4d4ada5446e7a33e48c43f410439@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
Hi,
On Wed Jun 17, 2026 at 10:36 AM CEST, Yu-Chun Lin [林祐君] wrote:
>>>>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot
>>>>> retrieve the gpio_chip instantiated inside gpio-regmap.c to fulfill
>>>>> these requirements in our
>>>>> map() function.
>>
>> Why is gpiochip_irq_reqres() called in the first place? Isn't that only
>> called if the irq handling is set up via gc->irq.chip and not via
>> gpiochip_irqchip_add_domain() like in gpio-regmap?
>>
>
> The panic was caused by my driver including 'GPIOCHIP_IRQ_RESOURCE_HELPERS',
> which forced the call to 'gpiochip_irq_reqres()' and crashed.
But why did you use it if your irq domain isn't managed by the
gpiolib, but rather your own irq domain? Before going with option #3
I'd double check if that is correct in your driver.
-michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] Add RTC support for Renesas RZ/T2H and RZ/N2H SoCs
From: Wolfram Sang @ 2026-06-17 9:18 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
Hi,
> The RTC block is closely related to the RZ/N1 implementation and can
> reuse the existing driver infrastructure when operating in SCMP mode,
> which is required on these SoCs due to their 195.3 kHz RTC input clock.
Yes, I implemented SCMP mode because the (back then) upcoming R-Car X5H
also dropped SUBU mode. And SCMP works on my RZ/N1D board as well, so I
could test it already.
> While the RZ/T2H and RZ/N2H variants do not implement the RTCA0SUBU and
> RTCA0TCR registers present on RZ/N1, those registers are not accessed by
> the driver in SCMP mode, allowing support to be added with minimal
> changes.
Note that even for RZ/N1, RTCA0TCR is marked as "not available".
> The RZ/T2H RTC variant also supports a 1 Hz output signal on the
> RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
> marked as reserved in the RZ/N1 hardware manual, making RZ/T2H a
> distinct RTC variant despite its overall compatibility with the RZ/N1
> implementation.
R-Car X5H is the same for the above as well.
> The series consists of:
> dt-bindings updates to describe the RZ/T2H and RZ/N2H RTC variants,
> driver updates to recognize the new compatible string and enable
> support for these SoCs.
I will review and test in on my N1D-board today.
Thanks for your work and happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Konrad Dybcio @ 2026-06-17 9:30 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <1bcf00ae-2558-4c3a-970d-aee1da0c06f9@oss.qualcomm.com>
On 6/17/26 4:31 AM, Fenglin Wu wrote:
>>> + ret = ptn_bulk_write(h, HAP_PTN_FIFO_DIN_0_REG, &data[i], 4);
>>> + if (ret)
>>> + return ret;
>>> + }
>>> +
>>> + for (; i < len; i++) {
>>> + ret = ptn_write(h, HAP_PTN_FIFO_DIN_1B_REG, (u8)data[i]);
>>> + if (ret)
>>> + return ret;
>>> + }
>> So if i'm reading this right, the first loop will always write
>> 4*(len//4) bytes and the second one will be entered at most once,
>> to write len rem 4 bytes.. should this be an if instead?
>
> I should put a comment for clarification. Here’s some background: FIFO data writing supports both 4-byte bulk writes using registers [HAP_PTN_FIFO_DIN_0_REG ... HAP_PTN_FIFO_DIN_3_REG], and 1-byte writes using the HAP_PTN_FIFO_DIN_1B_REG register. The 4-byte bulk write is more efficient, especially for waveform which has several Kb data, and it helps to reduce software latency when loading effects and reduce the delay in triggering vibration. It also helps prevent the FIFO from running dry during data refill in FIFO-empty interrupts. Typically, we use 4-byte writes for the initial 4-byte aligned data, and 1-byte writes for any trailing remainder.
>
> So it still needs a 'for' loop here since the remainder could be more than 1 byte.
Right, I mentioned len rem 4 but failed to notice it's a
single-byte write.. anyway, a comment here would be good
>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * Configure the hardware FIFO memory boundary.
>>> + * FIFO occupies addresses [0, fifo_len).
>>> + */
>>> +static int haptics_configure_fifo_mmap(struct qcom_haptics *h)
>>> +{
>>> + u32 fifo_len, fifo_units;
>>> +
>>> + /* Config all memory space for FIFO usage for now */
>> What's the not-"for now" endgame for this?
>
> The hardware supports more modes than the two currently supported in the driver. One of these, called 'PAT_MEM' mode, also shares memory space with FIFO mode. However, 'PAT_MEM' requires memory to be pre-reserved and waveform data to be pre-loaded. The entire 8K bytes of memory can be divided into partitions, and it is configurable, with FIFO mode always using the first partition [0, fifo_len], where 'fifo_len' is set via the 'MMAP_FIFO_REG' register. 'PAT_MEM' mode plays waveform using data preloaded in a memory bank defined by the registers 'PATX_MEM_START_ADDR_REG' and 'PATTERN_SPMI_PATX_LEN_REG' (they are not defined in the driver). Since PAT_MEM is mainly intended for hardware-triggered vibrations, such as a signal from a dedicated GPIO triggering a short vibration with a preloaded waveform, and although it also supports software triggers, I haven't found a suitable way to support it well into the driver under input FF framework yet. So, I am currently allocating the
> entire 8K FIFO memory for FIFO mode only. We can adjust this later if we find a better way to incorporate 'PAT_MEM' mode into the driver.
Sounds like a plan.
For the other mode, would that GPIO trigger need any OS intervention?
Could you speak a bit more about how that works?
Konrad
^ permalink raw reply
* Re: [PATCH v6 5/6] remoteproc: qcom: pas: Add late attach support for subsystems
From: Jingyi Wang @ 2026-06-17 9:37 UTC (permalink / raw)
To: Stephan Gerhold, Aiqun(Maria) Yu
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Konrad Dybcio, shengchao.guo,
tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel,
Gokul Krishna Krishnakumar
In-Reply-To: <aip7feoTn0ncwzL7@linaro.org>
On 6/11/2026 5:10 PM, Stephan Gerhold wrote:
> On Thu, Jun 11, 2026 at 11:10:25AM +0800, Aiqun(Maria) Yu wrote:
>> On 5/22/2026 8:07 PM, Stephan Gerhold wrote:
>>> On Tue, May 19, 2026 at 12:24:23AM -0700, Jingyi Wang wrote:
>>>> Subsystems can be brought out of reset by entities such as bootloaders.
>>>> As the irq enablement could be later than subsystem bring up, the state
>>>> of subsystem should be checked by reading SMP2P bits.
>>>>
>>>> A new qcom_pas_attach() function is introduced. if a crash state is
>>>> detected for the subsystem, rproc_report_crash() is called. If the ready
>>>> state is detected, it will be marked as "attached", otherwise it could
>>>> be the early boot feature is not supported by other entities. In this
>>>> case, the state will be marked as RPROC_OFFLINE so that the PAS driver
>>>> can load the firmware and start the remoteproc.
>>>>
>>>> Co-developed-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
>>>> Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
>>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>>
>>> Unfortunately, removing the ping-pong functionality that was present in
>>> previous patch versions makes the whole mechanism a lot more fragile.
>>> I'm not entirely sure if this has changed in SMP2P v2 or more recent
>>> firmware versions, but in my experience the SMP2P "ready" bit does not
>>> tell you if the remoteproc is actually running. The problem is that the
>>> "ready" bit is asserted by the remoteproc when the firmware is ready,
>>> but it is not cleared when you shutdown or forcibly stop the remoteproc.
>>>
>>> If this is still the case, you can easily reproduce that with the
>>> following test:
>>>
>>> 1. Start the system as usual and let it attach the remoteproc
>>> 2. Manually stop the remoteproc in sysfs (echo stop > state)
>>> 3. modprobe -r qcom_q6v5_pas
>>> 4. modprobe qcom_q6v5_pas
>>> 5. If the "ready" bit is still set, the driver will try attaching the
>>> remoteproc, but it's actually not running. No recovery will happen.
>>>
>>> In this situation, it is very difficult to detect the correct remoteproc
>>> state without relying on an additional query mechanism like the
>>> ping-pong feature.
>>
>> This a valid use case and concern. We had a discussion with Bjorn, and
>> want to take this scenario into consideration of the separate robustness
>> improvement series[1].
>> Stephan could you agree to have the basic function in this series can be
>> go in firstly.
>>
>> [1]
>> https://lore.kernel.org/all/20260519-rproc-attach-issue-v2-0-caa1eaf75081@oss.qualcomm.com/
>>
>>>
>>> You can make it a bit more reliable if you also check the status of the
>>> "stop-ack" bit. This would tell you if the remoteproc was cleanly
>>> stopped with the SMP2P "stop" mechanism. However, that will typically
>>> still not fix the case above since nowadays remoteprocs are typically
>>> stopped via the QMI qcom_sysmon and the "stop-ack" is not set in that
>>> case. I believe this might set the separate "shutdown-ack" bit though
>>> that is described for some SoCs, I never finished testing that.
>>>
>>> And even if you check both "stop-ack" and "shutdown-ack", that doesn't
>>> tell you if the remoteproc was forcibly killed using
>>> qcom_scm_pas_shutdown() without gracefully stopping it first. The ideal
>>> solution would be querying the PAS API to tell us if the remoteproc is
>>> actively running, but the last time I checked I was unfortunately not
>>> able to find a documented call that would tell us that.
>>
>> It is a state currently kernel don't know whether the remoteproc is
>> offline or crashed when ready==1 && error==0 && ping-pong==0 scenario.
>> If it is re-modprob, the software don't have any data and only the
>> firmware can tell us whether if it is active or not per my understanding.
>>
>> Maybe let's have this scenario and solution discussion in the other
>> series I mentioned before.
>>
>
> If you add a new feature upstream, you must make sure that it is
> reasonably robust and reliable. The other series is about generic
> limitations in the remoteproc subsystem, so I don't think you should
> move QC-specific parts over there as well (personally, I would have
> probably kept all of it in one series to make it easier to understand,
> but that's subjective).
>
> With the current firmware design, it's hard - probably impossible - to
> make the status detection perfectably reliable. I would therefore choose
> some reasonable compromise to start with. Given that Shawn (and actually
> me as well) would like to have attach working without firmware support
> for the ping-pong functionality, I think it would be reasonable to start
> with the basic detection scheme discussed above, i.e.
>
> ready==1 && handover==1 && fatal==0 && stop-ack==0 && shutdown-ack==0
>
Hi Stephan,
We did local test, checking stop-ack==0 && shutdown-ack==0 should be able to
cover graceful shutdown cases.
Would it be redundant to additionally check the handover state here? In our
observations, the ready and handover bits are usually set together. Meanwhile,
handover irq is not a necessary condition for pas start.
Thanks,
Jingyi
> The ping-pong functionality could be added later for platforms that
> support it. It would be good to have the interrupts already defined in
> the device tree, so you can tweak the driver without making DT changes
> later.
>
> Thanks,
> Stephan
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
From: Wolfram Sang @ 2026-06-17 9:38 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
On Mon, Jun 15, 2026 at 04:47:54PM +0100, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add compatible strings for the RTC block found on the Renesas RZ/T2H
> (R9A09G077) and RZ/N2H (R9A09G087) SoCs.
>
> These SoCs integrate a closely related variant of the RZ/N1 RTC IP.
> Unlike RZ/N1, they do not implement the RTCA0SUBU and RTCA0TCR
> registers. This is not a limitation for Linux support, as these
> registers are not used when the RTC operates in "scmp" clock mode, which
> is required on RZ/T2H and RZ/N2H due to their 195.3 kHz input clock.
>
> The RZ/T2H RTC variant also supports a 1Hz output signal on the
> RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
> marked as reserved in the RZ/N1 hardware manual.
>
> Update the binding schema to require the additional clock inputs used by
> these SoCs.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Sashiko is wrong here because
a) TCR is the "Test Register"
b) TCR is not even present on RZ/N1D. Cover-letter misses that, too.
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 8/9] arm64: dts: qcom: shikra-cqs-evk: Enable ethernet0
From: Konrad Dybcio @ 2026-06-17 9:42 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <ajF+xlipLuZtf4HL@oss.qualcomm.com>
On 6/16/26 6:50 PM, Mohd Ayaan Anwar wrote:
> On Tue, Jun 16, 2026 at 11:50:26AM +0200, Konrad Dybcio wrote:
>> On 6/11/26 8:37 PM, Mohd Ayaan Anwar wrote:
>>
>>> +&tlmm {
>>> + ethernet0_defaults: ethernet0-defaults-state {
>>
>> s/defaults/default
>>
>> Please move this definition to shikra.dtsi
>>
>
> The CQM and CQS variants have identical GPIO mapping but the IQS is
> different. So should I keep this in shikra.dtsi and overwrite for IQS in
> shikra-iqs-evk.dts?
>
>
>>> +
>>> + emac0_phy_en_hog: emac0-phy-en-hog {
>>> + gpio-hog;
>>> + gpios = <149 GPIO_ACTIVE_HIGH>;
>>> + output-high;
>>> + line-name = "emac0-phy-en";
>>> + };
>>
>> This looks like a hack - what does this pin actually do?
>>
>
> The power supply to both PHYs on Shikra is gated by a GPIO pin. I am
> unsure whether they should be modelled as a fixed, enable-on-boot
> regulator or just like this. They need to be powered on early so that
> MDIO can detect them.
If it's a regulator, then it should be described as a regulator. There
was some discussion regarding the power resources of PHYs over here:
https://lore.kernel.org/linux-arm-msm/SN7PR19MB67369F7DD02F702437C0F1919D1B2@SN7PR19MB6736.namprd19.prod.outlook.com/
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: Andy Shevchenko @ 2026-06-17 9:43 UTC (permalink / raw)
To: rva333
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260616-mt6323-adc-v3-2-1c27c588185d@protonmail.com>
On Tue, Jun 16, 2026 at 05:15:40PM +0300, Roman Vivchar via B4 Relay wrote:
> The mt6323 AUXADC is a 15-bit ADC used for system monitoring. This driver
> provides support for reading various channels including battery and
> charger voltages, battery and chip temperature, current sensing and
> accessory detection.
>
> Add a driver for the AUXADC found in the MediaTek mt6323 PMIC.
...
> +static int mt6323_auxadc_prepare_channel(struct mt6323_auxadc *auxadc)
> +{
> + struct regmap *map = auxadc->regmap;
> + u32 val;
> + int ret;
> +
> + ret = regmap_read(map, MT6323_AUXADC_CON19, &val);
> + if (ret)
> + return ret;
> +
> + /* The ADC is idle. */
> + if (!(val & AUXADC_CON19_DECI_GDLY_MASK))
> + return 0;
> + ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19, val,
> + !(val & AUXADC_ADC19_BUSY_MASK),
> + 10, 500);
Still can be amended.
ret = regmap_read_poll_timeout(map, MT6323_AUXADC_ADC19,
val, !(val & AUXADC_ADC19_BUSY_MASK),
10, 500);
(no need to resend just for this).
> + if (ret)
> + return ret;
> +
> + return regmap_clear_bits(map, MT6323_AUXADC_CON19,
> + AUXADC_CON19_DECI_GDLY_MASK);
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 11/12] arm64: dts: qcom: glymur: Add iris video node
From: Konrad Dybcio @ 2026-06-17 9:48 UTC (permalink / raw)
To: Vishnu Reddy, Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Dmitry Baryshkov, Mauro Carvalho Chehab,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Stanimir Varbanov,
Bjorn Andersson, Konrad Dybcio
Cc: linux-kernel, linux-media, linux-arm-msm, iommu, devicetree
In-Reply-To: <20260610-glymur-v8-11-1c79b9d51fc0@oss.qualcomm.com>
On 6/10/26 8:29 AM, Vishnu Reddy wrote:
> Add iris video codec to glymur SoC, which comes with significantly
> different powering up sequence than previous platforms, thus different
> clocks and resets.
>
> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/glymur.dtsi | 118 +++++++++++++++++++++++++++++++++++
> 1 file changed, 118 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> index 20b49af7298e..42bcd03c4d3e 100644
> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> @@ -16,6 +16,7 @@
> #include <dt-bindings/interconnect/qcom,glymur-rpmh.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/mailbox/qcom-ipcc.h>
> +#include <dt-bindings/media/qcom,glymur-iris.h>
> #include <dt-bindings/phy/phy-qcom-qmp.h>
> #include <dt-bindings/power/qcom,rpmhpd.h>
> #include <dt-bindings/power/qcom-rpmpd.h>
> @@ -4788,6 +4789,123 @@ mdss_dp3_out: endpoint {
> };
> };
>
> + iris: video-codec@aa00000 {
> + compatible = "qcom,glymur-iris";
> + reg = <0x0 0xaa00000 0x0 0xf0000>;
Please keep the address part padded to 8 hex digits with a leading zero
[...]
> + /*
> + * IRIS firmware is signed by vendors, only
> + * enable on boards where the proper signed firmware
> + * is available.
> + */
> + status = "disabled";
I find this comment superfluous
Konrad
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale, Conor Dooley
In-Reply-To: <20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The MediaTek mt6323 PMIC includes an EFUSE used for storing calibration
data.
Add the devicetree binding documentation for the MediaTek mt6323 EFUSE.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
.../devicetree/bindings/mfd/mediatek,mt6397.yaml | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 05c121b0cb3d..beaa67bf0df2 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -145,6 +145,23 @@ properties:
required:
- compatible
+ efuse:
+ type: object
+ unevaluatedProperties: false
+ description:
+ The efuse is responsible for storing calibration data, such as thermal
+ sensor calibration.
+
+ properties:
+ compatible:
+ const: mediatek,mt6323-efuse
+
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml#
+
+ required:
+ - compatible
+
leds:
type: object
additionalProperties: false
@@ -243,6 +260,10 @@ examples:
interrupt-controller;
#interrupt-cells = <2>;
+ efuse {
+ compatible = "mediatek,mt6323-efuse";
+ };
+
leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/4] nvmem: add support for the MediaTek mt6323 PMIC
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale, Conor Dooley
This series adds support for the EFUSE found on the MediaTek mt6323 PMIC.
The previous version of the series for all AUXADC, EFUSE and thermal
drivers was split after Krzysztof's comment [1].
Tested on the MediaTek mt6572 and mt8163 SoCs (Ben), both paired with a
mt6323.
[1]: https://lore.kernel.org/linux-mediatek/20260504-mt6323-v1-0-799b58b355ff@protonmail.com/T/#med30fad67a090be35f549231336b2dec295233f6
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
Changes in v2:
- EFUSE driver: Sort variables in the mt6323_efuse_read (Andy)
- Link to v1: https://patch.msgid.link/20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com
Changes after split:
- EFUSE driver:
- Remove 'linux/errno.h' header (Andy)
- Remove explicit cast to u16 in the 'mt6323_efuse_read' (Andy)
- Reword comment in the 'mt6323_efuse_read'
- Capitalize MediaTek in the module description
- Link to a previous series: https://patch.msgid.link/20260512-mt6323-v2-0-3efcba579e88@protonmail.com
---
Roman Vivchar (4):
dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
nvmem: add mt6323 PMIC EFUSE driver
mfd: mt6397-core: add mt6323 EFUSE support
ARM: dts: mediatek: mt6323: add EFUSE support
.../devicetree/bindings/mfd/mediatek,mt6397.yaml | 21 ++++++
MAINTAINERS | 5 ++
arch/arm/boot/dts/mediatek/mt6323.dtsi | 4 +
drivers/mfd/mt6397-core.c | 3 +
drivers/nvmem/Kconfig | 11 +++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/mt6323-efuse.c | 85 ++++++++++++++++++++++
7 files changed, 131 insertions(+)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260611-mt6323-nvmem-0c54a0f2fa9f
Best regards,
--
Roman Vivchar <rva333@protonmail.com>
^ permalink raw reply
* [PATCH v2 2/4] nvmem: add mt6323 PMIC EFUSE driver
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add support for the EFUSE controller found in the Mediatek MT6323 PMIC.
The MT6323 EFUSE stores 24 bytes of hardware-related data, such as
thermal sensor calibration values.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
MAINTAINERS | 5 +++
drivers/nvmem/Kconfig | 11 ++++++
drivers/nvmem/Makefile | 2 ++
drivers/nvmem/mt6323-efuse.c | 85 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 103 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..910360f148c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16256,6 +16256,11 @@ S: Maintained
F: Documentation/devicetree/bindings/mmc/mtk-sd.yaml
F: drivers/mmc/host/mtk-sd.c
+MEDIATEK MT6323 PMIC NVMEM DRIVER
+M: Roman Vivchar <rva333@protonmail.com>
+S: Maintained
+F: drivers/nvmem/mt6323-efuse.c
+
MEDIATEK MT6735 CLOCK & RESET DRIVERS
M: Yassine Oudjana <y.oudjana@protonmail.com>
L: linux-clk@vger.kernel.org
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0..db248a3c4e87 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -227,6 +227,17 @@ config NVMEM_MTK_EFUSE
This driver can also be built as a module. If so, the module
will be called efuse-mtk.
+config NVMEM_MT6323_EFUSE
+ tristate "Mediatek MT6323 PMIC EFUSE support"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on MFD_MT6397
+ help
+ This is a driver to access hardware related data like sensor
+ calibration, etc.
+
+ This driver can also be built as a module. If so, the module
+ will be called efuse-mt6323.
+
config NVMEM_MXS_OCOTP
tristate "Freescale MXS On-Chip OTP Memory Support"
depends on ARCH_MXS || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d4..0e2b73f42b25 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -48,6 +48,8 @@ obj-$(CONFIG_NVMEM_MICROCHIP_OTPC) += nvmem-microchip-otpc.o
nvmem-microchip-otpc-y := microchip-otpc.o
obj-$(CONFIG_NVMEM_MTK_EFUSE) += nvmem_mtk-efuse.o
nvmem_mtk-efuse-y := mtk-efuse.o
+obj-$(CONFIG_NVMEM_MT6323_EFUSE) += nvmem_mt6323-efuse.o
+nvmem_mt6323-efuse-y := mt6323-efuse.o
obj-$(CONFIG_NVMEM_MXS_OCOTP) += nvmem-mxs-ocotp.o
nvmem-mxs-ocotp-y := mxs-ocotp.o
obj-$(CONFIG_NVMEM_NINTENDO_OTP) += nvmem-nintendo-otp.o
diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
new file mode 100644
index 000000000000..7a0ce4c7f565
--- /dev/null
+++ b/drivers/nvmem/mt6323-efuse.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2026 Roman Vivchar <rva333@protonmail.com>
+ */
+
+#include <linux/err.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+#include <linux/mfd/mt6323/registers.h>
+
+#define MT6323_EFUSE_DOUT_BASE MT6323_EFUSE_DOUT_0_15
+#define MT6323_EFUSE_SIZE 24
+
+static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct regmap *map = context;
+ u16 *buf = val;
+ u32 tmp;
+ int ret;
+
+ /*
+ * A manual loop using regmap_read is required because PWRAP is not
+ * a continuous MMIO space, but rather a FSM that doesn't implement the
+ * necessary read callback for the regmap_read_raw and regmap_read_bulk
+ * functions.
+ */
+ for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
+ ret = regmap_read(map, MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
+ if (ret)
+ return ret;
+
+ *buf++ = tmp;
+ }
+
+ return 0;
+}
+
+static int mt6323_efuse_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct nvmem_config config = {
+ .name = "mt6323-efuse",
+ .stride = 2,
+ .word_size = 2,
+ .size = MT6323_EFUSE_SIZE,
+ .reg_read = mt6323_efuse_read,
+ };
+ struct nvmem_device *nvmem;
+ struct regmap *regmap;
+
+ /* efuse -> mfd -> pwrap */
+ regmap = dev_get_regmap(dev->parent->parent, NULL);
+ if (!regmap)
+ return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
+
+ config.dev = dev;
+ config.priv = regmap;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ return PTR_ERR_OR_ZERO(nvmem);
+}
+
+static const struct of_device_id mt6323_efuse_of_match[] = {
+ { .compatible = "mediatek,mt6323-efuse" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mt6323_efuse_of_match);
+
+static struct platform_driver mt6323_efuse_driver = {
+ .probe = mt6323_efuse_probe,
+ .driver = {
+ .name = "mt6323-efuse",
+ .of_match_table = mt6323_efuse_of_match,
+ },
+};
+module_platform_driver(mt6323_efuse_driver);
+
+MODULE_DESCRIPTION("MediaTek MT6323 PMIC EFUSE driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/4] mfd: mt6397-core: add mt6323 EFUSE support
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
The mt6323 PMIC includes an EFUSE. Register the EFUSE in the mt6323
devices array to allow the corresponding driver to probe using compatible
string.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
drivers/mfd/mt6397-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 3e58d0764c7e..362737a1c4a9 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
static const struct mfd_cell mt6323_devs[] = {
{
+ .name = "mt6323-efuse",
+ .of_compatible = "mediatek,mt6323-efuse",
+ }, {
.name = "mt6323-rtc",
.num_resources = ARRAY_SIZE(mt6323_rtc_resources),
.resources = mt6323_rtc_resources,
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/4] ARM: dts: mediatek: mt6323: add EFUSE support
From: Roman Vivchar via B4 Relay @ 2026-06-17 9:48 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Roman Vivchar
Cc: Andy Shevchenko, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com>
From: Roman Vivchar <rva333@protonmail.com>
Add the devicetree node for the mt6323 efuse.
Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
Signed-off-by: Roman Vivchar <rva333@protonmail.com>
---
arch/arm/boot/dts/mediatek/mt6323.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
index c230c865116d..807e000a7ff6 100644
--- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
+++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
@@ -14,6 +14,10 @@ pmic: mt6323 {
interrupt-controller;
#interrupt-cells = <2>;
+ efuse {
+ compatible = "mediatek,mt6323-efuse";
+ };
+
mt6323_leds: leds {
compatible = "mediatek,mt6323-led";
#address-cells = <1>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC 8/9] arm64: dts: qcom: shikra-cqs-evk: Enable ethernet0
From: Andrew Lunn @ 2026-06-17 9:48 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Mohd Ayaan Anwar, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Bjorn Andersson, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-arm-msm,
netdev, devicetree, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <4f3c6bee-3ccb-467e-a466-89fece0e6a7f@oss.qualcomm.com>
> >>> + emac0_phy_en_hog: emac0-phy-en-hog {
> >>> + gpio-hog;
> >>> + gpios = <149 GPIO_ACTIVE_HIGH>;
> >>> + output-high;
> >>> + line-name = "emac0-phy-en";
> >>> + };
> >>
> >> This looks like a hack - what does this pin actually do?
> >>
> >
> > The power supply to both PHYs on Shikra is gated by a GPIO pin. I am
> > unsure whether they should be modelled as a fixed, enable-on-boot
> > regulator or just like this. They need to be powered on early so that
> > MDIO can detect them.
>
> If it's a regulator, then it should be described as a regulator.
Agreed.
> There
> was some discussion regarding the power resources of PHYs over here:
>
> https://lore.kernel.org/linux-arm-msm/SN7PR19MB67369F7DD02F702437C0F1919D1B2@SN7PR19MB6736.namprd19.prod.outlook.com/
MDIO detection is nice to have, but only works well on simple
boards. I would suggest hard coding the PHY ID in the compatible.
Andrew
^ permalink raw reply
* Re: [PATCH v3 1/5] clk: renesas: rzv2h-cpg: Use per-SoC PLL reference frequency for calculations
From: Geert Uytterhoeven @ 2026-06-17 9:48 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615104845.4122868-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Mon, 15 Jun 2026 at 12:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Introduce a per-SoC PLL reference input frequency parameter to avoid
> relying on a hardcoded 24MHz constant during PLL configuration math.
>
> Add an input_fref member to struct rzv2h_pll_limits. In the core
> calculation helper rzv2h_get_pll_pars(), derive the base input clock
> rate from limits->input_fref, utilizing the conditional ternary operator
> to fall back to 24MHz if the struct field is left uninitialized (0), and
> drop the obsolete macro RZ_V2H_OSC_CLK_IN_MEGA.
>
> This abstraction permits the reuse of the common PLL divider logic on
> newer SoC platforms like the RZ/T2H, which feature a 48 MHz PLL reference
> clock input instead of the 24 MHz signal used by RZ/V2H(P), without
> disrupting existing platforms.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Thanks for your patch!
> --- a/include/linux/clk/renesas.h
> +++ b/include/linux/clk/renesas.h
> @@ -53,6 +53,9 @@ static inline void rzg2l_cpg_dsi_div_set_divider(u8 divider, int target) { }
> * various parameters used to configure a PLL. These limits ensure
> * the PLL operates within valid and stable ranges.
> *
> + * @input_fref: Reference input frequency to the PLL (in MHz). If set
"in Hz", as pointed out by Sashiko.
> + * to 0, a default value of 24MHz is used.
> + *
> * @fout: Output frequency range (in MHz)
> * @fout.min: Minimum allowed output frequency
> * @fout.max: Maximum allowed output frequency
> @@ -78,6 +81,8 @@ static inline void rzg2l_cpg_dsi_div_set_divider(u8 divider, int target) { }
> * @k.max: Maximum delta-sigma value
> */
> struct rzv2h_pll_limits {
> + u32 input_fref;
> +
> struct {
> u32 min;
> u32 max;
The rest LGTM, so with the above fixed:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 3/5] dt-bindings: clock: renesas,r9a09g077/87: Add LCDC_CLKD clock ID
From: Geert Uytterhoeven @ 2026-06-17 9:51 UTC (permalink / raw)
To: Prabhakar
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, linux-kernel,
linux-renesas-soc, linux-clk, devicetree, Biju Das,
Fabrizio Castro, Lad Prabhakar, Conor Dooley
In-Reply-To: <20260615104845.4122868-4-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 12:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Add the LCDC clockd (LCDC_CLKD) definition for the Renesas RZ/T2H
> (R9A09G077) and RZ/N2H (R9A09G087) SoCs. LCDC_CLKD is used as the
> operating clock for LCDC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, will queue in a branch shared by renesas-clk and renesas-dts.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox