On 2023-04-24 17:14:57-0500, Jorge Lopez wrote: > Sorry for asking again. I just want to be understand exactly what I must do. No problem! > > > > > > > > > > > + args->command = command; > > > > > > + args->commandtype = query; > > > > > > + args->datasize = insize; > > > > > > + memcpy(args->data, buffer, flex_array_size(args, data, insize)); > > > > > > + > > > > > > + ret = wmi_evaluate_method(HP_WMI_BIOS_GUID, 0, mid, &input, &output); > > > > > > > > > > The driver is mixing calls to the UUID based APIs and the wmi_device > > > > > ones. > > > > > wmi_devices is newer and preferred. > > > > > > > > The driver calls wmi_evaluate_method when initiating an WMI call. > > > > Where is the driver mixing calls to the UUID based APIs and the > > > > wmi_device one? > > > > WMI calls are made by calling hp_wmi_perform_query() which invokes > > > > wmi_evaluate_method(). > > > > Did I miss something? > > > > > > wmi_evaluate_method() is UUID-based. > > > struct wmi_driver is wmi_device based. > > > > > > The wmi_driver/wmi_device code essentially does nothing and is only used > > > to validate that a device is present. > > > The same can be done more easily wmi_has_guid(). > > > > > > > Are you asking to replace all calls to wmi_evaluate_method() which is > UUID based API with calls to wmidev_evaluate_method() which is > wmi_device based? Correct? To be honest I'm not 100% sure. wmi_device is great and perferct for simple drivers binding to a single UUID. But it does not handle multi-UUID logic as your driver needs very well. I would argue to stick to the legacy calls as it allows you to drop a bunch of code and makes the initialization flow more straightforward. But I don't know if somebody else won't ask for wmi_device later.
