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]
Date:	Fri, 09 Nov 2007 23:04:40 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	peer chen <peerchen@...il.com>
CC:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-ide <linux-ide@...r.kernel.org>,
	akpm <akpm@...ux-foundation.org>, Kuan Luo <kluo@...dia.com>
Subject: Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv

peer chen wrote:
> Yes, link - http://lkml.org/lkml/2007/10/8/93 add the AHCI legacy
> support to sata_nv when IDE/RAID mode been set in SBIOS and Device IDs
> are not in ahci.c at this moment. To do so, when a new chipset come
> out and DIDs haven't been submited to LKML,user still can use ahci
> driver to handle it when setting AHCI mode in BIOS, using sata_nv when
> setting RAID/IDE in BIOS.
> For example, ahci driver in Fedora 7 doesn't include the DIDs of
> MCP78, so if you set the IDE/RAID mode in BIOS, os installation onto
> SATA drive will fail. But if Fedora 7 include this patch, installation
> will be successful.

The problem with this change is that sata_nv picks it up through the 
default entry, and then later on, ahci picks it up as well.

Rather than the confusion of "which driver is the user running on this 
hardware?" it is easier to take steps to ensure the user is always 
running in AHCI mode.

Therefore, I think the best idea is to follow the same policy as 
drivers/net/forcedeth.c (Ayaz @ NVIDIA) and Intel AHCI, and simply 
provide the individual PCI IDs in advance of product release.

If you wish to avoid this, then take steps to make sure 
drivers/ata/ahci.c has the appropriate wildcard entry in its 
pci_device_id table.

Really, look at the sata_nv bug reports that keep popping up.  We want 
to move away from that driver long term, and always drive the SATA 
interface in AHCI mode.

The proposed sata_nv patch does the opposite -- guarantees we must 
support the continually problematic legacy IDE interface ad infinitum. 
Such patches are OK for the test lab, but in this specific case users 
/suffer/ when not running AHCI mode.

	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