Received-SPF: pass (google.com: domain of linux-kernel+bounces-111767-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 22 Mar 2024 18:14:11 +0200
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	Daniel Scally <djrscally@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-acpi@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org,
	Vladimir Oltean <vladimir.oltean@nxp.com>
Subject: Re: [PATCH] software node: Implement device_get_match_data fwnode
 callback
Message-ID: <Zf2uUwcMgIpo6rVh@smile.fi.intel.com>
References: <20240318234222.1278882-1-sui.jingfeng@linux.dev>
 <Zfq85f-Dp1S3CKuG@smile.fi.intel.com>
 <9ced20e0-dfbd-4337-b5df-223b7baffd9e@linux.dev>
 <ZftG6Q5AaG71dhWq@smile.fi.intel.com>
 <9644da91-f367-4083-a3e4-4d0677c8cbca@linux.dev>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9644da91-f367-4083-a3e4-4d0677c8cbca@linux.dev>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

On Fri, Mar 22, 2024 at 05:00:05PM +0800, Sui Jingfeng wrote:
> On 2024/3/21 04:28, Andy Shevchenko wrote:

..

> > > > > By replacing it with device_get_match_data() and creating a software
> > > > > graph that mimics the OF graph, everything else works fine, except that
> > > > > there isn't an out-of-box replacement for the of_device_get_match_data()
> > > > > function. Because the software node backend of the fwnode framework lacks
> > > > > an implementation for the device_get_match_data callback.
> > > > .device_get_match_data
> > > > 
> > > > > Implement device_get_match_data fwnode callback fwnode callback to fill
> > > > .device_get_match_data
> > > OK, thanks a lot.
> > > 
> > > > > this gap. Device drivers or platform setup codes are expected to provide
> > > > > a "compatible" string property. The value of this string property is used
> > > > > to match against the compatible entries in the of_device_id table. Which
> > > > > is consistent with the original usage style.
> > > > Why do you need to implement the graph in the board file?
> > > It can be inside the chip, there is no clear cut.\
> > Which chip? Flash memory / ROM or you meant something like FPGA here?
> > For the latter there is another discussion on how to use DT overlays
> > in ACPI-enabled environments for the FPGA configurations.
> 
> There are some hardware resource or software entity is created on the
> driver runtime. But DT or DT overlays are compiled before device driver
> get loaded. GPIO-emulated-I2C is just an example, this is kind of driver
> level knowledge on the runtime. With the GPIO or programmable some
> hardware IP unit, device driver authors can change the connection relationship
> at their will at the runtime. While with DT, every thing has to be sure
> before the compile time.
> 
> DT overlays can be a alternative solution, but this doesn't conflict with
> this patch. This patch won't assume how device drives go to use it, and
> allow device driver creating device instead enumerating by DT. In one
> word: "flexibility".

Software nodes in general for the device driver / platform quirks.
They are not designed for what you are talking about here.

Consider using SSDT / DT?overlays instead.

-- 
With Best Regards,
Andy Shevchenko