All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: jeff@garzik.org, mjg59@srcf.ucam.org, rdunlap@xenotime.net,
	trenn@suse.de, forrest.zhao@gmail.com,
	kristen.c.accardi@intel.com, lenb@kernel.org,
	linux-acpi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH 07/13] libata-acpi: add ATA_FLAG_ACPI_SATA port flag
Date: Mon, 23 Apr 2007 03:03:08 +0900	[thread overview]
Message-ID: <462BA35C.5040702@gmail.com> (raw)
In-Reply-To: <20070422185351.12adf7d8@the-village.bc.nu>

Alan Cox wrote:
> On Mon, 23 Apr 2007 02:41:06 +0900
> Tejun Heo <htejun@gmail.com> wrote:
> 
>> Whether a controller needs IDE or SATA ACPI hierarchy is determined by
>> the programming interface of the controller not by whether the
>> controller is SATA or PATA
> 
> NAK
> 
> I keep trying to point out that this is not true.
> 
> The ACPI interface to use can only be safely determined one way - and
> that is to see what methods the BIOS has attached to the device and use
> those.
> 
> Take the ACPI handle, go look for _GTF, _SDD etc and believe the
> firmware. Nothing else works.

Actually, that's dangerous.  For example, you must not do _STM/_GTM on
ahci becuase _STM/_GTM access PCI config registers which must not be
accessed in achi modes and some BIOSen supply the same _STM/_GTM nodes
whether the controller is in ata_piix mode or ahci mode.  Also, on ICH8,
the association gets quite weird due to PCI device splitting.

The ACPI spec says the layout is dependent on controller interface and I
 can see reasons why we need to follow that but not the other way
around.  Do you have counter-examples?

-- 
tejun

  reply	other threads:[~2007-04-22 18:03 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-22 17:41 [PATCHSET] libata: improve ATA ACPI support Tejun Heo
2007-04-22 17:41 ` [PATCH 02/13] libata: separate ATA_EHI_DID_RESET into DID_SOFTRESET and DID_HARDRESET Tejun Heo
2007-04-22 17:50   ` Alan Cox
2007-04-22 17:41 ` [PATCH 01/13] ahci: consolidate common port flags Tejun Heo
2007-04-22 17:49   ` Alan Cox
2007-04-28 18:51   ` Jeff Garzik
2007-04-22 17:41 ` [PATCH 03/13] libata: separate out ata_dev_reread_id() Tejun Heo
2007-04-28 18:53   ` Jeff Garzik
2007-04-29  2:52     ` Tejun Heo
2007-04-22 17:41 ` [PATCH 07/13] libata-acpi: add ATA_FLAG_ACPI_SATA port flag Tejun Heo
2007-04-22 17:53   ` Alan Cox
2007-04-22 18:03     ` Tejun Heo [this message]
2007-04-22 18:14       ` Alan Cox
2007-04-23  8:00         ` Tejun Heo
2007-04-22 18:03     ` Alan Cox
2007-04-22 18:09       ` Tejun Heo
2007-04-28 18:58   ` Jeff Garzik
2007-04-29  2:56     ` Tejun Heo
2007-04-22 17:41 ` [PATCH 04/13] libata: during revalidation, check n_sectors after device is configured Tejun Heo
2007-04-22 17:41 ` [PATCH 09/13] libata-acpi: clean up ata_acpi_exec_tfs() Tejun Heo
2007-04-28 19:00   ` Jeff Garzik
2007-04-29  2:56     ` Tejun Heo
2007-04-22 17:41 ` [PATCH 10/13] libata-acpi: miscellaneous cleanups Tejun Heo
2007-04-28 19:00   ` Jeff Garzik
2007-04-22 17:41 ` [PATCH 05/13] libata-acpi: s/CONFIG_SATA_ACPI/CONFIG_ATA_ACPI/ Tejun Heo
2007-04-28 18:54   ` Jeff Garzik
2007-04-22 17:41 ` [PATCH 06/13] libata-acpi: clean up parameters and misc stuff Tejun Heo
2007-04-28 18:55   ` Jeff Garzik
2007-04-29  2:54     ` Tejun Heo
2007-04-29  3:12       ` Jeff Garzik
2007-04-22 17:41 ` [PATCH 08/13] libata-acpi: implement ata_acpi_associate() Tejun Heo
2007-04-28 18:59   ` Jeff Garzik
2007-04-22 17:41 ` [PATCH 12/13] libata-acpi: remove redundant checks Tejun Heo
2007-04-22 17:41 ` [PATCH 11/13] libata: reimplement ACPI invocation Tejun Heo
2007-04-28 19:09   ` Jeff Garzik
2007-04-22 17:41 ` [PATCH 13/13] libata-acpi: implement _GTM/_STM support Tejun Heo
2007-04-22 18:25 ` [PATCHSET] libata: improve ATA ACPI support Alan Cox
2007-04-23  8:06   ` Tejun Heo
2007-04-23 22:05     ` Mark Lord
2007-04-23 23:03       ` Bartlomiej Zolnierkiewicz
2007-04-23 22:03   ` Mark Lord

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=462BA35C.5040702@gmail.com \
    --to=htejun@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=forrest.zhao@gmail.com \
    --cc=jeff@garzik.org \
    --cc=kristen.c.accardi@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=rdunlap@xenotime.net \
    --cc=trenn@suse.de \
    /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.