failed to evaluate control method

I’ve tried to evaluate an control method in my kmdf legacy driver,
because it’s just a legacy driver so it doesn’t own any control method in acpi, it’s just going to evaluate those methods belong to other device,
and the result is that WdfIoTargetSendIoctlSynchronously returned a failed status from ACPI driver.

so I’ve traced into ACPI to see what happened,
I saw my driver exactly sent an device control request to ACPI,
then AMLIGetNameSpaceObject exactly gets the object which is “_PR.CPU0._PSS” that I specify in ACPI_EVAL_INPUT_BUFFER_EX structure,
then ACPI called AMLIIsObjectInGivenScope,
but it returned me a failed status code: c0000039 (STATUS_OBJECT_PATH_INVALID)

There must be something wrong in my driver, post my code below,
thanks in advance for any opinions.

#define ACPI_NAME_STRING L"\Device\0000000e" //This is ACPI driver

NTSTATUS status = STATUS_SUCCESS;// Assume success
WDF_IO_TARGET_OPEN_PARAMS openParams;
WDF_MEMORY_DESCRIPTOR inputDescriptor;
ACPI_EVAL_INPUT_BUFFER_EX acpiInputBuffer;
WDF_MEMORY_DESCRIPTOR outputDescriptor;
ACPI_EVAL_OUTPUT_BUFFER acpiOutputBuffer;
WDFIOTARGET ioTarget;
WDFDEVICE device;
ULONG sizeReturned;

device = WdfIoQueueGetDevice(Queue);
status = WdfIoTargetCreate(device,
WDF_NO_OBJECT_ATTRIBUTES,
&ioTarget
);

DECLARE_CONST_UNICODE_STRING(acpiDeviceName, ACPI_NAME_STRING);
WDF_IO_TARGET_OPEN_PARAMS_INIT_CREATE_BY_NAME(&openParams,
&acpiDeviceName,
STANDARD_RIGHTS_ALL
);
status = WdfIoTargetOpen(ioTarget,
&openParams
);
acpiInputBuffer.Signature = ACPI_EVAL_INPUT_BUFFER_SIGNATURE;
strcpy(acpiInputBuffer.MethodName, “_PR.CPU0._PSS”);
WDF_MEMORY_DESCRIPTOR_INIT_BUFFER(&inputDescriptor,
(PVOID)&acpiInputBuffer,
sizeof(ACPI_EVAL_INPUT_BUFFER_EX));

RtlZeroMemory(&acpiOutputBuffer, sizeof(acpiOutputBuffer));
WDF_MEMORY_DESCRIPTOR_INIT_BUFFER(&outputDescriptor,
(PVOID)&acpiOutputBuffer,
sizeof(ACPI_EVAL_OUTPUT_BUFFER));
status = WdfIoTargetSendIoctlSynchronously(ioTarget,
NULL,
IOCTL_ACPI_EVAL_METHOD_EX,
&inputDescriptor,
&outputDescriptor,
NULL,
(PULONG_PTR)&sizeReturned
);

xxxxx@hotmail.com wrote:

I’ve tried to evaluate an control method in my kmdf legacy driver,
because it’s just a legacy driver so it doesn’t own any control method in acpi, it’s just going to evaluate those methods belong to other device,
and the result is that WdfIoTargetSendIoctlSynchronously returned a failed status from ACPI driver.

What led you to believe that would work?

so I’ve traced into ACPI to see what happened,
I saw my driver exactly sent an device control request to ACPI,
then AMLIGetNameSpaceObject exactly gets the object which is “_PR.CPU0._PSS” that I specify in ACPI_EVAL_INPUT_BUFFER_EX structure,
then ACPI called AMLIIsObjectInGivenScope,
but it returned me a failed status code: c0000039 (STATUS_OBJECT_PATH_INVALID)

There must be something wrong in my driver,…

No, I think there is something wrong with your concept. ACPI methods
for an object can only be called by the driver for that object (or it’s
parent objects). If you are not the driver for CPU0, then you can’t
call CPU0 methods. The function name is a huge clue –
AMLIIsObjectInGivenScope. Your driver is not in the scope for _PR.CPU0.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> #define ACPI_NAME_STRING L"\Device\0000000e" //This is ACPI driver

You’re hardcoding this value?

Sorry, it is not even persistent across boots I think.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Hi Tim,
I had surveyed this problem before, “Is it possible to evaluate those ACPI methods that are not belonged to me?”
obviously I’ve been unsure,
but there was an interesting statement from MSFT’s Jake in previous thread.

Yep, it’s not good to hard code it, this ACPI’s name maybe different for each different machine,
but it have always been the same one in the same machine, so I can temporarily hard code it for test.
it there any way to get this ACPI’s name dynamically?

> it there any way to get this ACPI’s name dynamically?

Try looking at device interfaces hanging off the ACPI devnode. They can possibly have very distinct (even if undocumented) GUID.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com