On Tue, 2 Nov 2021 03:55:35 +0800 (GMT+08:00)
"Dmitry Maslov" <maslovdmitry@xxxxxxxx> wrote:
> > -----Original Messages-----
> > From: "Andy Shevchenko" <andy.shevchenko@xxxxxxxxx>
> > Sent Time: 2021-11-01 16:20:35 (Monday)
> > To: "Dmitry Maslov" <maslovdmitry@xxxxxxxx>
> > Cc: "Jonathan Cameron" <jic23@xxxxxxxxxx>, linux-iio <linux-iio@xxxxxxxxxxxxxxx>, "Lars-Peter Clausen" <lars@xxxxxxxxxx>, north_sea@xxxxxx, baozhu.zuo@xxxxxxxx, jian.xiong@xxxxxxxx
> > Subject: Re: Re: [PATCH v3] iio: light: ltr501: Added ltr303 driver support
> >
> > On Mon, Nov 1, 2021 at 3:57 PM Dmitry Maslov <maslovdmitry@xxxxxxxx> wrote:
> > > > From: "Andy Shevchenko" <andy.shevchenko@xxxxxxxxx>
> > > > Sent Time: 2021-10-31 22:07:09 (Sunday)
> > > > On Sun, Oct 31, 2021 at 6:46 PM Maslov Dmitry <maslovdmitry@xxxxxxxx> wrote:
> >
> > ...
> >
> > > > > Signed-off-by: Maslov Dmitry <maslovdmitry@xxxxxxxx>
> > > >
> > > > I believe it should be Dmitry Maslov, i.e. First name Last name.
> > >
> > > I could change that, but I do not think there is an international standard for that. The reason I put Maslov Dmitry
> > > is to be in line with corporate email address, which belongs to a Chinese company - in China surname is put first
> > > on the legal documents.
> >
> > Hmm... You are right, there is no such requirement in the Submitting
> > Patches document.
> > ...
> >
> > > > > @@ -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.
Jonathan
>
>
>
