From: Gabriele Paoloni
> Sent: 27 October 2017 17:11
> This patchset supports the IPMI-bt device attached to the Low-Pin-Count
> interface implemented on Hisilicon Hip06/Hip07 SoC.
> -----------
> | LPC host|
> | |
> -----------
> |
> _____________V_______________LPC
> | |
> V V
> ------------
> | BT(ipmi)|
> ------------
>
> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a specific
> LPC driver is needed to make LPC host generate the standard LPC I/O cycles
> with
> the target peripherals'I/O port addresses. But on curent arm64 world, there is
> no real I/O accesses. All the I/O operations through in/out accessors are
> based
> on MMIO ranges; on Hip06/Hip07 LPC the I/O accesses are performed through
> driver
> specific accessors rather than MMIO.
> To solve this issue and keep the relevant existing peripherals' drivers
> untouched,
> this patchset:
> - introduces a generic I/O space management framework, LIBIO, to support
> I/O
> operations on host controllers operating either on MMIO buses or on buses
> requiring specific driver I/O accessors;
> - redefines the in/out accessors to provide a unified interface for both
> MMIO
> and driver specific I/O operations. Using LIBIO, th call of in/out() from
> the host children drivers, such as ipmi-si, will be redirected to the
> corresponding device-specific I/O hooks to perform the I/O accesses.
>
> Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals
> can
> be supported without any changes on the existing ipmi-si driver.
FWIW my thoughts on this are WTF!
Looks to me horribly over complicated and over generalised.
Surely is it could be done the same way that x86 does IO cycles?
So you encode the information into the 'address' the driver passes
to ioread16() (etc) to allow it to do either a normal bus cycle or
the indirect cycle onto the external bus.
So you have one kernel option that makes these real functions.
David
