Received: by 10.223.176.46 with SMTP id f43csp17373wra; Fri, 19 Jan 2018 13:05:28 -0800 (PST) X-Google-Smtp-Source: ACJfBovpnmP1t8SR78D1j7e2yIY/3FgieqHQDTzMjbxKcNb1xTg/XUp8Sm7D/i/9oEvSmxPtvag0 X-Received: by 10.99.97.202 with SMTP id v193mr6701162pgb.84.1516395928075; Fri, 19 Jan 2018 13:05:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516395928; cv=none; d=google.com; s=arc-20160816; b=cD+bHvCvET+PbKU6Y9dm6tSaO2x3oah03etlXLVFlB7ilXRsfKDwEiRkIY82bth1qr t1TndC/3vPJOP8QaUbFR2+nYHYkGvCFirUu0v/DG2Jwz5sicuSRMFBv6BlIlmWbqpD/3 OUaOSdh8dFYRFZeGAAcdKtk/gtwpO+pgCE5ykTqAaqpDqfH3O4pkyMJrKP8MScx1l1sk qbLYerjO+TSKHBEfrdxhkpK7Lzi9nb03u7KFo6+LQLnNYOi5e90zM7KoPXalTo4D8451 o3jkdztX2BBECdo3a36qZuzb4hnux1Jors9zVGUw+krjJvC/XSiT20bVajQdfM+/Gqxp J7EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=INwa/gI9P7MjbwnjpA2n8s7ryZlaNu+qiXtjJVh1/X4=; b=BHDjz5Npgvc/rPeveOuER+LurznErVRYLk3o9ARhHkWJR23N49s4s+fbthpbWQZV+i okB5N7ROwYJgfW776LexniPDQ2i2RnOdJ6u6Ud0MUlWvwbzLpH7fR5z1irXG18uvr+MS m38/K0fbNur3YtfxCLsN2KpUN4O1jb1vL7dX9mlq/Y0K+kaDNBLg8CcTK5CJQNfdhcLX DRPGm5tOBxgkvfdzopyQr4Sozf50oF2BV7h4y9QizB/94QVS58U5gdzoB4Dqr6H3q1z+ b1cGfgUnaujgjXvyjtt3Dwcz1yFc5j2oF/nTGuqJ9D7Z2mefi5cd9/C1PeueW18gfBhA yrHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DspDVFqu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a96-v6si1096214pli.745.2018.01.19.13.05.13; Fri, 19 Jan 2018 13:05:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DspDVFqu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756504AbeASVDM (ORCPT + 99 others); Fri, 19 Jan 2018 16:03:12 -0500 Received: from mail-lf0-f65.google.com ([209.85.215.65]:45398 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756460AbeASVDF (ORCPT ); Fri, 19 Jan 2018 16:03:05 -0500 Received: by mail-lf0-f65.google.com with SMTP id x196so3611048lfd.12 for ; Fri, 19 Jan 2018 13:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=INwa/gI9P7MjbwnjpA2n8s7ryZlaNu+qiXtjJVh1/X4=; b=DspDVFqu1GBW3TVVe2kREJqvvybtAb1Yr6o3v6r9IZKMoD2XiwP+V6fiyDqn8+TJh5 tnxCPLaZYfCs5/hQTB5rbdL1s+rIpXeeHm02vWZ3UKJDvwrYjuu7ygY/l967du2vt0dv sTI3XnBo80XYySKTBkI8Ilo6aJdXGabDPuW/5iAP/IF/UPcrAjvVSd/pTven5buPuYvp Rg1UjENGDFbJf8nuIhGVpuE40uZ2CpSGKlprrKHJ+s8v/JyrgxJJu1WW7c9rExsSEH6p m/IyBRnBjLvyi1kfwhQ5/wzS/rOp+BwDfOvX2HnJNzO5g2u3BzACuX41KmUFiJQPuC5v qilg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=INwa/gI9P7MjbwnjpA2n8s7ryZlaNu+qiXtjJVh1/X4=; b=XR1j3b2b8l/yMeT7DbZPIhUdwQzVj1ZEtJgXFRFhAP56dyTgDJs+xssOg2vx2xqBJD BCQpfCQ+JKXpwyRh5jQFRCu0/TE1bK7KyiiLdfUunO6EfvrsRUltTakA5wLL8jv2MFlg 1iOk/FfdZoMub94Ujkb+mlybriQhz5u0mGaaiOUqxX/SAOGP9nYRN0Ev/L7Z2EW+RfSj ZzFnnrdZqVf4MZKbPGdEi0pCMHGj8STkeFzDAGTVOQ8MJW3O6jIddblW8OWO9n7iBCgA AQij+gZeclbiZh8AAvzPl025HhnRr8O3OAey1xZg00QDFphxZtAJHBIqGkOLl2woaoiB Qa2Q== X-Gm-Message-State: AKwxytfh81n2Mgxcd+kdn4+jhViuNovomM5U9/gF3rHARYzJtzLb4Dmm dtLTDwZNaUj9DskAs1a+v+Y= X-Received: by 10.46.118.18 with SMTP id r18mr12498233ljc.11.1516395783893; Fri, 19 Jan 2018 13:03:03 -0800 (PST) Received: from mobilestation ([95.79.164.146]) by smtp.gmail.com with ESMTPSA id q4sm1882656lje.42.2018.01.19.13.03.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 13:03:03 -0800 (PST) Date: Sat, 20 Jan 2018 00:03:10 +0300 From: Serge Semin To: Arnd Bergmann Cc: jdmason@kudzu.us, Dave Jiang , Allen.Hubbe@gmail.com, "Hook, Gary" , Sergey.Semin@t-platforms.ru, linux-ntb@googlegroups.com, Linux Kernel Mailing List Subject: Re: [PATCH] NTB: ntb_perf: fix cast to restricted __le32 Message-ID: <20180119210310.GA2284@mobilestation> References: <20180119173044.8013-1-fancer.lancer@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 19, 2018 at 09:42:17PM +0100, Arnd Bergmann wrote: > On Fri, Jan 19, 2018 at 6:30 PM, Serge Semin wrote: > > Sparse is whining about the u32 and __le32 mixed usage in the > > driver. > > > > drivers/ntb/test/ntb_perf.c:288:21: warning: cast to restricted __le32 > > drivers/ntb/test/ntb_perf.c:295:37: warning: incorrect type in argument 4 (different base types) > > drivers/ntb/test/ntb_perf.c:295:37: expected unsigned int [unsigned] [usertype] val > > drivers/ntb/test/ntb_perf.c:295:37: got restricted __le32 [usertype] > > ... > > > > The NTB API can't be changed so ntb_spad_*() methods > > would return either pure __le32 or __be32, since the scratchpad > > data can have arbitrary endianness in general. In this case we > > need to forcibly cast all the u32 to be __le32 and vise-versa > > where it's supposed to be in accordance with the driver logic. > > > > There's got to be a better way to do this than sprinkling lots of __force > typecasts throughout the code. > > It looks like all those casts are about > ntb_peer_spad_read()/ntb_peer_msg_write() calls, so why not change > those function prototypes to work on __le32 types? > > There should also be some form of documentation regarding why you > need to swap the data twice, since all the ntb drivers later end up > doing another cpu_to_le32() on the little-endian data. > > Arnd Actually the provided patch is the best solution I could come up with. The thing is, that the methods can't be changed. Those functions are the part of the NTB API methods used by many drivers. So basically they are like pci_{read,write}_config_{byte,word,dword}() methods. We can't change their prototypes only because it's suit some driver. The methods give an access to the NTB device dummy u32-sized registers, nothing else. So endianness is the transmitted data settings in this case. NTB is the technology to interconnect some two systems with possibly different endianness (unlike PCI, which interconnect CPU with LE devices). In this case I'd need to set some agreement up between two systems about the endianness of the exchanged data like host and network types in Linux networking. I've chosen the network data to be little-endian, that's why I needed first to convert them from CPU to le32, then on remote side convert them back from le32 to CPU. If you have any better suggestion how the warning can be fixed, I'd be glad to stick to it. -Sergey