From: Miquel Raynal <miquel.raynal@bootlin.com>
To: David Regan <dregan@broadcom.com>
Cc: dregan@mail.com, Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, computersforpeace@gmail.com,
kdasu.kdev@gmail.com, linux-mtd@lists.infradead.org,
devicetree@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Joel Peshkin <joel.peshkin@broadcom.com>,
Tomer Yacoby <tomer.yacoby@broadcom.com>,
Dan Beygelman <dan.beygelman@broadcom.com>,
William Zhang <william.zhang@broadcom.com>,
Anand Gore <anand.gore@broadcom.com>,
Kursad Oney <kursad.oney@broadcom.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
rafal@milecki.pl, bcm-kernel-feedback-list@broadcom.com,
andre.przywara@arm.com, baruch@tkos.co.il,
linux-arm-kernel@lists.infradead.org,
Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [PATCH v3 10/10] mtd: rawnand: brcmnand: allow for on-die ecc
Date: Mon, 29 Jan 2024 11:52:28 +0100 [thread overview]
Message-ID: <20240129115228.06dc2292@xps-13> (raw)
In-Reply-To: <CAA_RMS5gX88v_Qt1csgSL_ffMNsqo2G8B164EB_Hg=hXd620eg@mail.gmail.com>
Hi David,
dregan@broadcom.com wrote on Fri, 26 Jan 2024 11:57:39 -0800:
> Hi Miquèl,
>
> On Thu, Jan 25, 2024 at 10:19 PM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> >
> > Hi David,
> >
> > dregan@broadcom.com wrote on Thu, 25 Jan 2024 11:47:46 -0800:
> >
> > > Hi Miquèl,
> > >
> > > On Wed, Jan 24, 2024 at 9:40 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi David,
> > > >
> > > > dregan@broadcom.com wrote on Tue, 23 Jan 2024 19:04:58 -0800:
> > > >
> > > > > Allow settings for on-die ecc such that if on-die ECC is selected
> > > > > don't error out but require ECC strap setting of zero
> > > > >
> > > > > Signed-off-by: David Regan <dregan@broadcom.com>
> > > > > Reviewed-by: William Zhang <william.zhang@broadcom.com>
> > > > > ---
> > > > > Changes in v3: None
> > > > > ---
> > > > > Changes in v2:
> > > > > - Added to patch series
> > > > > ---
> > > > > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 14 ++++++++++----
> > > > > 1 file changed, 10 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > > > > index a4e311b6798c..42526f3250c9 100644
> > > > > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > > > > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > > > > @@ -2727,9 +2727,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
> > > > > cfg->blk_adr_bytes = get_blk_adr_bytes(mtd->size, mtd->writesize);
> > > > >
> > > > > if (chip->ecc.engine_type != NAND_ECC_ENGINE_TYPE_ON_HOST) {
> > > > > - dev_err(ctrl->dev, "only HW ECC supported; selected: %d\n",
> > > > > - chip->ecc.engine_type);
> > > > > - return -EINVAL;
> > > > > + if (chip->ecc.strength) {
> > > > > + dev_err(ctrl->dev, "ERROR!!! HW ECC must be set to zero for non-hardware ECC; selected: %d\n",
> > > > > + chip->ecc.strength);
> > > >
> > > > Can you use a more formal string? Also clarify it because I don't
> > > > really understand what it leads to.
> > >
> > > How about:
> > >
> > > dev_err(ctrl->dev, "HW ECC set to %d, must be zero for on-die ECC\n",
> >
> > Actually I am wondering how legitimate this is. Just don't enable the
> > on host ECC engine if it's not in use. No need to check the core's
> > choice.
>
> Our chip ECC engine will either be on if it's needed or off if it's not.
> Either I can do that in one place or put checks in before each
> read/write to turn on/off the ECC engine, which seems a lot more
> work and changes and possible issues/problems.
> Turning it on/off as needed has not been explicitly tested and
> could cause unforeseen consequences. This
> is a minimal change which should have minimal impact.
>
> >
> > >
> > > >
> > > > > + return -EINVAL;
> > > > > + }
> > > > > }
> > > > >
> > > > > if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) {
> > > > > @@ -2797,7 +2799,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
> > > > > if (ret)
> > > > > return ret;
> > > > >
> > > > > - brcmnand_set_ecc_enabled(host, 1);
> > > > > + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_ON_DIE) {
> > > > > + dev_dbg(ctrl->dev, "Disable HW ECC for on-die ECC\n");
> > > >
> > > > Not needed.
> > >
> > > Will remove.
> > >
> > > >
> > > > > + brcmnand_set_ecc_enabled(host, 0);
> > > > > + } else
> > > > > + brcmnand_set_ecc_enabled(host, 1);
> > > >
> > > > Style is wrong, but otherwise I think ECC should be kept disabled while
> > > > not in active use, so I am a bit surprised by this line.
> > >
> > > This is a double check to turn on/off our hardware ECC.
> >
> > I expect the engine to be always disabled. Enable it only when you
> > need (may require an additional patch before this one).
>
> We are already turning on the ECC enable at this point,
> this is just adding the option to turn it off if the NAND chip
> itself will be doing the ECC instead of our controller.
Sorry if I have not been clear.
This sequence:
- init
- enable hw ECC engine
Is broken.
It *cannot* work as any operation going through exec_op now may
perform page reads which should be unmodified by the ECC engine. You
driver *must* follow the following sequence:
- init and disable (or keep disabled) the hw ECC engine
- when you perform a page operation with correction you need to
- enable the engine
- perform the operation
- disable the engine
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: David Regan <dregan@broadcom.com>
Cc: dregan@mail.com, Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, computersforpeace@gmail.com,
kdasu.kdev@gmail.com, linux-mtd@lists.infradead.org,
devicetree@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Joel Peshkin <joel.peshkin@broadcom.com>,
Tomer Yacoby <tomer.yacoby@broadcom.com>,
Dan Beygelman <dan.beygelman@broadcom.com>,
William Zhang <william.zhang@broadcom.com>,
Anand Gore <anand.gore@broadcom.com>,
Kursad Oney <kursad.oney@broadcom.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
rafal@milecki.pl, bcm-kernel-feedback-list@broadcom.com,
andre.przywara@arm.com, baruch@tkos.co.il,
linux-arm-kernel@lists.infradead.org,
Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [PATCH v3 10/10] mtd: rawnand: brcmnand: allow for on-die ecc
Date: Mon, 29 Jan 2024 11:52:28 +0100 [thread overview]
Message-ID: <20240129115228.06dc2292@xps-13> (raw)
In-Reply-To: <CAA_RMS5gX88v_Qt1csgSL_ffMNsqo2G8B164EB_Hg=hXd620eg@mail.gmail.com>
Hi David,
dregan@broadcom.com wrote on Fri, 26 Jan 2024 11:57:39 -0800:
> Hi Miquèl,
>
> On Thu, Jan 25, 2024 at 10:19 PM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> >
> > Hi David,
> >
> > dregan@broadcom.com wrote on Thu, 25 Jan 2024 11:47:46 -0800:
> >
> > > Hi Miquèl,
> > >
> > > On Wed, Jan 24, 2024 at 9:40 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi David,
> > > >
> > > > dregan@broadcom.com wrote on Tue, 23 Jan 2024 19:04:58 -0800:
> > > >
> > > > > Allow settings for on-die ecc such that if on-die ECC is selected
> > > > > don't error out but require ECC strap setting of zero
> > > > >
> > > > > Signed-off-by: David Regan <dregan@broadcom.com>
> > > > > Reviewed-by: William Zhang <william.zhang@broadcom.com>
> > > > > ---
> > > > > Changes in v3: None
> > > > > ---
> > > > > Changes in v2:
> > > > > - Added to patch series
> > > > > ---
> > > > > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 14 ++++++++++----
> > > > > 1 file changed, 10 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > > > > index a4e311b6798c..42526f3250c9 100644
> > > > > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > > > > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > > > > @@ -2727,9 +2727,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
> > > > > cfg->blk_adr_bytes = get_blk_adr_bytes(mtd->size, mtd->writesize);
> > > > >
> > > > > if (chip->ecc.engine_type != NAND_ECC_ENGINE_TYPE_ON_HOST) {
> > > > > - dev_err(ctrl->dev, "only HW ECC supported; selected: %d\n",
> > > > > - chip->ecc.engine_type);
> > > > > - return -EINVAL;
> > > > > + if (chip->ecc.strength) {
> > > > > + dev_err(ctrl->dev, "ERROR!!! HW ECC must be set to zero for non-hardware ECC; selected: %d\n",
> > > > > + chip->ecc.strength);
> > > >
> > > > Can you use a more formal string? Also clarify it because I don't
> > > > really understand what it leads to.
> > >
> > > How about:
> > >
> > > dev_err(ctrl->dev, "HW ECC set to %d, must be zero for on-die ECC\n",
> >
> > Actually I am wondering how legitimate this is. Just don't enable the
> > on host ECC engine if it's not in use. No need to check the core's
> > choice.
>
> Our chip ECC engine will either be on if it's needed or off if it's not.
> Either I can do that in one place or put checks in before each
> read/write to turn on/off the ECC engine, which seems a lot more
> work and changes and possible issues/problems.
> Turning it on/off as needed has not been explicitly tested and
> could cause unforeseen consequences. This
> is a minimal change which should have minimal impact.
>
> >
> > >
> > > >
> > > > > + return -EINVAL;
> > > > > + }
> > > > > }
> > > > >
> > > > > if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) {
> > > > > @@ -2797,7 +2799,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
> > > > > if (ret)
> > > > > return ret;
> > > > >
> > > > > - brcmnand_set_ecc_enabled(host, 1);
> > > > > + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_ON_DIE) {
> > > > > + dev_dbg(ctrl->dev, "Disable HW ECC for on-die ECC\n");
> > > >
> > > > Not needed.
> > >
> > > Will remove.
> > >
> > > >
> > > > > + brcmnand_set_ecc_enabled(host, 0);
> > > > > + } else
> > > > > + brcmnand_set_ecc_enabled(host, 1);
> > > >
> > > > Style is wrong, but otherwise I think ECC should be kept disabled while
> > > > not in active use, so I am a bit surprised by this line.
> > >
> > > This is a double check to turn on/off our hardware ECC.
> >
> > I expect the engine to be always disabled. Enable it only when you
> > need (may require an additional patch before this one).
>
> We are already turning on the ECC enable at this point,
> this is just adding the option to turn it off if the NAND chip
> itself will be doing the ECC instead of our controller.
Sorry if I have not been clear.
This sequence:
- init
- enable hw ECC engine
Is broken.
It *cannot* work as any operation going through exec_op now may
perform page reads which should be unmodified by the ECC engine. You
driver *must* follow the following sequence:
- init and disable (or keep disabled) the hw ECC engine
- when you perform a page operation with correction you need to
- enable the engine
- perform the operation
- disable the engine
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: David Regan <dregan@broadcom.com>
Cc: dregan@mail.com, Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, computersforpeace@gmail.com,
kdasu.kdev@gmail.com, linux-mtd@lists.infradead.org,
devicetree@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Joel Peshkin <joel.peshkin@broadcom.com>,
Tomer Yacoby <tomer.yacoby@broadcom.com>,
Dan Beygelman <dan.beygelman@broadcom.com>,
William Zhang <william.zhang@broadcom.com>,
Anand Gore <anand.gore@broadcom.com>,
Kursad Oney <kursad.oney@broadcom.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
rafal@milecki.pl, bcm-kernel-feedback-list@broadcom.com,
andre.przywara@arm.com, baruch@tkos.co.il,
linux-arm-kernel@lists.infradead.org,
Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [PATCH v3 10/10] mtd: rawnand: brcmnand: allow for on-die ecc
Date: Mon, 29 Jan 2024 11:52:28 +0100 [thread overview]
Message-ID: <20240129115228.06dc2292@xps-13> (raw)
In-Reply-To: <CAA_RMS5gX88v_Qt1csgSL_ffMNsqo2G8B164EB_Hg=hXd620eg@mail.gmail.com>
Hi David,
dregan@broadcom.com wrote on Fri, 26 Jan 2024 11:57:39 -0800:
> Hi Miquèl,
>
> On Thu, Jan 25, 2024 at 10:19 PM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> >
> > Hi David,
> >
> > dregan@broadcom.com wrote on Thu, 25 Jan 2024 11:47:46 -0800:
> >
> > > Hi Miquèl,
> > >
> > > On Wed, Jan 24, 2024 at 9:40 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi David,
> > > >
> > > > dregan@broadcom.com wrote on Tue, 23 Jan 2024 19:04:58 -0800:
> > > >
> > > > > Allow settings for on-die ecc such that if on-die ECC is selected
> > > > > don't error out but require ECC strap setting of zero
> > > > >
> > > > > Signed-off-by: David Regan <dregan@broadcom.com>
> > > > > Reviewed-by: William Zhang <william.zhang@broadcom.com>
> > > > > ---
> > > > > Changes in v3: None
> > > > > ---
> > > > > Changes in v2:
> > > > > - Added to patch series
> > > > > ---
> > > > > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 14 ++++++++++----
> > > > > 1 file changed, 10 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > > > > index a4e311b6798c..42526f3250c9 100644
> > > > > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > > > > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > > > > @@ -2727,9 +2727,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
> > > > > cfg->blk_adr_bytes = get_blk_adr_bytes(mtd->size, mtd->writesize);
> > > > >
> > > > > if (chip->ecc.engine_type != NAND_ECC_ENGINE_TYPE_ON_HOST) {
> > > > > - dev_err(ctrl->dev, "only HW ECC supported; selected: %d\n",
> > > > > - chip->ecc.engine_type);
> > > > > - return -EINVAL;
> > > > > + if (chip->ecc.strength) {
> > > > > + dev_err(ctrl->dev, "ERROR!!! HW ECC must be set to zero for non-hardware ECC; selected: %d\n",
> > > > > + chip->ecc.strength);
> > > >
> > > > Can you use a more formal string? Also clarify it because I don't
> > > > really understand what it leads to.
> > >
> > > How about:
> > >
> > > dev_err(ctrl->dev, "HW ECC set to %d, must be zero for on-die ECC\n",
> >
> > Actually I am wondering how legitimate this is. Just don't enable the
> > on host ECC engine if it's not in use. No need to check the core's
> > choice.
>
> Our chip ECC engine will either be on if it's needed or off if it's not.
> Either I can do that in one place or put checks in before each
> read/write to turn on/off the ECC engine, which seems a lot more
> work and changes and possible issues/problems.
> Turning it on/off as needed has not been explicitly tested and
> could cause unforeseen consequences. This
> is a minimal change which should have minimal impact.
>
> >
> > >
> > > >
> > > > > + return -EINVAL;
> > > > > + }
> > > > > }
> > > > >
> > > > > if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) {
> > > > > @@ -2797,7 +2799,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
> > > > > if (ret)
> > > > > return ret;
> > > > >
> > > > > - brcmnand_set_ecc_enabled(host, 1);
> > > > > + if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_ON_DIE) {
> > > > > + dev_dbg(ctrl->dev, "Disable HW ECC for on-die ECC\n");
> > > >
> > > > Not needed.
> > >
> > > Will remove.
> > >
> > > >
> > > > > + brcmnand_set_ecc_enabled(host, 0);
> > > > > + } else
> > > > > + brcmnand_set_ecc_enabled(host, 1);
> > > >
> > > > Style is wrong, but otherwise I think ECC should be kept disabled while
> > > > not in active use, so I am a bit surprised by this line.
> > >
> > > This is a double check to turn on/off our hardware ECC.
> >
> > I expect the engine to be always disabled. Enable it only when you
> > need (may require an additional patch before this one).
>
> We are already turning on the ECC enable at this point,
> this is just adding the option to turn it off if the NAND chip
> itself will be doing the ECC instead of our controller.
Sorry if I have not been clear.
This sequence:
- init
- enable hw ECC engine
Is broken.
It *cannot* work as any operation going through exec_op now may
perform page reads which should be unmodified by the ECC engine. You
driver *must* follow the following sequence:
- init and disable (or keep disabled) the hw ECC engine
- when you perform a page operation with correction you need to
- enable the engine
- perform the operation
- disable the engine
Thanks,
Miquèl
next prev parent reply other threads:[~2024-01-29 10:52 UTC|newest]
Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 3:04 [PATCH v3 00/10] mtd: rawnand: brcmnand: driver and doc updates David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` [PATCH v3 01/10] dt-bindings: mtd: brcmnand: Updates for bcmbca SoCs David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 17:24 ` Conor Dooley
2024-01-24 17:24 ` Conor Dooley
2024-01-24 17:24 ` Conor Dooley
2024-01-25 3:01 ` William Zhang
2024-01-25 3:01 ` William Zhang
2024-01-25 3:01 ` William Zhang
2024-01-25 19:51 ` Conor Dooley
2024-01-25 19:51 ` Conor Dooley
2024-01-25 19:51 ` Conor Dooley
2024-01-26 1:55 ` William Zhang
2024-01-26 1:55 ` William Zhang
2024-01-26 1:55 ` William Zhang
2024-01-26 16:46 ` Conor Dooley
2024-01-26 16:46 ` Conor Dooley
2024-01-26 16:46 ` Conor Dooley
2024-01-26 18:09 ` William Zhang
2024-01-26 18:09 ` William Zhang
2024-01-26 18:09 ` William Zhang
2024-01-24 17:24 ` Conor Dooley
2024-01-24 17:24 ` Conor Dooley
2024-01-24 17:24 ` Conor Dooley
2024-01-24 17:34 ` Miquel Raynal
2024-01-24 17:34 ` Miquel Raynal
2024-01-24 17:34 ` Miquel Raynal
2024-01-25 3:14 ` William Zhang
2024-01-25 3:14 ` William Zhang
2024-01-25 3:14 ` William Zhang
2024-01-24 3:04 ` [PATCH v3 02/10] ARM: dts: broadcom: bcmbca: Add NAND controller node David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 17:30 ` Miquel Raynal
2024-01-24 17:30 ` Miquel Raynal
2024-01-24 17:30 ` Miquel Raynal
2024-01-25 3:09 ` William Zhang
2024-01-25 3:09 ` William Zhang
2024-01-25 3:09 ` William Zhang
2024-01-25 3:34 ` Florian Fainelli
2024-01-25 3:34 ` Florian Fainelli
2024-01-25 3:34 ` Florian Fainelli
2024-01-25 5:53 ` William Zhang
2024-01-25 5:53 ` William Zhang
2024-01-25 5:53 ` William Zhang
2024-01-25 9:20 ` Miquel Raynal
2024-01-25 9:20 ` Miquel Raynal
2024-01-25 9:20 ` Miquel Raynal
2024-01-25 18:14 ` William Zhang
2024-01-25 18:14 ` William Zhang
2024-01-25 18:14 ` William Zhang
2024-01-24 3:04 ` [PATCH v3 03/10] arm64: " David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` [PATCH v3 04/10] mtd: rawnand: brcmnand: Rename bcm63138 nand driver David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` [PATCH v3 05/10] mtd: rawnand: brcmnand: Add BCMBCA read data bus interface David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` [PATCH v3 06/10] mtd: rawnand: brcmnand: Add support for getting ecc setting from strap David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 17:32 ` Miquel Raynal
2024-01-24 17:32 ` Miquel Raynal
2024-01-24 17:32 ` Miquel Raynal
2024-01-25 3:13 ` William Zhang
2024-01-25 3:13 ` William Zhang
2024-01-25 3:13 ` William Zhang
2024-01-24 3:04 ` [PATCH v3 07/10] mtd: rawnand: brcmnand: Support write protection setting from dts David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` [PATCH v3 08/10] mtd: rawnand: brcmnand: exec_op helper functions return type fixes David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 17:35 ` Miquel Raynal
2024-01-24 17:35 ` Miquel Raynal
2024-01-24 17:35 ` Miquel Raynal
2024-01-24 3:04 ` [PATCH v3 09/10] mtd: rawnand: brcmnand: update log level messages David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 17:37 ` Miquel Raynal
2024-01-24 17:37 ` Miquel Raynal
2024-01-24 17:37 ` Miquel Raynal
2024-01-25 18:47 ` David Regan
2024-01-25 18:47 ` David Regan
2024-01-25 18:47 ` David Regan
2024-01-24 3:04 ` [PATCH v3 10/10] mtd: rawnand: brcmnand: allow for on-die ecc David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 3:04 ` David Regan
2024-01-24 17:40 ` Miquel Raynal
2024-01-24 17:40 ` Miquel Raynal
2024-01-24 17:40 ` Miquel Raynal
2024-01-25 19:47 ` David Regan
2024-01-25 19:47 ` David Regan
2024-01-25 19:47 ` David Regan
2024-01-26 6:19 ` Miquel Raynal
2024-01-26 6:19 ` Miquel Raynal
2024-01-26 6:19 ` Miquel Raynal
2024-01-26 19:57 ` David Regan
2024-01-26 19:57 ` David Regan
2024-01-26 19:57 ` David Regan
2024-01-29 10:52 ` Miquel Raynal [this message]
2024-01-29 10:52 ` Miquel Raynal
2024-01-29 10:52 ` Miquel Raynal
2024-01-30 8:11 ` William Zhang
2024-01-30 8:11 ` William Zhang
2024-01-30 8:11 ` William Zhang
2024-01-30 11:01 ` Miquel Raynal
2024-01-30 11:01 ` Miquel Raynal
2024-01-30 11:01 ` Miquel Raynal
2024-01-30 15:26 ` David Regan
2024-01-30 15:26 ` David Regan
2024-01-30 15:26 ` David Regan
2024-01-30 18:55 ` Miquel Raynal
2024-01-30 18:55 ` Miquel Raynal
2024-01-30 18:55 ` Miquel Raynal
2024-02-01 6:48 ` William Zhang
2024-02-01 6:48 ` William Zhang
2024-02-01 6:48 ` William Zhang
2024-02-01 8:25 ` Miquel Raynal
2024-02-01 8:25 ` Miquel Raynal
2024-02-01 8:25 ` Miquel Raynal
2024-02-01 18:53 ` William Zhang
2024-02-01 18:53 ` William Zhang
2024-02-01 18:53 ` William Zhang
2024-02-02 17:38 ` David Regan
2024-02-02 17:38 ` David Regan
2024-02-02 17:38 ` David Regan
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=20240129115228.06dc2292@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=anand.gore@broadcom.com \
--cc=andre.przywara@arm.com \
--cc=baruch@tkos.co.il \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=computersforpeace@gmail.com \
--cc=conor+dt@kernel.org \
--cc=dan.beygelman@broadcom.com \
--cc=dan.carpenter@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dregan@broadcom.com \
--cc=dregan@mail.com \
--cc=florian.fainelli@broadcom.com \
--cc=joel.peshkin@broadcom.com \
--cc=kdasu.kdev@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kursad.oney@broadcom.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=tomer.yacoby@broadcom.com \
--cc=vigneshr@ti.com \
--cc=william.zhang@broadcom.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.