Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions
From: Karel Balej
Date: Thu Oct 10 2024 - 12:40:18 EST
Lee Jones, 2024-10-10T09:35:19+01:00:
> On Thu, 10 Oct 2024, Lee Jones wrote:
>
> > On Wed, 09 Oct 2024, Karel Balej wrote:
> >
> > > Lee Jones, 2024-10-09T11:06:43+01:00:
> > > > On Fri, 20 Sep 2024 18:12:34 +0200, Karel Balej wrote:
> > > > > RTC lives on the base register page of the chip. Add definitions of the
> > > > > registers needed for a basic set/read time functionality.
> > > > >
> > > > >
> > > >
> > > > Applied, thanks!
> > >
> > > Thank you, however I'm a little perplexed.
> > >
> > > It was my understanding that RFC patches should not be applied without
> > > further agreement, is that not the case? Obviously this patch was very
> > > simple and I used RFC mainly because of the RTC driver itself, but I'm
> > > curious to know for future submissions.
> >
> > I missed the fact that this was an RFC. I can unapply it if you like?
> >
> > > Also, I expected the entire series to go at once through the rtc tree
> > > with your ack as while it is not a strict dependency in terms of
> > > breakage, the first patch seems rather pointless without the follow-up
> > > which could theoretically take a long time to get applied and even some
> > > requested changes could require changes to this patch. Could you please
> > > explain what the policy is on this?
> >
> > The policy is flexible. However, the generally accepted rule is that if
> > there are build-time dependencies between patches, then one maintainer
> > (usually me since MFD is usually at the centre of these cross-subsystem
> > patch-sets) takes them and sends out a pull-request for an immutable
> > branch for the other maintainers to pull from.
> >
> > However in this case, there are no build-time dependencies so the
> > patches are able to and therefore should go in via their respective
> > repos.
>
> Actually, it looks like there are build-time deps between them.
Indeed, I didn't realize that yesterday. What I had in mind before was
in fact the other part of the patch: I was wondering about the policy of
applying a patch adding a MFD cell for which there is no driver
available. That's what I meant by "not a strict dependency in terms of
breakage".
> Please break out the inclusion of the additional defines and place them
> into the RTC patch. I will then Ack that one. The patch making changes
> to driver/mfd will still go in via the MFD repo.
So the above in other words: it sounds like you would apply this updated
patch independently of the RTC driver because otherwise you could just
ack the current version, is that correct? If so, I cannot see why this
would be preferable given what I wrote before about the RTC driver being
possibly delayed or eventually given up on (not that I would expect that
to be the case here :-). Could you please still comment on this then?
Thank you,
K. B.