On Sun, Aug 2, 2020 at 5:32 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > On Fri, Jul 31, 2020 at 06:05:10PM +0200, Bartosz Golaszewski wrote: > > On Sun, Jul 26, 2020 at 3:12 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: [snip!] > > > > > > > > > +static u64 gpioline_config_flags(struct gpioline_config *lc, int line_idx) > > > > > +{ > > > > > + int i; > > > > > + > > > > > + for (i = lc->num_attrs - 1; i >= 0; i--) { > > > > > > > > Much better to read is > > > > > > > > unsigned int i = lc->num_attrs; > > > > > > > > while (i--) { > > > > ... > > > > } > > > > > > > > > > Really? I find that the post-decrement in the while makes determining the > > > bounds of the loop more confusing. > > > > > > > Agreed, Andy: this is too much nit-picking. :) > > > > I was actually hoping for some feedback on the direction of that loop, > as it relates to the handling of multiple instances of the same > attribute associated with a given line. > > The reverse loop here implements a last in wins policy, but I'm now > thinking the kernel should be encouraging userspace to only associate a > given attribute with a line once, and that a first in wins would help do > that - as additional associations would be ignored. > > Alternatively, the kernel should enforce that an attribute can only be > associated once, but that would require adding more request validation. > I guess this would result in a lot of churn to do validation which is largely unnecessary? To me the first in wins sounds more consistent. 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. [snip] Bartosz