From: "Szőke Benjamin" <egyszeregy@freemail.hu>
To: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] spidev: Introduce "linux,spidev-name" property for device tree of spidev.
Date: Mon, 20 May 2024 19:20:12 +0200 [thread overview]
Message-ID: <9ae65e3c-f1fa-4ca9-8d74-12d92c51c5c6@freemail.hu> (raw)
In-Reply-To: <1ec9e8e5-0818-42b0-8776-d9cfb0585f42@sirena.org.uk>
2024. 05. 20. 15:20 keltezéssel, Mark Brown írta:
> On Sun, May 19, 2024 at 11:13:46PM +0200, egyszeregy@freemail.hu wrote:
>> From: Benjamin Szőke <egyszeregy@freemail.hu>
>>
>> Optionally, spidev may have a "linux,spidev-name" property.
>> This is a string which is defining a custom suffix name for spi device in
>> /dev/spidev-<name> format. It helps to improve software portability between
>> various SoCs and reduce complexities of hardware related codes in SWs.
>
> This seems like what udev rules are for?
Hi,
Goal of this patch is to introduce this new mode to assign a custom name from
lowlevel device tree to a spidev device. As i know udev can do it, but to do it
from device tree is the best and easier way for this feature in my opinion.
It is more maintainable then use udev in userspace for it.
For example there are three different SoCs: i.MX7, i.MX9, ZynqMP.
In Yocto project, the Linux image's SW environment is nicely configurable
independently from what is the target MACHNIE. But if i like to deploy a SW
which uses peripheries like gpiobanks, i2c-dev, spidev these /dev/... name will
be totally different on each SoCs, more over in ZynqMP and any other Adaptive
SoC platform, the index number for the spidev, gpiobanks or other can be not
deterministic if it probed in run-time. Goal is to easily make a Linux OS image
which can support multiple SoCs in SW point of view easily.
So, in Yocto project build system point of view the best, if any Machine
specific settings is stored in the device tree files of the target machine in
driver levels/config, because it will be deterministic in 100% sure and it will
be nicely separated from the SW meta layers which may not contains any machine
specific hacking with udev and so on.
So this way to assign a custom name for a spidev from device tree is more
efficient and more maintainable in SW developing point of view in embedded Linux
and Yocto/buildroot world because i need to just define a name like
linux,spidev-name = "sensor"; then use it with a fixed name in my generic SW
under /dev/spidev-sensor name. And there are no need to care about what will be
the index number of this spidev randomly after boot and how need to make an ugly
append layer for udev config and make it for all of machine variants separately.
My opinion udev is ugly to use for it, and no longer beneficial for new Adaptive
SoCs where they can be not deterministic what kind of index number they got in
driver probing for many gpio, spidev, i2c-dev peripheries (you do not have info
about that which need to mapping for what custom name, it can be different in
many time based on PL FW). It is much better, safe and easier to assign this
custom suffix/name explicitly from device tree, moreover it is a driver related
things, i think the best place is in device tree for it not in a sys config file
for udev.
DT binding would need to be documented later in a separated patch as a guideline
mentioned it in Linux repo.
next prev parent reply other threads:[~2024-05-20 17:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-19 21:13 [PATCH v2] spidev: Introduce "linux,spidev-name" property for device tree of spidev egyszeregy
2024-05-20 13:20 ` Mark Brown
2024-05-20 17:20 ` Szőke Benjamin [this message]
2024-05-20 20:14 ` Mark Brown
2024-06-02 15:31 ` Szőke Benjamin
2024-06-07 15:55 ` Mark Brown
2024-06-07 16:07 ` Conor Dooley
2024-06-11 10:41 ` Andy Shevchenko
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=9ae65e3c-f1fa-4ca9-8d74-12d92c51c5c6@freemail.hu \
--to=egyszeregy@freemail.hu \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@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 read-only IMAP folder(s) and NNTP newsgroup(s).