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 74666C433F5 for ; Thu, 17 Mar 2022 21:10:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230113AbiCQVLv (ORCPT ); Thu, 17 Mar 2022 17:11:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229989AbiCQVLr (ORCPT ); Thu, 17 Mar 2022 17:11:47 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 611E6FDE3F; Thu, 17 Mar 2022 14:10:30 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id z3so5481366plg.8; Thu, 17 Mar 2022 14:10:30 -0700 (PDT) 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=5119qc3EtEQdDi8mG4lL3e8ynwtRHGtpJfUH9ad79BM=; b=cLbT42cpQNWZwjJlG1HnfdtUY2sEaO3MFC70NXE52i6GLZibAK6Lc+lPwcNb8Ix9pl KERlUCP/9Nu8tzePGfDRvKLgtyQpV9zbLKOP3MmzlIBK9OaRMaBz31mVX/VzB0K4+nEQ nvXspkRLxRJg5R3ZB2ih+tf0A9N34hPWap1kgA99fyVmUNOK/X7LkBFR81em8dCeb0om sdTaSTkk+0RIHwCQ7IDD3jDo4xa86MYRSCSwbYhAp2QWnirLfqKmhEgmwpa80PDQBZRl FjpOb12nlrmX0h9IV+bjY6i6u4jq69yZDk3XP4+M3sHvjwIcNg7KcB5b5zs1ukiJ5IVf tXSA== 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=5119qc3EtEQdDi8mG4lL3e8ynwtRHGtpJfUH9ad79BM=; b=OmWw7R2rWGKffukMTY1LJMV3WbIh2CIC7o8IiIcKEYik+5oAp7ZpU4t7VGGIqK2OXC KIDyQmIxdn+6KtCCNyxL01Jn2jcQu0jQFdJ2c8vZb+xAxiuFUtnJISH28ze0DgM+bEW1 NwYtytOmUraEdJSguZ3F1CyttOOFJQJcbR31cyFk9QHkLy46l0MhDJfiwBL08ytVrX6h YiToJBOl/5HkOcESDi8i2GQBVmYi/5+tVRM+3kxBPPMV0TV2Rtf60/evhgFhlPibLyCN 5pvgSbv5qCktX5YFaYjw8xjZf4KiPseVKFPrQOaCZHF7WuT8qizKEL/ICE8AesXrp1Sb CEsg== X-Gm-Message-State: AOAM5301YJOuKCQPGKKfFxRCgVW7jWg4E3o9t1fAF+/Xn51fRD8tO9Kg Ch6TimgoZq01Q8NbExKZ/17HFKrGreU= X-Google-Smtp-Source: ABdhPJxXmdglkWtd/gJOeOPGrLtSGqZac2mfJTMtH5m81DtDv/2NIUQ7qhi00BvFz4PDEuRQCWqbZA== X-Received: by 2002:a17:90b:2242:b0:1c6:80e3:71b6 with SMTP id hk2-20020a17090b224200b001c680e371b6mr6024596pjb.152.1647551429768; Thu, 17 Mar 2022 14:10:29 -0700 (PDT) Received: from 9a2d8922b8f1 ([122.161.51.18]) by smtp.gmail.com with ESMTPSA id m11-20020a17090a3f8b00b001bc299e0aefsm10187305pjc.56.2022.03.17.14.10.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Mar 2022 14:10:29 -0700 (PDT) Date: Fri, 18 Mar 2022 02:40:24 +0530 From: Kuldeep Singh To: Marc Zyngier Cc: Rob Herring , Joel Stanley , Andrew Jeffery , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org Subject: Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property Message-ID: <20220317211024.GA99538@9a2d8922b8f1> References: <20220317191527.96237-1-singh.kuldeep87k@gmail.com> <20220317191527.96237-4-singh.kuldeep87k@gmail.com> <87h77wxslh.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h77wxslh.wl-maz@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 17, 2022 at 07:54:34PM +0000, Marc Zyngier wrote: > On Thu, 17 Mar 2022 19:15:26 +0000, > Kuldeep Singh wrote: > > > > Arch timer either require clock-frequency property or doesn't need to > > specify clock at all in DT. In general, frequency can be determined > > internally and in case of brokern firmwares, need to extend > > clock-frequency to pass info to driver. > > A clock frequency and a clock are not the same thing. Yes Marc, That's what I have mentioned in commit description. Driver uses "clock-frequency" property only and doesn't take inputs from "clocks" property. So, any platform should refrain from defining such entity at first place in DT. Binding also says the same i.e pass info via "clock-frequency" property and no mention of "clocks". > > > > > Aspeed BMC is the platform which defines clocks property, an invalid > > entry which can be safely removed. > > Safely removed? Says who? Have you tested this change? Since "clocks" is never read by driver and driver incorporates "clock-frequency" which was certainly not defined here, I believe this reasoning is sufficient for my clause. As it's safe to remove an entry which was never used. Please note, it's just Aspeed BMC which had "clocks" defined, other platforms which require input from DT have extended "clock-frequency" property like I mentioned before. I don't possess this platform physically,and did successfull compile time testing. I have initally copied few Aspeed folks, they can help in reviewing and confirming this. > > > > > Moreover, clocks also matches incorrectly with the regex pattern. > > Remove this entry altogether to fix it. > > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+' > > NAK. That's not a reason to randomly butcher things. I hope I explained my reasons above. - Kuldeep 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 2A8B3C433EF for ; Thu, 17 Mar 2022 21:12:02 +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=MEmaAQtkYDlsdK6GkaHUOEBVREKSnCyNmlkdrrjsDxw=; b=ayI7erZl/Ibnr2 O1VDl3nivtwDCZz0mDICfOE++4Bpe+UhjcJgIW3TGXbj5T8SK4sJOAkY4qm1iUpbRjDXkemTqv9+1 zg+nY/GewkKl+3lekDYsmWsW5LgdnsHwfYGy4BTPrKtXBGBFIaiSuloxQfMYW2brqCPqty3NOFXND 5/bWzrqQSWtK0ASTDvgjtXTg34eSyjH9Rv/m0SfxSitpzCdHje3VTTVuS3d+EO9dygZEOH2uvQbpz iccA9EiLXOPdF49TLpcae+COZU+uCoDYt+EIsTNBEKx6UGO367828iAQKGDyaLGE6s3w8GNl8kOEa sBjjaR7sOMoSjFAJ6SLw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nUxOH-00HPaz-O2; Thu, 17 Mar 2022 21:10:39 +0000 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nUxOA-00HPZA-P1 for linux-arm-kernel@lists.infradead.org; Thu, 17 Mar 2022 21:10:32 +0000 Received: by mail-pj1-x1030.google.com with SMTP id m22so5971489pja.0 for ; Thu, 17 Mar 2022 14:10:30 -0700 (PDT) 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=5119qc3EtEQdDi8mG4lL3e8ynwtRHGtpJfUH9ad79BM=; b=cLbT42cpQNWZwjJlG1HnfdtUY2sEaO3MFC70NXE52i6GLZibAK6Lc+lPwcNb8Ix9pl KERlUCP/9Nu8tzePGfDRvKLgtyQpV9zbLKOP3MmzlIBK9OaRMaBz31mVX/VzB0K4+nEQ nvXspkRLxRJg5R3ZB2ih+tf0A9N34hPWap1kgA99fyVmUNOK/X7LkBFR81em8dCeb0om sdTaSTkk+0RIHwCQ7IDD3jDo4xa86MYRSCSwbYhAp2QWnirLfqKmhEgmwpa80PDQBZRl FjpOb12nlrmX0h9IV+bjY6i6u4jq69yZDk3XP4+M3sHvjwIcNg7KcB5b5zs1ukiJ5IVf tXSA== 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=5119qc3EtEQdDi8mG4lL3e8ynwtRHGtpJfUH9ad79BM=; b=yvWVzDPvJDmNdSg4CWSPAfrZig1qlUPpKAUnTBih8eHWRmOGgYfc7tfaHTB+6Vfd7g srJ8gj8AdQjvE5dhkhHzurzqhhK8F6E8NTzX47rzEmTqVUm04R9txHZut+7Hm2ZXUkXi dw1+TywnUWFgTUw/DGwAs1kvdM/QPLii+dSRr02WCH4KU4eKi07QRktTSyNaemceqDLP Z6Til9XRe6+A5ItyVXPDjfLiNBMnqIR0qYAEqDUz/7+diAukrvhBAwq1jPaV/9wBDnLR r2eeaYzgusPHbnzdfpIIBrhRnm6wDNy9aRToX7Pm+ls0b2Xw1GAAUFXtOaoDAY0dkf4z +8eg== X-Gm-Message-State: AOAM5302fspWTUZfPGOKy6Ta2aU/Rkpo6Txh5tp3K3NycbTNnft8fxwm bzb/FJJ/R8/mO2+aaZTWe6o= X-Google-Smtp-Source: ABdhPJxXmdglkWtd/gJOeOPGrLtSGqZac2mfJTMtH5m81DtDv/2NIUQ7qhi00BvFz4PDEuRQCWqbZA== X-Received: by 2002:a17:90b:2242:b0:1c6:80e3:71b6 with SMTP id hk2-20020a17090b224200b001c680e371b6mr6024596pjb.152.1647551429768; Thu, 17 Mar 2022 14:10:29 -0700 (PDT) Received: from 9a2d8922b8f1 ([122.161.51.18]) by smtp.gmail.com with ESMTPSA id m11-20020a17090a3f8b00b001bc299e0aefsm10187305pjc.56.2022.03.17.14.10.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Mar 2022 14:10:29 -0700 (PDT) Date: Fri, 18 Mar 2022 02:40:24 +0530 From: Kuldeep Singh To: Marc Zyngier Cc: Rob Herring , Joel Stanley , Andrew Jeffery , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org Subject: Re: [PATCH v2 3/3] ARM: dts: aspeed: Remove arch timer clocks property Message-ID: <20220317211024.GA99538@9a2d8922b8f1> References: <20220317191527.96237-1-singh.kuldeep87k@gmail.com> <20220317191527.96237-4-singh.kuldeep87k@gmail.com> <87h77wxslh.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87h77wxslh.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220317_141030_858714_F07E4045 X-CRM114-Status: GOOD ( 19.04 ) 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 Thu, Mar 17, 2022 at 07:54:34PM +0000, Marc Zyngier wrote: > On Thu, 17 Mar 2022 19:15:26 +0000, > Kuldeep Singh wrote: > > > > Arch timer either require clock-frequency property or doesn't need to > > specify clock at all in DT. In general, frequency can be determined > > internally and in case of brokern firmwares, need to extend > > clock-frequency to pass info to driver. > > A clock frequency and a clock are not the same thing. Yes Marc, That's what I have mentioned in commit description. Driver uses "clock-frequency" property only and doesn't take inputs from "clocks" property. So, any platform should refrain from defining such entity at first place in DT. Binding also says the same i.e pass info via "clock-frequency" property and no mention of "clocks". > > > > > Aspeed BMC is the platform which defines clocks property, an invalid > > entry which can be safely removed. > > Safely removed? Says who? Have you tested this change? Since "clocks" is never read by driver and driver incorporates "clock-frequency" which was certainly not defined here, I believe this reasoning is sufficient for my clause. As it's safe to remove an entry which was never used. Please note, it's just Aspeed BMC which had "clocks" defined, other platforms which require input from DT have extended "clock-frequency" property like I mentioned before. I don't possess this platform physically,and did successfull compile time testing. I have initally copied few Aspeed folks, they can help in reviewing and confirming this. > > > > > Moreover, clocks also matches incorrectly with the regex pattern. > > Remove this entry altogether to fix it. > > 'clocks' does not match any of the regexes: 'pinctrl-[0-9]+' > > NAK. That's not a reason to randomly butcher things. I hope I explained my reasons above. - Kuldeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel