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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 12/04/2026 15:32, Krzysztof Kozlowski wrote:
> 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.

BTW, all this was asked at v1 and author did not improve the commit msg
beside giving quite broad/unspecific "Vera".

Best regards,
Krzysztof