diff mbox series

[v1] mtd: rawnand: meson: fix bitmask for length in command word

Message ID d4338bd5-125c-a9e7-cb46-6f5e1da05cfa@sberdevices.ru (mailing list archive)
State Superseded
Headers show
Series [v1] mtd: rawnand: meson: fix bitmask for length in command word | expand

Commit Message

Arseniy Krasnov March 22, 2023, 6:42 p.m. UTC
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(-)

Comments

Martin Blumenstingl March 22, 2023, 8:10 p.m. UTC | #1
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
Arseniy Krasnov March 23, 2023, 7:57 a.m. UTC | #2
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
Arseniy Krasnov March 28, 2023, 3:56 p.m. UTC | #3
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
Miquel Raynal March 28, 2023, 4:50 p.m. UTC | #4
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
Arseniy Krasnov March 28, 2023, 6:36 p.m. UTC | #5
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
Martin Blumenstingl March 28, 2023, 8:25 p.m. UTC | #6
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
Arseniy Krasnov March 29, 2023, 7:12 a.m. UTC | #7
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
Miquel Raynal March 29, 2023, 7:31 a.m. UTC | #8
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
Arseniy Krasnov March 29, 2023, 7:48 a.m. UTC | #9
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
Dmitry Rokosov March 29, 2023, 8:17 a.m. UTC | #10
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!

[...]
Tudor Ambarus March 29, 2023, 8:20 a.m. UTC | #11
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
Dmitry Rokosov March 29, 2023, 9:55 a.m. UTC | #12
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 mbox series

Patch

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);