LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Alex Chiang <achiang@hp.com>
To: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>,
	Greg KH <gregkh@suse.de>, Jesse Barnes <jbarnes@virtuousgeek.org>,
	Matthew Wilcox <matthew@wil.cx>, Gary Hade <garyhade@us.ibm.com>,
	warthog19@eaglescrag.net, rick.jones2@hp.com,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH 4/4] ACPI PCI slot detection driver
Date: Wed, 12 Mar 2008 21:24:10 -0600	[thread overview]
Message-ID: <20080313032410.GA17561@ldl.fc.hp.com> (raw)
In-Reply-To: <47D7BF6C.3080306@jp.fujitsu.com>

Hi Kenji-san,

* Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>:
> Hi Alex-san,
>
>> On my machine, it is legal to evaluate S1F0._SUN independent of
>> S1F0._STA because L001._INI has already been evaluated.
>> It would be helpful to know what Fujitsu's namespace looks like.
>> If Fujitsu slot objects contain _STA and _INI, then I agree with
>> Kenji-san -- I definitely need to check _STA before evaluating
>> _SUN.
>
> Thank you for explanation. Maybe I understood the summary of
> implementation of HP firmware. But how to use or where to put _INI
> method in the ACPI namespace never becomes reasonable reason why
> your driver may ignore _STA before evaluating _SUN.
>
>> But in any case, I think both HP and Fujitsu firmware are doing
>> legal things -- neither firmware is breaking the spec.
>
> My understanding of your explanation so far is:
>
> - evaluating _SUN without checking _STA doesn't cause problem,
>  from the view point of HP's implementation.
> - some IBM machine is doing same as HP
>
> I never think those are reasonable reasons why ignoring _STA
> before evaluating _SUN is legal. Am I missing something?

I think the piece that I did not explain clearly is that the spec
does not require checking _STA immediately before _SUN. The spec
says: 

	- you must check _STA before calling _INI
	- _INI must be called to initialize _SUN
	- _INI is called once, when the table is loaded

On HP's implementation, we do obey those rules. We call _INI on
the PCI bridge during boot, which then initializes the children
SxFy objects. From that point on, it is legal for us to call
_SUN.

The other issue is that the spec does not specify the *semantics*
of _STA. P/IBM firmware engineers think _STA should indicate card
presence, but Fujitsu firmware engineers think _STA should
indicate slot presence.

I don't think either firmware team is incorrect -- it is simply
the case that the specification was not precise enough, to the
point where separate teams following the same spec came up with
implementations with different behaviors and different semantics.

I believe that we both have compliant, legal firmware.

>> If one list is shorter than the other, then that should be the
>> list to put in the kernel, and the default behavior should be
>> "majority rule".
>
> I don't want to consider "majority rule" before I understand why
> ignoring _STA is legal.

On HP and IBM machines, it *is* legal because we *did* call _STA,
then _INI, then _SUN. That is one interpretation of the spec.

On Fujitsu machines, the semantics of _STA are different, and it
is not legal to ignore _STA. That is another interpretation of
the spec.

Because I think we both have compliant, legal firmware, I think
the kernel should pick the most maintainable solution for the
different implementations. In my opinion, writing code for
"majority rule" and shorter DMI lists is the most maintainable
solution.

Let us try to find a compromise, ok? Right now, for the machines
we know about, there are more implementations where _INI lives at
the bridge level and correctly initialize _SUN, so it's easier to
follow my original approach.

If we can get this into linux-next and get more exposure on more
platforms, and we find out that the other interpretation of the
spec is more popular, then I will very happily ACK your patch,
and we can have DMI calls to handle HP/IBM machines.

Does that sound fair?

[Let's try and work out an answer here before working on shpchp
naming issues; I already agree that I need to fix that issue
before going upstream, but I want to focus here first.]

Thanks,

