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 30925C433F5 for ; Tue, 8 Mar 2022 06:44:40 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HBfHuY5stYRndU/o8D63Syy7QZh9E9Wt3kd3Jq0RRP0=; b=pxTpwa013XeRE8 leQIHFWnXQD3ehCXWkLLhu0IanQw81m0SUYyz7QfxwDHHRGalEyte0V1oLMaQ8Wc8W22x0t1uz5UF qYzjEm9bm/MCpLSqznNyDd9ZEycMtWaXwD7t89yuIHXwH2r9jcmXf4UK531sFSkFwmbnF59ScudqT qqU1Bylr3aJ4FOL82g/KDrmyP0QlcQpvJAYk7p1YJdyaUq/GDjaAgWtUuMXzpWRWCHGrzXcV5YBFf JJYP4WHprIqOrJnzxkNdWWzVen0Jo24dALNYyLLoX10xr1eTxyjTTiWxPg2Zn70DVZo3oM1mnD3G2 +mckFDuax46pvqpKrikw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRTYh-002v3p-OA; Tue, 08 Mar 2022 06:43:00 +0000 Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRTPC-002qTE-JR for linux-arm-kernel@lists.infradead.org; Tue, 08 Mar 2022 06:33:12 +0000 Received: by mail-pg1-x529.google.com with SMTP id z4so15574597pgh.12 for ; Mon, 07 Mar 2022 22:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hMjnxV0GnFj2CSor8E3F7ywKx8ZqWT73m+9Cg9mTc0I=; b=SLdxROCW6cr3FHmNOHAdjkeIc8HSPqIauQwbKl06rFdvYwydIfxdCuzSumG9QQcDJc K+VSXhaQaSUh09zI60t2vuH1BgCyUy0iuQ1wPpR/ucWsmcC4LvUZ4nNWOVWZmod8BDeY hgSgKiW9vNbYk6BNWeB9gE+aiz1HBTQD4E/pH/gpnCIYWTntMiBj4uYwGUmugiSZZZa3 3t+g+iRBngfe7q85VOKTu4lrDzWeZnb4waJrKtkHV78xCGD/04kLcBgtxhrCYAC966n9 9LcRa2Xx5q7buYyo7hhS6xhZTyvjCNAVtUaUzECkVdJ3dMORTaM9kkRQO1PPBYlMHoE5 uLQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=hMjnxV0GnFj2CSor8E3F7ywKx8ZqWT73m+9Cg9mTc0I=; b=CJrvxPGiUjxSMFgGfxzTSgc4VgpfHioM/VMGOj6DgUuqJY4eIp6Z7KE7lIZcx4yBnw Slaz7T0koI3wlAGmdN9w2mWmzgNJPKSdvbQQnmVrWglhEs/HG+tvZqGBexrki9U8wGT/ LeQrpx8Dh/VG9yH8ZAjICRd1V9Dex9jJSMqKvB1n9GPnU3iFoU5w56qN/Jv5hC/1PoRQ uYuysWNe1bKdT8Q3hi4171z0bd0VLzNRHa8JmqI8jDT6/V+LZzXXDtpPYLNAKSlXW9CO FfPq8WRKh00m8fyrEKa+WcnaBJv8qL+w9zxLQa03drG1DdG7ZsmRYdeOruvEsiq3s+ld d1wA== X-Gm-Message-State: AOAM5313PpONNc6B3qzP9h81NLz4nw2XLLApGsWAFKhCJfXCJAPP6O7u oKGO/aMCYV5Gkd8NJDrhX7Q= X-Google-Smtp-Source: ABdhPJzM074HV5/+qzKqbSEKkUCYmOGcd3K7CQJbyJDhO2N3GuyVvwZHiiPbJmprB2u0EkXiohKqTQ== X-Received: by 2002:a65:43c8:0:b0:378:7add:ec4c with SMTP id n8-20020a6543c8000000b003787addec4cmr12509854pgp.570.1646721189783; Mon, 07 Mar 2022 22:33:09 -0800 (PST) Received: from 9a2d8922b8f1 ([122.161.53.68]) by smtp.gmail.com with ESMTPSA id z16-20020a056a00241000b004f3a647ae89sm18559292pfh.174.2022.03.07.22.33.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Mar 2022 22:33:09 -0800 (PST) Date: Tue, 8 Mar 2022 12:03:04 +0530 From: Kuldeep Singh To: Rob Herring Cc: Linus Walleij , linux-arm-kernel , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/2] arm: dts: realview/versatile/ste: Update spi clock name Message-ID: <20220308063304.GA67419@9a2d8922b8f1> References: <20220307205357.66322-1-singh.kuldeep87k@gmail.com> <20220307205357.66322-2-singh.kuldeep87k@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220307_223310_689143_DB220CC2 X-CRM114-Status: GOOD ( 18.87 ) 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 Mon, Mar 07, 2022 at 07:14:09PM -0600, Rob Herring wrote: > On Mon, Mar 7, 2022 at 2:54 PM Kuldeep Singh wrote: > > > > SPI clock for pl022 is "sspclk" and meanwhile few platforms such as > > realview, versatile etc. specify "SSPCLK" as clock name. Even though > > bindings checks don't differentiate between the two names still keep > > same convention throughout i.e sspclk to align with other platforms. > > I don't see the point in worrying about this. The binding already > allows both. Why? Because I wrote the schema and checked it against > all the in tree users. The resulting warnings are what should be fixed > in the dts files IMO. What's not warning doesn't need to be fixed. Hi Rob, I personally share a different opinion though. Kindly bear with me for my explanations. As there were no checks on DTs before, so DTs have been defining names which may not align with bindings. In case of pl022, doc says sspclk is connected clock and whereas binding specify SSPCLK and sspclk both. Why keep both versions in bindings? just because DTs have it. I don't think it's justifiable enough and that's what prompted me to keep single entry. Please let me know in case my understanding is incorrect. I kept "sspclk" as it is aligned with "apb_pclk" and I have not seen many DT defining names in caps. Moreover, I ran out few checks and came up with some observations: 1. Keep SSPCLK in binding, 'make dtbs_check' doesn't complain. An obvious behavior. 2. Remove SSPCLK from binding, 'make dtbs_check' again doesn't complain. For 2), though binding doesn't have SSPCLK, still DTs with clock-name SSPCLK do not complain which further leads me to conclusion that casing is not considered while comparing. So, why should we keep both and can't simply discard other one. This may not be a concern as per warnings point of view, but let's say in future comparison checks get even more stricter, then this will roll out as a warning and needs to be looked again. Why shall we leave out a chance which may need to be revisited later? Regards Kuldeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel