public inbox for linux-gpio@vger.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Jon Hunter <jonathanh@nvidia.com>,
	Prathamesh Shete <pshete@nvidia.com>,
	linux-gpio@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH 1/2] pinctrl: tegra: Duplicate pinmux functions table
Date: Thu, 1 Jun 2023 14:27:35 +0200	[thread overview]
Message-ID: <ZHiOt7Jsp_PP7Se4@orome> (raw)
In-Reply-To: <CACRpkdaN2r24QrL5t-_SsUQ-9o=BhZx0eFgpbsA+QiFTicPnKg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

On Thu, Jun 01, 2023 at 01:19:45PM +0200, Linus Walleij wrote:
> On Tue, May 30, 2023 at 12:53 PM Thierry Reding
> <thierry.reding@gmail.com> wrote:
> 
> > From: Thierry Reding <treding@nvidia.com>
> >
> > The function table is filled with group information based on other
> > instance-specific data at runtime. However, the function table can be
> > shared between multiple instances, causing the ->probe() function for
> > one instance to overwrite the table of a previously probed instance.
> >
> > Fix this by sharing only the function names and allocating a separate
> > function table for each instance.
> >
> > Fixes: 5a0047360743 ("pinctrl: tegra: Separate Tegra194 instances")
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> 
> Both patches applied!
> 
> I can't figure out if the problem is urgent or just wasting memory, so
> I applied it as non-urgent fix for now, tell me if this needs to go
> upstream pronto.

I think you might be able to write a device tree that triggers this, but
so far I've only seen it cause an WARN splat when accessing the debugfs
attribute that reads out the pinmux functions. I think Prathamesh had
mentioned it could also hang the system when you access debugfs.

Overall I don't think this is very urgent. We only observed this as part
of testing the Tegra234 patches that are under review, so it's probably
uncommon for people to run the problematic code paths.

No matter what you decide, the Fixes: tag should make sure it goes into
stable releases which is probably good enough.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2023-06-01 12:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30 10:53 [PATCH 1/2] pinctrl: tegra: Duplicate pinmux functions table Thierry Reding
2023-05-30 10:53 ` [PATCH 2/2] pinctrl: tegra: Consistently refer to SoC data Thierry Reding
2023-06-01 11:19 ` [PATCH 1/2] pinctrl: tegra: Duplicate pinmux functions table Linus Walleij
2023-06-01 12:27   ` Thierry Reding [this message]

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=ZHiOt7Jsp_PP7Se4@orome \
    --to=thierry.reding@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=pshete@nvidia.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox