[PATCH] iio: proximity: sx9360: Add a new ACPI hardware ID

[PATCH] iio: proximity: sx9360: Add a new ACPI hardware ID

[Gwendal Grignou]

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 },
 	{ }
 };
 MODULE_DEVICE_TABLE(acpi, sx9360_acpi_match);
-- 
2.38.1.431.g37b22c650d-goog

Re: [PATCH] iio: proximity: sx9360: Add a new ACPI hardware ID

[Jonathan Cameron]

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);

Re: [PATCH] iio: proximity: sx9360: Add a new ACPI hardware ID

[Gwendal Grignou]

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);
>

Re: [PATCH] iio: proximity: sx9360: Add a new ACPI hardware ID

[Jonathan Cameron]

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);  
> >