Hi List,

This has probably come up before but I did a quick search and couldn't find anything. If it exists please point me at it.

So at $dayjob we're looking at adding support for the BCM5718 Ethernet chipset to u-boot. We've actually got things working and I'm looking at preparing the code for submission.

Naturally I'm getting a bunch of checkpatch errors that I need to work through. And I wonder how this type of porting _should_ be done?

Some of the checkpatch errors things that exist in the upstream kernel. Others are because of subtle differences in the internal apis between linux an u-boot. For example pci_read_config_word() under u-boot takes a pci_dev_t (usually these are declared deviceno) as it's first argument while under linux it takes a struct pci_dev* (usually called pdev). Because of the difference in naming there are a bunch of lines >80 chars. Obviously I could fix this by changing deviceno to pdev but I actually think that'd be more confusing.

Then there's also code that won't be used under u-boot (e.g. firmware loading, smp, locking). Some of this we've deleted other parts we've #if 0'd out. This is mostly because 2 poeple were doing the work and made arbitrary choices. I personally think the latter is better because it makes taking fixes from Linux easier but is that something we actually should care about?

I think I've seen one instance on this mailing list of taking the Linux code verbatim as patch 1/2 then the porting/cleanup as patch 2/2. This seems like a good idea but it may still lose the ability to take fixes.

Any comments/suggestions?

Thanks, Chris