From: "Szőke Benjamin" <egyszeregy@freemail.hu>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: linus.walleij@linaro.org, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gpiolib: Introduce "linux,gpiochip-name" property for device tree of GPIO controller.
Date: Mon, 20 May 2024 16:41:00 +0000 (GMT) [thread overview]
Message-ID: <3c0f28a0-9d07-4e15-ad8e-ad22f25ff979@freemail.hu> (raw)
In-Reply-To: <CAMRc=MctEsMiRgaV5UTiaxjoFDa2izX9wnLAU07=G8gBEcSKoQ@mail.gmail.com>
2024. 05. 19. 19:27 keltezéssel, Bartosz Golaszewski írta:
> On Sun, May 19, 2024 at 4:49 PM <egyszeregy@freemail.hu> wrote:
>>
>> From: Benjamin Szőke <egyszeregy@freemail.hu>
>>
>> Optionally, a GPIO controller may have a "linux,gpiochip-name" property.
>
> Oh, may it really?
>
> $ git grep "linux,gpiochip-name" Documentation/devicetree/bindings/
> $
>
> Doesn't look like it.
>
>> This is a string which is defining a custom suffix name for gpiochip in
>> /dev/gpiochip-<name> format. It helps to improve software portability
>> between various SoCs and reduce complexities of hardware related codes
>> in SWs.
>>
>> Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>
>> ---
>> drivers/gpio/gpiolib.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>> index ce94e37bcbee..e24d8db1d054 100644
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -860,6 +860,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
>> struct lock_class_key *lock_key,
>> struct lock_class_key *request_key)
>> {
>> + const char *name;
>> struct gpio_device *gdev;
>> unsigned int desc_index;
>> int base = 0;
>> @@ -896,7 +897,16 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
>> goto err_free_gdev;
>> }
>>
>> - ret = dev_set_name(&gdev->dev, GPIOCHIP_NAME "%d", gdev->id);
>> + /*
>> + * If "linux,gpiochip-name" is specified in device tree, use /dev/gpiochip-<name>
>> + * in Linux userspace, otherwise use /dev/gpiochip<id>.
>> + */
>> + ret = device_property_read_string(gc->parent, "linux,gpiochip-name", &name);
>> + if (ret < 0)
>> + ret = dev_set_name(&gdev->dev, GPIOCHIP_NAME "%d", gdev->id);
>> + else
>> + ret = dev_set_name(&gdev->dev, GPIOCHIP_NAME "-%s", name);
>> +
>> if (ret)
>> goto err_free_ida;
>>
>> --
>> 2.39.3
>>
>
> NAK, this is udev's task in user-space if you need this.
>
> Bart
Hi,
Goal of this patch is to introduce this new mode to assign a custom name from
lowlevel device tree to a gpio bank.
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 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 and in SW point of view it is flexible.
So, in Yocto project point of view the best, if any Machine specific settings is
stored in the device tree files of the target MACHNIEs 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 for building image.
So this way to assign a custom name for a gpiobanks from device tree is more
efficient and more maintainable in SW developing point of view in
Yocto/buildroot world because i need to just define a name like
linux,gpiochip-name = "expander"; then use it with a fixed name in my generic SW
under /dev/gpiochip-expander name. And there are no need to care about what will
be the index number of this banks randomly after boot and how need to make an
ugly append layer for udev and make it for all of machine variants which are the
target to use with the same SW.
My opinion udev is ugly to use for it and more complicated, and no longer
beneficial for new Adaptive SoCs where they can be not deterministic what kind
of index number they got in driver probing (you will not know what index need to
mapping for what custom name). It is much better to assign this suffix/name
explicitly from device tree.
next prev parent reply other threads:[~2024-05-20 16:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-19 14:49 [PATCH] gpiolib: Introduce "linux,gpiochip-name" property for device tree of GPIO controller egyszeregy
2024-05-19 17:27 ` Bartosz Golaszewski
2024-05-20 16:41 ` Szőke Benjamin [this message]
2024-05-21 11:36 ` Bartosz Golaszewski
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=3c0f28a0-9d07-4e15-ad8e-ad22f25ff979@freemail.hu \
--to=egyszeregy@freemail.hu \
--cc=brgl@bgdev.pl \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@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).