public inbox for linux-rtc@vger.kernel.org
 help / color / mirror / Atom feed
From: "Troy Mitchell" <troy.mitchell@linux.spacemit.com>
To: "Alex Elder" <elder@riscstar.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.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: Mon, 12 Jan 2026 09:49:59 +0800	[thread overview]
Message-ID: <DFM8F4B9RK3A.1RG65AV3UCWC6@linux.spacemit.com> (raw)
In-Reply-To: <a383dbc8-5d14-4654-933d-5dfa73a23b12@riscstar.com>

On Mon Jan 12, 2026 at 3:55 AM CST, Alex Elder wrote:
> On 1/9/26 4:36 PM, Alexandre Belloni wrote:
>>> 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
>
> I think I'm the dumb one.  I think I finally understand your
> point.
>
>> 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.
>
> Your point is that patch has no real effect, at least not
> on the scenario I was talking about.
>
> I.e., I was saying this mattered for using defconfig alone.
> But, as you point out, using defconfig alone gives us:
>
>    ARCH_SPACMIT=y	(in defconfig)
>    MFD_SPACEMIT_P1=m	(from patch 2)
>
> And then, *without* this patch:
>    RTC_DRV_SPACEMIT_P1=MFD_SPACEMIT_P1
> meaning
>    RTC_DRV_SPACEMIT_P1=m
>
> And therefore there's no need for this patch to set the
> default to m rather than MFD_SPACEMIT_P1.
>
Thanks Alex and Alexandre for the clarification. You're absolutely right - 
the patch is indeed redundant since RTC_DRV_SPACEMIT_P1 already inherits 
the correct default value (m) through its dependency on MFD_SPACEMIT_P1.

I'll drop this patch in the next version and review the rest of the series
for similar unnecessary default overrides.

                                          - Troy
>
>
>> The current default behaviour of RTC_DRV_SPACEMIT_P1 seems to be the
>> correct one and the proper fix is then patch 2.
>
> Yes, now I understand.  I'm sorry about my confusion.
>
> 					-Alex


      reply	other threads:[~2026-01-12  1:50 UTC|newest]

Thread overview: 12+ 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 ` [PATCH v4 1/3] regulator: spacemit: MFD_SPACEMIT_P1 as dependencies Troy Mitchell
2025-12-25  7:46 ` [PATCH v4 2/3] mfd: simple-mfd-i2c: add default value Troy Mitchell
2026-01-09 16:41   ` (subset) " 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 16:53   ` Alexandre Belloni
2025-12-29 18:02     ` Alex Elder
2025-12-30  0:51       ` Alexandre Belloni
2025-12-30  1:46         ` Alex Elder
2026-01-09 22:36           ` Alexandre Belloni
2026-01-11 19:55             ` Alex Elder
2026-01-12  1:49               ` Troy Mitchell [this message]

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=DFM8F4B9RK3A.1RG65AV3UCWC6@linux.spacemit.com \
    --to=troy.mitchell@linux.spacemit.com \
    --cc=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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox