[PATCH v3] software node: Implement device_get_match_data fwnode callback

[PATCH v3] software node: Implement device_get_match_data fwnode callback

[Sui Jingfeng]

Because the software node backend of the fwnode API framework lacks an
implementation for the .device_get_match_data function callback. This
makes it difficult to use(and/or test) a few drivers that originates
from DT world on the non-DT platform.

Implement the .device_get_match_data fwnode callback, which helps to keep
the three backends of the fwnode API aligned as much as possible. This is
also a fundamental step to make a few drivers OF-independent truely
possible.

Device drivers or platform setup codes are expected to provide a software
node string property, named as "compatible". At this moment, the value of
this string property is being used to match against the compatible entries
in the of_device_id table. It can be extended in the future though.

Fixes: ffb42e64561e ("drm/tiny/repaper: Make driver OF-independent")
Fixes: 5703d6ae9573 ("drm/tiny/st7735r: Make driver OF-independent")
Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev>
---
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Daniel Scally <djrscally@gmail.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
---
v1 -> v2: Update commit message
v2 -> v3: Move a loop invariant conditional out of while clause
---
 drivers/base/swnode.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index eb6eb25b343b..b6f40715c4f8 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -15,6 +15,7 @@
 #include <linux/kobject.h>
 #include <linux/kstrtox.h>
 #include <linux/list.h>
+#include <linux/mod_devicetable.h>
 #include <linux/property.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
@@ -390,6 +391,33 @@ static void software_node_put(struct fwnode_handle *fwnode)
 	kobject_put(&swnode->kobj);
 }
 
