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

[Akhil R]

On Sun, 12 Apr 2026 15:33:42 +0200, Krzysztof Kozlowski
> 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".

If I am not wrong, the ask in v1 was to specify the product which this is
getting used - 'Vera' it is. I do not know why you would think it is
unspecific.

As Thierry and Guenter mentioned, the lack of policy and 'mix of both' in
the defconfig makes it quite difficult to understand what could genuinely
be convincing other than putting down every little detail or do a trial
and error.

Anyway, I will describe where each config is getting used in the next
revision - hoping that would help.

Regards,
Akhil