On Tue, Mar 6, 2018 at 12:36 PM, John Garry <john.ga...@huawei.com> wrote:
> On 06/03/2018 11:21, Andy Shevchenko wrote:
>> On Tue, 2018-03-06 at 18:47 +0800, John Garry wrote:
>>> This patchset supports the IPMI-bt device attached to the Low-Pin-
>>> interface implemented on Hisilicon Hip06/Hip07 SoC.
>>> | LPC host|
>>> | |
>>> | |
>>> V V
>>> | BT(ipmi)|
>>> When master accesses those peripherals beneath the Hip06/Hip07 LPC, a
>>> 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, logical PIO,
>>> 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 logical PIO, th call of
>>> in/out() from
>>> the host children drivers, such as ipmi-si, will be redirected to
>>> corresponding device-specific I/O hooks to perform the I/O
>>> 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.
>>> The whole patchset has been tested on Hip07 D05 board both using DTB
>>> and ACPI.
>>> V15 thread here: https://lkml.org/lkml/2018/2/26/584
>> Thanks for an update.
>> Though I answered to previous thread.
>> Summary: I'm fine with the series as long as maintainers are fine
>> (Rafael et al.). On personal side I think that the handler approach is
>> better. Details are in v15 thread.
> Hi Andy,
> Thanks for your input and continued support. As I mentioned in reply in v15,
> the handler support would (or has) faced issues. And Rafael seems fine with
> deferring the probe to the LLDD in Patch #7/9
Well, the only sort-of concern is that these devices may not be
"serial bus slaves" in general, so the naming is slightly confusing.
But overall this approach and the one based on a scan handler both
boil down to checking a (list of) device ID(s) and doing something
special in case of a match.