Hi Matthew, On Thu, Mar 03, 2016 at 05:45:35PM +0000, Matthew Garrett wrote: > On Thu, Mar 03, 2016 at 12:47:40PM +0100, Lukas Wunner wrote: > > > I think you want to add a quirk to spi.c:acpi_spi_add_device() > > which checks if acpi_dev_get_resources() returned nothing and > > the HID of the acpi_device is APP000D: Search the namespace below > > the acpi_device's handle for _CRS.UBUF (using acpi_get_handle()). > > If this exists, call acpi_walk_resource_buffer() on it (with the > > acpi_spi_add_resource callback). You need to somehow convert the > > acpi_handle to an acpi_buffer, maybe that just involves filling in > > acpi_buffer->pointer = acpi_handle and somehow determining the > > length of the resource settings from the handle. Someone more > > intimately familiar with the layout of the namespace in memory > > should be able to answer this. Hopefully this will already get > > you started, if not just ask questions. > > If Apple are consistently using this mechanism to define resources, do > we want to extend acpi_dev_get_resources to attempt to call the _DSM > method as well? What Apple is doing with their _DSM is functionally equivalent to the _DSD (Device Specific Data) method in the ACPI spec. (Apple isn't using _DSD at all.) We could extend drivers/acpi/property.c:acpi_init_properties() to check if dmi_match(DMI_BOARD_VENDOR, "Apple Inc."), and instead of calling _DSD, call _DSM with Apple's UUID and populate adev->data with that. Or add the properties to the existing data, if any. Then whenever we feel the need we could just retrieve Apple's properties with acpi_dev_get_property(). E.g. in the case of this SPI slave we need to fill in five values of struct spi_device and we would add a quirk for APP000D which retrieves each value via acpi_dev_get_property() instead of acpi_dev_get_resources(). Alternatively we could evaluate the _DSM individually from the quirk and obtain the values we need from the returned package. But being able to get them with acpi_dev_get_property() might be more generic, it's not unlikely that we need to retrieve Apple's properties from other quirks as well. The suggestion I made in my previous e-mail (to fetch UBUF) was probably not so great in terms of maintainability since Apple might change the name of the variable in a future version of the DSDT, or on other machines. Best regards, Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
