Re: SVN rev 206755 breakage

Rui Paulo wrote:
> On 18 Apr 2010, at 14:05, Alexander Motin wrote:
>> Most of AHCI controllers could also work as usual PCI ATA, but not every
>> PCI ATA could work as AHCI. It would be nice to compare `pciconf -lvbc`
>> output in both working (Rui) and not working (Michael) cases.
> 
> ahci0_at_pci0:0:31:2:	class=0x01018f card=0x72708086 chip=0x27c48086 rev=0x02 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller'
>     class      = mass storage
>     subclass   = ATA

                   ^^^
It doesn't report itself as AHCI.

>     bar   [10] = type I/O Port, range 32, base 0x20d8, size  8, enabled
>     bar   [14] = type I/O Port, range 32, base 0x20fc, size  4, enabled
>     bar   [18] = type I/O Port, range 32, base 0x20d0, size  8, enabled
>     bar   [1c] = type I/O Port, range 32, base 0x20f8, size  4, enabled
>     bar   [20] = type I/O Port, range 32, base 0x2020, size 16, enabled
>     bar   [24] = type Memory, range 32, base 0x90445000, size 1024, enabled

This resource (BAR(5)) is absent on Michael's system. It is needed to
work in AHCI mode, but not required for legacy PCI ATA. Probably some
kind of BIOS magic in your case makes it appear in this mode with this
chip ID.
On ICH8 and above in non-AHCI mode BAR(5) is also present, but with
different meaning (access to some SATA registers). So it may be
difficult to distinguish what exactly we have there.

>     cap 01[70] = powerspec 2  supports D0 D3  current D0
> 
> BTW, Mac OS X also uses AHCI on this controller.

I think Mac OS X is very special beast, which could easily be tuned for
their specific hardware.

So I think either your patch should be either reverted, or somehow
improved to check presence of BAR(5) and may be something else on probe
stage, but IMHO it's a kind of magic and I wouldn't be doing so.

-- 
Alexander Motin