[U-Boot] [PATCH 2/5] e1000: Restructure and streamline PCI device probing

[Moffett, Kyle D]

On Apr 12, 2011, at 16:17, Wolfgang Denk wrote:
> In message <1297467482-14864-3-git-send-email-Kyle.D.Moffett at boeing.com> you wrote:
>> By allocating the e1000 device structures much earlier, we can easily
>> generate better error messages and siginficantly clean things up.
>> 
>> The only user-visable change (aside from reworded error messages) is
>> that a detected e1000 device which fails to initialize due to software
>> or hardware error will still be allocated a device number.
>> 
>> As one example, consider a system with 2 e1000 PCI devices where the
>> first controller has a corrupted EEPROM.  Using the old code the
>> second controller would be "e1000#0", while with this change it would be
>> "e1000#1".
>> 
>> This change should hopefully make such EEPROM errors much more
>> straightforward to handle correctly in boot scripts and the like.
>> 
>> It is also necessary for a followup patch which allows SPI programming
>> of an e1000 controller's EEPROM even if the checksum is invalid.
> 
> This patch has a number of overlong lines.  Please globally fix the
> line length.

The only lines longer than 80 characters in this patch are these 4 when
indented by 3 levels:
> hw->hw_addr = pci_map_bar(devno, PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
> printf("%s: ERROR: Can't enable I/O memory\n", nic->name);
> printf("%s: ERROR: Can't enable bus-mastering\n", nic->name);
> printf("%s: ERROR: EEPROM checksum is bad!\n", nic->name);

According to Documentation/CodingStyle:
> Statements longer than 80 columns will be broken into sensible chunks.
> Descendants are always substantially shorter than the parent and are placed
> substantially to the right. The same applies to function headers with a long
> argument list. Long strings are as well broken into shorter strings. The
> only exception to this is where exceeding 80 columns significantly increases
> readability and does not hide information.


Wrapping any of those lines will in fact make them much harder to read and
dissimilar to the other nearly identical printf() calls in that piece of
code; I strongly disagree that it is necessary.

Cheers,
Kyle Moffett