lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 Dec 2017 12:49:39 -0600
From:   "Andrew F. Davis" <>
To:     Mark Brown <>
CC:     Liam Girdwood <>, <>,
Subject: Re: [RFC PATCH 1/3] ASoC: Add platforms directory

On 12/06/2017 12:42 PM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 12:13:22PM -0600, Andrew F. Davis wrote:
>> On 12/06/2017 11:29 AM, Mark Brown wrote:
>>> Machine and drivers for SoC internal stuff tend to be bound fairly
>>> closely together, simiarly the various drivers for an IP on a SoC often
>>> know things about each other for various reasons.
>> This is the problem, we don't want them to be so tightly bound, and
>> luckily, for the most part they are not. Even a complex and history rich
>> platform like OMAP was rather trivial to split from its various machine
>> drivers.
> Anything new that can is already getting pushed into using the existing
> generic cards.  New machine drivers are only for things where that's not
> possible.
>>> What I am saying is that they go together very closely.  Moving the code
>>> around isn't going to change that.
>> Not at first, but this partition will discourage future machine-platform
>> mash-ups (like omap-hdmi-audio.c, yuck).
> It's not a pressing problem.
>> My end-goal here is to start trimming the needed machine drivers and
>> replacing them with generics, a couple OMAP machine drivers do nothing
>> that couldn't be done with the "asoc-simple-card" driver. With the
>> machine drivers split out form the platform drivers it becomes easier to
>> target them.
> 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.

>> I don't have any need to group the TI platforms (Davinci / OMAP) right
>> now, but I *have* been thinking about grouping the TI CODECs, they share
>> a lot of code that could be factored out if they were stored in their
>> own space sound/soc/codecs/ti/. Plus it would make it easy to add myself
> You can share code easily enough without moving anything, just make a
> library like the arizona drivers did.

The lack of organization bugs me, this is why directories exist.

>> as a reviewer for them (I seem to be getting a lot of internal support
>> requests for these drivers these days). That can be a re-org for another
>> day, unless you would like me to post an RFC with what I had in mind?
> Wouldn't a few regexps in the MAINTAINERS file cover it?  We've already
> got a bunch of vendors doing this.


It's messy how many prefixes we have :/

>>> If we were going to do this reshuffling then we *really* shouldn't be
>>> doing it randomly for only a few vendors.  Doing it inconsistently is
>>> not going to make anything clearer.
>> I can send patches for rest of the vendors if you would like to see that
>> and what the end result would look like.
> I'm not convinced this is a good idea.

Powered by blists - more mailing lists