[alsa-devel] [PATCH 1/3] ASoC: codec: cpcap: new codec

[Sebastian Reichel]

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 at kernel.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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20170711/6d84bb0d/attachment.sig>