Re: [PATCH 01/28] media: atomisp: Add v4l2_get_acpi_sensor_info() helper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux