[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170711104911.wmzmt5fjkzghwljz@sirena.org.uk>
Date: Tue, 11 Jul 2017 11:49:11 +0100
From: Mark Brown <broonie@...nel.org>
To: Tony Lindgren <tony@...mide.com>
Cc: Sebastian Reichel <sebastian.reichel@...labora.co.uk>,
Sebastian Reichel <sre@...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: [PATCH 1/3] ASoC: codec: cpcap: new codec
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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists