On Sat, Mar 16, 2019 at 12:09:06PM +0100, Jacek Anaszewski wrote:
> > On 3/15/19 8:13 PM, Andy Shevchenko wrote:
> > > The similar to the commit e88162f9dad426f3c83e23150b7f28b7d9486df8
> > >
> > > ("Revert "i2c: mux: pca954x: Add ACPI support for pca954x"")
> > >
> > > remove non-official ACPI IDs from LED drivers.
> > >
> > > This should be a de facto state until somebody shows either
> > > official letter from NXP about matter or DSDT dump (with
> > > machine / motherboard model) which has a such.
> > I have one general question - is the problem in the lack of official
> > announcement for these ACPI IDs?
Yes. One may not be so creative to take ACPI IDs from the thin air.
If you go to https://uefi.org you can find an official ACPI and PNP registers
of vendors, it their solely realm what and how to proceed with ID allocation.
And yes, I know about abusing this even by some companies in the past.
> > Or maybe some of the pca9xxx devices
> > available on the market support different IDs?
It might be a case, but as I already said in the past to (some) maintainers:
don't accept ACPI IDs without official prove from the vendor or example of DSDT
in a wild which has that ID.
So, I might be mistaken with the patches, but to be on safe side since I can't
google for any prove of those IDs exist, I think we better to remove this vague
ACPI support.
>> If neither of the above
>
> s/If neither of the above/If only the former/
>
> > is the case then is there any other legal reason for not having this
>
> s/other//
>
> > support in the kernel, even if it reportedly works for some pieces
> > of the hardware?
--
With Best Regards,
Andy Shevchenko
