Message-ID: <20241011074009.GM661995@google.com>
Date: Fri, 11 Oct 2024 08:40:09 +0100
From: Lee Jones <lee@...nel.org>
To: Karel Balej <balejk@...fyz.cz>
Cc: duje.mihanovic@...le.hr, phone-devel@...r.kernel.org,
	~postmarketos/upstreaming@...ts.sr.ht,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	linux-kernel@...r.kernel.org, linux-rtc@...r.kernel.org
Subject: Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and
 relevant definitions

On Thu, 10 Oct 2024, Karel Balej wrote:

> 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".

I've become less strict about that over the years.  The chances of the
accompanying driver not going in over the next release or so is usually
very small.

> > 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?

As above.  I trust you. :)

-- 
Lee Jones [李琼斯]

Powered by blists - more mailing lists