lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B4DFE1A.4000606@pobox.com>
Date:	Wed, 13 Jan 2010 12:08:42 -0500
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Krzysztof Halasa <khc@...waw.pl>
CC:	Robert Hancock <hancockrwd@...il.com>,
	Seth Heasley <seth.heasley@...el.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.32.3] ahci: AHCI and RAID mode SATA patch for Intel
 Cougar Point DeviceIDs

On 01/13/2010 10:15 AM, Krzysztof Halasa wrote:
> Jeff Garzik<jgarzik@...ox.com>  writes:
>
>> Well, two lines of thinking here:
>>
>> * some of lines of Intel chips do not separate AHCI into a separate
>> PCI ID rather legacy IDE interface.  When an AHCI interface exists and
>> AHCI/IDE share the same PCI ID, we default to using AHCI.  Thus, some
>> of those PCI ID matches in ahci.c's PCI table may not get caught by
>> the generic PCI class match at the end of the table.
>>
>> * the cost carrying redundant PCI IDs seems low, harmless, and
>> potentially helpful.
>
> Also people may use things like this:
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index a3241a1..0616bbb 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -561,9 +561,11 @@ static const struct pci_device_id ahci_pci_tbl[] = {
>   	{ PCI_VDEVICE(INTEL, 0x3b2c), board_ahci }, /* PCH RAID */
>   	{ PCI_VDEVICE(INTEL, 0x3b2f), board_ahci }, /* PCH AHCI */
>
> +#ifdef DOESNT_WORK_FOR_ME
>   	/* JMicron 360/1/3/5/6, match class to avoid IDE function */
>   	{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
>   	  PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci_ign_iferr },
> +#endif
>
>   	/* ATI */
>   	{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 */
> @@ -667,9 +669,11 @@ static const struct pci_device_id ahci_pci_tbl[] = {
>   	/* Promise */
>   	{ PCI_VDEVICE(PROMISE, 0x3f20), board_ahci },	/* PDC42819 */
>
> +#ifdef DOESNT_WORK_FOR_ME
>   	/* Generic, PCI class code for AHCI */
>   	{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
>   	  PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci },
> +#endif
>

I'm not sure I understand your point.  Are there ahci problems with the 
generic entries, that remain unresolved?

	Jeff




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