linux-kernel - Re: [PATCHv4 1/4] dt-bindings: sound: add motorola,cpcap-audio-codec

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] [day] [month] [year] [list]

Message-ID: <20180223124720.wntxfitr5iu35osb@earth.universe>
Date:   Fri, 23 Feb 2018 13:47:20 +0100
From:   Sebastian Reichel <sebastian.reichel@...labora.co.uk>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        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

Hi,

On Thu, Feb 22, 2018 at 11:54:19AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@...nel.org> [180219 12:05]:
> > On Fri, Feb 16, 2018 at 07:57:07AM -0800, Tony Lindgren wrote:
> > > One advantage of using a compatible property for the pmic subdevices
> > > though is that it leaves out a dependency between various device
> > > drivers things happen automagically. The mfd core driver can be
> > > minimal and just implement interrupt handling and regmap. So no need
> > > to to parse the child nodes in the pmic mfd driver :)
> > 
> > There's no need to do that anyway - with a MFD the child devices can
> > assume that they're part of the MFD and reference their parent.
> > 
> > > So personally I'd prefer the option that requires least amount
> > > of custom code if compatible vs no compatible property is the
> > > only issue here.
> > 
> > It's a few lines of code to register the child devices from code rather
> > than the DT, and keeps it out of the ABI.
> 
> OK yeah that's a good point with avoiding the ABI. Seems
> we still want the dts child node(s) though. That way audio
> device can be disabled for devices where audio is not wired
> up at all on this PMIC.

We need something to identify the correct child node. If there
is no compatible, the node name will become ABI. So I don't
think we gain anything by removing the compatible. As far as
I can see it seems to be unusual to use fixed node names. I
could find some examples, but most sub-devices are identified
using compatibles. This method also has direct support in MFD
(using .of_compatible in mfd_cell).

Based on a bit of grepping through drivers/mfd/, the node name
based identification seems to be mainly used by ASoC, while most
other subsystems seem to prefer compatible based identification.

Anyways, I have implemented the node name based identification and
will post patches once I fixed the enum issue. I will probably
send them later today.

-- Sebastian

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