23 Jul, 2011

1 commit

  • With a non-constant 8-bit argument, a call to udelay() generates a warning:

    drivers/gpu/drm/radeon/atom.c: In function 'atom_op_delay':
    drivers/gpu/drm/radeon/atom.c:654: warning: comparison is always false due to limited range of data type

    The code looks like it works OK with an 8-bit arg, and the calling code is
    doing nothing wrong, so udelay() needs fixing.

    Fixing it was rather tricky. Simply typecasting `n' in the comparison with
    20000 didn't change anything. Hence the divide-by-20000 trick.

    Using a do{}while loop didn't work because udelay() is used in ?: statements,
    hence the ({...}) construct.

    While I was there I replaced the brain-bending ?:?:?: mess with nice if/else
    code.

    Probably other architectures are generating the same warning and can use a
    similar change.

    [Taken from the x86 tree and moved to asm-generic by Jonas Bonn]

    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Jonas Bonn

    Andrew Morton
     

08 Jul, 2011

1 commit

  • Several architectures are using a common delay.h implementation that
    appears to have originated with the x86 architecture. This common
    implementation is a bit fuller than the current asm-generic version
    and has some compile-time checks that should be interesting for all
    architectures.

    This patch takes the common delay.h version and replaces the rather
    trivial asm-generic version with it. As no architecture was actually
    using asm-generic/delay.h, this change is rather innocuous; it will,
    however, allow us to switch at least four architectures over to using
    the asm-generic version.

    Signed-off-by: Jonas Bonn
    Acked-by: Arnd Bergmann

    Jonas Bonn
     

12 Jun, 2009

1 commit

  • These are all kernel internal interfaces that get copied
    around a lot. In most cases, architectures can provide
    their own optimized versions, but these generic versions
    can work as well.

    I have tried to use the most common contents of each
    header to allow existing architectures to migrate easily.

    Thanks to Remis for suggesting a number of cleanups.

    Signed-off-by: Remis Lima Baima
    Signed-off-by: Arnd Bergmann

    Arnd Bergmann