No subject

which determines whether the host can directly control the corresponding BM=
C
GPIO output, or whether BMC software can inspect and decide whether to act =
on
that request.

Another example is the Target Attached Flash Sharing (TAFS) defined by the
eSPI specification that allows BMC to share its storage with the host.

In hardware mode, the eSPI Target Device controller routes the request
directly to a predefined storage controller on AST2600.
In software mode, it raises an interrupt and lets software handle the
transaction instead.

So I would not describe the AST2600 eSPI block as being globally in either
"hardware mode" or "software mode".
That choice is made per backend function, and some backend functions do not
implement such a switch at all.

So far, this series only covers the LPC bridge and flash channel parts.

> For the higher-level interfaces (flash, gpio, ...), I don't think
> there is any consensus yet about how this should be done, but again
> I think this won't be drivers/soc but instead something more
> generic.

For the flash-related interface, would it make sense to follow the
configuration model used by the USB gadget mass-storage function, and expos=
e
the backing storage selection through configfs?=20

For the attributes, perhaps the only backing storage object and read-only
flag would be required in our case.

For the Virtual Wire GPIO, we think GPIO subsystem may be leveraged here,
though some corner cases may not map cleanly to a typical GPIO controller
model.

For the Out-of-band channel, since the eSPI spec models it for tunneled SMB=
us
packets, we may want to integrate it with the kernel's MCTP stack if that i=
s
a suitable fit.

Thanks,
Yun Hsuan