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

[Sui Jingfeng]

Hi,


On 2024/3/21 04:28, Andy Shevchenko wrote:
> > > > By replacing it with device_get_match_data() and creating a software
> > > > graph that mimics the OF graph, everything else works fine, except that
> > > > there isn't an out-of-box replacement for the of_device_get_match_data()
> > > > function. Because the software node backend of the fwnode framework lacks
> > > > an implementation for the device_get_match_data callback.
> > > .device_get_match_data
> > >
> > > > Implement device_get_match_data fwnode callback fwnode callback to fill
> > > .device_get_match_data
> > OK, thanks a lot.
> >
> > > > this gap. Device drivers or platform setup codes are expected to provide
> > > > a "compatible" string property. The value of this string property is used
> > > > to match against the compatible entries in the of_device_id table. Which
> > > > is consistent with the original usage style.
> > > Why do you need to implement the graph in the board file?
> > It can be inside the chip, there is no clear cut.\
> Which chip? Flash memory / ROM or you meant something like FPGA here?
> For the latter there is another discussion on how to use DT overlays
> in ACPI-enabled environments for the FPGA configurations.


There are some hardware resource or software entity is created on the
driver runtime. But DT or DT overlays are compiled before device driver
get loaded. GPIO-emulated-I2C is just an example, this is kind of driver
level knowledge on the runtime. With the GPIO or programmable some
hardware IP unit, device driver authors can change the connection relationship
at their will at the runtime. While with DT, every thing has to be sure
before the compile time.

DT overlays can be a alternative solution, but this doesn't conflict with
this patch. This patch won't assume how device drives go to use it, and
allow device driver creating device instead enumerating by DT. In one
word: "flexibility".



--
Best regards,
Sui