+static const void *
+software_node_get_match_data(const struct fwnode_handle *fwnode,
+			     const struct device *dev)
+{
+	struct swnode *swnode = to_swnode(fwnode);
+	const struct of_device_id *matches = dev->driver->of_match_table;
+	const char *val = NULL;
+	int ret;
+
+	ret = property_entry_read_string_array(swnode->node->properties,
+					       "compatible", &val, 1);
+	if (ret < 0 || !val)
+		return NULL;
+
+	if (!matches)
+		return NULL;
+
+	while (matches->compatible[0]) {
+		if (!strcmp(matches->compatible, val))
+			return matches->data;
+
+		++matches;
+	}
+
+	return NULL;
+}
+
 static bool software_node_property_present(const struct fwnode_handle *fwnode,
 					   const char *propname)
 {
@@ -676,6 +704,7 @@ software_node_graph_parse_endpoint(const struct fwnode_handle *fwnode,
 static const struct fwnode_operations software_node_ops = {
 	.get = software_node_get,
 	.put = software_node_put,
+	.device_get_match_data = software_node_get_match_data,
 	.property_present = software_node_property_present,
 	.property_read_int_array = software_node_read_int_array,
 	.property_read_string_array = software_node_read_string_array,
-- 
2.34.1

Re: [PATCH v3] software node: Implement device_get_match_data fwnode callback

[Dmitry Torokhov]

Hi Sui,

On Sun, Apr 28, 2024 at 04:36:50AM +0800, Sui Jingfeng wrote:
> Because the software node backend of the fwnode API framework lacks an
> implementation for the .device_get_match_data function callback. This
> makes it difficult to use(and/or test) a few drivers that originates
> from DT world on the non-DT platform.
> 
> Implement the .device_get_match_data fwnode callback, which helps to keep
> the three backends of the fwnode API aligned as much as possible. This is
> also a fundamental step to make a few drivers OF-independent truely
> possible.
> 
> Device drivers or platform setup codes are expected to provide a software
> node string property, named as "compatible". At this moment, the value of
> this string property is being used to match against the compatible entries
> in the of_device_id table. It can be extended in the future though.

I am sorry, but this is not really correct. Software nodes are used to
augment missing or incomplete parameters, but are never primary objects
in the matching process. Sometimes "compatible" property is used with
software nodes, but it does not participate in the matching process.

There are several ways for various buses to match a device and a driver,
but none of them operate on software nodes. Consider for example how
devices on SPI bus are matched (see
drivers/spi/spi.c::spi_match_device()):

1. OF/device tree based match. It *requires* the device to have
dev->of_node which is coming from a DTB. It does not work on software
nodes. In case of match the match data should come from of_device_id
entry.

2. ACPI-based match. The match is done based either on OF-compatible
data (which includes "compatible" property) in _DSD (if driver supports
OF-based matching), or based on HID/CID data. In the latter case the
match data is coming from acpi_device_id entry.

3. Name-based match, typically used for board-instantiated devices. In
this case match is done by comparing device name under which it was
instantiated against names listed in the drivers id_table. The match
data is coming from spi_device_id entry.

Similar matching processes are implemented for i2c and platform buses,
as well as others.

Your patch is effectively hijacks the #3 matching process and
substitutes the bus-specific match data (from
spi_device_id/i2c_device_id/etc) with OF data. This is not expected and
while we may want this in a long term (so we can eventually remove these
bus-specific device ids and only have ACPI/OF ones) I do not think we
are ready for this yet. At the very least this needs to be very clearly
documented.

> 
> Fixes: ffb42e64561e ("drm/tiny/repaper: Make driver OF-independent")
> Fixes: 5703d6ae9573 ("drm/tiny/st7735r: Make driver OF-independent")

As other people mentioned this patch does not fix the aforementioned
commits because they are not broken. In case of non-OF match (which
includes the case where you use software nodes) the match data is coming
from matching spi_device_id entry in the driver.

Thanks.

-- 
Dmitry

Re: [PATCH v3] software node: Implement device_get_match_data fwnode callback

[Sui Jingfeng]

Hi,

On 6/22/24 03:58, Dmitry Torokhov wrote:
> Hi Sui,
> 
> On Sun, Apr 28, 2024 at 04:36:50AM +0800, Sui Jingfeng wrote:
>> Because the software node backend of the fwnode API framework lacks an
>> implementation for the .device_get_match_data function callback. This
>> makes it difficult to use(and/or test) a few drivers that originates
>> from DT world on the non-DT platform.
>>
>> Implement the .device_get_match_data fwnode callback, which helps to keep
>> the three backends of the fwnode API aligned as much as possible. This is
>> also a fundamental step to make a few drivers OF-independent truely
>> possible.
>>
>> Device drivers or platform setup codes are expected to provide a software
>> node string property, named as "compatible". At this moment, the value of
>> this string property is being used to match against the compatible entries
>> in the of_device_id table. It can be extended in the future though.
> 
> I am sorry, but this is not really correct. 

I fine if the maintainers of fwnode API want to reject this, but got
rejected is not really equals to "not correct".

Software nodes are used to
> augment missing or incomplete parameters, but are never primary objects
> in the matching process. Sometimes "compatible" property is used with
> software nodes, but it does not participate in the matching process. > There are several ways for various buses to match a device and a driver,
> but none of them operate on software nodes. 

It's not participate in the matching process in the *past*, but what
we present is something *new*. I fine if you adhere to *old* and/or
*subsystem-dependent* approach, but there really no need to persuade
other people to follow your "old" idea.

Consider for example how
> devices on SPI bus are matched (see
> drivers/spi/spi.c::spi_match_device()):


This only make the driver be able to probed in a non-DT way, but
it doesn't tell how does the *additional device properties* can
be get. This is the key point.


> 1. OF/device tree based match. It *requires* the device to have
> dev->of_node which is coming from a DTB. It does not work on software
> nodes. In case of match the match data should come from of_device_id
> entry.
> 
> 2. ACPI-based match. The match is done based either on OF-compatible
> data (which includes "compatible" property) in _DSD (if driver supports
> OF-based matching), or based on HID/CID data. In the latter case the
> match data is coming from acpi_device_id entry.
> 
> 3. Name-based match, typically used for board-instantiated devices. In
> this case match is done by comparing device name under which it was
> instantiated against names listed in the drivers id_table. The match
> data is coming from spi_device_id entry.

The statements here sound right, but it's useless. Because the problems
isn't solved yet, nor does you words point out a practical approach.

> Similar matching processes are implemented for i2c and platform buses,
> as well as others.
> 
> Your patch is effectively hijacks the #3 matching process and
> substitutes the bus-specific match data (from
> spi_device_id/i2c_device_id/etc) with OF data. This is not expected and

Please stop *contaminating* other people's patch, if you have better
idea you can posting it. My patch open a new door, and there do have
programmer in requesting(need) this in the past.


> while we may want this in a long term (so we can eventually remove these
> bus-specific device ids and only have ACPI/OF ones) I do not think we
> are ready for this yet. At the very least this needs to be very clearly
> documented.

This is your *personal* wants, if you want to remove something,
just do it. Keep quiet if you are not ready. Exposing your concerns
doesn't help to solve any problems.

Or, if you want it to be clear, you can contribute to Documentation/
gpu/todo.rst. Other peoples help you to become clear there, thanks.

Please note that we are talking about the completeness of the fwnode
APIs, what's you say above has nothing to do the device fwnode APIs.
Hence, is not revelant to my patch, again is out of scope.

>>
>> Fixes: ffb42e64561e ("drm/tiny/repaper: Make driver OF-independent")
>> Fixes: 5703d6ae9573 ("drm/tiny/st7735r: Make driver OF-independent")
> 
> As other people mentioned this patch does not fix the aforementioned
> commits because they are not broken. 

You still not really understand what other people does, I'm not saying
it broken. I'm talking about the completeness.

In case of non-OF match (which
> includes the case where you use software nodes) the match data is coming
> from matching spi_device_id entry in the driver.


We don't care about much how it is probed now, rather, after the driver
probed by a non-OF way, how does the additional devices properties
can be get?


Say:

1) "device_property_read_u32(dev, "rotation", &rotation);" and
2) "!device_property_read_string(dev, "pervasive,thermal-zone", 
&thermal_zone))"


For those spi/i2c/platform devices, what we argues are that
those drivers really should just depend on "OF" before we have
a reliable fwnode API backend to redirect to.

Where the additional device_property_read_xxxx() calls redirect to?

What if users want to invoke more device_property_read_xxxx() function?

Re: [PATCH v3] software node: Implement device_get_match_data fwnode callback

[Dmitry Torokhov]

On Sun, Jun 23, 2024 at 02:04:00AM +0800, Sui Jingfeng wrote:
> Hi,
> 
> On 6/22/24 03:58, Dmitry Torokhov wrote:
> > Hi Sui,
> > 
> > On Sun, Apr 28, 2024 at 04:36:50AM +0800, Sui Jingfeng wrote:
> > > Because the software node backend of the fwnode API framework lacks an
> > > implementation for the .device_get_match_data function callback. This
> > > makes it difficult to use(and/or test) a few drivers that originates
> > > from DT world on the non-DT platform.
> > > 
> > > Implement the .device_get_match_data fwnode callback, which helps to keep
> > > the three backends of the fwnode API aligned as much as possible. This is
> > > also a fundamental step to make a few drivers OF-independent truely
> > > possible.
> > > 
> > > Device drivers or platform setup codes are expected to provide a software
> > > node string property, named as "compatible". At this moment, the value of
> > > this string property is being used to match against the compatible entries
> > > in the of_device_id table. It can be extended in the future though.
> > 
> > I am sorry, but this is not really correct.
> 
> I fine if the maintainers of fwnode API want to reject this, but got
> rejected is not really equals to "not correct".

Your statement is factually incorrect. As I shown below using SPI bus as
an example, compatible is only used for OF-based matches. Specifying
"compatible" property via SW node does zilch for matching process. There
are drivers like atmel_mxt_ts that check presence of "compatible"
explicitly (I added it to ensure that the touch controller has all
necessary properties on x86 because older Chromebooks were using ACPI
HID names to differentiate between the touchscreen and touchpad and I
wanted something more robust) but this is not a part of the matching
process.

