Hi. W dniu 21.01.2023 o 16:33, Lukas Zeller pisze: > Hi Sergio, thanks for the reply! > > On 21 Jan 2023, at 14:00, Sergio Paracuellos <[email protected]> > wrote: > >> On Sat, Jan 21, 2023 at 1:19 PM Lukas Zeller <[email protected]> wrote: >>> [...]So while I understand that using only the DT mechanisms for >>> configuring GPIO modes, named gpios and libgpiod instead of /sys/class/gpio >>> etc. is the way to go, I must also state that without loadable DT overlays, >>> this essentially makes openwrt unsuitable for experimental/educational >>> devices. >> >> Configure the GPIO modes is not something that is expected to be done >> by a user since all of that belongs to the pinctrl driver space and >> AFAIK linux kernel people are not thinking in doing pinctrl driver >> user-space tools. > > Apparently, yes. > > I also fully understand this from a system designer's point of view. > > What pin is connected to what external hardware, is something that is, in a > given system, on a given PCB, pretty immutable and thus DT is the correct and > only place to also define it in a way that is immutable between flashing > firmwares. > >> The libgpiod is useful to detect and set to on and >> off different pins (among other pure GPIO operations) but from the >> already function GPIO set up in them. > > This draws a pretty arbitrary boundary for what a educational/experimental > use consists of. Toggling predefined GPIOs on and off, yes, using the same > pin for PWM (say, GPIO18 on MT76x8), no? rotary-encoder? W1? GPIO-based SPI, > I2C? > >> I am not doing the rules, > > :-) > >> I am just saying the things that are now in the kernel and user space as I >> think they are. As I have already said, I am not an expert in this >> topic at all but maybe if we want to do such complex things like >> configuring the mode of a pin from user space some kind of user space >> drivers need to be provided in some way... So, if openWRT is using >> linux kernel, at the end they have to also live with kernel people's >> decisions in some way... > > In some way. > > But OpenWrt does patch the kernel to adjust things that Linux mainline does > not provide. > > So it *is* an OpenWrt question whether to support HW tinkering and to what > degree. > > Having that loadable DT overlay patch (which works on 5.10, I'm using it) as > a menuconfig option disabled by default would have two benefits: > > - going with the linux kernel way, to have these HW config things in the DT, > and only there. > > - one single, completely HW independent switch, off by default, to allow HW > experiments or not (compiling in the dynamically loadable DT overlays code). > > Builds for targets that *want* to be open for educational/experimental HW > tinkering, with the set of risks that comes with that, can set this switch. > All normal router targets will not set set it, and thus are not affected. > > I think this would be better and easier to maintain, than reverting back to > driver-level hacks like we had in 19.x with *_gpio_custom and friends. > > So basically, I'm suggesting to revisit the decision to reject the patch from > Daniel Golle [1].
Instead of doing it the hard way of patching, why not using out-of-tree kernel module[2] for loading dtb overlay with configfs? It already exists for some time. Unfortunately I didn't test it, as the board I wanted to use it has gone in flames. For ready to use recipe see the attachment. Feel free to submit it to packages feed and take over maintainership after giving it a test. > [1] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037139.html 2. https://github.com/ikwzm/dtbocfg -- TMN
# SPDX-License-Identifier: GPL-2.0-only # # Copyright (c) 2022 Tomasz Maciej Nowak <[email protected]> include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME := dtbocfg PKG_VERSION := 0.0.9 PKG_RELEASE := 1 PKG_LICENSE := BSD-2-Clause PKG_LICENSE_FILES := LICENSE PKG_SOURCE_PROTO := git PKG_SOURCE_URL := https://github.com/ikwzm/dtbocfg.git PKG_SOURCE_VERSION := 2d5593ba4fea35b75fce716a5d9538f984493cbd PKG_MIRROR_HASH := 7cbb8aa089dc3d261ea5461297a970aa3d4cb667b9459850969eec233f409898 PKG_MAINTAINER := Tomasz Maciej Nowak <[email protected]> PKG_BUILD_PARALLEL := 1 PKG_FLAGS := nonshared include $(INCLUDE_DIR)/package.mk define KernelPackage/fs-dtbocfg SUBMENU := Filesystems TITLE := Device Tree Blob Overlay Configuration File System DEPENDS := +kmod-fs-configfs @!TARGET_bcm27xx FILES := $(PKG_BUILD_DIR)/dtbocfg.ko AUTOLOAD := $(call AutoLoad,31,dtbocfg,) endef define KernelPackage/fs-dtbocfg/description Device Tree Overlay is a mechanism that enables dynamic loading/unloading of a new device tree blob on top of the kernel device tree. endef define Build/Compile $(KERNEL_MAKE) M="$(PKG_BUILD_DIR)" modules endef $(eval $(call KernelPackage,fs-dtbocfg))
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
