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:13:22 -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 11:29 AM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 10:06:34AM -0600, Andrew F. Davis wrote:
>> Your wording seems a bit inconsistent to me, what do you mean by "IP
>> drivers", CODEC or SoC internal IP? For clarity I'll try to use only the
>> three driver type labels: codec, platform, and machine. This is all in
>> Documentation/sound/soc/overview.rst which I'm sure you are familiar
>> with as you seem to have had a hand in writing it.
> IPs in SoCs.
>> Anyway, I'm working under the assumption that we should try to enforce a
>> logical separation between component drivers: codec drivers should be
>> agnostic to what machine they are placed, platform drivers should do the
>> same and not make special arrangements to work with one machine in
>> particular. Machine drivers on the other hand will need to dig into
>> specifics of the codec and platform drivers that they use and connect.
> 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

>> With this in mind I do not see any reason not to have platform drivers
>> in a platforms/ directory just like we do with codecs/. In case there
>> was any confusion, I still want to keep the platform drivers' files all
>> grouped in directories by IP holder, just moved under this platforms/.
> Moving everything around is at the very least going to be a pain for
> anyone doing backports and anyone actively working on patches, splitting
> the machine drivers from the rest of the drivers for systems based on
> that SoC means it's going to be a little harder for people to find
> relevant system specific machine drivers.  Generic machine drivers are
> already split out.
> Any benefits seem very weak here and it's an awfully disruptive change.

While it may still be a small pain for people currently building patches
against the old structure, for back-ports, git seems to handle these
renames well and follows the file patches back to the old location.

>> This has the benefit of reducing exactly what you are talking about,
>> platform drivers working in concert with machine drivers, instead of the
>> other way around.
> 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).

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.

>> This isn't only confusing to me, but other first time ASoC devs:
> I rather suspect the confusion they're having is more to do with the
> fact that the documentation isn't very good than it is to do with where
> the files are.

The documentation wont have to explain why platform and machine drivers
are mashed together in top-level directories if we fix this here :)

>> even the answerer seems to assume there is a
>> sound/soc/platforms/, for the same reason we have sound/soc/codecs/.
> Or possibly just because they're not very familiar with what they're
> talking about here.

That does seems to be the case, but the assumption was still that a
partitioning should exist.

>>> If you want to make a common directory for TI stuff do that, there's no
>>> need to mess up all the other platforms to do that though.
>> Do you mean sounds/soc/ti/{platforms,machines}/ ? I could do this, but I
>> don't see how what I've done in my example patches has any effect on
>> other IP holders, they are free to migrate as the please.
> Oh, right.  Your commit message sounded like you wanted to dump
> everything into a single directory for all SoC side drivers which
> doesn't seem like an obviously useful thing, my best guess had been that
> you were trying to get all the TI drivers into one directory.  I don't
> see a pressing need to do that, but I can see it might potentially be
> causing issues for people.

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

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

Powered by blists - more mailing lists