> 
> Software nodes are used to
> > augment missing or incomplete parameters, but are never primary objects
> > in the matching process. Sometimes "compatible" property is used with
> > software nodes, but it does not participate in the matching process. > There are several ways for various buses to match a device and a driver,
> > but none of them operate on software nodes.
> 
> It's not participate in the matching process in the *past*, but what
> we present is something *new*.

I see absolutely nothing in your patch that would affect the matching
process. It is also not a part of a larger series, so there is nothing
"new" here.

> I fine if you adhere to *old* and/or
> *subsystem-dependent* approach, but there really no need to persuade
> other people to follow your "old" idea.
> 
> Consider for example how
> > devices on SPI bus are matched (see
> > drivers/spi/spi.c::spi_match_device()):
> 
> 
> This only make the driver be able to probed in a non-DT way, but
> it doesn't tell how does the *additional device properties* can
> be get. This is the key point.

I think you misunderstand what device_get_match_data() does. It does not
deal with device properties so there's nothing "additional" there.

> 
> 
> > 1. OF/device tree based match. It *requires* the device to have
> > dev->of_node which is coming from a DTB. It does not work on software
> > nodes. In case of match the match data should come from of_device_id
> > entry.
> > 
> > 2. ACPI-based match. The match is done based either on OF-compatible
> > data (which includes "compatible" property) in _DSD (if driver supports
> > OF-based matching), or based on HID/CID data. In the latter case the
> > match data is coming from acpi_device_id entry.
> > 
> > 3. Name-based match, typically used for board-instantiated devices. In
> > this case match is done by comparing device name under which it was
> > instantiated against names listed in the drivers id_table. The match
> > data is coming from spi_device_id entry.
> 
> The statements here sound right, but it's useless. Because the problems
> isn't solved yet, nor does you words point out a practical approach.

I am explaining you how the system works since there appears to be a
severe misconnect. I think you need to state clearly the problem you are
trying to solve, beyond "completeness of the API" argument.

> 
> > Similar matching processes are implemented for i2c and platform buses,
> > as well as others.
> > 
> > Your patch is effectively hijacks the #3 matching process and
> > substitutes the bus-specific match data (from
> > spi_device_id/i2c_device_id/etc) with OF data. This is not expected and
> 
> Please stop *contaminating* other people's patch, if you have better

I am providing a review of your proposal/patch. That is what happens on
LKML and I suggest you get used to this if you want to become a regular
contributor to the Linxu kernel.

> idea you can posting it. My patch open a new door, and there do have
> programmer in requesting(need) this in the past.

Please point at what exactly you are trying to solve here, because it is
still not clear. Start from the beginning. What are you trying to
achieve on a practical level? I.e. "If I do *this* my device does not
work because of *reason* and to fix this I need *that*". It may very
well be that right "that" is something different from what you are
proposing,

> 
> 
> > while we may want this in a long term (so we can eventually remove these
> > bus-specific device ids and only have ACPI/OF ones) I do not think we
> > are ready for this yet. At the very least this needs to be very clearly
> > documented.
> 
> This is your *personal* wants, if you want to remove something,
> just do it. Keep quiet if you are not ready. Exposing your concerns
> doesn't help to solve any problems.

This sounds incredibly rude. Please consider your tone when writing
your responses.

> 
> Or, if you want it to be clear, you can contribute to Documentation/
> gpu/todo.rst. Other peoples help you to become clear there, thanks.
> 
> Please note that we are talking about the completeness of the fwnode
> APIs, what's you say above has nothing to do the device fwnode APIs.
> Hence, is not revelant to my patch, again is out of scope.
> 
> > > 
> > > Fixes: ffb42e64561e ("drm/tiny/repaper: Make driver OF-independent")
> > > Fixes: 5703d6ae9573 ("drm/tiny/st7735r: Make driver OF-independent")
> > 
> > As other people mentioned this patch does not fix the aforementioned
> > commits because they are not broken.
> 
> You still not really understand what other people does, I'm not saying
> it broken. I'm talking about the completeness.

