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

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

Am 16.02.26 um 16:24 schrieb Andreas Kemnade:
> On Mon, 16 Feb 2026 11:29:14 +0200
> Vladimir Oltean <olteanv@gmail.com> 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@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.  
>> 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.
Excellent!
>>
>> 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).
It would help immensely if there was a way to get the patches renaming
driver-local conflicting helper-functions very early, before anything else.

Would this sort of patch be acceptable in linux-next now, so it can make
it into v7.0-rc1?

If not then that mini-patchset would be the first one I shall submit after
v7.0-rc1 is released.

Then I can treat the actual implementation of the devm_mux_* helpers
as a second standalone patch-set.

And finally patching all drivers with local helpers to use the new global ones
can be patch-set number 3.

Any opinions on this?

> 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. 
This seems like an option, if I can get the patch-set (or a partial one) ready early in the cycle.
>
> Regards,
> Andreas
>
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy