From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.25]) (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 678B13FC7 for ; Mon, 27 Jan 2025 14:11:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=85.215.255.25 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737987096; cv=pass; b=azHlmWeUqe8lhK5US0uB3DuMePNc//0TFKh7mA2owjZlv1qCwI2adKG8WO+Orh0rdLgozKCLYE7GIMHJd1/zjD6drLQ7ox+KcjfU7ZaFV992EIg+gG1ryPSetNJPJAYLVYDZU+WAyOpp7kK4wh28uTV5w21flAyGwogVjhjHIU8= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737987096; c=relaxed/simple; bh=4e9WBLR5WjhLhnp0Yv1XvboPXgI09phG4vrDvYHIVTo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L0nRkL0DDsCasQE/Nypa7nDVmKxXbuvLX6BtoCX5vmdHhII9QOOl6wV1Z9Ji5xvJr6CfR3MyQ9F5AMpzape70kFpO9PIah/5OVv9HNwBD8q/vr75S3nOx+w/lkj+bipvoMdPZ09Hk860EzVbEtOAveQtWjU2oK9u5D5Np9DajuM= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=outer-limits.org; spf=none smtp.mailfrom=outer-limits.org; dkim=pass (2048-bit key) header.d=outer-limits.org header.i=@outer-limits.org header.b=frSxCHgh; dkim=permerror (0-bit key) header.d=outer-limits.org header.i=@outer-limits.org header.b=YdhTW3wu; arc=pass smtp.client-ip=85.215.255.25 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=outer-limits.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=outer-limits.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=outer-limits.org header.i=@outer-limits.org header.b="frSxCHgh"; dkim=permerror (0-bit key) header.d=outer-limits.org header.i=@outer-limits.org header.b="YdhTW3wu" ARC-Seal: i=1; a=rsa-sha256; t=1737987086; cv=none; d=strato.com; s=strato-dkim-0002; b=PVM7vsXkKk2ymR7CJuS5eUxi0/C8vAIPipOIV4kst4TC+8Jtm2SBhTNZJZfXY8y1id OaPcwjMz87+7Imd6Szj9IHgQDDA3STjv/3nUCxqBx3DSXSXXv/UB4do6S83FoCzMla0R T0Jl9grGg1zLJnn3oOEw4jGeJjnnKRzA7B1LpUjqM21FlXc0wAp8l7pIqom349DyfepP rUI+tcVaBAyK1Q7WaKgLoFCxGSf1XHM7myYkA8Qx86LxqkJ//vbdo6EoaLxVggD+9Um5 JQbUEXhNH5pHhQD/5ewZExFaxDVHG1Qs6t6FRkxvxt3KjFM1Ew1Hw5Wa4HFVsO2xuRjT 4aKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1737987086; s=strato-dkim-0002; d=strato.com; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=Ua7lvuI8kI1W8XhSMM6w9rfC5/4qPWlkdRyrv+iu13o=; b=XjEYMingxMcKtWWG74Xpzg9e78815PfLOiwX88uzMspMNCopI6jfXi1TPtj5T9U4vi ROYuyAIVN1jJDsHXnOw6zkHCokaGr8evPjmLYU3rCtlwBWFDfKeqhC2aHkj42FAxjdZG 5WLwtZ2IsgaACtpcV9Wm6bvHLGuayDw3z0OOd9uQXH7/N2xbMysOickC6pIx8Civag5H rC3pwUKClHguvf/2UIITlO1dZlpeIuYAtc8FnMDxk66gtpZ9wnPawUh/JSFkRmJ852CM R9wTAIhQascRGs1A5gCQmvXz+FiPBFJTRzWINA5XE5lunvqR9qcw0dYvq67jtBi2RqXI HlhQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1737987086; s=strato-dkim-0002; d=outer-limits.org; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=Ua7lvuI8kI1W8XhSMM6w9rfC5/4qPWlkdRyrv+iu13o=; b=frSxCHghmP+4XEj4Tp/mW9NQSep/hSXpfdmgIu+YjeXRATQBKpffopAKExQDFJQLvY zlsQlkYfc/1B8E/q0L5BKApmQnLWtLI78EGCpdG47Hv+Nud58qkg7N4S5ogk2M0Vt+P6 IZIgA1zRO2XoNButvN1E060hrjq9MQCy9R5FBci/xvWGXW7t2I47zQzatW5PPwi31Mm4 djnCinHdCNaUnUTNRPWchXxNfTlJhlWN6fGKG+EavoovTqVz6QyerdaGT9Th6FeTrD0Q Jyi20D96I9wX2ZGa7rEo1vFp/BmDUYJfn8LkgOC1Fczf+8q5Iv1uTu6n5KDRoT/h/KGT 7nqw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1737987086; s=strato-dkim-0003; d=outer-limits.org; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=Ua7lvuI8kI1W8XhSMM6w9rfC5/4qPWlkdRyrv+iu13o=; b=YdhTW3wuweHFIJlImcH0LAG45xsVq/URN+b3aGoUX1r/OER9mlp0J2H9OXCqrXFeEE 083HjjzYKJMXeNQ6cwCw== X-RZG-AUTH: ":JnkIfEGmW/AMJS6HttH4FbRVwc4dHlPLCp4e/IoHo8zEMMHAgwTfqBEHcVJSv9P5mRTGd2ImeA==" Received: from [192.168.37.162] by smtp.strato.de (RZmta 51.2.17 AUTH) with ESMTPSA id J1a25110REBPquu (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 27 Jan 2025 15:11:25 +0100 (CET) Message-ID: Date: Mon, 27 Jan 2025 15:11:25 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Add io_sync stubs to generic IO memcpy/memset To: Arnd Bergmann , Andrew Morton Cc: linux-kernel@vger.kernel.org References: <20250127100407.866238-1-julian@outer-limits.org> <1db6ef22-453e-4d31-a643-8e6f84a025e4@app.fastmail.com> Content-Language: en-US From: Julian Vetter In-Reply-To: <1db6ef22-453e-4d31-a643-8e6f84a025e4@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/27/25 11:27, Arnd Bergmann wrote: > On Mon, Jan 27, 2025, at 11:04, Julian Vetter wrote: >> The recently added IO memcpy and memset functions lack support for >> barriers or other sync functions before and/or after the transaction. To >> convert more architectures to use the generic IO memcpy and memset >> functions, add empty __pre_io_sync and __post_io_sync defines that can >> be overwritten by individual architectures if needed. >> >> Signed-off-by: Julian Vetter >> --- >> lib/iomem_copy.c | 20 ++++++++++++++++++++ >> 1 file changed, 20 insertions(+) >> >> diff --git a/lib/iomem_copy.c b/lib/iomem_copy.c >> index dec7eaea60e0..2e81182dd4d3 100644 >> --- a/lib/iomem_copy.c >> +++ b/lib/iomem_copy.c >> @@ -9,6 +9,14 @@ >> #include >> #include >> >> +#ifndef __pre_io_sync >> +#define __pre_io_sync >> +#endif >> + >> +#ifndef __post_io_sync >> +#define __post_io_sync >> +#endif > > I think we should define what these barriers are supposed to > do exactly, and how they relate to the __io_br/__io_ar/__io_bw/__io_aw > ones include/asm-generic/io.h. > Thank you for your quick reply. You're right, I was just going with the naming used in the powerpc arch which has an io_sync define. I'm now wondering if we can't simply use the read{l,q}/write{l,q} functions (instead of the __raw_xxx version), there are already calls to __io_br before and__io_ar after each read (and write). But this might have performance implications on some architectures, depending what it resolves to. Otherwise I propose renaming the __pre_io_sync and __post_io_sync into a single __io_mbr which is called before and after each loop. Looking at PowerPC and SuperH, both of them could be consolidated into the generic IO memcpy code when adding this. What do you think? 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. Thank you! Julian > Depending on what the barriers are meant to do, we probably > want to either use the existing ones directly or use a similar > naming scheme. > > Arnd