Completeness for the sake of completeness is not an argument. As it
stands your patch will not change these driver's behavior.

> 
> In case of non-OF match (which
> > includes the case where you use software nodes) the match data is coming
> > from matching spi_device_id entry in the driver.
> 
> 
> We don't care about much how it is probed now, rather, after the driver
> probed by a non-OF way, how does the additional devices properties
> can be get?
> 
> 
> Say:
> 
> 1) "device_property_read_u32(dev, "rotation", &rotation);" and
> 2) "!device_property_read_string(dev, "pervasive,thermal-zone",
> &thermal_zone))"
> 
> 
> For those spi/i2c/platform devices, what we argues are that
> those drivers really should just depend on "OF" before we have
> a reliable fwnode API backend to redirect to.

They are working fine without such restriction now, so I see absolutely
no reason imposing this restriction.

> 
> Where the additional device_property_read_xxxx() calls redirect to?
> 
> What if users want to invoke more device_property_read_xxxx() function?

They are being directed to first the primary FW node instance, which may
be either OF, ACPI, or SW node, and then, if property is not present
there, to the secondary FW node, which can be either again.

At no point ->device_get_match_data() callback in involved in this
process.

Thanks.

-- 
Dmitry

Re: [PATCH v3] software node: Implement device_get_match_data fwnode callback

[Sui Jingfeng]

Hi,

On 6/23/24 03:29, Dmitry Torokhov wrote:
>> In case of non-OF match (which
>>> includes the case where you use software nodes) the match data is coming
>>> from matching spi_device_id entry in the driver.
>>
>> We don't care about much how it is probed now, rather, after the driver
>> probed by a non-OF way, how does the additional devices properties
>> can be get?
>>
>>
>> Say:
>>
>> 1) "device_property_read_u32(dev, "rotation", &rotation);" and
>> 2) "!device_property_read_string(dev, "pervasive,thermal-zone",
>> &thermal_zone))"
>>
>>
>> For those spi/i2c/platform devices, what we argues are that
>> those drivers really should just depend on "OF" before we have
>> a reliable fwnode API backend to redirect to.
> They are working fine without such restriction now, 


You still *NOT* answer where the additional devices properties[1][2]
can be acquire.

[1] device_property_read_u32(dev, "rotation", &rotation)

[2] device_property_read_string(dev, "pervasive,thermal-zone", 
&thermal_zone))


> so I see absolutely no reason imposing this restriction.

The reason is rigorous.

You are acclaiming that works by hardcode or by ignoring the flaws
is fine, then all driver are working fine by *your* standard.

Your personal standard has nothing to do with this patch.

>> Where the additional device_property_read_xxxx() calls redirect to?
>>
>> What if users want to invoke more device_property_read_xxxx() function?
> They are being directed to first the primary FW node instance, which may
> be either OF, ACPI, or SW node, and then, if property is not present
> there, to the secondary FW node, which can be either again.


What I'm asking is, on the non-OF and no-ACPI cases, where's those
device_property_read_xxx() calls can be directed to?

> At no point ->device_get_match_data() callback in involved in this
> process.
> 

The patch is written for people who need it, not for people who don't.

It will be involved if the device is associated with software node.
Its for fwnode API user to get a consistent experience, that is
to get a matching data without introduce extra/duplicated match
mechanism.

The patch is focus on fixing the undefined behavior, is discussing
the correct way to consolidate the fwnode API. Its not going to
discuss how does the those *old" and/or how does those non-fwnode
systems works.

Its NOT discussing how does the driver itself can be probed, a driver
can be probed multiple way and is another question. Being probed and
extract matching data can two different thing and is perfectly valid.

