On Thu, Apr 25, 2013 at 1:56 AM, Huang Shijie <b32...@freescale.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<b32...@freescale.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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
