On Tue, Apr 05, 2016 at 02:49:13PM +0300, Octavian Purdila wrote: > If we really want to have a single path for ACPI enumeration we could > do that by using an ACPI SPI bridge driver or scan handlers after > extending the matching mechanisms. But we would still need to modify > the SPI subsystem and I don't think its worth it just to save a call > to acpi_register_spi_devices() from spi_register_master(). It's not specifically for SPI, it's the fact that you're asking every single bus type which might be described in ACPI to handle both hotplug and coldplug paths separately. Given that the code that's being added just seems like trivial boilerplate it seems like we're doing this wrong, we should be factoring this out so there's nothing bus types can get wrong. > Now for parent notification complexity: in the case of SPI we can > easily to this because current ACPI SPI enumeration supports only > direct children as slaves. However, on I2C we can have an unrelated > node as a slave - that is why the I2C scanning searches the whole > namespaces for references to a particular i2c_adapter. So, we would > need to retrieve the parent node from the namespace node information > which means that we will do SPI specific stuff in ACPI generic code. I > don't think it is a big issue, because we already treat SPI / I2C > special, right? Or perhaps the issue is that we can't make our mind up if the bus specific code should go in the bus or in the ACPI core?
Attachment:
signature.asc
Description: PGP signature
