| Message ID | d4338bd5-125c-a9e7-cb46-6f5e1da05cfa@sberdevices.ru |
|---|---|
| State | Changes Requested |
| Delegated to: | Miquel Raynal |
| Headers | show |
| Series | [v1] mtd: rawnand: meson: fix bitmask for length in command word | expand |
Hello Arseniy, thank you for submitting this fix! On Wed, Mar 22, 2023 at 7:45 PM Arseniy Krasnov <avkrasnov@sberdevices.ru> wrote: > > Valid mask is 0x3FFF, without this patch the following problems were > found: > > 1) [ 0.938914] Could not find a valid ONFI parameter page, trying > bit-wise majority to recover it > [ 0.947384] ONFI parameter recovery failed, aborting > > 2) Read with disabled ECC mode was broken. > > Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") > Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> This matches what I can see in the old vendor driver, so: Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> [...] > - cmd = (len & GENMASK(5, 0)) | scrambler | DMA_DIR(dir); > + cmd = (len & GENMASK(13, 0)) | scrambler | DMA_DIR(dir); My understanding of the vendor driver is that this "len" is only used for "raw" access (my own words: any access that doesn't use the HW ECC engine). As a future improvement (no need to update re-send this patch) it would be great to have a #define with a meaningful name for "GENMASK(13, 0)" (maybe something like NFC_CMD_RAW_LENGTH) as it's used in multiple places now Best regards, Martin
On 22.03.2023 23:10, Martin Blumenstingl wrote: > Hello Arseniy, > > thank you for submitting this fix! Thanks! > > On Wed, Mar 22, 2023 at 7:45 PM Arseniy Krasnov > <avkrasnov@sberdevices.ru> wrote: >> >> Valid mask is 0x3FFF, without this patch the following problems were >> found: >> >> 1) [ 0.938914] Could not find a valid ONFI parameter page, trying >> bit-wise majority to recover it >> [ 0.947384] ONFI parameter recovery failed, aborting >> >> 2) Read with disabled ECC mode was broken. >> >> Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") >> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> > This matches what I can see in the old vendor driver, so: Moreover it was clear that mask of 0x3f is too small for length of data in bytes, for example for 2048 + OOB size. > Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > [...] >> - cmd = (len & GENMASK(5, 0)) | scrambler | DMA_DIR(dir); >> + cmd = (len & GENMASK(13, 0)) | scrambler | DMA_DIR(dir); > My understanding of the vendor driver is that this "len" is only used > for "raw" access (my own words: any access that doesn't use the HW ECC > engine). Exactly, 'len' is only for raw access. > As a future improvement (no need to update re-send this patch) it > would be great to have a #define with a meaningful name for > "GENMASK(13, 0)" (maybe something like NFC_CMD_RAW_LENGTH) as it's > used in multiple places now Ack Thanks, Arseniy > > > Best regards, > Martin
Hello! @Miquel Raynal, what is the status of this patch? Thanks, Arseniy On 23.03.2023 10:57, Arseniy Krasnov wrote: > > > On 22.03.2023 23:10, Martin Blumenstingl wrote: >> Hello Arseniy, >> >> thank you for submitting this fix! > Thanks! >> >> On Wed, Mar 22, 2023 at 7:45 PM Arseniy Krasnov >> <avkrasnov@sberdevices.ru> wrote: >>> >>> Valid mask is 0x3FFF, without this patch the following problems were >>> found: >>> >>> 1) [ 0.938914] Could not find a valid ONFI parameter page, trying >>> bit-wise majority to recover it >>> [ 0.947384] ONFI parameter recovery failed, aborting >>> >>> 2) Read with disabled ECC mode was broken. >>> >>> Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") >>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >> This matches what I can see in the old vendor driver, so: > Moreover it was clear that mask of 0x3f is too small for length of data in > bytes, for example for 2048 + OOB size. >> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> >> >> [...] >>> - cmd = (len & GENMASK(5, 0)) | scrambler | DMA_DIR(dir); >>> + cmd = (len & GENMASK(13, 0)) | scrambler | DMA_DIR(dir); >> My understanding of the vendor driver is that this "len" is only used >> for "raw" access (my own words: any access that doesn't use the HW ECC >> engine). > Exactly, 'len' is only for raw access. >> As a future improvement (no need to update re-send this patch) it >> would be great to have a #define with a meaningful name for >> "GENMASK(13, 0)" (maybe something like NFC_CMD_RAW_LENGTH) as it's >> used in multiple places now > Ack > > Thanks, Arseniy >> >> >> Best regards, >> Martin
Hi Arseniy, avkrasnov@sberdevices.ru wrote on Tue, 28 Mar 2023 18:56:19 +0300: > Hello! > > @Miquel Raynal, what is the status of this patch? Please, it's been 6 days, there is also a maintainer (Liang) in between, I'm fine with the patch but it was too late to take it as part of my previous fixes PR. As said earlier today on the mailing list to Christophe I will make another fixes PR next week (I'll wait for the current one to be part of the next -rc tag). By the way any reason not to have Cc'ed stable? > > Thanks, Arseniy > > On 23.03.2023 10:57, Arseniy Krasnov wrote: > > > > > > On 22.03.2023 23:10, Martin Blumenstingl wrote: > >> Hello Arseniy, > >> > >> thank you for submitting this fix! > > Thanks! > >> > >> On Wed, Mar 22, 2023 at 7:45 PM Arseniy Krasnov > >> <avkrasnov@sberdevices.ru> wrote: > >>> > >>> Valid mask is 0x3FFF, without this patch the following problems were > >>> found: > >>> > >>> 1) [ 0.938914] Could not find a valid ONFI parameter page, trying > >>> bit-wise majority to recover it > >>> [ 0.947384] ONFI parameter recovery failed, aborting > >>> > >>> 2) Read with disabled ECC mode was broken. > >>> > >>> Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") > >>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> > >> This matches what I can see in the old vendor driver, so: > > Moreover it was clear that mask of 0x3f is too small for length of data in > > bytes, for example for 2048 + OOB size. > >> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > >> > >> [...] > >>> - cmd = (len & GENMASK(5, 0)) | scrambler | DMA_DIR(dir); > >>> + cmd = (len & GENMASK(13, 0)) | scrambler | DMA_DIR(dir); > >> My understanding of the vendor driver is that this "len" is only used > >> for "raw" access (my own words: any access that doesn't use the HW ECC > >> engine). > > Exactly, 'len' is only for raw access. > >> As a future improvement (no need to update re-send this patch) it > >> would be great to have a #define with a meaningful name for > >> "GENMASK(13, 0)" (maybe something like NFC_CMD_RAW_LENGTH) as it's > >> used in multiple places now > > Ack > > > > Thanks, Arseniy > >> > >> > >> Best regards, > >> Martin Thanks, Miquèl
On 28.03.2023 19:50, Miquel Raynal wrote: > Hi Arseniy, > > avkrasnov@sberdevices.ru wrote on Tue, 28 Mar 2023 18:56:19 +0300: > >> Hello! >> >> @Miquel Raynal, what is the status of this patch? > > Please, it's been 6 days, there is also a maintainer (Liang) in > between, I'm fine with the patch but it was too late to take it as > part of my previous fixes PR. As said earlier today on the mailing list > to Christophe I will make another fixes PR next week (I'll wait for the > current one to be part of the next -rc tag). Thanks for details, sure no problem for PR on the next week! Yes, Liang is a maintainer, but i didn't see any feedbacks from him on my previous fixes for this driver. > > By the way any reason not to have Cc'ed stable? Sorry, what do You mean? I've included linux-mtd mailing lists, there is one more list for mtd reviews? I will appreciate if You can point me Thanks, Arseniy > >> >> Thanks, Arseniy >> >> On 23.03.2023 10:57, Arseniy Krasnov wrote: >>> >>> >>> On 22.03.2023 23:10, Martin Blumenstingl wrote: >>>> Hello Arseniy, >>>> >>>> thank you for submitting this fix! >>> Thanks! >>>> >>>> On Wed, Mar 22, 2023 at 7:45 PM Arseniy Krasnov >>>> <avkrasnov@sberdevices.ru> wrote: >>>>> >>>>> Valid mask is 0x3FFF, without this patch the following problems were >>>>> found: >>>>> >>>>> 1) [ 0.938914] Could not find a valid ONFI parameter page, trying >>>>> bit-wise majority to recover it >>>>> [ 0.947384] ONFI parameter recovery failed, aborting >>>>> >>>>> 2) Read with disabled ECC mode was broken. >>>>> >>>>> Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") >>>>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >>>> This matches what I can see in the old vendor driver, so: >>> Moreover it was clear that mask of 0x3f is too small for length of data in >>> bytes, for example for 2048 + OOB size. >>>> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> >>>> >>>> [...] >>>>> - cmd = (len & GENMASK(5, 0)) | scrambler | DMA_DIR(dir); >>>>> + cmd = (len & GENMASK(13, 0)) | scrambler | DMA_DIR(dir); >>>> My understanding of the vendor driver is that this "len" is only used >>>> for "raw" access (my own words: any access that doesn't use the HW ECC >>>> engine). >>> Exactly, 'len' is only for raw access. >>>> As a future improvement (no need to update re-send this patch) it >>>> would be great to have a #define with a meaningful name for >>>> "GENMASK(13, 0)" (maybe something like NFC_CMD_RAW_LENGTH) as it's >>>> used in multiple places now >>> Ack >>> >>> Thanks, Arseniy >>>> >>>> >>>> Best regards, >>>> Martin > > > Thanks, > Miquèl
Hi Arseniy, On Tue, Mar 28, 2023 at 8:39 PM Arseniy Krasnov <avkrasnov@sberdevices.ru> wrote: [...] > > > > By the way any reason not to have Cc'ed stable? > > Sorry, what do You mean? I've included linux-mtd mailing lists, there is > one more list for mtd reviews? I will appreciate if You can point me "stable" typically refers to the stable tree where fixes for already released kernel versions are maintained. When Miquel applies the patch it will either land in the next -rc of the current development cycle (typically applies to fixes - currently 6.3-rc5) or -rc1 of the next kernel version (typically applies to new features, cleanups, etc. - currently 6.4-rc1). Let's say you are fixing a bug now but want the fix to be included in 6.1 LTS (long term stable) or other stable release. In this case it's recommended to Cc the maintainers of the stable trees as part of your patch, see [0]. That way once the commit with your fix hits Linus Torvalds linux tree it will be backported by the stable team within a few days (assuming of course that the patch applies cleanly to older versions, if not they're notifying you). Note: even without Cc'ing the stable maintainers your commit may be backported (semi-automatically) if it has a Fixes tag and the stable maintainers find your commit. But my understanding is that it's easiest for them if they're explicitly Cc'ed on the patch. I hope this makes sense. If not: don't hesitate to ask. Best regards, Martin [0] https://www.kernel.org/doc/html/v4.15/process/stable-kernel-rules.html#option-1
On 28.03.2023 23:25, Martin Blumenstingl wrote: > Hi Arseniy, > > On Tue, Mar 28, 2023 at 8:39 PM Arseniy Krasnov > <avkrasnov@sberdevices.ru> wrote: > [...] >>> >>> By the way any reason not to have Cc'ed stable? >> >> Sorry, what do You mean? I've included linux-mtd mailing lists, there is >> one more list for mtd reviews? I will appreciate if You can point me > "stable" typically refers to the stable tree where fixes for already > released kernel versions are maintained. > When Miquel applies the patch it will either land in the next -rc of > the current development cycle (typically applies to fixes - currently > 6.3-rc5) or -rc1 of the next kernel version (typically applies to new > features, cleanups, etc. - currently 6.4-rc1). > > Let's say you are fixing a bug now but want the fix to be included in > 6.1 LTS (long term stable) or other stable release. > In this case it's recommended to Cc the maintainers of the stable > trees as part of your patch, see [0]. > That way once the commit with your fix hits Linus Torvalds linux tree > it will be backported by the stable team within a few days (assuming > of course that the patch applies cleanly to older versions, if not > they're notifying you). > Note: even without Cc'ing the stable maintainers your commit may be > backported (semi-automatically) if it has a Fixes tag and the stable > maintainers find your commit. But my understanding is that it's > easiest for them if they're explicitly Cc'ed on the patch. > > I hope this makes sense. If not: don't hesitate to ask. Hello! Thanks for this detailed explanation, that really helps! Thanks, Arseniy > > > Best regards, > Martin > > > [0] https://www.kernel.org/doc/html/v4.15/process/stable-kernel-rules.html#option-1
Hello, avkrasnov@sberdevices.ru wrote on Wed, 29 Mar 2023 10:12:10 +0300: > On 28.03.2023 23:25, Martin Blumenstingl wrote: > > Hi Arseniy, > > > > On Tue, Mar 28, 2023 at 8:39 PM Arseniy Krasnov > > <avkrasnov@sberdevices.ru> wrote: > > [...] > >>> > >>> By the way any reason not to have Cc'ed stable? > >> > >> Sorry, what do You mean? I've included linux-mtd mailing lists, there is > >> one more list for mtd reviews? I will appreciate if You can point me > > "stable" typically refers to the stable tree where fixes for already > > released kernel versions are maintained. > > When Miquel applies the patch it will either land in the next -rc of > > the current development cycle (typically applies to fixes - currently > > 6.3-rc5) or -rc1 of the next kernel version (typically applies to new > > features, cleanups, etc. - currently 6.4-rc1). > > > > Let's say you are fixing a bug now but want the fix to be included in > > 6.1 LTS (long term stable) or other stable release. > > In this case it's recommended to Cc the maintainers of the stable > > trees as part of your patch, see [0]. > > That way once the commit with your fix hits Linus Torvalds linux tree > > it will be backported by the stable team within a few days (assuming > > of course that the patch applies cleanly to older versions, if not > > they're notifying you). > > Note: even without Cc'ing the stable maintainers your commit may be > > backported (semi-automatically) if it has a Fixes tag and the stable > > maintainers find your commit. But my understanding is that it's > > easiest for them if they're explicitly Cc'ed on the patch. > > > > I hope this makes sense. If not: don't hesitate to ask. That is an excellent summary, I should copy/paste it sometimes :) > > Hello! Thanks for this detailed explanation, that really helps! So IOW, I am asking you to send a v2 with an additional line in the commit, right next "Fixes": Cc: stable@vger.kernel.org Thanks, Miquèl
On 29.03.2023 10:31, Miquel Raynal wrote: > Hello, > > avkrasnov@sberdevices.ru wrote on Wed, 29 Mar 2023 10:12:10 +0300: > >> On 28.03.2023 23:25, Martin Blumenstingl wrote: >>> Hi Arseniy, >>> >>> On Tue, Mar 28, 2023 at 8:39 PM Arseniy Krasnov >>> <avkrasnov@sberdevices.ru> wrote: >>> [...] >>>>> >>>>> By the way any reason not to have Cc'ed stable? >>>> >>>> Sorry, what do You mean? I've included linux-mtd mailing lists, there is >>>> one more list for mtd reviews? I will appreciate if You can point me >>> "stable" typically refers to the stable tree where fixes for already >>> released kernel versions are maintained. >>> When Miquel applies the patch it will either land in the next -rc of >>> the current development cycle (typically applies to fixes - currently >>> 6.3-rc5) or -rc1 of the next kernel version (typically applies to new >>> features, cleanups, etc. - currently 6.4-rc1). >>> >>> Let's say you are fixing a bug now but want the fix to be included in >>> 6.1 LTS (long term stable) or other stable release. >>> In this case it's recommended to Cc the maintainers of the stable >>> trees as part of your patch, see [0]. >>> That way once the commit with your fix hits Linus Torvalds linux tree >>> it will be backported by the stable team within a few days (assuming >>> of course that the patch applies cleanly to older versions, if not >>> they're notifying you). >>> Note: even without Cc'ing the stable maintainers your commit may be >>> backported (semi-automatically) if it has a Fixes tag and the stable >>> maintainers find your commit. But my understanding is that it's >>> easiest for them if they're explicitly Cc'ed on the patch. >>> >>> I hope this makes sense. If not: don't hesitate to ask. > > That is an excellent summary, I should copy/paste it sometimes :) > >> >> Hello! Thanks for this detailed explanation, that really helps! > > So IOW, I am asking you to send a v2 with an additional line in the > commit, right next "Fixes": > > Cc: stable@vger.kernel.org Done! Thanks, Arseniy > > Thanks, > Miquèl
On Wed, Mar 29, 2023 at 09:31:45AM +0200, Miquel Raynal wrote: > Hello, > > avkrasnov@sberdevices.ru wrote on Wed, 29 Mar 2023 10:12:10 +0300: > > > On 28.03.2023 23:25, Martin Blumenstingl wrote: > > > Hi Arseniy, > > > > > > On Tue, Mar 28, 2023 at 8:39 PM Arseniy Krasnov > > > <avkrasnov@sberdevices.ru> wrote: > > > [...] > > >>> > > >>> By the way any reason not to have Cc'ed stable? > > >> > > >> Sorry, what do You mean? I've included linux-mtd mailing lists, there is > > >> one more list for mtd reviews? I will appreciate if You can point me > > > "stable" typically refers to the stable tree where fixes for already > > > released kernel versions are maintained. > > > When Miquel applies the patch it will either land in the next -rc of > > > the current development cycle (typically applies to fixes - currently > > > 6.3-rc5) or -rc1 of the next kernel version (typically applies to new > > > features, cleanups, etc. - currently 6.4-rc1). > > > > > > Let's say you are fixing a bug now but want the fix to be included in > > > 6.1 LTS (long term stable) or other stable release. > > > In this case it's recommended to Cc the maintainers of the stable > > > trees as part of your patch, see [0]. > > > That way once the commit with your fix hits Linus Torvalds linux tree > > > it will be backported by the stable team within a few days (assuming > > > of course that the patch applies cleanly to older versions, if not > > > they're notifying you). > > > Note: even without Cc'ing the stable maintainers your commit may be > > > backported (semi-automatically) if it has a Fixes tag and the stable > > > maintainers find your commit. But my understanding is that it's > > > easiest for them if they're explicitly Cc'ed on the patch. > > > > > > I hope this makes sense. If not: don't hesitate to ask. > > That is an excellent summary, I should copy/paste it sometimes :) > Finally I fully understand why 'Fixes' tag is so helpful! Thank you Martin! [...]
On 3/29/23 09:17, Dmitry Rokosov wrote: > On Wed, Mar 29, 2023 at 09:31:45AM +0200, Miquel Raynal wrote: >> Hello, >> >> avkrasnov@sberdevices.ru wrote on Wed, 29 Mar 2023 10:12:10 +0300: >> >>> On 28.03.2023 23:25, Martin Blumenstingl wrote: >>>> Hi Arseniy, >>>> >>>> On Tue, Mar 28, 2023 at 8:39 PM Arseniy Krasnov >>>> <avkrasnov@sberdevices.ru> wrote: >>>> [...] >>>>>> >>>>>> By the way any reason not to have Cc'ed stable? >>>>> >>>>> Sorry, what do You mean? I've included linux-mtd mailing lists, there is >>>>> one more list for mtd reviews? I will appreciate if You can point me >>>> "stable" typically refers to the stable tree where fixes for already >>>> released kernel versions are maintained. >>>> When Miquel applies the patch it will either land in the next -rc of >>>> the current development cycle (typically applies to fixes - currently >>>> 6.3-rc5) or -rc1 of the next kernel version (typically applies to new >>>> features, cleanups, etc. - currently 6.4-rc1). >>>> >>>> Let's say you are fixing a bug now but want the fix to be included in >>>> 6.1 LTS (long term stable) or other stable release. >>>> In this case it's recommended to Cc the maintainers of the stable >>>> trees as part of your patch, see [0]. >>>> That way once the commit with your fix hits Linus Torvalds linux tree >>>> it will be backported by the stable team within a few days (assuming >>>> of course that the patch applies cleanly to older versions, if not >>>> they're notifying you). >>>> Note: even without Cc'ing the stable maintainers your commit may be >>>> backported (semi-automatically) if it has a Fixes tag and the stable >>>> maintainers find your commit. But my understanding is that it's >>>> easiest for them if they're explicitly Cc'ed on the patch. >>>> >>>> I hope this makes sense. If not: don't hesitate to ask. >> >> That is an excellent summary, I should copy/paste it sometimes :) >> > > Finally I fully understand why 'Fixes' tag is so helpful! > Thank you Martin! > Here's the official documentation: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
On Wed, Mar 29, 2023 at 09:20:14AM +0100, Tudor Ambarus wrote: > > > On 3/29/23 09:17, Dmitry Rokosov wrote: > > On Wed, Mar 29, 2023 at 09:31:45AM +0200, Miquel Raynal wrote: > >> Hello, > >> > >> avkrasnov@sberdevices.ru wrote on Wed, 29 Mar 2023 10:12:10 +0300: > >> > >>> On 28.03.2023 23:25, Martin Blumenstingl wrote: > >>>> Hi Arseniy, > >>>> > >>>> On Tue, Mar 28, 2023 at 8:39 PM Arseniy Krasnov > >>>> <avkrasnov@sberdevices.ru> wrote: > >>>> [...] > >>>>>> > >>>>>> By the way any reason not to have Cc'ed stable? > >>>>> > >>>>> Sorry, what do You mean? I've included linux-mtd mailing lists, there is > >>>>> one more list for mtd reviews? I will appreciate if You can point me > >>>> "stable" typically refers to the stable tree where fixes for already > >>>> released kernel versions are maintained. > >>>> When Miquel applies the patch it will either land in the next -rc of > >>>> the current development cycle (typically applies to fixes - currently > >>>> 6.3-rc5) or -rc1 of the next kernel version (typically applies to new > >>>> features, cleanups, etc. - currently 6.4-rc1). > >>>> > >>>> Let's say you are fixing a bug now but want the fix to be included in > >>>> 6.1 LTS (long term stable) or other stable release. > >>>> In this case it's recommended to Cc the maintainers of the stable > >>>> trees as part of your patch, see [0]. > >>>> That way once the commit with your fix hits Linus Torvalds linux tree > >>>> it will be backported by the stable team within a few days (assuming > >>>> of course that the patch applies cleanly to older versions, if not > >>>> they're notifying you). > >>>> Note: even without Cc'ing the stable maintainers your commit may be > >>>> backported (semi-automatically) if it has a Fixes tag and the stable > >>>> maintainers find your commit. But my understanding is that it's > >>>> easiest for them if they're explicitly Cc'ed on the patch. > >>>> > >>>> I hope this makes sense. If not: don't hesitate to ask. > >> > >> That is an excellent summary, I should copy/paste it sometimes :) > >> > > > > Finally I fully understand why 'Fixes' tag is so helpful! > > Thank you Martin! > > > > Here's the official documentation: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html Tudor thank you for suggestion! I don't see anything about Fixes: tag on this page, but looks like 'Submitting patches' tutorial has it: """ A Fixes: tag indicates that the patch fixes an issue in a previous commit. It is used to make it easy to determine where a bug originated, which can help review a bug fix. This tag also assists the stable kernel team in determining which stable kernel versions should receive your fix. This is the preferred method for indicating a bug fixed by the patch. See Describe your changes for more details. """
diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c index a28574c00900..074e14225c06 100644 --- a/drivers/mtd/nand/raw/meson_nand.c +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -280,7 +280,7 @@ static void meson_nfc_cmd_access(struct nand_chip *nand, int raw, bool dir, if (raw) { len = mtd->writesize + mtd->oobsize; - cmd = (len & GENMASK(5, 0)) | scrambler | DMA_DIR(dir); + cmd = (len & GENMASK(13, 0)) | scrambler | DMA_DIR(dir); writel(cmd, nfc->reg_base + NFC_REG_CMD); return; } @@ -544,7 +544,7 @@ static int meson_nfc_read_buf(struct nand_chip *nand, u8 *buf, int len) if (ret) goto out; - cmd = NFC_CMD_N2M | (len & GENMASK(5, 0)); + cmd = NFC_CMD_N2M | (len & GENMASK(13, 0)); writel(cmd, nfc->reg_base + NFC_REG_CMD); meson_nfc_drain_cmd(nfc); @@ -568,7 +568,7 @@ static int meson_nfc_write_buf(struct nand_chip *nand, u8 *buf, int len) if (ret) return ret; - cmd = NFC_CMD_M2N | (len & GENMASK(5, 0)); + cmd = NFC_CMD_M2N | (len & GENMASK(13, 0)); writel(cmd, nfc->reg_base + NFC_REG_CMD); meson_nfc_drain_cmd(nfc);
Valid mask is 0x3FFF, without this patch the following problems were found: 1) [ 0.938914] Could not find a valid ONFI parameter page, trying bit-wise majority to recover it [ 0.947384] ONFI parameter recovery failed, aborting 2) Read with disabled ECC mode was broken. Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> --- drivers/mtd/nand/raw/meson_nand.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)