Re: [PATCH V1 1/2] gpio: inverter: Add virtual controller for gpio configuration

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Mon, Jun 24, 2019 at 12:50 PM Enrico Weigelt, metux IT consult
<lkml@xxxxxxxxx> wrote:
> On 18.06.19 13:42, Linus Walleij wrote:

> > GPIO_ACTIVE_LOW is there to tell which way the consumer acts.
> > If the line is counted as asserted when active low, it should be flagged
> > as GPIO_ACTIVE_LOW, in the strict sense.
>
> Right. But now some could argue: "the reset consumer contains an
> inverter, there the inverter driver shall be used" ;-)

Usually this is determined by the name and characteristic of the pin.

We don't try to model the inside of external components
on the board, the only thing we really step inside of any
other components than the main SoC.

Perhaps there may be special cases when we want to do that,
but we deal with that the day we have a real world example.

> Well, these electronic semantics can also have a some room for
> interpretation. Even if there's some explicit interverter in the
> schematics, one could count that part of the consumer and then
> declare the line low active. OTOH, one could count all low active
> lines "inverted" and demand an explicit inverter device here.
>
> IMHO, it's often a matter of perspective, which approach is better.
> It's good to have both options now.

IETF has this motto: rough consensus and running code.

As long as the semantics behave as expected it's fine.

> By the way: I'm a great fan of modelling devices semantically (not
> just electrically) correct for the whole machine (including external
> peripherals - not just the stuff on the board itself). For example in
> an embedded system w/ some gpio attached sensor, there should be a
> driver for the actual sensor (eg. IIO) instead letting userland play
> directly w/ the gpio. And if we have a line controlling some external
> device's power, there should be an explicit regulutor, etc, etc.
> (Actually, I'm pretty reluctant of handing out raw gpios to userland)

We are in violent agreement.

> > The fact that many people use this flag as a workaround doesn't mean
> > it doesn't have a valid semantic when used right.
>
> I'm still not sure whether these really are workarounds or just a
> different perspective. At least haven't had a case yet, where both
> perspectives have been equally valid.

When the component is a blackbox and the manufacturer doesn't
say what it looks like on the inside, just that this one pin is active
low, certainly use GPIO_ACTIVE_LOW. Other cases can be
debated.

Yours,
Linus Walleij