On Mon, Apr 13, 2026 at 10:49:50AM +0100, Jon Hunter wrote:
> 
> On 10/04/2026 09:25, Jon Hunter wrote:
> > 
> > 
> > On 10/04/2026 07:37, Krzysztof Kozlowski wrote:
> > > On 09/04/2026 15:13, pshete@nvidia.com wrote:
> > > > From: Prathamesh Shete <pshete@nvidia.com>
> > > > 
> > > > Building the Pinctrl driver into the kernel image increases its size.
> > > 
> > > That's obvious.
> > > 
> > > > These drivers are not required during early boot, build them as
> > > > a loadable
> > > > module instead to reduce the kernel image size.
> > > 
> > > So you replace built-in into module?
> > > > 
> > > > Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
> > > > ---
> > > >   arch/arm64/configs/defconfig | 2 ++
> > > >   1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > > > index dd1ac01ee29b..f525670d3b84 100644
> > > > --- a/arch/arm64/configs/defconfig
> > > > +++ b/arch/arm64/configs/defconfig
> > > > @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
> > > >   CONFIG_PINCTRL_SM8550_LPASS_LPI=m
> > > >   CONFIG_PINCTRL_SM8650_LPASS_LPI=m
> > > >   CONFIG_PINCTRL_SOPHGO_SG2000=y
> > > > +CONFIG_PINCTRL_TEGRA238=m
> > > > +CONFIG_PINCTRL_TEGRA264=m
> > > 
> > > No, you just added as module. Why do we want them in upstream defconfig?
> > > 
> > > Standard question, already asked Nvidia more than once.
> > 
> > Yes :-)
> > 
> > Prathamesh, what we need to do is ...
> > 
> > 1. Add a patch to populate the pinctrl DT nodes for Tegra264 device.
> > 2. In this patch, only enable pinctrl for Tegra264 because we are
> >     lacking an upstream board for Tegra238 for that moment. In the commit
> >     message we should add a comment to indicate with Tegra264 platform is
> >     using this.
> 
> Thinking about this some more, I think I would prefer that we skip the
> defconfig patch and just add ...
> 
>  default m if ARCH_TEGRA_238_SOC
> 
>  default m if ARCH_TEGRA_264_SOC
> 
> ... in the respective Kconfig files for the drivers.

I know some people have objected to this type of construct in the past
because it means that you automatically enable these drivers in configs
where it previously wasn't, bloating people's test builds, etc.

I also know that people don't like it when we add seemingly random
options to defconfig.

For this particular case, given that the options are dependent on the
per-SoC Kconfig symbols I think the "default m" above is a fair
compromise.

Thierry