Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp3015327ybh; Mon, 16 Mar 2020 14:08:35 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsFAEjYEyaeVGuyr6JQOCR4JvQYGvD4Aa+2OU2+CPD2h4DRVVzdzDu9kN2sn1VSl4juoUiD X-Received: by 2002:aca:3255:: with SMTP id y82mr1166644oiy.44.1584392915649; Mon, 16 Mar 2020 14:08:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584392915; cv=none; d=google.com; s=arc-20160816; b=Wsw6PqT9eU6iwAmByVRVHGojIZajRh87ItONdphJsieElQsYLNYKTsLmA6CGpxogxe CEj2hdO/S9T8c4yiY4T+Xql5nsS7OPWbZC4OrDq05HQxRev9/KRj413HDB470TFbR72Y PBo2FmVp/78VyFaNTg3QUbXyMUmA3uejXBge8ighhkPHT5CAVh+q9cGGV8my+gjBAHvS 5N1cmT/u7ayVnmzjjye+zRkGtLjl3mXO+9JciCjCchdeWwMtEAECsj6NIzyxzRLoI0vN GWPlFdAi3KCpOpwPU4LGddgik0IyLv2B1ysqMyVzmLheUbL8c4sg0hSkh3Y8i6MC7/2M cxyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=e4Js+GQN9i9BA17yb5cl9W991Ln3p6FSzvC77lFfomI=; b=Dz6Og4NEyV7TS/nCxfPA/+6RDiCiGu1IbzU90fhPGesV0kFtUI1cM2hyfMwcP5CcUi 3Gxqmlq/T4yfELOyIVbMBBoRcrXwSG4iu7G2/9hhu8QEeKMb6QX1gpXro7e8ojkfwBW4 r0pxOa22Xnjk4XINJs9h5fMRZN7NO7tc9HrjDazxlwhlm6lRZYAuwzG6i28cWjuj4u6h ne95EPAJHqCVdSm7Y+J42+oa9hVCEYwD0wghUVNP4srDZTcfXGaTvDFNtbbOELkejk+a X3E/r+OcT2NNvx31udlyghV4+TN1synEnPrEfofI188lm2VAAl3hBDfgaOhmZaUUy/hN CFVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=cyJ67de5; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 63si543416otm.66.2020.03.16.14.08.20; Mon, 16 Mar 2020 14:08:35 -0700 (PDT) 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=@rasmusvillemoes.dk header.s=google header.b=cyJ67de5; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732647AbgCPVHa (ORCPT + 99 others); Mon, 16 Mar 2020 17:07:30 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:45885 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732603AbgCPVHa (ORCPT ); Mon, 16 Mar 2020 17:07:30 -0400 Received: by mail-wr1-f65.google.com with SMTP id t2so12991899wrx.12 for ; Mon, 16 Mar 2020 14:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=e4Js+GQN9i9BA17yb5cl9W991Ln3p6FSzvC77lFfomI=; b=cyJ67de5xFz1SvZEhRxwZqWrPgxn0OKkczBOTpCiEBdsUAfjmlrHcgf1ubnpaLBXXl UD5u/Kt8WmQHfVqeeZwIwbQsWv1ZpvyKHQlfV5p2w6GtUBmXIAiDdvOIJkOaQKuo2pzk kI90cqzwoP6aTh1YX0/1Kd7iFxdR3H1peXxw8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=e4Js+GQN9i9BA17yb5cl9W991Ln3p6FSzvC77lFfomI=; b=DnelfBBqIFUmlL+gV5lxjImgRwZmWqw9Xyr5p0v+Tlk1wrnYyod5Kp+ljPAZe2cZwn ZDZzqeOe9fGyGZaPZJPcqpQubG36IaEfvF+w/58LcEorWN3itJIJJNBnB20z/zTAK4RL Xk6h3Nn6Kp1O6pQzK7YsQJYr3KSnCpss3v0/GKeITLQ0hHL28wrwLrGgYXPR0ZTfD5ym baSAnDp+xzpCinrlt3ZN5grl2IOWZdfE4YZHpl8GTRyFWUG7BuBbRKvp7cN/o95QDyoQ CfjaeUtPl7U7uScfa5FLhAelBPQKfr+4Jv5w/tw4MjICsIzOCb+/AQIUhoB/7rGa9ZaW WV5w== X-Gm-Message-State: ANhLgQ1wi5+HyQWbVSxCnv91J8SmpwVBYMgbrVLDtgK6XsRjzAMbIA+g yaZCf0JoHqF2cz8201vkI7LhSfR/7JbtfQ== X-Received: by 2002:adf:d1a9:: with SMTP id w9mr130439wrc.17.1584392847404; Mon, 16 Mar 2020 14:07:27 -0700 (PDT) Received: from [192.168.1.149] (ip-5-186-114-43.cgn.fibianet.dk. [5.186.114.43]) by smtp.gmail.com with ESMTPSA id q13sm1407210wrs.91.2020.03.16.14.07.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Mar 2020 14:07:26 -0700 (PDT) Subject: Re: [PATCH 6/6] soc: fsl: qe: fix sparse warnings for ucc_slow.c To: Li Yang , Timur Tabi , Zhao Qiang Cc: linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20200312222827.17409-1-leoyang.li@nxp.com> <20200312222827.17409-7-leoyang.li@nxp.com> From: Rasmus Villemoes Message-ID: Date: Mon, 16 Mar 2020 22:07:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200312222827.17409-7-leoyang.li@nxp.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/03/2020 23.28, Li Yang wrote: > Fixes the following sparse warnings: > [snip] > > Also removed the unneccessary clearing for kzalloc'ed structure. Please don't mix that in the same patch, do it in a preparatory patch. That makes reviewing much easier. > > /* Get PRAM base */ > uccs->us_pram_offset = > @@ -231,24 +224,24 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc > /* clear bd buffer */ > qe_iowrite32be(0, &bd->buf); > /* set bd status and length */ > - qe_iowrite32be(0, (u32 *)bd); > + qe_iowrite32be(0, (u32 __iomem *)bd); It's cleaner to do two qe_iowrite16be to &bd->status and &bd->length, that avoids the casting altogether. > bd++; > } > /* for last BD set Wrap bit */ > qe_iowrite32be(0, &bd->buf); > - qe_iowrite32be(cpu_to_be32(T_W), (u32 *)bd); > + qe_iowrite32be(T_W, (u32 __iomem *)bd); Yeah, and this is why. Who can actually keep track of where that bit ends up being set with that casting going on. Please use qe_iowrite16be() with an appropriately modified constant to the appropriate field instead of these games. And if the hardware doesn't support 16 bit writes, the definition of struct qe_bd is wrong and should have a single __be32 status_length field, with appropriate accessors defined. > /* Init Rx bds */ > bd = uccs->rx_bd = qe_muram_addr(uccs->rx_base_offset); > for (i = 0; i < us_info->rx_bd_ring_len - 1; i++) { > /* set bd status and length */ > - qe_iowrite32be(0, (u32 *)bd); > + qe_iowrite32be(0, (u32 __iomem *)bd); Same. > /* clear bd buffer */ > qe_iowrite32be(0, &bd->buf); > bd++; > } > /* for last BD set Wrap bit */ > - qe_iowrite32be(cpu_to_be32(R_W), (u32 *)bd); > + qe_iowrite32be(R_W, (u32 __iomem *)bd); Same. > qe_iowrite32be(0, &bd->buf); > > /* Set GUMR (For more details see the hardware spec.). */ > @@ -273,8 +266,8 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc > qe_iowrite32be(gumr, &us_regs->gumr_h); > > /* gumr_l */ > - gumr = us_info->tdcr | us_info->rdcr | us_info->tenc | us_info->renc | > - us_info->diag | us_info->mode; > + gumr = (u32)us_info->tdcr | (u32)us_info->rdcr | (u32)us_info->tenc | > + (u32)us_info->renc | (u32)us_info->diag | (u32)us_info->mode; Are the tdcr, rdcr, tenc, renc fields actually set anywhere (the same for the diag and mode, but word-grepping for those give way too many false positives)? They seem to be a somewhat pointless split out of the bitfields of gumr_l, and not populated anywhere?. That's not directly related to this patch, of course, but getting rid of them first (if they are indeed completely unused) might make the sparse cleanup a little simpler. Rasmus