On Wed, 24 Oct 2012 14:21:20 -0700 Tom Rini trini@ti.com wrote:
On Thu, Oct 18, 2012 at 09:53:36AM -0700, Tom Rini wrote:
On Tue, Oct 16, 2012 at 07:28:16PM -0500, Kim Phillips wrote:
This 32-patch series only begins to address making u-boot source more 'sparseable,' or sparse-clean, ultimately to catch type, address space, and endianness mismatches and generally improve code quality. E.g., in this initial dose whose main purpose is to reduce the output volume to workable levels, a couple of endianness bugs are found and fixed in of_bus_default_translate() and fdt_get_base_address(). See [PATCH 14/32] common/fdt_support.c: sparse fixes.
Patch 1 adds endianness attributes to byteorder.h helpers, e.g., cpu_to_be32(). This is required for correct operation and prevents sparse from emitting false-positives.
Patches 2-6 fix issues where u-boot had imported linux header code and the importer simply force-#defined sparse-specific attributes to nothing, to allow u-boot to build.
Patches 7-10 are general sparse fixes to common header areas.
Patch 11 is too, which also changes the long-standing u-boot image header types to __be32, as per u-boot image definition.
Patches 12-14 address further misc. sparse issues in common/.
Patches 15-16 do the same for the net subsystem.
Patches 17-18 do the same for lib/.
Patch 19 for include/fdt.h.
Patches 20-23 for Power Arch's mpc8xxx, 83xx, and 85xx subsystems.
I've assigned in patchwork some of these patches to the area custodians, once reviewed please hand them back to me. For the rest of the series, I'm giving things a read and review.
To this end I'm preparing to merge some of these patches today. However, even cutting out a number of patches with changes requested already I'm seeing various failures on MAKEALL --arch arm. I'll let you know at what point I stop taking the patches in and what the error is.
I was going to resubmit the whole series after I'd re-done the libfdt ones to suit the dtc and the kernel libfdt copies, but patches 1 through 6 are the most important. Whether I tangled things up in my rebases, sure, there might be issues; I just wanted to partition by importance and subsystem, so the subsystem maintainers can ack/apply freely (as one did).
I will definitely re-submit 14 and 19, and run checkpatch over any others you don't end up applying. I'm just caught up doing other stuff right now...
Kim