From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E07932F0681 for ; Fri, 21 Nov 2025 17:52:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763747526; cv=none; b=H/g2vYCdz27uUuAn9gsbK3mkzvdXf9FgexQ9eB9jv2XAUavv0sl77V+b09TjhoH3vtC80c5lj2A3HMFjybqHXpmKjRUAn5YeE28ziVElkk+/67zczEIoAG34hhTBvCfPkviXF/dFjG2xThHL+zcmzYHNPa9Nk6P4Yve1Y69oaC0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763747526; c=relaxed/simple; bh=H6Nmw2cOUCXV1RMAwGf1wSN9k4qMYCw+aluImtFnens=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jv+u2mlL2hEEZNeEl4JqJ8zJbo1cpnoXjjZeVI4dSDcz27NMLWwGDBQzFQINyaA0tB51lGlIh8nm5SkC38yJsPIk7G42nBQQgRRtT1R+0qKYhPPEClurUHWlNEsMQJOsNTMqnfZ0ayKvfxIPRVclOV7GKRHHvIlSRFE2GoQVQRo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=pyOwuSxW; arc=none smtp.client-ip=209.85.210.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="pyOwuSxW" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-7a9cdf62d31so2822109b3a.3 for ; Fri, 21 Nov 2025 09:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1763747523; x=1764352323; darn=vger.kernel.org; h=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=2ZYN6CUWohQloljnDLqdKdUMC90qRAZ5XfNki7IHyQA=; b=pyOwuSxWfMObuvFKz9K5jHMEl70J5FmSrsCekpxvMyct1hPQjkcHo9kIHJLBnE8Kqv XhbM63q6FrutqEomifISBHFQAjG4Qw2g5MmLs2n3qZ7A8DYfzAV5u97DXpDfaX6kYuUH B7eUOE/o4gj21yx4j4v1DC+JtHLwRQGXlCgsOcc56mDZPUeQP0XUIRTy+DOqh7w64+A+ Hm1Cq1Nts2q7b+zjBE8Xcs93AxXwtoiTxoJyaQJyEHqyCeAcnhy6HVoGcSPpd/dOfHPe E3sIKCHT1kAFKxKYn8TGUorh0UM5E43lWXLH2A2dluRSCtOsmog+6q2MtV20L9Puxcvj Gt+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763747523; x=1764352323; h=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=2ZYN6CUWohQloljnDLqdKdUMC90qRAZ5XfNki7IHyQA=; b=E6Hta2FAzBU5BqJCLmpZNdco2moXCnHB/Y8FlumXrVoi2H5tfXoDp2Rrms8vp8Wgbd JxWB83bGOMeiyPhOAtKlSYSVFKYpftvCNLLk1WTMwfcsrswtEhR8DH2BFv1GHqx3TgGr /QEgNuamd4SZs07QbevCX+rjMnGeaiyG5IyaFZE8mnZcxZ+cNyRw7z19UzP0O3w6Ioh8 jkijUDLIp74vueIxuqvXdMnQszVpTbUSz7AVwpEpgLFbizAjacZ1QDOmgNzwRiglnyAw 1d3IGyLohSDNXZpEpRNZR4hJUFf/KDcpwooSwcNqlA81KEK6co9pduIyqdBFzuVAcnop btaQ== X-Forwarded-Encrypted: i=1; AJvYcCVfPJDblmkvhEE/ealrFhopx5iTVF3j/H1CZhO/R4K25n4oIKWhirf26Llh0uy+oLRwaW5vt3Yd6xEk+3k=@vger.kernel.org X-Gm-Message-State: AOJu0Ywtsxrd/TbQ7NNE0yNmOYIxU/AJg0wXXglZWk3vI6JrYTSHb0Zu b1Cpvzlfkb74XKEdkY/C6rEfmMShbdaDKmyVzmChzbPx5E1UBZ5Qhs1W9h/+cdFwKQ== X-Gm-Gg: ASbGncsw5WN0br63yproRAkDpVgNsrSZI6g9TAZgmauFOAhtlcrYvv0RsK1HE3rZnYm jhPml6im6DeTGPiPnAkz0aNYs3+zdQX+HoOf974oc5Hs5Pj4SKRqxRBt32K6YEWY1wc7A2o4Kfu SrfMZH6T/jL33UcLnG+QRzs5QXPhf4macSUYOZ6tp5c5ytPdT5T3IbrsGt6AH1vG6/DQNSDiNSg jgLg8+dl5LTJZZPndl9GKZchB4BtFbf3II6qIyWen5W61ZxCLltu+kFW/bEI9+9WDYvUV7GCVMZ TLzc4TRqaNLfWsSd+CsA7xUdAIzVf/1hPabzVCRqvqZQ2JiDNJ+4JqSE0WBeggGtVIBVztCOnEw XR7eHo3/0c3swnO2hYTfMIQBmDrT3kx9woiA2DssoSoXA8djuPgGKm//u6bB6C0vdSisvn9kwnq qG8QGyczmCEV/TDGNwxmiGuP+VprnXwSsxIz7NmdQkRStZ+4t2Zdp920A= X-Google-Smtp-Source: AGHT+IFPL3FivnOWfid8exhOdWBbh9Ql9Sf8cs9AXnf97m9xxC/jy3I6lLegY3I666JwhN5KsK/Tfw== X-Received: by 2002:a05:6a00:9286:b0:782:5ca1:e1c with SMTP id d2e1a72fcca58-7c58e112b18mr3708723b3a.21.1763747522951; Fri, 21 Nov 2025 09:52:02 -0800 (PST) Received: from google.com (226.174.82.34.bc.googleusercontent.com. [34.82.174.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7c3f174ba7dsm6627878b3a.64.2025.11.21.09.52.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 09:52:02 -0800 (PST) Date: Fri, 21 Nov 2025 17:51:58 +0000 From: William McVicker To: "Russell King (Oracle)" Cc: Catalin Marinas , Will Deacon , Daniel Lezcano , Thomas Gleixner , Krzysztof Kozlowski , Alim Akhtar , Donghoon Yu , Hosung Kim , Rob Herring , John Stultz , Youngmin Nam , Peter Griffin , Tudor Ambarus , =?iso-8859-1?Q?Andr=E9?= Draszik , Conor Dooley , Marek Szyprowski , linux-samsung-soc@vger.kernel.org, kernel-team@android.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 1/6] ARM: make register_current_timer_delay() accessible after init Message-ID: References: <20251120184242.1625820-1-willmcvicker@google.com> <20251120184242.1625820-2-willmcvicker@google.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: Hi Daniel and Russell, On 11/21/2025, Russell King (Oracle) wrote: > On Thu, Nov 20, 2025 at 06:42:29PM +0000, Will McVicker wrote: > > The function register_current_timer_delay() is called from the > > exynos_mct clocksource driver at probe time. In the event that the > > exynos_mct driver is probed deferred or the platform manually unbinds > > and rebinds the driver we need this function available. So drop the > > __init tag. > > First question. Why. Sorry for not explaining this very well. Let me fill in the gaps. > > Second, have you analysed the code to check that you _can_ call this > after init time? > > Let's look at the code: > > if (!delay_calibrated && (!delay_res || (res < delay_res))) { > } else { > pr_info("Ignoring duplicate/late registration of read_current_ti > mer delay\n"); > } > > So, if delay_calibrated is set, then this will fail. When is that set? > It's set by calibrate_delay_is_known() and calibration_delay_done(). > When are these called? Basically after calibrate_delay() has finished. > When is calibrate_delay() called? It's called by start_kernel(), while > the init sections are still present. > > So, calling this _after_ the init sections has been freed will result > in the above pr_info() printed and this function doing *nothing*. > So it's utterly pointless to call if the init sections have been freed. > > Please find a different solution. Sorry for wasting your time digging into this! You're right we shouldn't (and don't) call register_current_timer_delay() after the init sections are freed. This change was made purely to address the section mismatch compile-time errors. The Exynos MCT driver cannot be compiled as a module for ARM 32-bit devices; however, since ARM64 and ARM devices both call the function exynos4_clocksource_init() and ARM64 configurations can set the MCT driver as a module, we hit a section mismatch error due to calling an __init tagged function -- register_current_timer_delay() -- from a non-init tagged function -- exynos4_clocksource_init(). If you inspect the code, you will see that register_current_timer_delay() is compiled out of the driver for ARM64. To avoid hacking up the MCT driver with more `#if defined(CONFIG_ARM)` to handle this section mismatch, I decided it was cleaner to drop the __init tag. I'd be happy to re-factor the MCT driver to split up the ARM and ARM64 parts of exynos4_clocksource_init() to avoid the section mismatch altogher in order to keep the __init tag for register_current_timer_delay(). Given the comments here, I think that makes sense. I hope that explains it. Let me know if I overlooked anything. Thanks, Will