| Message ID | 87sgt7p3zo.wl-kuninori.morimoto.gx@renesas.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: modern dai_link style support | expand |
Hi Morimoto-san, > These are for modern dai_link style support patches. > [001/145] adds missing modern dai_link style for CPU. > and others are switch to modern style from legacy style. > Last patch removes legacy style. > > These are based on mark/for-5.3 + v5.2-rc1 > > I hope these work well for all sound card, but I can't test for all. > Please test these at each sound cards. We're testing for Intel stuff w/ SOF. One question: I try to enforce the use of checkpatch --strict to avoid different styles in the Intel contributions, and your series generates a ton of alignment warnings, e.g. CHECK: Alignment should match open parenthesis #45: FILE: sound/soc/intel/boards/sof_rt5682.c:373: + links[id].cpus->dai_name = devm_kasprintf(dev, GFP_KERNEL, "ssp%d-port", CHECK: Alignment should match open parenthesis #81: FILE: sound/soc/intel/boards/glk_rt5682_max98357a.c:378: +SND_SOC_DAILINK_DEF(idisp3_codec, + DAILINK_COMP_ARRAY(COMP_CODEC("ehdaudio0D2", "intel-hdmi-hifi3"))); I am not too religious on style as long as there is a style. I'd be fine if the expectation is that all the dailink definitions use a tab for readability (and it's a one-time change), but would like the functional code changes to be aligned to avoid future warnings. Would that work for you? I can send you the Intel changes if that helps. Thanks -Pierre
Hi Pierre-Louis Thank you for your feedback and test ! > > [001/145] adds missing modern dai_link style for CPU. > > and others are switch to modern style from legacy style. > > Last patch removes legacy style. > > > > These are based on mark/for-5.3 + v5.2-rc1 > > > > I hope these work well for all sound card, but I can't test for all. > > Please test these at each sound cards. > > We're testing for Intel stuff w/ SOF. Thanks ! I hope it works well > One question: I try to enforce the use of checkpatch --strict to avoid > different styles in the Intel contributions, and your series generates > a ton of alignment warnings, e.g. > > CHECK: Alignment should match open parenthesis > #45: FILE: sound/soc/intel/boards/sof_rt5682.c:373: > + links[id].cpus->dai_name = devm_kasprintf(dev, GFP_KERNEL, > "ssp%d-port", > > CHECK: Alignment should match open parenthesis > #81: FILE: sound/soc/intel/boards/glk_rt5682_max98357a.c:378: > +SND_SOC_DAILINK_DEF(idisp3_codec, > + DAILINK_COMP_ARRAY(COMP_CODEC("ehdaudio0D2", "intel-hdmi-hifi3"))); > > I am not too religious on style as long as there is a style. > I'd be fine if the expectation is that all the dailink definitions use > a tab for readability (and it's a one-time change), but would like the > functional code changes to be aligned to avoid future warnings. > Would that work for you? I can send you the Intel changes if that helps. Ahh, yes, it is using 1 tag only and not aligned to open parenthesis. But, if it aligned to open parenthesis, then, it will be 80 char over warning instead. # ?? or does your "functional code changes" means "fixup checkpatch.pl" ? But, yes, can you send me the changes ? Thank you for your help !! Best regards --- Kuninori Morimoto
> Ahh, yes, it is using 1 tag only and not aligned to open parenthesis. > But, if it aligned to open parenthesis, then, it will be 80 char over > warning instead. > # ?? or does your "functional code changes" means "fixup checkpatch.pl" ? > > But, yes, can you send me the changes ? I'll send you suggested changes, I saw other cases where we want to use dmic_codec instead of dmic01_codec. Small potatoes really, this is a really nice work you've been doing!