From: Brian Norris <computersforpeace@gmail.com> To: dedekind1@gmail.com Cc: LiuShuo <b35362@freescale.com>, linuxppc-dev@linux.freescale.net, linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org, dwmw2@infradead.org Subject: Re: [PATCH] mtd-utils: fix corrupt cleanmarker with flash_erase -j command Date: Wed, 17 Aug 2011 18:20:58 -0700 [thread overview] Message-ID: <CAN8TOE9QEX6Yssy4HCONrawngmRRCgYbh5jNVpH1dREUsDfagg@mail.gmail.com> (raw) In-Reply-To: <1313566762.19563.3.camel@sauron> On Wed, Aug 17, 2011 at 12:39 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote: > I think the OOB mode should not be a global MTD device state. Each > ioctl invocation should just specify the mode. I agree. This brings up some questions, though. See below. > Brian's idea of having a completely new ioctl or a set of new ioctls for > OOB which would copletely deprecate the old ones is a good idea. Let's > wait for his patch. I sent a patch series (RFC) to the MTD mailing list. You can see the cover description, which describes my proposed changes and asks some questions, at the following link, but for some reason the patches are being held up by the mailing list software - for now, you'll only receive them if you were CC'd directly: http://lists.infradead.org/pipermail/linux-mtd/2011-August/037522.html Follow that thread for more information. > May be we should even start physically removing depricated ioctls by > first adding a printk with a warning and then removing completely. But > first mtdutils should be updated to not use them. Yes, this sounds fine, although I'm not too familiar with the MTD_OOB_AUTO stuff, so I'm not sure how well it will replace all the uses of MEMGETOOBSEL. I don't actually see any users of ECCGETLAYOUT; I think I've asked about this ioctl before, but I can't seem to find any response...perhaps it can be killed with no work? Brian
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <computersforpeace@gmail.com> To: dedekind1@gmail.com Cc: LiuShuo <b35362@freescale.com>, linuxppc-dev@linux.freescale.net, linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org, Li Yang <leoli@freescale.com>, dwmw2@infradead.org Subject: Re: [PATCH] mtd-utils: fix corrupt cleanmarker with flash_erase -j command Date: Wed, 17 Aug 2011 18:20:58 -0700 [thread overview] Message-ID: <CAN8TOE9QEX6Yssy4HCONrawngmRRCgYbh5jNVpH1dREUsDfagg@mail.gmail.com> (raw) In-Reply-To: <1313566762.19563.3.camel@sauron> On Wed, Aug 17, 2011 at 12:39 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote: > I think the OOB mode should not be a global MTD device state. Each > ioctl invocation should just specify the mode. I agree. This brings up some questions, though. See below. > Brian's idea of having a completely new ioctl or a set of new ioctls for > OOB which would copletely deprecate the old ones is a good idea. Let's > wait for his patch. I sent a patch series (RFC) to the MTD mailing list. You can see the cover description, which describes my proposed changes and asks some questions, at the following link, but for some reason the patches are being held up by the mailing list software - for now, you'll only receive them if you were CC'd directly: http://lists.infradead.org/pipermail/linux-mtd/2011-August/037522.html Follow that thread for more information. > May be we should even start physically removing depricated ioctls by > first adding a printk with a warning and then removing completely. But > first mtdutils should be updated to not use them. Yes, this sounds fine, although I'm not too familiar with the MTD_OOB_AUTO stuff, so I'm not sure how well it will replace all the uses of MEMGETOOBSEL. I don't actually see any users of ECCGETLAYOUT; I think I've asked about this ioctl before, but I can't seem to find any response...perhaps it can be killed with no work? Brian
next prev parent reply other threads:[~2011-08-18 1:21 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-08-03 5:50 [PATCH] mtd-utils: fix corrupt cleanmarker with flash_erase -j command b35362 2011-08-03 5:50 ` b35362 2011-08-16 15:06 ` Artem Bityutskiy 2011-08-16 15:06 ` Artem Bityutskiy 2011-08-16 19:42 ` Brian Norris 2011-08-16 19:42 ` Brian Norris 2011-08-17 7:35 ` LiuShuo 2011-08-17 7:35 ` LiuShuo 2011-08-17 7:39 ` Artem Bityutskiy 2011-08-17 7:39 ` Artem Bityutskiy 2011-08-18 1:20 ` Brian Norris [this message] 2011-08-18 1:20 ` Brian Norris 2011-08-08 8:16 b35362
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=CAN8TOE9QEX6Yssy4HCONrawngmRRCgYbh5jNVpH1dREUsDfagg@mail.gmail.com \ --to=computersforpeace@gmail.com \ --cc=b35362@freescale.com \ --cc=dedekind1@gmail.com \ --cc=dwmw2@infradead.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linuxppc-dev@linux.freescale.net \ --cc=linuxppc-dev@ozlabs.org \ /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: linkBe 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.