linux-kernel - Re: [PATCH 1/2] mtd: spi-nor: introduce SNOR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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