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. -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
