Hi Sui, On Tue, Jan 23, 2024 at 04:01:28PM +0800, Sui Jingfeng wrote: > On 2024/1/23 09:17, Laurent Pinchart wrote: > > On Tue, Jan 23, 2024 at 12:32:16AM +0800, Sui Jingfeng wrote: > >> Because ACPI based systems only has the fwnode associated, the of_node > >> member of struct device is NULL. To order to move things forward, we add > >> drm_bridge_find_by_fwnode() to extend the support. > >> > >> Signed-off-by: Sui Jingfeng <sui.jingfeng@xxxxxxxxx> > > > > Could we switch completely to fwnode, instead of maintaining the fwnode > > and OF options side-by-side ? > > The side-by-side approach allow us to migrate smoothly, But it increases the maintenance burden for the duration of the migration. I fear the migration would span years, with nobody really taking active care of it, and the OF and non-OF API will have a risk to diverge. > the main consideration is that the OF approach has been > works very well, it is flexible and very successful in > the embedded world. fwnode is a superset of OF, so I don't expect issues switching from OF to fwnode. For the non-OF, non-fwnode users, that's possibly a different question. > It seems that the fwnode API could NOT replace the OF > options completely. For example, the'of_device_id' and 'of_match_table' related things are always there, there Yes, and that's not a problem. OF drivers still use of_device_id and of_match_table, even if they use the fwnode API. No issue there. > are large well-established helpers and subroutines and > already formed as a standard. Some part of it may suffer > from backward compatibility problems. fwnode has been designed to offer the same API as OF for drivers. If something is missing, it can be raised with the maintainers. > So I want to leave some space to other programmers. > Maybe there are other programmers who feel that using > OF alone is enough for a specific problem(domain). -- Regards, Laurent Pinchart
