On Tue, Jul 5, 2016 at 2:07 AM, Graeme Gregory [off-list ref] wrote:

On Tue, Jun 21, 2016 at 04:31:38PM -0700, Suman Tripathi wrote:

quoted

Hi Arnd,

On Tue, Jun 21, 2016 at 11:08 AM, Suman Tripathi [off-list ref] wrote:

quoted

On Wed, Jun 15, 2016 at 11:54 PM, Arnd Bergmann [off-list ref] wrote:

quoted

On Wednesday, June 15, 2016 5:44:00 PM CEST suman-tripathi wrote:

quoted

This patch adds ACPI support for APM X-Gene AHCI controller in
ahci_platform driver for v3 hardware. APM X-Gene AHCI controller
v3 hardware is fully compliant with ahci_platform driver and requires
no workaround quirk.

Signed-off-by: Suman Tripathi <redacted>
---
 drivers/ata/ahci_platform.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 62a04c8..3395baf 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c

@@ -86,6 +86,7 @@ MODULE_DEVICE_TABLE(of, ahci_of_match);

 static const struct acpi_device_id ahci_acpi_match[] = {
        { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
+       { "APMC0D33", 0},
        {},
 };
 MODULE_DEVICE_TABLE(acpi, ahci_acpi_match);

Doesn't the ACPI_DEVICE_CLASS entry take care of this? I thought it had been

yeah it also works. Just thought that we need something different as
our's is a non-PCI SATA.

Are you suggesting to introduce a new class ACPI_DEVICE_CLASS for
non-pci ahci ? or to reuse the existing PCI_CLASS_STORAGE_SATA_AHCI ?

This was discussed when AMD Seattle SoC had the same issue and it was
decided in standards body and on LKML that using PCI device classes for
non PCI devices was fine.

Example from Overdrive DSDT

Device (AHC0)
{
  Name (_HID, "AMDI0600")  // _HID: Hardware ID
  Name (_UID, 0x00)  // _UID: Unique ID
  Name (_CCA, 0x01) // _CCA: Cache Coherency Attribute
  Name (_CLS,
    Package (0x03) // _CLS: Class Code
    {
      0x01,
      0x06,
      0x01
    })

Got it. Will do the same. Thanks !!

  ...

Graeme

-- 
Thanks,
with regards,
Suman Tripathi