Hi Linus, User space supporting is necessary in OpenBMC. OpenBMC has to support IPMI command(user space network command) to dynamically disable/enable all the buttons in the front panel of a server, which need pass-through to support be disabled/enabled dynamically in the user space. Once pass-through of power/reset button is enabled, IPMI command cannot handle the power any more. So correct logic should be that pass-through of buttons is enabled by default, once OpenBMC got the related ipmi command (like power on/off/reset/disable front panel command), disable pass-through firstly, do the corresponding operation and then enable pass-through back. Thanks, Kwin. -----Original Message----- From: Linus Walleij [mailto:linus.walleij@xxxxxxxxxx] Sent: Monday, February 11, 2019 4:08 PM To: Andrew Jeffery <andrew@xxxxxxxx> Cc: Wang, Kuiying <kuiying.wang@xxxxxxxxx>; Joel Stanley <joel@xxxxxxxxx>; Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxx>; open list:GPIO SUBSYSTEM <linux-gpio@xxxxxxxxxxxxxxx>; Andrew Geissler <geissonator@xxxxxxxxx>; OpenBMC Maillist <openbmc@xxxxxxxxxxxxxxxx>; Mauery, Vernon <vernon.mauery@xxxxxxxxx>; Feist, James <james.feist@xxxxxxxxx>; Yoo, Jae Hyun <jae.hyun.yoo@xxxxxxxxx>; Nguyen, Hai V <hai.v.nguyen@xxxxxxxxx>; Khetan, Sharad <sharad.khetan@xxxxxxxxx>; Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> Subject: Re: Enable buttons GPIO passthrough On Mon, Feb 11, 2019 at 5:54 AM Andrew Jeffery <andrew@xxxxxxxx> wrote: > On Fri, 8 Feb 2019, at 22:31, Linus Walleij wrote: > > > +static int aspeed_gpio_pass_through(struct gpio_chip *chip, unsigned int offset, > > > + unsigned long usecs) { > > > + printk("kwin::aspeed_gpio_pass_through is called"); > > > + return 0; > > > +} > > > > I guess you want to actually implement this too :D > > Something to keep in mind is that the ASPEED pinctrl already supports > configuring the passthrough bits. What we don't want is to cause some > inconsistent state between the GPIO and pinmux subsystems by just whacking the bits directly. > > Looks like we should be able to make it work with PIN_MAP_MUX_GROUP() > and using some custom name for the state (maybe "passthrough")? It's a > half-baked thought though so I'm not sure if it's feasible let alone > acceptable, but hopefully Linus can comment. Since its a real odd thing this "passthrough" I would certainly prefer if you could keep it as a custom thing on the pin control side of things. Then I suppose that you set it up using the device tree and all is fine? What I'd like to hear from Kwin is a convincing story why Aspeed SoCs need to do this from userspace, as that seems to be his goal. Yours, Linus Walleij