On Tue, 2012-05-29 at 16:44 -0600, Shuah Khan wrote: > On Tue, 2012-05-29 at 22:27 +0000, Moore, Robert wrote: > > > > 2. Calling acpi_get_handle() on _OST prior to executing the method. > > > > This will ensure that this method only gets run if it is present > > > under > > > > the device in question. Coupled with what is already outlined in #1 > > > > above, now _OST gets executed only when it is defined under the > > > device object. > > > > Example case in the existing code, please see > > > acpi_processor_ppc_ost() > > > > implementation. > > > > > > Yes, I did look at acpi_processor_ppc_ost() when I implemented the > > > function. I believe calling acpi_get_handle() is redundant since > > > acpi_ns_get_node() is called within acpi_evaluate_object() as well. > > > acpi_evaluate_object() simply returns with AE_NOT_FOUND when _OST > > > method does not exist. > > > > > > > This is correct. If _OST does not exist, AE_NOT_FOUND will be returned from evaluate_object. > > Yes that is correct from the ACPI Spec and implementation point of view. > My thinking is that a call to acpi_get_handle() might not penalize the > OS as much as acpi_evaluate_object() would on systems that don't > actually implement _OST. In other words, acpi_get_handle() might not go > as deep as acpi_evaluate_object() would go into the ACPI layer, hence > might be a safer measure on platforms that don't actually implement this > optional method under all devices included in this patch set. > I do not think we need to worry about it. The code difference is not that much, and this _OST path is limited to ACPI hotplug operations, which are infrequent events. Automatic workload balancing can make frequent use of the operations, but is not frequent enough to make any difference here. I think simpler code works fine. Thanks, -Toshi -- 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
