From: Kent Gibson <warthog618@gmail.com>
To: Pedro Botella <pbotella@gmail.com>
Cc: linux-gpio@vger.kernel.org, brgl@bgdev.pl
Subject: Re: [libgpiod] Bug in python binding when requesting output?
Date: Sat, 13 Feb 2021 08:23:36 +0800 [thread overview]
Message-ID: <20210213002336.GA7405@sol> (raw)
In-Reply-To: <CAJAEvhib-M-UQeoCDs+aex-hdE-vJSQk=C5B7z4A9WmR+JcxQQ@mail.gmail.com>
On Thu, Feb 11, 2021 at 09:54:22PM +0100, Pedro Botella wrote:
> Hi,
>
> I'm experiencing what I think is a bug in the python bindings for libgpiod.
> I believe a line.request with type gpiod.LINE_REQ_DIR_OUT always
> results in that line being set to '0'.
That is correct - when requesting a line as output at the kernel uAPI
the initial value must always be provided. If you do not provide
default_vals via the Python API then the output should be defaulted to
'0' by the Python binding.
> To reproduce:
> 1. request a line with type gpiod.LINE_REQ_DIR_OUT
> 2. set the line to '1'
> 3. release the line
> 4. request the same line with type gpiod.LINE_REQ_DIR_OUT
> 5. get the value, it should now be '0'
>
To clarify, the expected behaviour is that the output is defaulted
to '0' if default values are not provided.
So the problem you are seeing is that the output is not consistently '0'?
If you are expecting to see a '1' then you are expecting the lack of
default_vals in the kwds to leave the output value as is, but that is
not the case - it should default to '0'.
> I think the issue is in "gpiod_LineBulk_request" in
> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings/python/gpiodmodule.c
> There a call to "gpiod_line_request_bulk" with default_vals being
> passed as a pointer. Later on in the code, this parameter is checked
> for NULL, if it is not NULL then the values in the array are used as
> default_vals.
> I believe that a NULL pointer should be passed instead if no
> default_vals have been requested when doing a Line.request from
> Python.
>
Agreed - passing default_vals uninitialized to gpiod_line_request_bulk()
is a bug.
It should be zeroed, or a NULL pointer should be passed if the
default_vals were not provided in the kwds. Otherwise the output
value will be set based on the uninitializezd contents of default_vals.
Would you like to provide a patch?
In the meantime the obvious workaround is to always provide default_vals
in the kwds.
Cheers,
Kent.
next prev parent reply other threads:[~2021-02-13 0:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-11 20:54 [libgpiod] Bug in python binding when requesting output? Pedro Botella
2021-02-13 0:23 ` Kent Gibson [this message]
2021-02-15 8:15 ` Pedro Botella
2021-02-15 9:11 ` Kent Gibson
2021-02-15 11:33 ` Pedro Botella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210213002336.GA7405@sol \
--to=warthog618@gmail.com \
--cc=brgl@bgdev.pl \
--cc=linux-gpio@vger.kernel.org \
--cc=pbotella@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).