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 38C5FC43334 for ; Sun, 19 Jun 2022 11:49:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236830AbiFSLtX (ORCPT ); Sun, 19 Jun 2022 07:49:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231256AbiFSLtJ (ORCPT ); Sun, 19 Jun 2022 07:49:09 -0400 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3348311C32 for ; Sun, 19 Jun 2022 04:49:08 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id e2so625292edv.3 for ; Sun, 19 Jun 2022 04:49:08 -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=Yp4bmUkucrfn0YoCb3947aiyNMhaiNjLfndCRiuztxU=; b=yr+bG3jG4+68iQNvAiVbY3Z1gBJqsRvJGx5qiy0JF4mCyAGs2+gQW+U/llayv2QvZa JObgwL6nY/In7vN0HgMJyKOHcXvcqtzdmIISyxAbBNQcLPd/7bs5WSSXoP1BF4CC0oSj cOA/+WUR3Mjc/ZGuFAcYgKsUk8uEOUyOsnHY2Kdcj/KV2McZ7G5VwDWc+oYaFweytQiE 3DWEEJAHPlikXDtlaqwLSmEuovXWj4PGrR2gjXnxInhsq+/pVhYHn++AcQqqzmdENG9M mGqPzpp9dyG8QRwIRiVCBK/yzkGrKuwNwcUEZGSzbCoak4I6gm0aJOkIY6vumz7Ed2+i k4Hw== 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=Yp4bmUkucrfn0YoCb3947aiyNMhaiNjLfndCRiuztxU=; b=X3fkfxSuZmWS/RCKWns9VK4/m2dgQhhcFPHI9R1LQ3ZO+1Qt72ujLb59jYGwtxwU9M xV5jnJ1lwcXopXVPWT7nrwDM7cC1y5D5rwOyORD3pEPek8de/HNIS5n4gSt1sfKkLthk V6LP0wnI1bntj16e9+//5fU2uvlqvvXs7CZHXT4lwAovtMwx4lZo+D/HcD01puquSjym Uy+bmYWGkzmzbi24YWN8GNKD87O0W91epSzbzafMFoY/JJ4AXLxCZ4uQa3JqXMgPzSNf 4O9wA/VF+J6sm1iA5AhTrJ+vhRXis4fgDb6AIva2Q6YEEzjp0c5ecF0aFXX/CiEsvlVp 0WZQ== X-Gm-Message-State: AJIora9e7URNjGxNvDZ8kpuYh2peu9L7VF/vSoEi+oV+ixMvzrH3bUWq iUScWiL1McIoyhPKvjFvDwydbQ== X-Google-Smtp-Source: AGRyM1uf/0HgCvqeSezyCxo06xRPdiDZsKSIjIh9ayuMCVtMgx1owUBRCkmcqmcT3JXy2reZyX/UXQ== X-Received: by 2002:aa7:cb13:0:b0:433:4985:1b54 with SMTP id s19-20020aa7cb13000000b0043349851b54mr22955689edt.182.1655639346743; Sun, 19 Jun 2022 04:49:06 -0700 (PDT) Received: from [192.168.0.206] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id fd18-20020a056402389200b0043570d96d25sm2987288edb.95.2022.06.19.04.49.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jun 2022 04:49:06 -0700 (PDT) Message-ID: <5c7a1763-01fb-249d-a301-9164e2139ac6@linaro.org> Date: Sun, 19 Jun 2022 13:49:04 +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 , =?UTF-8?B?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= , Greg Kroah-Hartman , Matthias Brugger Cc: 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> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 19/06/2022 09:40, Chunfeng Yun wrote: > On Fri, 2022-06-17 at 18:29 -0400, 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. > How about using fixed clock instead to fix the check warning? > Using enum way seems make it more complex. > That would mean the clock is not actually optional. The DTS should reflect the hardware so either you have the clock there or not. Either it is an input or not. Of course there are some exceptions (like non-controllable clock or regulator which not always has to be modeled). Best regards, Krzysztof