Thanks for the review.
+++ b/sound/soc/sof/intel/shim.h
@@ -0,0 +1,159 @@
...
+extern struct snd_sof_dsp_ops sof_byt_ops;
+extern struct snd_sof_dsp_ops sof_cht_ops;
These two symbols are found in this patch.
+extern struct snd_sof_dsp_ops sof_hsw_ops;
This symbol is added in second patch and this first patch has
no reference to it.
+extern struct snd_sof_dsp_ops sof_bdw_ops;
This symbol is added in third patch and this first patch has
no reference to it.
+
+#endif
I think it better to add these extern declarations when adding
corresponding symbols (Of course no issues as is).
Yes, that's no big deal. It won't break as is though since the build is
added in the last patch.
Furthermore, if you have no plan to change contents of these symbols in
kernel run time, it's better to have 'const' qualifier to locate the
symbol to readonly section. However, user of these symbols is machine
driver and you have a plan to implement it later. They can get 'const'
when you work for arrangement of existent/new codes.
Good point, I don't think the ops are changed, ever. I'll double-check
and change if indeed this is the case, thanks for the suggestion.
In this meaning, it might be good to add a new member to 'struct
snd_soc_acpi_mach' for new drivers to refer to the const ops, then
'pdata' member is used from the existent drivers.
Sorry, I don't get your point. the ops structure is included in the
sof_ops_table, not the snd_soc_acpi_mach.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
