pt., 11 sty 2019 o 00:21 Linus Walleij <linus.walleij@xxxxxxxxxx> napisał(a): > > Hi Stefan, > > I'll try to answer as best I can :) > > On Wed, Jan 2, 2019 at 4:59 PM Stefan Wahren <stefan.wahren@xxxxxxxx> wrote: > > > during test of my latest BCM2835 DT patch series [1], i noticed a discrepancy between > > pinctrl debugfs and gpioinfo from libgpio on my Raspberry Pi 3 (linux-next, multi_v7_defconfig): > > > > 1. Pins configured as alternative function (e.g. pin 0 as alt0) are considered by gpioinfo as > > input even the get_direction callback of the pinctrl-bcm2835 returns -EINVAL in this case > > We have no semantics for for "GPIO line is not there" in gpiolib. > > In general, not all GPIOs in the world are even connected to pins, > some are internal or say connected to an FPGA fabric. They are > general purpose input/output but not necessarily associated with > a physical pin. > > Also there are many GPIO drivers without pin control back-ends > and those are generally considered "there" even if the pin itself > is not connected to anything. > > So that is the generic problem space. > > So far, since the inception of the GPIO subsystem, the line has > been considered as existing if it has a register bit and some > electronic driver associated with it. > > If you want to change this, you need to jit GPIO and pin control > closer together. As of today, many unused GPIOs are represented > in debugfs and also in lsgpio and friends. > > > 2. Pins whose mux is claimed by a kernel driver > > (e.g. pin 0 by i2c) are considered by gpioinfo as unused > > Since they are disconnected from the pin they are kind of unused. > > This is a semantic question I guess it is in one sense unintuitive > but you can often set the bit in the register and once the pin is > muxed back to GPIO from whatever it was before, it is driven high, > so it still has a state and in that sense it is there. > > > I think this is very confusing for users. > > Yeah I guess it's like that. Generally I think the biggest problem for > user is that platforms have not named the gpio lines with names so > the user does not know what they are for. But this could be improved > too. > > > Where does this needs to be fixed (pinctrl/gpio driver, gpiolib, libgpiod)? > > All over the place I'm afraid. If it annoys you then start hacking :) > > Yours, > Linus Walleij Hi Stefan, I missed this message before because for some reason libgpiod mails sent to this list went into my spam box. Linus already explained almost everything. I'd like to just point out that libgpiod is relatively simple and only implements features already supported in the kernel uAPI. If the kernel says a line is used, then it interprets it as such. So most of the heavy lifting would need to be done in the kernel. Bart