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

[Manivannan Sadhasivam]

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@xxxxxxxxxxxxxxxx/

Thanks!

- Mani

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