From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a3-smtp.messagingengine.com (fhigh-a3-smtp.messagingengine.com [103.168.172.154]) (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 4FEA11D5ABA for ; Tue, 3 Feb 2026 17:19:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.154 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770139191; cv=none; b=RZr8He7gOgSEFG9ww2KGSiuow12wL33wnkSyVW9xTGzmItUAqpT8tL9YCboN5IIj1XOxGu4aydRzntrBe+ikOAf2zP/jqGf+1ighVtRAqK3/WNW5/lKGGEg/laST4QCs5L2p2JWBJXkkn1sjaMg1FDykNwOZmvYTrpIzdE/7gr8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770139191; c=relaxed/simple; bh=36s1qsNys6uJjcPWSgXuohI0x/wE4Sb01U75MUOwIFM=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=nSfk54zL47JkD42DBY6xIDf8Zh/iqlzXJixNiynB/sQGOBHPgFDzAgjqBJOk/yZM+xY60UYtUqq/7Dwr8+rC677GIcbCD0fYb7nKGCtlocIuLClMQ4yCcP2qBAdcKk0CuvyOBiS3q1mqV1rFiUPF7LWwpYPybBHbUBVri8CQGss= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=euWKCmON; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=HQJvMqr0; arc=none smtp.client-ip=103.168.172.154 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="euWKCmON"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="HQJvMqr0" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 3E96F1400087; Tue, 3 Feb 2026 12:19:48 -0500 (EST) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-04.internal (MEProxy); Tue, 03 Feb 2026 12:19:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1770139188; x=1770225588; bh=fpSajIVZjkZZLcEgZT2wYAImlkh3WeN99av2xam9naA=; b= euWKCmONC965n640l7qWtqVS3FYbGPKjBpEyaztDTFQPBii9umSgtdcBQIjqjmnf jW43Dle9DCwQ9rWGrcmpqxuhmz9CU0fGEEtVbWcVxSKRyREcuKY1UPpQabJAUbBs CSnx8pl+giDRZgK00FSRed51vYpUNPoyW6RysBQu7Ii4hNwOLWgrH8es38Mx//dg Rgen+J+gaIC5PuoLfNdkpPQ7kbVR6QhEtECrz9Z1C9Pk6Miux2+oQlL/guGYmb2z 6wUdEKw1dSW28xAJg0hAeXZ35dNXPimwRnrne6B9nV1qR/1FqtnKc2wUbnQaqUbS 5gKMblzG64XE/qmN5F5yBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770139188; x= 1770225588; bh=fpSajIVZjkZZLcEgZT2wYAImlkh3WeN99av2xam9naA=; b=H QJvMqr0ObN97cp+qltQa2RE9+zSX2qqLtSqAF+4Gc0wLqAEwxHy0m6T0iu4DkOMJ +/quGG1sOL1BYdEgC8ASzxbI0b8MW6Rpc+jasTxMQYkEdNJ2aaMSy8VRTsQtyMN/ puRp+swlAgGIQbAcnsIV8zkfI0P5b/lqDSyfA2f+ABrjHwL2C2tnq0gkZA+fvV3g qXYPeYkEmFfFwOJularvy64k13GkPykuEKZiRLUd+z4abpKJWtZkypruvjiXydM5 C6Z7azwVsOHHz2AMwqcD7JzxmVo2O4QmVZImSt7wv/6T4rGtaa19MiCGxKrhtr1X gXc4v/WXS6/R7/FSxOlsA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddukedtieefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedftehrnhgu uceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrthhtvg hrnhephfdthfdvtdefhedukeetgefggffhjeeggeetfefggfevudegudevledvkefhvdei necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghrnh gusegrrhhnuggsrdguvgdpnhgspghrtghpthhtohepudehpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegrlhgvgigrnhgurhgvrdgsvghllhhonhhisegsohhothhlihhnrd gtohhmpdhrtghpthhtohepphhrihhmvgdriigvnhhgsehhihhsihhlihgtohhnrdgtohhm pdhrtghpthhtohepfigrnhhgiihhohhuudeshhhishhilhhitghonhdrtghomhdprhgtph htthhopeiguhifvghiheeshhhishhilhhitghonhdrtghomhdprhgtphhtthhopehjohhn rghthhgrnhdrtggrmhgvrhhonheshhhurgifvghirdgtohhmpdhrtghpthhtohepfhgrnh hghhgrohduudeshhhurgifvghirdgtohhmpdhrtghpthhtoheplhhinhhugigrrhhmsehh uhgrfigvihdrtghomhdprhgtphhtthhopehlihhuhihonhhglhhonhhgsehhuhgrfigvih drtghomhdprhgtphhtthhopeifrghnghihuhhshhgrnhduvdeshhhurgifvghirdgtohhm X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 731EE70006A; Tue, 3 Feb 2026 12:19:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AdHIckEZVcNF Date: Tue, 03 Feb 2026 18:19:25 +0100 From: "Arnd Bergmann" To: "Yushan Wang" , "Alexandre Belloni" , "Drew Fustini" , "Jonathan Cameron" , "Krzysztof Kozlowski" , "Linus Walleij" , "Will Deacon" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: fanghao11@huawei.com, linuxarm@huawei.com, liuyonglong@huawei.com, prime.zeng@hisilicon.com, "Zhou Wang" , "Wei Xu" Message-Id: In-Reply-To: <20260203161843.649417-2-wangyushan12@huawei.com> References: <20260203161843.649417-1-wangyushan12@huawei.com> <20260203161843.649417-2-wangyushan12@huawei.com> Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, Feb 3, 2026, at 17:18, Yushan Wang wrote: > The driver will create a file of `/dev/hisi_l3c` on init, mmap > operations to it will allocate a memory region that is guaranteed to be > placed in L3 cache. > > The driver also provides unmap() to deallocated the locked memory. > > The driver also provides an ioctl interface for user to get cache lock > information, such as lock restrictions and locked sizes. > > Signed-off-by: Yushan Wang Hi Yushan, Thanks for your submission. Since we are in the last week of the merge window, this is not going to be linux-7.0 material, but I'll have a quick look for now. > .../userspace-api/ioctl/ioctl-number.rst | 1 + > MAINTAINERS | 6 + > drivers/soc/hisilicon/Kconfig | 11 + > drivers/soc/hisilicon/Makefile | 2 + > drivers/soc/hisilicon/hisi_soc_l3c.c | 357 ++++++++++++++++++ > include/uapi/misc/hisi_l3c.h | 28 ++ I don't think this should be in drivers/soc/, since I want to reserve that for internal drivers without a user visible interface other than the soc_device information. (yes, there are a few historic counterexamples) I also don't think this should be a hilicon specific interface, if possible. The functionality is not that unusual in the end. We had similar concepts using the numactl system calls in the part, but I don't think we should do that here because you may need the numa interfaces for other purposes as well, and it may be confusing to existing callers. Having a generic madvise() based interface would be great, not sure if hardware support for that is common enough for that. > + /* Continuous physical memory is required for L3 cache lock. */ > + pg = alloc_contig_pages(1 << order, GFP_KERNEL | __GFP_NOWARN | > __GFP_ZERO, > + cpu_to_node(smp_processor_id()), NULL); Since this is a user allocation, should that be GFP_USER instead of GFP_KERNEL? > +/* HISI_L3C_INFO: cache lock info for HiSilicon SoC */ > +#define HISI_L3C_LOCK_INFO _IOW(0xBB, 1, unsigned long) The specification here looks wrong, please see Documentation/driver-api/ioctl.rst I think for your implementation it should be #define HISI_L3C_LOCK_INFO _IOR(0xBB, 1, hisi_l3c_lock_info) > +struct hisi_l3c_lock_info { > + __u32 lock_region_num; > + __u64 lock_size; > + __u8 address_alignment; > + __u64 max_lock_size; > + __u64 min_lock_size; > +}; You are leaking kernel data because of the padding in this structure, please rearrange the members to avoid padding. It may be better to use a different interface instead of ioctl(), possibly exporting global data in sysfs. Arnd