[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yffs0nuG3ElH1bNE@smile.fi.intel.com>
Date: Mon, 31 Jan 2022 16:06:10 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Javier Martinez Canillas <javierm@...hat.com>
Cc: Andy Shevchenko <andy@...nel.org>, linux-fbdev@...r.kernel.org,
Michael Hennerich <michael.hennerich@...log.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Helge Deller <deller@....de>, linux-staging@...ts.linux.dev,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
Phillip Potter <phil@...lpotter.co.uk>,
Carlis <zhangxuezhi1@...ong.com>,
Lee Jones <lee.jones@...aro.org>,
Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH v1 1/4] fbtft: Unorphan the driver
On Mon, Jan 31, 2022 at 02:55:21PM +0100, Javier Martinez Canillas wrote:
> On 1/31/22 14:23, Andy Shevchenko wrote:
> > On Mon, Jan 31, 2022 at 01:08:32PM +0100, Javier Martinez Canillas wrote:
...
> > The tricky part is the PRP0001
> > ACPI PNP ID that allows to reuse it on ACPI-based platforms.
>
> Oh, I wasn't aware about PRP0001. I've read about it at:
>
> https://www.kernel.org/doc/Documentation/acpi/enumeration.txt
Yep!
The idea is that new drivers for discrete (and sometimes even on-SoC)
components should be platform-agnostic (means no strict OF / ACPI
dependencies), so anybody can prototype devices on either of the
platforms.
As a matter of fact IIO subsystem is leading in this by cleaning up
most of the drivers towards that goal.
OF/ACPI explicit dependency makes sense when we 100+% sure that
IP in question won't ever appear on the other type of platform
(which I believe is very rare nowadays for most of the components).
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists