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 7AF83C433F5 for ; Mon, 4 Apr 2022 07:29: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=qOWX9CVKQYdwdnULowTf0H00IbD1+SoK5nuXwhtygRE=; b=xOQqxS3wCT7HoK 1u87dCtqNpgM7gA8dJIHu71LPWK0H+gyVvQaUm0mMgqh7HmwBDZ85OYbLXPJ0B0rEQyPUc4/HGEhR 8ObddQZJbXeVE98IH58kgR///yklqCwgNHbl4c5LxBnV52k/Re5yvJHZzXNnA2oIt/jZyaLoKqWda bBFxesotfoIS7iKVae7xWE9ad47LmdAat+9bWXR1XPZ9I5f35bdwBcB3J7jJ0/b8Tu59/D0deUGPM d48bZ/6kzXc04vcGrpMnlSUt0L3kZD0JQ4YZKh09jGX2oA1iOVq/EKR8zl3ngzPyrIq+wPM8ep62o emJwqxSKi7R14JJ+n3KA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbH7a-00DcUX-G9; Mon, 04 Apr 2022 07:27:30 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbH7V-00DcTe-OZ; Mon, 04 Apr 2022 07:27:28 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id BD08B3201F82; Mon, 4 Apr 2022 03:27:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 04 Apr 2022 03:27:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; bh=TDH98TyHYWyK2t EdUf0NoO/6nH3Q1TMk2EezkWhx3sQ=; b=dVMnZC6J7tmVc2SUnBa4VQJJqZ20bo 6f54IrlyZ8tr75WoIHSLwBO6KSnEfdiuxUimbqbtpmF3Gr9RhlL2ZKSusEe+w1aO CI4McmjlBK5t1NSFFVUIp8y95sFNox+JBwrDbsHVRTydyk5+wcAtylD4lI9e+X7E n7gkgadc8ZMK7rn7cOl+79hP3fhNAogO9KrvuMpgHuPJ8NEhhPHkDOoZX6giePuM nIbHv3t7XmRYCkRcX9Saly/cUk+iDS3PsUuRkdpZ7fJa0kgj3hd0cocDgsSbpAkl AG0ObjjhPcY/qRGLBYQWgri0NbrsGC35+bgHQvGxEJaq9ZRrtnfB1+Ew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=TDH98TyHYWyK2tEdUf0NoO/6nH3Q1TMk2EezkWhx3 sQ=; b=f4+WBWo2dbAGquUDEXVBczIWI4+fiiWvJ5XQvUSV8sgOzp+23gO8eYlqK h14y6fc/Fn27YhO7OFqxM501oQUvwLQL0Acr1bB70UtB2lE8ATX4NBToTbjPQASr yjlxXrj4uRaV+IL8n39XTTUZsNlNXl3PzAl+edblexvqSN3ZnF2hjHiA/MqoNfBx NAD8uzbrrGz28Ev05vRofgf9HKDyRZMqfFX7z3CPAsJksL3vmoepKzfZ6TyYmYWe M/2AWLsbw3/ulG6MGvSfVfsa9ZHPWgcDjDAiCo0tGyM8rZ2c0HrtbgVxtXu/eIqW yaVnWuXx4kFjIXGoRF2DOeOL3p+ng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudejuddguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggugfgjsehtqhertddttddvnecuhfhrohhmpeforgig ihhmvgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrf grthhtvghrnhepkeeludfhledtieegfeelveetveegueeghfeitedttddvjefhgfevgfdt leegheehnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgv tghh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 4 Apr 2022 03:27:13 -0400 (EDT) Date: Mon, 4 Apr 2022 09:27:12 +0200 From: Maxime Ripard To: Alexander Stein Cc: Tony Lindgren , linux-arm-kernel@lists.infradead.org, Marek Szyprowski , Mike Turquette , Stephen Boyd , linux-clk@vger.kernel.org, Dmitry Osipenko , 'Linux Samsung SOC' , linux-amlogic@lists.infradead.org, linux-omap@vger.kernel.org Subject: Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: (EXT) Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put Message-ID: <20220404072712.bbsbkq3cpyx4xuzy@houat> References: <20220325161144.1901695-1-maxime@cerno.tech> <14273141.O9o76ZdvQC@steina-w> <20220401145502.5hnilpku3qh77bvs@houat> <4391300.LvFx2qVVIh@steina-w> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4391300.LvFx2qVVIh@steina-w> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220404_002726_504061_3A876303 X-CRM114-Status: GOOD ( 17.80 ) 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, Apr 04, 2022 at 09:06:42AM +0200, Alexander Stein wrote: > Here is the requested output: > --- > $ ./scripts/faddr2line build_arm64/vmlinux > 'clk_mux_determine_rate_flags+0x33c/0x380' > clk_mux_determine_rate_flags+0x33c/0x380: > clk_mux_determine_rate_flags at drivers/clk/clk.c:627 > --- > From a first look it seems that 'best_parent' is just a NULL-pointer here. > With this small fix > --->8--- > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > index 071857ef381a..45e081330fac 100644 > --- a/drivers/clk/clk.c > +++ b/drivers/clk/clk.c > @@ -626,7 +626,7 @@ int clk_mux_determine_rate_flags(struct clk_hw *hw, > > pr_crit("%s: Best parent %s (%lu)\n", > __func__, > - best_parent->name, > + best_parent? best_parent->name : "unknown", > best); > > return 0; > --->8--- > > The boot eventually get stuck, but at a later point.Which is probably why your > analysis found nothing strange. Due to the size of the output I put it on a > gist on github [1]. Please note that this is still based on a next-20220331 > based tree without the revert. I've looked into it over the weekend, and ran qemu on an imx6 to try to see if it was any similar I believe the issue comes from the fact that the core will forward rate requests structure to the parent clock as is, and if the parent clock changes the parent it wants, we end up trying to use that parent in the initial clock which doesn't work really well. I've fixed it in my branch here: https://github.com/mripard/linux/commits/rpi/clk-improvements-more-fixes Could you give it a try? Maxime _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel