[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160119122524.GM6588@sirena.org.uk>
Date: Tue, 19 Jan 2016 12:25:24 +0000
From: Mark Brown <broonie@...nel.org>
To: Johan Hovold <johan@...nel.org>
Cc: Michael Trimarchi <michael@...rulasolutions.com>,
Jacob Siverskog <jacob@...nage.engineering>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Liam Girdwood <lgirdwood@...il.com>,
"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] ASoC: pcm179x: Add I2C interface driver
On Mon, Jan 18, 2016 at 05:56:57PM +0100, Johan Hovold wrote:
> On Mon, Jan 18, 2016 at 05:14:42PM +0100, Michael Trimarchi wrote:
> > > + { .compatible = "ti,pcm1792a", },
> > > + { }
> > > +};
> > > +MODULE_DEVICE_TABLE(of, pcm179x_of_match);
> > can match go in the common part?
> For matching purposes it could, but that would prevent the OF-aliases
> from being defined for the driver modules.
> There are a couple of codec drivers that have taken this route, and it
> works as long as they also define a legacy (e.g. i2c_device_id) table
> that modalias autoloading can fall back to.
> But having having the common module carry the OF-aliases does not seem
> like the right thing to do (e.g. as the common module cannot drive
> anything on its own) even if it avoids a copy of the OF id table.
This does seem like something that the modules code should be able to
cope with - we have a reference from the driver struct to the table
which you'd really expect it to be using. We already have some issues
there with userspace not handling multiple modaliases terribly well IIRC.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists