Hi Takashi-san Thank you for your feedback > > These are part of "replace snd_soc_read/write to snd_soc_component_read/write" > > patch-set. Full-patch-set will be over 100 patches. > > > > [0/x] - [x-1/x] : ASoC: use snd_soc_component_read/write on xxxx > > [x/x] : ASoC: remove snd_soc_component_read/write > > > > [0/x] - [x-1/x] are almost same patches. > > so, I pickuped few of them for reviewing to avoid patch flood on ML. > > > > If these review were OK, I will post full-patch-set, > > or send git-pull-request. > > > > Main purpose of these patches are replace current snd_soc_read/write > > to snd_soc_component_read/write to remove codec related function. > > I really don't see any big merits by these changes. > What's wrong with keeping as is? The driver is accessing the codec > register, after all. > > For keeping consistency, replacing a few exceptions would be OK. But > replacing hundreds of callers needs a proper justification to do it > so. Now, ALSA SoC is planning to remove "struct snd_soc_codec" and "struct snd_soc_platform", and merge these into "struct snd_soc_component". New ALSA SoC will be based on "component", and additional new feature (= bridge ?). As 1st phase, I would like to cleanup these. my 1st step is removing codec related read/write (= use component read/write), and 2nd step is remove codec probe/remove (= use component probe/remove). and 3rd, 4th... I don't know how many steps are exist. In 2nd phase, ALSA SoC will support more modern design HW as normal style. (Current ALSA SoC needs complex feature for it, like DPCM) Lars-Peter is considering about 2nd phase, but it will be after 1st phase. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
