From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 E7C57427A16 for ; Mon, 29 Jun 2026 15:48:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782748103; cv=none; b=r7b/TQ1iaTuQhiP8XZnMgyyvVKaWPKWTKR60tAZDwuZBTqGVr1HvCApvQ9dPOWNSybemWBUFCAalpy/5KVKrZEM/EL3OcYhUB5Pl+Xvq7+31AAJbTlZpY6OXG3ffbQyH0GYJZYrL1bl8jaQWryToSN+0pH8HlTMNeobMw5OGdrU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782748103; c=relaxed/simple; bh=xEj2dKDGeASR+fSR2Rl0OKNkvS5xk75qjuIZf3NSAJ0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ScvYeMAlqqTpnSnfPi29exMELovAyqPeK5hitEnmlwwtmEycBMiI7gF0eXRFrOjUezRJhqxYxnDMBze8GFS2z9SjghHPiVlLHKvvX2fEMVSm69AVLnBYyp4jfay7hSymPNz2qd64D1S1q6nNZaa5P+L/cWclv0eRz0yr1g74g8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=aXeqHSD3; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=aPWqSA1w; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aXeqHSD3"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="aPWqSA1w" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782748099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5qsO792Ztaa0qn5nI0kJBMOa5Ndy7BivqDU0OQn0EDk=; b=aXeqHSD3FHmzjGYoyXXNko8aigdQgmTf7pMk+JXT4QIclq2V3qCJ0UY7TgYQ9y6j5gX7dT YjMLn3e3de7LoGPBCxTIpzjeJJCsCXxZmGopVkGxlJUVBA6UAQLgEww0956OcN9/m0NuWK pKERJhaigv/HR6ZE0G4pUc00l6yPi2M= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-633-mI4bbTjYNeO7nz1MSKDq3g-1; Mon, 29 Jun 2026 11:48:18 -0400 X-MC-Unique: mI4bbTjYNeO7nz1MSKDq3g-1 X-Mimecast-MFC-AGG-ID: mI4bbTjYNeO7nz1MSKDq3g_1782748097 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-92ae405b5eeso445047485a.0 for ; Mon, 29 Jun 2026 08:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782748097; x=1783352897; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=5qsO792Ztaa0qn5nI0kJBMOa5Ndy7BivqDU0OQn0EDk=; b=aPWqSA1w99vyc3/BXLJ+BrznWgIAnP7X5gj1EtG2y1KF9LkFMLciagnaa4ehNNt6gy 3ZH6Jx4rKk7affpUP7sBwAsEJ5vY0B5Es2iTfGzX/50FLhQW8CNvWgZypGDN8N/3YxuJ 3oXakenjcVDAZSz4uU13B+l22tgb6nkSIVJPpT5fiTU0vsAoNGWOqm4iTURR8ltH9Nkb WIUXYqZADabcAsb0qmtkMgYvgj9HAQgpYYelPSnT6mTBx1Jbk6NKXQZuvGrAV8ZlgeHU fIj92jxiBonTh8dU7KK1j1eawDHFBbS+sHstNbya7sc4mMSGjNDSgL5OzXcdh1klorV0 w/Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782748097; x=1783352897; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=5qsO792Ztaa0qn5nI0kJBMOa5Ndy7BivqDU0OQn0EDk=; b=clmNykSO/f+5xbDy2Ojd6XlKsIlCBQuyZ9ucqS5gu/BSG7hQy5Ne0tI8+jasaYSvyJ UBVNakWbT2BSUyyAb8Yxk8O6DQPHvSOaw5ZlCH9uTRRsXGKWZ4FLes7oO/zthG+krjZY VvZjvV/fAXsBHo8yopb7S2Z6JUmBewFT5+Rizmi3al2BIefoeVDUmU5Ud1EcemJltNBH hTnw1iAuaEnpdxNcNMBOWgfDh/UQeqVcoF89UeEqLPpyVetR1+tyA7HcpaqGU3J3x/40 d9mZXqQdQzHC3+0ykREtOwcJGdwuRLEEQBnKiy7RoinzQjEBdSQ9o7gVfS3jZecWCDOK 33+g== X-Forwarded-Encrypted: i=1; AFNElJ/qlT97r5BsIxP8GBZ3uvao7Yg9TLHf0vJXqQGFSS/SNq7yDASU/Zf7ZYu/Av45NftxKl5BCQv7hzJHfQc=@vger.kernel.org X-Gm-Message-State: AOJu0YyDrkiZV0z2Llv0PI0oS/RgUEECtzx1Sj0sCHGukh0z6uAt8/ou ym85DgQ5Rxc1QnLnZKlJWasuZglx10N/CMXQ2MF4Rx+7bAgBJLjuqYivSz1mfmhvdmxDuMKn930 GsvkIHUKHMC6GkvWrPa3E3bcRf3r4PPtHupOJjJYmbkElWHI/FcyWxiJeQRdmWppxmg== X-Gm-Gg: AfdE7cmTnib6y1Cc7egq/uGEJl0A++e9ojtJMPKLRNTDT2iWm6pjb6h9S04uVpBx8Kn E9K6w11oMKMmSa8sBp05nszv2erTV60WpxCSoNb/dTxDHsTDGjJLNcEon4Vr5YawDfJDZU8xKeQ +69VAUbbyWzmcTHWuH94mTZ27uOIrUbU7jbXJSZJcPM5n14si/xxvJRTnwyagux4nKrtlWuXFFY ORlAphGJcvFPGs3nVfEz+cO41DznFbx0miQTViK7L7je28ztRN4W8BFJs5FUADItwXzgsPMDAdA Ae882TtMbTrKUUTiwxVertLn1h1u5P6/L6VkFy3YfBNAUNEH/4lj9xp//8cJ4DHAptCfRj+AhLh ++jOUYUQ5v8QOXv/HEQgBJEDyLQ9cDeA8UlnTTz/OQG6ErA== X-Received: by 2002:a05:620a:4690:b0:92b:6805:9193 with SMTP id af79cd13be357-92e627e2931mr13885885a.59.1782748097382; Mon, 29 Jun 2026 08:48:17 -0700 (PDT) X-Received: by 2002:a05:620a:4690:b0:92b:6805:9193 with SMTP id af79cd13be357-92e627e2931mr13870385a.59.1782748096281; Mon, 29 Jun 2026 08:48:16 -0700 (PDT) Received: from redhat.com (c-73-183-53-213.hsd1.pa.comcast.net. [73.183.53.213]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8f1a69c283fsm947266d6.26.2026.06.29.08.48.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 08:48:15 -0700 (PDT) Date: Mon, 29 Jun 2026 11:48:14 -0400 From: Brian Masney To: Konrad Dybcio Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , Ulf Hansson , Bjorn Andersson , Michael Turquette , Stephen Boyd , Russell King , Neil Armstrong , Xuyang Dong , Jens Glathe , Hans de Goede , Maxime Ripard , Saravana Kannan , Abel Vesa , driver-core@lists.linux.dev, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org Subject: Re: [PATCH 4/4] clk: implement sync_state support Message-ID: References: <20260626-clk-sync-state-v1-0-4156d8196dc8@redhat.com> <20260626-clk-sync-state-v1-4-4156d8196dc8@redhat.com> 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: User-Agent: Mutt/2.3.2 (2026-04-26) On Mon, Jun 29, 2026 at 03:44:26PM +0200, Konrad Dybcio wrote: > On 6/26/26 6:32 PM, Brian Masney wrote: > > The existing support for disabling unused clks runs in the late initcall > > stage, and it has been known for a long time that this is broken since > > it runs too early in the boot up process. It doesn't work for kernel > > modules, and it also doesn't work if all of the consumers haven't fully > > probed yet. Folks have long recommended to boot certain platforms with > > clk_ignore_unused to work around issues with disabling unused clks. > > [...] > > > [ 0.366737] clk: Disabling unused clocks not associated with a device > > [ 0.367232] PM: genpd: Disabling unused power domains > > [ 7.791413] qcom-qmp-pcie-phy 1c24000.phy: clk: Disabling unused clocks > > [ 7.799702] qcom_aoss_qmp c300000.power-management: clk: Disabling unused clocks > > [ 8.548820] qcom-qmp-pcie-phy 1c14000.phy: clk: Disabling unused clocks > > [ 9.121849] qcom-qmp-usb-phy 88f1000.phy: clk: Disabling unused clocks > > [ 9.121985] qcom-qmp-usb-phy 88ef000.phy: clk: Disabling unused clocks > > [ 9.122691] qcom-edp-phy aec5a00.phy: clk: Disabling unused clocks > > Many of these drivers only register fixed "virtual" clocks that > don't lead to any registers being altered and only exist to convey > what the clocks look like on the hw level.. but I don't think we > have great infra to skip that.. > > > [ 9.122760] disp_cc-sc8280xp af00000.clock-controller: clk: Disabling unused clocks > > [ 9.142121] qcom-qmp-combo-phy 88eb000.phy: clk: Disabling unused clocks > > [ 9.169149] qcom-qmp-combo-phy 8903000.phy: clk: Disabling unused clocks > > [ 16.057997] qcom-cpufreq-hw 18591000.cpufreq: clk: Disabling unused clocks > > [ 16.058149] clk-rpmh 18200000.rsc:clock-controller: clk: Disabling unused clocks > > [ 16.334879] qcom-qmp-pcie-phy 1c06000.phy: clk: Disabling unused clocks > > [ 16.706113] camcc-sc8280xp ad00000.clock-controller: clk: Disabling unused clocks > > [ 21.565731] q6prm-lpass-clock 3000000.remoteproc:glink-edge:gpr:service@2:clock-controller: clk: Disabling unused clocks > > [ 21.597069] va_macro 3370000.codec: clk: Disabling unused clocks > > [ 21.605039] rx_macro 3200000.rxmacro: clk: Disabling unused clocks > > [ 21.630313] wsa_macro 3240000.codec: clk: Disabling unused clocks > > [ 21.635069] tx_macro 3220000.txmacro: clk: Disabling unused clocks > > This is a bit noisy, but then it's necessary for debugging the > related hangs. Maybe if it turns out to be a huge issue, we can > hide it behind a _dbg() in the future. Agreed. Personally I think we have this go in with dev_info() initially, then after it's been there for one release, move it to dev_dbg(). > I was hoping/expecting that sync_state would completely replace the > late initcall (which would also simplify this diff), but I'm surprised > to learn that there's a whole bunch of clk_register(dev=NULL) > calls in the kernel (are most of them doing it for no good reason > by chance?) Yes, correct there are a ton of clk drivers that use clk_register(dev=NULL) to register clks from __init early in the boot. My understanding of one use case is that this is needed to setup arch timers that have a dependency on a clock. My understanding is that lots of drivers that register clks in __init don't need to do it from there. Brian