On Mon, Oct 02, 2023 at 05:25:05PM +0800, Kent Gibson wrote:

On Mon, Oct 02, 2023 at 12:05:11PM +0300, Andy Shevchenko wrote:

quoted

On Wed, Sep 27, 2023 at 10:23:12PM +0800, Kent Gibson wrote:

quoted

On Wed, Sep 27, 2023 at 04:59:34PM +0300, Andy Shevchenko wrote:

quoted

On Wed, Sep 27, 2023 at 09:49:35PM +0800, Kent Gibson wrote:

quoted

On Wed, Sep 27, 2023 at 03:17:06PM +0300, Andy Shevchenko wrote:

quoted

On Wed, Sep 27, 2023 at 09:32:11AM +0800, Kent Gibson wrote:

...

quoted

quoted

quoted

quoted

quoted

Yet, it opens a way to scale this in case we might have v3 ABI that let's say
allows to work with 512 GPIOs at a time. With your code it will be much harder
to achieve and see what you wrote about maintenance (in that case).

v3 ABI?? libgpiod v2 is barely out the door!
Do you have any cases where 64 lines per request is limiting?

IIRC it was SO question where the OP asks exactly about breaking the 64 lines
limitation in the current ABI.

quoted

If that sort of speculation isn't premature optimisation then I don't know
what is.

No, based on the real question / discussion, just have no link at hand.
But it's quite a niche, I can agree.

Let me know if you find a ref to that discussion - I'm curious.

Here it is (read comments as well):
https://stackoverflow.com/questions/76307370/control-gpio-from-linux-userspace-with-linux-gpio-h

That question looks to me to be confusing how many GPIOs can be
requested per request (64) and in total (effectively unlimited) - thinking
they are the same.
That could be due to their desire to use the gpiod_chip_get_all_lines()
convenience function with a chip with more than 64 lines, rather than
because they have an actual need for the lines to be managed in a single
request.

So that doesn't look like a genuine use case to me - just a "what if I
want to do X" question.  Certainly not something that would warrant a v3
ABI.

Sure, and I'm not talking about v3 ABI to go for, see the word "might" in my
reply in the first paragraph of this message.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel