On Fri, Sep 5, 2025 at 11:21 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > This generic pin config property is confusingly named so let's > rename it to make things clearer. > > There are already drivers in the tree that use PIN_CONFIG_OUTPUT > to *read* the value of an output driven pin, which is a big > semantic confusion for the head: are we then reading the > setting of the output or the actual value/level that is put > out on the pin? > > We already have PIN_CONFIG_OUTPUT_ENABLE that turns on driver > buffers for output, so this can by logical conclusion only > drive the voltage level if it should be any different. > > But if we read the pin, are we then reading the *setting* of > the output value or the *actual* value we can see on the > line? > > If the pin has not first been set into output mode with > PIN_CONFIG_OUTPUT_ENABLE, but is instead in some input mode > or tristate, what will reading this property actually > return? > > Reading the current users reading this property it is clear > that what we read is the logical level of the pin as 0 or 1 > depending on if it is low or high. > > Rename it to PIN_CONFIG_LEVEL so it is crystal clear that > we set or read the voltage level of the pin and nothing else. > > Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> Patch applied. Yours, Linus Walleij