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 5D102C25B77 for ; Wed, 22 May 2024 09:37:52 +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=32R/GS76JjjVfVKr4hG3KTn2UQdB3KsVh+0xEEwKcpY=; b=4k8O7/xwnquhtQ EgsEm+iy84z4QGcG+ANXAt1WdDGo9wKRItphVd4HPTbFStuTvpfKZTN3nRgz9pkxl2Es2zrPXgldo BdkN52byqbVG1hE5vhlRaidTaUVdCNLFmELvyL2pwEjw00RMO61Nii0SkHiT8SRTzgSWC1+b8h03V En6fq30V5KRhuvIN4ysOQuJ8WIqhIshRL0IjflFIpl23yHFMng0+1ugii4MzepBhQhWd9bc2lN3ww OAvfM44e/zY7pv6mCKH3WMUD626Ab1gjj97QHQ0wEykYWaiBeRv9p2ucH+W9ixiItqhkL1TaES5np 4qxDwvsb7CHzMSfl+Ecw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9iPm-00000002WMp-3ziY; Wed, 22 May 2024 09:37:42 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9iPk-00000002WMN-0PAY for linux-arm-kernel@lists.infradead.org; Wed, 22 May 2024 09:37:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FPV/MYHZk/dqJlDve20g25zBG2H8Z0c6edLJw8v0DIA=; b=MYIjKcnnnH/FEHu/DO0+PdW264 ArXQVtPQMOiQ8y6Jj4T3/GRb2ZVMksn20N8xhZ/SogvmFLdh3EQNwwjiSqm23TnkR4OgFKvWPRIjI 0qdVRSkWKOGWf5vhSDWOgloIJZ5E9OTTuYy6jowwFKbPZ21xC6OG+ARL3O2mTF3eyCLlCpQauwbMV +YY5CrNL5Su0Fr7fixAlEXnlnm+Ud3G1IfzaFHXgtKbjEkcXLo3WK+m3Jy1xAi+g6CHiHEvG/ctdc AdOpMYMKM+aLo2cKC689b5ub7RhPY6GQmn1gNQBD3S0z27rvK5Y+TbAfpUQ/cBhz4QGa6oDfzE5kJ +MVZo2yQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:37892) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1s9iPe-0004oN-2d; Wed, 22 May 2024 10:37:34 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1s9iPg-00062j-PU; Wed, 22 May 2024 10:37:36 +0100 Date: Wed, 22 May 2024 10:37:36 +0100 From: "Russell King (Oracle)" To: Linux regressions mailing list Cc: Guenter Roeck , linux-arm-kernel@lists.infradead.org, Duanqiang Wen , mturquette@baylibre.com, sboyd@kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] clkdev: report over-sized strings when creating clkdev entries Message-ID: References: <7eda7621-0dde-4153-89e4-172e4c095d01@roeck-us.net> <4ea9cc83-c7ca-47b8-8d43-dab16193108f@roeck-us.net> <646bd149-f29a-4c91-ab00-4f6d2fce23fd@roeck-us.net> <44151fe7-1822-4b95-8981-9a1f1884d662@leemhuis.info> 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-20240522_023740_224674_B9E05A31 X-CRM114-Status: GOOD ( 30.01 ) 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 Wed, May 22, 2024 at 10:34:22AM +0100, Russell King (Oracle) wrote: > On Wed, May 22, 2024 at 08:53:18AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote: > > Hmmm. Communication problem aside, this in the end seems to be a > > regression that is caused by a change of yours. Maybe not a major one > > that is making a fuzz about, but still one that would be good to get > > fixed. So who will take care of that? > > I have suggested several approaches to fixing it, and each time I'm > being ignored by Guenter, who seems to have some other agenda - > because he seems to believe that using dev_name() when registering > the clk with clkdev is wrong... despite the fact that clkdev uses > dev_name(). > > What I am uncertain about is: > 1) whether clkdev is even necessary here, or whether it is pure noise. > I think it's pure noise. Why? The dev_name() that is being used# > to register the clk seems to be the _source_ device of the clock, > whereas the name given should be the _consumer_ of the clock (when > clk_get(dev, con_id) is called, dev is the _consumer_ device, and > this is the device that dev_name() is used internally with.) Thus, > if _that_ device is not the same as the struct device that is being > passed to dev_name() when registering the clk, the entry in clkdev > is utterly useless. > > 2) why someone would think that using best_dev_name() to work around > this would be a good idea. One might as well pass the string > "hahaha" when registering the clk - because if the device name is > truncated, clk_get() is not going to find it. So, by registering > it with clkdev, we're just eating memory for no reason. > > Therefore, this change is finding bugs elsewhere. Should it cause a > boot failure? No, and I'm happy to make clkdev just warn about it. > However, reverting the change means we're not going to find these > issues. > > Why was the change originally proposed (by Duanqiang Wen) ? The reason > was because of this truncation causing clk_get() to fail unexpectedly. > > I am all for a _sensible_ discussion over this - not one that seems to > have an agenda about "should dev_name() be used when registering a > clk" that seems to be Guenter's approach because _that_ is not the root > cause of the issue and I've already explained that _that_ is not the > issue here. Yet, Guenter insists on that. ... and I'll also add that I'm up to my eyeballs with an issue at Oracle, and thus have very very little time to deal with mainline kernel issues right now, so if people appear to be intentionally obtuse and difficult, I will end the discussion as I did here _purely_ because I _do_ _not_ _have_ _the_ _time_ to waste my time with them. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel