[libgpiod] bug: pull-up does not work

[libgpiod] bug: pull-up does not work

[Jiří Prchal]

Hi,
since in debian is 1.6.2 and pull-up doesn't work so I cloned git, 
branch next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, 
same result.

~# uname -r
5.17.0-rc7_cpm9g25

floating pins should go with pull-up/down
~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
0 0 0 0 0 0 0 0
~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
1 1 0 0 0 0 0 0
~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
0 1 0 1 0 0 0 0

~# gpioget -v
gpioget (libgpiod) v2.0-devel

Whats wrong with it?
Thanks
Jiri

Re: [libgpiod] bug: pull-up does not work

[Kent Gibson]

On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote:
> Hi,
> since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch
> next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result.
> 

You mean it doesn't work for you on your platform.

The libgpiod-2.0 branch is a work in progress and should not be considered
the place to go to find solutions to problems with v1.6.
Not that I'm saying that the v2 branch doesn't work, I'm actually pretty
sure it does, but its purpose is to switch to the latest kernel uAPI, not
to provide fixes, should they be needed, for v1.6.

> ~# uname -r
> 5.17.0-rc7_cpm9g25
> 
> floating pins should go with pull-up/down
> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> 0 0 0 0 0 0 0 0
> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> 1 1 0 0 0 0 0 0
> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> 0 1 0 1 0 0 0 0
> 
> ~# gpioget -v
> gpioget (libgpiod) v2.0-devel
> 
> Whats wrong with it?

You forgot to mention which of those pins are floating.
Or what gpiochip3 is and whether it supports biasing.

So does your chip support pull-up/down?
The kernel can only enable it if the hardware and pinctrl driver supports it.
If the hardware doesn't support it then attempting to set the
pull-up/down is quietly ignored, which would be consistent with what you
are seeing.

Cheers,
Kent.

Re: [libgpiod] bug: pull-up does not work

[Jiří Prchal]

On 25. 03. 22 15:57, Kent Gibson wrote:
> On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote:
>> Hi,
>> since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch
>> next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result.
>>
> 
> You mean it doesn't work for you on your platform.
> 
> The libgpiod-2.0 branch is a work in progress and should not be considered
> the place to go to find solutions to problems with v1.6.
> Not that I'm saying that the v2 branch doesn't work, I'm actually pretty
> sure it does, but its purpose is to switch to the latest kernel uAPI, not
> to provide fixes, should they be needed, for v1.6.
Just thought api v1 doesn't support pull-ups so tried v2.
> 
>> ~# uname -r
>> 5.17.0-rc7_cpm9g25
>>
>> floating pins should go with pull-up/down
>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
>> 0 0 0 0 0 0 0 0
>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
>> 1 1 0 0 0 0 0 0
>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
>> 0 1 0 1 0 0 0 0
>>
>> ~# gpioget -v
>> gpioget (libgpiod) v2.0-devel
>>
>> Whats wrong with it?
> 
> You forgot to mention which of those pins are floating.
All of them.
> Or what gpiochip3 is and whether it supports biasing.
AT91SAM9G25, hw supports pull-ups.
> 
> So does your chip support pull-up/down?
> The kernel can only enable it if the hardware and pinctrl driver supports it.
Is there possibility that pinctrl doesn't support it? I think other 
gpios used in kernel are with pull-up.
Example:
pinctrl@fffff400 {
	1wire {
		pinctrl_1wire: 1wire-0 {
			atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* 
PC0 PIO, pull-up */
		};
	};
};

> If the hardware doesn't support it then attempting to set the
> pull-up/down is quietly ignored, which would be consistent with what you
> are seeing.
> 
> Cheers,
> Kent.
> 

Re: [libgpiod] bug: pull-up does not work

[Kent Gibson]

On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote:
> 
> 
> On 25. 03. 22 15:57, Kent Gibson wrote:
> > On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote:
> > > Hi,
> > > since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch
> > > next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result.
> > > 
> > 
> > You mean it doesn't work for you on your platform.
> > 
> > The libgpiod-2.0 branch is a work in progress and should not be considered
> > the place to go to find solutions to problems with v1.6.
> > Not that I'm saying that the v2 branch doesn't work, I'm actually pretty
> > sure it does, but its purpose is to switch to the latest kernel uAPI, not
> > to provide fixes, should they be needed, for v1.6.
> Just thought api v1 doesn't support pull-ups so tried v2.

v1 does support bias since Linux v5.5, and libgpiod added support in v1.5.

> > 
> > > ~# uname -r
> > > 5.17.0-rc7_cpm9g25
> > > 
> > > floating pins should go with pull-up/down
> > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> > > 0 0 0 0 0 0 0 0
> > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> > > 1 1 0 0 0 0 0 0
> > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> > > 0 1 0 1 0 0 0 0
> > > 
> > > ~# gpioget -v
> > > gpioget (libgpiod) v2.0-devel
> > > 
> > > Whats wrong with it?
> > 
> > You forgot to mention which of those pins are floating.
> All of them.
> > Or what gpiochip3 is and whether it supports biasing.
> AT91SAM9G25, hw supports pull-ups.
> > 
> > So does your chip support pull-up/down?
> > The kernel can only enable it if the hardware and pinctrl driver supports it.
> Is there possibility that pinctrl doesn't support it? I think other gpios
> used in kernel are with pull-up.
> Example:
> pinctrl@fffff400 {
> 	1wire {
> 		pinctrl_1wire: 1wire-0 {
> 			atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0
> PIO, pull-up */
> 		};
> 	};
> };
> 

