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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4855CC7618A for ; Mon, 20 Mar 2023 17:29:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pEw/nQ6qG0UGPI0T5kOPtrDEj1h2NvgJLgxpZHIOlS4=; b=Qw+QiUo6VyECfj IDC1YlS5GnY4O/bdoXKu6Q8noL52m+xHQ47rP3HPO5Foh1ofB/zx2x7msQTZ3laqFMITzcxcB308m LtJjoNZI6YhY6ZID85DldaAfsqnP0JQlqKZ0+GJCwbmUffC958wtq56iNbhYSLf3wtqY9imWC2hIB iCWhNpsUHpLBELHoq3YncDoYQ8f0giLrDvZc+1KwyQ+fN/lYG6X4GYxyUWTvh3SCB+1E5a87SM7c6 Bd4hWekcfyNnZVJdZlAj6MnRlQ5U0vbsJUyRxVi6yxrvckjSelWSnO+pZb5AwgjOkKUPvQZdvoxVt zlt8mg6kmQQl1n3TRT2w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1peJJ9-009z63-1c; Mon, 20 Mar 2023 17:28:31 +0000 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1peJJ5-009z5M-3A for linux-arm-kernel@lists.infradead.org; Mon, 20 Mar 2023 17:28:29 +0000 Received: by mail-ed1-x52e.google.com with SMTP id o12so49767647edb.9 for ; Mon, 20 Mar 2023 10:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1679333304; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=b9pX5fliZvB4+kznLyF5jnrxrGLHA6LLF6Cnxe9MC48=; b=GqJCTFrChfHB40oOYHyfWTI/8mjA/jlE/zJv2f4TVg7YNZfwnzvv5+OqQlEKWGD2dH MFsws0t6KPJdr6RDzJ8AgcfM1R9XRK6Hf7sTl4kal7IsFXQrXNYuBeuWJ2m+i9I0d9ir IqFKZ7596/Si3uZPOn+jNthM8/5ZiHUUoFRX099OjJpaDMrlUni/vytjBE3Z1mxM7ysQ hr0JggP6feSGi461CvyGRSJNaHyoyL1J1e7+LXL25/kqZCLLC0L+BWlHjH0QO+8k9K7y A0pA+wQT3ZckDIvpTVRc//WVjUNS9KolF2G+fqR2Y8K6FEmXOXdThdx20VUeJsetNxjs 0Zyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679333304; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b9pX5fliZvB4+kznLyF5jnrxrGLHA6LLF6Cnxe9MC48=; b=WM1I9wfM9Yg61JT0Fmd6EADbbSkICgF1ltU+yv5buKTpXyN99qRL7FV1y1HkKLY8en yLsQvgxpqywLdO/lKYSOO+tqIzKCI1G/uX+FIJ2YSy3Rb0KBFz2KsbSVUxq1un8JeGTu 7IjyzVo2cf4SdcA3IirvvWhHeAHeIauRYulGb3Us8AboiVAIWxStn6yohq52QLFqxAS1 7XfJzZ1lhO8D6c5QbmWcuclIJk6MBbbmNPzTlwVO8LyY0Ujx+p/aBV2CKEWAK9Xra85I pi2FijgU+Jiv6d6cwtbvE86Lq/z+BXfgN1z5iizFbS4Dxa8sIISa0fzLAOMfW2iDAaag CRMA== X-Gm-Message-State: AO0yUKVu+gORTvwCOZJRNBFhH36BIGMzpmt6DZ/dyYjIBKeZXvaMAt9A W5ppiLmFge/7meSOscAsYpsYsQ== X-Google-Smtp-Source: AK7set9Ezk9dD+DlISj3bqFA+1PKg/UVKPzOLXXBLPYlp40gPSrFOOXoVyZ40Z991PUXBtmjKSq4Uw== X-Received: by 2002:a17:906:2853:b0:922:2ba3:2348 with SMTP id s19-20020a170906285300b009222ba32348mr9468015ejc.7.1679333304157; Mon, 20 Mar 2023 10:28:24 -0700 (PDT) Received: from ?IPV6:2a02:810d:15c0:828:458e:64e7:8cf1:78b0? ([2a02:810d:15c0:828:458e:64e7:8cf1:78b0]) by smtp.gmail.com with ESMTPSA id a21-20020a170906191500b009339e2e36e4sm2141676eje.81.2023.03.20.10.28.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Mar 2023 10:28:23 -0700 (PDT) Message-ID: <614fa099-e666-03da-1b11-29cc804bf847@linaro.org> Date: Mon, 20 Mar 2023 18:28:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [EXT] Re: [PATCH v2 1/3] dt-bindings: usb: cdns-imx8qm: add imx8qm cdns3 glue bindings Content-Language: en-US To: Frank Li , "shawnguo@kernel.org" Cc: "devicetree@vger.kernel.org" , "festevam@gmail.com" , "imx@lists.linux.dev" , "kernel@pengutronix.de" , "krzysztof.kozlowski+dt@linaro.org" , "linux-arm-kernel@lists.infradead.org" , dl-linux-imx , "linux-kernel@vger.kernel.org" , "robh+dt@kernel.org" , "s.hauer@pengutronix.de" References: <20230316212712.2426542-1-Frank.Li@nxp.com> <20230316212712.2426542-2-Frank.Li@nxp.com> <1fd1fe42-3da6-1598-a04d-cb99a9b4b145@linaro.org> From: Krzysztof Kozlowski In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230320_102828_020235_C8731FF2 X-CRM114-Status: GOOD ( 20.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 20/03/2023 18:02, Frank Li wrote: >>> Although frequency is fixed, clock name may change for difference >> platform. >>> >>> assigned-clocks = <&clk IMX_SC_R_USB_2 IMX_SC_PM_CLK_PER>, >>> <&clk IMX_SC_R_USB_2 IMX_SC_PM_CLK_MISC>, >>> <&clk IMX_SC_R_USB_2 >> IMX_SC_PM_CLK_MST_BUS>; >>> assigned-clock-rates = <125000000>, <12000000>, <250000000>; >>> >>> some platform use IMX_SC_R_USB_2, other platform may use >> IMX_SC_R_USB_3. >> >> This I understand, you wrote it above, so nothing new and my concerns >> are still there. > > I think Fixed value is not good reason. All reg base address, irq number are all for fixed number. The same No, because one device - IP block - could have different addresses, depending how it is wired/implemented in given SoC. Also our representation of devices in the kernel requires regs/interrupts coming from DTS, thus DTS is also answer to entire design of kernel and other SW. That's not the case here at all. > Logic can be applied to irq-provider driver. But why still be descript in dts? It is hardware property. > > https://elixir.bootlin.com/linux/v4.8/source/Documentation/devicetree/bindings/clock/clock-bindings.txt > have not said that can't set to fixed clock frequency. I don't understand this. > > This is quick common case for network, USB, SATA, PCIE, which protocol defined > Frequency. And they do not define fixed values in the bindings, so? There are exceptions, but it's usually not argument, right? > > https://elixir.bootlin.com/linux/v6.3-rc3/source/Documentation/devicetree/bindings/ata/qcom-sata.txt > https://elixir.bootlin.com/linux/v6.3-rc3/source/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml The second is a good example - as you can see, there is a choice of values, so they are not exactly fixed. > > Such frequency information is necessary. We can put to dts or clock drivers. The clock driver If this is the argument, then the answer is NAK. Sorry, but DTS is not for offloading fixed stuff just because you do not want to work on drivers. The same for discoverable stuff. > Become bigger, or dts become bigger. I think the key point is if property to descript hardware information. You have to understand that with your binding you are not allowing to any changes of these frequencies. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel