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:   Fri, 16 Feb 2018 15:16:09 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Sebastian Reichel <sebastian.reichel@...labora.co.uk>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Tony Lindgren <tony@...mide.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 1/4] dt-bindings: sound: add motorola,cpcap-audio-codec

On Fri, Feb 16, 2018 at 03:12:37PM +0100, Sebastian Reichel wrote:
> On Fri, Feb 16, 2018 at 01:44:48PM +0000, Mark Brown wrote:
> > On Fri, Feb 16, 2018 at 02:25:38PM +0100, Sebastian Reichel wrote:

> > > While it looks empty in the DT binding file, it's actually not empty
> > > once some standard properties are added to support audio-graph-card.

> > This tells me you're missing something in the binding defining the
> > DAIs and...

> Well it is described by the following document:

> Documentation/devicetree/bindings/sound/audio-graph-card.txt

You still need to say which DAIs exist on the device and how they are
identified - if there's only one DAI it's obviously easy but if a device
has multiple DAIs then there's some naming to do.

> > ...that still doesn't require a compatible here.

> I agree, that it's not required. Also the node is not required.
> Everything could be dumped into the main node. Many things are
> not required, but they make implementations easier and help in
> regards to DT readability and consistency. Having the compatible
> means, that all sub-functions _can_ be handled equally by the
> operating system. Not having the compatible means you _always_
> need special handling for the audio codec. This basically makes
> the codec node different for the simple purpose of "because it is
> not strictly required". If we have a compatible node, other
> operating systems can still decide to ignore it, right?

It's not just other operating systems, it's also other versions of
Linux we have to think about here.  The most obvious issue with audio is
the clocking where the division between ASoC and clock APIs is not super
obvious and could easily change in the future.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