From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Alex Elder <elder@riscstar.com>
Cc: Troy Mitchell <troy.mitchell@linux.spacemit.com>,
Lee Jones <lee@kernel.org>, Yixun Lan <dlan@gentoo.org>,
Andi Shyti <andi.shyti@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
spacemit@lists.linux.dev, linux-i2c@vger.kernel.org,
linux-rtc@vger.kernel.org
Subject: Re: [PATCH v4 3/3] rtc: spacemit: default module when MFD_SPACEMIT_P1 is enabled
Date: Fri, 9 Jan 2026 23:36:27 +0100 [thread overview]
Message-ID: <20260109223627b566d2b0@mail.local> (raw)
In-Reply-To: <6ca28183-1687-4ddc-8b3c-5e5be4255561@riscstar.com>
On 29/12/2025 19:46:59-0600, Alex Elder wrote:
> On 12/29/25 6:51 PM, Alexandre Belloni wrote:
> > On 29/12/2025 12:02:23-0600, Alex Elder wrote:
> > > On 12/25/25 10:53 AM, Alexandre Belloni wrote:
> > > > On 25/12/2025 15:46:33+0800, Troy Mitchell wrote:
> > > > > The RTC driver defaulted to the same value as MFD_SPACEMIT_P1, which
> > > > > caused it to be built-in automatically whenever the PMIC support was
> > > > > set to y.
> > > > >
> > > > > This is not always desirable, as the RTC function is not required on
> > > > > all platforms using the SpacemiT P1 PMIC.
> > > >
> > > > But then, can't people simply change the config? I don't feel like
> > > > this is an improvement.
> > >
> > > It's not an improvement for people who want to use the SpacemiT
> > > P1 PMIC, but it's an improvement for all the other RISC-V builds
> > > using "defconfig" that would rather have that support be modular
> > > to avoid needlessly consuming resources.
> >
> > But then, wouldn't MFD_SPACEMIT_P1 be simply not set or set to m ? So
> > this doesn't have any impact on other RISC-V builds while it makes
> > people using the SpacemiT P1 PMIC jump through hoops to be able to use
> > the RTC as this is a very uncommon way to set default values.
> >
> > My point is:
> > - other RISC-V platforms would simply not select MFD_SPACEMIT_P1 or
> > have MFD_SPACEMIT_P1 set to m
> > - having RTC_DRV_SPACEMIT_P1 built-in by default when MFD_SPACEMIT_P1
> > is built-in doesn't really hurt any SpacemiT P1 users but would be
> > the expectation of those using the RTC.
>
> The "hurt" isn't about P1 users, it's about everyone else.
>
> > - those wanting to optimise because they won't use the RTC, they can
> > already simply unselect RTC_DRV_SPACEMIT_P1 or set it to m.
>
>
> The purpose is to make the driver a module (not built-in)
> when "defconfig" is used (without the need for any Kconfig
> fragments to unselect things).
>
>
> In arch/riscv/configs/defconfig, we have this:
> CONFIG_ARCH_SPACEMIT=y
>
> In drivers/mfd/Kconfig b/drivers/mfd/Kconfig, we have this
> (added by patch 2 in this series):
> config MFD_SPACEMIT_P1
> default m if ARCH_SPACEMIT
>
> So when using defconfig (alone), MFD_SPACEMIT_P1 is set to m,
> to benefit non-SpacemiT RISC-V platforms.
>
> This patch is trying to do the same thing for the RTC,
> i.e. having RTC_DRV_SPACEMIT_P1 be defined as a module
> by default.
>
> I think you understand.
I'm sorry, I must be dumb but I don't understand. The current behaviour
is that when MFD_SPACEMIT_P1 is m, then the default value for
RTC_DRV_SPACEMIT_P1 will be m. Since patch 2 makes it exactly that way
(MFD_SPACEMIT_P set to m), I don't get why it is necessary to mess with
the default of RTC_DRV_SPACEMIT_P1.
The current default behaviour of RTC_DRV_SPACEMIT_P1 seems to be the
correct one and the proper fix is then patch 2.
WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Alex Elder <elder@riscstar.com>
Cc: Troy Mitchell <troy.mitchell@linux.spacemit.com>,
Lee Jones <lee@kernel.org>, Yixun Lan <dlan@gentoo.org>,
Andi Shyti <andi.shyti@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
spacemit@lists.linux.dev, linux-i2c@vger.kernel.org,
linux-rtc@vger.kernel.org
Subject: Re: [PATCH v4 3/3] rtc: spacemit: default module when MFD_SPACEMIT_P1 is enabled
Date: Fri, 9 Jan 2026 23:36:27 +0100 [thread overview]
Message-ID: <20260109223627b566d2b0@mail.local> (raw)
In-Reply-To: <6ca28183-1687-4ddc-8b3c-5e5be4255561@riscstar.com>
On 29/12/2025 19:46:59-0600, Alex Elder wrote:
> On 12/29/25 6:51 PM, Alexandre Belloni wrote:
> > On 29/12/2025 12:02:23-0600, Alex Elder wrote:
> > > On 12/25/25 10:53 AM, Alexandre Belloni wrote:
> > > > On 25/12/2025 15:46:33+0800, Troy Mitchell wrote:
> > > > > The RTC driver defaulted to the same value as MFD_SPACEMIT_P1, which
> > > > > caused it to be built-in automatically whenever the PMIC support was
> > > > > set to y.
> > > > >
> > > > > This is not always desirable, as the RTC function is not required on
> > > > > all platforms using the SpacemiT P1 PMIC.
> > > >
> > > > But then, can't people simply change the config? I don't feel like
> > > > this is an improvement.
> > >
> > > It's not an improvement for people who want to use the SpacemiT
> > > P1 PMIC, but it's an improvement for all the other RISC-V builds
> > > using "defconfig" that would rather have that support be modular
> > > to avoid needlessly consuming resources.
> >
> > But then, wouldn't MFD_SPACEMIT_P1 be simply not set or set to m ? So
> > this doesn't have any impact on other RISC-V builds while it makes
> > people using the SpacemiT P1 PMIC jump through hoops to be able to use
> > the RTC as this is a very uncommon way to set default values.
> >
> > My point is:
> > - other RISC-V platforms would simply not select MFD_SPACEMIT_P1 or
> > have MFD_SPACEMIT_P1 set to m
> > - having RTC_DRV_SPACEMIT_P1 built-in by default when MFD_SPACEMIT_P1
> > is built-in doesn't really hurt any SpacemiT P1 users but would be
> > the expectation of those using the RTC.
>
> The "hurt" isn't about P1 users, it's about everyone else.
>
> > - those wanting to optimise because they won't use the RTC, they can
> > already simply unselect RTC_DRV_SPACEMIT_P1 or set it to m.
>
>
> The purpose is to make the driver a module (not built-in)
> when "defconfig" is used (without the need for any Kconfig
> fragments to unselect things).
>
>
> In arch/riscv/configs/defconfig, we have this:
> CONFIG_ARCH_SPACEMIT=y
>
> In drivers/mfd/Kconfig b/drivers/mfd/Kconfig, we have this
> (added by patch 2 in this series):
> config MFD_SPACEMIT_P1
> default m if ARCH_SPACEMIT
>
> So when using defconfig (alone), MFD_SPACEMIT_P1 is set to m,
> to benefit non-SpacemiT RISC-V platforms.
>
> This patch is trying to do the same thing for the RTC,
> i.e. having RTC_DRV_SPACEMIT_P1 be defined as a module
> by default.
>
> I think you understand.
I'm sorry, I must be dumb but I don't understand. The current behaviour
is that when MFD_SPACEMIT_P1 is m, then the default value for
RTC_DRV_SPACEMIT_P1 will be m. Since patch 2 makes it exactly that way
(MFD_SPACEMIT_P set to m), I don't get why it is necessary to mess with
the default of RTC_DRV_SPACEMIT_P1.
The current default behaviour of RTC_DRV_SPACEMIT_P1 seems to be the
correct one and the proper fix is then patch 2.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-01-09 22:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-25 7:46 [PATCH v4 0/3] spacemit: fix P1 sub-device Kconfig defaults and dependencies Troy Mitchell
2025-12-25 7:46 ` Troy Mitchell
2025-12-25 7:46 ` [PATCH v4 1/3] regulator: spacemit: MFD_SPACEMIT_P1 as dependencies Troy Mitchell
2025-12-25 7:46 ` Troy Mitchell
2025-12-25 7:46 ` [PATCH v4 2/3] mfd: simple-mfd-i2c: add default value Troy Mitchell
2025-12-25 7:46 ` Troy Mitchell
2026-01-09 16:41 ` (subset) " Lee Jones
2026-01-09 16:41 ` Lee Jones
2025-12-25 7:46 ` [PATCH v4 3/3] rtc: spacemit: default module when MFD_SPACEMIT_P1 is enabled Troy Mitchell
2025-12-25 7:46 ` Troy Mitchell
2025-12-25 16:53 ` Alexandre Belloni
2025-12-25 16:53 ` Alexandre Belloni
2025-12-29 18:02 ` Alex Elder
2025-12-29 18:02 ` Alex Elder
2025-12-30 0:51 ` Alexandre Belloni
2025-12-30 0:51 ` Alexandre Belloni
2025-12-30 1:46 ` Alex Elder
2025-12-30 1:46 ` Alex Elder
2026-01-09 22:36 ` Alexandre Belloni [this message]
2026-01-09 22:36 ` Alexandre Belloni
2026-01-11 19:55 ` Alex Elder
2026-01-11 19:55 ` Alex Elder
2026-01-12 1:49 ` Troy Mitchell
2026-01-12 1:49 ` Troy Mitchell
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=20260109223627b566d2b0@mail.local \
--to=alexandre.belloni@bootlin.com \
--cc=andi.shyti@kernel.org \
--cc=broonie@kernel.org \
--cc=dlan@gentoo.org \
--cc=elder@riscstar.com \
--cc=lee@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-rtc@vger.kernel.org \
--cc=spacemit@lists.linux.dev \
--cc=troy.mitchell@linux.spacemit.com \
/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.