Add I3C subsystem support, DesignWare I3C master controller, and
SPD5118 hwmon sensor as modules to the defconfig.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18881bd239f9..5dde063822cb 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -582,6 +582,8 @@ CONFIG_I2C_UNIPHIER_F=y
CONFIG_I2C_XILINX=m
CONFIG_I2C_RCAR=y
CONFIG_I2C_CROS_EC_TUNNEL=y
+CONFIG_I3C=m
+CONFIG_DW_I3C_MASTER=m
CONFIG_SPI=y
CONFIG_SPI_APPLE=m
CONFIG_SPI_ARMADA_3700=y
@@ -761,6 +763,7 @@ CONFIG_SENSORS_SL28CPLD=m
CONFIG_SENSORS_AMC6821=m
CONFIG_SENSORS_INA2XX=m
CONFIG_SENSORS_INA3221=m
+CONFIG_SENSORS_SPD5118=m
CONFIG_SENSORS_TMP102=m
CONFIG_MISC_RP1=m
CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
--
2.50.1On 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. Best regards, Krzysztof
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. Best Regards, Akhil
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. Best regards, Krzysztof
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. Some mention specific products, other mention SoCs. Does this requirement apply to DT platforms or also ACPI platforms? Thierry
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. > 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. Best regards, Krzysztof
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. But alright, we'll either add more details to the commit message, or drop this patch entirely. Thierry
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. 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... Best regards, Krzysztof
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? > 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 devices that real people want to run (preferably upstream) Linux on. Anyway, I think this clarifies some of the questions I posed in my other mail, so we'll go and add more information to this commit message to let you know what products this will be used in. Thierry
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
On 25/03/2026 11:59, 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 And I already explained this to *you* 3 years ago: https://lore.kernel.org/all/ac8f30a7-fc72-9a44-74b3-a69001bfdaaf@linaro.org/ So how this could be a new requirement *now* if three years ago we had exactly same discussion. I understand question for the first time, but why this being brought up as "why is this a new thing" again? Best regards, Krzysztof
On Wed, Mar 25, 2026 at 12:03:37PM +0100, Krzysztof Kozlowski wrote: > On 25/03/2026 11:59, 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 > > And I already explained this to *you* 3 years ago: > > https://lore.kernel.org/all/ac8f30a7-fc72-9a44-74b3-a69001bfdaaf@linaro.org/ > > So how this could be a new requirement *now* if three years ago we had > exactly same discussion. > > I understand question for the first time, but why this being brought up > as "why is this a new thing" again? I have to admit I did not remember what we discussed, so I had to go read that exchange again. It sounds to me like we were not discussing the specific issue of a missing description as to which particular product needed this, but you were instead rejecting the idea of enabling drivers that were not strictly necessary like those for PCI devices because they were making your life more difficult by building drivers by default that you were not interested in. Here you're arguing that you want proof that this is going to be used by some upstream-supported device, which are two different things, because they might very well be drivers that you're not interested in but end up building if documented properly. So I find it a little hard to keep track of what is acceptable to you and what isn't. Are you objecting to this on the grounds of it bloating the kernel build or because you want documentation for what platforms a driver is being used on? Our action items will be different depending on what your answer is: if you want documentation about what device this will be used for, we'll get you that information. If your concern is that it bloats the build we drop the patch and will have to ask users to build their own configurations. Maybe to avoid these kinds of discussions in the past you can write down your rules about what should go into defconfig and what should not. And maybe we can eventually find consensus and find something that people can use as a reference. Thierry
On 25/03/2026 13:58, Thierry Reding wrote: > On Wed, Mar 25, 2026 at 12:03:37PM +0100, Krzysztof Kozlowski wrote: >> On 25/03/2026 11:59, 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 >> >> And I already explained this to *you* 3 years ago: >> >> https://lore.kernel.org/all/ac8f30a7-fc72-9a44-74b3-a69001bfdaaf@linaro.org/ >> >> So how this could be a new requirement *now* if three years ago we had >> exactly same discussion. >> >> I understand question for the first time, but why this being brought up >> as "why is this a new thing" again? > > I have to admit I did not remember what we discussed, so I had to go > read that exchange again. It sounds to me like we were not discussing > the specific issue of a missing description as to which particular > product needed this, but you were instead rejecting the idea of > enabling drivers that were not strictly necessary like those for PCI > devices because they were making your life more difficult by building > drivers by default that you were not interested in. > > Here you're arguing that you want proof that this is going to be used > by some upstream-supported device, which are two different things, > because they might very well be drivers that you're not interested in > but end up building if documented properly. > > So I find it a little hard to keep track of what is acceptable to you > and what isn't. Are you objecting to this on the grounds of it bloating > the kernel build or because you want documentation for what platforms a > driver is being used on? > > Our action items will be different depending on what your answer is: if > you want documentation about what device this will be used for, we'll > get you that information. If your concern is that it bloats the build we > drop the patch and will have to ask users to build their own > configurations. > > Maybe to avoid these kinds of discussions in the past you can write down > your rules about what should go into defconfig and what should not. And > maybe we can eventually find consensus and find something that people > can use as a reference. I think answer is pretty simple and comes from the reason WHAT is the purpose of defconfig. It's purpose is only for us. Therefore defconfig can have anything anyone will find useful, when building and running vanilla upstream kernel on their devices, with exception of explicit needs for pluggable devices because then it bloats the kernel to impossible stage (otherwise look for me sending all USB, PCI, MEDIA, whatever devices for defconfig...). For example: 1. Something used only by a DT board not enabled upstream: no, because you cannot run upstream kernel on it, 2. Something used only by a ACPI platform, which require some out of tree patches to build: no, because you cannot run upstream kernel on it 3. Something not being part of the device but pluggable: depends, explain why upstream contributors would want it. Look at the commit here: "Add I3C subsystem support, DesignWare I3C master controller, and SPD5118 hwmon sensor as modules to the defconfig." Does it say why doing it? No. Nowhere in this posting I was objecting to actual change. At least not yet. I only ask WHY you are doing it. Why is it so hard for a contributor to know and express why they are doing something? If one does not know WHY they are doing it, then why the heck they are doing it? Best regards, Krzysztof
On Thu, 19 Mar 2026 18:15:14 +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. Makes sense. I will have to get that information. Will update. Regards, Akhil
© 2016 - 2026 Red Hat, Inc.