Eric Lee / smarc-fsl-linux-kernel

22 May, 2010

2 commits

  • cf9b59e9d   Merge remote branch 'origin' into secretlab/next-devicetree ... Browse Code »

    Merging in current state of Linus' tree to deal with merge conflicts and
    build failures in vio.c after merge.

    Conflicts:
    drivers/i2c/busses/i2c-cpm.c
    drivers/i2c/busses/i2c-mpc.c
    drivers/net/gianfar.c

    Also fixed up one line in arch/powerpc/kernel/vio.c to use the
    correct node pointer.

    Signed-off-by: Grant Likely

    Grant Likely
     
  • 4018294b5   of: Remove duplicate fields from of_platform_driver ... Browse Code »

    .name, .match_table and .owner are duplicated in both of_platform_driver
    and device_driver. This patch is a removes the extra copies from struct
    of_platform_driver and converts all users to the device_driver members.

    This patch is a pretty mechanical change. The usage model doesn't change
    and if any drivers have been missed, or if anything has been fixed up
    incorrectly, then it will fail with a compile time error, and the fixup
    will be trivial. This patch looks big and scary because it touches so
    many files, but it should be pretty safe.

    Signed-off-by: Grant Likely
    Acked-by: Sean MacLennan

    Grant Likely
     

19 May, 2010

1 commit

01 May, 2010

1 commit

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

22 Mar, 2010

1 commit

13 Mar, 2010

5 commits

  • 8004fd2ad   edac: e752x: add dram scrubbing support ... Browse Code »

    Add support to scrub DRAM using the e752x integrated memory scrubbing
    engine. The e7320/7520/e7525 chipsets support scrubbing at one rate while
    the i3100 chipset supports a normal and fast rate.

    A similar patch was originally sent back in 2008:
    http://sourceforge.net/mailarchive/forum.php?thread_name=1204835866.25206.70.camel@localhost.localdomain&forum_name=bluesmoke-devel

    This version has the following updates:
    - Use 16-bit PCI config cycles to access MCHSCRB register
    e7320/7520/e7525 docs say register is 16bits wide, i3100 says 8. I
    tested 16bits on the i3100 to be safe.
    - Recalcuate and round actual scrub rates

    The changes have been tested on an i3100-based board.

    Signed-off-by: Peter Tyser
    Signed-off-by: Doug Thompson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Tyser
     
  • 8de5c1a16   edac: e752x fsb ecc ... Browse Code »

    FSB parity is only supported on the Xeon processor. Previously it was
    incorrectly enabled for the Celeron as well.

    Signed-off-by: Konstantin Olifer
    Signed-off-by: Doug Thompson
    Cc: Peter Tyser
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Konstantin Olifer
     
  • 66ed3f751   edac: mpc85xx use resource_size instead of raw math ... Browse Code »

    Use resource_size() instead of arithmetic.

    Signed-off-by: H Hartley Sweeten
    Signed-off-by: Doug Thompson
    Acked-by: Dave Jiang
    Cc: Peter Tyser
    Cc: Kumar Gala
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    H Hartley Sweeten
     
  • dcca7c3d0   edac: mpc85xx improve SDRAM error reporting ... Browse Code »

    Add the ability to detect the specific data line or ECC line which failed
    when printing out SDRAM single-bit errors. An example of a single-bit
    SDRAM ECC error is below:

    EDAC MPC85xx MC1: Err Detect Register: 0x80000004
    EDAC MPC85xx MC1: Faulty data bit: 59
    EDAC MPC85xx MC1: Expected Data / ECC: 0x7f80d000_409effa0 / 0x6d
    EDAC MPC85xx MC1: Captured Data / ECC: 0x7780d000_409effa0 / 0x6d
    EDAC MPC85xx MC1: Err addr: 0x00031ca0
    EDAC MPC85xx MC1: PFN: 0x00000031

    Knowning which specific data or ECC line caused an error can be useful in
    tracking down hardware issues such as improperly terminated signals, loose
    pins, etc.

    Note that this feature is only currently enabled for 64-bit wide data
    buses, 32-bit wide bus support should be added.

    I don't have any 32-bit wide systems to test on. If someone has one and
    is willing to give this patch a shot with the check for a 64-bit data bus
    removed it would be much appreciated and I can re-submit with both 32 and
    64 bit buses supported.

    Signed-off-by: Peter Tyser
    Signed-off-by: Doug Thompson
    Cc: Kumar Gala
    Cc: Dave Jiang
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Tyser
     
  • 21768639b   edac: mpc85xx mask ecc syndrome correctly ... Browse Code »

    With a 64-bit wide data bus only the lowest 8-bits of the ECC syndrome are
    relevant. With a 32-bit wide data bus only the lowest 16-bits are
    relevant on most architectures.

    Without this change, the ECC syndrome displayed can be mildly confusing,
    eg:

    EDAC MPC85xx MC1: syndrome: 0x25252525

    When in reality the ECC syndrome is 0x25.

    A variety of Freescale manuals say a variety of different things about how
    to decode the CAPTURE_ECC (syndrome) register. I don't have a system with
    a 32-bit bus to test on, but I believe the change is correct. It'd be
    good to get an ACK from someone at Freescale about this change though.

    Signed-off-by: Peter Tyser
    Signed-off-by: Doug Thompson
    Cc: Kumar Gala
    Cc: Dave Jiang
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Tyser
     

