[PATCH 0/2] pinctrl: rockchip: Two fixes for latent driver bugs

[PATCH 0/2] pinctrl: rockchip: Two fixes for latent driver bugs

[Simon Glass]

This series contains two small fixes for pre-existing issues in the
Rockchip pinctrl driver, found by the sashiko AI review of my RV1106
series.

The first makes the SoC-data calculation safe when the probe runs
more than once due to a probe deferral: the pin count currently
accumulates across runs, shifting every bank's pin base. The second
aligns the RV1103B drive-type override in the get path with the set
path, which restricts it to bank 2.

The first fix is tested on a Luckfox Pico Mini B by forcing the
probe to defer once: without the fix the second probe doubles the
pin count and no GPIO bank comes up, while with it the values are
recalculated identically and all banks work. The second is a
behavioural no-op until drive-strength decoding is added to the get
path, so it is verified by inspection against the set path.


Simon Glass (2):
  pinctrl: rockchip: Reset the pin count when recalculating SoC data
  pinctrl: rockchip: Restrict the RV1103B 2-bit drive type to bank 2

 drivers/pinctrl/pinctrl-rockchip.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

---
base-commit: fc02acf6ac0ccde0c805c2daa9148683cdd01ba8
branch: rkpinfix

-- 
2.43.0

[PATCH 1/2] pinctrl: rockchip: Reset the pin count when recalculating SoC data

[Simon Glass]

rockchip_pinctrl_get_soc_data() mutates the static per-SoC data. The
iomux and drive offsets are recalculated idempotently, since a rerun
anchors at the values calculated before, but the total pin count only
accumulates: each run adds every bank's pins again. When the probe is
deferred and runs a second time, nr_pins doubles and every bank's
pin_base shifts, so later pin lookups resolve to the wrong bank and
the wrong registers.

Reset the pin count at the start of the calculation, so that a rerun
produces the same values.

This is verified on a Luckfox Pico Mini B (RV1103, with the pending
RV1106 series applied) by forcing the probe to defer once: without
this patch the second probe calculates nr_pins=304 instead of 152 and
no GPIO bank comes up; with it the recalculation matches the first
run and all banks work.

Fixes: d3e5116119bd ("pinctrl: add pinctrl driver for Rockchip SoCs")
Link: https://sashiko.dev/#/patchset/20260729132736.3807082-1-sjg@chromium.org?part=4
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Glass <sjg@chromium.org>

---

 drivers/pinctrl/pinctrl-rockchip.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
