[LEDE-DEV] [PATCH] kernel: owl-loader: fix EEPROM size validation for 4KiB EEPROMs
Martin Blumenstingl
martin.blumenstingl at googlemail.com
Wed Oct 5 11:28:46 PDT 2016
Hi Christian,
On Mon, Oct 3, 2016 at 3:34 PM, Christian Lamparter
<chunkeey at googlemail.com> wrote:
> On Monday, October 3, 2016 1:06:18 AM CEST Martin Blumenstingl wrote:
>> The validation of the received EEPROM data uses struct firmware's size
>> field, which contains the size in bytes. ath9k_platform_data's
>> eeprom_data field however is an u16 array with 2048 elements.
>> Using a simple sizeof(pdata->eeprom_data) returns the array size (2048
>> in our case).
> Not according to ISO/IEC 9899:201x (N1570 C11) 6.5.3.4.2 page 90 [0]:
> "The sizeof operator yields the size (in bytes) of its operand, [...]".
>
> so sizeof(pdata->eeprom_data) will return 4096 and not 2048.
> (If it does then the compiler is buggy.)
>
> Just take a look at the FIELD_SIZEOF definition [1] you'll see that it
> also just uses a single sizeof.
> #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
actually you are right, I mixed this up with ARRAY_SIZE.
>> The actual maximum size however is 2048 * sizeof(u16), or
>> in other words 4096 bytes (the kernel's FIELD_SIZEOF macro does the
>> same calculation, but is easier to read).
> Yes, sizeof seems to confuse people (Some think it should do sth. like
> ARRAY_SIZE for arrays). I'm fine with replacing the magic numbers with
> something else. If you want, you can cut the part about 4096 vs 2048
> from the commit message and simply state that the patch introduces
> proper names for the limits (and also change the subject).
sounds like a good idea, I'll respin that patch next weekend
Thanks for the quick feedback!
More information about the Lede-dev
mailing list