[PATCH v1] ata: ahci_xgene: Add AHCI Support for second generation of APM X-Gene SoC

[Mark Rutland]

On Wed, Apr 01, 2015 at 06:00:33PM +0100, Catalin Marinas wrote:
> On Wed, Apr 01, 2015 at 05:39:56PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Apr 01, 2015 at 12:31:16PM -0400, Tejun Heo wrote:
> > > On Wed, Apr 01, 2015 at 12:13:36PM -0400, Tejun Heo wrote:
> > > > > Signed-off-by : Suman Tripathi <stripathi at apm.com>
> > > > 
> > > > Applied to libata/for-4.1 w/ minor edit.
> > > 
> > > Reverted due to build failure from missing asm/cputype.h.
> > 
> > I'm guessing this is some kind of ARM driver, which is why
> > linux-arm-kernel has been Cc'd - though I haven't seen the original
> > patch.
> > 
> > ARM has asm/cputype.h, and has had for a long time, so "missing
> > asm/cputype.h" doesn't make sense as a reason to revert it.  Maybe
> > it's trying to be built on x86 when it should be restricted to
> > only ARM?
> > 
> > Dunno without seeing the original patch.
> 
> First search result leads here:
> 
> https://www.mail-archive.com/devicetree@vger.kernel.org/msg67774.html
> 
> The driver in general should not be ARM specific, though it runs on an
> ARMv8 platform. But looking at the patch it has some errata workarounds
> triggered based on the CPU id (MIDR). That looks dodgy as it doesn't
> even check the full ID, only the variant part.
> 
> But if they don't have any other way of identifying the hardware
> version (ideally some SoC or device identification), the driver should
> at least be made dependent on ARM64. Looking at the Kconfig entries,
> PHY_XGENE depends on (ARM64 || COMPILE_TEST). The COMPILE_TEST part
> should be dropped (I would still prefer a different way to handle this
> than checking MIDR but I'm not familiar with the hardware).

We should just add a new compatible string for the new revision of the
AHCI controller. Given the errata we're avoiding apply to the AHCI
controller and not the CPU, looking at the CPU ID is nonsense.

Mark.