Received: by 10.223.185.116 with SMTP id b49csp8553780wrg; Fri, 2 Mar 2018 04:01:32 -0800 (PST) X-Google-Smtp-Source: AG47ELsxdf0OjiBB1+ls4ixrsh+Y2i8XCYHPck/AsX8Yo6tc528PK/xFxtf4/c6luHl3LxXYACZt X-Received: by 2002:a17:902:146:: with SMTP id 64-v6mr4856786plb.30.1519992092644; Fri, 02 Mar 2018 04:01:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519992092; cv=none; d=google.com; s=arc-20160816; b=BV/NsRHn2MXeQixGF8gb5pjJM8+x5J7kQO1rJvv4EPEFKvHxXSFZKh98rVRqbs+24J iPGjtWT+FUJHVIFvTxTULByP/smAzFOl4n7YkXunb0ALB23c7KV7ObyGrsYVwphMK5Oo zjKtnDhoitqihoF4LvJ4BuRGlqEeMt0+NbFa9DZ6E1/hmwuk25YbhX6l+v+MNKpKouUG otSPjTiDOxNx0dnew0hQEbUXKPZbHWknLCvfzb+17nta0OOsJfTIn3ep+yC6jgNXvBMh XFil4em8gQRz6dsV467THVsJDYqq132qg9oa5qNkpJQv/frlhwXVWVUXTm5CmuNMb6U/ aVQg== 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:arc-authentication-results; bh=wCckyqKTN375WtD/7f1dDIYRdtvdbZIKODNCvLaUgZM=; b=BYWeYnhd14ZJ0rxS/NH2069RfqT+b19+jyoqTYRuXOtcV4B12uylIrchOGuOMC7Ouy SW7DTVXkIHWkiZCbk6iyju3tgXAmrIIYmE+xYTkFubZWtFPXVgaRMFITFrqOYW1MrIDE oMHxpkiDmHohHjkuxvUfLRIdVXR+UhRGdF5tzmbBZThlYrvyuKbgCaxVXQIkf+QFcKR4 2QpmErP1mlJymLdkInh/9WuKn4vTtsHrquULXkd/Nt/IpkUceepQUrKtHJYscAqc2GjO yDIFELPppiauqMG/i3DiXxSoS+KRjieiI4nEwL5L+2K+679spq79wpQf/XZQDdrB2455 3lJQ== ARC-Authentication-Results: i=1; mx.google.com; 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 t3-v6si4666583ply.83.2018.03.02.04.01.17; Fri, 02 Mar 2018 04:01:32 -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; 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 S1422764AbeCBINV (ORCPT + 99 others); Fri, 2 Mar 2018 03:13:21 -0500 Received: from mga01.intel.com ([192.55.52.88]:29528 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422701AbeCBINT (ORCPT ); Fri, 2 Mar 2018 03:13:19 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2018 00:13:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,411,1515484800"; d="scan'208";a="31861717" Received: from vkoul-udesk7.iind.intel.com (HELO localhost) ([10.223.84.143]) by orsmga003.jf.intel.com with ESMTP; 02 Mar 2018 00:13:14 -0800 Date: Fri, 2 Mar 2018 13:47:06 +0530 From: Vinod Koul To: Sean Wang Cc: dan.j.williams@intel.com, robh+dt@kernel.org, mark.rutland@arm.com, dmaengine@vger.kernel.org, devicetree@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Randy Dunlap , Fengguang Wu , Julia Lawall Subject: Re: [PATCH v5 2/3] dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC Message-ID: <20180302081706.GL15443@localhost> References: <20180301082329.GD15443@localhost> <1519900021.8089.136.camel@mtkswgap22> <20180301125649.GH15443@localhost> <1519973271.8089.166.camel@mtkswgap22> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1519973271.8089.166.camel@mtkswgap22> 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, Mar 02, 2018 at 02:47:51PM +0800, Sean Wang wrote: > Hi, Vinod > > On Thu, 2018-03-01 at 18:26 +0530, Vinod Koul wrote: > > On Thu, Mar 01, 2018 at 06:27:01PM +0800, Sean Wang wrote: > > > On Thu, 2018-03-01 at 13:53 +0530, Vinod Koul wrote: > > > > On Sun, Feb 18, 2018 at 03:08:30AM +0800, sean.wang@mediatek.com wrote: > > > > > > > > > @@ -0,0 +1,1054 @@ > > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > // Copyright ... > > > > > > > > The copyright line needs to follow SPDX tag line > > > > > > > > > > okay, I will make it reorder and be something like that > > > > > > // SPDX-License-Identifier: GPL-2.0 > > > /* > > > * Copyright (c) 2017-2018 MediaTek Inc. > > > * Author: Sean Wang > > > * > > > * Driver for MediaTek High-Speed DMA Controller > > > * > > > */ > > > > It needs to be: > > > > // SPDX-License-Identifier: GPL-2.0 > > // Copyright (c) 2017-2018 MediaTek Inc. > > > > /* > > * whatever else you want > > */ > > > > The first two lines are in C99 style comment and need to have SPDX tag and > > Copyright info > > Sure, I can do it using C99 style comments at the first two lines. > > In addition, I'm really curious where we can find a reference to the > rule and if it 's a strict rule for all the drivers. > > Because I'm considering whether I should turn other driver into using > the same rule. Yes that seems to be the rule now https://lkml.org/lkml/2017/11/2/715 > > > > > +#define MTK_HSDMA_USEC_POLL 20 > > > > > +#define MTK_HSDMA_TIMEOUT_POLL 200000 > > > > > +#define MTK_HSDMA_DMA_BUSWIDTHS BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED) > > > > > > > > Undefined buswidth?? > > > > ?? > > Sorry for I didn't answer the question in the short time. > > After spending some time on a confirmation with design, it is > DMA_SLAVE_BUSWIDTH_4_BYTES and not be configurable. Then it should be DMA_SLAVE_BUSWIDTH_4_BYTES and not DMA_SLAVE_BUSWIDTH_UNDEFINED... > > > > shouldn't we check if next is in range, we can crash if we get bad value > > > > from hardware.. > > > > > > okay, there are checks for next with ddone bit check and null check in > > > the corresponding descriptor as the following. > > > > what if you get bad next value > > > > next is not hardware value. it's maintained by software which is always > between 0 to MTK_DMA_SIZE - 1, and definitely doesn't get a bad value. > > > > > > > > > + rxd = &pc->ring.rxd[next]; > > > > resulting in bad ref here > > rxd is also definitely a good ref not if next is out of range, say you read -1 or 200000? -- ~Vinod