On Fri, Jul 5, 2019 at 12:35 PM <Michael.Wu@xxxxxxxxxx> wrote: > For example, there is a button which drives level to be low when it is pushed, and drivers level to be high when it is released. > We want to catch the event when the button is pushed. > > In user space we configure a line event with the following code: > > req.handleflags = GPIOHANDLE_REQUEST_INPUT; > req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE; But *THIS* is the case that should have GPIOHANDLE_REQUEST_ACTIVE_LOW, because you push the button to activate it (it is inactive when not pushed). Also this should have GPIOEVENT_REQUEST_RISING_EDGE. > Run the same logic on another board which the polarity of the button is inverted. The button drives level to be high when it is pushed. > For the inverted level case, we have to add flag GPIOHANDLE_REQUEST_ACTIVE_LOW: > > req.handleflags = GPIOHANDLE_REQUEST_INPUT | GPIOHANDLE_REQUEST_ACTIVE_LOW; > req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE; This one should not be active low. And also have GPIOEVENT_REQUEST_RISING_EDGE. However I agree that the semantic should change as in the patch, it makes most logical sense. The reason it looks as it does is because GPIO line values and interrupts are two separate subsystems inside the kernel with their own flags (as you've seen). But you are right, userspace has no idea about that and should not have to care. Yours, Linus Walleij