On Tue, Aug 04, 2020 at 07:47:43PM +0200, Bartosz Golaszewski wrote: > On Tue, Aug 4, 2020 at 1:01 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > > > [snip] > > > > > > Also: I just started going through the patches - nice idea with the > > > GPIO attributes, I really like it. Although I need to give it a longer > > > thought tomorrow - I'm wondering if we can maybe unify them and the > > > flags. > > > > > > > I had an earlier draft that did just that - and that is partially why > > the loop is last in wins - I was using slot 0 as the default flags. > > But the default flags cover a lot of use cases, including all of v1, and > > it was simple and cheap to provide a default - and it simplified the > > initial port of libgpiod to v2... > > > > If porting libgpiod to v2 is the only concern then I wouldn't stress > about it. At the same time I'm wondering - is there any use-case where > we wouldn't need the flags attribute for at least some lines? Because > if it's always required than maybe having a default isn't that bad. > The only case where flags are not required is an AS-IS request. I have no idea what that use case is useful for, but it is in v1 and therefore supported by v2 for backward compatibility. So there is almost always a flags attribute, and I didn't want to waste an attribute slot on it. Supporting the default in the kernel is trivial - it is literally just the default return in gpioline_config_flags: + } + return lc->flags; +} which would otherwise be 0. Cheers, Kent.