Pinctrl and device tree are outside my area, but my understanding is
that setting via DT is a separate interface, so while it may be
supported by DT it may not be via the gpiolib interface.
But I will defer to anyone else on that.
(CCing in Andy since I'm pretty sure he would know)

Not sure which pinctrl is relevant for your case.
pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib
interface, but pinctrl-at91-pio4 does, so my guess would be you are using
the pinctrl-at91.

But again, this is outside my area so you would need to confirm that
yourself or get feedback from someone else.
If you determine that you are using a pinctrl that supports setting
bias via gpiolib then we'll have to do some more digging.

Cheers,
Kent.

Re: [libgpiod] bug: pull-up does not work

[Jiří Prchal]

On 25. 03. 22 17:01, Kent Gibson wrote:
> On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote:
>>
>>
>> On 25. 03. 22 15:57, Kent Gibson wrote:
>>> On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote:
>>>> Hi,
>>>> since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch
>>>> next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result.
>>>>
>>>
>>> You mean it doesn't work for you on your platform.
>>>
>>> The libgpiod-2.0 branch is a work in progress and should not be considered
>>> the place to go to find solutions to problems with v1.6.
>>> Not that I'm saying that the v2 branch doesn't work, I'm actually pretty
>>> sure it does, but its purpose is to switch to the latest kernel uAPI, not
>>> to provide fixes, should they be needed, for v1.6.
>> Just thought api v1 doesn't support pull-ups so tried v2.
> 
> v1 does support bias since Linux v5.5, and libgpiod added support in v1.5.
> 
>>>
>>>> ~# uname -r
>>>> 5.17.0-rc7_cpm9g25
>>>>
>>>> floating pins should go with pull-up/down
>>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
>>>> 0 0 0 0 0 0 0 0
>>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
>>>> 1 1 0 0 0 0 0 0
>>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
>>>> 0 1 0 1 0 0 0 0
>>>>
>>>> ~# gpioget -v
>>>> gpioget (libgpiod) v2.0-devel
>>>>
>>>> Whats wrong with it?
>>>
>>> You forgot to mention which of those pins are floating.
>> All of them.
>>> Or what gpiochip3 is and whether it supports biasing.
>> AT91SAM9G25, hw supports pull-ups.
>>>
>>> So does your chip support pull-up/down?
>>> The kernel can only enable it if the hardware and pinctrl driver supports it.
>> Is there possibility that pinctrl doesn't support it? I think other gpios
>> used in kernel are with pull-up.
>> Example:
>> pinctrl@fffff400 {
>> 	1wire {
>> 		pinctrl_1wire: 1wire-0 {
>> 			atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0
>> PIO, pull-up */
>> 		};
>> 	};
>> };
>>
> 
> Pinctrl and device tree are outside my area, but my understanding is
> that setting via DT is a separate interface, so while it may be
> supported by DT it may not be via the gpiolib interface.
> But I will defer to anyone else on that.
> (CCing in Andy since I'm pretty sure he would know)
> 
> Not sure which pinctrl is relevant for your case.
> pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib
> interface, but pinctrl-at91-pio4 does, so my guess would be you are using
> the pinctrl-at91.
pinctrl-at91-pio4 didn't help, syminfo says "for Atmel PIO4 controller 
available on sama5d2 SoC" but my is sam9g25.
How can I find out if it supports gpiolib?
> 
> But again, this is outside my area so you would need to confirm that
> yourself or get feedback from someone else.
> If you determine that you are using a pinctrl that supports setting
> bias via gpiolib then we'll have to do some more digging.
> 
> Cheers,
> Kent.
> 
Thanks
Jiri

Re: [libgpiod] bug: pull-up does not work

[Kent Gibson]

On Mon, Mar 28, 2022 at 09:12:16AM +0200, Jiří Prchal wrote:
> 
> 
> On 25. 03. 22 17:01, Kent Gibson wrote:
> > On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote:
> > > 
> > > 
> > > On 25. 03. 22 15:57, Kent Gibson wrote:
> > > > On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote:
> > > > > Hi,
> > > > > since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch
> > > > > next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result.
> > > > > 
> > > > 
> > > > You mean it doesn't work for you on your platform.
> > > > 
> > > > The libgpiod-2.0 branch is a work in progress and should not be considered
> > > > the place to go to find solutions to problems with v1.6.
> > > > Not that I'm saying that the v2 branch doesn't work, I'm actually pretty
> > > > sure it does, but its purpose is to switch to the latest kernel uAPI, not
> > > > to provide fixes, should they be needed, for v1.6.
> > > Just thought api v1 doesn't support pull-ups so tried v2.
> > 
> > v1 does support bias since Linux v5.5, and libgpiod added support in v1.5.
> > 
> > > > 
> > > > > ~# uname -r
> > > > > 5.17.0-rc7_cpm9g25
> > > > > 
> > > > > floating pins should go with pull-up/down
> > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> > > > > 0 0 0 0 0 0 0 0
> > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> > > > > 1 1 0 0 0 0 0 0
> > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> > > > > 0 1 0 1 0 0 0 0
> > > > > 
> > > > > ~# gpioget -v
> > > > > gpioget (libgpiod) v2.0-devel
> > > > > 
> > > > > Whats wrong with it?
> > > > 
> > > > You forgot to mention which of those pins are floating.
> > > All of them.
> > > > Or what gpiochip3 is and whether it supports biasing.
> > > AT91SAM9G25, hw supports pull-ups.
> > > > 
> > > > So does your chip support pull-up/down?
> > > > The kernel can only enable it if the hardware and pinctrl driver supports it.
> > > Is there possibility that pinctrl doesn't support it? I think other gpios
> > > used in kernel are with pull-up.
> > > Example:
> > > pinctrl@fffff400 {
> > > 	1wire {
> > > 		pinctrl_1wire: 1wire-0 {
> > > 			atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0
> > > PIO, pull-up */
> > > 		};
> > > 	};
> > > };
> > > 
> > 
> > Pinctrl and device tree are outside my area, but my understanding is
> > that setting via DT is a separate interface, so while it may be
> > supported by DT it may not be via the gpiolib interface.
> > But I will defer to anyone else on that.
> > (CCing in Andy since I'm pretty sure he would know)
> > 
> > Not sure which pinctrl is relevant for your case.
> > pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib
> > interface, but pinctrl-at91-pio4 does, so my guess would be you are using
> > the pinctrl-at91.
> pinctrl-at91-pio4 didn't help, syminfo says "for Atmel PIO4 controller
> available on sama5d2 SoC" but my is sam9g25.
> How can I find out if it supports gpiolib?
> > 

What does gpiodetect report?
That should given an indication which driver is being used.

Cheers,
Kent.

> > But again, this is outside my area so you would need to confirm that
> > yourself or get feedback from someone else.
> > If you determine that you are using a pinctrl that supports setting
> > bias via gpiolib then we'll have to do some more digging.
> > 
> > Cheers,
> > Kent.
> > 
> Thanks
> Jiri

Re: [libgpiod] bug: pull-up does not work

[Jiří Prchal]

On 28. 03. 22 10:08, Kent Gibson wrote:
> On Mon, Mar 28, 2022 at 09:12:16AM +0200, Jiří Prchal wrote:
>>
>>
>> On 25. 03. 22 17:01, Kent Gibson wrote:
>>> On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote:
>>>>
>>>>
>>>> On 25. 03. 22 15:57, Kent Gibson wrote:
>>>>> On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote:
>>>>>> Hi,
>>>>>> since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch
>>>>>> next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result.
>>>>>>
>>>>>
>>>>> You mean it doesn't work for you on your platform.
>>>>>
>>>>> The libgpiod-2.0 branch is a work in progress and should not be considered
>>>>> the place to go to find solutions to problems with v1.6.
>>>>> Not that I'm saying that the v2 branch doesn't work, I'm actually pretty
>>>>> sure it does, but its purpose is to switch to the latest kernel uAPI, not
>>>>> to provide fixes, should they be needed, for v1.6.
>>>> Just thought api v1 doesn't support pull-ups so tried v2.
>>>
>>> v1 does support bias since Linux v5.5, and libgpiod added support in v1.5.
>>>
>>>>>
>>>>>> ~# uname -r
>>>>>> 5.17.0-rc7_cpm9g25
>>>>>>
>>>>>> floating pins should go with pull-up/down
>>>>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
>>>>>> 1 1 0 0 0 0 0 0
>>>>>> ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
>>>>>> 0 1 0 1 0 0 0 0
>>>>>>
>>>>>> ~# gpioget -v
>>>>>> gpioget (libgpiod) v2.0-devel
>>>>>>
>>>>>> Whats wrong with it?
>>>>>
>>>>> You forgot to mention which of those pins are floating.
>>>> All of them.
>>>>> Or what gpiochip3 is and whether it supports biasing.
>>>> AT91SAM9G25, hw supports pull-ups.
>>>>>
>>>>> So does your chip support pull-up/down?
>>>>> The kernel can only enable it if the hardware and pinctrl driver supports it.
>>>> Is there possibility that pinctrl doesn't support it? I think other gpios
>>>> used in kernel are with pull-up.
>>>> Example:
>>>> pinctrl@fffff400 {
>>>> 	1wire {
>>>> 		pinctrl_1wire: 1wire-0 {
>>>> 			atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0
>>>> PIO, pull-up */
>>>> 		};
>>>> 	};
>>>> };
>>>>
>>>
>>> Pinctrl and device tree are outside my area, but my understanding is
>>> that setting via DT is a separate interface, so while it may be
>>> supported by DT it may not be via the gpiolib interface.
>>> But I will defer to anyone else on that.
>>> (CCing in Andy since I'm pretty sure he would know)
>>>
>>> Not sure which pinctrl is relevant for your case.
>>> pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib
>>> interface, but pinctrl-at91-pio4 does, so my guess would be you are using
>>> the pinctrl-at91.
>> pinctrl-at91-pio4 didn't help, syminfo says "for Atmel PIO4 controller
>> available on sama5d2 SoC" but my is sam9g25.
>> How can I find out if it supports gpiolib?
>>>
> 
> What does gpiodetect report?
> That should given an indication which driver is being used.
# gpiodetect
gpiochip0 [fffff400.gpio] (32 lines)
gpiochip1 [fffff600.gpio] (19 lines)
gpiochip2 [fffff800.gpio] (32 lines)
gpiochip3 [fffffa00.gpio] (22 lines)

Compiled and linked both pinctrl.
> 
> Cheers,
> Kent.
> 
>>> But again, this is outside my area so you would need to confirm that
>>> yourself or get feedback from someone else.
>>> If you determine that you are using a pinctrl that supports setting
>>> bias via gpiolib then we'll have to do some more digging.
>>>
>>> Cheers,
>>> Kent.
>>>
>> Thanks
>> Jiri

Re: [libgpiod] bug: pull-up does not work

[Kent Gibson]

On Mon, Mar 28, 2022 at 10:58:20AM +0200, Jiří Prchal wrote:
> 
> 
> On 28. 03. 22 10:08, Kent Gibson wrote:
> > On Mon, Mar 28, 2022 at 09:12:16AM +0200, Jiří Prchal wrote:
> > > 
> > > 
> > > On 25. 03. 22 17:01, Kent Gibson wrote:
> > > > On Fri, Mar 25, 2022 at 04:13:11PM +0100, Jiří Prchal wrote:
> > > > > 
> > > > > 
> > > > > On 25. 03. 22 15:57, Kent Gibson wrote:
> > > > > > On Fri, Mar 25, 2022 at 11:02:07AM +0100, Jiří Prchal wrote:
> > > > > > > Hi,
> > > > > > > since in debian is 1.6.2 and pull-up doesn't work so I cloned git, branch
> > > > > > > next/libgpiod-2.0 and compiled libgpiod and tools, but no luck, same result.
> > > > > > > 
> > > > > > 
> > > > > > You mean it doesn't work for you on your platform.
> > > > > > 
> > > > > > The libgpiod-2.0 branch is a work in progress and should not be considered
> > > > > > the place to go to find solutions to problems with v1.6.
> > > > > > Not that I'm saying that the v2 branch doesn't work, I'm actually pretty
> > > > > > sure it does, but its purpose is to switch to the latest kernel uAPI, not
> > > > > > to provide fixes, should they be needed, for v1.6.
> > > > > Just thought api v1 doesn't support pull-ups so tried v2.
> > > > 
> > > > v1 does support bias since Linux v5.5, and libgpiod added support in v1.5.
> > > > 
> > > > > > 
> > > > > > > ~# uname -r
> > > > > > > 5.17.0-rc7_cpm9g25
> > > > > > > 
> > > > > > > floating pins should go with pull-up/down
> > > > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> > > > > > > 0 0 0 0 0 0 0 0
> > > > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> > > > > > > 1 1 0 0 0 0 0 0
> > > > > > > ~# gpioget -B pull-up 3 6 8 10 12 14 16 18 20
> > > > > > > 0 1 0 1 0 0 0 0
> > > > > > > 
> > > > > > > ~# gpioget -v
> > > > > > > gpioget (libgpiod) v2.0-devel
> > > > > > > 
> > > > > > > Whats wrong with it?
> > > > > > 
> > > > > > You forgot to mention which of those pins are floating.
> > > > > All of them.
> > > > > > Or what gpiochip3 is and whether it supports biasing.
> > > > > AT91SAM9G25, hw supports pull-ups.
> > > > > > 
> > > > > > So does your chip support pull-up/down?
> > > > > > The kernel can only enable it if the hardware and pinctrl driver supports it.
> > > > > Is there possibility that pinctrl doesn't support it? I think other gpios
> > > > > used in kernel are with pull-up.
> > > > > Example:
> > > > > pinctrl@fffff400 {
> > > > > 	1wire {
> > > > > 		pinctrl_1wire: 1wire-0 {
> > > > > 			atmel,pins = <AT91_PIOC 0 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC0
> > > > > PIO, pull-up */
> > > > > 		};
> > > > > 	};
> > > > > };
> > > > > 
> > > > 
> > > > Pinctrl and device tree are outside my area, but my understanding is
> > > > that setting via DT is a separate interface, so while it may be
> > > > supported by DT it may not be via the gpiolib interface.
> > > > But I will defer to anyone else on that.
> > > > (CCing in Andy since I'm pretty sure he would know)
> > > > 
> > > > Not sure which pinctrl is relevant for your case.
> > > > pinctrl-at91 doesn't appear to support setting the pull-up via the gpiolib
> > > > interface, but pinctrl-at91-pio4 does, so my guess would be you are using
> > > > the pinctrl-at91.
> > > pinctrl-at91-pio4 didn't help, syminfo says "for Atmel PIO4 controller
> > > available on sama5d2 SoC" but my is sam9g25.
> > > How can I find out if it supports gpiolib?
> > > > 
> > 
> > What does gpiodetect report?
> > That should given an indication which driver is being used.
> # gpiodetect
> gpiochip0 [fffff400.gpio] (32 lines)
> gpiochip1 [fffff600.gpio] (19 lines)
> gpiochip2 [fffff800.gpio] (32 lines)
> gpiochip3 [fffffa00.gpio] (22 lines)
> 
> Compiled and linked both pinctrl.

Ok, that isn't helpful, for me anyway, and I'm not sure where to go from
there. Hopefully someone else can chip in.

Cheers,
Kent.

[libgpiod] feature request: output state read and sustain

[Jiří Prchal]

Hi,
using new libgpiod / chardev driver, is there any way to get state of 
output? I mean one process sets it for example to 1 and another process 
reads this output state for example to show that on web page.
I have to say that old sysfs interface was more user friendly...

And at second: it would be better to NOT "the state of a GPIO line 
controlled over the character device reverts to default when the last 
process referencing the file descriptor representing the device file 
exits." "Set and forget" behavior is more natural to what some gpios are 
used. For example resetting external modems, need set 1 for short time, 
then to 0 and leave it for long long time until next reset is needed. 
It's non sense to keep running some process only to keep output at 0.

Thanks
Jiri

Re: [libgpiod] feature request: output state read and sustain

[Kent Gibson]

On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
> Hi,
> using new libgpiod / chardev driver, is there any way to get state of
> output? I mean one process sets it for example to 1 and another process
> reads this output state for example to show that on web page.
> I have to say that old sysfs interface was more user friendly...
> 

"new" being anything since Linux 4.8 ;-)?
And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
provide an interface to the chip driver.  More on that later.

Only the process holding the line has access to the current value.
If you need that value elsewhere then it has to be published by that
process - it is not available through the GPIO API itself.
There is nothing preventing that process publishing the value
in whatever way is appropriate to your application.
e.g. write it to a file that can be read by your webapp, just as it
would from sysfs.

Less restrictive access models are frequently "more user friendly", but
have other issues. e.g. some misbehaving process just reset your
modem for you.

And sysfs has other great features like being slow and being complete
rubbish for events on input lines.

> And at second: it would be better to NOT "the state of a GPIO line
> controlled over the character device reverts to default when the last
> process referencing the file descriptor representing the device file exits."
> "Set and forget" behavior is more natural to what some gpios are used. For
> example resetting external modems, need set 1 for short time, then to 0 and
> leave it for long long time until next reset is needed. It's non sense to
> keep running some process only to keep output at 0.

Agreed, that might be more natural, but that behaviour is not by choice,
it is a consequence of the kernel internals.  In short, if the GPIO
subsystem does not hold the chip then the driver is free to do what it
likes to it.
So when you release a line all bets are off.
It may stay where you left it, but it may not - it may even switch to an
input - it depends on the driver.
If it works for you that's great, but without major kernel changes
libgpiod has no better option than to provide the caveat as the "set and
forget" behaviour is something that it cannot guarantee.

Cheers,
Kent.

Re: [libgpiod] feature request: output state read and sustain

[Jiří Prchal]

On 29. 06. 22 9:23, Kent Gibson wrote:
> On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
>> Hi,
>> using new libgpiod / chardev driver, is there any way to get state of
>> output? I mean one process sets it for example to 1 and another process
>> reads this output state for example to show that on web page.
>> I have to say that old sysfs interface was more user friendly...
>>
> 
> "new" being anything since Linux 4.8 ;-)?
> And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
> provide an interface to the chip driver.  More on that later.
> 
> Only the process holding the line has access to the current value.
> If you need that value elsewhere then it has to be published by that
> process - it is not available through the GPIO API itself.
> There is nothing preventing that process publishing the value
> in whatever way is appropriate to your application.
> e.g. write it to a file that can be read by your webapp, just as it
> would from sysfs.
> 
> Less restrictive access models are frequently "more user friendly", but
> have other issues. e.g. some misbehaving process just reset your
> modem for you.
> 
> And sysfs has other great features like being slow and being complete
> rubbish for events on input lines.
> 
>> And at second: it would be better to NOT "the state of a GPIO line
>> controlled over the character device reverts to default when the last
>> process referencing the file descriptor representing the device file exits."
>> "Set and forget" behavior is more natural to what some gpios are used. For
>> example resetting external modems, need set 1 for short time, then to 0 and
>> leave it for long long time until next reset is needed. It's non sense to
>> keep running some process only to keep output at 0.
> 
> Agreed, that might be more natural, but that behaviour is not by choice,
> it is a consequence of the kernel internals.  In short, if the GPIO
> subsystem does not hold the chip then the driver is free to do what it
> likes to it.
> So when you release a line all bets are off.
> It may stay where you left it, but it may not - it may even switch to an
> input - it depends on the driver.
Does it mean that without changing this particular line it could be changed? For example by setting another line in chip?

> If it works for you that's great, but without major kernel changes
> libgpiod has no better option than to provide the caveat as the "set and
> forget" behaviour is something that it cannot guarantee.
Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario:
start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things
when the proces dies systemd will start it again

and another scenario:
proces checks time, if is the right time -> gpioset =1
other proces reads output and print out on web

Jiri

> 
> Cheers,
> Kent.
> 

Re: [libgpiod] feature request: output state read and sustain

[Kent Gibson]

On Wed, Jun 29, 2022 at 11:25:57AM +0200, Jiří Prchal wrote:
> 
> 
> On 29. 06. 22 9:23, Kent Gibson wrote:
> > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
> > > Hi,
> > > using new libgpiod / chardev driver, is there any way to get state of
> > > output? I mean one process sets it for example to 1 and another process
> > > reads this output state for example to show that on web page.
> > > I have to say that old sysfs interface was more user friendly...
> > > 
> > 
> > "new" being anything since Linux 4.8 ;-)?
> > And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
> > provide an interface to the chip driver.  More on that later.
> > 
> > Only the process holding the line has access to the current value.
> > If you need that value elsewhere then it has to be published by that
> > process - it is not available through the GPIO API itself.
> > There is nothing preventing that process publishing the value
> > in whatever way is appropriate to your application.
> > e.g. write it to a file that can be read by your webapp, just as it
> > would from sysfs.
> > 
> > Less restrictive access models are frequently "more user friendly", but
> > have other issues. e.g. some misbehaving process just reset your
> > modem for you.
> > 
> > And sysfs has other great features like being slow and being complete
> > rubbish for events on input lines.
> > 
> > > And at second: it would be better to NOT "the state of a GPIO line
> > > controlled over the character device reverts to default when the last
> > > process referencing the file descriptor representing the device file exits."
> > > "Set and forget" behavior is more natural to what some gpios are used. For
> > > example resetting external modems, need set 1 for short time, then to 0 and
> > > leave it for long long time until next reset is needed. It's non sense to
> > > keep running some process only to keep output at 0.
> > 
> > Agreed, that might be more natural, but that behaviour is not by choice,
> > it is a consequence of the kernel internals.  In short, if the GPIO
> > subsystem does not hold the chip then the driver is free to do what it
> > likes to it.
> > So when you release a line all bets are off.
> > It may stay where you left it, but it may not - it may even switch to an
> > input - it depends on the driver.
> Does it mean that without changing this particular line it could be changed? For example by setting another line in chip?
> 

If you hold a line then it is guaranteed to remain in the state you
request. Changing or releasing other lines will not alter that line.

If you release a line then other processes are free to request it and
alter it.  But if no other process request it, it will generally will
remain in the state you left it.  Generally.
The exception is if you release the last requested line on the chip, in
which case the GPIO subsystem will release the chip to the driver and
what happens to all the lines on the chip after that is up to the driver.

The big problem is you never know if the line you are releasing is the
last requested line.  Unless you explicitly hold at least one line.

> > If it works for you that's great, but without major kernel changes
> > libgpiod has no better option than to provide the caveat as the "set and
> > forget" behaviour is something that it cannot guarantee.
> Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario:
> start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things
> when the proces dies systemd will start it again
> 

No, you don't have to emulate sysfs, you can do whatever works for you,
that was just an example.

The libgpiod tools are not the only interface libgpiod provides - they
are just the command line/shell interface.
You would not call gpioset repeatedly, you would request the line using
libgpiod (for C), or the appropriate bindings for the language you are
working in, and then set the line as required in your program.

If you are working in shell with libgpiod v1.6.3 then there is no way
to hold a line and subsequently change it.  You would have to repeatedly
call gpioset and hope for the best in between times.
For libgpiod v2 I'm working on an interactive mode for gpioset that
keeps it running and holding the line(s) and you pipe set commands to it
from your script as required.

If you need anything more complicated for scripting then the Python
bindings would be the way to go.

> and another scenario:
> proces checks time, if is the right time -> gpioset =1
> other proces reads output and print out on web
> 

line manager process:
request line (using appropriate binding)
wait until whenever
set=1 (using appropriate binding)
publish line state where web server can see
...

web server process:
webserver asked for state
returns last published value

Cheers,
Kent.

Re: [libgpiod] feature request: output state read and sustain

[Andy Shevchenko]

On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
> On 29. 06. 22 9:23, Kent Gibson wrote:
> > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:

> >> using new libgpiod / chardev driver, is there any way to get state of
> >> output? I mean one process sets it for example to 1 and another process
> >> reads this output state for example to show that on web page.

I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO
chips may not allow this on H/W level and when reading they always
will get the value of Input Buffer (now imagine if the line is
configured as Output with Input being disconnected from the physical
pin).

> >> I have to say that old sysfs interface was more user friendly...

And much more buggy and PITA.

> > "new" being anything since Linux 4.8 ;-)?
> > And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
> > provide an interface to the chip driver.  More on that later.
> >
> > Only the process holding the line has access to the current value.
> > If you need that value elsewhere then it has to be published by that
> > process - it is not available through the GPIO API itself.
> > There is nothing preventing that process publishing the value
> > in whatever way is appropriate to your application.
> > e.g. write it to a file that can be read by your webapp, just as it
> > would from sysfs.
> >
> > Less restrictive access models are frequently "more user friendly", but
> > have other issues. e.g. some misbehaving process just reset your
> > modem for you.
> >
> > And sysfs has other great features like being slow and being complete
> > rubbish for events on input lines.
> >
> >> And at second: it would be better to NOT "the state of a GPIO line
> >> controlled over the character device reverts to default when the last
> >> process referencing the file descriptor representing the device file exits."
> >> "Set and forget" behavior is more natural to what some gpios are used. For
> >> example resetting external modems, need set 1 for short time, then to 0 and
> >> leave it for long long time until next reset is needed. It's non sense to
> >> keep running some process only to keep output at 0.
> >
> > Agreed, that might be more natural, but that behaviour is not by choice,
> > it is a consequence of the kernel internals.  In short, if the GPIO
> > subsystem does not hold the chip then the driver is free to do what it
> > likes to it.
> > So when you release a line all bets are off.
> > It may stay where you left it, but it may not - it may even switch to an
> > input - it depends on the driver.
> Does it mean that without changing this particular line it could be changed? For example by setting another line in chip?

No, it's only about the line in question.

> > If it works for you that's great, but without major kernel changes
> > libgpiod has no better option than to provide the caveat as the "set and
> > forget" behaviour is something that it cannot guarantee.
> Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario:
> start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things
> when the proces dies systemd will start it again

Do not use shell. Use proper programming language that may give you an
easier way of handling this, i.e. _context_. Shell tools are
_context-less_ and here is the problem you are trying to solve, but
from the wrong end.

> and another scenario:
> proces checks time, if is the right time -> gpioset =1
> other proces reads output and print out on web


-- 
With Best Regards,
Andy Shevchenko

Re: [libgpiod] feature request: output state read and sustain

[Kent Gibson]

On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
> > On 29. 06. 22 9:23, Kent Gibson wrote:
> > > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
> 
> > >> using new libgpiod / chardev driver, is there any way to get state of
> > >> output? I mean one process sets it for example to 1 and another process
> > >> reads this output state for example to show that on web page.
> 
> I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO
> chips may not allow this on H/W level and when reading they always
> will get the value of Input Buffer (now imagine if the line is
> configured as Output with Input being disconnected from the physical
> pin).
> 

Agreed.  Userspace should know the value they set the output to, and so
have no need to read it back.  GPIO is not NVM.

The only time it makes sense to me to go to the hardware for output
values is for open-drain outputs, but as you say, even then it would
depend in the hardware and driver supporting it. And for those cases it
might be better to explicitly emulate open-drain and switch the line to
an input when not being actively drive.

> > >> I have to say that old sysfs interface was more user friendly...
> 
> And much more buggy and PITA.
> 
> > > "new" being anything since Linux 4.8 ;-)?
> > > And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
> > > provide an interface to the chip driver.  More on that later.
> > >
> > > Only the process holding the line has access to the current value.
> > > If you need that value elsewhere then it has to be published by that
> > > process - it is not available through the GPIO API itself.
> > > There is nothing preventing that process publishing the value
> > > in whatever way is appropriate to your application.
> > > e.g. write it to a file that can be read by your webapp, just as it
> > > would from sysfs.
> > >
> > > Less restrictive access models are frequently "more user friendly", but
> > > have other issues. e.g. some misbehaving process just reset your
> > > modem for you.
> > >
> > > And sysfs has other great features like being slow and being complete
> > > rubbish for events on input lines.
> > >
> > >> And at second: it would be better to NOT "the state of a GPIO line
> > >> controlled over the character device reverts to default when the last
> > >> process referencing the file descriptor representing the device file exits."
> > >> "Set and forget" behavior is more natural to what some gpios are used. For
> > >> example resetting external modems, need set 1 for short time, then to 0 and
> > >> leave it for long long time until next reset is needed. It's non sense to
> > >> keep running some process only to keep output at 0.
> > >
> > > Agreed, that might be more natural, but that behaviour is not by choice,
> > > it is a consequence of the kernel internals.  In short, if the GPIO
> > > subsystem does not hold the chip then the driver is free to do what it
> > > likes to it.
> > > So when you release a line all bets are off.
> > > It may stay where you left it, but it may not - it may even switch to an
> > > input - it depends on the driver.
> > Does it mean that without changing this particular line it could be changed? For example by setting another line in chip?
> 
> No, it's only about the line in question.
> 
> > > If it works for you that's great, but without major kernel changes
> > > libgpiod has no better option than to provide the caveat as the "set and
> > > forget" behaviour is something that it cannot guarantee.
> > Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario:
> > start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things
> > when the proces dies systemd will start it again
> 
> Do not use shell. Use proper programming language that may give you an
> easier way of handling this, i.e. _context_. Shell tools are
> _context-less_ and here is the problem you are trying to solve, but
> from the wrong end.
> 

Actually my proposed gpioset for v2 will support running interactively
so it can maintain context and be driven from shell - for cases where
basic scripting will suffice.

Cheers,
Kent.

Re: [libgpiod] feature request: output state read and sustain

[Andy Shevchenko]

On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote:
> On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:

...

> > Do not use shell. Use proper programming language that may give you an
> > easier way of handling this, i.e. _context_. Shell tools are
> > _context-less_ and here is the problem you are trying to solve, but
> > from the wrong end.
>
> Actually my proposed gpioset for v2 will support running interactively
> so it can maintain context and be driven from shell - for cases where
> basic scripting will suffice.

Dunno if it's the right direction and if I missed any (additional) discussion.
As far as I remember the idea was to introduce DBus aware daemon that
should handle the context of the line and at the same time consider security
implications. Allowing shell to be context-aware is a hidden mine
field. What will happen if the script/user forgets to move the line to
the proper state and the chip will drain a lot of current? So, at
least PM concerns just popped up immediately to my mind. What else can
be problematic? So, I dunno, it's a good idea to allow shell to leave
a line in some state when the user actually doesn't care about it
anymore. At the bare minimum this mustn't be default behaviour.

-- 
With Best Regards,
Andy Shevchenko

Re: [libgpiod] feature request: output state read and sustain

