Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon

From: Krzysztof Kozlowski <krzk@kernel.org>
To: Guenter Roeck <linux@roeck-us.net>, Akhil R <akhilrajeev@nvidia.com>
Cc: Frank.Li@nxp.com, acpica-devel@lists.linux.dev,
	alexandre.belloni@bootlin.com, conor+dt@kernel.org,
	devicetree@vger.kernel.org, ebiggers@kernel.org,
	krzk+dt@kernel.org, lenb@kernel.org, linux-acpi@vger.kernel.org,
	linux-hwmon@vger.kernel.org, linux-i3c@lists.infradead.org,
	linux-kernel@vger.kernel.org, miquel.raynal@bootlin.com,
	p.zabel@pengutronix.de, rafael@kernel.org, robh@kernel.org,
	sakari.ailus@linux.intel.com, wsa+renesas@sang-engineering.com
Subject: Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
Date: Sun, 12 Apr 2026 15:32:23 +0200	[thread overview]
Message-ID: <ef05d6fd-97d9-4795-9626-e69895e5df74@kernel.org> (raw)
In-Reply-To: <d0f1f053-589a-4681-8c8f-8e4b5daec145@roeck-us.net>

On 11/04/2026 09:20, Guenter Roeck wrote:
> On 4/10/26 22:34, Akhil R wrote:
> [ ... ]
>>>>> And it
>>>>> should bring me clear rule what I can or cannot remove from defconfig,
>>>>> if in 2 years I come and start pruning it from symbols.
>>
>> I am still a little confused on what information would likely accept (and
>> keep) these configs in the defconfig. Would updating the commit message
>> as below work?
>>
>> "These configs enable the support for SPD5118 within the
>> Small-Outline-Compression-Attached Memory Modules (SOCAMM) LPDDR5X found
>> in the NVIDIA Vera CPUs. The Vera CPU uses ACPI and is part of platforms
>> such as Vera Rubin."
>>
> 
> It is quite interesting that we argue about SPD5118 which is mandatory in
> DDR5 systems. At the same time, CONFIG_IGB_HWMON, CONFIG_SENSORS_MACSMC_HWMON,
> CONFIG_SENSORS_RASPBERRYPI_HWMON, and CONFIG_RTC_DRV_DS3232_HWMON _are_
> enabled in arm64:defconfig. CONFIG_IGB_HWMON is even built-in.

Why CONFIG_SENSORS_MACSMC_HWMON is weird? It is part of the soc using
the defconfig?

The author here has troubles bringing any arguments why his drivers
should be defconfig and keeps asking what do I want to hear. If one
cannot make an argument why a change is needed, then maybe the change
should not be sent?

It's the job of the author to convince why the community needs this
change, unless it is obvious, ofc.

> 
> It is kind of difficult to understand why those are more important than
> the temperature sensor on DDR5 modules (or the temperature sensor on DDR4
> modules, for that matter).

No one discussed this. I have no clue what is SPD5118 and commit msg did
not explain that. Did not even provide accurate user of that.

> 
> I don't know what the policy for defconfig is, but just based on that it does
> seem to lack consistency.

No wonder... people write poor commits and send that to upstream. And
when asked "why do we want this" they got stuck.

> 
> A separate question is if it is time to enable I3C in default configurations.
> I'd think so - more and more chip vendors support it, and presumably they would
> not invest in it if there was no demand, but that is just my personal opinion.

Isn't I3C needed for SPD5118. Otherwise I understand even less from this
rationale - why I3C is being enabled here?

And before author asks what do I want to here: no, it is author's job to
convince me to accept I3C in defconfig. Not mine.

Best regards,
Krzysztof

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c