On Sun 2019-03-17 23:08:26, Andy Shevchenko wrote: > 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. I don't think that's the case here. I believe you are breaking someone's config. They can probably fix it easily, and then you get the what you wanted, but I don't see reason to break it in the first place. WARN_ON(1) or something there might be acceptable. Breaking driver is not. > > > 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. So what. You are saying "must" and "legal base", so explain. > 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? It it does not cause problems elsewhere, why not? 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
