Re: [PATCH v5 04/14] dt-bindings: media: qcom,venus: Remove clock, power-domain, and iommus from common schema

[Krzysztof Kozlowski]

On 13/05/2026 20:54, Vishnu Reddy wrote:
> 
> On 5/13/2026 6:59 PM, Dmitry Baryshkov wrote:
>> On Sat, May 09, 2026 at 10:34:15PM +0530, Vishnu Reddy wrote:
>>> On 5/9/2026 12:52 AM, Dmitry Baryshkov wrote:
>>>> On Sat, May 09, 2026 at 12:29:53AM +0530, Vishnu Reddy wrote:
>>>>> The common schema defines minItems and maxItems for clocks, power-domains,
>>>>> and iommus. This suggests that the number of these resources can vary,
>>>>> while in reality they are fixed constraints per platform.
>>>> It really doesn't. It provides common definitions, while individual
>>>> platform schemas tighten those.
>>> If a new platform requires more resources than the current maxItems listed in
>>> the common-schema (e.g.,Glymur due to its dual vcodec core design), we need
>>> to keep bumping maxItems in the common schema every time a new platform exceeds
>>> the previous limit. That makes the common schema a moving target driven by
>>> platform specific.
>>>
>>> I am fine with increasing maxItems in the common schema instead of removing.
>>> I can set it to a reasonable value (for example, up to 20) so that it
>>> accommodates future platforms without frequent changes. Anyway, each platform
>>> schema must define fixed constraints, since clocks and power-domains are
>>> mandatory per platform.
>>>
>>> Could you please let me know which one you would prefer going forward?
>> Just touch venus-common when new platform requires bigger lists.
> 
> In the v3 series, I followed same approach — bumping maxItems in venus-common
> schema to accommodate the Glymur platform while keeping fixed constraints in
> the Glymur-specific schema:
> https://lore.kernel.org/all/20260428-glymur-v3-2-8f28930f47d3@xxxxxxxxxxxxxxxx/
> 

The approach taken at v3 was correct and I ONLY commented about very
confusing commit msg which told that you relaxed constraints. You must
not relax constraints, so commit msg claiming that you relax them is
obviously incorrect. Each device must have a fixed, as in non-relaxed,
constraints, thus making them relaxed (not fixed) is wrong.

Best regards,
Krzysztof