Andreas,
On Thu, Feb 19, 2015 at 9:56 AM, Andreas Färber afaerber@suse.de wrote:
Am 19.02.2015 um 18:44 schrieb Doug Anderson:
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";
If we want to be specific just in case, was it an active decision not to use "google,peach-pi[t]-audio-max98..."?
Again, either way works for me.
I don't think it was an active decision, but I am certainly nowhere near an audio expert and I don't think I made that particular decision (I could be wrong).
One could make the argument that "snow" describes the general hookup style of the hardware and then you list the actual codec after that, but that's a pretty weak argument...
-Doug