linux-kernel - Re: [GIT PULL] mtd: Changes for v5.13-rc4

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] [day] [month] [year] [list]

Message-ID: <20210929002435.4d0b437c@xps13>
Date:   Wed, 29 Sep 2021 00:24:35 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-mtd <linux-mtd@...ts.infradead.org>,
        Richard Weinberger <richard@....at>,
        Tudor Ambarus <Tudor.Ambarus@...rochip.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Frieder Schrempf <frieder.schrempf@...tron.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] mtd: Changes for v5.13-rc4

Hi Linus,

miquel.raynal@...tlin.com wrote on Wed, 26 May 2021 18:46:12 +0200:

> Hi Linus,
> 
> Linus Torvalds <torvalds@...ux-foundation.org> wrote on Wed, 26 May
> 2021 06:20:35 -1000:
> 
> > On Wed, May 26, 2021 at 5:59 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:  
> > >
> > > Raw NAND:
> > > * txx9ndfmc, tmio, sharpsl, ndfc, lpc32xx_slc, fsmc, cs553x:
> > >   - Fix external use of SW Hamming ECC helper    
> > 
> > Why are these guys all pointlessly duplicating the ecc wrapper
> > functions for their ecc 'correct' functions?
> > 
> > The whole "the Hamming software ECC engine has been updated to become
> > a proper and independent ECC engine" excuse makes no sense. If
> > multiple chips just want a basic sw hamming helper, then they should
> > have one. Not have to be forced to each write their own pointless
> > wrapper like this.
> > 
> > These chip drivers just want 'ecc_sw_hamming_correct()' with the
> > proper arguments, and it seems entirely wrong to duplicate the helper
> > five times or whatever. There should just be a generic helper - the
> > way there used to be.
> > 
> > In fact, I would generally strongly recommend that if there used to be
> > a generic helper that different chip drivers used (ie the old
> > rawnand_sw_hamming_correct()), then such a helper should be left alone
> > and not change the semantics of it.  
> 
> I am not happy neither with the fix (which I wrote myself) as my first
> goal was to uniformize the way the Hamming helpers are being called (as
> part of a much bigger work). I assumed that all drivers either used the
> Hamming software engine or simply didn't, without thinking about the
> "intermediate" situations where a particular driver would just want to
> call a particular Hamming helper to workaround its "missing" hardware
> capabilities.
> 
> Unfortunately when I spotted that many drivers were broken by my rework
> I decided to provide per-driver fixes, while, as you suggest, I should
> probably have declared a generic 'hamming correct' core helper and use
> that directly instead of duplicating the logic in each broken driver.
> 
> > The new "proper independent ECC engine" that had new semantics should
> > have been the one that got a new name, rather than breaking an old and
> > existing helper function and then making the chip drivers pointlessly
> > write their own new helper functions.
> > 
> > I've pulled this, but under protest. The patch honestly just looks
> > like mindless duplication.  

Just to let you know that I proposed there [1] a series to clean this
up.

[1] https://lore.kernel.org/linux-mtd/20210928221507.199198-1-miquel.raynal@bootlin.com/T/#t

Thanks,
Miquèl