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 ...