From: Lee Jones <lee@kernel.org>
To: Karel Balej <balejk@matfyz.cz>
Cc: duje.mihanovic@skole.hr, phone-devel@vger.kernel.org,
~postmarketos/upstreaming@lists.sr.ht,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-kernel@vger.kernel.org, linux-rtc@vger.kernel.org
Subject: Re: (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions
Date: Thu, 10 Oct 2024 09:35:19 +0100 [thread overview]
Message-ID: <20241010083519.GC661995@google.com> (raw)
In-Reply-To: <20241010083100.GB661995@google.com>
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.
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.
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2024-10-10 8:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-20 16:12 [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions Karel Balej
2024-09-20 16:12 ` [RFC PATCH 2/2] rtc: add driver for Marvell 88PM886 PMIC RTC Karel Balej
2024-10-09 10:06 ` (subset) [RFC PATCH 1/2] mfd: 88pm886: add the RTC cell and relevant definitions Lee Jones
2024-10-09 19:03 ` Karel Balej
2024-10-10 8:31 ` Lee Jones
2024-10-10 8:35 ` Lee Jones [this message]
2024-10-10 16:40 ` Karel Balej
2024-10-11 7:40 ` Lee Jones
2024-10-10 8:35 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241010083519.GC661995@google.com \
--to=lee@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=balejk@matfyz.cz \
--cc=duje.mihanovic@skole.hr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=phone-devel@vger.kernel.org \
--cc=~postmarketos/upstreaming@lists.sr.ht \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.