On 23/01/2023 16:58, Thierry Reding wrote:

On Fri, Jan 20, 2023 at 06:00:25PM +0100, Krzysztof Kozlowski wrote:

quoted

On 20/01/2023 17:56, Catalin Marinas wrote:

quoted

On Fri, Jan 20, 2023 at 07:20:01AM +0100, Krzysztof Kozlowski wrote:

quoted

On 20/01/2023 06:48, Mohan Kumar D wrote:

quoted

On 18-01-2023 18:06, Krzysztof Kozlowski wrote:

quoted

External email: Use caution opening links or attachments
On 18/01/2023 12:46, Mohan Kumar D wrote:

quoted

On 18-01-2023 13:04, Krzysztof Kozlowski wrote:

quoted

External email: Use caution opening links or attachments
On 17/01/2023 19:16, Mohan Kumar wrote:

quoted

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

We enable drivers for devices present in our platforms. Everything which
is on such platforms. For pluggable USB/PCI/whatever third-party
devices, then comes the argument as boot-related.

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.

Yep and this one here is nowhere near that architecture. It's pluggable
card, not related to hardware nor arm64 (If I understood correctly). Why
you do not enable it on x86? Or multi_v7? or hundreds of other defconfigs?

quoted

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.

I am sorry, but adding new stuff does not require arguments against.
Adding new stuff requires argument for it. You reverse the argumentation
that I need to find proves that we do not need it in mainline platforms,
if I got your response correctly.

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.

I don't think we discuss the same thing. There are no extremes here at
all. The patch is about enabling arm64-unrelated PCI pluggable device,
just because it came from @nvidia.com author. If you think some PCI
pluggable 3rd party device is suitable for defconfig, I will bring
hundreds of other drivers I am also plugging over PCI to my boards, just
because I want some audio.

It's not reasonable path...

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel