linux-kernel - Re: [PATCH v2 9/9] mtd: rawnand: jz4780-bch: Add support for the JZ4740

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190203160709.29d7d721@bbrezillon>
Date:   Sun, 3 Feb 2019 16:07:09 +0100
From:   Boris Brezillon <bbrezillon@...nel.org>
To:     Paul Cercueil <paul@...pouillou.net>,
        Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Richard Weinberger <richard@....at>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Harvey Hunt <harveyhuntnexus@...il.com>,
        Mathieu Malaterre <malat@...ian.org>,
        linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 9/9] mtd: rawnand: jz4780-bch: Add support for the
 JZ4740

On Sun, 03 Feb 2019 11:56:32 -0300
Paul Cercueil <paul@...pouillou.net> wrote:

> Le dim. 3 févr. 2019 à 11:16, Boris Brezillon <bbrezillon@...nel.org> 
> a écrit :
> > On Sun, 03 Feb 2019 10:58:13 -0300
> > Paul Cercueil <paul@...pouillou.net> wrote:
> >   
> >>  Le dim. 3 févr. 2019 à 4:35, Boris Brezillon 
> >> <bbrezillon@...nel.org>
> >>  a écrit :  
> >>  > On Sat,  2 Feb 2019 20:19:26 -0300
> >>  > Paul Cercueil <paul@...pouillou.net> wrote:
> >>  >  
> >>  >>  Add the backend code for the jz4780-bch driver to support the   
> >> JZ4740  
> >>  >>  SoC from Ingenic.
> >>  >>
> >>  >>  Signed-off-by: Paul Cercueil <paul@...pouillou.net>
> >>  >>  ---
> >>  >>
> >>  >>  Changes:
> >>  >>
> >>  >>  v2: New patch
> >>  >>
> >>  >>   drivers/mtd/nand/raw/ingenic/Makefile         |   2 +-
> >>  >>   drivers/mtd/nand/raw/ingenic/jz4740_bch.c     | 173
> >>  >> ++++++++++++++++++
> >>  >>   .../mtd/nand/raw/ingenic/jz4780_bch_common.c  |   1 +
> >>  >>   .../nand/raw/ingenic/jz4780_bch_internal.h    |   1 +
> >>  >>   4 files changed, 176 insertions(+), 1 deletion(-)
> >>  >>   create mode 100644 drivers/mtd/nand/raw/ingenic/jz4740_bch.c
> >>  >>
> >>  >>  diff --git a/drivers/mtd/nand/raw/ingenic/Makefile
> >>  >> b/drivers/mtd/nand/raw/ingenic/Makefile
> >>  >>  index f38b467490cf..d16c96113a93 100644
> >>  >>  --- a/drivers/mtd/nand/raw/ingenic/Makefile
> >>  >>  +++ b/drivers/mtd/nand/raw/ingenic/Makefile
> >>  >>  @@ -1,3 +1,3 @@
> >>  >>   obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
> >>  >>   obj-$(CONFIG_MTD_NAND_JZ4780) += jz4780_nand.o   
> >> jz4780_bch_common.o  
> >>  >> \
> >>  >>  -				 jz4780_bch.o jz4725b_bch.o
> >>  >>  +				 jz4780_bch.o jz4725b_bch.o jz4740_bch.o  
> >>  >
> >>  > I still don't see the point of the jz4780_bch_common/jz47xxx_bch
> >>  > separation. You seem to always embed all objects anyway, so you   
> >> can  
> >>  > just put the code for both engines in the same source file and   
> >> decide  
> >>  > which one to use based on the compat (which you already do   
> >> anyway).
> >> 
> >>  Each SoC has a different set of registers for the BCH hardware. I 
> >> can
> >>  try to
> >>  cram everything into one file, but it won't be that much cleaner.  
> > 
> > Then maybe they deserve separate drivers/modules.
> > 
> > BTW, didn't you say that one IP uses Reed-Salomon instead of BCH. I'd
> > suggest prefixing structs and functions with jz47xx_ecc instead of
> > jz47xx_bch and naming the common part jz47xx_ecc.c to reflect that.  
> 
> Would it be a good idea to make a generic ECC API that the jz47xx_nand
> driver could use? Then the three jz47xx BCH codepaths could be separate
> drivers that register with the generic ECC core.

Definitely. Actually, Miquel is already working on that, but I don't
think it's a good idea to wait for this new framework to be finished to
get your changes merged. So I'd recommend having a jz specific ECC API
(pretty much the one you have in the common file expect it would be
prefixed with _ecc instead of _bch) and convert it to the generic
approach afterwards. Given the size of the common.c file, you can even
put everything in jz47xx_ecc.h as inline funcs to avoid having yet
another module.