Stefano,
many thanks.
This will be a hard challenge for me to obey to the rules :-)
The 80 character thing is reported from checkpatch.pl as WARNING, not as
ERROR - so there will be a chance of the patch to become accepted by a
custodian.
In between i tried to reformat by Code to obey to these rules, but now
checkpatch.pl tells me following:
WARNING: Avoid unnecessary line continuations
#531: FILE: board/BuR/bur_tseries/board.c:155:
+ if (tps65217_voltage_update(TPS65217_DEFDCDC3, \
in real life the code section looks like this:
/* Set DCDC3 (CORE) voltage to 1.125V */
if (tps65217_voltage_update(TPS65217_DEFDCDC3, \
TPS65217_DCDC_VOLT_SEL_1125MV)) {
puts("tps65217_voltage_update failure\n");
return;
}
If i don't do the line break at line 155 checkpatch.pl is disturbing me
with the 80 character rule.
Another thing is linewrapping of output strings, to obey to the rules i
have to format the string as following:
if (i2c_probe(TPS65217_CHIP_PM)) {
printf("PMIC chip (0x%02x) not present! skipping" \
"further configuration.\n", TPS65217_CHIP_PM);
return;
}
But this makes it impossible to grep the code in case of an error.
Any idea how to deal with such things ?
best regards,
Hannes
Stefano Babic wrote:
> Hi Hannes,
>
> On 04/02/2014 13:50, Hannes Petermaier wrote:
>> Hello,
>>
>> I've read on the U-Boot website about coding style. They say 'All
>> contributions to U-Boot should conform to the Linux kernel coding
>> style'.
>> Further i've read this link and there are at least 2 things which i have
>> troubles with.
>>
>> 1)
>> a tab-ident is 8 spaces
>
> Right
>
>> (in eclipse for example with the built in K&R has
>> 4 characters). With 8 characters per TAB the problem from point 2 enters
>> very, very fast.
>>
>> 2)
>> a line ist limited to 80 characters (maybe thus comes from very old days
>> where displays couldn't show more than this and scrolling was very
>> expensive). is this state of the art ?
>
> Yes, it is. Same rule as in kernel.
>
>>
>> In fact i've found a lot of files within the u-boot code which do not
>> obey
>> to this rules.
>
> I cannot tell for each exceptions you found. Maybe the code is very old,
> and it slipped into mainline without fixing the lenght. There are also
> some well-known exception (generally for tables), where a longer line
> was accepted after discussion in the ML to increase readability.
> (tables for pinmux, as example
> arch/arm/include/asm/arch-mx6/mx6dl_pins.h).
>
>>
>> Now my question is, how strong are this two points ?
>
> They are strong until there is a general acceptance on the ML to drop
> the rule. However, the rule was already discussed in the past (you can
> dig deep in archives), and the result was to maintain it, exactly as it
> is valid for linux.
>
>
>> checkpatch.pl rails against a patch file with a lot of warnings if there
>> is a line longer than 80bytes, also it takes TABS as 8 spaces.
>
> checkpatch is run before merging a patch into a merge tree by
> custodians. If checkpatch reports errors, they must be fixed.
>
>>
>> whats your opinion about this ?
>>
>> Last question:
>> Is this mailing list the right place of discussing such things ?
>>
>
> I think you are in the right place to discuss these topics ;-)
>
> Best regards,
> Stefano Babic
>
> --
> =====================================================================
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =====================================================================
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
