linux-kernel - Re: [PATCH 2/3] dt-bindings: usb: mtk-xhci: Allow middle optional clocks to be missing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a24c24e6-fdee-df79-fd2f-6a71540bd9b3@linaro.org>
Date:   Mon, 20 Jun 2022 10:50:57 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Chunfeng Yun <chunfeng.yun@...iatek.com>,
        Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Matthias Brugger <matthias.bgg@...il.com>
Cc:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>, kernel@...labora.com,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: usb: mtk-xhci: Allow middle optional
 clocks to be missing

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@...labora.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