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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Mar 17, 2026 at 12:41:19PM +0200, Andy Shevchenko wrote:
> 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@solid-run.com/
> > > > 
> > > > 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@mail.gmail.com/
> > > 
> > > 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?

Okay, I found the new patches in Linux Next.
I will respin my set based on that.

> > > 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



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy