On Tue, 11 Mar 2008 22:10:40 +0900 Kenji Kaneshige <kaneshige.kenji@xxxxxxxxxxxxxx> 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
