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@xxxxxxxxx> 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.