From: "Niedermayr, BENEDIKT" <benedikt.niedermayr@siemens.com>
To: "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Cc: "Kiszka, Jan" <jan.kiszka@siemens.com>
Subject: Question regarding runtime pinctrl (2nd try)
Date: Wed, 30 Nov 2022 15:09:50 +0000 [thread overview]
Message-ID: <7abfb823b92a4451d442b001ea7e49017ff3a3c8.camel@siemens.com> (raw)
Hello,
I got no response since last time so I try it again, but with a bit more knowledge this time.
After carefully reading the pinctrl documentation (driver-api/pin-control.rst) it was very clear for me that such an interface already exists and is
accessable via debugfs. The documentation is very clear and self-explanatory. Thanks for that!
At the time of writing my last email [1] I took a look into an older BSP kernel where this feature has not been implemented, yet. I must apologize for
that...
Now my last concern is using debugfs on a productive system. IMHO debugfs is not the right interface to interact
on a productive system. Especially when when a unprivileged process wants to interact with an interface offered by debugfs. It's possible to change
permissions on files and folders there but nevertheless I think that this is not the way to go, since debugfs was designed to offer interfaces to privileged
processes only.
My proposal would be to implement an chardev interface for that and using udev rules to assign correct permissions to that. With this interface I can then
select the active pinctrl-groups which have been defined in the device tree before.
I could also imagine to put the interface into the sysfs (that would be very close to the debugfs implementation I think).
What do you think about it? Am I still missing something?
[1] https://marc.info/?l=linux-gpio&m=166850640920120
cheers,
Benedikt
next reply other threads:[~2022-11-30 15:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 15:09 Niedermayr, BENEDIKT [this message]
2022-11-30 15:43 ` Question regarding runtime pinctrl (2nd try) Andy Shevchenko
2022-12-05 10:47 ` Niedermayr, BENEDIKT
2022-12-05 12:58 ` andriy.shevchenko
2022-12-07 12:02 ` Niedermayr, BENEDIKT
2022-12-07 20:38 ` andriy.shevchenko
2022-12-09 12:47 ` Niedermayr, BENEDIKT
2022-12-09 14:39 ` andriy.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=7abfb823b92a4451d442b001ea7e49017ff3a3c8.camel@siemens.com \
--to=benedikt.niedermayr@siemens.com \
--cc=jan.kiszka@siemens.com \
--cc=linux-gpio@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).