Re: [PATCH net-next v5 1/5] dt-bindings: mfd: x-powers: Add AC200

On 11/08/2026 09:23, James Hilliard wrote:
> On Tue, Aug 11, 2026 at 1:07 AM Krzysztof Kozlowski <[email protected]> wrote:
>>
>> On 09/08/2026 22:28, James Hilliard wrote:
>>> The AC200 is an I2C-controlled mixed-signal companion IC containing
>>> audio, video, RTC and Fast Ethernet PHY functions.
>>>
>>> Describe the parent device and its shared input clock. The Ethernet PHY
>>> is represented by a PHY package on its MDIO bus, with a phandle back to
>>> this device for access to the package control registers, so it does not
>>> require an MFD child node. Function-specific supplies belong to their
>>> consumer bindings rather than the shared parent.
>>>
>>> The input clock must run at 24 or 27 MHz when the Ethernet PHY is used,
>>> matching the rates encoded by its documented clock selector.
>>>
>>> Signed-off-by: James Hilliard <[email protected]>
>>> ---
>>
>> I do not understand why MFD and net are combined. And nothing in top
>> part of cover letter explains me that (which I asked already - any
>> dependency or merging is THE MOST important information. Where do you
>> put the most important information which maintainers should see
>> immediately?)
> 
> The AC200 PHY control registers reside in the I2C-managed
> multifunction device. The AC200 PHY backend therefore consumes
> the regmap published by the AC200 MFD driver, while the AC300
> backend accesses its control registers directly over MDIO.
> 
> The managed syscon registration change is used by the AC200 MFD
> provider. The net driver itself uses the existing syscon lookup
> interface, so there is no compile-time dependency from the net
> patches on the new syscon API. There is, however, an unavoidable
> runtime dependency for AC200 on its I2C provider. AC300 has no
> such dependency.

Runtime dependency for new drivers is irrelevant. Patchset should go via
different subsystems thus should be split to make maintainers life easier.

The only reason to combine it - which is nowhere explained - is to agree
on common design of expressing child relationship with sibling phandle
style.

And again the problem is that cover letter explains nothing. I went
through first three paragraphs.

> 
>> Bundling it together suggests this is somehow incomplete and later will
>> be finished, which is wrong by itself. How to fix it - decouple
>> dependencies.
> 
> Could you clarify whether you mean that the MFD and net changes
> should be sent as separate submissions, or that the driver
> interface should be redesigned so the net side has no dependency
> on the AC200 MFD provider?

You organize independent work targeting independent subsystems into
independent patchsets. Simply act as maintainer. What maintainers are
supposed to do here? How much time they need to parse this patchset and
apply?

Best regards,
Krzysztof