From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2AC7C433EF for ; Tue, 21 Jun 2022 07:14:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345003AbiFUHOz (ORCPT ); Tue, 21 Jun 2022 03:14:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47006 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239480AbiFUHOz (ORCPT ); Tue, 21 Jun 2022 03:14:55 -0400 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E602B186D3 for ; Tue, 21 Jun 2022 00:14:53 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id cf14so8306125edb.8 for ; Tue, 21 Jun 2022 00:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=BU3K6SinExvEocmmVPaQvW019Wdd8765AUfADvWsjq8=; b=xY9S8gGdlJGQCO07Q+2Nif+7F+wUWZSqeaYzI+/xN6CmLvdv63g6mOmni/9E1yYxsH uI17z96Mml3ciYVyMDtRAlm37PSTXF1ZXBMWwVC/H3aNKs/PqaMNj5s+Oq+4xwRSZkAL hyuy0YvZNQpHxLeZeekbD9Fyam83qoBdOx+oBcmiY9pJgEO9ihqbzw6r2Cgpbrw88YP+ UWNYbY2jtasa9G0901v8zzrDRzj4gxPBd2l4G2bx86qq9KrEjL2+dV7PtHXNeX/ZBmpI FaUR68G7DhK+GMBVKiSV9moScQmiMhX1rXykJOSd47zhVMR9x7OX23a0VbJse16ZIdod XskA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=BU3K6SinExvEocmmVPaQvW019Wdd8765AUfADvWsjq8=; b=IEFb0SWIKH7pwFT64BFw79n7Bm93fQj03NS/CGsVr5f5YC5UWGilANYs3Jhh5UHX1V rbjF4GouspFQgjKKsJqmOzl5e2YGXO5l0Inm0V0JejHoD3KiWgvs0IiA/Bjgttinbv+X 1SPddHYrfiq7VEbH8bAf8xs4DSJtZRpqoMNsv71qEopx393/ygLTEhndMNZTbowJBt7w RVo1Hds6NC5CuPHwI/fRetp46wB22B4VZDKDebD5flZNCO+CmryzF7GzYhtIP/ch3MUv eNqub6xP1HDO+be1C5c9v1LtutpIOi/6VS0p1bn85tWYWkZY0RacJtLGwuK6G08tu53p GoSw== X-Gm-Message-State: AJIora+/2IFUoF7c9zl/yF9gQJJfVklIa6CWXkHIEq1tsfw6QCuNSSNn +EBwLHiZ2v4VWGXt0swSa9DpKg== X-Google-Smtp-Source: AGRyM1tBku4dOhxRZ+tsBWaShFdZdDXQbIGVuRg++IW5L6zuGtkFMc1YBVszGNTf/5dmlH8pwRuK4w== X-Received: by 2002:a05:6402:2554:b0:42d:ee79:559d with SMTP id l20-20020a056402255400b0042dee79559dmr33858014edb.175.1655795692479; Tue, 21 Jun 2022 00:14:52 -0700 (PDT) Received: from [192.168.0.216] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id q12-20020a5085cc000000b0042ab87ea713sm11952447edh.22.2022.06.21.00.14.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jun 2022 00:14:52 -0700 (PDT) Message-ID: Date: Tue, 21 Jun 2022 09:14:50 +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: =?UTF-8?B?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= Cc: Chunfeng Yun , Greg Kroah-Hartman , Matthias Brugger , AngeloGioacchino Del Regno , kernel@collabora.com, Krzysztof Kozlowski , Rob Herring , 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> <20220620155057.a6qilnhm7snzhapa@notapiano> From: Krzysztof Kozlowski In-Reply-To: <20220620155057.a6qilnhm7snzhapa@notapiano> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 20/06/2022 17:50, Nícolas F. R. A. Prado wrote: > On Mon, Jun 20, 2022 at 10:50:57AM +0200, Krzysztof Kozlowski wrote: >> 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 >>>>>>> --- >>>>>>> >>>>>>> .../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. > > Hi Krzysztof and Chunfeng, > > thank you both for the feedback. > > Since the solution I proposed in this patch is not acceptable I see two options: > 1. Split the clocks in several if blocks matched by compatibles > 2. Make the clocks required and use fixed-clock nodes for the missing clocks in > the DT > > My understanding is that 1 is the desirable solution if the clock is really > missing in some hardware variants, while 2 is desirable if all hardware variants > really receive all the clocks, only that on some variants they're fixed and not > controlable by SW. > > From what I'm reading of this discussion it seems that the latter is the case > here and thus we should go for 2. Is this correct? This is how I understood it as well, so correct from my side. > > Also Chunfeng, do you have information on whether the same is true for the MMC > HW block? I recently submitted some changes to that binding [1] but I followed > approach 1 there instead. However if all the clocks are present in the HW level > there as well it would make more sense for me to change it to follow approach 2. > > Thanks, > Nícolas > > [1] https://lore.kernel.org/all/20220617230114.2438875-1-nfraprado@collabora.com Best regards, Krzysztof