Re: [PATCH v2] arm64: defconfig: Enable HDA INTEL config for ARM64

[Thierry Reding <treding@nvidia.com>]

[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]

On Fri, Jan 20, 2023 at 06:00:25PM +0100, Krzysztof Kozlowski wrote:
> On 20/01/2023 17:56, Catalin Marinas wrote:
> > On Fri, Jan 20, 2023 at 07:20:01AM +0100, Krzysztof Kozlowski wrote:
> >> On 20/01/2023 06:48, Mohan Kumar D wrote:
> >>> On 18-01-2023 18:06, Krzysztof Kozlowski wrote:
> >>>> External email: Use caution opening links or attachments
> >>>> On 18/01/2023 12:46, Mohan Kumar D wrote:
> >>>>> On 18-01-2023 13:04, Krzysztof Kozlowski wrote:
> >>>>>> External email: Use caution opening links or attachments
> >>>>>> On 17/01/2023 19:16, Mohan Kumar wrote:
> >>>>>>> Enable CONFIG_SND_HDA_INTEL for NVIDIA PCI based graphics sound card for
> >>>>>>> ARM64 based platforms as Intel PCI driver was used for registering the
> >>>>>>> sound card.
> >>>>>> It's not a part of SoC, not a common device used during debugging or
> >>>>>> development, so I don't think it is reasonable to enable it. We do not
> >>>>>> enable driver just because someone uses them. Otherwise please clarify
> >>>>>> which board has this device embedded (not pluggable by user, but embedded).
> >>>>> This change is required for enabling HDA sound registration for Nvidia
> >>>>> discrete GPU cards based on PCI and pluggable to Nvidia Jetson Platforms.
> >>>> You can plug anything to PCI slot and we do not enable every such PCI
> >>>> adapter.
> >>> Without this config enabled, the Intel hda audio driver won't be built 
> >>> and dGPU won't be able to register sound card. Do you have any 
> >>> suggestion here?
> >>
> >> Without hundreds of other drivers they also won't be built and won't be
> >> usable. Anyway, this is just defconfig, so it does not matter. You can
> >> always enable it in your setup, why is this a problem?
> >>
> >> Again, we do not enable drivers for every PCI card.
> > 
> > I don't think we have any set rules for what goes in a defconfig. If one
> > has a real use-case, we tend to enable stuff in defconfig, especially if
> > it's a module.
> 
> There will be always an use case for every PCI and USB card. It's not
> related to storage or networking which could justify device bringup
> (rootfs). It's really not needed for any board operation. defconfig is
> not for marketing products but for our development and reference platforms.

If defconfig were only for boot-critical drivers, it's terribly bloated
as it is. We enable things like multimedia, infrared and audio. None of
those are critical to booting a system. Heck, we also enable most of
DRM/KMS, which are useful for boot on consumer devices, but are rarely
critical on development and reference platforms.

Besides, a PCI board can be considered a development platform depending
on who you are.

I've always looked at defconfig as more of a guideline as to what's a
useful baseline configuration for an architecture.

> The only argument behind this change is "I have a PCI card and I want it
> in defconfig", but why it has to be in defconfig in the first place?
> There is no reason. This is not distro...

That's highly subjective and honestly that argument can go in both
directions. People can, after all, start from an allnoconfig and then
work their way up to something that's usable on their particular device.
Or they could start from an allmodconfig and work their way down.

The point of defconfig is to give you something that's somewhere between
the two extremes. Obviously if we start enabling everything, it defeats
that purpose. If we prohibit the enablement of new options, we equally
limit its usefulness.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]