Re: [PATCH v10 3/6] mfd: max77759: add register bitmasks and modify irq configs for charger

[Amit Sunil Dhamne]

Hi Krzysztof,

On 4/29/26 9:59 AM, Krzysztof Kozlowski wrote:
> On 29/04/2026 02:29, Amit Sunil Dhamne wrote:
> > Hi Lee,
> >
> >
> > Thanks for your review.
> >
> >
> > On 4/24/26 1:26 AM, Lee Jones wrote:
> > > On Tue, 31 Mar 2026, Amit Sunil Dhamne via B4 Relay wrote:
> > >
> > > > From: Amit Sunil Dhamne <amitsd@xxxxxxxxxx>
> > > >
> > > > Add register bitmasks for charger function.
> > > > In addition split the charger IRQs further such that each bit represents
> > > > an IRQ downstream of charger regmap irq chip. In addition populate the
> > > > ack_base to offload irq ack to the regmap irq chip framework.
> > > Please reword this commit messages.
> > >
> > > Using 'In addition' twice in such close proximity reads a little awkwardly.
> > Thanks for pointing it out. Unfortunately, this commit is already part
> > of the linux and linux-next so I am not sure if I could fix the commit
> > message retrospectively.
> I don't understand why you decided to put this with USB patchset. We do
> ask not to mix subsystems all the time. You made it unnecessarily
> combination of at least three subsystems.
>
> Do not do that.
Thank you for the feedback. I understand the concern regarding mixing 
subsystems, and I apologize for the extra overhead this caused during 
review.

The decision to group these was driven by tight functional 
inter-dependencies that I felt would have caused build failures or 
regressions if split:

MFD & Charger: The charger driver relies on new macros and symbols 
defined in mfd/max77759.h. Additionally, the MFD driver handles the IRQ 
chip initialization and defines the named IRQ resources that the charger 
driver requires to register its handlers.

Charger & USB Type-C: To avoid a regression, the charger driver needed 
to take over charger mode programming from the TCPC driver (where it was 
previously handled as a workaround). Merging these separately would have 
created a race condition or left the hardware in an inconsistent state 
during the transition.

I see now that this made the patchset difficult to manage across 
subsystems. For future cases involving such dependencies, would you 
recommend providing an immutable branch for maintainers to pull from, or 
is there a different preferred workflow you'd suggest?

Best regards,

Amit


> Best regards,
> Krzysztof