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

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/[email protected]/
> > 
> 
> 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.

> 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/[email protected]

-- 
With Best Regards,
Andy Shevchenko