Thread (24 messages) read the whole thread 24 messages, 9 authors, 6d ago

Re: [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()

From: Robin Murphy <robin.murphy@arm.com>
Date: 2026-07-20 14:34:58
Also in: driver-core, imx, linux-arm-kernel, linux-arm-msm, linux-i2c, linux-iommu, linux-pm, linux-sound, linuxppc-dev, lkml

On 20/07/2026 2:39 pm, Bartosz Golaszewski wrote:
On Mon, 20 Jul 2026 14:58:27 +0200, Robin Murphy [off-list ref] said:
quoted
On 20/07/2026 10:24 am, Bartosz Golaszewski wrote:
quoted
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
This is very much non-portable code specific to OF-only platforms, but
if the intention is to remove platform_device_set_of_node() again
already, then FWIW,
Providing platform_device_set_of_node() and using it was done to make the
transision to expanding reference counting to all firmware nodes possible.
I don't think we'll remove it just yet as it doesn't make sense to convert
the code under drivers/of/ to using the fwnode variant.
OK, but in that case why convert these users either? If the OF helper 
does continue to exist then I'd imagine the static checker brigade will 
eventually end up sending patches to "simplify" these open-coded 
equivalents back to using it. And frankly, if drivers do know for sure 
they're exclusively dealing with of_nodes, rather than doing something 
conditional under an is_of_node() check, then I see little justification 
for them *not* using the dedicated helper.

If the complaint is that there are no *public* users to justify 
exporting platform_device_set_fwnode(), then as I say AFAICS that's much 
more neatly addressed with the static inline approach, such that we 
still get to unify the public APIs, actively eliminate something from 
the symbol table and save a bit of source and object code, but without 
any need to churn the truly OF-based callers at all.

Thanks,
Robin.
quoted
Acked-by: Robin Murphy <robin.murphy@arm.com>

(Although I'm slightly puzzled by the cover letter - AFAICS in -next,
platform_device_set_of_node() is itself very much a user of
platform_device_set_fwnode(), however in terms of symbol exports,
perhaps the former could now just be a static inline wrapper?)
Sure that can be done independently later.

Bart
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help