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

lists.openwall.net		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 18:42:19 +0000
From:   Mark Brown <broonie@...nel.org>
To:     "Andrew F. Davis" <afd@...com>
Cc:     Liam Girdwood <lgirdwood@...il.com>, alsa-devel@...a-project.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/3] ASoC: Add platforms directory

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.

> 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.

> 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.

> > 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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)