[PATCH v9 5/7] ACPI: Translate the I/O range of non-MMIO devices before scanning
From: mika.westerberg@linux.intel.com (Mika Westerberg)
Date: 2017-06-13 20:03:49
Also in:
linux-acpi, linux-pci, lkml
On Tue, Jun 13, 2017 at 07:01:38PM +0000, Gabriele Paoloni wrote:
I am not very familiar with Linux MFD however the main issue here is that
1) for IPMI we want to re-use the standard IPMI driver without touching it:
see
static const struct acpi_device_id acpi_ipmi_match[] = {
{ "IPI0001", 0 },
{ },
};
in "drivers/char/ipmi/ipmi_si_intf.c" (and in general any standard driver
of an LPC child)
2) We need a way to guarantee that all LPC children are not enumerated
by acpi_default_enumeration() (so for example if an ipmi node is an LPC#
child it should not be enumerated, otherwise it should be)
Currently acpi_default_enumeration() skips spi/i2c slaves by checking:
1) if the acpi resource type is a serial bus
2) if the type of serial bus descriptor is I2C or SPI
For LPC we cannot leverage on any ACPI property to "recognize" that our
devices are LPC children; hence before I proposed for acpi_default_enumeration()
to skip devices that have already been enumerated (by calling
acpi_device_enumerated() ).
So in the current scenario, how do you think that MFD can help?If you look at Documentation/acpi/enumeration.txt there is a chapter "MFD devices". I think it pretty much maches what you have here. An LPC device (MFD device) and bunch of child devices. The driver for your LPC device can specify _HID for each child device. Those are then mached by the MFD ACPI code to the corresponding ACPI nodes from which platform devices are created including "IPI0001". It causes acpi_default_enumeration() to be called but it should be fine as we are dealing with platform device anyway. Once the platform device is created your ipmi driver will be probed by the driver core. Does that make sense?