Messages in this thread | | | Subject | Re: [PATCH v16 0/9] LPC: legacy ISA I/O support | From | John Garry <> | Date | Tue, 13 Mar 2018 10:42:22 +0000 |
| |
On 13/03/2018 10:22, Rafael J. Wysocki wrote: > On Tue, Mar 6, 2018 at 5:22 PM, John Garry <john.garry@huawei.com> wrote: >>>>>> >>>>>> 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 >>> >>> >> >> Hi Rafael, >> >>> Well, the only sort-of concern is that these devices may not be >>> "serial bus slaves" in general, so the naming is slightly confusing. >>> >> >> Right, the name. >> >> The key point is that we model the bus the same as other serial buses like >> I2C or SPI, so require the same treatment from the ACPI scan. >> >> Would you prefer acpi_is_serial_bus_slave() and >> acpi_device_flags.serial_bus_slave symbols be modified also? > > Yeah, preferably. > > You can rename them to acpi_device_enumeration_by_parent() and > acpi_device_flags.enumeration_by_parent, respectively, as far as I'm > concerned. > > At least the names would match the purpose then. :-) > > And please update the comment in acpi_default_enumeration() while at it.
Hi Rafael,
That should be ok. I can just add this mentioned modification to my series and send for review.
All the best, John
> > . >
| |