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

[Andreas Kemnade]

On Mon, 16 Feb 2026 11:29:14 +0200
Vladimir Oltean <olteanv@xxxxxxxxx> wrote:

> Hi Josua,
> 
> On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
> > >> 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@xxxxxxxxxxxxxxxxxxx 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.  
> 
> To avoid this, a combination of developer due diligence + maintainer due
> diligence is probably required.
> 
> From linux-phy perspective, there will be some automated build testing
> (which did not exist at the time of your submission). This would have
> caught the 'hidden' devm_mux_state_get_optional() call present only in
> linux-phy/next, when testing patch 2/7.
> 
> But, to work, the build automation needs to be able to apply the entire
> patch set on linux-phy/next. So expect some pushback if it doesn't
> (hence the recommendation to send a mini-series to linux-phy first, and
> request a stable tag).
> 
I do not think that is at all the duty of the patch submitter. I think as
long as every dependencies and side effects are documented, it is IMHO up to the
maintainers to decide how it can be merged best. They know best whether there
is any danger of conflicts in their working tree because that is an area 
where people are working on. Especially this patchset is around for months.

 In MFD where it is
more common practice to have cross-subsystem patchsets, once acks from
everyone are there, MFD Maintainer creates an immutable branch with a tag.
The maintainers of the affected subsystems pull it in. 

Regards,
Andreas