Received-SPF: pass (google.com: domain of linux-kernel+bounces-207140-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Sat, 8 Jun 2024 17:49:29 +0100
From: Jonathan Cameron <jic23@kernel.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Yasin Lee <yasin.lee.x@outlook.com>, lars@metafoo.de,
 linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, nuno.a@analog.com,
 swboyd@chromium.org, u.kleine-koenig@pengutronix.de, yasin.lee.x@gmail.com
Subject: Re: [PATCH v4 2/2] iio:proximity:hx9023s: Add TYHX HX9023S sensor
 driver
Message-ID: <20240608174929.14cd9f51@jic23-huawei>
In-Reply-To: <CAHp75VfYhMbHK7pMTuVDZ3uc5ZjytA7uC+3fr7u3nWUEosGZHw@mail.gmail.com>
References: <20240607114138.390272-1-yasin.lee.x@outlook.com>
	<SN7PR12MB81017291E79E6B61A8DEC9A5A4FB2@SN7PR12MB8101.namprd12.prod.outlook.com>
	<CAHp75VdYYGe7rXJm1z2a=r7ZnSU0-y+3N8juoNF-5xXi5=z5nA@mail.gmail.com>
	<CAHp75VfYhMbHK7pMTuVDZ3uc5ZjytA7uC+3fr7u3nWUEosGZHw@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 7 Jun 2024 22:45:49 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Fri, Jun 7, 2024 at 10:40=E2=80=AFPM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Fri, Jun 7, 2024 at 2:42=E2=80=AFPM Yasin Lee <yasin.lee.x@outlook.c=
om> wrote: =20
>=20
> ...
> .
> > > +static const struct acpi_device_id hx9023s_acpi_match[] =3D {
> > > +       { "TYHX9023" },
> > > +       {}
> > > +}; =20
> >
> > Btw, do you have a reference to any device on the market that has this =
ID? =20
>=20
> Aaaargh!
> Jonathan, we have to have a big rule from now on on ACPI IDs, if
> anybody introduces an ID in the driver, they must provide the device
> model that is (are going to) use it and excerpt from the ACPI ID
> registry to prove the vendor ID is real.
>=20
> This is the heck fake ID!
> NAK.

Agreed.  Though we should also put together some boilerplate text /
Documentation on how to get a real ID if it makes sense and what
information we need to justify carrying a bad one (which usually
has to include that you've made the supplier aware that the Linux
maintainers are going to be grumpy and our ire wasn't enough to persuade
them to promise to mend their ways - note it has worked a few times!)

For this case, key is:  There are two types of valid ID the one here
is of the ACPI ID form. For that...

ACPI IDs have to be granted by a manufacturer who has registered
with UEFI forum and been granted the use of the four letter sequence
for their products.  For example HiSilicon (my employer) has HISI.
Note that the list on the website is sometimes a bit out of date, so
if you know it has been granted recently just say that in your
patch header.  Note, I can check an would guess Andy can as well :)

That company is then responsible for handling their ID space. In my
case I know who has control of the big spread sheet, so when I want
a valid ID I go ask him and make a case for why.  Those ID spreadsheets
aren't public though in most cases, so we only know it's gone wrong
when we get a clash or a suspicious value (DEAD or BEEF usually ;)

If this process has not been gone through but some device manufacturer
has shipped a firmware with a made up ID, then we are effectively
carrying a workaround for their errata.  We will do that, but we need
much more information and a comment next to the id table entry to provide
at least one example of the shipping product suffering from this bug.

Jonathan

p.s Occasionally these sneak past me (less so with Andy's eagle eyes
on the job) and in the past I was young and didn't know better.
We will rip new ones out if we detect them reasonably quickly and
we reserve the right to rip out old ones to see who screams...
>=20