All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-mtd <linux-mtd@lists.infradead.org>,
	Richard Weinberger <richard@nod.at>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] mtd: Changes for v5.13-rc4
Date: Wed, 29 Sep 2021 00:24:35 +0200	[thread overview]
Message-ID: <20210929002435.4d0b437c@xps13> (raw)
In-Reply-To: <20210526184612.751e7e5c@xps13>

Hi Linus,

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

> Hi Linus,
> 
> Linus Torvalds <torvalds@linux-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@bootlin.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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-mtd <linux-mtd@lists.infradead.org>,
	Richard Weinberger <richard@nod.at>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] mtd: Changes for v5.13-rc4
Date: Wed, 29 Sep 2021 00:24:35 +0200	[thread overview]
Message-ID: <20210929002435.4d0b437c@xps13> (raw)
In-Reply-To: <20210526184612.751e7e5c@xps13>

Hi Linus,

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

> Hi Linus,
> 
> Linus Torvalds <torvalds@linux-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@bootlin.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

  reply	other threads:[~2021-09-28 23:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26 15:59 [GIT PULL] mtd: Changes for v5.13-rc4 Miquel Raynal
2021-05-26 15:59 ` Miquel Raynal
2021-05-26 16:20 ` Linus Torvalds
2021-05-26 16:20   ` Linus Torvalds
2021-05-26 16:46   ` Miquel Raynal
2021-05-26 16:46     ` Miquel Raynal
2021-09-28 22:24     ` Miquel Raynal [this message]
2021-09-28 22:24       ` Miquel Raynal
2021-05-26 16:25 ` pr-tracker-bot
2021-05-26 16:25   ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210929002435.4d0b437c@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=frieder.schrempf@kontron.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=torvalds@linux-foundation.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.