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

[Andy Shevchenko]

On Sat, Feb 28, 2026 at 01:10:02PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 24, 2026 at 08:30:00PM +0200, Vladimir Oltean wrote:
> > 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.
> 
> Thanks for explanation. I prefer that Ulf's staff settles down first as it seems
> more important.

Any news on that front?

> > 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.
> 
> Sure.
> 
> > > 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?)
> 
> Because of inconsistency. This makes my mind blown and the code is not good
> for others to read and understand when it's inconsistent like this. That's it.

-- 
With Best Regards,
Andy Shevchenko