linux-kernel - Re: [PATCH V3 6/9] mtd: add a new field for ecc info in the nand_flash

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, 25 Apr 2013 23:15:18 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	Huang Shijie <b32955@...escale.com>
Cc:	dwmw2@...radead.org, dedekind1@...il.com,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 6/9] mtd: add a new field for ecc info in the nand_flash_dev{}

On Thu, Apr 25, 2013 at 1:56 AM, Huang Shijie <b32955@...escale.com> wrote:
> 于 2013年04月25日 14:57, Brian Norris 写道:
>
>>
>> A bit late on this one, but is there a good reason this wasn't just 2
>> separate 16-bit fields? We already have a few, and I don't see why
>> this couldn't be the same.
>>
> I just want to make the ecc_strength/ecc_size more coupled for the
> nand_flash_dev{}.
> If we spilit to two fields. It makes the nand_flash_ids[] less readable.

Sure, that's a decent reason. But how about as an instance of an
anonymous struct instead? See my suggestion below.

>>> Signed-off-by: Huang Shijie<b32955@...escale.com>
>>> ---
>>>   include/linux/mtd/nand.h |   10 ++++++++++
>>>   1 files changed, 10 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
>>> index 063e517..f4c7777 100644
>>> --- a/include/linux/mtd/nand.h
>>> +++ b/include/linux/mtd/nand.h
>>> @@ -624,6 +624,10 @@ struct nand_chip {
>>>          { .name = (nm), {{ .dev_id = (devid) }}, .chipsize = (chipsz), \
>>>            .options = (opts) }
>>>
>>> +#define NAND_ECC_INFO(strength, size)  (((strength)<<  16) | (size))
>>
>> We could redefine this:
>>
>> #define NAND_ECC_INFO(strength, size) .ecc_strength = (strength),
>> .ecc_size = (size)
>
> Do this type of macro could be accepted by the kernel?

Something like this should be acceptable, I think, if I can straighten
it out so that it compiles right (!)

> I think your macro needs a pair of bracket, such as:
> #define NAND_ECC_INFO(strength, size) (.ecc_strength = (strength), .ecc_size
> = (size))
>
> But if we add the brackets, we will meet a compiler error.

Here's my modification (note the underscores, since we can't have the
field .strength in the same macro as the "parameter" strength):

#define ECC_INFO(_strength, _size)        { .strength = (_strength),
.size = (_size) }
#define ECC_STRENGTH(type)              ((type)->ecc.strength)
#define ECC_SIZE(type)                  ((type)->ecc.strength)

And replace the field in nand_flash_dev with:

        struct {
                uint16_t strength;
                uint16_t size;
        } ecc;

How does that look? It's actually quite similar to the construct Artem
used with mfr_id and dev_id, except that we give the struct a name.
And this time, it actually compiles!

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/