On Thu, Sep 15, 2022 at 11:30 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > On Thu, Sep 15, 2022 at 10:51:02AM +0200, Linus Walleij wrote: > > On Thu, Sep 15, 2022 at 4:23 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > > > > After sleeping on this, I'm even more in disagreement with renaming > > > value to state. > > > > OK let's not do that then. > > > > > OTOH, I totally agree with the addition of GPIOD_ACTIVE/INACTIVE to be > > > used for the logical cases, and even a script to apply it globally. > > > Ideally that script would change both the calls to the logical functions > > > to use ACTIVE/INACTIVE, and the physical to HIGH/LOW. > > > > OK we have consensus on this. > > > > > Introducing enums for those, and changing the function signatures to > > > use those rather than int makes sense to me too. > > > > Either they can be enum or defined to bool true/false. Not really > > sure what is best. But intuitively enum "feels better" for me. > > > > Enums work for me - especially if the goal is to differentiate > logical from physical - there should be a distinct enum for each. > We won't even have to change the function signatures if we go with enums - they already take an int and I'm in general against putting enum types into function signatures in C as they give you a false sense of a strong type. Bart > > > Though I'm not sure > > > why that has to wait until after all users are changed to the new macros. > > > Would that generate lint warnings? > > > > I rather want it all to happen at once. One preparatory commit > > adding the new types and one sed script to refactor the whole > > lot. Not gradual switchover. > > > > The reason is purely administrative: we have too many refactorings > > lagging behind, mainly the GPIO descriptors that have been > > lagging behind for what is it? 5 years? 10? GPIO irqchips also dragged > > out for way too long. We can't keep doing things gradually like > > this, it takes too much time and effort. > > > > I don't want any more "in-transition-indefinitely" stuff in the GPIO > > subsystem if I can avoid it. > > > > Therefore I would advice to switch it all over at the end of a merge > > window and be done with it. > > > > Agreed - do it all at once. My question was specific to the change of the > function signatures to using enums - what is to prevent us doing that > before running the sed script, and have the script switch usage over to > the enums? > > Cheers, > Kent.