From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-b6-smtp.messagingengine.com (fout-b6-smtp.messagingengine.com [202.12.124.149]) (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 B5EEB1DDA39 for ; Tue, 28 Jan 2025 09:14:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.149 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738055690; cv=none; b=CrwtJ486meiWkbFKgtQIktmLF09ADQF/g82VsLdOEQTlBze5P+Pbp4d3CmwQFkVIqOkBfs1OBf27zQAq5WHbscMrh5C8rmiic+bb2mpLo3e5nVDyqCpDnSWVEZXRAgGjDzZHMPfP7OXfKcszyAdwDFoxqbcD/g9PAcnjoN0Pt/c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738055690; c=relaxed/simple; bh=xUbXRs3KFcoLPyf5A0MBU9td3o+2SstZh2pIJ4kA/hI=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=hPDg23xQxo0eEQrJKiHOVRsO3kr1v4rR7k727t8oluNusZDgdDwPk/75X4UeHH36KGWZ8+6+uTYAkpaDeWKC/oBQ3pyDjZJUhqj4z3hOnRXEdAOErtVqGhWxbRGh/k0fCPBrh9EhLwEFi4WdmWMvKod6dGI9m8KWpzIOGQk2tYA= 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=q4DmHaDy; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=z9anPs9v; arc=none smtp.client-ip=202.12.124.149 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="q4DmHaDy"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="z9anPs9v" Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfout.stl.internal (Postfix) with ESMTP id 82BD011401C5; Tue, 28 Jan 2025 04:14:46 -0500 (EST) Received: from phl-imap-11 ([10.202.2.101]) by phl-compute-10.internal (MEProxy); Tue, 28 Jan 2025 04:14:46 -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=1738055686; x=1738142086; bh=NFzZyK602SSDC1ggEXqU9TedQHZy//5iWiXQM786tnU=; b= q4DmHaDyYe/Lg8aLDKbd4ezspWHSftKl44b2i15+yiYhvagfwMVO10g3JItZtd90 EoAhMhVyonqVMl20uRRmCdgLvZjHBSS7RJzlJW5QlcEUfpiFKKyOMjugKe810Jv4 tTIeAQW4mGYJkirYYJ/JnL6xsl21pON9N9PzK3PIv+NH3GKjkgYFNRB4js3/8km8 1z3V6kM5sfgCwdJ6wv3Jn4ha8AISebww97tcLjH0o8x49EmKmPOdQIFuZ93wR7+4 Z3o9BAeFtiuLBbvZOTqKqP7fksoSKfC/YvafGPLooJkXENtJK1NS6HK/xkOShy1k UPacctN0sjvYMy4iw6Un7w== 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=1738055686; x= 1738142086; bh=NFzZyK602SSDC1ggEXqU9TedQHZy//5iWiXQM786tnU=; b=z 9anPs9vjbTFiMT/mmwcZ+4m6MVhtZYTP9jAXRmvgXyD+UVatAZh2xHYZrwzORf8Y 3NAymjT2M8daj7HpnHSVEf0W/6FqLzBqkDF3LIpeDarOsKPb2faVy9tsC5HidTZ+ rTuI/G4PJOz6QbXyGwLMh3/TE/YslOlQV34dwqUm+kWHq68Vcmx3bEfVUeBEYLil NoSAoc/nr4LLmPYM7BhT3E81jnF4K6/L/d6rz65iG1eAmrE/uLk72QzgxjSc+RkD 6d9GeOgYU8pNud2n1Xpv+wXUJ4wKUoW0Act5UK0c8JkQgopdZM70GPtaoKAUTqOE ONVeSvxionRIPR+lKlkbQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejgedgudehjeduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgfgsehtjeertder tddtnecuhfhrohhmpedftehrnhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnug gsrdguvgeqnecuggftrfgrthhtvghrnhephfdthfdvtdefhedukeetgefggffhjeeggeet fefggfevudegudevledvkefhvdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvgdpnhgspghrtghpthhtohep fedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprghkphhmsehlihhnuhigqdhfoh hunhgurghtihhonhdrohhrghdprhgtphhtthhopehjuhhlihgrnhesohhuthgvrhdqlhhi mhhithhsrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkh gvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id E35132220072; Tue, 28 Jan 2025 04:14:45 -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 Date: Tue, 28 Jan 2025 10:14:23 +0100 From: "Arnd Bergmann" To: "Julian Vetter" , "Andrew Morton" Cc: linux-kernel@vger.kernel.org Message-Id: In-Reply-To: <8f22066a-a2cc-4e6d-91aa-a2bdd0e53b79@outer-limits.org> References: <20250127100407.866238-1-julian@outer-limits.org> <1db6ef22-453e-4d31-a643-8e6f84a025e4@app.fastmail.com> <308d30b7-acdb-43ec-bb27-7912a5351bcc@app.fastmail.com> <8f22066a-a2cc-4e6d-91aa-a2bdd0e53b79@outer-limits.org> Subject: Re: [PATCH] Add io_sync stubs to generic IO memcpy/memset Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, Jan 28, 2025, at 09:32, Julian Vetter wrote: > On 1/27/25 16:48, Arnd Bergmann wrote: >> I suspect that the powerpc variant got this wrong for historic >> reasons, but that's hard to tell now. The ppc32 variant didn't >> have barriers at all originally, it was just memcpy/memset >> before it got combined with ppc64 into arch/powerpc. >> > > hmmm... ok. I'm not sure what do make of this. But maybe I can just send > a patch to the PowerPC mailinglist, without those "sync" calls and see > what they have to say. I just looked again and I see that the powerpc I/O memcpy/memset functions do use the same barriers as readl/writel -- sync before each one, twi/isync after read and sync after write, the only difference is the eieio in the middle, so you could start with a patch that removes the eieio. The question here is whether we want to allow or prevent combining and reordering accesses within the string operations, and my feeling is that allowing them makes more sense here, but there may be a powerpc specific reason we don't want that. I'm still unsure about having barriers before/after the string operations, I can very much see that debate go either way, but I also feel like this should be done consistently across all architectures. A possible answer may be that we declare these helpers to include the same barriers as readl_relaxed()/writel_relaxed(), i.e. ordering between I/O operations is enforced, but not the barriers for serializing against DMA and interrupts that is provided by the normal readl()/writel(). Most architectures assume that the relaxed variants don't need any barriers, so that is what asm-generic/io.h implements, but I think alpha and mips need barriers here and powerpc simply defines the relaxed accessors to be identical to the non-relaxed ones for simplicity. >>> The existing ones, especially __io_br unfortunately don't resolve to the >>> right define on these architectures. The __io_ar and __io_br resolve to >>> the right mb() on SuperH and PowerPC as well, but this would again have >>> implications on other architectures. >> >> The barriers in the sh functions seem arbitrary, and I would >> expect them to be wrong. >> > Ok, same for SuperH, I will send a patch to the mailinglist without the > 'mb()' before and after and see what they say. If they don't like it, I > will come back to this. I doubt there is anyone left who understands the history behind the exact implementation on sh, the only real options I see for it are to not touch it at all, or to remove the functions in favor of the generic ones. sh also has custom readsl/writesl functions, which are related, but I see that it is completely missing the corresponding readsw/writesw and readsb/writesb interfaces and it prevents the use of the generic implementations. Arnd