Re: [PATCH] gpiolib: cdev: don't record a line direction the driver refused

[Kent Gibson <warthog618@gmail.com>]

On Fri, Oct 16, 2026 at 03:23:24AM -0500, Bartosz Golaszewski wrote:
> On Thu, 15 Oct 2026 17:37:14 +0200, Kent Gibson <warthog618@gmail.com> said:
> >
> >> We can't protect the flags with mutex or spinlock due to the multitude of
> >> issues that forced us to use SRCU. We could maybe consider atomic_t for the
> >> flags field and that would allow us to use various atomic ops and possibly it
> >> would be enough to cover all the read-modify-write cases we have. I need to
> >> think about it and will also ask the clanker for help.
> >>
> >
> > I was thinking along the lines of reverting to atomic bitops directly
> > on the flags, e.g. reverting b7adfb6076ff, without changing the
> > underlying type to atomic_t.
> > Given that most of the time we are operating on individual flags.
> >
> 
> That's still two threads fighting over the flags effectively, right? Ideally
> we should modify the entire set of flags at once. If that proves to be
> impossible, going back to atomic bitops is probably the next best thing.
> 

Yeah, that change wouldn't resolve that conflict - it is just about
deciding which framework you plan to use for the flags.
The IRQ flag problem, and any other flag contention lurking, needs to be
addressed separately either way.

> > With atomic_t you could also use xchg variants for bulk ops?
> >
> 
> I'm not following, could you rephrase or give an example?
> 

I mean atomic_xchg(), atomic_cmpxchg() etc.
I thought atomic_t was intended for counters, not bitmaps of flags, and
I don't have any example, but I expect the code to be pretty hideous - 
You would need to READ_ONCE(), check the flags are in a suitable state,
update them, then atomic_try_cmpxchg() with your updated value.
Rinse and repeat if the try_cmpxchg fails.

> >>
> >> Definitely! I don't see why I would ever be against extending the test
> >> coverage. :)
> >>
> >
> > Ok, I'll try to give it some thought.
> >
> 
> Please also take a look at gpiolib-kunit.c. It may be a better fit for this
> kind of testing.

Will do, but I was thinking of driving error paths in userspace libraries as
well.

Cheers,
Kent.