Your problem is that you are not fully understand what other people
does before you rush into the discussion. You are putting restrictions
onto other people, while leaving the problem itself there unsolved.

Its not a place to express your personal value or you personal status,
such as, you are "ready" or "not ready" for something. Or persuading
somebody should get used to what or teaching people to talks with a
whatever tone like a God.

None of those junk words are technical, I can not see constructive
ideas.

Thanks.

Re: [PATCH v3] software node: Implement device_get_match_data fwnode callback

[Dmitry Torokhov]

On Sun, Jun 23, 2024 at 03:38:23PM +0800, Sui Jingfeng wrote:
> Hi,
> 
> On 6/23/24 03:29, Dmitry Torokhov wrote:
> > > In case of non-OF match (which
> > > > includes the case where you use software nodes) the match data is coming
> > > > from matching spi_device_id entry in the driver.
> > > 
> > > We don't care about much how it is probed now, rather, after the driver
> > > probed by a non-OF way, how does the additional devices properties
> > > can be get?
> > > 
> > > 
> > > Say:
> > > 
> > > 1) "device_property_read_u32(dev, "rotation", &rotation);" and
> > > 2) "!device_property_read_string(dev, "pervasive,thermal-zone",
> > > &thermal_zone))"
> > > 
> > > 
> > > For those spi/i2c/platform devices, what we argues are that
> > > those drivers really should just depend on "OF" before we have
> > > a reliable fwnode API backend to redirect to.
> > They are working fine without such restriction now,
> 
> 
> You still *NOT* answer where the additional devices properties[1][2]
> can be acquire.
> 
> [1] device_property_read_u32(dev, "rotation", &rotation)
> 
> [2] device_property_read_string(dev, "pervasive,thermal-zone",
> &thermal_zone))
> 
> 
> > so I see absolutely no reason imposing this restriction.
> 
> The reason is rigorous.
> 
> You are acclaiming that works by hardcode or by ignoring the flaws
> is fine, then all driver are working fine by *your* standard.
> 
> Your personal standard has nothing to do with this patch.
> 
> > > Where the additional device_property_read_xxxx() calls redirect to?
> > > 
> > > What if users want to invoke more device_property_read_xxxx() function?
> > They are being directed to first the primary FW node instance, which may
> > be either OF, ACPI, or SW node, and then, if property is not present
> > there, to the secondary FW node, which can be either again.
> 
> 
> What I'm asking is, on the non-OF and no-ACPI cases, where's those
> device_property_read_xxx() calls can be directed to?
> 
> > At no point ->device_get_match_data() callback in involved in this
> > process.
> > 
> 
> The patch is written for people who need it, not for people who don't.
> 
> It will be involved if the device is associated with software node.
> Its for fwnode API user to get a consistent experience, that is
> to get a matching data without introduce extra/duplicated match
> mechanism.
> 
> The patch is focus on fixing the undefined behavior, is discussing
> the correct way to consolidate the fwnode API. Its not going to
> discuss how does the those *old" and/or how does those non-fwnode
> systems works.
> 
> Its NOT discussing how does the driver itself can be probed, a driver
> can be probed multiple way and is another question. Being probed and
> extract matching data can two different thing and is perfectly valid.
> 
> Your problem is that you are not fully understand what other people
> does before you rush into the discussion. You are putting restrictions
> onto other people, while leaving the problem itself there unsolved.
> 
> Its not a place to express your personal value or you personal status,
> such as, you are "ready" or "not ready" for something. Or persuading
> somebody should get used to what or teaching people to talks with a
> whatever tone like a God.
> 
> None of those junk words are technical, I can not see constructive
> ideas.

Yes, indeed, it appears that further discussion is pointless at this
point.

Andy, Heikki, Greg, and others: FWIW this is a NAK from me.

Thanks.

-- 
Dmitry

Re: [PATCH v3] software node: Implement device_get_match_data fwnode callback

[Dmitry Torokhov]

