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 D2CA2C3DA6E for ; Wed, 10 Jan 2024 07:26:34 +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=3RNiiWWbFttNWVEppIFvIjfQPES0iGYgAV75dl1pa48=; b=j/BuppCwB5NJpn GiL/zcT13sdyr68x71Q8NyVChGqDzc3o7Zd+l/xeWAaHCEnAYkx5/XHmu4hP1xk8K+RywkodJiG25 Ji9WmWpxVdDkFl0hlW6kYqhE/9AVV/IO4ZnLgFZPpWYmbkCXiVYmlVuF6yFEGYpnT1/ZY3/NoPhwC 1wyCh1bjiXVYp2DOl4yqEM7cuixSoXhX3Zr2hfvMW/SUZEky3sOU1f/RB2nd9RLHEiA5XBgzOoOQr 9yP8kB2f8SbSnLW+hSpE+jc3KUB0vE4IRo6my5im/FInOkwPOqzIdMTjkPcm6f/PTEXwf4ed8DqX2 3YZuaw/9GRcLtdhhi8jg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rNSyT-00AbUJ-30; Wed, 10 Jan 2024 07:26:05 +0000 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rNSyR-00AbTn-1j for linux-arm-kernel@lists.infradead.org; Wed, 10 Jan 2024 07:26:05 +0000 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3373a30af67so3577332f8f.0 for ; Tue, 09 Jan 2024 23:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1704871559; x=1705476359; darn=lists.infradead.org; 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=3OiOLhRr/v/UoX6M5hASdWKUoK8n0S9t0J6jvZFucNA=; b=T6BdB4fXyeQOHgUxcvcfuWJjaziNeD6OSk/p9WzgUUdwZR2dMWVolizbQL4kYRIAQK wcdtAnXNCS2nXjjnSzskgvlASxfkJemJuTZc/WJupSixyB7Rs7ck8U278+VrlR571Sth OPFsEf0fvh4J456e7UuylkmJ9941xQEb/Om+lFOmUq+aH638yw6XewoqCuHJUZ5OT7Ok 93STRfu2KKDw2pCVuyF3xpoMY066wRYWEjGD4mqXDse5QRD33W+CmUg15h4oY6ivsFrX El2IWydtD3+8fxi/hHGvJv17C4DZAtwzMAaRJ/cRoD5ft1gVUeHPdDmC+kVzChEFQvHa QDJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704871559; x=1705476359; 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=3OiOLhRr/v/UoX6M5hASdWKUoK8n0S9t0J6jvZFucNA=; b=utmSf83PheQP+ulzofHqlSzzDJ7xfxvwYSbWZv+4LWq0c2TgRU1IFXIMewHTesp3oS LgxakJhV6gedaG1ffMwPMxRS51wQ4dnotFVYy8F2scLyLYvJgkUitLjzVNqqfSMFNEMh dO0dljeR1aRXJWBJ7H91lIvLk4bZJKUyzMdijFfk1EDayLPXbTbXGV8BGsVZP2HmbhIc gO0TMv/qswN/eU2+Amz8sPxkvQPAAMXSNJZRl2Y1Kz71IPvv05mTjkpoS/UmePL8M64L X/KmzmYltYRYJv2+AfNM3GiQDMi5AP5AKY4Iv88fGeHiY2Zv6jtMb2tuoTyuoYt4LsdS k2Mw== X-Gm-Message-State: AOJu0YzckzekcgPwWoW+zAOOMwr8syKDL4oUlfNzPgPsEBuyC0U9TU0E L8Qt7Z57n8Hs/LXJqkEUVliXUbNZoF+iqQ== X-Google-Smtp-Source: AGHT+IE1O/Q18uyQ9bgM0s5oBgheZhm9Raon+NZw5D/zhrfsAJdZYSoWCcIqwTEWmKfgCMrEQYnWfw== X-Received: by 2002:adf:f107:0:b0:336:ca90:3a1a with SMTP id r7-20020adff107000000b00336ca903a1amr195607wro.114.1704871558869; Tue, 09 Jan 2024 23:25:58 -0800 (PST) Received: from [192.168.2.107] ([79.115.63.202]) by smtp.gmail.com with ESMTPSA id z16-20020a5d4d10000000b0033686e8f02dsm4125387wrt.45.2024.01.09.23.25.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jan 2024 23:25:58 -0800 (PST) Message-ID: Date: Wed, 10 Jan 2024 07:25:56 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/12] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit Content-Language: en-US To: Krzysztof Kozlowski , Rob Herring Cc: peter.griffin@linaro.org, krzysztof.kozlowski+dt@linaro.org, mturquette@baylibre.com, sboyd@kernel.org, conor+dt@kernel.org, andi.shyti@kernel.org, alim.akhtar@samsung.com, gregkh@linuxfoundation.org, jirislaby@kernel.org, s.nawrocki@samsung.com, tomasz.figa@gmail.com, cw00.choi@samsung.com, arnd@arndb.de, semen.protsenko@linaro.org, andre.draszik@linaro.org, saravanak@google.com, willmcvicker@google.com, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, linux-serial@vger.kernel.org, kernel-team@android.com References: <20231228125805.661725-1-tudor.ambarus@linaro.org> <20231228125805.661725-2-tudor.ambarus@linaro.org> <20240109040315.GA2619804-robh@kernel.org> <8a55e1d9-c102-4cdf-8f23-edc40889cf6d@linaro.org> <38523622-4963-44a5-a5d6-64896ae47e09@linaro.org> From: Tudor Ambarus In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240109_232603_574464_B6DC283A X-CRM114-Status: GOOD ( 30.49 ) 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 1/9/24 18:38, Krzysztof Kozlowski wrote: > On 09/01/2024 17:12, Tudor Ambarus wrote: >> >> >> On 1/9/24 15:01, Krzysztof Kozlowski wrote: >>> On 09/01/2024 12:58, Tudor Ambarus wrote: >>>> >>>> >>>> On 1/9/24 11:09, Krzysztof Kozlowski wrote: >>>>> On 09/01/2024 05:03, Rob Herring wrote: >>>>>> On Thu, Dec 28, 2023 at 12:57:54PM +0000, Tudor Ambarus wrote: >>>>>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0) >>>>>>> clock management unit. >>>>>>> >>>>>>> Reviewed-by: Sam Protsenko >>>>>>> Signed-off-by: Tudor Ambarus >>>>>>> --- >>>>>>> v2: >>>>>>> - fix comments as per Sam's suggestion and collect his R-b tag >>>>>>> - Rob's suggestion of renaming the clock-names to just "bus" and "ip" >>>>>>> was not implemented as I felt it affects readability in the driver >>>>>>> and consistency with other exynos clock drivers. I will happily update >>>>>>> the names in the -rc phase if someone else has a stronger opinion than >>>>>>> mine. >>>>>> >>>>>> I'll defer to Krzysztof. >>>>> >>>>> I miss the point why clock-names cannot be fixed now. This is the name >>>>> of property, not the input clock name. >>>> >>>> They can be fixed now. I've just aired the fixes at: >>>> https://lore.kernel.org/linux-arm-kernel/20240109114908.3623645-1-tudor.ambarus@linaro.org/ >>>> >>>> Preparing v3 for this patch set to include the updated names here too. >>> >>> I think I was not that clear enough. I did not get your current patchset >>> - so PERIC0 clock controller - cannot use new naming. >>> >> >> Ok, I understand that the fixes from >> https://lore.kernel.org/linux-arm-kernel/20240109114908.3623645-1-tudor.ambarus@linaro.org/ >> >> are NACK-ed and I shall use the full clock-names in this patch set as >> well, thus "dout_cmu_peric0_bus", and "dout_cmu_peric0_ip". I don't mind >> changing them back, will send a v4 using the full clock names. > > They are not rejected, it is just independent thing. At least looks like > independent. The datasheet is not so verbose, but as I understand, CMU_MISC and CMU_PERIC0 are clock domains of the same clock controller, thus I think they should be treated the same. We should either get rid of the name of the block in the clock names or keep it, but be consistent across all the clock domains. > >> Out of curiosity, why can't we change the names? All gs101 patches are >> for v6.8, thus they haven't made a release yet. We still have the -rc >> phase where we can fix things. > > We can change. I would not bother that much with doing that, because I > sent already them to arm-soc. That means I need to consider this as > fixes and I just did not want to deal with it. > > The question is quite different for a new clock controller - peric0. > What parts of driver readability is affected by using "bus" name? > As Peter pointed out, if keeping the shorter names, one would have to cross reference with the device tree in order to determine which clock is used, its type, whether it's a gate or a divider. Whereas if we keep the full name, one can see what's the clock about with a glance. The full name coincides with the clock names that are defined in the clock driver, thus one can grep for the full name from the device tree and hit the clock definition from the clock driver. The cons of keeping the full name is that keeping the name of the block in the DT's clock name is just redundant. Rob was clear and said that including the block name in the -names is a pattern we don't want. In what concerns my personal preference, I like the full name. At the same time, I see Rob's point, and if that turns out to be a rule, let's respect it. So I'm fine with both, but let's be consistent across the driver and have the same clock name scheme for all the clock domains, otherwise it will just look weird. Thanks, ta _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel