Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp918156ybm; Wed, 22 May 2019 13:56:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqzq7IMg4P551K2BDJJxgqsNX27k2jHtMdCQPrN/FXpsYhU9ypWXj+Bb6vBoKYSTFzOXA4rU X-Received: by 2002:a63:e358:: with SMTP id o24mr8291087pgj.78.1558558567828; Wed, 22 May 2019 13:56:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558558567; cv=none; d=google.com; s=arc-20160816; b=GE1xH9wcKY/hDDl8aX2s+oVke6Ki0hHDQhyUCJidJUW7Sja4PuX3o6Wem7/UaluyPo cq7mli6IQlNR8hc8WXGUxVCfLedCJuHwSECB7Zbb4919taLeV11JZgVSMIwajCY/dn9a EXwAo894mfzByZeYJsAJN/7yifwr92mhp3seZWq5IJ+36ZN2egMp0sLtSQuvKtfiUwBN SnG7l4CqFjvDe3x0PEGAiQKrRBGACCO41YrTNV5Fx+0EA4HLdQ1DvQHVpmR8QQSmqVG/ sMDupGpAWnx5mu2Zrrws4+JqAy2sbGnp9V9cT2Tliz1Fx+gd3jeKyTEXHKKQd+8u9gjT 3MEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:references:message-id:date :thread-index:thread-topic:subject:cc:to:from:dkim-signature; bh=DOEO3y2soOvXq8t/1GH0lADqJ6A3XwpUwCBU/Y2+CsU=; b=C2A+kBSgBX5KHIJb71yWs5KfBCzK354jWAnhVKpwOiEKU1POFuZXn3r59+sEEywcko hd9oLJtYdzCQw0X5WpKIqQv34iEFRQqMUGUp9xtr/qzi111xgul8/zI+VsOgSlFzMPgr 1sBap6TmqPfXDh6TvNdf/PvDlrwsTBJyqpOuJ8+DO2oFzgxRYaALO/hs44pwwwMnb8LS i2FPEwloRvlURRexPYpz2mApoGverxxhssmvGZWXv6DqN1yTGNhvLVXRE3g+veYN2+JG YUc3iqd/qLAOrCfmlQEwTcR7Z8HJ1BaBfLEZzIb2YoLPe8wRkYsWhiZMHg7y/Ri+p4Bu f4eA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alliedtelesis.co.nz header.s=mail181024 header.b=tKXqnvKm; 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=alliedtelesis.co.nz Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y1si414786pgf.211.2019.05.22.13.55.51; Wed, 22 May 2019 13:56:07 -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=@alliedtelesis.co.nz header.s=mail181024 header.b=tKXqnvKm; 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=alliedtelesis.co.nz Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730383AbfEVUxn (ORCPT + 99 others); Wed, 22 May 2019 16:53:43 -0400 Received: from gate2.alliedtelesis.co.nz ([202.36.163.20]:38642 "EHLO gate2.alliedtelesis.co.nz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729528AbfEVUxm (ORCPT ); Wed, 22 May 2019 16:53:42 -0400 Received: from mmarshal3.atlnz.lc (mmarshal3.atlnz.lc [10.32.18.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by gate2.alliedtelesis.co.nz (Postfix) with ESMTPS id 6E53A886BF for ; Thu, 23 May 2019 08:53:38 +1200 (NZST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alliedtelesis.co.nz; s=mail181024; t=1558558418; bh=DOEO3y2soOvXq8t/1GH0lADqJ6A3XwpUwCBU/Y2+CsU=; h=From:To:CC:Subject:Date:References; b=tKXqnvKm1e2jPtxiUAa9wBkNp5sPy3IrM8N13NfWSr/ObgLN3VIh7ZmkH4qjwe+01 i3gi8mbXgliFjD3Ceq5pSXJb9q8v0jQh1B4Y94ryyTMauKVP8wNxOrHVD2z9o0wQqv lGgB4nIONrovafdDAmf5WXQhyKQ8Ze+xrnMG0/fIPWkt+0Naj2Ws9aDXlCyCdq7Gda 2ZE2yveMBtHBtZgXanpd6MaJvdEHbq2mRUA86Kdl5+AQdzcGnY++v+GQlIAL6qyTOd 9sBIzwC2sNiVKluVS7qt6sYBgMGPcBGWokc+/6/RbX5u0etwgtXbNsqVNuyzP9V6VR Xe2cIy+F6eWXw== Received: from svr-chch-ex1.atlnz.lc (Not Verified[10.32.16.77]) by mmarshal3.atlnz.lc with Trustwave SEG (v7,5,8,10121) id ; Thu, 23 May 2019 08:53:36 +1200 Received: from svr-chch-ex1.atlnz.lc (2001:df5:b000:bc8:409d:36f5:8899:92e8) by svr-chch-ex1.atlnz.lc (2001:df5:b000:bc8:409d:36f5:8899:92e8) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 23 May 2019 08:53:37 +1200 Received: from svr-chch-ex1.atlnz.lc ([fe80::409d:36f5:8899:92e8]) by svr-chch-ex1.atlnz.lc ([fe80::409d:36f5:8899:92e8%12]) with mapi id 15.00.1156.000; Thu, 23 May 2019 08:53:37 +1200 From: Chris Packham To: Richard Weinberger CC: David Woodhouse , Brian Norris , Marek Vasut , "Miquel Raynal" , Richard Weinberger , Vignesh Raghavendra , "linux-mtd@lists.infradead.org" , LKML Subject: Re: [PATCH 1/2] mtd: concat: refactor concat_lock/concat_unlock Thread-Topic: [PATCH 1/2] mtd: concat: refactor concat_lock/concat_unlock Thread-Index: AQHVEDJo4rpNy/YxbUOF1g0LZpyjfw== Date: Wed, 22 May 2019 20:53:36 +0000 Message-ID: <86adfe1f5a18492fbdf4bbe26ca05a93@svr-chch-ex1.atlnz.lc> References: <20190522000753.13300-1-chris.packham@alliedtelesis.co.nz> Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:df5:b000:22:3a2c:4aff:fe70:2b02] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/05/19 8:30 AM, Richard Weinberger wrote:=0A= > On Wed, May 22, 2019 at 2:08 AM Chris Packham=0A= > wrote:=0A= >>=0A= >> concat_lock() and concat_unlock() only differed in terms of the mtd_xx= =0A= >> operation they called. Refactor them to use a common helper function and= =0A= >> pass mtd_lock or mtd_unlock as an argument.=0A= >>=0A= >> Signed-off-by: Chris Packham =0A= >> ---=0A= >> drivers/mtd/mtdconcat.c | 41 +++++++++--------------------------------= =0A= >> 1 file changed, 9 insertions(+), 32 deletions(-)=0A= >>=0A= >> diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c=0A= >> index cbc5925e6440..9514cd2db63c 100644=0A= >> --- a/drivers/mtd/mtdconcat.c=0A= >> +++ b/drivers/mtd/mtdconcat.c=0A= >> @@ -451,7 +451,8 @@ static int concat_erase(struct mtd_info *mtd, struct= erase_info *instr)=0A= >> return err;=0A= >> }=0A= >>=0A= >> -static int concat_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)= =0A= >> +static int __concat_xxlock(struct mtd_info *mtd, loff_t ofs, uint64_t l= en,=0A= >> + int (*mtd_op)(struct mtd_info *mtd, loff_t of= s, uint64_t len))=0A= >> {=0A= >> struct mtd_concat *concat =3D CONCAT(mtd);=0A= >> int i, err =3D -EINVAL;=0A= >> @@ -470,7 +471,7 @@ static int concat_lock(struct mtd_info *mtd, loff_t = ofs, uint64_t len)=0A= >> else=0A= >> size =3D len;=0A= >>=0A= >> - err =3D mtd_lock(subdev, ofs, size);=0A= >> + err =3D mtd_op(subdev, ofs, size);=0A= >> if (err)=0A= >> break;=0A= >>=0A= >> @@ -485,38 +486,14 @@ static int concat_lock(struct mtd_info *mtd, loff_= t ofs, uint64_t len)=0A= >> return err;=0A= >> }=0A= >>=0A= >> -static int concat_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len= )=0A= >> +static int concat_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)= =0A= >> {=0A= >> - struct mtd_concat *concat =3D CONCAT(mtd);=0A= >> - int i, err =3D 0;=0A= >> -=0A= >> - for (i =3D 0; i < concat->num_subdev; i++) {=0A= >> - struct mtd_info *subdev =3D concat->subdev[i];=0A= >> - uint64_t size;=0A= >> -=0A= >> - if (ofs >=3D subdev->size) {=0A= >> - size =3D 0;=0A= >> - ofs -=3D subdev->size;=0A= >> - continue;=0A= >> - }=0A= >> - if (ofs + len > subdev->size)=0A= >> - size =3D subdev->size - ofs;=0A= >> - else=0A= >> - size =3D len;=0A= >> -=0A= >> - err =3D mtd_unlock(subdev, ofs, size);=0A= >> - if (err)=0A= >> - break;=0A= >> -=0A= >> - len -=3D size;=0A= >> - if (len =3D=3D 0)=0A= >> - break;=0A= >> -=0A= >> - err =3D -EINVAL;=0A= >> - ofs =3D 0;=0A= >> - }=0A= >> + return __concat_xxlock(mtd, ofs, len, mtd_lock);=0A= >> +}=0A= >>=0A= >> - return err;=0A= >> +static int concat_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len= )=0A= >> +{=0A= >> + return __concat_xxlock(mtd, ofs, len, mtd_unlock);=0A= >> }=0A= >>=0A= >> static void concat_sync(struct mtd_info *mtd)=0A= > =0A= > Not sure if it passing a function pointer is worth it. bool is_lock would= =0A= > also do it. But this is a matter of taste, I guess. :)=0A= =0A= I briefly considered that. But since mtd_lock(), mtd_unlock() and =0A= mtd_is_locked() all take the same arguments I figured it'd benefit from =0A= some type checking. A bool wouldn't work (assuming I can convince you =0A= about 2/2) but an enum mtd_op or int flags would do the trick if you =0A= want me to change it.=0A= =0A= > =0A= > Reviewed-by: Richard Weinberger =0A= > =0A= =0A=