[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <224d1d98-5d6f-515e-feef-a1ebf20a90d9@linaro.org>
Date: Thu, 31 Mar 2022 10:26:07 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Martin Povišer <povik@...ebit.org>
Cc: Martin Povišer <povik+lin@...ebit.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Mark Kettenis <kettenis@...nbsd.org>,
Hector Martin <marcan@...can.st>,
Sven Peter <sven@...npeter.dev>
Subject: Re: [RFC PATCH 1/5] dt-bindings: sound: Add Apple Macs sound system
On 31/03/2022 10:23, Martin Povišer wrote:
>
>> There should be some maximum of supported codecs. Hardware might have
>> such constraints. If really unsure, choose some reasonable (small)
>> amount. It could be later raised, if needed.
>
> There are some constraints but technically not in the driver that binds
> on this binding. I thought no limit is better than an arbitrary one, but
> if the preference is to have one, I will add it, no problem.
Just to clarify this - bindings are not about the driver, but about the
hardware. We model here the hardware and its programming model, not the
driver implementation (although of course it's always somehow related).
Hardware has some limitations for sure. The question is whether we know
them. :)
I prefer even arbitrary limit, because then schema will check DTSes for
simple mistakes. You can also explain this in commit msg, that maxItems
are arbitrary, so whoever in the future wants to change it, will know
the background.
Best regards,
Krzysztof
Powered by blists - more mailing lists