From: Sui Jingfeng <sui.jingfeng@linux.dev>

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.

Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev>
[mani: removed fixes tag]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/base/swnode.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 16a8301c25d6..cd722712b8e9 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)
 {
@@ -694,6 +722,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_bool = software_node_property_present,
 	.property_read_int_array = software_node_read_int_array,

-- 
2.48.1

On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:

> Because the software node backend of the fwnode API framework lacks an
> implementation for the .device_get_match_data function callback.

Maybe this is done on purpose. Have you thought about this aspect?

> This makes it difficult to use(and/or test) a few drivers that originates
> from DT world on the non-DT platform.

How difficult? DSA implementation went to the way of taking DT overlay
approach. Why that one can't be applied here?

> 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 really do not want to see this patch without very good justification
(note, there were at least two attempts in the past to add this stuff
 and no-one was merged, have you studied those cases?).

-- 
With Best Regards,
Andy Shevchenko

On 2026/1/12 15:56, Andy Shevchenko wrote:
> On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> 
>> Because the software node backend of the fwnode API framework lacks an
>> implementation for the .device_get_match_data function callback.
> 
> Maybe this is done on purpose. 


It is a *fact* that the broken swnode lacks an implementation for the 
.device_get_match_data stub.


Otherwise, If it is really done *on purpose*, the maintainers of swnode
backend probably shall document it in the source file *explicitly*.

Have you thought about this aspect?
> 

If it is sure thing, then it shouldn't start with "Maybe ..."


>> This makes it difficult to use(and/or test) a few drivers that originates
>> from DT world on the non-DT platform.
> 
> How difficult? 

The emphasis isn't on the 'difficult' word, it means 'inconvenience'

> DSA implementation went to the way of taking DT overlay
> approach. Why that one can't be applied here?


Software node as an complement of ACPI, Therefore should do the same.



DT overlay introduce extra overhead/side effects on the non-DT systems.

Besides, DT overlay requires the OS distribution(such as ubuntu) has the 
DT overlay config option selected.



> 
>> 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 really do not want to see this patch

You can do that by dropping the maintainer-ship.

Your endless, bruth-force ranting on such a straight-forward thing 
doesn't make much sense, because that waste everybody's time.

> without very good justification


Justifications has been provided over and over again.

> (note, there were at least two attempts in the past to add this stuff

This exactly saying that the implementation is missing.

>   and no-one was merged, 

That's the reason why you see it at least the second time.

have you studied those cases?).
> 

The first one is not 100% correct.

+ Dmitry Torokhov (who was against this patch previously)

On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> 
> > Because the software node backend of the fwnode API framework lacks an
> > implementation for the .device_get_match_data function callback.
> 
> Maybe this is done on purpose. Have you thought about this aspect?
> 

IMO, software nodes were introduced to add sub-properties to the existing
firmware nodes, but it has usecase/potential to go beyond that. More below.

> > This makes it difficult to use(and/or test) a few drivers that originates
> > from DT world on the non-DT platform.
> 
> How difficult? DSA implementation went to the way of taking DT overlay
> approach. Why that one can't be applied here?
> 

Sometimes you do not have any DT node at all. For example, in this series, the
M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
match it with the existing OF based BT driver (for non-M2 device). From the
driver's point of view, a BT device attached to the M.2 slot and over custom
connectors are both the same. Only difference is that, in the case of custom
connectors, the bluetooth DT node will have the BT device described and in the
case of M.2, the device won't get described, but just the connector [1]. But for
the driver to identify the device (since it cannot enumerate it), either it has
to rely on DT/ACPI or some other means.

In the previous version of this series [2], I used the serdev ID based on the
product name for creating the serdev device and added a new id_table for serdev
driver to match with the device [3]. This almost duplicated the existing OF
match logic. Then Bartosz suggested to use swnode approach [4], to get rid of
the custom serdev ID based matching. When I prototyped, it mostly worked well,
except that swnode needed to have its own .device_get_match_data(), match() and
uevent/modalias functions. And if the swnode reused the existing DT compatible
string, it can work with the existing BT driver without modifications. And this
approach can also be extended to devices instantiated from the board specific
drivers.

[1] https://lore.kernel.org/all/20260110-pci-m2-e-v3-10-4faee7d0d5ae@oss.qualcomm.com/
[2] https://lore.kernel.org/all/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com/
[3] https://lore.kernel.org/all/20251125-pci-m2-e-v2-2-32826de07cc5@oss.qualcomm.com/
[4] https://lore.kernel.org/all/CAMRc=Mc-WebsQZ3jt2xirioNMticiWj9PJ3fsPTXGCeJ1iTLRg@mail.gmail.com/

> > 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 really do not want to see this patch without very good justification
> (note, there were at least two attempts in the past to add this stuff
>  and no-one was merged, have you studied those cases?).
> 

Yes I did. I didn't put the above justification in the cover letter, as it was
already overwhelmed with too much information regarding the connector node.
Maybe I should've added it in the comments section of this patch. But I didn't
know how to do that with b4.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > I really do not want to see this patch without very good justification
> > (note, there were at least two attempts in the past to add this stuff
> >  and no-one was merged, have you studied those cases?).
> > 
> 
> Yes I did. I didn't put the above justification in the cover letter, as it was
> already overwhelmed with too much information regarding the connector node.
> Maybe I should've added it in the comments section of this patch. But I didn't
> know how to do that with b4.

You can just amend the commit directly and put comments under "---". They
will be preserved when email is sent, but won't be applied when the maintainer
pulls the series.

-K

On Mon, Jan 12, 2026 at 08:37:02AM -0500, Konstantin Ryabitsev wrote:
> On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > > I really do not want to see this patch without very good justification
> > > (note, there were at least two attempts in the past to add this stuff
> > >  and no-one was merged, have you studied those cases?).
> > > 
> > 
> > Yes I did. I didn't put the above justification in the cover letter, as it was
> > already overwhelmed with too much information regarding the connector node.
> > Maybe I should've added it in the comments section of this patch. But I didn't
> > know how to do that with b4.
> 
> You can just amend the commit directly and put comments under "---". They
> will be preserved when email is sent, but won't be applied when the maintainer
> pulls the series.
> 

Ah, thanks for the info!

- Mani

-- 
மணிவண்ணன் சதாசிவம்

On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> + Dmitry Torokhov (who was against this patch previously)
> 
> On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > 
> > > Because the software node backend of the fwnode API framework lacks an
> > > implementation for the .device_get_match_data function callback.
> > 
> > Maybe this is done on purpose. Have you thought about this aspect?
> 
> IMO, software nodes were introduced to add sub-properties to the existing
> firmware nodes, but it has usecase/potential to go beyond that. More below.

Potential doesn't mean the necessity.

> > > This makes it difficult to use(and/or test) a few drivers that originates
> > > from DT world on the non-DT platform.
> > 
> > How difficult? DSA implementation went to the way of taking DT overlay
> > approach. Why that one can't be applied here?
> 
> Sometimes you do not have any DT node at all.

Yes, that is exactly the case I have referred to. The PCI core (in Linux)
is able to create DT subtree on non-OF based platforms.

> For example, in this series, the
> M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
> match it with the existing OF based BT driver (for non-M2 device). From the
> driver's point of view, a BT device attached to the M.2 slot and over custom
> connectors are both the same. Only difference is that, in the case of custom
> connectors, the bluetooth DT node will have the BT device described and in the
> case of M.2, the device won't get described, but just the connector [1].

So, what's the problem to add such a description? (Assuming you want a customisation
it can be done at run-time, correct?)

> But for the driver to identify the device (since it cannot enumerate it),
> either it has to rely on DT/ACPI or some other means.

Yes.

> In the previous version of this series [2], I used the serdev ID based on the
> product name for creating the serdev device and added a new id_table for serdev
> driver to match with the device [3]. This almost duplicated the existing OF
> match logic.

That's how we do when we want to add a board file, but thing is that we do not
want board files (only in the cases when other ways are impossible or make less
sense).

> Then Bartosz suggested to use swnode approach [4], to get rid of
> the custom serdev ID based matching. When I prototyped, it mostly worked well,

I know that Bart is fan of swnodes, but it should not be used as a silver
bullet, really.

> except that swnode needed to have its own .device_get_match_data(), match() and
> uevent/modalias functions. And if the swnode reused the existing DT compatible
> string, it can work with the existing BT driver without modifications. And this
> approach can also be extended to devices instantiated from the board specific
> drivers.

DT overlay should work without even modifications done to swnode code, right?

> [1] https://lore.kernel.org/all/20260110-pci-m2-e-v3-10-4faee7d0d5ae@oss.qualcomm.com/
> [2] https://lore.kernel.org/all/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com/
> [3] https://lore.kernel.org/all/20251125-pci-m2-e-v2-2-32826de07cc5@oss.qualcomm.com/
> [4] https://lore.kernel.org/all/CAMRc=Mc-WebsQZ3jt2xirioNMticiWj9PJ3fsPTXGCeJ1iTLRg@mail.gmail.com/
> 
> > > 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 really do not want to see this patch without very good justification
> > (note, there were at least two attempts in the past to add this stuff
> >  and no-one was merged, have you studied those cases?).
> 
> Yes I did. I didn't put the above justification in the cover letter, as it was
> already overwhelmed with too much information regarding the connector node.
> Maybe I should've added it in the comments section of this patch. But I didn't
> know how to do that with b4.

Then you missed it. The cover letter for such a change is way too short.

-- 
With Best Regards,
Andy Shevchenko

On Mon, Jan 12, 2026 at 10:27:45AM +0200, Andy Shevchenko wrote:
> On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > + Dmitry Torokhov (who was against this patch previously)
> > 
> > On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> > > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > 
> > > > Because the software node backend of the fwnode API framework lacks an
> > > > implementation for the .device_get_match_data function callback.
> > > 
> > > Maybe this is done on purpose. Have you thought about this aspect?
> > 
> > IMO, software nodes were introduced to add sub-properties to the existing
> > firmware nodes, but it has usecase/potential to go beyond that. More below.
> 
> Potential doesn't mean the necessity.
> 
> > > > This makes it difficult to use(and/or test) a few drivers that originates
> > > > from DT world on the non-DT platform.
> > > 
> > > How difficult? DSA implementation went to the way of taking DT overlay
> > > approach. Why that one can't be applied here?
> > 
> > Sometimes you do not have any DT node at all.
> 
> Yes, that is exactly the case I have referred to. The PCI core (in Linux)
> is able to create DT subtree on non-OF based platforms.
> 

Maybe I should look into creating dynamic DT node for the device and insert it
to the uart node. Theoretically it should work.

> > For example, in this series, the
> > M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
> > match it with the existing OF based BT driver (for non-M2 device). From the
> > driver's point of view, a BT device attached to the M.2 slot and over custom
> > connectors are both the same. Only difference is that, in the case of custom
> > connectors, the bluetooth DT node will have the BT device described and in the
> > case of M.2, the device won't get described, but just the connector [1].
> 
> So, what's the problem to add such a description? (Assuming you want a customisation
> it can be done at run-time, correct?)
> 
> > But for the driver to identify the device (since it cannot enumerate it),
> > either it has to rely on DT/ACPI or some other means.
> 
> Yes.
> 
> > In the previous version of this series [2], I used the serdev ID based on the
> > product name for creating the serdev device and added a new id_table for serdev
> > driver to match with the device [3]. This almost duplicated the existing OF
> > match logic.
> 
> That's how we do when we want to add a board file, but thing is that we do not
> want board files (only in the cases when other ways are impossible or make less
> sense).
> 
> > Then Bartosz suggested to use swnode approach [4], to get rid of
> > the custom serdev ID based matching. When I prototyped, it mostly worked well,
> 
> I know that Bart is fan of swnodes, but it should not be used as a silver
> bullet, really.
> 
> > except that swnode needed to have its own .device_get_match_data(), match() and
> > uevent/modalias functions. And if the swnode reused the existing DT compatible
> > string, it can work with the existing BT driver without modifications. And this
> > approach can also be extended to devices instantiated from the board specific
> > drivers.
> 
> DT overlay should work without even modifications done to swnode code, right?
> 

Not from the overlay binaries (.dtbo), but adding dynamic BT node for the device
based on the enumerated PCI device should work.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

On Mon, Jan 12, 2026 at 02:32:21PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Jan 12, 2026 at 10:27:45AM +0200, Andy Shevchenko wrote:
> > On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> > > + Dmitry Torokhov (who was against this patch previously)
> > > 
> > > On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> > > > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > > > 
> > > > > Because the software node backend of the fwnode API framework lacks an
> > > > > implementation for the .device_get_match_data function callback.
> > > > 
> > > > Maybe this is done on purpose. Have you thought about this aspect?
> > > 
> > > IMO, software nodes were introduced to add sub-properties to the existing
> > > firmware nodes, but it has usecase/potential to go beyond that. More below.
> > 
> > Potential doesn't mean the necessity.
> > 
> > > > > This makes it difficult to use(and/or test) a few drivers that originates
> > > > > from DT world on the non-DT platform.
> > > > 
> > > > How difficult? DSA implementation went to the way of taking DT overlay
> > > > approach. Why that one can't be applied here?
> > > 
> > > Sometimes you do not have any DT node at all.
> > 
> > Yes, that is exactly the case I have referred to. The PCI core (in Linux)
> > is able to create DT subtree on non-OF based platforms.
> > 
> 
> Maybe I should look into creating dynamic DT node for the device and insert it
> to the uart node. Theoretically it should work.
> 

It worked flawlessly. So I sent v4 incorporating this design:
https://lore.kernel.org/linux-pci/20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com/

Thanks!

- Mani

-- 
மணிவண்ணன் சதாசிவம்