On Sun, Mar 17, 2019 at 09:48:14PM +0100, Pavel Machek wrote: > On Sun 2019-03-17 22:44:22, Andy Shevchenko wrote: > > On Sun, Mar 17, 2019 at 02:20:19AM +0100, Pavel Machek wrote: > > > On Fri 2019-03-15 21:13:42, Andy Shevchenko wrote: > > > > There is no evidence of officially registered ACPI IDs for these devices. > > > > Thus, revert commit 44b3e31d540e917a4d2292b902ade63fa1748d9a. > > > > > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > > > > > > NAK. I don't believe someone did that code without testing. > > > > Testing is irrelevant here. > > Do you believe someone wrote that code without testing? I can't say anything about this driver, though I believe that's possible. It's not the first time, perhaps not the last. I know the code, which was never worked, used to be in kernel. > > It's unlike device tree where IDs comes from thin air. > > Do you have any document in possession that supports legal base for these IDs > > being in the kernel? > > Legal? ACPI specification was not law last time I checked. If I'm not mistaken ACPI specification doesn't tell anything about _how_ the ID comes into the play. OTOH the official registry had been established. And just a parallel example: you meant you can add to, say, PCI driver couple of IDs, because your FPGA can do it and everything would be fine? -- With Best Regards, Andy Shevchenko
