Re: [PATCH v2 3/3] mtd: dataflash: Make use of "extened device information"

[Marek Vasut]

On 04/19/2017 05:07 PM, Andrey Smirnov wrote:
> On Wed, Apr 19, 2017 at 1:47 AM, Marek Vasut <marek.vasut@xxxxxxxxx> wrote:
>> On 04/19/2017 04:58 AM, Andrey Smirnov wrote:
>>> On Tue, Apr 18, 2017 at 11:31 AM, Marek Vasut <marek.vasut@xxxxxxxxx> wrote:
>>>> On 04/18/2017 04:21 PM, Andrey Smirnov wrote:
>>>>> In anticipation of supporting chips that need it, extend the size of
>>>>> struct flash_info's 'jedec_id' field to make room 2 byte of extended
>>>>> device information as well as add code to fetch this data during
>>>>> jedec_probe().
>>>>>
>>>>> Cc: cphealy@xxxxxxxxx
>>>>> Cc: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
>>>>> Cc: Brian Norris <computersforpeace@xxxxxxxxx>
>>>>> Cc: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx>
>>>>> Cc: Marek Vasut <marek.vasut@xxxxxxxxx>
>>>>> Cc: Richard Weinberger <richard@xxxxxx>
>>>>> Cc: Cyrille Pitchen <cyrille.pitchen@xxxxxxxxx>
>>>>> Cc: linux-kernel@xxxxxxxxxxxxxxx
>>>>> Signed-off-by: Andrey Smirnov <andrew.smirnov@xxxxxxxxx>
>>>>> ---
>>>>>
>>>>> Changes since [v1]:
>>>>>
>>>>>       - Formatting
>>>>>
>>>>> [v1] http://lkml.kernel.org/r/20170411161722.11164-1-andrew.smirnov@xxxxxxxxx
>>>>>
>>>>>
>>>>>  drivers/mtd/devices/mtd_dataflash.c | 113 +++++++++++++++++++++---------------
>>>>>  1 file changed, 65 insertions(+), 48 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mtd/devices/mtd_dataflash.c b/drivers/mtd/devices/mtd_dataflash.c
>>>>> index 5b7a8c3..5d694a4 100644
>>>>> --- a/drivers/mtd/devices/mtd_dataflash.c
>>>>> +++ b/drivers/mtd/devices/mtd_dataflash.c
>>>>> @@ -690,7 +690,7 @@ struct flash_info {
>>>>>       /* JEDEC id has a high byte of zero plus three data bytes:
>>>>>        * the manufacturer id, then a two byte device id.
>>>>>        */
>>>>> -     u32             jedec_id;
>>>>> +     u64             jedec_id;
>>>>>
>>>>>       /* The size listed here is what works with OP_ERASE_PAGE. */
>>>>>       unsigned        nr_pages;
>>>>> @@ -713,63 +713,34 @@ static struct flash_info dataflash_data[] = {
>>>>>        * These newer chips also support 128-byte security registers (with
>>>>>        * 64 bytes one-time-programmable) and software write-protection.
>>>>>        */
>>>>> -     { "AT45DB011B",  0x1f2200, 512, 264, 9, SUP_POW2PS},
>>>>> -     { "at45db011d",  0x1f2200, 512, 256, 8, SUP_POW2PS | IS_POW2PS},
>>>>> +     { "AT45DB011B",  0x1f22000000, 512, 264, 9, SUP_POW2PS},
>>>>> +     { "at45db011d",  0x1f22000000, 512, 256, 8, SUP_POW2PS | IS_POW2PS},
>>>>>
>>>>> -     { "AT45DB021B",  0x1f2300, 1024, 264, 9, SUP_POW2PS},
>>>>> -     { "at45db021d",  0x1f2300, 1024, 256, 8, SUP_POW2PS | IS_POW2PS},
>>>>> +     { "AT45DB021B",  0x1f23000000, 1024, 264, 9, SUP_POW2PS},
>>>>> +     { "at45db021d",  0x1f23000000, 1024, 256, 8, SUP_POW2PS | IS_POW2PS},
>>>>>
>>>>> -     { "AT45DB041x",  0x1f2400, 2048, 264, 9, SUP_POW2PS},
>>>>> -     { "at45db041d",  0x1f2400, 2048, 256, 8, SUP_POW2PS | IS_POW2PS},
>>>>> +     { "AT45DB041x",  0x1f24000000, 2048, 264, 9, SUP_POW2PS},
>>>>> +     { "at45db041d",  0x1f24000000, 2048, 256, 8, SUP_POW2PS | IS_POW2PS},
>>>>>
>>>>> -     { "AT45DB081B",  0x1f2500, 4096, 264, 9, SUP_POW2PS},
>>>>> -     { "at45db081d",  0x1f2500, 4096, 256, 8, SUP_POW2PS | IS_POW2PS},
>>>>> +     { "AT45DB081B",  0x1f25000000, 4096, 264, 9, SUP_POW2PS},
>>>>> +     { "at45db081d",  0x1f25000000, 4096, 256, 8, SUP_POW2PS | IS_POW2PS},
>>>>>
>>>>> -     { "AT45DB161x",  0x1f2600, 4096, 528, 10, SUP_POW2PS},
>>>>> -     { "at45db161d",  0x1f2600, 4096, 512, 9, SUP_POW2PS | IS_POW2PS},
>>>>> +     { "AT45DB161x",  0x1f26000000, 4096, 528, 10, SUP_POW2PS},
>>>>> +     { "at45db161d",  0x1f26000000, 4096, 512, 9, SUP_POW2PS | IS_POW2PS},
>>>>>
>>>>> -     { "AT45DB321x",  0x1f2700, 8192, 528, 10, 0},           /* rev C */
>>>>> +     { "AT45DB321x",  0x1f27000000, 8192, 528, 10, 0},       /* rev C */
>>>>>
>>>>> -     { "AT45DB321x",  0x1f2701, 8192, 528, 10, SUP_POW2PS},
>>>>> -     { "at45db321d",  0x1f2701, 8192, 512, 9, SUP_POW2PS | IS_POW2PS},
>>>>> +     { "AT45DB321x",  0x1f27010000, 8192, 528, 10, SUP_POW2PS},
>>>>> +     { "at45db321d",  0x1f27010000, 8192, 512, 9, SUP_POW2PS | IS_POW2PS},
>>>>>
>>>>> -     { "AT45DB642x",  0x1f2800, 8192, 1056, 11, SUP_POW2PS},
>>>>> -     { "at45db642d",  0x1f2800, 8192, 1024, 10, SUP_POW2PS | IS_POW2PS},
>>>>> +     { "AT45DB642x",  0x1f28000000, 8192, 1056, 11, SUP_POW2PS},
>>>>> +     { "at45db642d",  0x1f28000000, 8192, 1024, 10, SUP_POW2PS | IS_POW2PS},
>>>>>  };
>>>>>
>>>>> -static struct flash_info *jedec_probe(struct spi_device *spi)
>>>>> +static struct flash_info *jedec_lookup(struct spi_device *spi, u64 jedec)
>>>>>  {
>>>>> -     int ret, i;
>>>>> -     u8 code = OP_READ_ID;
>>>>> -     u8 id[3];
>>>>> -     u32 jedec;
>>>>> +     int status, i;
>>>>>       struct flash_info *info;
>>>>> -     int status;
>>>>> -
>>>>> -     /*
>>>>> -      * JEDEC also defines an optional "extended device information"
>>>>> -      * string for after vendor-specific data, after the three bytes
>>>>> -      * we use here.  Supporting some chips might require using it.
>>>>> -      *
>>>>> -      * If the vendor ID isn't Atmel's (0x1f), assume this call failed.
>>>>> -      * That's not an error; only rev C and newer chips handle it, and
>>>>> -      * only Atmel sells these chips.
>>>>> -      */
>>>>> -     ret = spi_write_then_read(spi, &code, 1, id, 3);
>>>>> -     if (ret < 0) {
>>>>> -             pr_debug("%s: error %d reading JEDEC ID\n",
>>>>> -                     dev_name(&spi->dev), ret);
>>>>> -             return ERR_PTR(ret);
>>>>> -     }
>>>>> -
>>>>> -     if (id[0] != CFI_MFR_ATMEL)
>>>>> -             return NULL;
>>>>> -
>>>>> -     jedec = id[0];
>>>>> -     jedec = jedec << 8;
>>>>> -     jedec |= id[1];
>>>>> -     jedec = jedec << 8;
>>>>> -     jedec |= id[2];
>>>>
>>>> Hm, the diff again screwed this up, oh well ...
>>>>
>>>>>       for (i = 0, info = dataflash_data;
>>>>>                       i < ARRAY_SIZE(dataflash_data);
>>>>> @@ -799,12 +770,58 @@ static struct flash_info *jedec_probe(struct spi_device *spi)
>>>>>               }
>>>>>       }
>>>>>
>>>>> +     return NULL;
>>>>> +}
>>>>> +
>>>>> +static struct flash_info *jedec_probe(struct spi_device *spi)
>>>>> +{
>>>>> +     int ret;
>>>>> +     u8 code = OP_READ_ID;
>>>>> +     u8 id[8] = {0};
>>>>> +     const unsigned int id_size = 5;
>>>>> +     const unsigned int first_byte = sizeof(id) - id_size;
>>>>> +     const u64 eid_mask = GENMASK_ULL(63, 16);
>>>>> +     u64 jedec;
>>>>> +     struct flash_info *info;
>>>>> +
>>>>> +     /*
>>>>> +      * JEDEC also defines an optional "extended device information"
>>>>> +      * string for after vendor-specific data, after the three bytes
>>>>> +      * we use here.  Supporting some chips might require using it.
>>>>> +      *
>>>>> +      * If the vendor ID isn't Atmel's (0x1f), assume this call failed.
>>>>> +      * That's not an error; only rev C and newer chips handle it, and
>>>>> +      * only Atmel sells these chips.
>>>>> +      */
>>>>> +     ret = spi_write_then_read(spi, &code, 1, &id[first_byte], id_size);
>>>>> +     if (ret < 0) {
>>>>> +             pr_debug("%s: error %d reading JEDEC ID\n",
>>>>> +                     dev_name(&spi->dev), ret);
>>>>
>>>> I think you can turn this into:
>>>>
>>>> dev_err(&spi->dev, "error %d reading JEDEC ID\n", ret);
>>>
>>> OK, will do it in a separate patch, since this is original code.
>>
>> OK
>>
>>>>> +             return ERR_PTR(ret);
>>>>> +     }
>>>>> +
>>>>> +     if (id[first_byte] != CFI_MFR_ATMEL)
>>>>> +             return NULL;
>>>>> +
>>>>> +     jedec = be64_to_cpup((__be64 *)id);
>>>>> +
>>>>> +     info = jedec_lookup(spi, jedec);
>>>>> +     if (info)
>>>>> +             return info;
>>>>> +
>>>>> +     /* Clear extended id bits and try to find a match again */
>>>>> +     jedec &= eid_mask;
>>>>
>>>> Wouldn't that be jedec &= ~eid_mask; (with a tilde) if you want to clear
>>>> them ?
>>>
>>> eid_mask is generated as bits 63 to 16 with GENMASK_ULL, so bits 15 to
>>> 0 should already be zeroed out. I can rename it to eid_mask_inverted
>>> so it's less confusing.
>>
>> I think that's a good idea and you can make the mask u32 instead of u64.
>> But isn't eid_mask_inverted the same as id_mask ?
> 
> I just realized that "eid_mask" is used only in one place and I don't
> gain anything by having that variable, so I think what I'd do is use
> GENMASK in-place, then it should be clear why there's no bit inversion
> and there's no dilemma on how to name the variable.

The upside of defining mask as a macro is that you can derive the
meaning of the macro from it's name . If you use ad-hoc constant in the
code, you cannot do that. And there might be spots in the code which
will re-use that macro in the future.

-- 
Best regards,
Marek Vasut