bcm63xx kernel 5.10

[Daniel González Cabanelas]

Hi Florian,

El mar, 8 feb 2022 a las 17:19, Florian Fainelli
(<f.fainelli at gmail.com>) escribió:
>
>
>
> On 2/4/2022 2:57 PM, Florian Fainelli wrote:
> >
> >
> > On 2/4/2022 2:50 PM, Florian Fainelli wrote:
> >>
> >>
> >> On 2/4/2022 2:45 PM, Florian Fainelli wrote:
> >>>
> >>>
> >>> On 2/4/2022 2:34 PM, Daniel González Cabanelas wrote:
> >>>> El vie, 4 feb 2022 a las 23:02, Florian Fainelli
> >>>> (<f.fainelli at gmail.com>) escribió:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2/4/2022 11:21 AM, Álvaro Fernández Rojas wrote:
> >>>>>> So the problem is that SET_FEATURES and GET_FEATURES isn’t
> >>>>>> supported by versions 2.1, 2.2 and 4.0 of the nand controller,
> >>>>>> which are the ones present on bcm63xx, right?
> >>>>>
> >>>>> Yes, I suspect this is the problem since I do not see CMD_LOW_LEVEL_OP
> >>>>> being defined in the register database for the controllers v2.1 and
> >>>>> v2.2, v3.3. Staring with v4.0, the controllers do have the
> >>>>> CMD_LOW_LEVEL_OP. This is the version/feature table that I could
> >>>>> programmatically compile:
> >>>>>
> >>>>> version: 0.1, ll: no
> >>>>> version: 1.0, ll: no
> >>>>> version: 2.0, ll: no
> >>>>> version: 2.1, ll: no
> >>>>> version: 2.2, ll: no
> >>>>> version: 3.0, ll: no
> >>>>> version: 3.2, ll: no
> >>>>> version: 3.3, ll: no
> >>>>> version: 3.4, ll: no
> >>>>> version: 4.0, ll: yes
> >>>>> version: 5.0, ll: yes
> >>>>> version: 6.0, ll: yes
> >>>>> version: 6.2, ll: yes
> >>>>> version: 7.0, ll: yes
> >>>>> version: 7.1, ll: yes
> >>>>> version: 7.2, ll: yes
> >>>>> version: 7.3, ll: yes
> >>>>>
> >>>>> How about this patch, does it work better?
> >>>>>
> >>>>> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >>>>> b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >>>>> index f75929783b94..06ac593beec0 100644
> >>>>> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >>>>> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> >>>>> @@ -1727,6 +1727,8 @@ static void brcmnand_cmdfunc(struct nand_chip
> >>>>> *chip, unsigned command,
> >>>>>                   break;
> >>>>>           case NAND_CMD_SET_FEATURES:
> >>>>>           case NAND_CMD_GET_FEATURES:
> >>>>> +               if (ctrl->nand_version < 0x0400)
> >>>>> +                       break;
> >>>>>                   brcmnand_low_level_op(host, LL_OP_CMD, command,
> >>>>> false);
> >>>>>                   brcmnand_low_level_op(host, LL_OP_ADDR, column,
> >>>>> false);
> >>>>>                   break;
> >>>>>
> >>>>> --
> >>>>> Florian
> >>>>
> >>>> No, it didn't help:
> >>>
> >>> OK, last tentative and then I think you should report this to
> >>> linux-mtd such that the MTD maintainers may suggest whether we are
> >>> missing something obvious here:
> >>
> >> scratch that, can you try this instead:
> >
> > And also try this patch because I don't believe there is sufficient
> > protection in macronix_nand_block_protection_support to ensure that the
> > NAND chip is ONFI capable:
>
> Could you try this patch?
>
> >
> > diff --git a/drivers/mtd/nand/raw/nand_macronix.c
> > b/drivers/mtd/nand/raw/nand_macronix.c
> > index 1472f925f386..78f893add636 100644
> > --- a/drivers/mtd/nand/raw/nand_macronix.c
> > +++ b/drivers/mtd/nand/raw/nand_macronix.c
> > @@ -219,9 +219,13 @@ static int mxic_nand_unlock(struct nand_chip *chip,
> > loff_t ofs, uint64_t len)
> >
> >   static void macronix_nand_block_protection_support(struct nand_chip
> > *chip)
> >   {
> > +       struct nand_parameters *p = &chip->parameters;
> >          u8 feature[ONFI_SUBFEATURE_PARAM_LEN];
> >          int ret;
> >
> > +       if (!p->onfi || !chip->parameters.supports_set_get_features)
> > +               return;
> > +
> >          bitmap_set(chip->parameters.get_feature_list,
> >                     ONFI_FEATURE_ADDR_MXIC_PROTECTION, 1);
> >
> > Thanks!
>
> --
> Florian

I re-tested it again, it didn't work.

Regards