From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH] of: Add .of suffix to device names from devicetree
Date: Thu, 15 Nov 2018 10:33:06 +0100 [thread overview]
Message-ID: <20181115093306.344snwqocwfhhgsr@pengutronix.de> (raw)
In-Reply-To: <CAHQ1cqFY+9+atQh+ZHHgQL_eRV+gFebAp=X6=TZwrtJsztpx=g@mail.gmail.com>
On Wed, Nov 14, 2018 at 07:59:25AM -0800, Andrey Smirnov wrote:
> On Wed, Nov 14, 2018 at 12:52 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >
> > Previous implementation used to add a number to the device names
> > for devices registered from the device tree which did not have a 'reg'
> > property, thus a device node named "state" resulted in a device name
> > "state.<x>". Current implementation skips that number and we get a
> > device named "state". This conflicts with our barebox state
> > implementation which tries to register a device named "state" itself.
> > We could rename the state device nodes of all our device trees, but it
> > causes less trouble to rename the devices.
> >
>
> State implementation will register a device named the same as alias
> pointing to corresponding node, so the problem only arises if DT has
> both a state node named "foo" and an alias to it named "foo" as well.
> It seems that the whole alias/standalone device creation code in
> common/state/state.c was written precisely because original DT naming
> scheme was not producing "fixed/stable" names, so changing then naming
> scheme from matching what Linux does in order to fit some assumptions
> in state code and unfortunate DT naming, while the easiest solution,
> seems a bit backwards.
>
> Can we fix this using an early internal DT fixup that would rename
> problematic node and maybe even print a warning urging users to rename
> their state nodes?
We have boards that have multiple state instances registered with
different names, but all follow the same pattern and have the same
problem, so it's not only "state" that causes problems, but could be
any string. Lucas noted there were problems with imx-thermal aswell.
We have the general problem that devices that have variables attached
to them shall have a specific name, so we must make sure these are
not used by devices registered from the device tree.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2018-11-15 9:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-14 8:52 Sascha Hauer
2018-11-14 12:48 ` Jan Lübbe
2018-11-14 15:59 ` Andrey Smirnov
2018-11-15 9:33 ` Sascha Hauer [this message]
2018-12-31 11:12 ` Ladislav Michl
2019-01-04 8:12 ` Sascha Hauer
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=20181115093306.344snwqocwfhhgsr@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=andrew.smirnov@gmail.com \
--cc=barebox@lists.infradead.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