Received-SPF: pass (google.com: domain of linux-kernel+bounces-102971-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <1537d42f-fe61-48c2-9ee2-1066db71a19e@quicinc.com>
Date: Thu, 14 Mar 2024 13:58:21 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 2/3] dt-bindings: iio: adc: Add support for QCOM PMIC5
 Gen3 ADC
Content-Language: en-US
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, <jic23@kernel.org>,
        <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
        <conor+dt@kernel.org>, <andersson@kernel.org>,
        <konrad.dybcio@linaro.org>, <lee@kernel.org>,
        <andriy.shevchenko@linux.intel.com>, <daniel.lezcano@linaro.org>,
        <dmitry.baryshkov@linaro.org>
CC: <lars@metafoo.de>, <luca@z3ntu.xyz>, <marijn.suijten@somainline.org>,
        <agross@kernel.org>, <sboyd@kernel.org>, <rafael@kernel.org>,
        <rui.zhang@intel.com>, <lukasz.luba@arm.com>,
        <linus.walleij@linaro.org>, <quic_subbaram@quicinc.com>,
        <quic_collinsd@quicinc.com>, <quic_amelende@quicinc.com>,
        <quic_kamalw@quicinc.com>, <kernel@quicinc.com>,
        <linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
        <linux-arm-msm-owner@vger.kernel.org>, <linux-iio@vger.kernel.org>,
        <linux-pm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <cros-qcom-dts-watchers@chromium.org>
References: <20231231171237.3322376-1-quic_jprakash@quicinc.com>
 <20231231171237.3322376-3-quic_jprakash@quicinc.com>
 <3f812ffa-ec33-448e-b72a-ce698618a8c1@linaro.org>
 <13f2b558-a50d-44d3-85de-38e230212732@quicinc.com>
 <f52b2d5e-b2b4-48ae-a6a6-fc00c89662d2@linaro.org>
 <0b9e807d-e0ca-411c-9a2b-3d804bdf168c@quicinc.com>
 <d3dc9a41-4738-4634-9a98-fefcf418f552@linaro.org>
From: Jishnu Prakash <quic_jprakash@quicinc.com>
In-Reply-To: <d3dc9a41-4738-4634-9a98-fefcf418f552@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Krzysztof,

On 2/21/2024 12:49 PM, Krzysztof Kozlowski wrote:
> On 21/02/2024 06:36, Jishnu Prakash wrote:
>> Hi Krzysztof,
>>
>> On 2/17/2024 7:43 PM, Krzysztof Kozlowski wrote:
>>> On 16/02/2024 11:39, Jishnu Prakash wrote:
>>>> Hi Krzysztof,
>>>>


>>
>>> How is this a problem?
>>
>> In qcom,spmi-vadc.yaml, we have the following top-level constraints for
>> the "reg" and "interrupts" properties:
>>
>>     reg:
>>       maxItems: 1
>>
>>     interrupts:
>>       maxItems: 1
>>
>> For the ADC5 Gen3 device being added now, these constraints cannot be
>> followed always, as there may be more than one peripheral under one
>> device instance, each with a corresponding interrupt. For example, the
>> above properties could be like this for a ADC5 Gen3 device:
>>
>>       reg = <0x9000>, <0x9100>;
>>       interrupts = <0x0 0x90 0x1 IRQ_TYPE_EDGE_RISING>,
>>                    <0x0 0x91 0x1 IRQ_TYPE_EDGE_RISING>;
>>
>>
>> I could not overwrite the top-level constraints for the new device
>> "qcom,spmi-adc5-gen3" alone in qcom,spmi-vadc.yaml, so I tried to remove
>> the constraints from the top level and add them back conditionally for
>> all the device types separately, but you told me not to remove them
>> (full message:
>> https://lore.kernel.org/linux-iio/832053f4-bd5d-4e58-81bb-1a8188e7f364@linaro.org/)
> 
> Because top-level widest constraints must stay, but it is not a problem.
> Most of the multi-device bindings work like this. Dozen of Qualcomm. Why
> you cannot do this the same way we do for all Qualcomm devices?
> 

I would like to clarify a point with you related to the top-level 
constraints, as I think I have not asked this exact question earlier.

For these top-level constraints in qcom,spmi-vadc.yaml:

     reg:
       maxItems: 1

     interrupts:
       maxItems: 1

If we add ADC5 Gen3 bindings in the same file, is it acceptable to 
update the top-level constraints to something like this:

     reg:
       minItems: 1
       maxItems: 2

     interrupts:
       minItems: 1
       maxItems: 2

followed by updating maxItems back to 1 for all the earlier existing 
compatibles, using if:then: conditions, like the below example?

   - if:
       properties:
         compatible:
           contains:
             const: qcom,spmi-adc5

     then:
       properties:
         reg:
           maxItems: 1
         interrupts:
           maxItems: 1


If this is acceptable, I'll add ADC5 Gen3 bindings in the same file with 
changes like the above, else I'll add them in a new file after first 
creating a common schema file as you suggested.

Thanks,
Jishnu

>>
>> Since these constraints cannot be modified for a specific new device or
> 
> ???
> 
>> removed, I think the only way to accommodate this new device is to add
>> it in its own new file.
>>
>> Is this a sufficient justification for adding this documentation in a
>> new file or do you have any other suggestions?
> 
> I already gave you the suggestions and you ignored them. Do like we are
> doing for all other drivers. Don't re-invent stuff. Either this fits to
> existing schema or come with common schema (and then provide rationale
> why it does not fit to existing one).
> 
> Best regards,
> Krzysztof
>