[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <73a5b252-b83b-aa3f-d593-776e42182ab6@linaro.org>
Date: Tue, 29 Nov 2022 11:45:40 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Sibi Sankar <quic_sibis@...cinc.com>, andersson@...nel.org
Cc: agross@...nel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
krzysztof.kozlowski+dt@...aro.org, robh+dt@...nel.org,
konrad.dybcio@...ainline.org, robimarko@...il.com,
quic_gurus@...cinc.com, quic_rjendra@...cinc.com
Subject: Re: [PATCH V5 1/2] dt-bindings: firmware: qcom-scm: Add optional
interrupt
On 29/11/2022 11:05, Sibi Sankar wrote:
> On 11/28/22 14:00, Krzysztof Kozlowski wrote:
>> On 28/11/2022 06:57, Sibi Sankar wrote:
>>
>>>>
>>>> Which devices have interrupts?
>>>>
>>>> We talked about it here:
>>>> https://lore.kernel.org/all/2464d90f-64e9-5e3c-404b-10394c3bc302@quicinc.com/
>>>> and here:
>>>> https://lore.kernel.org/all/c20edd0d-7613-5683-60e7-54317cac6e0b@linaro.org/
>>>>
>>>> But I still don't get which devices support it and which do not.
>>>
>>> lol, I thought we reached a consensus earlier because of the "ok" and
>>> R-b. Like I explained earlier the bootloader would be adding interrupt
>>> on the fly, wouldn't such cases cause binding check failure if we list
>>> all the devices supporting it?
>>
>> What type of failure? I don't get. Is this interrupt valid for SM8250?
>> SDM845? MSM8996? and so on? Now you make it valid.
>
> ok if we mark the interrupt as required for SM8450 and not specify the
> interrupt in the board file (since the bootloader will be adding it on
> the fly), dtbs_check will throw 'interrupts' is a required property for
> the board file. This was the failure I was talking about.
OK, but no one said here about making it required. So how this issue can
happen?
Please read above chapter again. I said nothing about required, but I
said "valid".
>
>>
>>> Also some of the SM8450 devices in the
>>> wild would be running firmware not having the feature but I guess
>>> eventually most of the them will end up supporting the feature in the
>>> end.
>>
>> That's not what I meant. Your patch describes the case for one variant
>> but you are affecting all of them.
>
> Not really, the driver treats interrupts as optional.
Linux implementation matters less. We talk about device/hardware
(firmware in this case).
> If the interrupt
> isn't present we assume that the feature isn't supported. If the
> bootloader adds the property during boot then we assume the fw has
> waitqueue support.
Sure, my question stays. Which devices do not support it at all?
Best regards,
Krzysztof
Powered by blists - more mailing lists