On 12/06/2017 01:27 PM, Mark Brown wrote: > On Wed, Dec 06, 2017 at 12:49:39PM -0600, Andrew F. Davis wrote: >> On 12/06/2017 12:42 PM, Mark Brown wrote: > >>> We need to preserve old bindings to ensure DT compatiblity, the easiest >>> way to do that is to keep old machine drivers around. There are plenty >>> of older drivers that wouldn't be accepted now but would at least need >>> replacing with a compatibility layer that adapts the bindings onto one >>> of the generic drivers. That adaption layer would definitely be useful >>> (basically a big table of platform data) but it'd take time to implement >>> it. > >> We then should at least start depreciating them now so that someday we >> can drop that stuff. Isolating them would be the first step. > > Moving the drivers around is not going to help with that. For users the > drivers are not deprecated until someone actually steps up and makes > something that allows the generic drivers to handle the old bindings and > moves them over, at which point we'd just remove things that have been > converted. We can't just tell them not to use something without > providing an alternative. For developers they're just going to end up > with the simpler machine drivers sitting next to a bunch of machine > drivers that reasonably exist which I'm not sure clarifies anything. > It's an orthogonal problem. > It helps in that people would see an organized set of drivers to target, "this folder here (sound/soc/machines/) should be reduced as much as possible". Otherwise it is just, "go dig around for the machine drivers burred together with platform drivers, which file is which type? Who knows!?" I will help too, but there needs to be just a bit of organization first. >>> Wouldn't a few regexps in the MAINTAINERS file cover it? We've already >>> got a bunch of vendors doing this. > >> pcm* >> tas* >> tlv* >> twl* > >> It's messy how many prefixes we have :/ > > Eh, not that bad. And easy enough to do anyway. > And it is easy enough to group them into a directory by something like vendor, same as everyone else, including your very own sound/soc/. Yet codecs/ is a giant 400+ file blob, by C file count it is the largest directory in the whole kernel... Top 10: C files count: folder 130: drivers/staging/comedi/drivers 145: drivers/gpio 159: drivers/watchdog 164: drivers/rtc 165: drivers/hwmon 172: net/netfilter 175: drivers/acpi/acpica 194: lib 201: drivers/mfd 239: sound/soc/codecs Maybe a bit of grouping wouldn't be so bad _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