[Jiří Prchal]

On 29. 06. 22 12:47, Kent Gibson wrote:
> On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
>> On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
>>> On 29. 06. 22 9:23, Kent Gibson wrote:
>>>> On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
>>
>>>>> using new libgpiod / chardev driver, is there any way to get state of
>>>>> output? I mean one process sets it for example to 1 and another process
>>>>> reads this output state for example to show that on web page.
>>
>> I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO
>> chips may not allow this on H/W level and when reading they always
>> will get the value of Input Buffer (now imagine if the line is
>> configured as Output with Input being disconnected from the physical
>> pin).
>>
> 
> Agreed.  Userspace should know the value they set the output to, and so
> have no need to read it back.  GPIO is not NVM.
Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0)
I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one.

> 
> The only time it makes sense to me to go to the hardware for output
> values is for open-drain outputs, but as you say, even then it would
> depend in the hardware and driver supporting it. And for those cases it
> might be better to explicitly emulate open-drain and switch the line to
> an input when not being actively drive.
Open-drain outputs as many HW as I know has separate register for output to switch on and off the tranzistor and input register to read value on pin.
So 2 values are needed from o-d outputs. OK, first could be write only and second read only.
> 
>>>>> I have to say that old sysfs interface was more user friendly...
>>
>> And much more buggy and PITA.
>>
>>>> "new" being anything since Linux 4.8 ;-)?
>>>> And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
>>>> provide an interface to the chip driver.  More on that later.
>>>>
>>>> Only the process holding the line has access to the current value.
>>>> If you need that value elsewhere then it has to be published by that
>>>> process - it is not available through the GPIO API itself.
>>>> There is nothing preventing that process publishing the value
>>>> in whatever way is appropriate to your application.
>>>> e.g. write it to a file that can be read by your webapp, just as it
>>>> would from sysfs.
>>>>
>>>> Less restrictive access models are frequently "more user friendly", but
>>>> have other issues. e.g. some misbehaving process just reset your
>>>> modem for you.
>>>>
>>>> And sysfs has other great features like being slow and being complete
>>>> rubbish for events on input lines.
>>>>
>>>>> And at second: it would be better to NOT "the state of a GPIO line
>>>>> controlled over the character device reverts to default when the last
>>>>> process referencing the file descriptor representing the device file exits."
>>>>> "Set and forget" behavior is more natural to what some gpios are used. For
>>>>> example resetting external modems, need set 1 for short time, then to 0 and
>>>>> leave it for long long time until next reset is needed. It's non sense to
>>>>> keep running some process only to keep output at 0.
>>>>
>>>> Agreed, that might be more natural, but that behaviour is not by choice,
>>>> it is a consequence of the kernel internals.  In short, if the GPIO
>>>> subsystem does not hold the chip then the driver is free to do what it
>>>> likes to it.
>>>> So when you release a line all bets are off.
>>>> It may stay where you left it, but it may not - it may even switch to an
>>>> input - it depends on the driver.
>>> Does it mean that without changing this particular line it could be changed? For example by setting another line in chip?
>>
>> No, it's only about the line in question.
>>
>>>> If it works for you that's great, but without major kernel changes
>>>> libgpiod has no better option than to provide the caveat as the "set and
>>>> forget" behaviour is something that it cannot guarantee.
>>> Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario:
>>> start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things
>>> when the proces dies systemd will start it again
>>
>> Do not use shell. Use proper programming language that may give you an
>> easier way of handling this, i.e. _context_. Shell tools are
>> _context-less_ and here is the problem you are trying to solve, but
>> from the wrong end.
>>
> 
> Actually my proposed gpioset for v2 will support running interactively
> so it can maintain context and be driven from shell - for cases where
> basic scripting will suffice.
It would be nice.

