On Sat 2019-03-16 14:44:35, Andy Shevchenko wrote:
> 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.
Code is already in, so this is different situation.
And yes, that rule kind-of makes sense. Feel free to comment on any
patches violating it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
