[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29f4cff4-edc5-3838-2495-253e794178ae@microchip.com>
Date: Thu, 28 Jul 2022 13:31:01 +0000
From: <Tudor.Ambarus@...rochip.com>
To: <michael@...le.cc>
CC: <p.yadav@...com>, <miquel.raynal@...tlin.com>, <richard@....at>,
<vigneshr@...com>, <quic_c_sbhanu@...cinc.com>,
<linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] mtd: spi-nor: introduce SNOR_ID3()
On 7/28/22 16:12, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>>>> +#define SNOR_ID3(_jedec_id)
>>
>> How about SFDP_ID3 and SFDP_ID6 instead?
>
> Yes, probably a better name. I was also thinking about splitting
> the id in vendor, device and additional bytes. But I haven't
> thought of the actual implementation that much. Such as:
>
> #define SFDP_ID(<u8 vid>, <u16 did>, <variable aux bytes>)
> #define SFDP_ID_FULL(<num_continuation_code>, <u8 vid>, <u16 did>,
> <variable aux bytes>)
>
> Couldn't make up a better name than that _FULL for now. Happy to hear
> suggestions :)
>
You mean splitting the ID in manufacturer ID, flash ID and extended flash ID?
I'd like to understand the benefits of splitting this, can you give me an
example? In the past I though about introducing some flash info macros for
families of flashes of the same vendor, it will reduce the number of lines
on flash definition, but not really related.
--
Cheers,
ta
Powered by blists - more mailing lists