Jiri
> 
> Cheers,
> Kent.

Re: [libgpiod] feature request: output state read and sustain

[Kent Gibson]

On Wed, Jun 29, 2022 at 12:58:18PM +0200, Andy Shevchenko wrote:
> On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote:
> > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
> 
> ...
> 
> > > Do not use shell. Use proper programming language that may give you an
> > > easier way of handling this, i.e. _context_. Shell tools are
> > > _context-less_ and here is the problem you are trying to solve, but
> > > from the wrong end.
> >
> > Actually my proposed gpioset for v2 will support running interactively
> > so it can maintain context and be driven from shell - for cases where
> > basic scripting will suffice.
> 
> Dunno if it's the right direction and if I missed any (additional) discussion.
> As far as I remember the idea was to introduce DBus aware daemon that
> should handle the context of the line and at the same time consider security
> implications. Allowing shell to be context-aware is a hidden mine
> field. What will happen if the script/user forgets to move the line to
> the proper state and the chip will drain a lot of current? So, at
> least PM concerns just popped up immediately to my mind. What else can
> be problematic? So, I dunno, it's a good idea to allow shell to leave
> a line in some state when the user actually doesn't care about it
> anymore. At the bare minimum this mustn't be default behaviour.
> 

I don't think it is what you think it is.
Take a look.  If you don't like it then get Bart to bin it.

