On Monday 25 January 2016 15:43:00 Tejun Heo wrote:

On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote:

quoted

AMD Seattle SATA controller mostly conforms to AHCI interface with some
special register to control SGPIO interface. In the case of an AHCI
controller, the SGPIO feature is ideally implemented using the
"Enclosure Management" register of the AHCI controller, but those
registeres are not implemented in the Seattle SoC. Instead SoC
(Rev B0 onwards) provides a 32-bit SGPIO control register which should
be programmed to control the activity, locate and fault LEDs.

The driver is based on ahci_platform driver.

Signed-off-by: Brijesh Singh <redacted>
Acked-by: Hans de Goede <redacted>
CC: tj@kernel.org
CC: linux-ide@vger.kernel.org

Hans, can you please review the patch?

I think it needs more work: The changelog describes it as a normal
driver, but based on the previous discussion, this is just a hack
to work around broken BIOS versions that can no longer be fixed in
the field, and there has not been a decision what the proper
representation should be in ACPI.

The patch also fails to address the devicetree based case, even though
we did come to a conclusion that the current behavior is a regression
(compared to what we had in drivers/ide/) and that there is a relatively
simple fix to do it right.

I'd rather see this problem solved for DT first and then have a
discussion about what the ACPI binding should look like, with
a review from ACPI folks before this hack gets cemented in the kernel.

	Arnd