> From: "Jonathan Cameron" <jic23@xxxxxxxxxx>
> Sent Time: 2021-11-03 20:21:02 (Wednesday)
> To: "Dmitry Maslov" <maslovdmitry@xxxxxxxx>
> Cc: "Andy Shevchenko" <andy.shevchenko@xxxxxxxxx>, linux-iio <linux-iio@xxxxxxxxxxxxxxx>, "Lars-Peter Clausen" <lars@xxxxxxxxxx>, north_sea@xxxxxx, baozhu.zuo@xxxxxxxx, jian.xiong@xxxxxxxx
> Subject: Re: [PATCH v3] iio: light: ltr501: Added ltr303 driver support
> > > > > > @@ -1597,6 +1610,7 @@ static const struct acpi_device_id ltr_acpi_match[] = {
> > > > > > {"LTER0501", ltr501},
> > > > > > {"LTER0559", ltr559},
> > > > > > {"LTER0301", ltr301},
> > > > > > + {"LTER0303", ltr303},
> > > > >
> > > > > Any evidence of this ACPI ID being in the wild, please?
> > > >
> > > > I'm sorry, I do not exactly understand the question. Do you mean where that particular sensor is used?
> > >
> > > Can you provide a name of the machine which has this ID in its DSDT
> > > table, please?
> >
> > We're submitting this patch specifically for reTerminal.
> > Here is DTS file for the reTerminal, currently awaiting merge in Raspberry Pi Linux kernel
> > repository.
> > https://github.com/raspberrypi/linux/blob/6ef732875d705ff15cc4c25d4d0a0eee87dc2a58/arch/arm/boot/dts/overlays/seeed-reterminal-core-overlay.dts#L99
> >
> > So, while at the moment ACPI part is not being used, later we might use this sensor for other, x86 based
> > boards, for example ODYSSEY - X86J4125800.
> >
> > Is there a particular reason you think this part should be omitted for LTR303?
> >
> ACPI IDs are supposed to be made up of either a PNP id or ACPI ID registered with
> UEFI forum.
>
> A 4 letter version is an ACPI ID (3 letters in PNP), so it should be in this table
> https://uefi.org/acpi_id_list
>
> It's not. So that means the proper process wasn't followed. If you were using this
> ID on a server, chances are we'd just tell you go fix your firmware (it's happened
> to me and we fixed it). However the sad truth is in consumer / embedded devices that
> may not be a practical solution. As such, if the ID was known to be in the wild
> we would probably let it in.
>
> Unfortunately I only really got familiar with ACPI specs in the last 4 years
> and before that time I didn't know what the rules were - so let a load of IDs in.
> Some of those IDs are in use on hardware that is out there so we have to continue
> supporting them or introduce a regression on that hardware.
>
> The process of applying for a PNP or ACPI ID isn't that bad for a company - you ask
> for a particular ID and request is then sent for a round of 'has anyone an objection'
> to the ASWG (I'm a rather inactive member so I see these every week or so).
> Instructions at https://uefi.org/PNP_ACPI_Registry
>
> Note that there would be two options for Seeed. Either you persuade liteon to apply
> and then issue an appropriate number (which may well not be the part number - often
> people just start counting from 0, or assign ranges to different people in the company
> so there doesn't need to be a central registry) or seeed applies for an ACPI or PNP ID
> and then issues IDs for any part you want to support on an ACPI platform that doesn't
> yet have an ID issued by the supplier.
>
> Note that it's also common to use someone else's ID. Once it's assigned to a device
> it can't be reused anyway so if say, Intel or Hisilicon had assigned one to a part
> already then you could just reuse it for your ACPI platforms.
>
> Hope that clears up how this is supposed to work.
>
> Also note that every now and then we 'guess' that IDs are just cut and paste
> jobs and remove them. So far we've only hit ones that were in actual use a
> few times - the majority of invalid ones weren't in use.
>
Thank you for taking your time to write such detailed explanation! The whole situation
with ACPI/PNP ID is much more clear to me now.
As I mentioned above, currently our main goal is adding drivers necessary to support
reTerminal, which is ARM processor based device. It means that as of now, we
won't be using ACPI. Do you think it is valid option to just remove that part?
That shouldn't affect ARM based devices ability to interact with the sensor.
