linux-kernel - Re: [PATCH 4/4] ACPI PCI slot detection driver

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: <20080313032410.GA17561@ldl.fc.hp.com>
Date:	Wed, 12 Mar 2008 21:24:10 -0600
From:	Alex Chiang <achiang@...com>
To:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
Cc:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>,
	Greg KH <gregkh@...e.de>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Matthew Wilcox <matthew@....cx>,
	Gary Hade <garyhade@...ibm.com>, warthog19@...lescrag.net,
	rick.jones2@...com, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 4/4] ACPI PCI slot detection driver

Hi Kenji-san,

* Kenji Kaneshige <kaneshige.kenji@...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

--
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/