Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a24c24e6-fdee-df79-fd2f-6a71540bd9b3@linaro.org>
Date:   Mon, 20 Jun 2022 10:50:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH 2/3] dt-bindings: usb: mtk-xhci: Allow middle optional
 clocks to be missing
Content-Language: en-US
To:     Chunfeng Yun <chunfeng.yun@mediatek.com>,
        =?UTF-8?B?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= 
        <nfraprado@collabora.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Matthias Brugger <matthias.bgg@gmail.com>
Cc:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>, kernel@collabora.com,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-mediatek@lists.infradead.org, linux-usb@vger.kernel.org
References: <20220617222916.2435618-1-nfraprado@collabora.com>
 <20220617222916.2435618-3-nfraprado@collabora.com>
 <8639e64d-c659-7090-2d0a-078fd96cfbd4@linaro.org>
 <bb460aa483cc888ffa36709d9e9c1f2e3be0e000.camel@mediatek.com>
 <bc5458fe-083c-d679-9fcb-95810a290da8@linaro.org>
 <af50210b95d0cd8b2e3103b3d4a9702aeeba9452.camel@mediatek.com>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <af50210b95d0cd8b2e3103b3d4a9702aeeba9452.camel@mediatek.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 20/06/2022 08:59, Chunfeng Yun wrote:
> On Sun, 2022-06-19 at 14:05 +0200, Krzysztof Kozlowski wrote:
>> On 19/06/2022 09:46, Chunfeng Yun wrote:
>>> On Fri, 2022-06-17 at 18:25 -0700, Krzysztof Kozlowski wrote:
>>>> On 17/06/2022 15:29, Nícolas F. R. A. Prado wrote:
>>>>> The current clock list in the binding doesn't allow for one of
>>>>> the
>>>>> optional clocks to be missing and a subsequent clock to be
>>>>> present.
>>>>> An
>>>>> example where this is an issue is in mt8192.dtsi, which has
>>>>> "sys_ck",
>>>>> "ref_ck", "xhci_ck" and would cause dtbs_check warnings.
>>>>>
>>>>> Change the clock list in a way that allows the middle optional
>>>>> clocks to
>>>>> be missing, while still guaranteeing a fixed order. The
>>>>> "ref_ck" is
>>>>> kept
>>>>> as a const even though it is optional for simplicity, since it
>>>>> is
>>>>> present in all current dts files.
>>>>>
>>>>> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
>>>>> ---
>>>>>
>>>>>  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml       | 9
>>>>> +++++++--
>>>>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/usb/mediatek,mtk-
>>>>> xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-
>>>>> xhci.yaml
>>>>> index 63cbc2b62d18..99a1b233ec90 100644
>>>>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-
>>>>> xhci.yaml
>>>>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-
>>>>> xhci.yaml
>>>>> @@ -80,8 +80,13 @@ properties:
>>>>>      items:
>>>>>        - const: sys_ck  # required, the following ones are
>>>>> optional
>>>>>        - const: ref_ck
>>>>> -      - const: mcu_ck
>>>>> -      - const: dma_ck
>>>>> +      - enum:
>>>>> +          - mcu_ck
>>>>> +          - dma_ck
>>>>> +          - xhci_ck
>>>>> +      - enum:
>>>>> +          - dma_ck
>>>>> +          - xhci_ck
>>>>>        - const: xhci_ck
>>>>
>>>> You allow now almost any order here, including incorrect like
>>>> sys,ref,xhci,xhci,xhci.
>>>>
>>>> The order of clocks has to be fixed and we cannot allow
>>>> flexibility.
>>>> Are
>>>> you sure that these clocks are actually optional (not wired to
>>>> the
>>>> device)?
>>>
>>> In fact, these optional clocks are fixed, due to no gates are
>>> provided,
>>> SW can't control them by CCF;
>>> In this case, I usually use a fixed clock, or ignore it.
>>
>> But in some versions these clocks are controllable or not?
> Some SoCs are controllable, some ones are not (fixed clock).

Thanks for confirming. Then I would prefer to make these clocks required
(not optional) and always provide them - via common clock framework or
fixed-clock.

Best regards,
Krzysztof