From: Nam Cao <namcao@linutronix.de>
To: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Cc: Emil Renner Berthing <kernel@esmil.dk>,
Jianlong Huang <jianlong.huang@starfivetech.com>,
Hal Feng <hal.feng@starfivetech.com>,
Linus Walleij <linus.walleij@linaro.org>,
Huan Feng <huan.feng@starfivetech.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Drew Fustini <drew@beagleboard.org>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 2/2] pinctrl: starfive: jh7100: ignore disabled device tree nodes
Date: Mon, 4 Dec 2023 09:05:43 +0100 [thread overview]
Message-ID: <20231204080543.C8LyBqTM@linutronix.de> (raw)
In-Reply-To: <CAJM55Z9CooaYqeTuZK0FARKupf_StTSfWBo7ziv4KtGq6pEVaQ@mail.gmail.com>
Hi Emil,
On Fri, Dec 01, 2023 at 03:28:27PM +0100, Emil Renner Berthing wrote:
> Nam Cao wrote:
> > diff --git a/drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c b/drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c
> > index 530fe340a9a1..561fd0c6b9b0 100644
> > --- a/drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c
> > +++ b/drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c
> > @@ -492,7 +492,7 @@ static int starfive_dt_node_to_map(struct pinctrl_dev *pctldev,
> >
> > nmaps = 0;
> > ngroups = 0;
> > - for_each_child_of_node(np, child) {
> > + for_each_available_child_of_node(np, child) {
>
> Is this safe to do? I mean will the children considered "available" not change
> as drivers are loaded during boot so this is racy?
I think if node removal like this causes race condition, we would
already have race condition with node addition too: "what if the nodes
are added while the drivers are being loaded?"
At least with U-Boot, the device tree overlay is "merged" into the base
device tree, before the kernel even runs, so no race there. I don't know
if there are any cases where the device tree overlay is not guaranteed
to be applied before driver loading, but those cases do not sound sane
to me: they would cause race condition, regardless of whether nodes are
added or removed.
> Also arguably this is not a bugfix, but a new feature.
I'm not sure myself, I haven't seen official documentation/rules about
this. But many people do consider this to be a bug:
"Though you can add/override 'status' with 'status = "disabled";' which
should be treated very similar to a node not being present. I say
similar because it's a source of bugs for the OS to fail to pay
attention to status property." - Rob Herring [1].
"Linux has widespread use of the "status" property to indicate that a
node does not exist. (...). Expect efforts to fix the kernel code to
respect the "status" property." - elinux.org [2].
And I do agree with them. When someone write a device tree with some
nodes with "status = disabled" for whatever reasons, clearly they intend
to exclude these nodes.
Though I must admit that I am still quite new, so please correct me if
my reasoning/understanding is flawed.
Best regards,
Nam
[1] https://lore.kernel.org/lkml/CAL_JsqLV5d5cL3o3Dx=--zGD37c5O09rL9AXyRFmceTfBHt3Zg@mail.gmail.com/
[2] https://elinux.org/Device_Tree_Linux#status_property
next prev parent reply other threads:[~2023-12-04 8:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 9:23 [PATCH 1/2] pinctrl: starfive: jh7110: ignore disabled device tree nodes Nam Cao
2023-12-01 9:23 ` [PATCH 2/2] pinctrl: starfive: jh7100: " Nam Cao
2023-12-01 14:28 ` Emil Renner Berthing
2023-12-01 14:43 ` Emil Renner Berthing
2023-12-04 8:08 ` Nam Cao
2023-12-04 8:05 ` Nam Cao [this message]
2023-12-04 10:14 ` Linus Walleij
2023-12-04 10:11 ` [PATCH 1/2] pinctrl: starfive: jh7110: " Linus Walleij
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=20231204080543.C8LyBqTM@linutronix.de \
--to=namcao@linutronix.de \
--cc=andy.shevchenko@gmail.com \
--cc=drew@beagleboard.org \
--cc=emil.renner.berthing@canonical.com \
--cc=hal.feng@starfivetech.com \
--cc=huan.feng@starfivetech.com \
--cc=jianlong.huang@starfivetech.com \
--cc=kernel@esmil.dk \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).