Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict

[Josua Mayer <josua@solid-run.com>]

Hi,

On 12/02/2026 18:53, Geert Uytterhoeven wrote:
> Hi Vladimir,
>
> On Thu, 12 Feb 2026 at 17:48, Vladimir Oltean <olteanv@gmail.com> wrote:
>> On Sun, Feb 08, 2026 at 05:38:56PM +0200, Josua Mayer wrote:
>>> Rename the temporary devm_mux_state_get_optional function to avoid
>>> conflict with upcoming implementation in multiplexer subsystem.
>>>
>>> Acked-by: Vinod Koul <vkoul@kernel.org>
>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> In the future, when you have a series with cross-tree dependencies,
>> please try to think of it as individual mini-series for each tree's
>> 'next' branch, and specify clearly that you need stable tags (to be
>> pulled into other trees).

I don't really understand how I could split my series up to avoid this 
issue.

Due to the fact that one (and now two) drivers implemented local
mux helpers, to undo that an atomic change must be made tree-wide.

Meanwhile it must be avoided that while the mux core helpers are being
tested / reviewed, that any tree adds another driver-local mux helper
like appears to have happened here.

Note that my patch-set did go to linux-phy@lists.infradead.org list, too.

The second challenge for this series was that mux framework is being
enabled only by drivers Kconfig "select" - and not possible by menuconfig.
This is e.g. responsible for being unable to test =m build with arm64
defconfig - and lead to it only being detected through kernel robot
x86_64 allmodconfig.

>> Telling maintainers what is your expected
>> merge strategy helps avoid making mistakes.
>>
>> For example, if you did that in this set, you wouldn't have missed the
>> fact that in linux-phy/next, phy-can-transceiver is _not_ the only
>> occurrence of devm_mux_state_get_optional(). There's another one in
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c, and that should be also
>> handled in order for trees to not enter inconsistent states.
> To his defense, the one in drivers/phy/renesas/phy-rcar-gen3-usb2.c
> is a recent addition.
>
> So this is yet another case of "convert all current users" (i.e. those
> present in the typical subsystem base, typically *-rc1), with new
> users popping up in -next in parallel, which happens all the time...
>
> Gr{oetje,eeting}s,
>
>                          Geert
>