[{"id":1761497,"web_url":"http://patchwork.ozlabs.org/comment/1761497/","msgid":"<1504250211.8359.4.camel@gmail.com>","list_archive_url":null,"date":"2017-09-01T07:16:51","subject":"Re: [Skiboot] [PATCH] flash: Support adding the no-erase property\n\tto flash","submitter":{"id":68427,"url":"http://patchwork.ozlabs.org/api/people/68427/","name":"Suraj Jitindar Singh","email":"sjitindarsingh@gmail.com"},"content":"Hi,\n\nOn Mon, 2017-08-28 at 23:48 -0700, William A. Kennington III wrote:\n> Currently, flash devices like mbox-flash ignore erase commands. This\n> means that issuing an erase from userspace, through the mtd device,\n> and\n> back returns a successful operation that does nothing. Unfortunately\n> this makes userspace tools unhappy. Linux MTD devices support the\n> MTD_NO_ERASE flag which conveys that writes do not require erases on\n> the\n> underlying flash devices. We should set this property on all of our\n> devices which do not require erases to be performed.\n> \n> NOTE: This still requires a linux kernel component to set the\n> MTD_NO_ERASE flag from the device tree property.\n\nCan I just check, does the MTD_NO_ERASE flag mean that the mtd device\ndoesn't have an erase function, or that an erase isn't necessary before\na write?\n\nBecause the V2 mbox has an erase method which mbox-flash will call when\nan erase is performed. So if it means there isn't an erase function\nthen this is incorrect.\n\nIf it means that an erase isn't required before a write however then I\nsupport this as the mbox protocol explicitly states this to be the\ncase.\n\nThanks,\nSuraj\n\n> \n> Signed-off-by: William A. Kennington III \n> ---\n>  core/flash.c | 4 ++++\n>  1 file changed, 4 insertions(+)\n> \n> diff --git a/core/flash.c b/core/flash.c\n> index 53e6eba08..9e230174f 100644\n> --- a/core/flash.c\n> +++ b/core/flash.c\n> @@ -31,6 +31,7 @@\n>  struct flash {\n>  \tstruct list_node\tlist;\n>  \tbool\t\t\tbusy;\n> +\tbool\t\t\tno_erase;\n>  \tstruct blocklevel_device *bl;\n>  \tuint64_t\t\tsize;\n>  \tuint32_t\t\tblock_size;\n> @@ -199,6 +200,8 @@ static struct dt_node *flash_add_dt_node(struct\n> flash *flash, int id)\n>  \tdt_add_property_u64(flash_node, \"reg\", flash->size);\n>  \tdt_add_property_cells(flash_node, \"ibm,flash-block-size\",\n>  \t\t\tflash->block_size);\n> +\tif (flash->no_erase)\n> +\t\tdt_add_property(flash_node, \"no-erase\", NULL, 0);\n>  \n>  \t/* we fix to 32-bits */\n>  \tdt_add_property_cells(flash_node, \"#address-cells\", 1);\n> @@ -281,6 +284,7 @@ int flash_register(struct blocklevel_device *bl)\n>  \n>  \tflash->busy = false;\n>  \tflash->bl = bl;\n> +\tflash->no_erase = !(bl->flags & WRITE_NEED_ERASE);\n>  \tflash->size = size;\n>  \tflash->block_size = block_size;\n>  \tflash->id = num_flashes();","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","skiboot@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","skiboot@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xk9Y76Xdnz9s7C\n\tfor ;\n\tFri, 1 Sep 2017 17:17:15 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xk9Y75KctzDql1\n\tfor ;\n\tFri, 1 Sep 2017 17:17:15 +1000 (AEST)","from mail-io0-x243.google.com (mail-io0-x243.google.com\n\t[IPv6:2607:f8b0:4001:c06::243])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xk9Xq1YbrzDqhB\n\tfor ; Fri, 1 Sep 2017 17:16:59 +1000 (AEST)","by mail-io0-x243.google.com with SMTP id j99so2067782ioo.4\n\tfor ; Fri, 01 Sep 2017 00:16:59 -0700 (PDT)","from surajjs1.ozlabs.ibm.com ([122.99.82.10])\n\tby smtp.googlemail.com with ESMTPSA id\n\ty140sm1046967itb.28.2017.09.01.00.16.54\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tFri, 01 Sep 2017 00:16:56 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"gtc5LgNa\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"gtc5LgNa\"; dkim-atps=neutral","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"gtc5LgNa\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=message-id:subject:from:to:date:in-reply-to:references:mime-version\n\t:content-transfer-encoding;\n\tbh=/pMYQ/hSQQcE6zdsc1dXupx9prFqJ6vUBRDmNyfS4cw=;\n\tb=gtc5LgNanearHgsiYSpHERdtcTKfF7jUeudMZ/Zs8C32iSntEZ92MfwjHcvYCZ7Wd2\n\tpqXwFlep1Qtk/Bfnr9W3GKNNLPzZHld7NyhspILhplZN5ypdjmAT6enXdWAUnjQj5N9h\n\tnvS6kQlXvBAdx2c/exGQAgiupGM5fDsXIe32DwD1DS/AZSgVqe2SXHv916EDw89FhcOp\n\tEUjRyqclFThKRuFrPES4TmPd3oHcrBFKZiXBhq3yUtxpu6z+nCymn7ZmdYUiqBmnt+oo\n\tB1sVqvGS6yoaeZ6ah5JxHO93fjlXvLQWugG6q4LZ+QjORJ4kmhxAwvSObIILke2N9PXO\n\t012g==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:subject:from:to:date:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=/pMYQ/hSQQcE6zdsc1dXupx9prFqJ6vUBRDmNyfS4cw=;\n\tb=YMO8wuRZs6UHaTVZiPe14QpeX/1Vcm+ob0Q5W6+O6jGCqTeisACWlS1S4mCD7N9qZa\n\tJpILTm7ADmIPUOw3gsOlVSmo34tZxbgDhNoiN4czSnNxd2sJZLiq2TLr6mffjLyyXb0W\n\ta5s8Iog5i8MoIW2OpyiyYgMeuNTsR1u38VdVeHnhIxO3awrGdyH+jW9fAhHVCvM88Gqd\n\tkXrGRvI+LVFrgGW8SZXzRz9fkURJMMBrOjU6FFweZWhseUuz0OD02bd0InHC9atVw5fU\n\tMG7Vdo1jr6XFqvJFjhReJpj/dLlonIXLhlJHwfwbjW0kqL5rbwmqbaH86tEOo/P9SUyQ\n\tJGeA==","X-Gm-Message-State":"AHPjjUhmQzoLpgCrD5ftOMhyH+KVmOkRlaN27NgehLZjidC0ra2qF4cN\n\tMTPfyXQIIVey6vlAN2U=","X-Google-Smtp-Source":"ADKCNb4zUACfldfLjAjTvjM+Qkg6cIvULlyG1JVz2deMUwZGSWJDYjNU7vwFeSxEp3cnFTVczYx4mg==","X-Received":"by 10.107.128.232 with SMTP id k101mr701719ioi.338.1504250216766;\n\tFri, 01 Sep 2017 00:16:56 -0700 (PDT)","Message-ID":"<1504250211.8359.4.camel@gmail.com>","From":"Suraj Jitindar Singh ","To":"\"William A. Kennington III\" , skiboot@lists.ozlabs.org","Date":"Fri, 01 Sep 2017 17:16:51 +1000","In-Reply-To":"<20170829064840.3808-1-wak@google.com>","References":"<20170829064840.3808-1-wak@google.com>","X-Mailer":"Evolution 3.22.6 (3.22.6-2.fc25) ","Mime-Version":"1.0","Subject":"Re: [Skiboot] [PATCH] flash: Support adding the no-erase property\n\tto flash","X-BeenThere":"skiboot@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Mailing list for skiboot development ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"skiboot-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org","Sender":"\"Skiboot\"\n\t"}},{"id":1761830,"web_url":"http://patchwork.ozlabs.org/comment/1761830/","msgid":"","list_archive_url":null,"date":"2017-09-01T17:01:54","subject":"Re: [Skiboot] [PATCH] flash: Support adding the no-erase property\n\tto flash","submitter":{"id":70409,"url":"http://patchwork.ozlabs.org/api/people/70409/","name":"William Kennington","email":"wak@google.com"},"content":"https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-class-mtd#L65\n\"No erase necessary\"\n\nOn Fri, Sep 1, 2017 at 12:16 AM Suraj Jitindar Singh <\nsjitindarsingh@gmail.com> wrote:\n\n> Hi,\n>\n> On Mon, 2017-08-28 at 23:48 -0700, William A. Kennington III wrote:\n> > Currently, flash devices like mbox-flash ignore erase commands. This\n> > means that issuing an erase from userspace, through the mtd device,\n> > and\n> > back returns a successful operation that does nothing. Unfortunately\n> > this makes userspace tools unhappy. Linux MTD devices support the\n> > MTD_NO_ERASE flag which conveys that writes do not require erases on\n> > the\n> > underlying flash devices. We should set this property on all of our\n> > devices which do not require erases to be performed.\n> >\n> > NOTE: This still requires a linux kernel component to set the\n> > MTD_NO_ERASE flag from the device tree property.\n>\n> Can I just check, does the MTD_NO_ERASE flag mean that the mtd device\n> doesn't have an erase function, or that an erase isn't necessary before\n> a write?\n>\n> Because the V2 mbox has an erase method which mbox-flash will call when\n> an erase is performed. So if it means there isn't an erase function\n> then this is incorrect.\n>\n> If it means that an erase isn't required before a write however then I\n> support this as the mbox protocol explicitly states this to be the\n> case.\n>\n> Thanks,\n> Suraj\n>\n> >\n> > Signed-off-by: William A. Kennington III \n> > ---\n> > core/flash.c | 4 ++++\n> > 1 file changed, 4 insertions(+)\n> >\n> > diff --git a/core/flash.c b/core/flash.c\n> > index 53e6eba08..9e230174f 100644\n> > --- a/core/flash.c\n> > +++ b/core/flash.c\n> > @@ -31,6 +31,7 @@\n> > struct flash {\n> > struct list_node list;\n> > bool busy;\n> > + bool no_erase;\n> > struct blocklevel_device *bl;\n> > uint64_t size;\n> > uint32_t block_size;\n> > @@ -199,6 +200,8 @@ static struct dt_node *flash_add_dt_node(struct\n> > flash *flash, int id)\n> > dt_add_property_u64(flash_node, \"reg\", flash->size);\n> > dt_add_property_cells(flash_node, \"ibm,flash-block-size\",\n> > flash->block_size);\n> > + if (flash->no_erase)\n> > + dt_add_property(flash_node, \"no-erase\", NULL, 0);\n> >\n> > /* we fix to 32-bits */\n> > dt_add_property_cells(flash_node, \"#address-cells\", 1);\n> > @@ -281,6 +284,7 @@ int flash_register(struct blocklevel_device *bl)\n> >\n> > flash->busy = false;\n> > flash->bl = bl;\n> > + flash->no_erase = !(bl->flags & WRITE_NEED_ERASE);\n> > flash->size = size;\n> > flash->block_size = block_size;\n> > flash->id = num_flashes();\n>\n
On Fri, Sep 1, 2017 at 12:16 AM Suraj Jitindar Singh <sjitindarsingh@gmail.com> wrote:
Hi,
\n
\nOn Mon, 2017-08-28 at 23:48 -0700, William A. Kennington III wrote:
\n> Currently, flash devices like mbox-flash ignore erase commands. This
\n> means that issuing an erase from userspace, through the mtd device,
\n> and
\n> back returns a successful operation that does nothing. Unfortunately
\n> this makes userspace tools unhappy. Linux MTD devices support the
\n> MTD_NO_ERASE flag which conveys that writes do not require erases on
\n> the
\n> underlying flash devices. We should set this property on all of our
\n> devices which do not require erases to be performed.
\n>
\n> NOTE: This still requires a linux kernel component to set the
\n> MTD_NO_ERASE flag from the device tree property.
\n
\nCan I just check, does the MTD_NO_ERASE flag mean that the mtd device
\ndoesn't have an erase function, or that an erase isn't necessary before
\na write?
\n
\nBecause the V2 mbox has an erase method which mbox-flash will call when
\nan erase is performed. So if it means there isn't an erase function
\nthen this is incorrect.
\n
\nIf it means that an erase isn't required before a write however then I
\nsupport this as the mbox protocol explicitly states this to be the
\ncase.
\n
\nThanks,
\nSuraj
\n
\n>
\n> Signed-off-by: William A. Kennington III <wak@google.com>
\n> ---
\n>  core/flash.c | 4 ++++
\n>  1 file changed, 4 insertions(+)
\n>
\n> diff --git a/core/flash.c b/core/flash.c
\n> index 53e6eba08..9e230174f 100644
\n> --- a/core/flash.c
\n> +++ b/core/flash.c
\n> @@ -31,6 +31,7 @@
\n>  struct flash {
\n>       struct list_node        list;
\n>       bool                    busy;
\n> +     bool                    no_erase;
\n>       struct blocklevel_device *bl;
\n>       uint64_t                size;
\n>       uint32_t                block_size;
\n> @@ -199,6 +200,8 @@ static struct dt_node *flash_add_dt_node(struct
\n> flash *flash, int id)
\n>       dt_add_property_u64(flash_node, "reg", flash->size);
\n>       dt_add_property_cells(flash_node, "ibm,flash-block-size",
\n>                       flash->block_size);
\n> +     if (flash->no_erase)
\n> +             dt_add_property(flash_node, "no-erase", NULL, 0);
\n>  
\n>       /* we fix to 32-bits */
\n>       dt_add_property_cells(flash_node, "#address-cells", 1);
\n> @@ -281,6 +284,7 @@ int flash_register(struct blocklevel_device *bl)
\n>  
\n>       flash->busy = false;
\n>       flash->bl = bl;
\n> +     flash->no_erase = !(bl->flags & WRITE_NEED_ERASE);
\n>       flash->size = size;
\n>       flash->block_size = block_size;
\n>       flash->id = num_flashes();
\n
","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","skiboot@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","skiboot@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkQXC2Bzvz9t2x\n\tfor ;\n\tSat, 2 Sep 2017 03:02:19 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xkQXC0kDHzDqkQ\n\tfor ;\n\tSat, 2 Sep 2017 03:02:19 +1000 (AEST)","from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com\n\t[IPv6:2607:f8b0:400d:c0d::22f])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xkQX10Y61zDqhB\n\tfor ; Sat, 2 Sep 2017 03:02:08 +1000 (AEST)","by mail-qt0-x22f.google.com with SMTP id e2so3667493qta.0\n\tfor ; Fri, 01 Sep 2017 10:02:08 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"Byh7RWTx\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"Byh7RWTx\"; dkim-atps=neutral","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=google.com header.i=@google.com\n\theader.b=\"Byh7RWTx\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=20161025; \n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to;\n\tbh=qJhgoKaiot/2gRIOQ+VGd2qDDTtht4ijegUwaMxUGH4=;\n\tb=Byh7RWTxxDOLVsGHPd/L3c/WOAzZquU6whS3weOeUq+VOxFU0s4FajltqKMbrmU8sh\n\tkaaJVUVoqDa/w+JoYG0iDrLSkGOjNtYKdAMfBYjM6WcuhDKTJww/vkunf4Nkb8o3jolV\n\tyUIIo3xRnpfUsFrwtEFGYShOOKJUZnwQo+hZcSHXewkGD6HLc4UbHKOOnTlT0xvlt6nr\n\tMUh/S3qvgZIED6b4r+Jrtw1kGh8XEiTfgefERVdNU/YzkeglNpBPDj5OF/Q627XxkPHM\n\tEv3RuPv53/UcAh21PAg1tWdhdZc/vKc8nutFwcr//tQN5fD0mLhOcd9c7UuNy5iqfB9h\n\tt6/g==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to;\n\tbh=qJhgoKaiot/2gRIOQ+VGd2qDDTtht4ijegUwaMxUGH4=;\n\tb=cfN4Z+TVRichiDw7ivWjQl3I4T/kRwCUr4dM2w2i1M8peMCKJRJW82vr/RwHQWck6E\n\tAp7q0f3fhFFX7lVIR3jLMxodoVUpajF+96MfHuUL+WZ5IrLlgNNwl7cT/uk7BLsto5Ky\n\tpobKU2fAfKnZmzZt3lRUmHLSaE/43bDAO53yBHuHGMFEJk9+LJYZfQRXhw8kbOYW22nw\n\tAant0eXvfSXa01oSvq53N2xeeN4ecbbQQjJ5pOEOusEN6Sw6sLM97NL7Q97AF3vZrXTu\n\tEyhLIVh5wvEcEFSSuBdsdqXwBihB6/MZs6p2x4WQDEuv1g+lRcuq6tqQxMG9pZcNPvcz\n\twW/g==","X-Gm-Message-State":"AHPjjUiwyUj7nGvAlLkrZf+s2E6HQd1dv0wkqxAJCnWIi3o9s70gLCmM\n\t904oU3kXskwKCreWPIGr/wYn10miYw2U","X-Google-Smtp-Source":"ADKCNb5IkKGKmMbfL/PD/qJcH/+nYRIilxslRMRpEx5QyrMwKewNX4M8ll0NYB4yBVqKz4nkprj0NCHL+ZDEUoStYcc=","X-Received":"by 10.200.47.154 with SMTP id l26mr3919393qta.193.1504285325948; \n\tFri, 01 Sep 2017 10:02:05 -0700 (PDT)","MIME-Version":"1.0","References":"<20170829064840.3808-1-wak@google.com>\n\t<1504250211.8359.4.camel@gmail.com>","In-Reply-To":"<1504250211.8359.4.camel@gmail.com>","From":"William Kennington ","Date":"Fri, 01 Sep 2017 17:01:54 +0000","Message-ID":"","To":"Suraj Jitindar Singh , skiboot@lists.ozlabs.org","Subject":"Re: [Skiboot] [PATCH] flash: Support adding the no-erase property\n\tto flash","X-BeenThere":"skiboot@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Mailing list for skiboot development ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"multipart/mixed;\n\tboundary=\"===============6256874069517807483==\"","Errors-To":"skiboot-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org","Sender":"\"Skiboot\"\n\t"}},{"id":1762405,"web_url":"http://patchwork.ozlabs.org/comment/1762405/","msgid":"<1504495769.2249.1.camel@gmail.com>","list_archive_url":null,"date":"2017-09-04T03:29:29","subject":"Re: [Skiboot] [PATCH] flash: Support adding the no-erase property\n\tto flash","submitter":{"id":68427,"url":"http://patchwork.ozlabs.org/api/people/68427/","name":"Suraj Jitindar Singh","email":"sjitindarsingh@gmail.com"},"content":"On Fri, 2017-09-01 at 17:01 +0000, William Kennington wrote:\n> https://github.com/torvalds/linux/blob/master/Documentation/ABI/testi\n> ng/sysfs-class-mtd#L65\n> \"No erase necessary\"\n\nOk, thanks.\n\nIn that case I agree with this patch but think the commit message needs\nslight rewording as below. :)\n\n> \n> On Fri, Sep 1, 2017 at 12:16 AM Suraj Jitindar Singh gmail.com> wrote:\n> > Hi,\n> > \n> > On Mon, 2017-08-28 at 23:48 -0700, William A. Kennington III wrote:\n> > > Currently, flash devices like mbox-flash ignore erase commands. \n\nmbox-flash now has erase capability (for V2 implementations any way) so\nI think this sentence is misleading. You might be better off referring\nto the fact that the mbox protocol explicitly states that an erase is\nnot required before a write, which is exactly what this flag is\ndesigned to convey.\n\n> > This\n> > > means that issuing an erase from userspace, through the mtd\n> > device,\n> > > and\n> > > back returns a successful operation that does nothing.\n> > Unfortunately\n> > > this makes userspace tools unhappy. Linux MTD devices support the\n> > > MTD_NO_ERASE flag which conveys that writes do not require erases\n> > on\n> > > the\n> > > underlying flash devices. We should set this property on all of\n> > our\n> > > devices which do not require erases to be performed.\n> > >\n> > > NOTE: This still requires a linux kernel component to set the\n> > > MTD_NO_ERASE flag from the device tree property.\n> > \n> > Can I just check, does the MTD_NO_ERASE flag mean that the mtd\n> > device\n> > doesn't have an erase function, or that an erase isn't necessary\n> > before\n> > a write?\n> > \n> > Because the V2 mbox has an erase method which mbox-flash will call\n> > when\n> > an erase is performed. So if it means there isn't an erase function\n> > then this is incorrect.\n> > \n> > If it means that an erase isn't required before a write however\n> > then I\n> > support this as the mbox protocol explicitly states this to be the\n> > case.\n> > \n> > Thanks,\n> > Suraj\n> > \n> > >\n> > > Signed-off-by: William A. Kennington III \n\nWith a slight commit message rewording,\n\nReviewed-by: Suraj Jitindar Singh \n\n> > > ---\n> > >  core/flash.c | 4 ++++\n> > >  1 file changed, 4 insertions(+)\n> > >\n> > > diff --git a/core/flash.c b/core/flash.c\n> > > index 53e6eba08..9e230174f 100644\n> > > --- a/core/flash.c\n> > > +++ b/core/flash.c\n> > > @@ -31,6 +31,7 @@\n> > >  struct flash {\n> > >       struct list_node        list;\n> > >       bool                    busy;\n> > > +     bool                    no_erase;\n> > >       struct blocklevel_device *bl;\n> > >       uint64_t                size;\n> > >       uint32_t                block_size;\n> > > @@ -199,6 +200,8 @@ static struct dt_node\n> > *flash_add_dt_node(struct\n> > > flash *flash, int id)\n> > >       dt_add_property_u64(flash_node, \"reg\", flash->size);\n> > >       dt_add_property_cells(flash_node, \"ibm,flash-block-size\",\n> > >                       flash->block_size);\n> > > +     if (flash->no_erase)\n> > > +             dt_add_property(flash_node, \"no-erase\", NULL, 0);\n> > >  \n> > >       /* we fix to 32-bits */\n> > >       dt_add_property_cells(flash_node, \"#address-cells\", 1);\n> > > @@ -281,6 +284,7 @@ int flash_register(struct blocklevel_device\n> > *bl)\n> > >  \n> > >       flash->busy = false;\n> > >       flash->bl = bl;\n> > > +     flash->no_erase = !(bl->flags & WRITE_NEED_ERASE);\n> > >       flash->size = size;\n> > >       flash->block_size = block_size;\n> > >       flash->id = num_flashes();\n> >","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","skiboot@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","skiboot@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xlwMN0Wknz9sNq\n\tfor ;\n\tMon, 4 Sep 2017 13:29:52 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xlwMM6cH6zDqny\n\tfor ;\n\tMon, 4 Sep 2017 13:29:51 +1000 (AEST)","from mail-pf0-x243.google.com (mail-pf0-x243.google.com\n\t[IPv6:2607:f8b0:400e:c00::243])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xlwM44hjxzDqjP\n\tfor ; Mon, 4 Sep 2017 13:29:36 +1000 (AEST)","by mail-pf0-x243.google.com with SMTP id g13so3588028pfm.2\n\tfor ; Sun, 03 Sep 2017 20:29:36 -0700 (PDT)","from surajjs1.ozlabs.ibm.com ([122.99.82.10])\n\tby smtp.googlemail.com with ESMTPSA id\n\ta13sm8768230pgd.71.2017.09.03.20.29.32\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tSun, 03 Sep 2017 20:29:33 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"qo3JwpcG\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"qo3JwpcG\"; dkim-atps=neutral","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"qo3JwpcG\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=message-id:subject:from:to:date:in-reply-to:references:mime-version\n\t:content-transfer-encoding;\n\tbh=0SOuEToB+KMqRnsVDbKvRGy956ehv+D0aY4t+O4lCDk=;\n\tb=qo3JwpcG3OklQRV2P0xeWo2/RpnlERiPNKOR2sJvhJxom/LDLZW8y2737Y3+CZyAa0\n\tkNwvK2tcFBDYIAKNqB8QbO/CK17zXIFkgs1xnPl0kR7MpVIK1dQLm1xgMee/lfvDoUkg\n\thY5Y9HjdiTzZGZPee4YM8B1/qisMq6D8Np+qAIexz+T5I9a1ipYv7ZpSywhu5EGcB1ZW\n\t9xN7lNoQ1DS3X96AO6x++/tNhcMPm+T6jjeJm2Sayhyfu4sExyn+smC3JTiB8iWjRLUo\n\t+LZ8V96HUImQeaZeLiWaSoH6TdoOXbezSugmTOns1C7OWHhgTvhCVUVmdLQuk7pwwnN1\n\th3Lw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:subject:from:to:date:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=0SOuEToB+KMqRnsVDbKvRGy956ehv+D0aY4t+O4lCDk=;\n\tb=btY+oLmdhE4EYUCuR5M8A3JMKBNzpXQ3uH9/sujAbdTJEdRHLWxxbxLlqXldcrp2WK\n\taOYXicqqXIVcWGeGColEzyvYbc8hdMfQGJDTMdtjrBQ4cl4dchGKat8cAoUxAD3Ucq4t\n\tCoLeGSINsOLfKS7DfQ+fwO13ynTyPgbf+fOFXpLrQxdSqIiblcKl2jbmS54E7BTH51LO\n\tMbaCoiuHcI5+9bAklJ0KX4LSda/UyXX9t6V4idbEX3Mb5HgdOxOy+ZGPKUrMOmGknCtH\n\tiLqcsOK3J/H5PN9vDZ9GjMGUkzp1ef4zHl9zuYkYIhXnCqAjLGi0puBjmmfEMH8+0pzH\n\tH84A==","X-Gm-Message-State":"AHPjjUhmMdg/mxsM4nhJPVJn8gOgNl08X5YlkgzpVv7ZCRuiyQFse381\n\tioJfHUZ19QXAsQ==","X-Google-Smtp-Source":"ADKCNb59x9bclpG8fWYgSidj7YM5GqpxzDQPVDOhT1nFcvmAf9Y2wOOviPPrMEhSndy4a6RyUZ+lJQ==","X-Received":"by 10.84.238.193 with SMTP id l1mr2183199pln.61.1504495773853;\n\tSun, 03 Sep 2017 20:29:33 -0700 (PDT)","Message-ID":"<1504495769.2249.1.camel@gmail.com>","From":"Suraj Jitindar Singh ","To":"William Kennington , skiboot@lists.ozlabs.org","Date":"Mon, 04 Sep 2017 13:29:29 +1000","In-Reply-To":"","References":"<20170829064840.3808-1-wak@google.com>\n\t<1504250211.8359.4.camel@gmail.com>\n\t","X-Mailer":"Evolution 3.22.6 (3.22.6-2.fc25) ","Mime-Version":"1.0","Subject":"Re: [Skiboot] [PATCH] flash: Support adding the no-erase property\n\tto flash","X-BeenThere":"skiboot@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Mailing list for skiboot development ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"skiboot-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org","Sender":"\"Skiboot\"\n\t"}},{"id":1762965,"web_url":"http://patchwork.ozlabs.org/comment/1762965/","msgid":"<87k21dg2iz.fsf@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-05T05:03:48","subject":"Re: [Skiboot] [PATCH] flash: Support adding the no-erase property\n\tto flash","submitter":{"id":48041,"url":"http://patchwork.ozlabs.org/api/people/48041/","name":"Stewart Smith","email":"stewart@linux.vnet.ibm.com"},"content":"\"William A. Kennington III\" writes:\n> Currently, flash devices like mbox-flash ignore erase commands. This\n> means that issuing an erase from userspace, through the mtd device, and\n> back returns a successful operation that does nothing. Unfortunately\n> this makes userspace tools unhappy. Linux MTD devices support the\n> MTD_NO_ERASE flag which conveys that writes do not require erases on the\n> underlying flash devices. We should set this property on all of our\n> devices which do not require erases to be performed.\n>\n> NOTE: This still requires a linux kernel component to set the\n> MTD_NO_ERASE flag from the device tree property.\n>\n> Signed-off-by: William A. Kennington III \n\nThanks! Merged to master (with slight reword based on Suraj's\nsuggestion) as of ba99af9b149d02438347b055e6e7d6bd15e33551","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","skiboot@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","skiboot@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmZPZ4xQZz9sP3\n\tfor ;\n\tTue, 5 Sep 2017 15:04:02 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xmZPZ3ybWzDrJJ\n\tfor ;\n\tTue, 5 Sep 2017 15:04:02 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xmZPS4nywzDqZ9\n\tfor ; Tue, 5 Sep 2017 15:03:56 +1000 (AEST)","from pps.filterd (m0098413.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv854wuKT039833\n\tfor ; Tue, 5 Sep 2017 01:03:54 -0400","from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2csmxah4r8-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Tue, 05 Sep 2017 01:03:54 -0400","from localhost\n\tby e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tMon, 4 Sep 2017 23:03:53 -0600","from b03cxnp07028.gho.boulder.ibm.com (9.17.130.15)\n\tby e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tMon, 4 Sep 2017 23:03:51 -0600","from b03ledav005.gho.boulder.ibm.com\n\t(b03ledav005.gho.boulder.ibm.com [9.17.130.236])\n\tby b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8553oda2884060; Mon, 4 Sep 2017 22:03:50 -0700","from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id AA487BE038;\n\tMon, 4 Sep 2017 23:03:50 -0600 (MDT)","from birb.localdomain (unknown [9.192.255.220])\n\tby b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP id 071ACBE042;\n\tMon, 4 Sep 2017 23:03:50 -0600 (MDT)","by birb.localdomain (Postfix, from userid 1000)\n\tid 82A314F0CA5; Tue, 5 Sep 2017 15:03:48 +1000 (AEST)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=stewart@linux.vnet.ibm.com; receiver=)","From":"Stewart Smith ","To":"\"William A. Kennington III\" , skiboot@lists.ozlabs.org","In-Reply-To":"<20170829064840.3808-1-wak@google.com>","References":"<20170829064840.3808-1-wak@google.com>","Date":"Tue, 05 Sep 2017 15:03:48 +1000","MIME-Version":"1.0","X-TM-AS-GCONF":"00","x-cbid":"17090505-0024-0000-0000-0000172571B6","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007669; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000226; SDB=6.00912439; UDB=6.00457855;\n\tIPR=6.00692702; \n\tBA=6.00005572; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017009;\n\tXFM=3.00000015; UTC=2017-09-05 05:03:52","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090505-0025-0000-0000-00004C964F68","Message-Id":"<87k21dg2iz.fsf@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-05_02:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709050075","Subject":"Re: [Skiboot] [PATCH] flash: Support adding the no-erase property\n\tto flash","X-BeenThere":"skiboot@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Mailing list for skiboot development ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","Errors-To":"skiboot-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org","Sender":"\"Skiboot\"\n\t"}}]