Hello Morimoto-san,
On Mon, Feb 05, 2024 at 05:31:25AM +0000, Kuninori Morimoto wrote:
>
> Hi Sakari
>
> > > Thank you for your suggestion.
> > > But I'm not familiar with fwnode, and it seems we still need of_*,
> > > I will keep current style (= non fwnode) in v3
> >
> > The fwnode API should be kept in sync with the OF (and other firmware
> > specific) API. Merging your set in its current form would leave fwnode API
> > impaired. Therefore I'd very much prefer to see this set add similar fwnode
> > APIs, too.
>
> I will keep current fwnode API behavior, but I can't test it.
The fwnode API is an abstraction layer on top of the OF or ACPI APIs,
and allows drivers to work on both without needing to support OF and
ACPI explicitly and separately. You should be able to convert the
drivers you're using to the fwnode API, and it should work exactly the
same as when using the OF-specific functions. That will give you a way
to test the API.
For instance, if you look at the drivers/media/platform/rcar_drif.c
driver, you will see
if (!fwnode_property_read_u32(fwnode, "sync-active", &val))
which, on OF platforms, is equivalent to
if (!of_property_read_u32(np, "sync-active", &val))
This particular driver will never be used on an ACPI-based system, but
drivers are still encouraged to use the fwnode API.
> Now, I'm separating the patch-set into small stages.
> There is no problem for a while, but I think I will ask you to test it in the
> final stage.
--
Regards,
Laurent Pinchart
