From: "Heiko Stübner" <heiko@sntech.de>
To: Simon Glass <sjg@chromium.org>, Linus Walleij <linusw@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-gpio@vger.kernel.org,
Vladislav Leonov <vlad@zlab.su>, Jonas Karlman <jonas@kwiboo.se>,
Fabio Estevam <festevam@nabladev.com>,
Jeffy Chen <jeffy.chen@rock-chips.com>,
huang lin <hl@rock-chips.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] pinctrl: rockchip: Two fixes for latent driver bugs
Date: Fri, 07 Aug 2026 09:43:30 +0200 [thread overview]
Message-ID: <5262877.taCxCBeP46@diego> (raw)
In-Reply-To: <CAD++jLn8nZT9a0Qe+wtk+2zJ5tPvHjAq4PDPt18ANWiyJPdXpw@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Simon Glass <sjg@chromium.org>, Linus Walleij <linusw@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-gpio@vger.kernel.org,
Vladislav Leonov <vlad@zlab.su>, Jonas Karlman <jonas@kwiboo.se>,
Fabio Estevam <festevam@nabladev.com>,
Jeffy Chen <jeffy.chen@rock-chips.com>,
huang lin <hl@rock-chips.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] pinctrl: rockchip: Two fixes for latent driver bugs
Date: Fri, 07 Aug 2026 09:43:30 +0200 [thread overview]
Message-ID: <5262877.taCxCBeP46@diego> (raw)
In-Reply-To: <CAD++jLn8nZT9a0Qe+wtk+2zJ5tPvHjAq4PDPt18ANWiyJPdXpw@mail.gmail.com>
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
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-08-07 7:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 14:10 [PATCH 0/2] pinctrl: rockchip: Two fixes for latent driver bugs Simon Glass
2026-08-03 14:10 ` Simon Glass
2026-08-03 14:10 ` [PATCH 1/2] pinctrl: rockchip: Reset the pin count when recalculating SoC data Simon Glass
2026-08-03 14:10 ` Simon Glass
2026-08-03 14:10 ` [PATCH 2/2] pinctrl: rockchip: Restrict the RV1103B 2-bit drive type to bank 2 Simon Glass
2026-08-03 14:10 ` Simon Glass
2026-08-06 22:12 ` [PATCH 0/2] pinctrl: rockchip: Two fixes for latent driver bugs Linus Walleij
2026-08-06 22:12 ` Linus Walleij
2026-08-07 7:43 ` Heiko Stübner [this message]
2026-08-07 7:43 ` Heiko Stübner
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=5262877.taCxCBeP46@diego \
--to=heiko@sntech.de \
--cc=festevam@nabladev.com \
--cc=hl@rock-chips.com \
--cc=jeffy.chen@rock-chips.com \
--cc=jonas@kwiboo.se \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=sjg@chromium.org \
--cc=vlad@zlab.su \
/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.