Hi Arnd, On 02/05/2016 11:23 AM, Brijesh Singh wrote: > Hi, > >>> } >>> >>> Windows driver folks were okay to look at second resource field to map the SGPIO register and program the >>> registers to blink the LEDs. I think as per ACPI spec, its legal to pass more than one block in resource >>> template and since AML method is not mandatory for non standard enclosure management hence its entirely >>> possible that some BIOS vendors may not implement it at all. But if they implement and decide >>> to expose either AML method or register map but not both then Windows driver may break. >> >> I don't have access to the Windows source code. Is this in the >> architecture-independent part of their kernel, or only done on ARM64? >> How do they decide what the second memory range is for? >> >> If this is now a de-facto extension to the PCI_CLASS_STORAGE_SATA_AHCI binding, >> it should probably be put into the next version of the AHCI spec, and then >> there is no problem using it. >> > I don't have Windows code either and do not know the implementation details. I was told by the AMD folks > working on Windows drivers for Seattle that they do not need any changes in BIOS DSDT to get the LEDs blinking. > > This is not a de-facto extension of SATA_AHCI binding, you can call this method as a SoC hack to support the LEDs. > We are working with whatever BIOS is already available to enable the LEDs blinking. > I am not sure what I can do next, given the SoC and BIOS limitation it seems like platform driver is best choice to enable this feature. Do you have any review feedback on driver itself ? if not, then can we get this patch in? -Brijesh -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
