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

From: Krzysztof Kozlowski

Date: Mon Apr 13 2026 - 03:13:41 EST


On 13/04/2026 08:57, Akhil R wrote:
>>> 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.

I already said why. Because I Googled it and Google told me it can be
"architecture". And no, you do not use SPD5118 on architecture.

>
> 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.

I think the main problem is that people forgot that commits must answer
WHY you are doing this. Now my assumption is that people sending
defconfigs do not understand why they are doing it, therefore they
cannot explain "why" in commit msg.

Look, find me in following nvidia patches any answers to why this change
is needed:

https://lore.kernel.org/all/20260409131340.168556-7-pshete@xxxxxxxxxx/
https://lore.kernel.org/all/20240829134252.49661-1-jonathanh@xxxxxxxxxx/
https://lore.kernel.org/all/20240509215808.126217-1-bwicaksono@xxxxxxxxxx/

I understand that I can clarify what sort of answers to "why?" I expect.
but lack of such clarification is not excuse to not provide ANY
explanation in commit msg.

Basically it is logic like:
"Uh, I don't how to explain this change, why do we need it, why is it
good, why am I doing that...anyway, let's send it!"

Why doing something in the first place if one does not know the reason
behind?

Best regards,
Krzysztof