From: Igor Grinberg <grinberg@compulab.co.il>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/5] ARM: omap-common: Add standard access for board description EEPROM
Date: Tue, 3 Nov 2015 23:07:08 +0200 [thread overview]
Message-ID: <563921FC.5060602@compulab.co.il> (raw)
In-Reply-To: <5638F2D6.60203@ti.com>
On 11/03/15 19:45, Nishanth Menon wrote:
> On 11/03/2015 11:02 AM, Igor Grinberg wrote:
>
>>>>>> +
>>>>>> +/**
>>>>>> + * board_am_rev_is() - Compare board revision
>>>>>> + * @rev_tag: Revision tag to check in eeprom
>>>>>> + * @cmp_len: How many chars to compare?
>>>>>> + *
>>>>>> + * NOTE: revision information is often messed up (hence the str len
>>>>>> match) :(
>>>>>> + *
>>>>>> + * Return: false if board information does not match OR eeprom
>>>>>> was'nt read.
>>>>>> + * true otherwise
>>>>>> + */
>>>>>> +static inline bool board_am_rev_is(char *rev_tag, int cmp_len)
>>>>>> +{
>>>>>> + struct ti_am_eeprom *ep = TI_AM_EEPROM_DATA;
>>>>>> + int l;
>>>>>> +
>>>>>> + if (ep->header != TI_EEPROM_HEADER_MAGIC)
>>>>>> + return false;
>>>>>> +
>>>>>> + l = cmp_len > TI_EEPROM_HDR_REV_LEN ? TI_EEPROM_HDR_NAME_LEN :
>>>>>> cmp_len;
>>>>>> + return !strncmp(ep->version, rev_tag, l);
>>>>>> +}
>>>>>
>>>>> Same here.
>>>>>
>>>> I thought by making them static inline would save space.
>>>
>>> I prefer that myself as well.
>>
>> I'm not sure I understand what space will it save?
>> AFAIK, inline places the function code inside the the caller function
>> and thus spreads into each caller, no? It probably saves some branches,
>> but how does that save space?
>
> I dont think it saves space, but rather a function call overhead for
> trivial code as above.
I'm sorry, IMO the above code is not trivial enough...
or just it is not trivial: several variables on the stack,
some logic which is not that straight forward for someone who is
not familiar with the code and defines that are mapped into an SRAM...
and we also have strings comparison in the end.
Come on... that is not trivial at all. Moreover it gives a very bad
example to any newcomer...
>
>> Also, AFAIR, we try to not place code inside headers, unless the code
>> is a stub.
>
>
> That does not always make sense. here it is a straight forward
> comparison.. why hide it a function call deep when you can inline it?
Well, at least because header files are not meant to hold code.
Accepting this gives a bad example and reduces code quality...
--
Regards,
Igor.
next prev parent reply other threads:[~2015-11-03 21:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-03 12:22 [U-Boot] [PATCH v2 0/5] ARM: omap-common: Add board detection support for TI EVMs Steve Kipisz
2015-11-03 12:22 ` [U-Boot] [PATCH v2 1/5] ARM: OMAP4/5: Centralize early clock initialization Steve Kipisz
2015-11-03 16:07 ` Tom Rini
2015-11-04 8:32 ` Lokesh Vutla
2015-11-04 14:54 ` Steven Kipisz
2015-11-03 12:22 ` [U-Boot] [PATCH v2 2/5] ARM: OMAP4/5: Centralize gpi2c_init Steve Kipisz
2015-11-03 16:07 ` Tom Rini
2015-11-03 12:22 ` [U-Boot] [PATCH v2 3/5] ARM: omap-common: Add standard access for board description EEPROM Steve Kipisz
2015-11-03 13:16 ` Igor Grinberg
2015-11-03 15:13 ` Steven Kipisz
2015-11-03 15:26 ` Nishanth Menon
2015-11-03 16:07 ` Tom Rini
2015-11-03 16:11 ` Nishanth Menon
2015-11-03 17:02 ` Igor Grinberg
2015-11-03 17:45 ` Nishanth Menon
2015-11-03 21:07 ` Igor Grinberg [this message]
2015-11-03 21:13 ` Nishanth Menon
2015-11-03 12:22 ` [U-Boot] [PATCH v2 4/5] ARM: OMAP4/5: Add generic board detection hook Steve Kipisz
2015-11-03 16:07 ` Tom Rini
2015-11-03 12:22 ` [U-Boot] [PATCH v2 5/5] board: ti: AM57xx: Add detection logic for AM57xx-evm Steve Kipisz
2015-11-03 13:29 ` Igor Grinberg
2015-11-03 15:09 ` Steven Kipisz
2015-11-03 17:04 ` Igor Grinberg
2015-11-03 15:31 ` Nishanth Menon
2015-11-03 15:36 ` Steven Kipisz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=563921FC.5060602@compulab.co.il \
--to=grinberg@compulab.co.il \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox