All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Simon Glass" <sjg@chromium.org>
Cc: devicetree@vger.kernel.org, conor+dt@kernel.org, robh@kernel.org
Subject: Re: [PATCH v3 3/4] dt-bindings: pinctrl: rockchip: Add RV1106 compatible
Date: Wed, 29 Jul 2026 13:48:32 +0000	[thread overview]
Message-ID: <20260729134833.45A921F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729072727.v3.3.3a4f9d47d4dba36e14141f8796afe8907028aa9c@changeid>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing pinctrl driver match support for 'rockchip,rv1106-pinctrl'
- [High] Silent truncation and unreachable dead code in rockchip_get_drive_perpin()
- [Medium] Unused 'rockchip,grf' property in 'gpio-bank' child nodes
--

--- Patch [3]: [PATCH v3 3/4] dt-bindings: pinctrl: rockchip: Add RV1106 compatible ---
commit f508d7fe3fdaea1487deaf572cd3b667691010ce
Author: Simon Glass <sjg@chromium.org>

dt-bindings: pinctrl: rockchip: Add RV1106 compatible

Add the compatible for the pin controller of the Rockchip RV1106 and
its RV1103 package variant.

> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
> index 9b3cbeb54fed4..81747bb530569 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml
> @@ -51,6 +51,7 @@ properties:
>        - rockchip,rk3576-pinctrl
>        - rockchip,rk3588-pinctrl
>        - rockchip,rv1103b-pinctrl
> +      - rockchip,rv1106-pinctrl

[Severity: High]
Does this compatible string need to be added to the driver match table as well?

The schema strictly enforces 'rockchip,rv1106-pinctrl' without an allowable
fallback compatible, but it appears to be missing from the driver:

drivers/pinctrl/pinctrl-rockchip.c:rockchip_pinctrl_dt_match[] {
	static const struct of_device_id rockchip_pinctrl_dt_match[] = {
		{ .compatible = "rockchip,px30-pinctrl",
    ...
}

Will the pinctrl driver silently fail to probe for any device tree using this
new compatible string?

[Severity: Medium]
Will this new hardware function correctly without parsing the rockchip,grf
property in gpio-bank child nodes?

The property appears to be correctly documented for gpio-bank subnodes:

Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml {
    ...
      rockchip,grf:
        $ref: /schemas/types.yaml#/definitions/phandle
    ...
}

But looking at the driver, it only parses rockchip,grf from the parent
pinctrl node and seems to ignore the subnodes entirely:

drivers/pinctrl/pinctrl-rockchip.c:rockchip_pinctrl_probe() {
    ...
	node = of_parse_phandle(np, "rockchip,grf", 0);
    ...
}

Could this cause the hardware feature for per-bank IOC control to be
non-functional?

[Severity: High]
Can the RV1103B override logic lead to silent truncation and unreachable code?

Looking at rockchip_get_drive_perpin(), an override forces
DRV_TYPE_IO_LEVEL_2_BIT:

drivers/pinctrl/pinctrl-rockchip.c:rockchip_get_drive_perpin() {
    ...
	if (ctrl->type == RV1103B && pin_num >= 12)
		drv_type = DRV_TYPE_IO_LEVEL_2_BIT;
    ...
}

This hits the 2-bit case block, which introduces an early return and performs a
2-bit truncation for Banks 0 and 1:

drivers/pinctrl/pinctrl-rockchip.c:rockchip_get_drive_perpin() {
    ...
	case DRV_TYPE_IO_LEVEL_2_BIT:
		ret = regmap_read(regmap, reg, &data);
		if (ret)
			return ret;
		data >>= bit;

		return data & 0x3;
    ...
}

Because of this early return, does the fallback logic for RV1103B at the
bottom of the function become structurally dead?

drivers/pinctrl/pinctrl-rockchip.c:rockchip_get_drive_perpin() {
    ...
	if (ctrl->type == RV1103B && bank->bank_num == 2 && pin_num >= 12) {
		data = data >> 10;
		return data & 0x3;
	}
    ...
}

Since the override lacks a bank number check, won't 8-bit drive strength pins
on Banks 0 and 1 with pin_num >= 12 now incorrectly hit the new 2-bit case
block and be silently bitwise-truncated to a 2-bit value?

>        - rockchip,rv1108-pinctrl
>        - rockchip,rv1126-pinctrl

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729132736.3807082-1-sjg@chromium.org?part=3

  reply	other threads:[~2026-07-29 13:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 13:27 [PATCH v3 0/4] pinctrl: Add support for the Rockchip RV1106 Simon Glass
2026-07-29 13:27 ` Simon Glass
2026-07-29 13:27 ` [PATCH v3 1/4] pinctrl: rockchip: Decode drive strength in the get function Simon Glass
2026-07-29 13:27   ` Simon Glass
2026-07-29 13:42   ` sashiko-bot
2026-07-29 13:27 ` [PATCH v3 2/4] dt-bindings: gpio: rockchip,gpio-bank: Add rockchip,grf property Simon Glass
2026-07-29 13:27   ` Simon Glass
2026-07-29 13:46   ` sashiko-bot
2026-07-29 13:27 ` [PATCH v3 3/4] dt-bindings: pinctrl: rockchip: Add RV1106 compatible Simon Glass
2026-07-29 13:27   ` Simon Glass
2026-07-29 13:48   ` sashiko-bot [this message]
2026-07-29 13:27 ` [PATCH v3 4/4] pinctrl: rockchip: Add RV1106 pinctrl support Simon Glass
2026-07-29 13:27   ` Simon Glass
2026-07-29 13:47   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260729134833.45A921F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sjg@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.