Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp36476783rwd; Tue, 11 Jul 2023 01:15:06 -0700 (PDT) X-Google-Smtp-Source: APBJJlG6QtiqZgWEHTp6oJ8HYgBSAHHpOjQx0rDhceY9FEDQg7EIfax43V9YWMCTWEJpmp/tHWq8 X-Received: by 2002:a05:6512:3c83:b0:4fa:21d4:b3ca with SMTP id h3-20020a0565123c8300b004fa21d4b3camr14677574lfv.2.1689063306701; Tue, 11 Jul 2023 01:15:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689063306; cv=none; d=google.com; s=arc-20160816; b=BRgw6P+8N3joSsuYR+y+cagt5RT35pi7PwacSihduf0QgeAkZ896vEQhya7g1CjCxi C2CgqxbrCZ9d3MiivMyvtPwTvtf8onsFOC9j5MVPl3qzMD4DavXzJAu+flgSscKj7k/c pXsxcxJKLoaUJE2cSQ0ufI6dW11tPH8Lj2Kb+oFHYoH8pnJu8SnL80HWaZ5+dsWX/JP2 aMP2TuVV8j3fG4aubRMzVzQZoueXrXbYEhr1hNc/W+W17TZI1SOSHVZqMBW+tiyeTuvS Wjm9cYJ80YUnlIoNC/kJzl2FfyipUXOiUJVFlbhgBpVxLzLysdjcx0FWHra5/tBxU1w1 UDpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:references:organization:in-reply-to:subject:cc:to :from:dkim-signature; bh=AFvaINlfRMz7kk/nBxdbXpJUZkl8Iuzlg1vf/xS73Xo=; fh=sOmmyHwlD1CzPlb9UWFuNR46R3vtcBKsoiz880+0I6k=; b=st6xAxJ96PFTaDRAPi9YDhN3M+vHuWjZkxbpyazjv5a5/ScTH2ytqgDNAaMSnLmeo9 Su8kPks1l6+nZ+POKtyAwyKE+C0xVf7nzMHi8LAqPaEOgIhhN6ndvCbAzI7e5CuoClos 075iRegSShKiKReiyEQuU1jYnmL3xURp7KBQ6fcIEywT067BnVYiNESQoQujrUPRJi+q K7Ba+7sLzWtPTv29kVHMitgQCHaLXfI24/YvUf5CYsPgsun42yoVL4LAV6XI+hREsxwg uTZFOV65k0wkbCCx8eVeYf2qepwLSDDUrb31rVi4uq2fsVbUjqP0mLpxeS9eGLPj9E4q evsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=XenKIbs3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g7-20020aa7c587000000b0051df3ae38b4si1457400edq.573.2023.07.11.01.14.42; Tue, 11 Jul 2023 01:15:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=XenKIbs3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231679AbjGKIDV (ORCPT + 99 others); Tue, 11 Jul 2023 04:03:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229831AbjGKIDS (ORCPT ); Tue, 11 Jul 2023 04:03:18 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 623E992 for ; Tue, 11 Jul 2023 01:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689062597; x=1720598597; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=eyGG6dzB9CZXuAsyxkAbXw//cArH8N9tfew36H3vcQI=; b=XenKIbs3c8CpPK7EhUozwdZh/K1gajc2o0sV84iBKlQ2hmcmG44bKCyq Zm+3CbKNGv2fx7forYAUv/e1eNLU3j5VXUsowZmf/ZTveC3tKn29aFKCZ 14rl3OdbBcSAUQLPClLhrL+2TjYCi+VTrANkRusUYYxdSpkeMA7qC8+kd a0jA3oEUogT5D85x2nGmUw8CJBNeshLlNa99DMVcG/DEEhuT73axEPO4H s/7zgs32CNPvUPfdj23vmtMEirdwq+jWOKxpoV+5TGOrq76BvraG34k88 KdbxmYPHM3D/tVqU3v8klfmyAVttX9Mobvmh3IdOrcSTkji3rbTb4ithF Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10767"; a="430643154" X-IronPort-AV: E=Sophos;i="6.01,196,1684825200"; d="scan'208";a="430643154" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jul 2023 01:03:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10767"; a="715108432" X-IronPort-AV: E=Sophos;i="6.01,196,1684825200"; d="scan'208";a="715108432" Received: from sneaga-mobl3.ger.corp.intel.com (HELO localhost) ([10.252.52.179]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jul 2023 01:03:13 -0700 From: Jani Nikula To: suijingfeng , David Airlie , Daniel Vetter , Thomas Zimmermann , Li Yi Cc: loongson-kernel@lists.loongnix.cn, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, kernel test robot Subject: Re: [PATCH] drm/loongson: Fix two warnings because of passing wrong type In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20230710100931.255234-1-suijingfeng@loongson.cn> <87h6qcjc46.fsf@intel.com> Date: Tue, 11 Jul 2023 11:03:11 +0300 Message-ID: <87edlej2o0.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 10 Jul 2023, suijingfeng wrote: > Hi, > > On 2023/7/10 18:26, Jani Nikula wrote: >> On Mon, 10 Jul 2023, Sui Jingfeng wrote: >>> When accessing I/O memory, we should pass '__iomem *' type instead of >>> 'void *' simply, otherwise sparse tests will complain. After applied >>> this patch, the following two sparse warnings got fixed. >> Usually the commit message should explain why it's okay to cast away the >> warning. >> >> Because realistically this doesn't "fix" the warning, this merely hides >> it. > > > My understanding is that a point itself is just a variable where store a= =20 > address, > > if this address originally point to I/O memory, > > then, we can other cast it to u64 type, then cast it back to '__iomem *'= =20 > again. > > as long as the type's=C2=A0 bit-width is width enough to store this addre= ss,=20 > we won't lost the information. > > > 'void *' or 'u64' is just a intermediate represent of the address. > > we can other cast it to u64 type, then cast it back to 'void __iomem *'=20 > or 'void *' again. > > > Why it's okay ? My answer is that > > As long as a address is really point to the I/O memory, cast it to 'void= =20 > __iomem *' is OK. > > As long as a address is really point to the system memory, cast it to=20 > 'void *' is OK. The point of __iomem is to have sparse help you in tracking that, so you don't accidentally mix up the two. BR, Jani. > > >> BR, >> Jani. >> >>> 1) drivers/gpu/drm/loongson/lsdc_benchmark.c:27:35: >>> sparse: expected void volatile [noderef] __iomem * >>> sparse: got void *kptr >>> >>> 2) drivers/gpu/drm/loongson/lsdc_benchmark.c:42:51: >>> sparse: expected void const volatile [noderef] __iomem * >>> sparse: got void *kptr >>> >>> Reported-by: kernel test robot >>> Closes: https://lore.kernel.org/oe-kbuild-all/202307100243.v3hv6aes-lkp= @intel.com/ >>> Signed-off-by: Sui Jingfeng >>> --- >>> drivers/gpu/drm/loongson/lsdc_benchmark.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/loongson/lsdc_benchmark.c b/drivers/gpu/dr= m/loongson/lsdc_benchmark.c >>> index b088646a2ff9..36e352820bdb 100644 >>> --- a/drivers/gpu/drm/loongson/lsdc_benchmark.c >>> +++ b/drivers/gpu/drm/loongson/lsdc_benchmark.c >>> @@ -24,7 +24,7 @@ static void lsdc_copy_gtt_to_vram_cpu(struct lsdc_bo = *src_bo, >>> lsdc_bo_kmap(dst_bo); >>>=20=20=20 >>> while (n--) >>> - memcpy_toio(dst_bo->kptr, src_bo->kptr, size); >>> + memcpy_toio((void __iomem *)dst_bo->kptr, src_bo->kptr, size); >>>=20=20=20 >>> lsdc_bo_kunmap(src_bo); >>> lsdc_bo_kunmap(dst_bo); >>> @@ -39,7 +39,7 @@ static void lsdc_copy_vram_to_gtt_cpu(struct lsdc_bo = *src_bo, >>> lsdc_bo_kmap(dst_bo); >>>=20=20=20 >>> while (n--) >>> - memcpy_fromio(dst_bo->kptr, src_bo->kptr, size); >>> + memcpy_fromio(dst_bo->kptr, (void __iomem *)src_bo->kptr, size); >>>=20=20=20 >>> lsdc_bo_kunmap(src_bo); >>> lsdc_bo_kunmap(dst_bo); > --=20 Jani Nikula, Intel Open Source Graphics Center