[U-Boot] [PATCH-OMAP3] OMAP3: Use I2C file coding style

Jean-Christophe PLAGNIOL-VILLARD plagnioj at jcrosoft.com
Sun Nov 9 14:18:43 CET 2008


On 08:38 Sun 09 Nov     , Dirk Behme wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 17:32 Tue 04 Nov     , dirk.behme at googlemail.com wrote:
>>
>>> Subject: [PATCH-OMAP3] OMAP3: Use I2C file coding style
>>>
>>> From: Dirk Behme <dirk.behme at gmail.com>
>>>
>>> Use file coding style for inx/outx instead of global coding style.
>>>
>>> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
>>>
>>> ---
>>>
>>> Note: There was an additional review comment about this file:
>>>
>>> -- cut --
>>>
>>>> +#define inb(a) __raw_readb(a)
>>>> +#define outb(a, v) __raw_writeb(a, v)
>>>> #define inw(a) __raw_readw(a)
>>>> #define outw(a,v) __raw_writew(a,v)
>>>
>>> This 4 macro is supposed to be defined in io.h
>>> -- cut --
>>>
>>> In ARM's io.h there are already inx/outx macros, but with different syntax. The correct fix for omap24xx_i2c.c will be to replace all inx/outx by readx/writex macros and remove above defines. But this can't be done on OMAP3 branch, as it would conflict with "no general coding style clean up in OMAP3 patches, only OMAP3 related changes, please". Thus, we have to do code style changes for this file at mainline once OMAP3 is merged. Until then we have to stay with consistent local style.
>>
>>
>> I desagree,
>>
>> This fix is supposed to be done before appling of the OMAP3 patch set not
>> after.
>>
>> please do not add code which need to fix just after.
>
> Sorry if I misunderstand something here, but it seems to me that this  
> conflicts with
>
> http://lists.denx.de/pipermail/u-boot/2008-November/042975.html
>
> "It is more important to use a consistent style in a single source file, 
> indeed."
>
> ?

As I said this fix need be done on the master branch before merge of the omap3
branch.

>
> Additionally, do you (you == all maintainers and reviewers at this list) 
> accecpt/want to have general (non-OMAP3) coding style clean up in OMAP3 
> patch set? If yes, once we send the resulting OMAP3 patch series from 
> u-boot-arm/omap3 for final merge to U-Boot list again, we will get

you are right no general fix in the omap3 branch only omap fix.

Best Regards,
J.


More information about the U-Boot mailing list