Re: [RFC PATCH 1/3] ASoC: Add platforms directory

[Andrew F. Davis]

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