Mark,
On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown broonie@kernel.org wrote:
On Wed, Feb 18, 2015 at 07:25:58PM +0100, Andreas Färber wrote:
static const struct of_device_id snow_of_match[] = {
{ .compatible = "google,snow-audio-max98089", }, { .compatible = "google,snow-audio-max98090", }, { .compatible = "google,snow-audio-max98091", }, { .compatible = "google,snow-audio-max98095", },Since we completely ignore the CODEC in the property might it not be better to just add a plain old snow-audio compatible and bind to that, that way we don't need these driver updates? Just the "snow" bit should be enough to know it's one of this class of machines.
I think what you're suggesting is that here we should add a new compatible string "google,snow-audio" instead of adding "google,snow-audio-max98089" here. Then the sound node in the spring DTS would look like:
compatible = "google,snow-audio-max98089", "google,snow-audio";
That would allow us to later figure out that we're on a board with max98089 in case it became important but means that any other minor tweaks like this wouldn't need anything special. I haven't tried that to make sure that the fallback compatible string actually works in this case, but it seems like the right way to go...
Sound good?
-Doug