* Re: [PATCH] arm64: dts: qcom: install DT overlays via dtbs_install
From: Vishwas Udupa @ 2026-06-15 16:27 UTC (permalink / raw)
To: krzk
Cc: andersson, conor+dt, devicetree, kbajaj, konradybcio, krzk+dt,
linux-arm-msm, robh, snb, vudupa
In-Reply-To: <0f045b88-94fc-46b5-8a49-8a53235fc8fc@kernel.org>
EL2 DTBOs are used at build time to construct DTBs corresponding to
an EL2 (hypervisor-enabled) boot configuration. These DTBs are included in
distributions [1] as complete boot configurations (e.g. EL1 and EL2).
The EL2 configuration is not enabled by default and is typically selected
after the initial boot by updating a UEFI runtime variable from userspace.
Once set, firmware selects the prebuilt EL2 DTB on subsequent boots.
Although EL2 DTBOs are not used directly at runtime during initial boot,
they are required to generate and package the EL2 DTBs in the image so that
firmware can switch to EL2 when the configuration variable is enabled. Hence, el2 dtbo's
need to be retained.
1: https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/qcom-next-fitimage.its#L273
^ permalink raw reply
* Re: [PATCH v3 03/10] dt-bindings: input: microchip,cap11xx: Update datasheet URL and LED reg range
From: Conor Dooley @ 2026-06-15 16:27 UTC (permalink / raw)
To: Jun Yan
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-4-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]
On Mon, Jun 15, 2026 at 10:20:29PM +0800, Jun Yan wrote:
> - Add datasheet links for all supported CAP11xx variants.
> - Update LED node regex and replace enum constraints with minimum/maximum
> for LED reg ranges in preparation for CAP1114 support.
>
> CAP1114 has 11 LED channels. minimum/maximum constraints are easier to
> maintain than long enum lists when expanding channel count later.
>
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> ---
> .../bindings/input/microchip,cap11xx.yaml | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> index 7ade03f1b32b..9578c7c206a2 100644
> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> @@ -10,6 +10,15 @@ description: |
> The Microchip CAP1xxx Family of RightTouchTM multiple-channel capacitive
> touch controllers and LED drivers. The device communication via I2C only.
>
> + For more product information please see the links below:
> + CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.pdf
> + CAP1126: https://ww1.microchip.com/downloads/en/DeviceDoc/00001623B.pdf
> + CAP1188: https://ww1.microchip.com/downloads/en/DeviceDoc/00001620C.pdf
> + CAP1203: https://ww1.microchip.com/downloads/en/DeviceDoc/00001572B.pdf
> + CAP1206: https://ww1.microchip.com/downloads/en/DeviceDoc/00001567B.pdf
> + CAP1293: https://ww1.microchip.com/downloads/en/DeviceDoc/00001566B.pdf
> + CAP1298: https://ww1.microchip.com/downloads/en/DeviceDoc/00001571B.pdf
> +
> maintainers:
> - Rob Herring <robh@kernel.org>
>
> @@ -124,14 +133,16 @@ properties:
> The number of entries must correspond to the number of channels.
>
> patternProperties:
> - "^led@[0-7]$":
> + "^led@[0-9a-f]$":
This should be done alongside the cap1114 change, not here I think. The
constraint relaxation doesn't make sense because the user is arriving in
a later patch.
With it moved,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Although, should it not be led@[0-9a-b] if the max is 11?
pw-bot: changes-requested
Cheers,
Conor.
> type: object
> description: CAP11xx LEDs
> $ref: /schemas/leds/common.yaml#
>
> properties:
> reg:
> - enum: [0, 1, 2, 3, 4, 5, 6, 7]
> + description: LED channel number
> + minimum: 0
> + maximum: 7
>
> label: true
>
> @@ -158,7 +169,7 @@ allOf:
> - microchip,cap1298
> then:
> patternProperties:
> - "^led@[0-7]$": false
> + "^led@": false
>
> - if:
> properties:
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v19 3/3] pwm: Add OpenCores PTC PWM driver
From: sashiko-bot @ 2026-06-15 16:25 UTC (permalink / raw)
To: Hal Feng; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260615155759.129210-4-hal.feng@starfivetech.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hardware state corruption and PM runtime leak in `ocores_pwm_apply` on invalid parameter request.
--
commit b3a12f20d0a4ac7f1d2dc7a3d103fe2acf522975
Author: Hal Feng <hal.feng@starfivetech.com>
Subject: pwm: Add OpenCores PTC PWM driver
This commit adds a PWM driver for the OpenCores PTC IP core.
> diff --git a/drivers/pwm/pwm-ocores.c b/drivers/pwm/pwm-ocores.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/pwm/pwm-ocores.c
[ ... ]
> +static int ocores_pwm_apply(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct ocores_pwm_device *ddata = pwmchip_get_drvdata(chip);
> + bool was_enabled = pwm_is_enabled(pwm);
> + u64 period_data, duty_data;
> + int ret;
> +
> + if (state->polarity != PWM_POLARITY_INVERSED)
> + return -EINVAL;
> +
> + if (state->enabled) {
> + if (!was_enabled) {
> + ret = pm_runtime_resume_and_get(pwmchip_parent(chip));
> + if (ret < 0)
> + return ret;
> + }
> + } else {
> + if (was_enabled) {
> + writel(0, ddata->base + OCPWM_CTRL);
> + pm_runtime_put(pwmchip_parent(chip));
> + }
> + return 0;
> + }
> +
> + writel(0, ddata->base + OCPWM_CTRL);
> + writel(OCPWM_CTRL_RST, ddata->base + OCPWM_CTRL);
> +
> + period_data = mul_u64_u32_div(state->period, ddata->clk_rate, NSEC_PER_SEC);
> + if (period_data > U32_MAX)
> + period_data = U32_MAX;
> +
> + duty_data = mul_u64_u32_div(state->duty_cycle, ddata->clk_rate, NSEC_PER_SEC);
> + if (duty_data > U32_MAX)
> + duty_data = U32_MAX;
> +
> + if (!period_data || !duty_data) {
> + if (!was_enabled)
> + pm_runtime_put(pwmchip_parent(chip));
> + return -EINVAL;
[Severity: High]
Does stopping and resetting the hardware before validating the requested
parameters cause state corruption if the validation fails?
If period_data or duty_data evaluate to 0, the function returns -EINVAL.
Since the hardware was already stopped and reset, the framework's software
state will show the PWM as enabled, but the physical hardware will remain
disabled.
Additionally, if was_enabled is true, does this error path leak the PM
runtime reference?
Since OCPWM_CTRL_EN was prematurely cleared, ocores_pwm_pm_disable() will
later see the enable bit as 0 and skip its pm_runtime_put_noidle() call:
ocores_pwm_pm_disable() {
...
if (!pm_runtime_status_suspended(dev)) {
if (readl(ddata->base + OCPWM_CTRL) & OCPWM_CTRL_EN)
pm_runtime_put_noidle(dev);
...
}
> + }
> +
> + writel(period_data, ddata->base + OCPWM_LRC);
> + writel(duty_data, ddata->base + OCPWM_HRC);
> + writel(OCPWM_CTRL_OE | OCPWM_CTRL_EN, ddata->base + OCPWM_CTRL);
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615155759.129210-1-hal.feng@starfivetech.com?part=3
^ permalink raw reply
* Re: [PATCH v3 04/10] dt-bindings: input: microchip,cap11xx: Add microchip,cap1126 LED reg constraints
From: Conor Dooley @ 2026-06-15 16:24 UTC (permalink / raw)
To: Jun Yan
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-5-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v19 1/3] dt-bindings: pwm: opencores: Update compatibles, examples and maintainers
From: sashiko-bot @ 2026-06-15 16:24 UTC (permalink / raw)
To: Hal Feng; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260615155759.129210-2-hal.feng@starfivetech.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Invalid YAML indentation under the `items` block violates the subsystem's yamllint rules, causing `make dt_binding_check` to fail.
--
commit f6d46c997f1ef83c6c55a27e0e3260fdf27add18
Author: Hal Feng <hal.feng@starfivetech.com>
dt-bindings: pwm: opencores: Update compatibles, examples and maintainers
Remove the jh8100 compatible since the JH8100 SoC has been canceled and
will not be released. Add the jhb100 compatible to replace it. Use a oneOf
construct to support the single-string opencores,pwm-v1 compatible.
> diff --git a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
> index 52a59d245cdb1..5f05606a2d3d4 100644
> --- a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
> +++ b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
[ ... ]
> @@ -19,12 +19,14 @@ allOf:
>
> properties:
> compatible:
> - items:
> - - enum:
> - - starfive,jh7100-pwm
> - - starfive,jh7110-pwm
> - - starfive,jh8100-pwm
> + oneOf:
> - const: opencores,pwm-v1
> + - items:
> + - enum:
> + - starfive,jh7100-pwm
> + - starfive,jh7110-pwm
> + - starfive,jhb100-pwm
> + - const: opencores,pwm-v1
[Severity: Low]
Does this formatting cause make dt_binding_check to fail? It looks like the
YAML sequence markers under the items block are indented to 8 spaces,
matching the parent mapping key, instead of being indented to 10 spaces.
This might violate the yamllint indent-sequences rules.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615155759.129210-1-hal.feng@starfivetech.com?part=1
^ permalink raw reply
* Re: [PATCH v3 09/10] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Conor Dooley @ 2026-06-15 16:24 UTC (permalink / raw)
To: Jun Yan
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260615142103.352163-10-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: clock: renesas,r9a09g077/87: Add PCLKRTC clock ID
From: Conor Dooley @ 2026-06-15 16:22 UTC (permalink / raw)
To: Prabhakar
Cc: Geert Uytterhoeven, 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: <20260615143943.1610095-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
From: Conor Dooley @ 2026-06-15 16:22 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang, 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: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v19 1/3] dt-bindings: pwm: opencores: Update compatibles, examples and maintainers
From: Conor Dooley @ 2026-06-15 16:21 UTC (permalink / raw)
To: Hal Feng
Cc: Uwe Kleine-König, Philipp Zabel, Rob Herring,
Krzysztof Kozlowski, Emil Renner Berthing, Palmer Dabbelt,
Paul Walmsley, Albert Ou, linux-pwm, devicetree, linux-riscv,
linux-kernel
In-Reply-To: <20260615155759.129210-2-hal.feng@starfivetech.com>
[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]
On Mon, Jun 15, 2026 at 11:57:57PM +0800, Hal Feng wrote:
> Remove the jh8100 compatible since the JH8100 SoC has been canceled and
> will not be released. Add the jhb100 compatible to replace it.
> Use a oneOf construct to support the single-string opencores,pwm-v1
> compatible.
No thanks. Simple as this IP might be, I still want soc-specific
compatibles to be a requirement.
pw-bot: changes-requested
Thanks,
Conor.
>
> Change the register size in examples to 0x10, since an OpenCores PTC IP
> has only 4 32-bit registers: CNTR, HRC, LRC and CTRL.
>
> I will maintain this pwm module in place of William.
>
> Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
> ---
> .../devicetree/bindings/pwm/opencores,pwm.yaml | 16 +++++++++-------
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
> index 52a59d245cdb..5f05606a2d3d 100644
> --- a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
> +++ b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
> @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
> title: OpenCores PWM controller
>
> maintainers:
> - - William Qiu <william.qiu@starfivetech.com>
> + - Hal Feng <hal.feng@starfivetech.com>
>
> description:
> The OpenCores PTC ip core contains a PWM controller. When operating in PWM
> @@ -19,12 +19,14 @@ allOf:
>
> properties:
> compatible:
> - items:
> - - enum:
> - - starfive,jh7100-pwm
> - - starfive,jh7110-pwm
> - - starfive,jh8100-pwm
> + oneOf:
> - const: opencores,pwm-v1
> + - items:
> + - enum:
> + - starfive,jh7100-pwm
> + - starfive,jh7110-pwm
> + - starfive,jhb100-pwm
> + - const: opencores,pwm-v1
>
> reg:
> maxItems: 1
> @@ -49,7 +51,7 @@ examples:
> - |
> pwm@12490000 {
> compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
> - reg = <0x12490000 0x10000>;
> + reg = <0x12490000 0x10>;
> clocks = <&clkgen 181>;
> resets = <&rstgen 109>;
> #pwm-cells = <3>;
> --
> 2.43.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v19 1/3] dt-bindings: pwm: opencores: Update compatibles, examples and maintainers
From: Hal Feng @ 2026-06-15 15:57 UTC (permalink / raw)
To: Uwe Kleine-König, Philipp Zabel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Emil Renner Berthing,
Palmer Dabbelt, Paul Walmsley, Albert Ou
Cc: Hal Feng, linux-pwm, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20260615155759.129210-1-hal.feng@starfivetech.com>
Remove the jh8100 compatible since the JH8100 SoC has been canceled and
will not be released. Add the jhb100 compatible to replace it.
Use a oneOf construct to support the single-string opencores,pwm-v1
compatible.
Change the register size in examples to 0x10, since an OpenCores PTC IP
has only 4 32-bit registers: CNTR, HRC, LRC and CTRL.
I will maintain this pwm module in place of William.
Signed-off-by: Hal Feng <hal.feng@starfivetech.com>
---
.../devicetree/bindings/pwm/opencores,pwm.yaml | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
index 52a59d245cdb..5f05606a2d3d 100644
--- a/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/opencores,pwm.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: OpenCores PWM controller
maintainers:
- - William Qiu <william.qiu@starfivetech.com>
+ - Hal Feng <hal.feng@starfivetech.com>
description:
The OpenCores PTC ip core contains a PWM controller. When operating in PWM
@@ -19,12 +19,14 @@ allOf:
properties:
compatible:
- items:
- - enum:
- - starfive,jh7100-pwm
- - starfive,jh7110-pwm
- - starfive,jh8100-pwm
+ oneOf:
- const: opencores,pwm-v1
+ - items:
+ - enum:
+ - starfive,jh7100-pwm
+ - starfive,jh7110-pwm
+ - starfive,jhb100-pwm
+ - const: opencores,pwm-v1
reg:
maxItems: 1
@@ -49,7 +51,7 @@ examples:
- |
pwm@12490000 {
compatible = "starfive,jh7110-pwm", "opencores,pwm-v1";
- reg = <0x12490000 0x10000>;
+ reg = <0x12490000 0x10>;
clocks = <&clkgen 181>;
resets = <&rstgen 109>;
#pwm-cells = <3>;
--
2.43.2
^ permalink raw reply related
* Re: [PATCH net-next v7 12/12] net: airoha: add phylink support
From: Benjamin Larsson @ 2026-06-15 16:07 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-13-ansuelsmth@gmail.com>
Hi.
On 15/06/2026 14:29, Christian Marangi wrote:
> Add phylink support for each GDM port. For GDM1 add the internal interface
> mode as the only supported mode. For GDM2/3/4 add the required
> configuration of the PCS to make the external PHY or attached SFP cage
> work.
>
> These needs to be defined in the GDM port node using the pcs-handle
> property.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/ethernet/airoha/Kconfig | 1 +
> drivers/net/ethernet/airoha/airoha_eth.c | 161 +++++++++++++++++++++-
> drivers/net/ethernet/airoha/airoha_eth.h | 3 +
> drivers/net/ethernet/airoha/airoha_regs.h | 12 ++
> 4 files changed, 176 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/Kconfig b/drivers/net/ethernet/airoha/Kconfig
> index ad3ce501e7a5..38dcc76e5998 100644
> --- a/drivers/net/ethernet/airoha/Kconfig
> +++ b/drivers/net/ethernet/airoha/Kconfig
> @@ -20,6 +20,7 @@ config NET_AIROHA
> depends on NET_DSA || !NET_DSA
> select NET_AIROHA_NPU
> select PAGE_POOL
> + select PHYLINK
> help
> This driver supports the gigabit ethernet MACs in the
> Airoha SoC family.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5f1a118875fb..9a42fb991bd7 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -8,6 +8,7 @@
> #include <linux/of_reserved_mem.h>
> #include <linux/platform_device.h>
> #include <linux/tcp.h>
> +#include <linux/pcs/pcs.h>
> #include <linux/u64_stats_sync.h>
> #include <net/dst_metadata.h>
> #include <net/page_pool/helpers.h>
> @@ -1810,6 +1811,14 @@ static int airoha_dev_open(struct net_device *netdev)
> u32 cur_len, pse_port = FE_PSE_PORT_PPE1;
> struct airoha_qdma *qdma = dev->qdma;
>
> + err = phylink_of_phy_connect(dev->phylink, netdev->dev.of_node, 0);
> + if (err) {
> + netdev_err(netdev, "could not attach PHY: %d\n", err);
> + return err;
> + }
> +
> + phylink_start(dev->phylink);
> +
> netif_tx_start_all_queues(netdev);
> err = airoha_set_vip_for_gdm_port(dev, true);
> if (err)
> @@ -1907,6 +1916,9 @@ static int airoha_dev_stop(struct net_device *netdev)
> }
> }
>
> + phylink_stop(dev->phylink);
> + phylink_disconnect_phy(dev->phylink);
> +
> return 0;
> }
>
> @@ -3168,6 +3180,151 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> return false;
> }
>
> +/* Nothing to do in MAC, everything is handled in PCS */
> +static void airoha_mac_config(struct phylink_config *config, unsigned int mode,
> + const struct phylink_link_state *state)
> +{
> +}
> +
> +static void airoha_mac_link_up(struct phylink_config *config, struct phy_device *phy,
> + unsigned int mode, phy_interface_t interface,
> + int speed, int duplex, bool tx_pause, bool rx_pause)
> +{
> + struct airoha_gdm_dev *dev = container_of(config, struct airoha_gdm_dev,
> + phylink_config);
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> + u32 frag_size_tx, frag_size_rx;
> + u32 mask, val;
> +
> + /* TX/RX frag is configured only for GDM4 */
> + if (port->id != AIROHA_GDM4_IDX)
> + return;
> +
> + switch (speed) {
> + case SPEED_10000:
> + case SPEED_5000:
> + frag_size_tx = 8;
> + frag_size_rx = 8;
> + break;
> + case SPEED_2500:
> + frag_size_tx = 2;
> + frag_size_rx = 1;
> + break;
> + default:
> + frag_size_tx = 1;
> + frag_size_rx = 0;
> + }
> +
> + /* Configure TX/RX frag based on speed */
> + if (dev->nbq == 1) {
> + mask = GDMA4_SGMII1_TX_FRAG_SIZE_MASK;
Can the naming be consistently GDM4 without the A?
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [PATCH v5 0/4] Add eDP lane mapping support
From: Damon Ding @ 2026-06-15 12:34 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260604085220.2862986-1-damon.ding@rock-chips.com>
Hi all,
Gentle ping on this patch series.
Best regards,
Damon
On 6/4/2026 4:52 PM, Damon Ding wrote:
> This series adds configurable eDP physical lane mapping support via
> device tree data-lanes property.
>
> Lane mapping is mainly used for below scenarios:
> 1. Correct PCB lane swap and differential line routing crossover
> without hardware changes;
> 2. Adapt mismatched lane pin definitions between SoC and eDP panel;
> 3. Support multiple panel hardware variants on the same board
> by configuring data-lanes in device tree only.
>
> The series includes driver implementation and device tree binding
> updates to support custom lane mapping configuration from endpoint
> node, and keeps default linear lane order if no configuration is given.
>
> Patch 1: Add endpoint data-lanes property to analogix-dp binding
> Patch 2: Add DRM DP helper API to validate DP lane counts
> Patch 3: Add validation for samsung,lane-count property as preparation
> Patch 4: Implement lane mapping in analogix_dp driver
>
> Damon Ding (4):
> dt-bindings: display: bridge: analogix-dp: Add data-lanes support for
> endpoint
> drm/dp: Add helper to validate DP lane counts
> drm/bridge: analogix_dp: Add validation for samsung,lane-count
> property
> drm/bridge: analogix_dp: Add support for optional data-lanes mapping
>
> .../bindings/display/bridge/analogix,dp.yaml | 19 ++++--
> .../rockchip/rockchip,analogix-dp.yaml | 1 +
> .../drm/bridge/analogix/analogix_dp_core.c | 64 ++++++++++++++++++-
> .../drm/bridge/analogix/analogix_dp_core.h | 4 +-
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 15 ++---
> .../gpu/drm/bridge/analogix/analogix_dp_reg.h | 4 ++
> include/drm/display/drm_dp_helper.h | 6 ++
> 7 files changed, 97 insertions(+), 16 deletions(-)
>
> ---
>
> Changes in v2:
> - Add lane mapping application scenarios in commit message.
> - Remove redundant deprecated property 'data-lanes' for eDP node.
> - Update port@1 $ref to /schemas/graph.yaml#/$defs/port-base.
>
> Changes in v3:
> - Squash [PATCH v2 2/3] into [PATCH v2 1/3].
> - Add unevaluatedProperties: false to both the port@1 and endpoint
> nodes.
>
> Changes in v4:
> - Add validation for samsung,lane-count property as preparation.
>
> Changes in v5:
> - Add DRM DP helper API to validate DP lane counts.
> - Apply DRM DP helper API to check the validity of samsung,lane-count
> property.
> - Add Acked-by and Reviewed-by tags.
>
^ permalink raw reply
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: sashiko-bot @ 2026-06-15 16:00 UTC (permalink / raw)
To: Prabhakar; +Cc: devicetree, robh, conor+dt, wsa+renesas
In-Reply-To: <20260615154805.1619693-8-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Incorrect hardware alarm weekday assignment due to unsigned underflow when the alarm crosses a month boundary.
- [High] Unconfigured alarms in `rzn1_rtc_read_alarm` can return an invalid `tm_wday` value of `-1`, risking out-of-bounds array access in userspace.
- [High] Potential spurious interrupt when sequentially updating active hardware alarm registers.
--
commit d278abd6309a65fff235820bea9a8e8631da47be
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: rtc: rzn1: fix alarm range check truncation on 32-bit systems
This commit fixes a silent truncation issue on 32-bit systems by changing
the alarm and farest variables from unsigned long to time64_t. It also
replaces the time_after() macro with a direct signed comparison.
> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index fe21fa6242881..06339adae71f6 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
[ ... ]
> @@ -265,8 +266,8 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> {
> struct rzn1_rtc *rtc = dev_get_drvdata(dev);
> struct rtc_time *tm = &alrm->time, tm_now;
> - unsigned long alarm, farest;
> unsigned int days_ahead, wday;
> + time64_t alarm, farest;
> int ret;
>
> ret = rzn1_rtc_read_time(dev, &tm_now);
> @@ -276,7 +277,7 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> /* We cannot set alarms more than one week ahead */
> farest = rtc_tm_to_time64(&tm_now) + rtc->rtcdev->alarm_offset_max;
> alarm = rtc_tm_to_time64(tm);
> - if (time_after(alarm, farest))
> + if (alarm > farest)
> return -ERANGE;
>
> /* Convert alarm day into week day */
[Severity: High]
This isn't a bug introduced by this patch, but does the calculation for
days_ahead underflow if the alarm crosses a month boundary?
In rzn1_rtc_set_alarm(), days_ahead is typed as an unsigned int and is
calculated like this:
days_ahead = tm->tm_mday - tm_now.tm_mday;
wday = (tm_now.tm_wday + days_ahead) % 7;
If the alarm is set for the 1st of the next month, and today is the 31st,
the subtraction results in -30. When assigned to an unsigned int, this
underflows. Because 2^32 % 7 evaluates to 4, the resulting wday calculation
shifts the weekday by exactly 4 days, causing the hardware alarm register
to be programmed for the wrong day.
[Severity: High]
This is a pre-existing issue, but is there a risk of a spurious interrupt
when updating the active hardware alarm registers?
Just below this hunk in rzn1_rtc_set_alarm(), the match registers are
updated sequentially:
writel(bin2bcd(tm->tm_min), rtc->base + RZN1_RTC_ALM);
writel(bin2bcd(tm->tm_hour), rtc->base + RZN1_RTC_ALH);
writel(BIT(wday), rtc->base + RZN1_RTC_ALW);
The RTC core can invoke this function without first disabling the hardware
alarm if replacing an existing timer. If the hardware alarm interrupt is
active, modifying these registers sequentially could cause the intermediate
hardware state to momentarily match the current time, triggering a spurious
interrupt and prematurely expiring the next timer in the queue.
[Severity: High]
This is a pre-existing issue, but what happens in rzn1_rtc_read_alarm() if
the hardware alarm is unconfigured?
If the hardware alarm register reads 0, fls(0) - 1 evaluates to -1:
drivers/rtc/rtc-rzn1.c:rzn1_rtc_read_alarm() {
...
wday = readl(rtc->base + RZN1_RTC_ALW);
...
delta_days = ((fls(wday) - 1) - tm->tm_wday + 7) % 7;
tm->tm_wday = fls(wday) - 1;
...
}
If the current weekday is Saturday (6), delta_days evaluates to 0:
((-1 - 6 + 7) % 7) == 0.
Because delta_days is 0, the rtc_time64_to_tm() block is skipped, and the
function returns with tm->tm_wday = -1. Since rtc_valid_tm() does not
bound-check tm_wday, this -1 is passed to userspace where tools commonly
use it as an array index, which could cause an out-of-bounds memory read.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=7
^ permalink raw reply
* Re: [PATCH 05/12] rtc: rzn1: Add system suspend/resume support and wakeup capability
From: sashiko-bot @ 2026-06-15 15:59 UTC (permalink / raw)
To: Prabhakar; +Cc: wsa+renesas, conor+dt, robh, devicetree
In-Reply-To: <20260615154805.1619693-6-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Medium] Incorrect error rollback and returning errors from rzn1_rtc_resume() breaks wakeup configuration.
- [Medium] A hardware limitation is logged as a critical error on every suspend.
Pre-existing issues:
- [High] Asynchronous pm_runtime_put() is used before devres pm_runtime_disable(), leaving hardware powered on.
--
commit 65fe5cbeb3fc2e52fb88cf7b501a98dd6399fa39
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
rtc: rzn1: Add system suspend/resume support and wakeup capability
Add system-wide power management support along with wakeup capability to
the rtc-rzn1 driver, bridging sub-minute gaps with a 1-second periodic
broadcast loop.
> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index 866ff595188d8..12a319e9112c1 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
[ ... ]
> @@ -500,6 +511,74 @@ static void rzn1_rtc_remove(struct platform_device *pdev)
> pm_runtime_put(&pdev->dev);
> }
[Severity: High]
This is a pre-existing issue, but does using pm_runtime_put() here and in
the dis_runtime_pm error path of rzn1_rtc_probe() leave the hardware
powered on?
The driver initializes runtime PM using devm_pm_runtime_enable(), which
registers a devres action to call pm_runtime_disable() upon probe failure
or device removal. By calling the asynchronous pm_runtime_put(), the
suspend operation is queued but immediately cancelled by the subsequent
pm_runtime_disable() devres action.
Should pm_runtime_put_sync() be used instead when pm_runtime_disable()
follows immediately to ensure the device is properly suspended?
> +static int rzn1_rtc_suspend(struct device *dev)
> +{
> + struct rzn1_rtc *rtc = dev_get_drvdata(dev);
> + int ret;
[ ... ]
> + if (rtc->alarm_enabled)
> + dev_crit(dev, "second/minute-level wakeup accuracy cannot be guaranteed by HW\n");
[Severity: Medium]
Does this unconditionally log a critical message on every suspend if the
alarm is enabled?
Since this is a known architectural limitation rather than an acute failure,
this will spam the kernel log with critical severity messages during normal
system suspend operations.
Would it be better to downgrade this to dev_warn() or dev_info()?
> + ret = enable_irq_wake(rtc->alarm_irq);
> + if (ret)
> + return ret;
> + if (rtc->sec_irq >= 0) {
> + ret = enable_irq_wake(rtc->sec_irq);
> + if (ret) {
> + disable_irq_wake(rtc->alarm_irq);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int rzn1_rtc_resume(struct device *dev)
> +{
> + struct rzn1_rtc *rtc = dev_get_drvdata(dev);
> + int ret;
> +
> + if (!device_may_wakeup(dev))
> + return 0;
> +
> + ret = disable_irq_wake(rtc->alarm_irq);
> + if (ret)
> + return ret;
> + if (rtc->sec_irq >= 0) {
> + ret = disable_irq_wake(rtc->sec_irq);
> + if (ret) {
> + enable_irq_wake(rtc->alarm_irq);
> + return ret;
> + }
> + }
[Severity: Medium]
Is it correct to re-enable the alarm_irq wakeup source and return an error
here in rzn1_rtc_resume() if disable_irq_wake() fails?
Because the PM core ignores device resume failures and continues the
system resume sequence, returning an error here and re-enabling alarm_irq
leaves it permanently configured as a wakeup source while the system is
active. This unbalanced state could lead to spurious wakeups.
Should the rollback logic be reconsidered or removed for the resume path?
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=5
^ permalink raw reply
* Re: [PATCH 02/12] rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt
From: sashiko-bot @ 2026-06-15 15:58 UTC (permalink / raw)
To: Prabhakar; +Cc: robh, conor+dt, wsa+renesas, devicetree
In-Reply-To: <20260615154805.1619693-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] If the optional 'xtal' clock is not present, `rtc->sync_time` remains 0, causing `readl_poll_timeout` to use a 0 timeout (infinite wait) and `usleep_range` to use a 0 delay.
--
commit 5d75a1049c228d2049afaf29833f1b2f212837d4
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt
This commit checks for -EPROBE_DEFER from platform_get_irq_byname_optional()
and handles the deferred probe request properly. It intercepts this specific
error condition, assigns it to the return value, and jumps to the
dis_runtime_pm label to avoid ignoring a valid probe deferral.
Fixes: eea7791e00f33 ("rtc: rzn1: implement one-second accuracy for alarms")
Cc: stable@vger.kernel.org
> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index c4ed437354574..f81d691c8b9a2 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
> @@ -465,6 +465,10 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
> }
>
> irq = platform_get_irq_byname_optional(pdev, "pps");
> + if (irq == -EPROBE_DEFER) {
> + ret = irq;
> + goto dis_runtime_pm;
> + }
> if (irq >= 0)
> ret = devm_request_irq(&pdev->dev, irq, rzn1_rtc_1s_irq, 0, "RZN1 RTC 1s", rtc);
[Severity: High]
If the optional xtal clock is not present, does rtc->sync_time remain 0,
causing readl_poll_timeout() to use a 0 timeout (infinite wait) and
usleep_range() to use a 0 delay?
devm_clk_get_optional() returns NULL if the clock is absent in the device
tree, skipping the calculation:
drivers/rtc/rtc-rzn1.c:rzn1_rtc_probe() {
...
xtal = devm_clk_get_optional(dev, "xtal");
if (IS_ERR(xtal)) {
...
} else if (xtal) {
rate = clk_get_rate(xtal);
...
rtc->sync_time = DIV_ROUND_UP(2 * NSEC_PER_MSEC, rate);
}
...
ret = readl_poll_timeout(rtc->base + RZN1_RTC_CTL0, val,
!(val & RZN1_RTC_CTL0_CEST), rtc->sync_time,
rtc->sync_time * 2);
...
}
In include/linux/iopoll.h, a timeout_us of 0 skips the timeout check
entirely, which could lead to a tight infinite loop and a kernel hard lockup
if the hardware fails to clear the CEST bit.
Additionally, rtc->sync_time being 0 causes usleep_range(0, 100) in
rzn1_rtc_set_time(), which may return almost immediately and violate the
hardware's explicit 2-clock-cycle delay requirement (previously hardcoded to
61us).
This regression was introduced by the commit 'rtc: rzn1: Dynamically
calculate synchronization delay based on clock rate' later in this series.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=2
^ permalink raw reply
* Re: [PATCH 12/12] rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
From: sashiko-bot @ 2026-06-15 15:58 UTC (permalink / raw)
To: Prabhakar; +Cc: devicetree, wsa+renesas, conor+dt, robh
In-Reply-To: <20260615154805.1619693-13-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Missing validation allows RZ/T2H variants to fall back to SUBU mode, which accesses physically non-existent registers, potentially causing an SError or Data Abort.
Pre-existing issues:
- [High] If the optional `xtal` clock is omitted in the device tree, `rtc->sync_time` remains 0, leading to infinite tight-polling in `readl_poll_timeout`.
--
commit af1aa184c32ed0a36cb0e267cb73522f881de94d
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
Add a new compatible string "renesas,r9a09g077-rtc" to the OF match table
to support the RTC IP variant found on the RZ/T2H and RZ/N2H SoCs. These
newer SoCs integrate a closely related variant of the RZ/N1 RTC IP but lack
the RTCA0SUBU and RTCA0TCR registers.
> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index 9f9cf9882fc49..dfff8dc8c3212 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
> @@ -597,6 +597,7 @@ static int rzn1_rtc_resume(struct device *dev)
> static DEFINE_SIMPLE_DEV_PM_OPS(rzn1_rtc_pm_ops, rzn1_rtc_suspend, rzn1_rtc_resume);
>
> static const struct of_device_id rzn1_rtc_of_match[] = {
> + { .compatible = "renesas,r9a09g077-rtc" },
[Severity: High]
The commit message notes that the new RZ/T2H variants lack the RTCA0SUBU
register and rely on rzn1_rtc_ops_scmp configurations. However, is it safe to
rely on the clock configuration to select between SCMP and SUBU operations?
In rzn1_rtc_probe(), the fallback to SUBU mode is based solely on the xtal
clock:
drivers/rtc/rtc-rzn1.c:rzn1_rtc_probe() {
if (xtal) {
rate = clk_get_rate(xtal);
...
if (rate != 32768)
scmp_val = RZN1_RTC_CTL0_SLSB_SCMP;
...
}
if (scmp_val) {
writel(rate - 1, rtc->base + RZN1_RTC_SCMP);
rtc->rtcdev->ops = &rzn1_rtc_ops_scmp;
} else {
rtc->rtcdev->ops = &rzn1_rtc_ops_subu;
}
}
If the device tree misconfigures the clock (e.g., rate is exactly 32768) or
omits the optional xtal clock entirely, scmp_val will be 0. The driver will
dynamically assign rzn1_rtc_ops_subu as the ops.
Subsequent operations like rzn1_rtc_read_offset() will directly access the
missing register:
drivers/rtc/rtc-rzn1.c:rzn1_rtc_read_offset() {
val = readl(rtc->base + RZN1_RTC_SUBU);
}
Could this cause an unhandled SError or Data Abort when accessing the
physically non-existent SUBU register on RZ/T2H? Should the driver explicitly
enforce the use of SCMP operations for this compatible string regardless of the
clock configuration?
[Severity: High]
This is a pre-existing issue, but if the optional xtal clock is omitted in the
device tree, rtc->sync_time remains 0 since it is initialized by devm_kzalloc()
and the calculation block is skipped.
Later in rzn1_rtc_probe():
/* Wait 2-4 RTC_PCLK clock cycles for the disabled controller to stop */
ret = readl_poll_timeout(rtc->base + RZN1_RTC_CTL0, val,
!(val & RZN1_RTC_CTL0_CEST), rtc->sync_time,
rtc->sync_time * 2);
Passing a timeout of 0 to readl_poll_timeout() instructs it to never time out.
Combined with a sleep_us of 0, could this result in an infinite tight loop
if the hardware condition !(val & RZN1_RTC_CTL0_CEST) is never met during
probe?
> { .compatible = "renesas,rzn1-rtc" },
> {},
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=12
^ permalink raw reply
* Re: [PATCH v3 3/3] regulator: qcom-refgen: add support for the IPQ9650 SoC
From: Mark Brown @ 2026-06-15 15:58 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, linux-arm-msm, linux-kernel, devicetree,
Dmitry Baryshkov
In-Reply-To: <20260615-ipq9650_refgen-v3-3-5f611623629c@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]
On Mon, Jun 15, 2026 at 02:05:49PM +0530, Kathiravan Thirumoorthy wrote:
> IPQ9650 SoC has 2 REFGEN blocks providing the reference current to the
> PCIe and USB, UNIPHY PHYs. For the other SoCs, clock for this block is
> enabled on power up but that's not the case for IPQ9650 and we have to
> enable those clocks explicitly to bring up the PHYs properly.
> +static int qcom_ipq9650_refgen_enable(struct regulator_dev *rdev)
> +{
> + struct qcom_refgen_drvdata *drvdata = rdev_get_drvdata(rdev);
> + int ret;
> +
> + ret = clk_bulk_prepare_enable(drvdata->num_clks, drvdata->clks);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +static int qcom_ipq9650_refgen_disable(struct regulator_dev *rdev)
> +{
> + struct qcom_refgen_drvdata *drvdata = rdev_get_drvdata(rdev);
> +
> + clk_bulk_disable_unprepare(drvdata->num_clks, drvdata->clks);
> +
> + return 0;
> +}
> +static const struct regulator_desc ipq9650_refgen_desc = {
> + .enable_reg = REFGEN_REG_REFGEN_STATUS,
> + .enable_mask = REFGEN_STATUS_OUT_MASK,
> + .enable_val = REFGEN_STATUS_OUT_ENABLE,
> + .ops = &(const struct regulator_ops) {
> + .enable = qcom_ipq9650_refgen_enable,
> + .disable = qcom_ipq9650_refgen_disable,
> + .is_enabled = regulator_is_enabled_regmap,
> + },
This looks like a get_status() operation, not an enable operation? The
enables and disables are pure clock operations.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 08/12] rtc: rzn1: Dynamically calculate synchronization delay based on clock rate
From: sashiko-bot @ 2026-06-15 15:57 UTC (permalink / raw)
To: Prabhakar; +Cc: conor+dt, devicetree, robh, wsa+renesas
In-Reply-To: <20260615154805.1619693-9-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Uninitialized `rtc->sync_time` causing infinite polling loop and missing hardware delays when optional `xtal` clock is absent.
- [Low] Semantic unit mismatch using `NSEC_PER_MSEC` for microsecond duration calculation.
--
commit 1c4e11a547342229c6e4a580cb676efaab170aba
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
rtc: rzn1: Dynamically calculate synchronization delay based on clock rate
This commit replaces hardcoded hardware synchronization delays with a
dynamically calculated time window derived from the runtime clock rate.
It stores the calculated clock cycles in the driver private structure to
adjust sleep boundaries dynamically.
> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index 06339adae71f6..bc6af59744e48 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
[ ... ]
> @@ -124,8 +125,8 @@ static int rzn1_rtc_set_time(struct device *dev, struct rtc_time *tm)
> /* Hold the counter if it was counting up */
> writel(RZN1_RTC_CTL2_WAIT, rtc->base + RZN1_RTC_CTL2);
>
> - /* Wait for the counter to stop: two 32k clock cycles */
> - usleep_range(61, 100);
> + /* Wait for the counter to stop: two RTC_PCLK clock cycles */
> + usleep_range(rtc->sync_time, rtc->sync_time + 100);
[Severity: High]
If the optional xtal clock is missing, rtc->sync_time remains 0 because the
calculation block in rzn1_rtc_probe() is skipped.
Does this evaluate to usleep_range(0, 100), bypassing the hardware's
required minimum 2-cycle synchronization wait period?
[ ... ]
> @@ -433,17 +434,25 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
> ret = -EOPNOTSUPP;
> goto dis_runtime_pm;
> }
> -
> if (rate != 32768)
> scmp_val = RZN1_RTC_CTL0_SLSB_SCMP;
> +
> + /*
> + * The internal clock counter operates in synchronization with the
> + * RTC_PCLK clock. Calculate the duration of two RTC_PCLK clock
> + * cycles in microseconds required for operations to complete.
> + */
> + rtc->sync_time = DIV_ROUND_UP(2 * NSEC_PER_MSEC, rate);
[Severity: Low]
This isn't a bug, but the calculation uses NSEC_PER_MSEC to compute
microseconds. While mathematically equivalent to 1,000,000, could this
use USEC_PER_SEC to clearly reflect a Hz-to-microseconds conversion?
[Severity: High]
The driver retrieves the xtal clock using devm_clk_get_optional() earlier
in rzn1_rtc_probe(). If the clock is missing, the else if (xtal) block is
skipped entirely.
Does this leave rtc->sync_time uninitialized at 0 for the default internal
clock?
> +
> }
>
> /* Disable controller during SUBU/SCMP setup */
> val = readl(rtc->base + RZN1_RTC_CTL0) & ~RZN1_RTC_CTL0_CE;
> writel(val, rtc->base + RZN1_RTC_CTL0);
> - /* Wait 2-4 32k clock cycles for the disabled controller */
> + /* Wait 2-4 RTC_PCLK clock cycles for the disabled controller to stop */
> ret = readl_poll_timeout(rtc->base + RZN1_RTC_CTL0, val,
> - !(val & RZN1_RTC_CTL0_CEST), 62, 123);
> + !(val & RZN1_RTC_CTL0_CEST), rtc->sync_time,
> + rtc->sync_time * 2);
[Severity: High]
If rtc->sync_time is 0 from the missing optional clock, the timeout argument
(rtc->sync_time * 2) evaluates to 0.
Since readl_poll_timeout() treats a 0 timeout as explicitly disabling the
timeout check, will this turn the wait into an infinite tight loop if the
hardware fails to respond?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=8
^ permalink raw reply
* Re: [PATCH 11/12] rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access
From: sashiko-bot @ 2026-06-15 15:57 UTC (permalink / raw)
To: Prabhakar; +Cc: robh, devicetree, conor+dt, wsa+renesas
In-Reply-To: <20260615154805.1619693-12-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Incomplete refactoring: open-coded logic remains for RZN1_RTC_SUBU_RTCA0FX
--
commit 2e16f66c80c483d619655d20fbb859a42e9d1b6d
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access
This commit replaces open-coded shift and mask operations with the bitfield
API in the rzn1 RTC driver to improve readability and match the hardware
manual.
> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index c7ef3c81180f4..9f9cf9882fc49 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
[ ... ]
> @@ -306,7 +312,7 @@ static int rzn1_rtc_read_offset(struct device *dev, long *offset)
> val = readl(rtc->base + RZN1_RTC_SUBU);
> ppb_per_step = val & RZN1_RTC_SUBU_DEV ? 1017 : 3051;
> subtract = val & RZN1_RTC_SUBU_DECR;
> - val &= 0x3F;
> + val = FIELD_GET(RZN1_RTC_SUBU_RTCA0FX, val);
>
> if (!val)
> *offset = 0;
[Severity: Low]
Since the stated goal of this patch is to replace open-coded masks with the
bitfield API, should the remaining 0x3F masks for this register be updated as
well?
In rzn1_rtc_read_offset() just below this change, there is still an explicit
mask used when calculating the offset:
*offset = -(((~val) & 0x3F) + 1) * ppb_per_step;
Additionally, it looks like the write path in rzn1_rtc_set_offset() was missed
entirely during the refactoring. It continues to use open-coded logic rather
than FIELD_PREP when constructing the RZN1_RTC_SUBU register:
subu |= RZN1_RTC_SUBU_DECR;
subu |= (~(-steps - 1)) & 0x3F;
Would it make sense to update these locations so the bitfield access is
consistent across the driver?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=11
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: qcom: lemans-pmics: Add ADC support for PMM8654au
From: Konrad Dybcio @ 2026-06-15 15:56 UTC (permalink / raw)
To: Jishnu Prakash, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ayyagari Ushasreevalli,
Kamal Wadhwa
In-Reply-To: <20260430-adc5_gen3_dt-v1-2-ab2bb40fd490@oss.qualcomm.com>
On 4/30/26 10:58 AM, Jishnu Prakash wrote:
> From: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com>
>
> Add ADC nodes for the four PMM8654au PMICs (pmm8654au_0 through
> pmm8654au_3) on the Lemans platform.
>
> Each ADC node exposes the following ADC channels:
> - DIE_TEMP: PMIC die temperature channel
> - VPH_PWR: Battery/supply voltage channel
>
> Also add the io-channels and io-channel-names properties under
> the temp-alarm nodes so that they can get temperature reading
> from the ADC die_temp channels.
>
> Signed-off-by: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com>
> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/lemans-pmics.dtsi | 93 ++++++++++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/lemans-pmics.dtsi b/arch/arm64/boot/dts/qcom/lemans-pmics.dtsi
> index 341119fc8244..6caec3e4df4b 100644
> --- a/arch/arm64/boot/dts/qcom/lemans-pmics.dtsi
> +++ b/arch/arm64/boot/dts/qcom/lemans-pmics.dtsi
> @@ -5,6 +5,7 @@
>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/spmi/spmi.h>
> +#include "qcom-adc5-gen3.h"
>
> / {
> thermal-zones {
> @@ -110,6 +111,8 @@ pmm8654au_0_temp_alarm: temp-alarm@a00 {
> reg = <0xa00>;
> interrupts-extended = <&spmi_bus 0x0 0xa 0x0 IRQ_TYPE_EDGE_BOTH>;
> #thermal-sensor-cells = <0>;
> + io-channels = <&pmm8654au_0_adc ADC5_GEN3_DIE_TEMP(0)>;
> + io-channel-names = "thermal";
> };
>
> pmm8654au_0_pon: pon@1200 {
> @@ -141,6 +144,27 @@ pmm8654au_0_rtc: rtc@6100 {
> interrupts = <0x0 0x62 0x1 IRQ_TYPE_EDGE_RISING>;
> };
>
> + pmm8654au_0_adc: adc@8000 {
> + compatible = "qcom,spmi-adc5-gen3";
> + reg = <0x8000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <0x0 0x80 0x1 IRQ_TYPE_EDGE_RISING>;
> + #io-channel-cells = <1>;
> +
> + channel@3 {
> + reg = <ADC5_GEN3_DIE_TEMP(0)>;
> + label = "pmm8654au_0_die_temp";
Are these labels namespaced, i.e. can the label be just "pm8654au_die_temp"
or "die_temp"?
Konrad
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
From: sashiko-bot @ 2026-06-15 15:56 UTC (permalink / raw)
To: Prabhakar; +Cc: conor+dt, devicetree, wsa+renesas, robh
In-Reply-To: <20260615154805.1619693-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The binding schema enforces a non-existent `timer` interrupt for the new RZ/T2H and RZ/N2H SoC variants.
--
commit be9b5c77c196688e72ded5e0e7c0ff1038239897
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
This commit adds compatible strings for the RTC block on the Renesas RZ/T2H
and RZ/N2H SoCs. It notes that these variants do not implement the RTCA0SUBU
and RTCA0TCR registers and updates the binding schema to require additional
clock inputs.
> diff --git a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
> index 1860f0e4c31a2..ea7b039a91e77 100644
> --- a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
[ ... ]
> @@ -54,6 +58,23 @@ required:
> - clock-names
> - power-domains
>
> +allOf:
> + - $ref: rtc.yaml#
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,r9a09g077-rtc
> + - renesas,r9a09g087-rtc
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + clock-names:
> + minItems: 2
[Severity: Medium]
The commit message mentions that these new SoC variants do not implement the
RTCA0TCR (Timer Control Register). Does this mean the hardware also lacks
the timer interrupt?
If the timer interrupt is not present on these variants, should this
conditional block also relax the interrupts and interrupt-names constraints?
The base binding expects three interrupts (alarm, timer, and pps). Without
an override here, won't device tree validation fail for accurately described
hardware that omits the timer interrupt?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=1
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: Add header file for ADC5 Gen3 channel macros
From: Konrad Dybcio @ 2026-06-15 15:55 UTC (permalink / raw)
To: Jishnu Prakash, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ayyagari Ushasreevalli,
Kamal Wadhwa
In-Reply-To: <20260430-adc5_gen3_dt-v1-1-ab2bb40fd490@oss.qualcomm.com>
On 4/30/26 10:58 AM, Jishnu Prakash wrote:
> Add macro definitions for virtual channels (combination of ADC channel
> number and PMIC SID number), to be used in devicetree by clients of ADC5
> GEN3 device and in the "reg" property of ADC channels.
>
> Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: qcom: sc8280xp: add Ayaneo Pocket S2 card with special WSA channel mapping
From: Neil Armstrong @ 2026-06-15 15:53 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: kancy2333, linux-sound, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <4e0f7aac-fd1e-40b7-a71e-47d02f10f3d2@kernel.org>
On 6/15/26 10:42, Srinivas Kandagatla wrote:
> Thanks Neil for the patch.
>
> On 6/10/26 8:41 AM, Neil Armstrong wrote:
>> The WSA Speakers are connected on the WSA2 interface, but the
>> WSA and WSA2 links are handled as a single dai and DSP interface, so
>> we need to specify the channel mapping of the Ayaneo Pocket S2 for the
>> WSA dai in order to have functional playback and avoid DSP errors.
>>
>> Let's add a special entry for the Ayaneo Pocket S2 adding a prepare
>> callback in order to set the proper channel mapping.
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> sound/soc/qcom/sc8280xp.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 56 insertions(+)
>>
>> diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
>> index 1f3afc6d015c..2f1688c9f317 100644
>> --- a/sound/soc/qcom/sc8280xp.c
>> +++ b/sound/soc/qcom/sc8280xp.c
>> @@ -14,6 +14,7 @@
>> #include "qdsp6/q6afe.h"
>> #include "qdsp6/q6apm.h"
>> #include "qdsp6/q6prm.h"
>> +#include "qdsp6/q6dsp-common.h"
>> #include "common.h"
>> #include "sdw.h"
>>
>> @@ -49,6 +50,7 @@ struct snd_soc_common {
>> bool codec_sysclk_set;
>> bool mi2s_mclk_enable;
>> bool mi2s_bclk_enable;
>> + int (*snd_prepare)(struct snd_pcm_substream *substream);
>> };
>>
>> struct sc8280xp_snd_data {
>> @@ -193,12 +195,58 @@ static int sc8280xp_snd_hw_params(struct snd_pcm_substream *substream,
>> return 0;
>> }
>>
>> +/*
>> + * WSA and WSA2 are handled as a single interface with the
>> + * following channels mask:
> It should not be handled as single interface in this case, you could use
> WSA2 as it is.
I would prefer, could you help me understand how to use it ?
>
>> + * __________________________________________________
>> + * | Bits | 3 | 2 | 1 | 0 |
>> + * ---------------------------------------------------
>> + * | Line | WSA2 Ch2 | WSA2 Ch1 | WSA Ch2 | WSA Ch1 |
>> + * ---------------------------------------------------
>> + *
>> + * The Ayaneo Pocket S2 speakers are connected only to
>> + * the WSA2 interface and the WSA interface is not enabled.
>> + *
>> + * Set the channel mapping on the WSA2 channels only.
>> + */
>> +static const unsigned int ayaneo_ps2_channels_mapping[] = {
>> + 0, /* WSA Ch1 */
>> + 0, /* WSA Ch2 */
>> + PCM_CHANNEL_FL, /* WSA2 Ch1 */
>> + PCM_CHANNEL_FR /* WSA2 Ch2 */
>> +};
>
> So we are are playing 4 channels on a 2 channel speakers?
No, because the only way we found to play on the WSA2 speakers
is to pass set active_channels_mask 0x1100 with lpaif_type to LPAIF_INTF_TYPE_WSA.
I followed your advice to play with the channel map, here's the result.
>
> There is also a patch by Abel, on allowing userspace/ucm to set the
> channel map for WSA at https://lkml.org/lkml/2026/6/10/1002
> Its worth having a look.
It's unrelated, I don't need to change the mapping from userspace.
Thanks,
Neil
>
> --srini
>
>> +
>> +static int ayaneo_ps2_snd_prepare(struct snd_pcm_substream *substream)
>> +{
>> + struct snd_soc_pcm_runtime *rtd = snd_soc_substream_to_rtd(substream);
>> + struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
>> + unsigned int channels = substream->runtime->channels;
>> +
>> + if (cpu_dai->id != WSA_CODEC_DMA_RX_0)
>> + return 0;
>> +
>> + if (channels != 2)
>> + return -EINVAL;
>> +
>> + return snd_soc_dai_set_channel_map(cpu_dai, 0, NULL,
>> + ARRAY_SIZE(ayaneo_ps2_channels_mapping),
>> + ayaneo_ps2_channels_mapping);
>> +}
>> +
>> static int sc8280xp_snd_prepare(struct snd_pcm_substream *substream)
>> {
>> struct snd_soc_pcm_runtime *rtd = snd_soc_substream_to_rtd(substream);
>> struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
>> struct sc8280xp_snd_data *data = snd_soc_card_get_drvdata(rtd->card);
>>
>> + if (data->snd_soc_common_priv->snd_prepare) {
>> + int ret;
>> +
>> + ret = data->snd_soc_common_priv->snd_prepare(substream);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> return qcom_snd_sdw_prepare(substream, &data->stream_prepared[cpu_dai->id]);
>> }
>>
>> @@ -273,6 +321,13 @@ static int sc8280xp_platform_probe(struct platform_device *pdev)
>> return devm_snd_soc_register_card(dev, card);
>> }
>>
>> +static struct snd_soc_common ayaneo_ps2_priv_data = {
>> + .driver_name = "ayaneo-ps2",
>> + .dapm_widgets = sc8280xp_dapm_widgets,
>> + .num_dapm_widgets = ARRAY_SIZE(sc8280xp_dapm_widgets),
>> + .snd_prepare = ayaneo_ps2_snd_prepare,
>> +};
>> +
>> static struct snd_soc_common kaanapali_priv_data = {
>> .driver_name = "kaanapali",
>> .dapm_widgets = sc8280xp_dapm_widgets,
>> @@ -341,6 +396,7 @@ static struct snd_soc_common sm8750_priv_data = {
>> };
>>
>> static const struct of_device_id snd_sc8280xp_dt_match[] = {
>> + {.compatible = "ayaneo,pocket-s2-sndcard", .data = &ayaneo_ps2_priv_data},
>> {.compatible = "qcom,kaanapali-sndcard", .data = &kaanapali_priv_data},
>> {.compatible = "qcom,qcm6490-idp-sndcard", .data = &qcm6490_priv_data},
>> {.compatible = "qcom,qcs615-sndcard", .data = &qcs615_priv_data},
>>
>
^ permalink raw reply
* Re: [PATCH v7 5/5] iio: adc: versal-sysmon: add oversampling support
From: Erim, Salih @ 2026-06-15 15:50 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajAL__3jUtSgSb7r@ashevche-desk.local>
Hi Andy,
Thanks for the review, replies inline.
On 15/06/2026 15:28, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 12:37:22AM +0100, Salih Erim wrote:
>> Add support for reading and writing the oversampling ratio through
>> the IIO oversampling_ratio attribute. The hardware supports averaging
>> 2, 4, 8, or 16 samples, plus a ratio of 1 (no averaging).
>>
>> Temperature and supply channels share oversampling configuration at
>> the type level (all temperature channels share one ratio, all supply
>> channels share another), exposed through info_mask_shared_by_type.
>>
>> The hardware encoding uses sample_count / 2 in a 4-bit field within
>> the CONFIG register. Per-channel averaging enable registers must also
>> be updated to activate or deactivate averaging.
>
> ...
>
>> +static int sysmon_osr_write_temp(struct sysmon *sysmon, int val)
>> +{
>> + /*
>> + * HW register encoding is sample_count / 2:
>> + * 0=none, 1=2x, 2=4x, 4=8x, 8=16x (not log2-based).
>> + */
>> + int hw_val = val >> 1;
>
> If, for some reason, val happens to be a small negative number, here might be
> a surprising behaviour.
The caller validates val against the oversampling_avail list
{1, 2, 4, 8, 16} before calling, so negatives never reach here.
But the parameter should be unsigned int to make that obvious.
Will change in v8.
>
>> + unsigned int readback;
>> + int ret;
>> +
>> + ret = regmap_update_bits(sysmon->regmap, SYSMON_CONFIG,
>> + SYSMON_CONFIG_TEMP_SAT_OSR,
>> + FIELD_PREP(SYSMON_CONFIG_TEMP_SAT_OSR, hw_val));
>> + if (ret)
>> + return ret;
>> +
>> + /*
>> + * Readback fence: the SysMon CONFIG register resides in the
>> + * PMC domain behind the NoC. A posted write may not reach the
>> + * hardware before the next MMIO access. Reading the register
>> + * back forces the interconnect to complete the write, preventing
>> + * a bus hang on the subsequent access.
>> + */
>> + regmap_read(sysmon->regmap, SYSMON_CONFIG, &readback);
>> +
>> + return sysmon_set_avg_enable(sysmon, SYSMON_TEMP_EN_AVG_BASE,
>> + SYSMON_TEMP_EN_AVG_COUNT,
>> + hw_val ? ~0U : 0);
>
> Is the last parameter > 32-bit? If not, drop 'U' as it might have a nice
> side-effect in case this become actually > 32-bit. Same for other cases.
> In other words, using ~0U should be quite cautious.
Will change to ~0. Same for both call sites.
Thanks,
Salih
>
>> +}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* [PATCH 12/12] rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add a new compatible string "renesas,r9a09g077-rtc" to the OF match table
to support the RTC IP variant found on the RZ/T2H and RZ/N2H SoCs.
These newer SoCs integrate a closely related variant of the RZ/N1 RTC IP.
The RZ/T2H and RZ/N2H variants lack the RTCA0SUBU and RTCA0TCR registers,
those registers are not accessed or used when operating under the
rzn1_rtc_ops_scmp configurations, making the current infrastructure
compatible.
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.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 9f9cf9882fc4..dfff8dc8c321 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -597,6 +597,7 @@ static int rzn1_rtc_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(rzn1_rtc_pm_ops, rzn1_rtc_suspend, rzn1_rtc_resume);
static const struct of_device_id rzn1_rtc_of_match[] = {
+ { .compatible = "renesas,r9a09g077-rtc" },
{ .compatible = "renesas,rzn1-rtc" },
{},
};
--
2.54.0
^ permalink raw reply related
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