Received: by 2002:ab2:7855:0:b0:1f9:5764:f03e with SMTP id m21csp222324lqp; Wed, 22 May 2024 02:34:57 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCV7G/DpiaxCm7xCzJ/3yryxRvz6h/rJT01+wSkAaV5vVE9u4DHNiL+RU/IBZiLmL1zlRJE0e5LS/X/HHTj8USo04WAE/QgRGBcAnL0o5w== X-Google-Smtp-Source: AGHT+IHcZWrvtuvEai1d6bk+5ihkY1Pvz4Nx9Kp+O6OvV4ddnIPsHe2V/5wI5YSWZr+p5wGfOb/A X-Received: by 2002:a05:6a21:78a7:b0:1ae:a5bf:341b with SMTP id adf61e73a8af0-1b1f874d882mr1693011637.6.1716370497122; Wed, 22 May 2024 02:34:57 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716370497; cv=pass; d=google.com; s=arc-20160816; b=0a5iczhav6+eAgjCDbR0cly+YUnm219M9jcVxRX+2JO5EutBqB6R0beH3+a4XEjkuz Q5ZgxTjhn5dgvVFSihkGZVLfCcPaDscSYD/BJYCotgwKeJ438dnbthpvENxOrQfRv+Dg CSWVKybzRyeMxJELebKr88I3kbzVCZ2yrn8A36smj+BuNHN/yBn+cilt+BcqNLxnLwdZ Xx5D18Rz1UXnz2MxPOWEVMXinbiTNuBmfFpeWcQ38NzyBfSWi4tLlMwCJTVP6HT8mDzG 9NEY8Y+/OqoCIBRCDZ3g696K7Tc6Yk3tul9t4WycqK39mhO3/ZJU0fvcKCZNSAHhJSxe y4FQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:in-reply-to:content-disposition:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:references :message-id:subject:cc:to:from:date:dkim-signature; bh=0ULik29NBLPRrUwg+mqBvlx8JWj5pFQ0AbuABh1uIWo=; fh=n5Rj8r4M0PNLSmiO+ux+abbGYBo4xbT+S2GulgtKxRc=; b=A+DLWZQiK/Z+NS+i/Sm9VjNSXcCYB+/AhjYtaBj7ZP7iU3oJr8wjWKBoC4T7FzJoTj cN/Q6kXApybJMC/YiM8FGzoXUzsiiHSEGsZNh6hr4W+SbCUHpFB9U7Jf1JC84gCgIl4L 9awhb2OgkqZiCoGP72lxZzD8KclwjjZ1Ym6J6+ReOKxhV+F7wfJ4qpC126gp2Bs5r3sA pO7Qi8dkjOJ1ko2PYdXH5fRI9Yl73Q/cZPHiiPrJKuN7+7MxTs15gFLZtc4QnmRlldf0 nucAX8lU/DWZvaC9eXptiYxId4clvBlFc2uzFxApfS77n02rTcfb51iXIk25c9RwvZsK UGMQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=fW+q7v1e; arc=pass (i=1 dkim=pass dkdomain=armlinux.org.uk dmarc=pass fromdomain=armlinux.org.uk); spf=pass (google.com: domain of linux-kernel+bounces-185993-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-185993-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id 41be03b00d2f7-676e9a350e3si740559a12.295.2024.05.22.02.34.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 May 2024 02:34:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-185993-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=fW+q7v1e; arc=pass (i=1 dkim=pass dkdomain=armlinux.org.uk dmarc=pass fromdomain=armlinux.org.uk); spf=pass (google.com: domain of linux-kernel+bounces-185993-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-185993-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 3E5A4281886 for ; Wed, 22 May 2024 09:34:56 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2667C811FE; Wed, 22 May 2024 09:34:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="fW+q7v1e" Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 16DE37D3F5; Wed, 22 May 2024 09:34:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716370493; cv=none; b=RGnitDRQHKc+mE7uMHFYoxYrGSfXCoz/mvWa/NHr2ij2ztjDyC8IEDS7XvCKvYQ/INK+mMyoZBe4Orp9BKhDJYNbwJCRcS6+Y3Tp2BSQ0q8ntRXWL7UNtUQxBCRAhZiped01OXOqrloKv6mmSJQQPQR+rCLekIFio5kmzVJ5eLo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716370493; c=relaxed/simple; bh=mX5vIgRWx9WAOsjeTaBhf88G2r0ZoYliqn7TtU06B+g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rtHQ7smmVrkbUugn49c5sVBW4SsXe3paHlUF7FPBAnHY1lPHZiW7/D7NtnbixoIaUIIizqECqkz3kGpVrv49CTNVWBEPJwpudIkyljXUuaHe85jbp/T/60amg6gWnPzjOgVicGgfStUwj7MppuKh434fe6/lqRDnty2AmbhoXVI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=fW+q7v1e; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk 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=0ULik29NBLPRrUwg+mqBvlx8JWj5pFQ0AbuABh1uIWo=; b=fW+q7v1eKF9i86BC7a3TFCWCJS pp4J5e5sVUH2nEndz39ojCjFGaOqyLglcpN9hTCtq91H9ePbGcWtzeseRil0LY5DHYUROa1VhFa8d DtObyI7YPh6BOgsEQN05gFjRG+50l9PR4gFiA7WOtRxOoJgaReLWE0WVFgG/Z1e0eK/V1bFESl0+6 UMKE1Ns3i2VsOQsgZF69Hnj4FVMZVnPMdspK7jIZyS/L9vtXR1XPKiA/Izbb5pYuDXjZ+FdNwgChw jzjQO9nZBwlQ3GoIp0qXB8gPYFCq+ScMReSX8kdfF9KszJMKIsghuRSLiHGzNi6UrUpLPRaiZivYS N57WdbAg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:45380) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1s9iMd-0004o5-3B; Wed, 22 May 2024 10:34:29 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1s9iMY-00062c-TZ; Wed, 22 May 2024 10:34:22 +0100 Date: Wed, 22 May 2024 10:34:22 +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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44151fe7-1822-4b95-8981-9a1f1884d662@leemhuis.info> Sender: Russell King (Oracle) 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. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!