All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Michał Kępień" <kernel@kempniu.pl>
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	Boris Brezillon <bbrezillon@kernel.org>
Subject: Re: [PATCH] mtd: add MEMREAD ioctl
Date: Thu, 30 Sep 2021 15:58:31 +0200	[thread overview]
Message-ID: <20210930155831.672acdee@xps13> (raw)
In-Reply-To: <YVXBf0v0AQ5+G9dt@larwa.hq.kempniu.pl>

Hi Michał,

kernel@kempniu.pl wrote on Thu, 30 Sep 2021 15:54:07 +0200:

> > > > > > I remember discussing search a new READ ioctl with Sascha Hauer a few
> > > > > > years back, but I can't find the discussion...      
> > > > 
> > > > I think this is the thread in question:
> > > > 
> > > >     https://www.infradead.org/pipermail/linux-mtd/2016-April/thread.html#67085
> > > > 
> > > > In fact, it looks like Boris beat me to preparing a draft patch adding a
> > > > MEMREAD ioctl by some five years:
> > > > 
> > > >     https://www.infradead.org/pipermail/linux-mtd/2016-April/067187.html    
> > > 
> > > Exactly the one I was referring to. Note that this patch still contains
> > > the unbounded malloc which I think is worth fixing, but other than
> > > that and the addition of ECC stats, it looks pretty similar to yours.  
> 
> Right, thanks.
> 
> > > > I guess the big question from my perspective is: should I revive Boris'
> > > > original effort on the MEMREAD ioctl (which returns more detailed
> > > > bitflip stats in the structure passed by user space) or would that be a
> > > > waste of time because the subsystem will be switched over wholesale to a
> > > > new way of doing I/O (mtd_io_op) in the foreseeable future and therefore
> > > > exposing yet another ioctl to user space today would be frowned upon?
> > > >     
> > > 
> > > That's not my call to make, but I think those 2 things are orthogonal
> > > and can be addressed separately.  
> > 
> > Agreed.  
> 
> Thank you both - it sounds like I should start working on a v2 that will
> make the new MEMREAD ioctl return more detailed ECC statistics to user
> space.
> 
> Boris, I think a Suggested-by tag crediting you is in order for both the
> unbounded malloc issue and the MEMREAD ioctl, but submitting-patches.rst
> says I should not add this tag without your permission.  So, are you
> okay with me adding it?
> 
> Miquel, as for the unbounded malloc issue, should I address this in a
> separate (preliminary) patch or rather submit a two-patch v2 series
> (unbounded malloc fix + new MEMREAD ioctl)?

Both work as long as you keep the changes in different commits :)

Thanks,
Miquèl

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Michał Kępień" <kernel@kempniu.pl>
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	Boris Brezillon <bbrezillon@kernel.org>
Subject: Re: [PATCH] mtd: add MEMREAD ioctl
Date: Thu, 30 Sep 2021 15:58:31 +0200	[thread overview]
Message-ID: <20210930155831.672acdee@xps13> (raw)
In-Reply-To: <YVXBf0v0AQ5+G9dt@larwa.hq.kempniu.pl>

Hi Michał,

kernel@kempniu.pl wrote on Thu, 30 Sep 2021 15:54:07 +0200:

> > > > > > I remember discussing search a new READ ioctl with Sascha Hauer a few
> > > > > > years back, but I can't find the discussion...      
> > > > 
> > > > I think this is the thread in question:
> > > > 
> > > >     https://www.infradead.org/pipermail/linux-mtd/2016-April/thread.html#67085
> > > > 
> > > > In fact, it looks like Boris beat me to preparing a draft patch adding a
> > > > MEMREAD ioctl by some five years:
> > > > 
> > > >     https://www.infradead.org/pipermail/linux-mtd/2016-April/067187.html    
> > > 
> > > Exactly the one I was referring to. Note that this patch still contains
> > > the unbounded malloc which I think is worth fixing, but other than
> > > that and the addition of ECC stats, it looks pretty similar to yours.  
> 
> Right, thanks.
> 
> > > > I guess the big question from my perspective is: should I revive Boris'
> > > > original effort on the MEMREAD ioctl (which returns more detailed
> > > > bitflip stats in the structure passed by user space) or would that be a
> > > > waste of time because the subsystem will be switched over wholesale to a
> > > > new way of doing I/O (mtd_io_op) in the foreseeable future and therefore
> > > > exposing yet another ioctl to user space today would be frowned upon?
> > > >     
> > > 
> > > That's not my call to make, but I think those 2 things are orthogonal
> > > and can be addressed separately.  
> > 
> > Agreed.  
> 
> Thank you both - it sounds like I should start working on a v2 that will
> make the new MEMREAD ioctl return more detailed ECC statistics to user
> space.
> 
> Boris, I think a Suggested-by tag crediting you is in order for both the
> unbounded malloc issue and the MEMREAD ioctl, but submitting-patches.rst
> says I should not add this tag without your permission.  So, are you
> okay with me adding it?
> 
> Miquel, as for the unbounded malloc issue, should I address this in a
> separate (preliminary) patch or rather submit a two-patch v2 series
> (unbounded malloc fix + new MEMREAD ioctl)?

Both work as long as you keep the changes in different commits :)

Thanks,
Miquèl

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

  reply	other threads:[~2021-09-30 13:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20  7:02 [PATCH] mtd: add MEMREAD ioctl Michał Kępień
2021-09-20  7:02 ` Michał Kępień
2021-09-28 13:58 ` Miquel Raynal
2021-09-28 13:58   ` Miquel Raynal
2021-09-28 14:24   ` Boris Brezillon
2021-09-28 14:24     ` Boris Brezillon
2021-09-28 14:35     ` Miquel Raynal
2021-09-28 14:35       ` Miquel Raynal
2021-09-29 19:42       ` Michał Kępień
2021-09-29 19:42         ` Michał Kępień
2021-09-30  6:51         ` Boris Brezillon
2021-09-30  6:51           ` Boris Brezillon
2021-09-30  8:47           ` Miquel Raynal
2021-09-30  8:47             ` Miquel Raynal
2021-09-30 13:54             ` Michał Kępień
2021-09-30 13:54               ` Michał Kępień
2021-09-30 13:58               ` Miquel Raynal [this message]
2021-09-30 13:58                 ` Miquel Raynal
2021-09-30 14:22               ` Boris Brezillon
2021-09-30 14:22                 ` Boris Brezillon

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=20210930155831.672acdee@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=bbrezillon@kernel.org \
    --cc=boris.brezillon@collabora.com \
    --cc=kernel@kempniu.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --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.