On Sun, Jun 23, 2024 at 12:58:25AM -0700, Dmitry Torokhov wrote:
> On Sun, Jun 23, 2024 at 03:38:23PM +0800, Sui Jingfeng wrote:
> > Hi,
> > 
> > On 6/23/24 03:29, Dmitry Torokhov wrote:
> > > > In case of non-OF match (which
> > > > > includes the case where you use software nodes) the match data is coming
> > > > > from matching spi_device_id entry in the driver.
> > > > 
> > > > We don't care about much how it is probed now, rather, after the driver
> > > > probed by a non-OF way, how does the additional devices properties
> > > > can be get?
> > > > 
> > > > 
> > > > Say:
> > > > 
> > > > 1) "device_property_read_u32(dev, "rotation", &rotation);" and
> > > > 2) "!device_property_read_string(dev, "pervasive,thermal-zone",
> > > > &thermal_zone))"
> > > > 
> > > > 
> > > > For those spi/i2c/platform devices, what we argues are that
> > > > those drivers really should just depend on "OF" before we have
> > > > a reliable fwnode API backend to redirect to.
> > > They are working fine without such restriction now,
> > 
> > 
> > You still *NOT* answer where the additional devices properties[1][2]
> > can be acquire.
> > 
> > [1] device_property_read_u32(dev, "rotation", &rotation)
> > 
> > [2] device_property_read_string(dev, "pervasive,thermal-zone",
> > &thermal_zone))
> > 
> > 
> > > so I see absolutely no reason imposing this restriction.
> > 
> > The reason is rigorous.
> > 
> > You are acclaiming that works by hardcode or by ignoring the flaws
> > is fine, then all driver are working fine by *your* standard.
> > 
> > Your personal standard has nothing to do with this patch.
> > 
> > > > Where the additional device_property_read_xxxx() calls redirect to?
> > > > 
> > > > What if users want to invoke more device_property_read_xxxx() function?
> > > They are being directed to first the primary FW node instance, which may
> > > be either OF, ACPI, or SW node, and then, if property is not present
> > > there, to the secondary FW node, which can be either again.
> > 
> > 
> > What I'm asking is, on the non-OF and no-ACPI cases, where's those
> > device_property_read_xxx() calls can be directed to?
> > 
> > > At no point ->device_get_match_data() callback in involved in this
> > > process.
> > > 
> > 
> > The patch is written for people who need it, not for people who don't.
> > 
> > It will be involved if the device is associated with software node.
> > Its for fwnode API user to get a consistent experience, that is
> > to get a matching data without introduce extra/duplicated match
> > mechanism.
> > 
> > The patch is focus on fixing the undefined behavior, is discussing
> > the correct way to consolidate the fwnode API. Its not going to
> > discuss how does the those *old" and/or how does those non-fwnode
> > systems works.
> > 
> > Its NOT discussing how does the driver itself can be probed, a driver
> > can be probed multiple way and is another question. Being probed and
> > extract matching data can two different thing and is perfectly valid.
> > 
> > Your problem is that you are not fully understand what other people
> > does before you rush into the discussion. You are putting restrictions
> > onto other people, while leaving the problem itself there unsolved.
> > 
> > Its not a place to express your personal value or you personal status,
> > such as, you are "ready" or "not ready" for something. Or persuading
> > somebody should get used to what or teaching people to talks with a
> > whatever tone like a God.
> > 
> > None of those junk words are technical, I can not see constructive
> > ideas.
> 
> Yes, indeed, it appears that further discussion is pointless at this
> point.
> 
> Andy, Heikki, Greg, and others: FWIW this is a NAK from me.

Even though I said I will not discuss this topic, I stumbled across some
of your patches to the DRM subsystem and it looks like what you want is
actually to help push through this set of patches allowing buses (such as
platform) define their own ->get_match_data() callback so that
device_get_match_data() can be used universally:

https://lore.kernel.org/all/20230804161728.394920-2-biju.das.jz@bp.renesas.com/

Thanks.

-- 
Dmitry