linux-kernel - Re: [PATCH v6 0/6] Add module support for Arm64 Exynos MCT driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aSCBKRpA4jSw1iuF@shell.armlinux.org.uk>
Date: Fri, 21 Nov 2025 15:11:37 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Will McVicker <willmcvicker@...gle.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Alim Akhtar <alim.akhtar@...sung.com>,
	Donghoon Yu <hoony.yu@...sung.com>,
	Hosung Kim <hosung0.kim@...sung.com>, Rob Herring <robh@...nel.org>,
	John Stultz <jstultz@...gle.com>,
	Youngmin Nam <youngmin.nam@...sung.com>,
	Peter Griffin <peter.griffin@...aro.org>,
	Tudor Ambarus <tudor.ambarus@...aro.org>,
	André Draszik <andre.draszik@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	linux-samsung-soc@...r.kernel.org, kernel-team@...roid.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 0/6] Add module support for Arm64 Exynos MCT driver

On Thu, Nov 20, 2025 at 06:42:28PM +0000, Will McVicker wrote:
> This series adds support to build the Arm64 Exynos MCT driver as a module.

There are parts of this that are just totally incompatible with it
being a module. For example, you can't register a replacement udelay
loop after the system has booted.

This is the second time I've faced a patch series wanting to remove
__init anntations to call it from a module, where the author has
clearly not analysed the code to see whether that is a valid thing
to do. This is unfair on reviewers - it is the submitters
responsibility to check that what they are doing is valid.

Moreover, in _this_ case, you will have received a kernel diagnostic
message stating that the call to register_current_timer_delay()
was ignored, so I also question whether you bothered to run-time
test this change.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!