index 7e0fcd45fd26..8bfc7ab5de15 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -4296,6 +4296,16 @@ static struct rockchip_pin_ctrl *rockchip_pinctrl_get_soc_data(
 	pmu_offs = ctrl->pmu_mux_offset;
 	drv_pmu_offs = ctrl->pmu_drv_offset;
 	drv_grf_offs = ctrl->grf_drv_offset;
+
+	/*
+	 * This function mutates the static per-SoC data. Most of it is
+	 * idempotent: recalculated iomux and drv offsets anchor at the
+	 * values calculated by a previous run. The pin count is not, so
+	 * reset it here; otherwise it accumulates when the probe runs
+	 * again after a probe deferral, shifting every bank's pin_base.
+	 */
+	ctrl->nr_pins = 0;
+
 	bank = ctrl->pin_banks;
 	for (i = 0; i < ctrl->nr_banks; ++i, ++bank) {
 		int bank_pins = 0;
-- 
2.43.0

[PATCH 2/2] pinctrl: rockchip: Restrict the RV1103B 2-bit drive type to bank 2

[Simon Glass]

The RV1103B override in rockchip_get_drive_perpin() forces the 2-bit
level drive type for every pin above 11, but only bank 2 has the
2-bit fields; banks 0 and 1 use the 8-bit level type for all pins,
as the corresponding check in rockchip_set_drive_perpin() shows.

Today this is harmless, since neither level type is decoded in the
get function and both paths fail with -EINVAL. It becomes an active
problem once decoding is added, as the pins of banks 0 and 1 would
be truncated to 2-bit values. Add the missing bank check, matching
the set path.

Fixes: 6d3ea3120eaa ("pinctrl: rockchip: Add RV1103B pinctrl support")
Link: https://sashiko.dev/#/patchset/20260729132736.3807082-1-sjg@chromium.org?part=1
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Glass <sjg@chromium.org>

---

 drivers/pinctrl/pinctrl-rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
index 8bfc7ab5de15..08084ed2cf1b 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -3212,7 +3212,7 @@ static int rockchip_get_drive_perpin(struct rockchip_pin_bank *bank,
 	u8 bit;
 	int drv_type = bank->drv[pin_num / 8].drv_type;
 
-	if (ctrl->type == RV1103B && pin_num >= 12)
+	if (ctrl->type == RV1103B && bank->bank_num == 2 && pin_num >= 12)
 		drv_type = DRV_TYPE_IO_LEVEL_2_BIT;
 
 	ret = ctrl->drv_calc_reg(bank, pin_num, &regmap, &reg, &bit);
-- 
2.43.0

Re: [PATCH 0/2] pinctrl: rockchip: Two fixes for latent driver bugs

[Linus Walleij]

Hi Simon,

On Mon, Aug 3, 2026 at 4:10 PM Simon Glass <sjg@chromium.org> wrote:

> This series contains two small fixes for pre-existing issues in the
> Rockchip pinctrl driver, found by the sashiko AI review of my RV1106
> series.
>
> The first makes the SoC-data calculation safe when the probe runs
> more than once due to a probe deferral: the pin count currently
> accumulates across runs, shifting every bank's pin base. The second
> aligns the RV1103B drive-type override in the get path with the set
> path, which restricts it to bank 2.
>
> The first fix is tested on a Luckfox Pico Mini B by forcing the
> probe to defer once: without the fix the second probe doubles the
> pin count and no GPIO bank comes up, while with it the values are
> recalculated identically and all banks work. The second is a
> behavioural no-op until drive-strength decoding is added to the get
> path, so it is verified by inspection against the set path.

Patches looks good and the Rockchip maintainers haven't
commented on the other week-old patches yet so I applied
these two patches.

If the maintainers have issues with them I can pull them out.

Yours,
Linus Walleij

Re: [PATCH 0/2] pinctrl: rockchip: Two fixes for latent driver bugs

[Heiko Stübner]

Am Freitag, 7. August 2026, 00:12:51 Mitteleuropäische Sommerzeit schrieb Linus Walleij:
> Hi Simon,
> 
> On Mon, Aug 3, 2026 at 4:10 PM Simon Glass <sjg@chromium.org> wrote:
> 
> > This series contains two small fixes for pre-existing issues in the
> > Rockchip pinctrl driver, found by the sashiko AI review of my RV1106
> > series.
> >
> > The first makes the SoC-data calculation safe when the probe runs
> > more than once due to a probe deferral: the pin count currently
> > accumulates across runs, shifting every bank's pin base. The second
> > aligns the RV1103B drive-type override in the get path with the set
> > path, which restricts it to bank 2.
> >
> > The first fix is tested on a Luckfox Pico Mini B by forcing the
> > probe to defer once: without the fix the second probe doubles the
> > pin count and no GPIO bank comes up, while with it the values are
> > recalculated identically and all banks work. The second is a
> > behavioural no-op until drive-strength decoding is added to the get
> > path, so it is verified by inspection against the set path.
> 
> Patches looks good and the Rockchip maintainers haven't
> commented on the other week-old patches yet so I applied
> these two patches.
> 
> If the maintainers have issues with them I can pull them out.

no issues ...they look correct.

And I'll try to look at the pending new soc pinctrl today.


Heiko