/ac


  reply	other threads:[~2008-03-13  3:24 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29  0:23 [PATCH 0/4, v7] PCI, ACPI: Physical PCI slot objects Alex Chiang
2008-02-29  0:26 ` [PATCH 1/4] Remove path attribute from sgi_hotplug Alex Chiang
2008-03-03 18:48   ` Jesse Barnes
2008-03-03 18:54     ` Prarit Bhargava
2008-03-05  0:19       ` Alex Chiang
2008-02-29  0:27 ` [PATCH 2/4] Construct one fakephp slot per pci slot Alex Chiang
2008-02-29  0:28 ` [PATCH 3/4] Introduce pci_slot Alex Chiang
2008-03-01  5:24   ` Greg KH
2008-03-03 20:56     ` Alex Chiang
2008-03-04  5:58       ` Greg KH
2008-03-04 23:30   ` [PATCH 3/4, v8] " Alex Chiang
2008-02-29  0:29 ` [PATCH 4/4] ACPI PCI slot detection driver Alex Chiang
2008-03-01  5:25   ` Greg KH
2008-03-01 14:43     ` Matthew Wilcox
2008-03-04  5:49       ` Greg KH
2008-03-04 18:18         ` Jesse Barnes
2008-03-04 19:30           ` Greg KH
2008-03-04 20:02             ` Jesse Barnes
2008-03-04 20:12             ` Kristen Carlson Accardi
2008-03-04 23:09             ` Alex Chiang
2008-03-05  1:11               ` Kenji Kaneshige
2008-03-05 20:20                 ` Alex Chiang
2008-03-05 20:34                   ` Matthew Wilcox
2008-03-06  2:07                   ` Kenji Kaneshige
2008-03-11 13:10                   ` Kenji Kaneshige
2008-03-11 13:13                     ` [PATCH 3/(3+1)] " Kenji Kaneshige
2008-03-11 13:17                       ` Kenji Kaneshige
2008-03-11 13:19                     ` [PATCH 4/(3+1)] Add quirks for " Kenji Kaneshige
2008-03-11 13:28                     ` [PATCH 4/4] " Matthew Wilcox
2008-03-11 16:56                       ` Jesse Barnes
2008-03-12  5:51                         ` Kenji Kaneshige
2008-03-12  4:08                       ` Kenji Kaneshige
2008-03-11 18:04                     ` Kristen Carlson Accardi
2008-03-11 19:14                       ` Alex Chiang
2008-03-12 11:33                         ` Kenji Kaneshige
2008-03-13  3:24                           ` Alex Chiang [this message]
2008-03-14  2:16                             ` Gary Hade
2008-03-14  5:34                               ` Kenji Kaneshige
2008-03-18 20:49                                 ` Alex Chiang
2008-03-12 10:50                       ` Kenji Kaneshige
2008-03-11 23:34                     ` Kristen Carlson Accardi
2008-03-12 12:59                       ` Kenji Kaneshige
2008-03-04 22:58         ` Alex Chiang
2008-03-04 23:15           ` Greg KH
2008-03-04 23:46             ` Alex Chiang
2008-03-01  5:12 ` [PATCH 0/4, v7] PCI, ACPI: Physical PCI slot objects Greg KH
2008-03-03 23:35   ` Alex Chiang
2008-03-04  5:56     ` Greg KH
2008-03-25  4:13 [PATCH 0/4, v11] " Alex Chiang
2008-03-25  4:17 ` [PATCH 4/4] ACPI PCI slot detection driver Alex Chiang
2008-03-25  4:50   ` Kenji Kaneshige
2008-03-25 17:09 [PATCH 0/4, v12] PCI, ACPI: Physical PCI slot objects Alex Chiang
2008-03-25 17:14 ` [PATCH 4/4] ACPI PCI slot detection driver Alex Chiang

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=20080313032410.GA17561@ldl.fc.hp.com \
    --to=achiang@hp.com \
    --cc=garyhade@us.ibm.com \
    --cc=gregkh@suse.de \
    --cc=jbarnes@virtuousgeek.org \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=kristen.c.accardi@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=matthew@wil.cx \
    --cc=rick.jones2@hp.com \
    --cc=warthog19@eaglescrag.net \
    --subject='Re: [PATCH 4/4] ACPI PCI slot detection driver' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).