00:09 <zmatt> probably most importantly, can I configure the gpio from DT like I can with gpio-of-helper, or does gpiod still unavoidably give userspace the ability to fry hardware by reconfiguring an input to an output?

00:29 <rcn-ee> gpio sys keeps on getting neutered on mainline.. this gives us the dynamic pinmux changes.. io, usart, etc without touching devmem... I feel sys dev gpio is a lost cause based on libgpiod ripping out

00:38 <set_> Did the kernel make for no happy medium to use both at different spots?

00:38 <rcn-ee> Yeap this would fix the gpio-of-helper

00:39 <set_> For a while, I was able to use both from specific kernels.

00:39 <rcn-ee> (functionally the same as gpio-aggregrator)

00:39 <set_> Anyway, off for now.

00:40 <rcn-ee> Fixed = mainline vs broken patches

00:44 <set_> Like, echo 1 > /sys/class/gpio/gpio60/value && gpioset GPIO23=1

00:44 <set_> Anyway, I am not interrupting so much now. Off and away.

00:45 <set_> sorry.

00:46 <rcn-ee> @set_: this change doesn't affect that.. is about how the actual pinmux is represented in the device tree... So we can set at boot up or dynamicly after bootup

00:47 <rcn-ee> uio needs the pinmux setup by something, either the old bone-gpio-helpher or this gpio-aggregrator

00:51 <set_> okay. No issue.

00:54 <set_> I thought this was about ease of use. using either/or/and could work. How? No clue. I am still trying to figure out v0.4 and how to decipher it. Zoinks.

00:56 <set_> Either way, for people like me, "learners at heart," following is key. It is not necessary for me to understand moves of your central unit but to be able to adapt in the DTS is key for me. Just an idea.

02:11 <zmatt> rcn-ee: I'm confused, what does dynamic pinmux have to do with gpio?

02:11 <zmatt> rcn-ee: are you conflating gpio-of-helper and bone-pinmux-helper? they really have nothing to do with each other

02:16 <zmatt> like, I don't know why 0002-bone-pinmux-helper.patch is in patches/drivers/ti/gpio ... it doesn't interact with the gpio subsystem in any way. the only occurrence of the word "gpio" in that patch is the (erroneous / redundant) #include <linux/of_gpio.h>

02:22 <zmatt> and conversely, neither gpio-of-helper nor gpio-aggregator provides any functionality related to pinmux setup. the only pinmux/pinctrl stuff in the gpio-of-helper driver is actually garbage that should be removed: it explicitly selects the default pinmux state (which is redundant, it's the default) and it gives a warning if missing (which is bogus, there can be valid reasons to not have a pinmux ...

02:22 <zmatt> ...node)