[alsa-devel] [PATCH] ASoC: SOF: Intel: add PCI ID for CometLake-S

[Takashi Iwai]

On Wed, 18 Dec 2019 20:01:55 +0100,
Pierre-Louis Bossart wrote:
> 
> 
> 
> >>>>> Then the issue I pointed above can be solved as well.
> >>>>
> >>>> The ifdefs are still needed in the PCI IDs tables
> >>>
> >>> Yes, but it halves the messes :)
> >>
> >> I wish it was true :-)
> >>
> >> In reality having buildbots play with kconfig options does help
> >> identify issues at the code level, just like the namespace use helped
> >> identify the .arch_ops just above did not belong here.
> >> I find it's a constant battle to avoid accumulated crud in the wrong
> >> places when dealing with multiple platforms, and when looking at
> >> patches it's very hard (at least for me) to realize where the code
> >> gets added and the implications.
> >
> > But how it can be worse than ifdef...?  From the resultant code POV,
> > it's same, the redundant objects are dropped automatically, while you
> > can avoid a pitfall like this case to forget the counter-part ifdef,
> > which could be identified at first by some randconfig tests.
> 
> In a perfect world it'd be fine.
> But the reviews are not perfect and it happens that we let things go
> through.
> With the _maybe_unused proposal, I would not know which objects are
> not necessary for a specific config, they would be silently removed by
> a tool. Issues reported by randconfig or 'unused variable' warnings
> are painful but at least they do provide a clear hint that something's
> not right (including in my own code).

Well, it's another side of coin.  With the current massive Kconfig and
ifdef, something can be overlooked pretty easily.  A randconfig may
catch it up, but this would be often after the commit.

But it's basically just a minor bikeshed thing.  However, the main
concern is: unless Intel stops producing a newer model, we'll go soon
beyond the amount of Kconfigs we can manage manually.

Usually splitting Kconfig items makes sense if -

- Functionality needs to be selective,
- It reduces the resultant code significantly, or
- Modules to be built can be chosen (and reduces memory footprint)

When looking at the current code, for example, I'm not sure which
category hits the case of Cometlake-S vs Cometlake-H vs
Cometlake-LP...

In short: I'd love to see if Kconfigs can be reduced as much as
possible.  It'll make our life easier for users, including distros, in
the end.


thanks,

Takashi