On Mon, 20 Jul 2026 20:28:39 +0200, Andrew Lunn <[email protected]> said: > On Mon, Jul 20, 2026 at 06:01:37PM +0200, Bartosz Golaszewski wrote: >> On Mon, 20 Jul 2026 16:43:40 +0200, Andrew Lunn <[email protected]> said: >> > On Mon, Jul 20, 2026 at 11:24:54AM +0200, Bartosz Golaszewski wrote: >> >> Prefer the higher-level platform_device_set_fwnode() over the >> >> OF-specific platform_device_set_of_node() for dynamically allocated >> >> platform devices. >> >> >> >> Signed-off-by: Bartosz Golaszewski <[email protected]> >> >> --- >> >> drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c >> >> b/drivers/net/ethernet/marvell/mv643xx_eth.c >> >> index >> >> 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc >> >> 100644 >> >> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c >> >> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c >> >> @@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct >> >> platform_device *pdev, >> >> goto put_err; >> >> } >> >> ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); >> >> - platform_device_set_of_node(ppdev, pnp); >> >> + platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp)); >> > >> > This is definitely an OF only driver. There are no other calls to >> > fwnode functions in this driver, so this is the wrong thing to do. >> > >> > Sorry, NACK. >> > >> >> I'm not going to die on this hill but drivers are OF-only until they're not. >> For example, Qualcomm is now working on a hybrid ACPI-OF approach for >> laptops[1] and we may end up needing to start converting drivers to fwnode >> after all. >> >> There's no real benefit to sticking to OF-specific APIs unless you need to >> iterate over all properties of a node or use some other functionality not >> available in fwnode. The overhead is minimal and it's never a hot path. > > There is a lot of benefit to sticking to OF specific APIs, because > within the kernel OF is well maintained, has active maintainers, there > are tools to validate bindings, etc. ACPI is a Wild West, each driver > is a snow flake, there is no review, no binding documentation, no > validation tools etc. > > I hope you allow plenty of time to convert any networking drivers, > where Linux is driving the hardware, to ACPI. Your first stop will be > the UEFI forum making a proposal for MDIO busses, because that > currently is not part of ACPI. You will then need to spend time > understanding the DT bindings, and figuring out which properties are > deprecated so need to stay OF only, and which can be converted to dual > OF/ACPI. I've seen too many naive attempts which blindly convert > everything, copying all the past errors in the DT binding into the > brand new ACPI binding. That will get NACKed. > > OF != ACPI >
I've never said that and ACPI is actually irrelevant to this discussion. Fwnode is the abstraction layer and OF happens to implement it. Unless you need fine-grained control (only exposed by the lower-level abstraction) or performance - neither of which is the case here - you should use the top-level API. As I said: there's no good reason to stick to OF-specific interfaces for drivers that don't really require it - and even then, we should strive to fill the gaps in the fwnode API instead. Bart
