Hi Lars, Mark
My previous mail was missing point...
> > > In my opinion the flags are just as much a hack as the pointer. In an
> > > ideal
> > > setup the component does not need to know what type it is. The reason why
> > > we
> > > need this in ASoC is because the framework has grown over time and we need
> > > to support legacy code.
> >
> > Yes, the pointer is essentially already a flag - having a separate flag
> > really doesn't add a huge amount here. What we need to do is get rid of
> > the need for the flag entirely.
>
> I can agree to remove flag entirely, and actually it is my final target.
> But we need many steps for it IMO.
>
> I would like to cleanup (= remove random pointer) as 1st step.
> My 1st concern is that each struct which want to have codec pointer has
> codec pointer randomly.
> And it makes component cleanup difficult IMO.
>
> 2nd concern is rtd has *codec, *platform, and *dai (for cpu/codec).
> These are different type of pointer.
> If platform can have dummy *dai, we can do like below ?
>
> struct snd_soc_pcm_runtime {
> ...
> struct snd_soc_dai *cpu;
> struct snd_soc_dai *codec;
> struct snd_soc_dai *platform;
> ...
> }
>
> Here, we can get original *codec or *platform by
> using component_to_xxx, because dai already have *component;
> It can be more cleanup ?
I mean current ALSA SoC has duplicate pointer,
and using different type of pointer for CPU/Codec/Platform/Card.
I agree that we would like to have flag-less style.
If my understanding was correct, we can more cleanup struct
relationship if we can exchange pointer style.
I think this is related to flag-less style.
For example, current rtd <-> CPU/Codec/Platform relationship
is using different type of pointer.
It makes flag-less style difficult.
But we can use same type of pointer if we can have dummy dai on platform,
like above idea. Similar idea is for component.
I think this kind of cleanup is needed, and it makes hotplug support easier.
Otherwise, hotplug support will add more random pointer on each struct,
and it makes cleanup more difficult.
# Here, I said "flag-less" style, but maybe we need flag somehow to keep
# current style ? For example I don't think we can have flag-less cristal-clear
# style for CODEC-CODEC support or DPCM etc ...
