Andreas,
On Thu, Feb 19, 2015 at 9:56 AM, Andreas Färber <afaerber@xxxxxxx> wrote:
> Am 19.02.2015 um 18:44 schrieb Doug Anderson:
>> 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";
>
> 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
--
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