There was no on-list discussion.  I had preliminary disussions with Bart,
and had intended to float it as an RFC, but got distracted by other
things and ended up going direct to an implementation.

Last I heard the DBus daemon is still on the cards, but not sure where
Bart is with it, and the gpioset addition is for simpler cases where
DBus is overkill or where there is no daemon.

It is not the default behaviour, it is an optional mode.

gpioset maintains the context, not shell.

"User's forgetting" is language independent.  Shell scripts matter!

What else have I missed replying to? I don't know.

And good to see our apparent agreement in the previous mails was just an
aberation.  I was starting to think there was something wrong with the
universe :-|.

Cheers,
Kent.

Re: [libgpiod] feature request: output state read and sustain

[Kent Gibson]

On Wed, Jun 29, 2022 at 01:17:54PM +0200, Jiří Prchal wrote:
> 
> 
> On 29. 06. 22 12:47, Kent Gibson wrote:
> > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
> > > > On 29. 06. 22 9:23, Kent Gibson wrote:
> > > > > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
> > > 
> > > > > > using new libgpiod / chardev driver, is there any way to get state of
> > > > > > output? I mean one process sets it for example to 1 and another process
> > > > > > reads this output state for example to show that on web page.
> > > 
> > > I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO
> > > chips may not allow this on H/W level and when reading they always
> > > will get the value of Input Buffer (now imagine if the line is
> > > configured as Output with Input being disconnected from the physical
> > > pin).
> > > 
> > 
> > Agreed.  Userspace should know the value they set the output to, and so
> > have no need to read it back.  GPIO is not NVM.
> Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0)
> I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one.
> 

No, no it is not RAM.

And I have seen hardware where you can't read back the output.
And so has Andy apparently.
That is the problem - there is lots of hardware out there and we are
trying to provide a consistent interface to inconsistent hardware.

Cheers,
Kent.

Re: [libgpiod] feature request: output state read and sustain

[Jiří Prchal]

On 29. 06. 22 13:25, Kent Gibson wrote:
> On Wed, Jun 29, 2022 at 01:17:54PM +0200, Jiří Prchal wrote:
>>
>>
>> On 29. 06. 22 12:47, Kent Gibson wrote:
>>> On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
>>>> On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
>>>>> On 29. 06. 22 9:23, Kent Gibson wrote:
>>>>>> On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
>>>>
>>>>>>> using new libgpiod / chardev driver, is there any way to get state of
>>>>>>> output? I mean one process sets it for example to 1 and another process
>>>>>>> reads this output state for example to show that on web page.
>>>>
>>>> I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO
>>>> chips may not allow this on H/W level and when reading they always
>>>> will get the value of Input Buffer (now imagine if the line is
>>>> configured as Output with Input being disconnected from the physical
>>>> pin).
>>>>
>>>
>>> Agreed.  Userspace should know the value they set the output to, and so
>>> have no need to read it back.  GPIO is not NVM.
>> Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0)
>> I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one.
>>
> 
> No, no it is not RAM.
> 
> And I have seen hardware where you can't read back the output.
> And so has Andy apparently.
> That is the problem - there is lots of hardware out there and we are
> trying to provide a consistent interface to inconsistent hardware.
OK, but if hw supports it why not provide it. And for hw without support keep it's value in memory? Or return to user space with errno indicating "no support"?
> 
> Cheers,
> Kent.

Re: [libgpiod] feature request: output state read and sustain

[Andy Shevchenko]

On Wed, Jun 29, 2022 at 1:20 PM Kent Gibson <warthog618@gmail.com> wrote:
> On Wed, Jun 29, 2022 at 12:58:18PM +0200, Andy Shevchenko wrote:
> > On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote:
> > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:

...

> > > > Do not use shell. Use proper programming language that may give you an
> > > > easier way of handling this, i.e. _context_. Shell tools are
> > > > _context-less_ and here is the problem you are trying to solve, but
> > > > from the wrong end.
> > >
> > > Actually my proposed gpioset for v2 will support running interactively
> > > so it can maintain context and be driven from shell - for cases where
> > > basic scripting will suffice.
> >
> > Dunno if it's the right direction and if I missed any (additional) discussion.
> > As far as I remember the idea was to introduce DBus aware daemon that
> > should handle the context of the line and at the same time consider security
> > implications. Allowing shell to be context-aware is a hidden mine
> > field. What will happen if the script/user forgets to move the line to
> > the proper state and the chip will drain a lot of current? So, at
> > least PM concerns just popped up immediately to my mind. What else can
> > be problematic? So, I dunno, it's a good idea to allow shell to leave
> > a line in some state when the user actually doesn't care about it
> > anymore. At the bare minimum this mustn't be default behaviour.
>
> I don't think it is what you think it is.
> Take a look.  If you don't like it then get Bart to bin it.
>
> There was no on-list discussion.  I had preliminary disussions with Bart,
> and had intended to float it as an RFC, but got distracted by other
> things and ended up going direct to an implementation.
>
> Last I heard the DBus daemon is still on the cards, but not sure where
> Bart is with it, and the gpioset addition is for simpler cases where
> DBus is overkill or where there is no daemon.
>
> It is not the default behaviour, it is an optional mode.

