linux-kernel - Re: [PATCH 1/3] ASoC: codec: cpcap: new 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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Jul 2017 14:13:31 +0200
From:   Sebastian Reichel <sebastian.reichel@...labora.co.uk>
To:     Mark Brown <broonie@...nel.org>
Cc:     Tony Lindgren <tony@...mide.com>,
        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: [PATCH 1/3] ASoC: codec: cpcap: new codec

Hi,

On Tue, Jul 11, 2017 at 11:49:11AM +0100, Mark Brown wrote:
> On Mon, Jul 10, 2017 at 10:15:41PM -0700, Tony Lindgren wrote:
> > * Mark Brown <broonie@...nel.org> [170710 10:52]:
> 
> > > If this is part of a MFD shouldn't the parent device register it without
> > > it needing to be in the DT?
> 
> > Having the MFD core part just do devm_of_platform_populate() leaves out
> > dependencies between the MFD core and it's child devices.
> 
> > There are also a lot of board specific configuration to be done for many
> > child devices such as ADC wiring, GPIO pins used, and macro firmware
> > usage.
> 
> > Not sure what all board specific stuff needs to be configured for this
> > driver yet, but it seems at least the macro interrupt wiring needs to
> > be configured. I would not be surprised to find GPIOs or ADC being used
> > for some connector detection too.
> 
> We can use subnodes without compatible strings, that's not a problem,
> but having to have compatible strings means we're encoding the way Linux
> splits device drivers up into the DT which might not work for other OSs
> or even future versions of Linux.  For example with CODEC drivers it's
> common to have a good chunk of clock control in there which we might at
> some point want to move over to the clock subsystem.

How is having a subnode without a compatible property different?
Sure we will bind the driver manually and make our code (a little
bit) more complex, but we still encoded the way Linux splits the
device into DT. My understanding is, that adding a node without a
compatible value is almost always not ok.

-- Sebastian

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