You should take a look at pinctrl. It's not available as a 'package', which means you'll need to clone the repo using git, and build it from sources (see the Build Instructions in the README). It's not difficult at all:
$ cd
$ git clone https://github.com/raspberrypi/utils.git
#
# this creates a copy of the entire "utils" repo in a `utils` folder in your home dir
# Afterwards, install the tools required to build `pinctrl` iaw the README:
#
$ sudo apt update
...
$ sudo apt install cmake device-tree-compiler libfdt-dev
...
$ cd utils/pinctrl
$ cmake .
$ make
$ sudo make install
...
#
# You're ready!
#
$ cd
$ pinctrl help
#
# Read the help; there is no man page.
pinctrl provides straightforward support for setting pullup resistors via the pu option; e.g.:
pinctrl -e set 10 pu #Enable GPIO10 ~50k in-pad pull up, echoing the result
pinctrl was developed by the Raspberry Pi team; perhaps in response to the failure of libgpiod & associated "tools" to gain any traction or user acceptance. pinctrl supports the RPi 5, and is a genuinely decent solution in these "unsettled" times of transition (LOL).
You should also be aware of the warning that's displayed when you run pinctrl help (no man page):
WARNING! pinctrl set writes directly to the GPIO control registers ignoring whatever else may be using them (such as Linux drivers) - it is designed as a debug tool, only use it if you know what you are doing and at your own risk!
This is fair warning, but note that "writing directly to GPIO registers" is not, in and of itself, a bad thing... ultimately, that's got to happen to make anything work! Similarly, it's prudent to recognize the possibility of poorly written (or documented) kernel code.
Responses to criticisms in the Comments & elsewhere:
Some will criticize the suggestion to use pinctrl (see the comments below & this answer). Fair enough - everyone here is entitled to their opinion. But before making a decision you should weigh up some facts:
- Is there a risk of bias in the recommendation for
pinctrl?
I am not the author of pinctrl, and have no "pride of authorship" in it. I've received no (zero) remuneration for my recommendation. I have no vested interest in pinctrl. My recommendation and my opinion is based solely on my experience with pinctrl, and my experience with, and reading e.g. on "Kent's libgpiod tools". These are the things that have shaped my opinion: there are no better alternatives to pinctrl available in the "kernel code space".
- Is there any evidence to support disparaging claims of
"no protection against contention that can result in unanticipated hardware configurations"?
In a search of RPi SE, and the RPi forums, I could not find a single instance of any such claims.
- What alternatives to
pinctrl are available in the "kernel code space"... are they "better" than pinctrl?
I feel that "better" is in the eyes of the beholder. One might consider the quality of the documentation, and whether or not the user interface seems logical to them. As for me, I did try libgpiod, and made an effort to learn more shortly after ver 2 of libgpiod was released.
- WRT the claims regarding the
libgpiod tools being "suitable for a production environment", see the following post from one of the RPi engineers:
"I'll agree that the fact gpioset requires interaction to quit is a little odd, but it does make some sense due to the normal operation of libgpio being to restore the state of the gpio. These are really only test tools though and should never be used for production code (same as was documented for sysfs gpio usage). Scripting with them makes no sense as there is no guarantee over the state of the GPIO after the app quits."
