On Sat, 5 Nov 2022 15:51:57 -0700 Gwendal Grignou <gwendal@xxxxxxxxxxxx> wrote: > From > https://treexy.com/products/driver-fusion/database/sensors/semtech/sx9360-proximity/ > > sx9360 SAR sensor can be presented with ACPI ID SAMM0208. > > Reported-by: Jordi Torres <majosamaso@xxxxxxxxx> > Signed-off-by: Gwendal Grignou <gwendal@xxxxxxxxxxxx> > --- > drivers/iio/proximity/sx9360.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/iio/proximity/sx9360.c b/drivers/iio/proximity/sx9360.c > index d9a12e6be6ca6..4ebc5784aa6d9 100644 > --- a/drivers/iio/proximity/sx9360.c > +++ b/drivers/iio/proximity/sx9360.c > @@ -865,6 +865,7 @@ static SIMPLE_DEV_PM_OPS(sx9360_pm_ops, sx9360_suspend, sx9360_resume); > > static const struct acpi_device_id sx9360_acpi_match[] = { > { "STH9360", SX9360_WHOAMI_VALUE }, > + { "SAMM0208", SX9360_WHOAMI_VALUE }, SAMM doesn't immediately seem to be a valid ACPI vendor ID. Anyone have a path to poke people to do this right or confirm whose ID that one is? Reality is we'll have to live with it, but I like to complain first in vague hope that people will one day play by the rules! Given semtech has a PNP ID (STH is valid) I'm not sure why someone would use an ACPI ID that doesn't seem to be (unless it is very recent and no one has updated the DB on uefi.org yet). Jonathan > { } > }; > MODULE_DEVICE_TABLE(acpi, sx9360_acpi_match);
