On Sun, Apr 9, 2023 at 3:28 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
> On 4/2/23 08:17, Andy Shevchenko wrote:
> > On Sat, Apr 1, 2023 at 4:59 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
...
> >> + obj = acpi_evaluate_dsm_typed(adev->handle, &intel_sensor_module_guid,
> >> + 0x00, 0x01, NULL, ACPI_TYPE_STRING);
> >> + if (obj) {
> >> + dev_info(dev, "Sensor module id: '%s'\n", obj->string.pointer);
> >> + if (module_id_str)
> >> + *module_id_str = kstrdup(obj->string.pointer, GFP_KERNEL);
> >> +
> >> + ACPI_FREE(obj);
> >> + }
> >
> >> + if (!soc_intel_is_byt() && !soc_intel_is_cht())
> >> + return 0;
> >
> > So, you (might) call the previous _DSM for any SoC, is it intentional?
>
> Yes the previous _DSM which gives a sensor-module-id string is also used on IPU3 and IPU6 so we want to at least try it on all x86/ACPI platforms. If the _DSM with that GUID is not supported then the call should be harmless.
Still there is a probability to have it being run on some broken ACPI
tables on non-BYT/CHT platforms. Yes, it will be very unlikely, but
still I think the more robust is to check for SoC CPU ID first.
--
With Best Regards,
Andy Shevchenko
