Aviso de isenção de responsabilidade: Eu não li o código mais recente gpio_keys , apenas desnatado. No entanto, acredito que há uma boa explicação para a separação das chaves GPIO dos IRQs.
Um kernel tem uma tabela de eventos IRQ, então eventos diferentes podem ser dados a IRQs conhecidos. A lista de eventos (retornos de chamada, bem, na verdade, ponteiros) é gravada em um PIC (um chip separado ou integrado na CPU) e, quando a interrupção determinada ocorre, o contexto de execução entra na função de evento. Essas funções precisam ser pequenas, então não há muito tempo perdido dentro da interrupção.
Mas o que é realmente importante aqui é que (a menos que a CPU seja instruída a ignorar temporariamente as interrupções) o kernel responderá a todas as interrupções.
Para um aplicativo responsivo, você deseja que as coisas conectadas aos pinos GPIO produzam uma interrupção (ou seja, seja como um IRQ). No entanto, pode haver aplicativos nos quais você não se importa com cada clique do botão ou com todas as alterações no estado do que estiver conectado ao pino GPIO. Um exemplo poderia ser um sensor, que você quer medir a cada meio segundo, digamos. Você não quer que o sensor informe ao kernel quando ele está "pressionado" que você quer que um aplicativo userspace insira o kernel para informar o estado atual do sensor a cada meio segundo. Não é difícil pensar em um sensor que expõe uma interface que se parece com um botão, praticamente qualquer sensor que tenha apenas dois estados (por exemplo, escuro / claro com um limite) pode parecer um botão.