On Sun, Mar 17, 2019 at 11:12:46PM +0100, Pavel Machek wrote: > On Sun 2019-03-17 23:58:56, Andy Shevchenko wrote: > > On Sun, Mar 17, 2019 at 09:54:39PM +0100, Pavel Machek wrote: > > > On Sun 2019-03-17 22:46:13, Andy Shevchenko wrote: > > > > On Sun, Mar 17, 2019 at 02:24:15AM +0100, Pavel Machek wrote: > > > > > 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: > > > > > > > > > > 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. > > > > > > > > So what? It must be removed. > > > > > > Must? Why? Because you say so? > > > > Because no-one can prove those IDs are official. > > And, therefore...? > > IDs may not or may not be official. But I don't see the need to prove > anything. Huh? > If you want the patch accepted, you have to explain what it will fix > and why it can't cause regressions. Regressions will come if this patch won't be accepted in case the company, whose PCA PNP ID is, decides to allocate them for something completely different. > > Have you read https://uefi.org/PNP_ACPI_Registry ? > > 6.1.5 refers to this site. > > Yeah. I see that whoever wrote uefi.org may dislike the current > driver, and that you dislike it, too. LOL, what? > That does not mean we _have_ to do anything, or that there is legal > problem we need to solve. See the link with the answer from NXP. -- With Best Regards, Andy Shevchenko
