RE: Enable buttons GPIO passthrough

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux