Hi all,
According to PCI 3.0 spec, ACHI's PCI class code is 0x010601,
and I suggest the ahci driver had better try to claim all ahci
controllers, pls see the following patch:
diff -Nur linux-2.6.17/drivers/scsi/ahci.c
linux-2.6.17-ahci/drivers/scsi/ahci.c
--- linux-2.6.17/drivers/scsi/ahci.c 2006-06-18 09:49:35.000000000
+0800
+++ linux-2.6.17-ahci/drivers/scsi/ahci.c 2006-10-31
22:50:54.000000000 +0800
@@ -296,6 +296,11 @@
board_ahci }, /* ATI SB600 non-raid */
{ PCI_VENDOR_ID_ATI, 0x4381, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_ahci }, /* ATI SB600 raid */
+ /* Claim all AHCI controllers not listed above.
+ * According to PCI 3.0, AHCI's class code is 0x010601
+ */
+ { PCI_AND_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0x010601,
0xffffff,
+ board_ahci },
{ } /* terminate list */
};
Best regards,
Conke @ AMD, Inc.
On Wed, 1 Nov 2006, Jeff Garzik wrote:
>
> For the benefit of others, some background: we should not be -removing- any
> PCI IDs due to this, because quite often the PCI class code will be RAID or
> something else, yet still be drive-able with this ahci driver.
Well, it might obviously be worthwhile removing the PCI ID's that actually
do say that they are AHCI. Maybe that's not all of them, but I wouldn't be
surprised if it's actually the majority of them..
(We had the same issue with "PCI IDE controller". Some PCI IDE controllers
are clearly exactly that from a programming interface standpoint, but
because they support RAID in hardware, they claim to be RAID controllers,
since that is more "glamorous". Gaah ;^).
Linus
Conke Hu wrote:
> Hi all,
> According to PCI 3.0 spec, ACHI's PCI class code is 0x010601,
> and I suggest the ahci driver had better try to claim all ahci
> controllers, pls see the following patch:
>
> diff -Nur linux-2.6.17/drivers/scsi/ahci.c
> linux-2.6.17-ahci/drivers/scsi/ahci.c
> --- linux-2.6.17/drivers/scsi/ahci.c 2006-06-18 09:49:35.000000000
> +0800
> +++ linux-2.6.17-ahci/drivers/scsi/ahci.c 2006-10-31
> 22:50:54.000000000 +0800
> @@ -296,6 +296,11 @@
> board_ahci }, /* ATI SB600 non-raid */
> { PCI_VENDOR_ID_ATI, 0x4381, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> board_ahci }, /* ATI SB600 raid */
> + /* Claim all AHCI controllers not listed above.
> + * According to PCI 3.0, AHCI's class code is 0x010601
> + */
> + { PCI_AND_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0x010601,
> 0xffffff,
> + board_ahci },
> { } /* terminate list */
> };
Since things have settled in this area, yes, this would probably be a
good thing to add.
For the benefit of others, some background: we should not be -removing-
any PCI IDs due to this, because quite often the PCI class code will be
RAID or something else, yet still be drive-able with this ahci driver.
Jeff
Conke Hu wrote:
> Hi all,
> According to PCI 3.0 spec, ACHI's PCI class code is 0x010601,
> and I suggest the ahci driver had better try to claim all ahci
> controllers, pls see the following patch:
BTW, make sure to always include a Signed-off-by: line in every patch.
See http://linux.yyz.us/patch-format.html and
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt and
Documentation/SubmittingPatches (in the kernel source tree).
Jeff
Linus Torvalds wrote:
>
> On Wed, 1 Nov 2006, Jeff Garzik wrote:
>> For the benefit of others, some background: we should not be -removing- any
>> PCI IDs due to this, because quite often the PCI class code will be RAID or
>> something else, yet still be drive-able with this ahci driver.
>
> Well, it might obviously be worthwhile removing the PCI ID's that actually
> do say that they are AHCI. Maybe that's not all of them, but I wouldn't be
> surprised if it's actually the majority of them..
The same PCI ID maps to either RAID or AHCI. The PCI ID only changes
when it's no longer in AHCI mode (IDE/legacy mode).
To confuse matters even further, sometimes you can use AHCI even though
it claims it is in IDE mode. And the reverse is -often- true: you can
usually use legacy IDE mode even if the PCI ID and class code claim AHCI
mode.
Who knows what beasts lurk behind the same PCI ID...
> (We had the same issue with "PCI IDE controller". Some PCI IDE controllers
> are clearly exactly that from a programming interface standpoint, but
> because they support RAID in hardware, they claim to be RAID controllers,
> since that is more "glamorous". Gaah ;^).
Heck these days 'RAID' is a marketing requirement for your hardware,
regardless of its capabilities...
Jeff
Ar Maw, 2006-10-31 am 21:22 -0800, ysgrifennodd Linus Torvalds:
> (We had the same issue with "PCI IDE controller". Some PCI IDE controllers
> are clearly exactly that from a programming interface standpoint, but
> because they support RAID in hardware, they claim to be RAID controllers,
> since that is more "glamorous". Gaah ;^).
Actually its far uglier than that. With one exception they don't support
hardware raid mode, they use the RAID class tag to stop other OS drivers
grabbing the interface or seeing it directly as un-raided software raid.
Alan
Thank you, Jeff.
But who should be the "Signed-off-by" man when I create a patch and ready for sending it to kernel org?
Best regards,
Conke @ AMD, Inc.
-----Original Message-----
From: Jeff Garzik [mailto:[email protected]]
Sent: 2006??11??1?? 13:11
To: Conke Hu
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: AHCI should try to claim all AHCI controllers
Conke Hu wrote:
> Hi all,
> According to PCI 3.0 spec, ACHI's PCI class code is 0x010601,
> and I suggest the ahci driver had better try to claim all ahci
> controllers, pls see the following patch:
BTW, make sure to always include a Signed-off-by: line in every patch.
See http://linux.yyz.us/patch-format.html and
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt and
Documentation/SubmittingPatches (in the kernel source tree).
Jeff
Alan Cox wrote:
> Ar Maw, 2006-10-31 am 21:22 -0800, ysgrifennodd Linus Torvalds:
>> (We had the same issue with "PCI IDE controller". Some PCI IDE controllers
>> are clearly exactly that from a programming interface standpoint, but
>> because they support RAID in hardware, they claim to be RAID controllers,
>> since that is more "glamorous". Gaah ;^).
>
> Actually its far uglier than that. With one exception they don't support
> hardware raid mode, they use the RAID class tag to stop other OS drivers
> grabbing the interface or seeing it directly as un-raided software raid.
Note that a lot of the software raid controllers actually have full
hardware RAID acceleration in the chipset (single block command is automatically
remapped across several drives of a RAID 0/1/10 configuration, reducing bus
transactions and bandwidth requirements.
But they still require a driver do perform the RAID management,
and are thus not true "hardware" RAID. But they are higher on the
food chain than total "pretend" RAID devices.
Cheers
hoi :)
On Wed, Nov 01, 2006 at 09:39:23PM +0800, Conke Hu wrote:
> But who should be the "Signed-off-by" man when I create a patch and ready for sending it to kernel org?
yourself.
Please look into Documentation/SubmittingPatches paragraph 11.
--
Martin Waitz