On Wed, Sep 14, 2022 at 12:35 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Wed, Sep 7, 2022 at 12:41 AM Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > > Linus, do you think we should introduce GPIOD_OUT_INACTIVE / > > GPIOD_OUT_ACTIVE or GPIOD_OUT_DEASSERTED / GPIOD_OUT_ASSERTED and > > deprecate existing GPIOD_OUT_LOW and GPIO_OUT_HIGH? > > They should rather be replaced everywhere in one go. > > I think it is just a half-measure unless we also add > #define GPIOD_ASSERTED 1 > #define GPIOD_DEASSERTED 0 > to be used instead of 1/0 in gpiod_set_value(). > We've had that discussion for libgpiod and went with GPIOD_VALUE_ACTIVE and GPIOD_VALUE_INACTIVE but... > It would also imply changing the signature of the function > gpiod_set_value() to gpiod_set_state() as we are not > really setting a value but a state. > ... now that you've mentioned it it does seem like GPIOD_STATE_ACTIVE/INACTIVE makes much more sense as well as naming the relevant functions gpiod_line_request_set_line_state() etc. > I have thought about changing this, but the problem is that I felt > it should be accompanied with a change fixing as many users > as possible. > > I think this is one of those occasions where we should merge > the new defines, and then send Linus Torvalds a sed script > that he can run at the end of the merge window to change all > gpiod_set_value(...., 1) -> gpiod_set_state(...., GPIOD_ASSERTED); > everywhere. > > After all users are changed, the GPIOD_ASSERTED/DEASSERTED > defined can be turned into an enum. > > That would be the silver bullet against a lot of confusion IMO. > > We would need Bartosz' input on this. > We can also let Linus know that we'll do it ourselves late in the merge window and send a separate PR on Saturday before rc1? Bart > Yours, > Linus Walleij