[PATCH 2/2] ahci: only attach ICH6-M if it's in SATA mode

[PATCH 2/2] ahci: only attach ICH6-M if it's in SATA mode

[Paul Bolle]

Intel's ICH6-M can operate either in IDE mode or in SATA mode. Attaching
in IDE mode is pointless (and should fail, as long as BIOS has configured
it even remotely sane). So let's only attach in SATA mode.

Note that ata_piix does the opposite: only attach if ICH6-M is in IDE
mode, so we end up with just one driver attaching in either mode.

(And since we're touching this table update a minor typo too.)

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Tested on an ICH6-M that always runs in IDE mode. So I'm not certain
this does the right thing for a ICH6-M running in SATA mode. 

 drivers/ata/ahci.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 4ba3bde..12182fd 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -191,8 +191,10 @@ static const struct ata_port_info ahci_port_info[] = {
 
 static const struct pci_device_id ahci_pci_tbl[] = {
 	/* Intel */
-	{ PCI_VDEVICE(INTEL, 0x2652), board_ahci }, /* ICH6 */
-	{ PCI_VDEVICE(INTEL, 0x2653), board_ahci }, /* ICH6M */
+	{ PCI_VDEVICE(INTEL, 0x2652), board_ahci }, /* ICH6R */
+	/* ICH6M Attach iff the controller is in SATA mode. */
+	{ PCI_VENDOR_ID_INTEL, 0x2653, PCI_ANY_ID, PCI_ANY_ID,
+	  PCI_CLASS_STORAGE_SATA << 8, 0xffff00, board_ahci },
 	{ PCI_VDEVICE(INTEL, 0x27c1), board_ahci }, /* ICH7 */
 	{ PCI_VDEVICE(INTEL, 0x27c5), board_ahci }, /* ICH7M */
 	{ PCI_VDEVICE(INTEL, 0x27c3), board_ahci }, /* ICH7R */
-- 
1.8.1.4

Re: [PATCH 2/2] ahci: only attach ICH6-M if it's in SATA mode

[Tejun Heo]

Hello, Paul.

On Mon, Dec 16, 2013 at 11:34:57AM +0100, Paul Bolle wrote:
> Intel's ICH6-M can operate either in IDE mode or in SATA mode. Attaching
> in IDE mode is pointless (and should fail, as long as BIOS has configured
> it even remotely sane). So let's only attach in SATA mode.
> 
> Note that ata_piix does the opposite: only attach if ICH6-M is in IDE
> mode, so we end up with just one driver attaching in either mode.
> 
> (And since we're touching this table update a minor typo too.)
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> Tested on an ICH6-M that always runs in IDE mode. So I'm not certain
> this does the right thing for a ICH6-M running in SATA mode. 
> 
>  drivers/ata/ahci.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 4ba3bde..12182fd 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -191,8 +191,10 @@ static const struct ata_port_info ahci_port_info[] = {
>  
>  static const struct pci_device_id ahci_pci_tbl[] = {
>  	/* Intel */
> -	{ PCI_VDEVICE(INTEL, 0x2652), board_ahci }, /* ICH6 */
> -	{ PCI_VDEVICE(INTEL, 0x2653), board_ahci }, /* ICH6M */
> +	{ PCI_VDEVICE(INTEL, 0x2652), board_ahci }, /* ICH6R */
> +	/* ICH6M Attach iff the controller is in SATA mode. */
> +	{ PCI_VENDOR_ID_INTEL, 0x2653, PCI_ANY_ID, PCI_ANY_ID,
> +	  PCI_CLASS_STORAGE_SATA << 8, 0xffff00, board_ahci },

I'm not quite sure about this one.  The patch seems correct on the
surface but given how old ich6 is at this point, the general
crappiness of BIOS on ahci front in that era, and that the existing
code has been working fine for all these years make me very reluctant
to change it.  e.g. I don't think CLASS_STORAGE_SATA was the only one.
They used different class for raid too.  It should be able to figure
out things given enough test cases but I don't think we have that
anymore and the benefit (avoding probe failure messages) doesn't seem
to justify the risk.

Thanks.

-- 
tejun

Re: [PATCH 2/2] ahci: only attach ICH6-M if it's in SATA mode

[Levente Kurusa]

On 12/16/2013 04:51 PM, Tejun Heo wrote:
> Hello, Paul.
> 
> On Mon, Dec 16, 2013 at 11:34:57AM +0100, Paul Bolle wrote:
>> Intel's ICH6-M can operate either in IDE mode or in SATA mode. Attaching
>> in IDE mode is pointless (and should fail, as long as BIOS has configured
>> it even remotely sane). So let's only attach in SATA mode.
>>
>> Note that ata_piix does the opposite: only attach if ICH6-M is in IDE
>> mode, so we end up with just one driver attaching in either mode.
>>
>> (And since we're touching this table update a minor typo too.)
>>
>> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
>> ---
>> Tested on an ICH6-M that always runs in IDE mode. So I'm not certain
>> this does the right thing for a ICH6-M running in SATA mode. 
>>
>>  drivers/ata/ahci.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
>> index 4ba3bde..12182fd 100644
>> --- a/drivers/ata/ahci.c
>> +++ b/drivers/ata/ahci.c
>> @@ -191,8 +191,10 @@ static const struct ata_port_info ahci_port_info[] = {
>>  
>>  static const struct pci_device_id ahci_pci_tbl[] = {
>>  	/* Intel */
>> -	{ PCI_VDEVICE(INTEL, 0x2652), board_ahci }, /* ICH6 */
>> -	{ PCI_VDEVICE(INTEL, 0x2653), board_ahci }, /* ICH6M */
>> +	{ PCI_VDEVICE(INTEL, 0x2652), board_ahci }, /* ICH6R */
>> +	/* ICH6M Attach iff the controller is in SATA mode. */
>> +	{ PCI_VENDOR_ID_INTEL, 0x2653, PCI_ANY_ID, PCI_ANY_ID,
>> +	  PCI_CLASS_STORAGE_SATA << 8, 0xffff00, board_ahci },
> 
> I'm not quite sure about this one.  The patch seems correct on the
> surface but given how old ich6 is at this point, the general
> crappiness of BIOS on ahci front in that era, and that the existing
> code has been working fine for all these years make me very reluctant
> to change it.  e.g. I don't think CLASS_STORAGE_SATA was the only one.
> They used different class for raid too.  It should be able to figure
> out things given enough test cases but I don't think we have that
> anymore and the benefit (avoding probe failure messages) doesn't seem
> to justify the risk.

Not only they use different class IDs, but IIRC they also change device ids.
For example, ICH7M was 0x27C4 in AHCI mode and 0x27DF in IDE mode. (obviously
Intel vendor ids)

Paul, did this patch change anything noticeable for you? I mean was there any
problem before that this patch fixes or not?


-- 
Regards,
Levente Kurusa

Re: [PATCH 2/2] ahci: only attach ICH6-M if it's in SATA mode

[Paul Bolle]

On Mon, 2013-12-16 at 18:28 +0100, Levente Kurusa wrote:
> Not only they use different class IDs, but IIRC they also change device ids.
> For example, ICH7M was 0x27C4 in AHCI mode and 0x27DF in IDE mode. (obviously
> Intel vendor ids)

Apparently ICH6-M always uses device ID 0x2653 for its SATA "function"
(whether in SATA mode or in IDE mode).

> Paul, did this patch change anything noticeable for you? I mean was there any
> problem before that this patch fixes or not?

What triggered these two patches was the warning I quoted in patch 1/2
(which Tejun already queued). Looking at the code involved raised the,
obvious, question why ahci bothers to attach to ICH6-M in IDE mode.
Anyhow, the only problem is that it unsuccessfully probes when ICH6-M is
in IDE mode. The probe doesn't break things, as far as I can tell.


Paul Bolle

Re: [PATCH 2/2] ahci: only attach ICH6-M if it's in SATA mode

[Paul Bolle]

On Mon, 2013-12-16 at 10:51 -0500, Tejun Heo wrote:
> I'm not quite sure about this one.  The patch seems correct on the
> surface but given how old ich6 is at this point, the general
> crappiness of BIOS on ahci front in that era, and that the existing
> code has been working fine for all these years make me very reluctant
> to change it.  e.g. I don't think CLASS_STORAGE_SATA was the only one.
> They used different class for raid too.

Well, raid should only be relevant for ICH6R (which has its own device
ID). The datasheet I've been staring at suggests that ICH6-M is
hardwired to either use PCI_CLASS_STORAGE_SATA or PCI_CLASS_STORAGE_IDE.

> It should be able to figure
> out things given enough test cases but I don't think we have that
> anymore and the benefit (avoding probe failure messages) doesn't seem
> to justify the risk.

That's your call, obviously. And I don't think that hardware like this
is used widely to run release candidates, if at all, so we can't even
consider a see-who-screams-when-their-setup-breaks approach.

Thanks,


Paul Bolle