Re: [PATCH v1 1/4] phy: phy-can-transceiver: Convert to use device property API

[Vladimir Oltean]

On Tue, Feb 24, 2026 at 06:54:48PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote:
> > On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote:
> 
> ...
> 
> > > -	if (!of_property_present(dev->of_node, "mux-states"))
> > > +	if (!device_property_present(dev, "mux-states"))
> > 
> > There's an entire saga with this function - devm_mux_state_get_optional().
> > Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series.
> > Would you mind not touching this, to avoid complicating what is already
> > a complicated operation? It is going away anyway, and from what I can
> > see in Josua's last series, its implementation from drivers/mux/core.c
> > is already using device property APIs:
> > https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@xxxxxxxxxxxxx/
> 
> Basically you ask me to postpone the series until that will be in. Since this
> file is a mess in terms of OF/fwnode API use in exchange I would like whoever
> is doing the other part to speed up a bit if possible.
> 
> I prefer to see cleaner solution to be applied sooner and last in a long distance,
> that's why I see either mine first but soon, or that first but also soon should
> be in. Can we try to achieve that?

The idea is that Ulf already expressed the availability to take the phy-can-transceiver
patch through the mmc tree and provide back a tag to be pulled into linux-phy:
https://lore.kernel.org/linux-phy/CAPDyKFrtTaJ5fqqbGrE_K6SAdTZYUfp-BycGjtWs4SabwBysKA@xxxxxxxxxxxxxx/

If linux-phy takes your patch first, there will be a conflict when pulling the
stable branch, and it won't be so fun, plus we can't even build-test Josua's
submission on linux-phy, so that's obviously not great.

So yeah, I'm not requesting you to postpone the entire series, just not
touch devm_mux_state_get_optional() and don't let it appear in your
patch context.

Somebody will have to remove "#include <linux/of.h>" at the end of the
whole process, but that's minor.

> ...
> 
> > > -		phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops);
> > > +		phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops);
> > 
> > It is not obvious why you replaced dev->of_node with NULL here.
> > It doesn't appear correct. You seem to be breaking OF-based PHY lookups.
> 
> It's the default. Yeah, I probably have to explain this in the commit message.

Ah, ok. Found the "phy->dev.of_node = node ?: dev->of_node;" assignment.
Sorry and noted, but please add it to the commit message too.

> Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be
> converted to that approach. Or even better, a new (agnostic) API should take
> default fwnode from the same device.
> 
> 		phy = devm_phy_create_simple(dev, &..._phy_ops);
> 
> // name was quickly chosen and may be not the best we can come up with

I agree in principle. PHY drivers shouldn't be given a function where
they routinely have to set one of the arguments to NULL, but a simpler
function without that argument.

But the phy-core.c doesn't support fwnode at all yet, it uses OF
throughout. I think it would be preferable to leave this change to
somebody who has business in that area.

(are you interested in PHYs with a fwnode for any particular reason, or
just because the API is more "generic" just in case?)