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. > > 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.
