Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1082726pxm; Wed, 23 Feb 2022 17:40:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJwJzRTYX/lieQMvSiWkLKNBNefu8LdEtryFhUw8Vw0/Ba/d3oSDMAc+lT698Wyw/P+QIwu5 X-Received: by 2002:a05:6a00:22ce:b0:4f0:ed5c:7166 with SMTP id f14-20020a056a0022ce00b004f0ed5c7166mr437744pfj.79.1645666839240; Wed, 23 Feb 2022 17:40:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645666839; cv=none; d=google.com; s=arc-20160816; b=qLik17sP53ZO4ibmc0bNTOAPZ365XD/mud1paokkkGuTElCSnOxfUcxCztJM/gBUyB 1Hk4k5MJUVHLya4eVkc9JCaAXmw/8y0P3ccQ8m72VwYtaGykQrvoK7yk4ELfjyZfLcKj aYUl0sx6OsnkeHhh2J7VntQ/ENrBbhgyXk1r94KDeMdVwE8+piXcvDOjaSYMcHPCclMy Xy0kBQwIKBKEtKIrtSbc46rZEIOWLJ3GhkaXN6ciCJ+k2UyiBOJ69DbyU3dlKwVzwzZh SKx44eEFoL+XOuYec0TlFW/gXwKYitb8W2hW8+VufSjUR7eAppCEDKKSvDI9oRIx/OZn LLuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=JaECZa5nGpPMXgtEOfjmXjW1FnPt4t63YP/6SkFVOjg=; b=o7Su9JU7feY0UOHrY9C7+BYaGtTvsk2VBEr4VRBSPytv7MZSGkbnwPnYu3FDlXRBa9 yvg9CbjVlHvqsaIOgSdHqD69Tmq0+SsWHp+Vy4aYcNPApO+QlouzddeOZHdRhimq1BFv jSnmODZyn9mVZC9f0pNP/KBQdzBJY9eoStqFzhCGbBJ2e1SEoAKlBqyjrLoaJJ04Ifc8 pwQFEhQWXTuREeEZJeeIJl3aQAPuR5iEJQcTItRG7T3gUw53j6hrjo2waVce3ewP/ewK 9ZwAVATGKbpXecO6Gii9t3t7w28GWlaCaDrCt/DrC6cw9T+P71SaZJsm7vubpnkeDFaZ TQOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rmrjmHtG; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id bd5si1274085pgb.467.2022.02.23.17.40.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Feb 2022 17:40:39 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rmrjmHtG; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 757C61402E; Wed, 23 Feb 2022 17:16:37 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244001AbiBWSoY (ORCPT + 99 others); Wed, 23 Feb 2022 13:44:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235517AbiBWSoX (ORCPT ); Wed, 23 Feb 2022 13:44:23 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D48064DF62; Wed, 23 Feb 2022 10:43:54 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 661B6615F8; Wed, 23 Feb 2022 18:43:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 247C7C340E7; Wed, 23 Feb 2022 18:43:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645641833; bh=XfBLjj4j3UjNuCB/GziGUYF4ayFzbyJpJY2IrYM3XUU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rmrjmHtGi/1eLxifAooKa7LLAMo24uRQeYXZJ/mzAaxxaKc++A2OAi+Jp6i9WAGMi hJTYhkUFcvE2ciF4k0zmK8FEhlFUJu+4acynMdYvZ4Yr3yJR5tsUQZhJ+XxEFa6Z7W lwXyAGLc4AcMGc3J4bK9XLFsYn+5Jrsbe5B7B/lMG8lDV4vXn/lCrCGmOaDcm51tAx GPuaxtQZVOBqg9+m/zXUJ2Ab1/+ECWKrxHtWpUE2Pu1/xkVIaTrq4fdTx15RBqOXXb wE4dw+3JRK3HrsoG7T0mZdrPpildS7DbpeJvFrtEEx88gDSN2ue685s1+qA6gUmxbY y7lGzNN4ReiQg== Date: Wed, 23 Feb 2022 11:43:48 -0700 From: Nathan Chancellor To: Akhil R Cc: "devicetree@vger.kernel.org" , "dmaengine@vger.kernel.org" , Jonathan Hunter , Krishna Yarlagadda , Laxman Dewangan , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" , "p.zabel@pengutronix.de" , Rajesh Gumasta , "robh+dt@kernel.org" , "thierry.reding@gmail.com" , "vkoul@kernel.org" , Pavan Kunapuli Subject: Re: [PATCH v20 2/2] dmaengine: tegra: Add tegra gpcdma driver Message-ID: References: <20220221153934.5226-1-akhilrajeev@nvidia.com> <20220221153934.5226-3-akhilrajeev@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Wed, Feb 23, 2022 at 03:49:09AM +0000, Akhil R wrote: > > Hi Akhil, > > > > On Mon, Feb 21, 2022 at 09:09:34PM +0530, Akhil R wrote: > > > Adding GPC DMA controller driver for Tegra. The driver supports dma > > > transfers between memory to memory, IO peripheral to memory and memory > > > to IO peripheral. > > > > > > Co-developed-by: Pavan Kunapuli > > > Signed-off-by: Pavan Kunapuli > > > Co-developed-by: Rajesh Gumasta > > > Signed-off-by: Rajesh Gumasta > > > Signed-off-by: Akhil R > > > Reviewed-by: Jon Hunter > > > Reviewed-by: Dmitry Osipenko > > > --- > > > drivers/dma/Kconfig | 11 + > > > drivers/dma/Makefile | 1 + > > > drivers/dma/tegra186-gpc-dma.c | 1507 > > > ++++++++++++++++++++++++++++++++ > > > 3 files changed, 1519 insertions(+) > > > create mode 100644 drivers/dma/tegra186-gpc-dma.c > > > > > > > > > +static const struct __maybe_unused dev_pm_ops tegra_dma_dev_pm_ops = > > > +{ > > > > The __maybe_unused cannot split the type ("struct dev_pm_ops") otherwise it > > causes a clang warning: > > > > https://lore.kernel.org/r/202202221207.lQ53BwKp-lkp@intel.com/ > > > > static const struct dev_pm_ops tegra_dma_dev_pm_ops __maybe_unused = { > > > > would look a litle better I think. However, is this attribute even needed? The > > variable is unconditionally used below, so there should be no warning about it > > being unused? > > > > Cheers, > > Nathan > > > > > + SET_SYSTEM_SLEEP_PM_OPS(tegra_dma_pm_suspend, > > > +tegra_dma_pm_resume) }; > > > + > > > +static struct platform_driver tegra_dma_driver = { > > > + .driver = { > > > + .name = "tegra-gpcdma", > > > + .pm = &tegra_dma_dev_pm_ops, > > > + .of_match_table = tegra_dma_of_match, > > > + }, > > > + .probe = tegra_dma_probe, > > > + .remove = tegra_dma_remove, > > > +}; > > > + > > > +module_platform_driver(tegra_dma_driver); > > > + > > > +MODULE_DESCRIPTION("NVIDIA Tegra GPC DMA Controller driver"); > > > +MODULE_AUTHOR("Pavan Kunapuli "); > > > +MODULE_AUTHOR("Rajesh Gumasta "); > > > +MODULE_LICENSE("GPL"); > > > -- > > > 2.17.1 > > > > > > > > Hi Nathan, > > Thanks. Will update the same. > > I am getting notification for the below warning also. > > >> drivers/dma/tegra186-gpc-dma.c:898:53: warning: shift count >= width of type [-Wshift-count-overflow] > FIELD_PREP(TEGRA_GPCDMA_HIGH_ADDR_DST_PTR, (dest >> 32)); > https://lore.kernel.org/all/202202230559.bLOEMEUh-lkp@intel.com/ > > I suppose, this is because it is compiled against a different ARCH other than arm64. > For arm64, the dma_addr_t is 64 bytes, and this warning does not occur. > Could this be ignored for now? If not, could you suggest a fix, if possible? I am not really familiar with the DMA API and dma_addr_t so I am not sure about a proper fix. You could cast dest to u64 to guarantee it is a type that can be shifted by 32 but that might not be right for CONFIG_PHYS_ADDR_T_64BIT=n. If the driver is not expected to run without CONFIG_PHYS_ADDR_T_64BIT, then this is probably fine. You could mark this driver 'depends on PHYS_ADDR_T_64BIT' if it cannot run with CONFIG_ARCH_TEGRA=y + CONFIG_PHYS_ADDR_T_64BIT=n but I do not see any other drivers that do that, which might mean that is not a proper fix. Please do not ignore the warning, as it will show up with ARCH=arm allmodconfig, which has -Werror enabled. Cheers, Nathan