08 Mar, 2010

1 commit

  • 52cf25d0a   Driver core: Constify struct sysfs_ops in struct kobj_type ... Browse Code »

    Constify struct sysfs_ops.

    This is part of the ops structure constification
    effort started by Arjan van de Ven et al.

    Benefits of this constification:

    * prevents modification of data that is shared
    (referenced) by many other structure instances
    at runtime

    * detects/prevents accidental (but not intentional)
    modification attempts on archs that enforce
    read-only kernel data at runtime

    * potentially better optimized code as the compiler
    can assume that the const data cannot be changed

    * the compiler/linker move const data into .rodata
    and therefore exclude them from false sharing

    Signed-off-by: Emese Revfy
    Acked-by: David Teigland
    Acked-by: Matt Domsch
    Acked-by: Maciej Sosnowski
    Acked-by: Hans J. Koch
    Acked-by: Pekka Enberg
    Acked-by: Jens Axboe
    Acked-by: Stephen Hemminger
    Signed-off-by: Greg Kroah-Hartman

    Emese Revfy
     

04 Mar, 2010

1 commit

03 Mar, 2010

1 commit

  • 0a135ba14   Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu ... Browse Code »

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
    percpu: add __percpu sparse annotations to what's left
    percpu: add __percpu sparse annotations to fs
    percpu: add __percpu sparse annotations to core kernel subsystems
    local_t: Remove leftover local.h
    this_cpu: Remove pageset_notifier
    this_cpu: Page allocator conversion
    percpu, x86: Generic inc / dec percpu instructions
    local_t: Move local.h include to ringbuffer.c and ring_buffer_benchmark.c
    module: Use this_cpu_xx to dynamically allocate counters
    local_t: Remove cpu_local_xx macros
    percpu: refactor the code in pcpu_[de]populate_chunk()
    percpu: remove compile warnings caused by __verify_pcpu_ptr()
    percpu: make accessors check for percpu pointer in sparse
    percpu: add __percpu for sparse.
    percpu: make access macros universal
    percpu: remove per_cpu__ prefix.

    Linus Torvalds
     

02 Mar, 2010

1 commit

  • d95cf4de6   amd64_edac: Simplify ECC override handling ... Browse Code »

    No need for clearing ecc_enable_override and checking it in two places.
    Instead, simply check it during probing and act accordingly. Also,
    rename the flag bitfields according to the functionality they actually
    represent. What is more, make sure original BIOS ECC settings are
    restored when the module is unloaded.

    Signed-off-by: Borislav Petkov

    Borislav Petkov
     

17 Feb, 2010

1 commit

  • a29d8b8e2   percpu: add __percpu sparse annotations to what's left ... Browse Code »

    Add __percpu sparse annotations to places which didn't make it in one
    of the previous patches. All converions are trivial.

    These annotations are to make sparse consider percpu variables to be
    in a different address space and warn if accessed without going
    through percpu accessors. This patch doesn't affect normal builds.

    Signed-off-by: Tejun Heo
    Acked-by: Borislav Petkov
    Cc: Dan Williams
    Cc: Huang Ying
    Cc: Len Brown
    Cc: Neil Brown

    Tejun Heo
     

12 Feb, 2010

