Hi Pierre-Louis
If sound card dirver is using "modern style", both codec/platform are using it. So this patch judges it as "modern style" if there is no settings for codec_name codec_of_node codec_dai_name platform_name platform_of_node
Doesn't this prevent a gradual dailink transition where e.g. the platform_name is removed first and then the codec_name/codec_dai_name is removed second?
I'm thinking transition to modern from legacy for "normal drivers" will be like this
1) will happen after multi-CPU was supported 2) Transit everything (= CPU/Codec/Platform) by 1 patch for each drivers, not gradual transition (= Mark / Lars doesn't like this style). 3) If you need/want to gradual transition (= like simple-card, audio-graph), unfortunately, it will be full responsibility for your action.
Yes, it is selfish, but is very difficult to prevent all cases in this case. So I think we need to have some rule for transition. Or, other idea is that transit all drivers first without this patch, and add support "no Platform" 2nd. In this case, it will be easier, but will needs many patches. I'm not sure which one is best.
I started doing the transition in steps changing all dailinks with platform and codec/codec_dai names at once is quite invasive and possibly error prone. Specifically for Intel machine drivers, the codec names are heavily tweaked to align with the actual ACPI name, not the hard-coded one, and that should be tested independently if possible. Same for codec_dai_names, they depend on quirks.
Yeah agree. I think transit to modern style on magical (= non hard-coded) platform will be trouble... I'm thinking that transition patch need to be tested/confirmed before removing legacy style for its safety
1) transit "hard-coded" platform first, and confirm modern style behavior. 2) if no problem happen on 1) step, transit "magical" platform 2nd step. will have few/some problem, fixup step-by-step.
These are my opinion, but I want to know your and Mark's idea. I can adjust/follow to it.
Best regards --- Kuninori Morimoto