Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp811672rdd; Tue, 9 Jan 2024 23:26:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IHfH0H42+YsrBw57+vEjhICdgLOMfIewlgBl9WX4l2V8Urk78adEb3Osi1y+c0MPxQ0HnS6 X-Received: by 2002:a05:6214:f04:b0:67f:b58b:6b0a with SMTP id gw4-20020a0562140f0400b0067fb58b6b0amr779309qvb.114.1704871573248; Tue, 09 Jan 2024 23:26:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704871573; cv=none; d=google.com; s=arc-20160816; b=sJboAj1SczXR5HbFzCPkSJuDGnX4RZHZ11V0RxlkeXW+NyS5HhOL0nBAU9FJugSBhV 9sIxma8sxTL7kstaVKkrThcikf3X8f9Usbu8GPwdxgyLEvKYDPyZ2qj743ujaXUhL6QS tRooHP4ATzQ+JGV2MOXfqSN8pXTHBuST6aS/QF2cIdVljOGZRU9WnDto0Ua+f8+RwYfn +PXcDTsSgryWEyQXgT6oySUf33xGUF/1GX7TYNGkie8FXIZJhAKanHYW0GJ9woNcfG0d Lg2yGEnMahKrYaGt/A8/PHAuDUN/gGwp9nboSca0bv2352s9DEipIceT3KhbQsoFWf3x lFxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=3OiOLhRr/v/UoX6M5hASdWKUoK8n0S9t0J6jvZFucNA=; fh=K3EZjXTRZDVdw9hLyhcfIuFB680BG0GUnjlFwVZ/QeA=; b=w8Zdpw3MB5mgbV05dPaoZZ6WLzMqb+0aXUo/ic8w5cTWLxCzxuEu5VJ87dCzsJSdJJ 0hcDZKwY8ylVsDB9LMGd4Z8LLt8p04oql+a4NfoQV8iVqTXH4qUF1sFOQ0EDWatY/Ak4 7p6tBF4M3jLndoBp9tQHoOGIycNhJK3sICmlOBCR9QDa5C61nSjThNBnYzVyXxsH4fYa 7MujX53NoBcmhmPi+TdPD5n/8dE1Ji+8w80IF1IQ4EVUmnzWUX2hslnxOhE42TWVi4YM R/QWyHEXb1mtfAvXWDSIpv3OOV+o/5JhzsJuQ4x9x6bCXdoxzETmJQ5cV99nJHsRKrpT pbag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="OAas/FW3"; spf=pass (google.com: domain of linux-kernel+bounces-21786-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21786-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id x13-20020a0ce0cd000000b00680abc0f833si3809370qvk.250.2024.01.09.23.26.13 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 23:26:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-21786-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="OAas/FW3"; spf=pass (google.com: domain of linux-kernel+bounces-21786-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21786-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id EC23C1C2561F for ; Wed, 10 Jan 2024 07:26:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3BC1539AF4; Wed, 10 Jan 2024 07:26:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="OAas/FW3" Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B15839851 for ; Wed, 10 Jan 2024 07:26:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-3376f71fcbbso2179563f8f.1 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=vger.kernel.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=OAas/FW3fsdbePoaO8FMoctN5Z/GFK/mmquIdXpthWjUb9jDyC4Vz16kjhhm6CEvEs zwS4EHfc3zMsf8Lil256/5eHixzvJwiZoMx7LZ/Ijau9m1yqe+gQNhlxssQ7qSRf0h35 LWJ3o8WQ2+KGRDuylDJ9BdJJHuS+lPmS71r37J3cggczHFwvvZl9ikw6KnejlUINtaOr vWtM952hwAxXzHAIQOFmR28TYyWYVNAiKsfjRE3Wm+5jJUKAVTqKbopgdH9ec0Lz2w6s 8KYIS95MqJxkEvsmAn0Yk1thscAOeiGoTzqbmKhC71w8haKXGYy1Fma8+J9DJUAxaGFl OPQA== 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=R7HYSdxiV3rSDYVWwdZYSpn3yfVOQ1pdqEhhH0yKBiSC5cioIXZ3yzyoVyCXcI1Ton N3jo3du9s1O7wV3/zTxX8fbjVhK6lLi01s4ImrMFeR2D95otg2DaVseaVgtZ0EVqzzvh HGVTZNKlsxAnITL+v8JZAFKj9i/iembEWRIWmM2gzkMg1ttri6EzRgyNqlmyowNBfgA1 LGMYQNkqHDcffB1f7BKjtCbKz/1Ab/zS2UOdY2fuDcRSGWOQyafXRJdFUkOydwsrF/aB UQTVIwncp7gMSwAOFeGsN2MvfxV/nvF5mesGSFLFFf6lw9xKKtAmmL5vhvIBNt7zK2To 2K7Q== X-Gm-Message-State: AOJu0Yz/IeC1UAbARFt0uBxk89t8YfXmDVBNPrI8YTpogsOplQjT9IoN qg79Ey2BG37UafhrLWRbNh1vMMOcPIsqrA== 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 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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