Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp1936945imc; Tue, 12 Mar 2019 03:54:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqzFCtKDAwPVRmI52/wTD+NeeaZ2ppT+ziffJdeXfUOQ1MEfoLUTDVSHt5PUhnjv+vWkwBTP X-Received: by 2002:a62:e40d:: with SMTP id r13mr37406697pfh.11.1552388095247; Tue, 12 Mar 2019 03:54:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552388095; cv=none; d=google.com; s=arc-20160816; b=uQhz8jmu1yx5IBGTR5H1Sv7y0d+0CBskeB7dUxGaUinpaiJ0KftAB7T3GvFF48H/RD vUpFZliAsScsrJg4PZPtFCSbP4ET06ikPIRbDKdU10sSvnYThXzH30b0F3tG3O1+tTlN simUV4kk+3RippfzPKG91D95rhkQQmD9LH1cq0fz2moax8Bx50bYh6/9Egzp1fpmCAx4 vVipsOc/nPhVp/1mIH1jcWrhE2pEJ4ALdgJEXsHQOaezrWKgYD2HwPa4BG7+NAnBmiMF Fm5uJygq+cT95DgLP0QlvJhM3H4bu5Px6dttzXm1mdKRaDIgWKJUIT8bWvh16HWP3EKf IyXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature:dkim-filter; bh=ZgV2yFx5wWKrkGMVucK2CamF3L6gxbdxfZJ4ivoFms4=; b=LbS1P5/Cdqgvsd3JdjTOVgx+Ox74I2hfw8rP+t3VcTS/iPnh/GpfhjbtNBuoRlzlAB 4/0ra+IiOc/p648lIRq1rAcTuDJhsevrk0e0BdMIupn3MWMjJS66FiaTu1ioSRWHtXuO msUY6PuJlIIww39CyTLgFzLQBffArUXkjBv+6yMQ4VZy96WRUDU4NZ/ovbKYLj0vfYcy sv0GB8/EZYBFx09A4E2kQsM9UPr/CIQQ3bkT6td6qYUUnZR/wS2f001DosYjSWvJ+rPf xZFSlKpbJ/Sz5fPaaA6RTvStd+QeSJKt+RCbFOkp0jJwLl1smOIg+Z8OfqBNhuj3TJB7 alFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=v2vyN1Az; 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 f4si7591342pfc.96.2019.03.12.03.54.39; Tue, 12 Mar 2019 03:54:55 -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=@nifty.com header.s=dec2015msa header.b=v2vyN1Az; 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 S1726535AbfCLKwE (ORCPT + 99 others); Tue, 12 Mar 2019 06:52:04 -0400 Received: from conssluserg-02.nifty.com ([210.131.2.81]:54948 "EHLO conssluserg-02.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725894AbfCLKwE (ORCPT ); Tue, 12 Mar 2019 06:52:04 -0400 Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) (authenticated) by conssluserg-02.nifty.com with ESMTP id x2CApwm2012086 for ; Tue, 12 Mar 2019 19:51:58 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com x2CApwm2012086 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1552387919; bh=ZgV2yFx5wWKrkGMVucK2CamF3L6gxbdxfZJ4ivoFms4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=v2vyN1AzoJYXM5cwTOnimn5xovn8ONyS1BsicHUEY63pJyKLH1ZOxUvceBZTfNCK2 b/OkxA29h34DZzw73PrO9Fz1+VdBl5BUirsRQGT+VKaioIS6qTG6EAUFUIYCkeaMxq boDKWJ2QJt+QcHMynAiLD+3n0XK2a36hMJCN0qpRNp/pk/mXf23j3mRBWQ46AN8rjV Sd9WmAF/gNymc+GUDEzKJaHi+9XIYjFm2DeuXm4NlNMwXls4DIuLw8ZJzGGYu4+PXt lKEx4jT8JIUpf1KN6VIjkeCKBPnQatAsBULeuOSDBbREfO0LPFkkNriMMb2gZrG6eR 4fBUBSHQ7eeXA== X-Nifty-SrcIP: [209.85.217.53] Received: by mail-vs1-f53.google.com with SMTP id b17so1250712vsr.13 for ; Tue, 12 Mar 2019 03:51:58 -0700 (PDT) X-Gm-Message-State: APjAAAUk+WBGx0fI4R88ibMnEay2OZsm/YZc0ah/daYmDyWPicEvGptn Mkd2ioaqj6jyzeUfm4BOrV0gIVQHvp+pe6iRy1w= X-Received: by 2002:a67:7c04:: with SMTP id x4mr19771381vsc.155.1552387917521; Tue, 12 Mar 2019 03:51:57 -0700 (PDT) MIME-Version: 1.0 References: <1552380290-19951-1-git-send-email-yamada.masahiro@socionext.com> <1552380290-19951-3-git-send-email-yamada.masahiro@socionext.com> <20190312112811.1af0bb00@xps13> In-Reply-To: <20190312112811.1af0bb00@xps13> From: Masahiro Yamada Date: Tue, 12 Mar 2019 19:51:21 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/9] mtd: rawnand: denali: refactor syndrome layout handling for raw access To: Miquel Raynal Cc: Boris Brezillon , Richard Weinberger , Linux Kernel Mailing List , Marek Vasut , linux-mtd , Brian Norris , David Woodhouse Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 12, 2019 at 7:28 PM Miquel Raynal wrote: > > Hi Masahiro, > > Masahiro Yamada wrote on Tue, 12 Mar > 2019 17:44:43 +0900: > > > The Denali IP adopts the syndrome page layout (payload and ECC are > > interleaved). The *_page_raw() and *_oob() callbacks are complicated > > because they must hide the underlying layout used by the hardware, > > and always return contiguous in-band and out-of-band data. > > > > Currently, similar code is duplicated to reorganize the data layout. > > For example, denali_read_page_raw() and denali_write_page_raw() look > > almost the same. > > > > The idea for refactoring is to split the code into two parts: > > [1] conversion of page layout > > [2] what to do at every ECC chunk boundary > > > > For [1], I wrote denali_raw_payload_op() and denali_raw_oob_op(). > > They manipulate data for the Denali controller's specific page layout > > of in-band, out-of-band, respectively. > > > > The difference between write and read is just the operation at > > ECC chunk boundaries. For example, denali_read_oob() calls > > nand_change_read_column_op(), whereas denali_write_oob() calls > > nand_change_write_column_op(). So, I implemented [2] as a callback > > passed into [1]. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > [...] > > > static int denali_read_page_raw(struct nand_chip *chip, uint8_t *buf, > > int oob_required, int page) > > { > > + struct denali_nand_info *denali = to_denali(chip); > > struct mtd_info *mtd = nand_to_mtd(chip); > > - struct denali_nand_info *denali = mtd_to_denali(mtd); > > - int writesize = mtd->writesize; > > - int oobsize = mtd->oobsize; > > - int ecc_steps = chip->ecc.steps; > > - int ecc_size = chip->ecc.size; > > - int ecc_bytes = chip->ecc.bytes; > > void *tmp_buf = denali->buf; > > - int oob_skip = denali->oob_skip_bytes; > > - size_t size = writesize + oobsize; > > - int ret, i, pos, len; > > + size_t size = mtd->writesize + mtd->oobsize; > > + int ret; > > + > > + if (!buf) > > + return -EINVAL; > > > > ret = denali_data_xfer(chip, tmp_buf, size, page, 1, 0); > > if (ret) > > return ret; > > > > - /* Arrange the buffer for syndrome payload/ecc layout */ > > - if (buf) { > > - for (i = 0; i < ecc_steps; i++) { > > - pos = i * (ecc_size + ecc_bytes); > > - len = ecc_size; > > - > > - if (pos >= writesize) > > - pos += oob_skip; > > - else if (pos + len > writesize) > > - len = writesize - pos; > > - > > - memcpy(buf, tmp_buf + pos, len); > > - buf += len; > > - if (len < ecc_size) { > > - len = ecc_size - len; > > - memcpy(buf, tmp_buf + writesize + oob_skip, > > - len); > > - buf += len; > > - } > > - } > > - } > > + ret = denali_raw_payload_op(chip, buf, denali_memcpy_in, tmp_buf); > > Honestly, I still don't like passing denali_memcpy_in/out as parameter. > > Besides that, once you'll have added helpers to avoid abusing the > ternary operator in 4/9, the rest looks fine by me. > Do you have any suggestion? There are 4 callbacks depending on the combination of full-raw/oob, read/write. I do not know how to make it cleaner. -- Best Regards Masahiro Yamada