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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 25/03/2026 14:05, Thierry Reding wrote:
> On Wed, Mar 25, 2026 at 01:47:44PM +0100, Krzysztof Kozlowski wrote:
>> On 25/03/2026 13:41, Thierry Reding wrote:
>>> On Wed, Mar 25, 2026 at 11:59:36AM +0100, Krzysztof Kozlowski wrote:
>>>> On 25/03/2026 11:31, Thierry Reding wrote:
>>>>> On Thu, Mar 19, 2026 at 06:15:14PM +0100, Krzysztof Kozlowski wrote:
>>>>>> On 19/03/2026 18:09, Akhil R wrote:
>>>>>>> On Thu, 19 Mar 2026 10:40:34 +0100, Krzysztof Kozlowski wrote:
>>>>>>>> On Wed, Mar 18, 2026 at 10:57:25PM +0530, Akhil R wrote:
>>>>>>>>> Add I3C subsystem support, DesignWare I3C master controller, and
>>>>>>>>> SPD5118 hwmon sensor as modules to the defconfig.
>>>>>>>>
>>>>>>>> Why? If there is no user of that, why would we want it? Your commit msg
>>>>>>>> should explain that.
>>>>>>>
>>>>>>> Ack. This is for Tegra410 which has a DesignWare I3C host controller.
>>>>>>> I will add this in the commit message.
>>>>>>
>>>>>> Board or products. Not SoCs.
>>>>>
>>>>> Is this a new requirement? I see a bit of both in defconfig changes.
>>>>
>>>> Almost every review from me has it for 2-3 years... And it is a known
>>>> thing since always in a bit different wording: we do not care about
>>>> downstream things and downstream products. defconfig does not serve
>>>> downstream at all, makes no sense outside of our (upstream) work.
>>>
>>> I don't understand why you're turning this into a downstream vs.
>>> upstream discussion. This is all code that is being submitted upstream,
>>> because we want these new platforms with I3C support enabled upstream.
>>> It's as simple as that.
>>>
>>>>> Some mention specific products, other mention SoCs. Does this
>>>>> requirement apply to DT platforms or also ACPI platforms?
>>>>
>>>> Just like kernel, applies to all platforms, regardless of firmware
>>>> interface.
>>>
>>> Hm... again, I don't think there's every been a rule to the effect of
>>> needing to specify a particular platform or product when adding a new
>>> defconfig change. There's plenty of things that we're enabling in the
>>> defconfigs because we think they are generally useful.
>>
>> And the commit msg MUST always explain WHY we are doing it, in this case
>> - why do you think it is generally useful.
>>
>> If you add new driver, it is usually obvious why it is generally useful.
>>
>> If you add defconfig change for dead stuff, it is not obvious. That's
>> why commit msg must provide arguments WHY do we want it, WHY do you
>> think it is useful for us.
> 
> You're making too many assumptions. What's your basis for calling this
> dead stuff? Do you really think we'd be spending any time on this if it
> wasn't going to get used?

I don't know. That's why the commit msg explains that it is not dead
stuff because we use it here and there.

Let's read the commit msg:

"Add I3C subsystem support, DesignWare I3C master controller, and
SPD5118 hwmon sensor as modules to the defconfig."

Helps nothing.

> 
>> If you add defconfig change for device which no one (in terms of
>> upstream) can use, then automatically it is not useful. Whether this
>> change is like that - I do not know. That's why you have commit msg to
>> provide argument WHY maintainer should take it. And it is as simple as
>> one sentence explaining the upstream kernel user/use case of this
>> defconfig change...
> 
> Again, why are you making this about upstream vs. downstream? The goal
> of these submissions is to make upstream capable of running on real

Up to here:
I do not make it upstream vs downstream. I expressed the same goal as
you here.

> devices that real people want to run (preferably upstream) Linux on.

But here not true. defconfig is ONLY upstream. The purpose of defconfig
is not to give some libraries of configs for downstream trees, because
it is useless for them. All downstreams or distros have their own
defconfigs, thus defconfig role is *only* upstream. I do not make it
"upstream vs downstream", but I make strong requirement of talking here
only about upstream.

Best regards,
Krzysztof