The fby35 OpenBMC sysvinit scripts check various GPIO pins at start and
decide where to start IPMB daemons for each slot in the sled (4 slots max).
It only starts an IPMB daemon if the slot GPIO pins indicate that it's
present and powered on.

I've been simulating some input pins by setting their value in the machine
reset function. I think a proper solution would be to add input pins to the
Aspeed GPIO code and create devices that force the pins high or low
appropriately, but for now setting the QOM property seemed fine.

But, I noticed that while the values were set initially, something in the
boot process resets all the values I set to "low". I imagine something in
userspace or the driver is blanket writing zero to the data registers. I
think the Aspeed GPIO controller probably shouldn't be changing the value of
input pins in this case.

To fix this, we could just make sure that aspeed_gpio_update() never sets
the value of an input pin. However, that would also prevent my code in
fby35_reset from initializing the input pins to some special value. So, to
support the QOM property setup use-case, I added a "force" parameter. Kinda
hacky, but it was the simplest thing I could think of.

Thanks,
Peter

Peter Delevoryas (2):
  hw/gpio/aspeed: Don't let guests modify input pins
  aspeed: Add fby35-bmc slot GPIO's

 hw/arm/aspeed.c       | 14 +++++++++++++-
 hw/gpio/aspeed_gpio.c | 22 ++++++++++++----------
 2 files changed, 25 insertions(+), 11 deletions(-)

-- 
2.36.1