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
