On Fri, 11 Jan 2019, at 19:31, Linus Walleij wrote: > On Thu, Dec 13, 2018 at 2:21 AM Joel Stanley <joel@xxxxxxxxx> wrote: > > On Tue, 11 Dec 2018 at 18:32, Wang, Kuiying <kuiying.wang@xxxxxxxxx> wrote: > > > > > > Hi Joel/Andrew, > > > > > > I write a drive to enable GPIO passthrough for buttons (like power/reset/id button) as > > > following attached patch. > > > > > > Do you think it is acceptable? > > > > > > Or we could do it in pinmux and extend gpio driver? Design passthrough state > > > except in/out. > > > > I think that this direction would be better than a misc driver. I've > > added Linus, the maintainer for these subsystems, and the linux-gpio > > mailing list to cc. > > I am sorry but I'm confused about this. It's a very terse explanation > of the problem and a bunch of code. > > Can you folks please define what exactly you mean with a > "GPIO passthrough" and what you are trying to achieve with > this on these buttons? On the Aspeed BMC SoCs, several GPIO banks (D and E) can be configured so the pins in the low half of a bank of 8 pins are input, and the pins in the high half of the bank are output. The line state of pins 0 <= i < 4 is reflected on pin i + 4. This way it appears as though the BMC is not present in the circuit. This is useful when the BMC may not have firmware of its own, or if it does, if the BMC firmware is not required on the critical path of the host's boot process. If or when the BMC firmware boots up, it may choose to break the pass-through behaviour in order to provide its own out-of-band management capabilities. This can be used for things like a box's power button as mentioned: If the BMC is not up, poke the host directly, otherwise, poke the BMC firmware and have it poke the host. The pass-through settings are tied to the SoC's pinmux. Intuitively it should be integrated into the pinmux driver, but IIRC there was some ugly coupling of the function that didn't have a neat solution with the currently-separate GPIO and pinmux drivers. Hope that helps. Andrew