Re: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()

[Ulf Hansson]

On Wed, 11 Feb 2026 at 17:17, Vinod Koul <vkoul@xxxxxxxxxx> wrote:
>
> On 10-02-26, 14:34, Ulf Hansson wrote:
> > On Tue, 10 Feb 2026 at 11:53, Geert Uytterhoeven
> > <geert+renesas@xxxxxxxxx> wrote:
> > >
> > > Now the mux core provides devm_mux_state_get_optional():
> > >
> > >     drivers/phy/renesas/phy-rcar-gen3-usb2.c:944:1: error: static declaration of ‘devm_mux_state_get_optional’ follows non-static
> > >      declaration
> > >       944 | devm_mux_state_get_optional(struct device *dev, const char *mux_name)
> > >           | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >     In file included from drivers/phy/renesas/phy-rcar-gen3-usb2.c:20:
> > >     include/linux/mux/consumer.h:64:19: note: previous declaration of ‘devm_mux_state_get_optional’ with type ‘struct mux_state *(struct device *, const char *)’
> > >        64 | struct mux_state *devm_mux_state_get_optional(struct device *dev, const char *mux_name);
> > >           |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > Fix this by dropping the temporary local wrapper.
> > >
> > > Fixes: ad314348ceb4fe1f ("mux: Add helper functions for getting optional and selected mux-state")
> > > Fixes: 8bb92fd7a0407792 ("phy: renesas: rcar-gen3-usb2: Use mux-state for phyrst management")
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> >
> > Thanks Geert for helping out!
> >
> > > ---
> > >   - ad314348ceb4fe1f is in mmc/next, and a PR has already been sent
> > >     https://lore.kernel.org/20260209133441.556464-1-ulf.hansson@xxxxxxxxxx
> > >   - 8bb92fd7a0407792 is in phy/next
> >
> > Vinod, do you want to pick up the $subject patch as a fix for 7.0-rc1
> > or do you prefer me to handle it?
>
> Should I drop the 8bb92fd7a0407792 and it makes things easier for
> everyone and then we can pick fixed commit for 7.1 cycle..

Well, my pull request for MMC was broken (the mux patches didn't get
properly tested in linux-next, until it was too late), so Linus will
not take it.

At this point I would say that 8bb92fd7a0407792 is still a bit
problematic as it uses the same name of the helper that the mux core
intends to use. It would be better with a phy specific name for it, so
it becomes easier to convert to the common mux helper, later on.
Although, at this point it's still okay as is, as we will need to
defer the mux core changes to v7.1 anyway.

So up to you!

Kind regards
Uffe