Message-ID: <20080311110403.7db9527c@appleyard>
Date:	Tue, 11 Mar 2008 11:04:03 -0700
From:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>
To:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
Cc:	Alex Chiang <achiang@...com>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.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

On Tue, 11 Mar 2008 22:10:40 +0900
Kenji Kaneshige <kaneshige.kenji@...fujitsu.com> wrote:

> Hi Alex-san,
> 
> Alex Chiang wrote:
> >>> It wasn't the IBM machine that was breaking; it was Fujitsu. They
> >>> were returning an error code (the numerical value 1023) when I
> >>> called the _SUN method on a slot object that existed in the ACPI
> >>> namespace but was not present (as reported by the _STA method).
> >>> By the time I got that error report, I'd already dropped the
> >>> duplicate name detection code, and was letting the kobject
> >>> infrastructure warn about duplicate names because for my test
> >>> cases, refcounting was a better solution.
> >>> [Kenji-san from Fujitsu seemed to be ok with the progress I'd
> >>> made at the time, he can speak up if he's changed his mind ;)]
> >> Unfortunatelly, I have not tried the new version of slot detection
> >> driver because of the lack of test environment. Maybe we need more
> >> several days to wait for test environment. 
> >> BTW, does the new one fixes the issue I reported before? I could
> >> not find it in the changelog. IIRC, this issue was difficult to
> >> solve because the root cause of this issue is from the difference
> >> of interpretation of ACPI spec between HP and Fujitsu (I still
> >> don't think it's a good idea to evaluate _SUN for the device
> >> object whose _STA is 0).
> > 
> > It looks like we disagree on how to interpret the spec (IBM
> > machines interpret the spec the same way HP machines do).
> > 

OK, let me see if I can understand what the issue is here.  Please
correct me if I'm wrong.  The debate is about whether or not it is
legitimate to call _SUN if _STA indicates that the device is not
present and functional.  I've checked ACPI 3.0b, and from what I've
read, you may not evaluate _SUN until _INI is called.  And _INI should
not be called unless _STA indicates that a device is present and
functional.

"OSPM evaluates the _STA object before it evaluates a device _INI
method. The return values of the Present and Functioning bits
determines whether _INI should be evaluated and whether children of the
device should be enumerated and initialized. See section 6.5.1, “_INI
(Init)”."

My interpretation of this is that if Alex's driver scans the Fujitsu
machine and calls _STA on one of the slots and gets Bit 0 (present) and
Bit 3 (functioning) set, then it is ok to enumerate it's children and
evaluate _ADR and _SUN for the children.  If they are returning 1023,
that would mean you should not evaluate the children of that object
since the functional bit is not set.  Is this correct?

If that is the case, I would say that Alex's driver needs to obey the
spec - or else if the this is allowed in an earlier version of the spec
then he needs to check for the version of the spec that was implemented
and make some different rules for that.

Thanks for the clarification,
Kristen

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