Good!

> gpioset maintains the context, not shell.

A-ha, that's cool, it pleases me.

> "User's forgetting" is language independent.  Shell scripts matter!

:-)

> What else have I missed replying to? I don't know.
>
> And good to see our apparent agreement in the previous mails was just an
> aberation.  I was starting to think there was something wrong with the
> universe :-|.

Ha-ha.

-- 
With Best Regards,
Andy Shevchenko

Re: [libgpiod] feature request: output state read and sustain

[Kent Gibson]

On Wed, Jun 29, 2022 at 01:48:17PM +0200, Jiří Prchal wrote:
> 
> 
> On 29. 06. 22 13:25, Kent Gibson wrote:
> > On Wed, Jun 29, 2022 at 01:17:54PM +0200, Jiří Prchal wrote:
> > > 
> > > 
> > > On 29. 06. 22 12:47, Kent Gibson wrote:
> > > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> > > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
> > > > > > On 29. 06. 22 9:23, Kent Gibson wrote:
> > > > > > > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
> > > > > 
> > > > > > > > using new libgpiod / chardev driver, is there any way to get state of
> > > > > > > > output? I mean one process sets it for example to 1 and another process
> > > > > > > > reads this output state for example to show that on web page.
> > > > > 
> > > > > I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO
> > > > > chips may not allow this on H/W level and when reading they always
> > > > > will get the value of Input Buffer (now imagine if the line is
> > > > > configured as Output with Input being disconnected from the physical
> > > > > pin).
> > > > > 
> > > > 
> > > > Agreed.  Userspace should know the value they set the output to, and so
> > > > have no need to read it back.  GPIO is not NVM.
> > > Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0)
> > > I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one.
> > > 
> > 
> > No, no it is not RAM.
> > 
> > And I have seen hardware where you can't read back the output.
> > And so has Andy apparently.
> > That is the problem - there is lots of hardware out there and we are
> > trying to provide a consistent interface to inconsistent hardware.
> OK, but if hw supports it why not provide it. And for hw without support keep it's value in memory? Or return to user space with errno indicating "no support"?

No idea - I'm new here (by your definition) ;-).

In general we do provide it where the hardware supports it, so for
example typically reading back outputs works.

I would guess the reason we don't provide a guarantee is that is that in
most cases it isn't necessary, and to do so adds cost.
Full on caching and error handling as you suggest would be overkill
for most situations.  Most writes to outputs don't get read back, so why
waste resources caching them? And if you want to do the error handling
you suggest you have to cache them - just in case, or you have to
pre-get them to find out which lines need to be cached, but you can't do
that without changing the line direction to output and you certainly
can't do that autonomously, so the driver interface needs to be far more
complex to probe the driver capabilities down to the line and in
different modes.  And you need to spend time doing that...
Basically a can of worms.

And the simple workaround is for the user to cache the value themselves
if they need it and find their hardware doesn't support read back.

So best effort is the most pragmatic and cost effective solution.
(Hopefully Andy will chip in with the actual reason, which is probably
something far more obvious ;-)

As always, if you see a better way, submit a patch!

Cheers,
Kent.

Re: [libgpiod] feature request: output state read and sustain

[Bartosz Golaszewski]

On Wed, Jun 29, 2022 at 12:58 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote:
> > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
>
> ...
>
> > > Do not use shell. Use proper programming language that may give you an
> > > easier way of handling this, i.e. _context_. Shell tools are
> > > _context-less_ and here is the problem you are trying to solve, but
> > > from the wrong end.
> >
> > Actually my proposed gpioset for v2 will support running interactively
> > so it can maintain context and be driven from shell - for cases where
> > basic scripting will suffice.
>
> Dunno if it's the right direction and if I missed any (additional) discussion.
> As far as I remember the idea was to introduce DBus aware daemon that
> should handle the context of the line and at the same time consider security

And it's still very much on the roadmap.

> implications. Allowing shell to be context-aware is a hidden mine
> field. What will happen if the script/user forgets to move the line to
> the proper state and the chip will drain a lot of current? So, at
> least PM concerns just popped up immediately to my mind. What else can
> be problematic? So, I dunno, it's a good idea to allow shell to leave
> a line in some state when the user actually doesn't care about it
> anymore. At the bare minimum this mustn't be default behaviour.
>

It's not much different from letting your current gpioset run in the
background, is it?

Kent just submitted his first version of gpioset, you can take a look
at it and review it. :)

Bart

> --
> With Best Regards,
> Andy Shevchenko

Re: [libgpiod] feature request: output state read and sustain

[Andy Shevchenko]

On Wed, Jun 29, 2022 at 2:56 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Wed, Jun 29, 2022 at 12:58 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> >
> > On Wed, Jun 29, 2022 at 12:48 PM Kent Gibson <warthog618@gmail.com> wrote:
> > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> > > > On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@aksignal.cz> wrote:
> >
> > ...
> >
> > > > Do not use shell. Use proper programming language that may give you an
> > > > easier way of handling this, i.e. _context_. Shell tools are
> > > > _context-less_ and here is the problem you are trying to solve, but
> > > > from the wrong end.
> > >
> > > Actually my proposed gpioset for v2 will support running interactively
> > > so it can maintain context and be driven from shell - for cases where
> > > basic scripting will suffice.
> >
> > Dunno if it's the right direction and if I missed any (additional) discussion.
> > As far as I remember the idea was to introduce DBus aware daemon that
> > should handle the context of the line and at the same time consider security
>
> And it's still very much on the roadmap.
>
> > implications. Allowing shell to be context-aware is a hidden mine
> > field. What will happen if the script/user forgets to move the line to
> > the proper state and the chip will drain a lot of current? So, at
> > least PM concerns just popped up immediately to my mind. What else can
> > be problematic? So, I dunno, it's a good idea to allow shell to leave
> > a line in some state when the user actually doesn't care about it
> > anymore. At the bare minimum this mustn't be default behaviour.
> >
>
> It's not much different from letting your current gpioset run in the
> background, is it?
>
> Kent just submitted his first version of gpioset, you can take a look
> at it and review it. :)

So far from Kent's and yours explanations there is no evidence to
raise an alarm.


-- 
With Best Regards,
Andy Shevchenko