| Message ID | 20221105225157.10081-1-gwendal@chromium.org (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | iio: proximity: sx9360: Add a new ACPI hardware ID | expand |
On Sat, 5 Nov 2022 15:51:57 -0700 Gwendal Grignou <gwendal@chromium.org> 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@gmail.com> > Signed-off-by: Gwendal Grignou <gwendal@chromium.org> > --- > 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);
On Sun, Nov 6, 2022 at 8:32 AM Jonathan Cameron <jic23@kernel.org> wrote: > > On Sat, 5 Nov 2022 15:51:57 -0700 > Gwendal Grignou <gwendal@chromium.org> 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@gmail.com> > > Signed-off-by: Gwendal Grignou <gwendal@chromium.org> > > --- > > 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! Sorry for not having checked UEFI DB first. You are not the only one to complain: https://andy-shev.dreamwidth.org/151340.html > 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). uefi.org says the last update is 2/14/2020, but that's not correct, some entries have been added in 2021: https://uefi.org/ACPI_ID_List?search=SECC From http://www.alsa-project.org/db/?f=6196fa05fcd368166cdeee8b0509be7ca64166ee, the sensor is present on device NT950QED from Samsung From https://www.samsung.com/sec/galaxybook/galaxy-book2-pro-360-nt950qed-kc71g/NT950QED-KC71G/, that device is a Samsung Galaxy Book 2 360. Surprisingly, Samsung does not have an ACPI ID defined, but does have a PNP ID (SAM). It may have been an uncontrolled spelling mistake. From https://treexy.com/products/driver-fusion/database/sensors/semtech/, Semtech sensors do appear under names different from STH. Gwendal. > > Jonathan > > > > { } > > }; > > MODULE_DEVICE_TABLE(acpi, sx9360_acpi_match); >
On Sun, 6 Nov 2022 20:28:22 -0800 Gwendal Grignou <gwendal@chromium.org> wrote: > On Sun, Nov 6, 2022 at 8:32 AM Jonathan Cameron <jic23@kernel.org> wrote: > > > > On Sat, 5 Nov 2022 15:51:57 -0700 > > Gwendal Grignou <gwendal@chromium.org> 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@gmail.com> > > > Signed-off-by: Gwendal Grignou <gwendal@chromium.org> > > > --- > > > 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! > Sorry for not having checked UEFI DB first. You are not the only one > to complain: https://andy-shev.dreamwidth.org/151340.html > > 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). > uefi.org says the last update is 2/14/2020, but that's not correct, > some entries have been added in 2021: > https://uefi.org/ACPI_ID_List?search=SECC Time to use the fact I have a members account... There are some more approved ones that aren't on that list yet but not SAMM as far as I can find by looking through relevant approval threads. > > From http://www.alsa-project.org/db/?f=6196fa05fcd368166cdeee8b0509be7ca64166ee, > the sensor is present on device NT950QED from Samsung > > From https://www.samsung.com/sec/galaxybook/galaxy-book2-pro-360-nt950qed-kc71g/NT950QED-KC71G/, > that device is a Samsung Galaxy Book 2 360. > > Surprisingly, Samsung does not have an ACPI ID defined, but does have > a PNP ID (SAM). It may have been an uncontrolled spelling mistake. Given you can always (almost?) use a PNP ID where you can use an ACPI one, lots of companies don't bother with both. You are probably right on typo (or maybe extended by someone who didn't realize you shouldn't do that). I've had my moan, so I'll pick this up when I'm on the right computer. Jonathan > > From https://treexy.com/products/driver-fusion/database/sensors/semtech/, > Semtech sensors do appear under names different from STH. > > Gwendal. > > > > > Jonathan > > > > > > > { } > > > }; > > > MODULE_DEVICE_TABLE(acpi, sx9360_acpi_match); > >
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 }, { } }; MODULE_DEVICE_TABLE(acpi, sx9360_acpi_match);
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@gmail.com> Signed-off-by: Gwendal Grignou <gwendal@chromium.org> --- drivers/iio/proximity/sx9360.c | 1 + 1 file changed, 1 insertion(+)