Regarding export of GPIOs

Regarding export of GPIOs

[Riz]

Hello,
I have some basic questions around the exporting of a GPIO.

1. Regarding gpio-hog mechanism:
The gpio-hog mechanism would help us to initialise a GPIO to either
high/low & in/out during bootup.
This is fine.

So my question is, if we hog a GPIO, does it also gets exported to the
userspace by default?


2. With the older sysfs interface, we would be using "echo x >
/sys/class/gpio/export" to export the gpiox to userspace.

I wanted to know what would be the right way to do this with the newer
interface?

3. To check if a GPIO is being exported or not, we would see the
/sys/class/gpio with the sysfs interface.

With the newer character device interface, what would be the right way
to check what GPIOs are exported to userspace?

Looking forward to hearing from you

Regards,
Rizwan

Re: Regarding export of GPIOs

[Andy Shevchenko]

On Fri, Aug 20, 2021 at 6:27 AM Riz <mdrizwan827@gmail.com> wrote:
>
> Hello,
> I have some basic questions around the exporting of a GPIO.
>
> 1. Regarding gpio-hog mechanism:
> The gpio-hog mechanism would help us to initialise a GPIO to either
> high/low & in/out during bootup.
> This is fine.
>
> So my question is, if we hog a GPIO, does it also gets exported to the
> userspace by default?
>
>
> 2. With the older sysfs interface, we would be using "echo x >
> /sys/class/gpio/export" to export the gpiox to userspace.
>
> I wanted to know what would be the right way to do this with the newer
> interface?
>
> 3. To check if a GPIO is being exported or not, we would see the
> /sys/class/gpio with the sysfs interface.
>
> With the newer character device interface, what would be the right way
> to check what GPIOs are exported to userspace?
>
> Looking forward to hearing from you

https://stackoverflow.com/questions/68856801/regarding-gpio-export ?

I think I pretty much answered there.


-- 
With Best Regards,
Andy Shevchenko

Re: Regarding export of GPIOs

[Kent Gibson]

On Fri, Aug 20, 2021 at 05:04:03PM +0300, Andy Shevchenko wrote:
> On Fri, Aug 20, 2021 at 6:27 AM Riz <mdrizwan827@gmail.com> wrote:
> >
> > Hello,
> > I have some basic questions around the exporting of a GPIO.
> >
> > 1. Regarding gpio-hog mechanism:
> > The gpio-hog mechanism would help us to initialise a GPIO to either
> > high/low & in/out during bootup.
> > This is fine.
> >
> > So my question is, if we hog a GPIO, does it also gets exported to the
> > userspace by default?
> >
> >
> > 2. With the older sysfs interface, we would be using "echo x >
> > /sys/class/gpio/export" to export the gpiox to userspace.
> >
> > I wanted to know what would be the right way to do this with the newer
> > interface?
> >
> > 3. To check if a GPIO is being exported or not, we would see the
> > /sys/class/gpio with the sysfs interface.
> >
> > With the newer character device interface, what would be the right way
> > to check what GPIOs are exported to userspace?
> >
> > Looking forward to hearing from you
> 
> https://stackoverflow.com/questions/68856801/regarding-gpio-export ?
> 
> I think I pretty much answered there.
> 

Continuing that thread and in response to your  comment:

> I agree with you. Even I looked into the kernel code, it sets the right
> direction of the hogged GPIO. I suspect this could be some issue with
> gpioinfo tool. I hog a GPIO as below
>
> pX { gpio-hog; gpios = < X 0 >; output-high; };
>
> The gpinfo reveals following info about the GPIO:
>
> line 13: "p.X" "some_name" input active-high [used]
>
> It shows it as [used] but the direction still says input
> 

I doubt that gpioinfo is the problem - it merely reports the flags
returned by the kernel and is known to correctly decode the flags for
lines requested using the GPIO API.
You could confirm that by comparing the output of lsgpio or the
libgpiod equivalent tools in my Go library[1].
You could also use strace to decode the GPIO ioctls with:

strace --trace=ioctl gpioinfo

That requires strace 5.11 or later.

If any of those demonstrate that the output flag is not being set then
the problem would appear to lie on the kernel side.

Cheers,
Kent.

[1] https://github.com/warthog618/gpiod

Re: Regarding export of GPIOs

[Riz]

Hi Kent,
Thank you for your response.

I am observing a strange thing here.

The kernel logs for the hogged GPIO reports as:
[    0.251788] GPIO line <num> (name) hogged as output/high

The corresponding dts changes are:
>
> pNum {
> gpio-hog;
> gpios = <num GPIO_ACTIVE_LOW>;
> output-low;
> line-name = "name";
> };


Based on the kernel log, I could say that it is hogging the GPIO as expected.

But using the gpioinfo and lsgpio tools always show the direction as
"input" for the hogged GPIO.
gpioinfo <chipname>:
line  X:      "pX" "name"   input   active-low [used]

lsgpio -n <chipname>:
line X: "pX" "name" [kernel active-low]

I tried following the kernel by adding some logs, it seems to set the
correct direction.
I have really ran out of options here, any leads would be helpful.

Thanks

Re: Regarding export of GPIOs

[Riz]

Sorry the kernel log was:
[    0.251788] GPIO line <num> (name) hogged as output/low

Regards.

On Tue, Aug 31, 2021 at 8:35 PM Riz <mdrizwan827@gmail.com> wrote:
>
> Hi Kent,
> Thank you for your response.
>
> I am observing a strange thing here.
>
> The kernel logs for the hogged GPIO reports as:
> [    0.251788] GPIO line <num> (name) hogged as output/high
>
> The corresponding dts changes are:
> >
> > pNum {
> > gpio-hog;
> > gpios = <num GPIO_ACTIVE_LOW>;
> > output-low;
> > line-name = "name";
> > };
>
>
> Based on the kernel log, I could say that it is hogging the GPIO as expected.
>
> But using the gpioinfo and lsgpio tools always show the direction as
> "input" for the hogged GPIO.
> gpioinfo <chipname>:
> line  X:      "pX" "name"   input   active-low [used]
>
> lsgpio -n <chipname>:
> line X: "pX" "name" [kernel active-low]
>
> I tried following the kernel by adding some logs, it seems to set the
> correct direction.
> I have really ran out of options here, any leads would be helpful.
>
> Thanks

Re: Regarding export of GPIOs

[Kent Gibson]

On Tue, Aug 31, 2021 at 08:38:01PM +0530, Riz wrote:
> Sorry the kernel log was:
> [    0.251788] GPIO line <num> (name) hogged as output/low
> 

It is a bit of a worry that you are editing logs, rather than just
copying them verbatim.  That is just another source of error and
confusion.
The only info you would be leaking here are the num and name, and neither
are significant.
If you are still concerned you can always make the name in your dts
something anonymous but still more meaningful than "name".
Call it "foobar" or something.

> Regards.
> 
> On Tue, Aug 31, 2021 at 8:35 PM Riz <mdrizwan827@gmail.com> wrote:
> >
> > Hi Kent,
> > Thank you for your response.
> >
> > I am observing a strange thing here.
> >
> > The kernel logs for the hogged GPIO reports as:
> > [    0.251788] GPIO line <num> (name) hogged as output/high
> >
> > The corresponding dts changes are:
> > >
> > > pNum {
> > > gpio-hog;
> > > gpios = <num GPIO_ACTIVE_LOW>;
> > > output-low;
> > > line-name = "name";
> > > };
> >

Just to re-iterate Andy's response - if you intend to make active use of
the line then hogging is not the way to go - it is for statically
setting lines for which no driver exists.

And setting GPIO_ACTIVE_LOW makes no sense in this context.  That inverts
the polarity when mapping between logical and physical values, but for
hogs you are not actively using the line so the logical value is not
relevant.
The output-low sets the physical level to low, and an output-high would
set it high.  No logical value involved.

The remainder of the response assumes you just want to determine why the
kernel is not reporting what you expect on a hogged line.

> >
> > Based on the kernel log, I could say that it is hogging the GPIO as expected.
> >
> > But using the gpioinfo and lsgpio tools always show the direction as
> > "input" for the hogged GPIO.
> > gpioinfo <chipname>:
> > line  X:      "pX" "name"   input   active-low [used]
> >
> > lsgpio -n <chipname>:
> > line X: "pX" "name" [kernel active-low]
> >

So lsgpio agrees with gpioinfo in that FLAG_IS_OUT is not set, and the
problem you are seeing is almost certainly on the kernel side.

> > I tried following the kernel by adding some logs, it seems to set the
> > correct direction.

To absolutely confirm that you could add debugging to the kernel to
report the desc->flags after the line is hogged, so in gpiod_hog(), and
where the info is read in gpiolib-cdev lineinfo_get() or
lineinfo_get_v1(), as appropriate.

If those differ then I would add debugging to all the places the
FLAG_IS_OUT is cleared to see if they are somehow being called and
clearing the flag after it is set by gpiod_hog().

If that doesn't turn up anything then the last resort is using a debugger
to put a hardware breakpoint on the desc->flags to identify how it is
being changed.

Cheers,
Kent.