On Fri, 5 Nov 2021 06:25:29 +0800
Dmitry Maslov <maslovdmitry@xxxxxxxx> wrote:
> > 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.
>
Absolutely. Just drop the ACPI table entry.
Thanks,
Jonathan
