Mark,
On Thu, Feb 19, 2015 at 1:44 AM, Mark Brown <broonie@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
