From: Robert Hancock <hancockr@shaw.ca>
To: Alan <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, jeff@garzik.org
Subject: Re: [PATCH] pata_acpi: take two
Date: Wed, 07 Feb 2007 23:12:05 -0600 [thread overview]
Message-ID: <45CAB125.7000907@shaw.ca> (raw)
In-Reply-To: <fa.E0XxdpTYuPtTLgPLQYHs2V10jM4@ifi.uio.no>
Alan wrote:
> --- linux.vanilla-2.6.20-rc6-mm3/drivers/ata/pata_amd.c 2007-01-31 14:20:10.000000000 +0000
> +++ linux-2.6.20-rc6-mm3/drivers/ata/pata_amd.c 2007-02-06 17:04:19.000000000 +0000
> @@ -642,6 +642,11 @@
> if (type == 1 && rev > 0x7)
> type = 2;
>
> +#if defined(CONFIG_ATA_ACPI)
> + /* Prefer the ACPI driver for Nvidia hardware */
> + if (pdev->vendor == PCI_VENDOR_ID_NVIDIA && ata_pata_acpi_present(pdev))
> + return -ENODEV;
> +#endif
> /* Check for AMD7411 */
> if (type == 3)
> /* FIFO is broken */
Problem with this approach is it may break distro/initrd setups since
the pata_amd driver appears to be the one that "should" work based on
the PCI ID, so the initrd would end up containing only this driver,
which will fail out with -ENODEV and cause a boot failure. If the root
filesystem was on a disk driven by this controller, the mkinitrd stuff
would have to "know" that it should also try loading pata_acpi.
Unless there are some Nvidia boxes out there which don't provide
_GTM/_STM ACPI methods (which seems a bit unlikely given Allen Martin's
comments) then we could potentially move the Nvidia PATA PCI IDs into
the pata_acpi driver, at least if ACPI is enabled in the kernel build..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
next parent reply other threads:[~2007-02-08 5:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.E0XxdpTYuPtTLgPLQYHs2V10jM4@ifi.uio.no>
2007-02-08 5:12 ` Robert Hancock [this message]
2007-02-09 20:18 ` [PATCH] pata_acpi: take two Alan
2007-02-07 17:22 Alan
2007-02-07 20:38 ` Mariusz Kozlowski
2007-02-08 0:30 ` Andrew Morton
2007-02-09 20:13 ` Alan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45CAB125.7000907@shaw.ca \
--to=hancockr@shaw.ca \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.