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. > 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. Yours, Linus Walleij
