Hi Lars, Mark > > > Current "codec" has its .probe/.remove, and "component" has it too. > > > codec side is just relayed it to component side. > > > This is the time to cleanup. > > > While for the widgets, routes and controls it did not really matter, I do > > not think this is the right approach for probe and remove. > > > This is kind of sub-classing a normal design pattern found all throughout > > the kernel. You have a generic callback function and a specialized callback > > function that takes the type of the object that is being worked on rather > > than the generic object type. > > I tend to agree here - look at struct device_driver for example, it has > a bunch of callbacks that are in practice rarely used because each > subsystem defines subsystem specific versions that are going to be much > more appropriate for most drivers. This sort of refactoring tends to > make more sense when it's done with pure data (as for your previous > series). Thank you for your feedback. My understanding is that current "codec" is already part of "component", and new ASoC controls "component" only. This means, if we switches to new ASoC style, it can't call "codec" side callback ? Indeed my patch-set is using/keeping "codec" pointer, but it is each driver's matter, ASoC framework side doesn't care about it. This is my understanding. - ASoC will care only "component" - driver can use "codec" which is part of "component" - "Platform", "CPU" etc use same style (= component base). This case, we can keep using current "codec" struct without big change. But it seems your opinion is like this ? - ASoC will care only "component" (same as my opinion) - This "component" includes all features (= Codec feature, CPU feature, Platform feature, etc) Anyway, I don't want to create new issue on ASoC. It seems we (or only me ?) still don't have cristal clear big-picture (?) If so, my previous patch-set might make new style switching difficult. Mark, because of this reasons, is it possible to remove my previous patch-set (= topic/codec-component) from your repository ? Incomplete big-patch-set will cause new trouble. I want to cleanup ASoC, but I want to do it under cristal clear agreement. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
