On Tue, Mar 6, 2018 at 12:36 PM, John Garry <john.garry@xxxxxxxxxx> 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- >>> 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, 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 >>> 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. >>> >>> 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.
