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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Mon, Aug 17, 2026 at 09:35:05AM +0300, Andy Shevchenko wrote:
> On Fri, Aug 14, 2026 at 02:49:31PM +0200, Manivannan Sadhasivam wrote:
> > On Mon, Jan 12, 2026 at 10:01:23PM +0530, Manivannan Sadhasivam wrote:
> > > 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/
> > 
> > Andy, I had to revive this old thread of a merged series as Krzk is not in
> > favour of adding DT overlay or dynamic OF nodes for these BT devices [1]. His
> > objections are due to the fact that we are just adding BT nodes of a
> > discoverable device (M.2 PCIe device) without any resources. So the node just
> > contains the compatible to match with the serdev driver and nothing else.
> > 
> > And he suggested to use swnodes or other similar mechanisms to plug with the
> > serdev driver as that's the only thing we want here, not a true hardware
> > description.
> 
> SW nodes are not for describing HW from scratch. They are for fixing missing
> pieces. If you can justify your case as a missing piece for the *existing*
> device (which is enumerated using standard mechanisms), you can add a property
> that fills the gap.
> 
> Unfortunately I see that there are `PROPERTY_ENTRY_STRING("compatible", ...)`
> cases in the kernel (only 9 drivers so far), and I can't say if they describing
> missing pieces or a SW-made descriptions of the hardware. For the latter the
> DT/ACPI/other means but swnodes should be used.

I have read all replies by @krzk and the question here, why don't you use
auxiliary bus? It seems the best suit for the case.

> > Since you strongly objected the swnode approach in this series, I wanted to hear
> > your opinion before I rework the code.
> 
> > [1] https://lore.kernel.org/linux-pci/768142f0-2638-41f3-a34f-dc80bb99eb7f@kernel.org

-- 
With Best Regards,
Andy Shevchenko