4 commits

  • 676ad5855   Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp ... Browse Code »

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp:
    amd64_edac: Do not falsely trigger kerneloops

    Linus Torvalds
     
  • f8c63345b   edac: mpc85xx fix build regression by removing unused debug code ... Browse Code »

    Some unused, unsupported debug code existed in the mpc85xx EDAC driver
    that resulted in a build failure when CONFIG_EDAC_DEBUG was defined:

    drivers/edac/mpc85xx_edac.c: In function 'mpc85xx_mc_err_probe':
    drivers/edac/mpc85xx_edac.c:1031: error: implicit declaration of function 'edac_mc_register_mcidev_debug'
    drivers/edac/mpc85xx_edac.c:1031: error: 'debug_attr' undeclared (first use in this function)
    drivers/edac/mpc85xx_edac.c:1031: error: (Each undeclared identifier is reported only once
    drivers/edac/mpc85xx_edac.c:1031: error: for each function it appears in.)

    Signed-off-by: Peter Tyser
    Signed-off-by: Doug Thompson
    Signed-off-by: Linus Torvalds

    Peter Tyser
     
  • cff9279e4   edac: mpc85xx fix bad page calculation ... Browse Code »

    Commit b4846251727a38a7f248e41308c060995371dd05 ("edac: mpc85xx add
    mpc83xx support") accidentally broke how a chip select's first and last
    page addresses are calculated. The page addresses are being shifted too
    far right by PAGE_SHIFT. This results in errors such as:

    EDAC MPC85xx MC1: Err addr: 0x003075c0
    EDAC MPC85xx MC1: PFN: 0x00000307
    EDAC MPC85xx MC1: PFN out of range!
    EDAC MC1: INTERNAL ERROR: row out of range (4 >= 4)
    EDAC MC1: CE - no information available: INTERNAL ERROR

    The vaule of PAGE_SHIFT is already being taken into consideration during
    the calculation of the 'start' and 'end' variables, thus it is not
    necessary to account for it again when setting a chip select's first and
    last page address.

    Signed-off-by: Peter Tyser
    Signed-off-by: Doug Thompson
    Cc: Ira W. Snyder
    Cc: Kumar Gala
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Tyser
     
  • cab4d2776   amd64_edac: Do not falsely trigger kerneloops ... Browse Code »

    An unfortunate "WARNING" in the message amd64_edac dumps when the system
    doesn't support DRAM ECC or ECC checking is not enabled in the BIOS
    used to trigger kerneloops which qualified the message as an OOPS thus
    misleading the users. See, e.g.

    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/422536
    http://bugzilla.kernel.org/show_bug.cgi?id=15238

    Downgrade the message level to KERN_NOTICE and fix the formulation.

    Cc: stable@kernel.org # .32.x
    Signed-off-by: Borislav Petkov
    Acked-by: Doug Thompson

    Borislav Petkov
     

17 Jan, 2010

1 commit

  • 118f3e1af   edac: i5000_edac critical fix panic out of bounds ... Browse Code »

    EDAC MC0: INTERNAL ERROR: channel-b out of range (4 >= 4)
    Kernel panic - not syncing: EDAC MC0: Uncorrected Error (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.

    This happens because FERR_NF_FBD bit 28 is not updated on i5000. Due to
    that, both bits 28 and 29 may be equal to one, returning channel = 3. As
    this value is invalid, EDAC core generates the panic.

    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14568

    Signed-off-by: Tamas Vincze
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Doug Thompson
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tamas Vincze
     

15 Jan, 2010

1 commit

24 Dec, 2009

6 commits

17 Dec, 2009

2 commits

16 Dec, 2009

3 commits

  • bbead2104   edac: i5100 add 6 ranks per channel ... Browse Code »

    Add support for 6 ranks per channel to the i5100 chipset. I have tested
    the patch as far as possible with correctible errors and things appear
    good. The DIMM mapping is correct for our board, but boards may differ.

    Signed-off-by: Nils Carlson
    Acked-by: Arthur Jones
    Signed-off-by: Doug Thompson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nils Carlson
     
  • 295439f2a   edac: i5100 add scrubbing ... Browse Code »

    Addscrubbing to the i5100 chipset. The i5100 chipset only supports one
    scrubbing rate, which is not constant but dependent on memory load. The
    rate returned by this driver is an estimate based on some experimentation,
    but is substantially closer to the truth than the speed supplied in the
    documentation.

    Also, scrubbing is done once, and then a done-bit is set. This means that
    to accomplish continuous scrubbing a re-enabling mechanism must be used.
    I have created the simplest possible such mechanism in the form of a
    work-queue which will check every five minutes. This interval is quite
    arbitrary but should be sufficient for all sizes of system memory.

    Signed-off-by: Nils Carlson
    Signed-off-by: Doug Thompson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nils Carlson
     
  • b18dfd05f   edac: i5100 clean controller to channel terms ... Browse Code »

    The i5100 driver uses the word controller instead of channel in a lot of
    places, this is simply a cleanup of the patch.

    Signed-off-by: Nils Carlson
    Signed-off-by: Doug Thompson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nils Carlson
     

15 Dec, 2009

1 commit

12 Dec, 2009

1 commit

  • 505422517   x86, msr: Add support for non-contiguous cpumasks ... Browse Code »

    The current rd/wrmsr_on_cpus helpers assume that the supplied
    cpumasks are contiguous. However, there are machines out there
    like some K8 multinode Opterons which have a non-contiguous core
    enumeration on each node (e.g. cores 0,2 on node 0 instead of 0,1), see
    http://www.gossamer-threads.com/lists/linux/kernel/1160268.

    This patch fixes out-of-bounds writes (see URL above) by adding per-CPU
    msr structs which are used on the respective cores.

    Additionally, two helpers, msrs_{alloc,free}, are provided for use by
    the callers of the MSR accessors.

    Cc: H. Peter Anvin
    Cc: Mauro Carvalho Chehab
    Cc: Aristeu Rozanski
    Cc: Randy Dunlap
    Cc: Doug Thompson
    Signed-off-by: Borislav Petkov
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Borislav Petkov
     

08 Dec, 2009

5 commits