Read GPIO problem

[MarkHaysHarris777]

This is not a bug.

... you have to set the direction to  "IN"  and then set the ACTIVE_LOW or the input pin will not work the way you expect, even though theoretically the default state of the pins is input !

After setting the direction to IN of course the pin functions normally as an input pin.

Actually, that is a bug... 

My money is on the DTS... as I think it can also set the inital state of the pins, but I really haven't played in that space, so I'll defer to the DTS experts on that one

No, actually, it is NOT a bug.

... that is one of the problems with the PineA64 board;  it does not guarantee the state of an uninitialized pin !  Unlike the Raspberry PI which DOES guarantee the state(s) of uninitialized pins.  The /sys/class/gpio/ system is not "in sync" with the hardware until explicit initialization.  The reason ACTIVE_LOW needs to be set is that the internal pullups can also be pulldowns !  If you don't set ACTIVE_LOW the function of the input pin (whether pullup or pulldown) is not known either, and may or may not function as expected.  The bottom line (aside from argumentative semantics) is that explicit initialization of gpio pads on the PineA64 board is required !

Having said all of that, I agree that we may be able to correct this situation (bug or semantics) with dts and|or init code which makes sure default states of all pins really are input;  but then,  do we assume pullups ?  Or is it really better that the gpio(s) are a resource left up to the user in user space/  again explicit initialization seems to be the best situation all around.