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
