Eric Lee / smarc-fsl-linux-kernel

27 Oct, 2010

1 commit

  • 3e4d3af50   mm: stack based kmap_atomic() ... Browse Code »
    44

    Keep the current interface but ignore the KM_type and use a stack based
    approach.

    The advantage is that we get rid of crappy code like:

    #define __KM_PTE \
    (in_nmi() ? KM_NMI_PTE : \
    in_irq() ? KM_IRQ_PTE : \
    KM_PTE0)

    and in general can stop worrying about what context we're in and what kmap
    slots might be appropriate for that.

    The downside is that FRV kmap_atomic() gets more expensive.

    For now we use a CPP trick suggested by Andrew:

    #define kmap_atomic(page, args...) __kmap_atomic(page)

    to avoid having to touch all kmap_atomic() users in a single patch.

    [ not compiled on:
    - mn10300: the arch doesn't actually build with highmem to begin with ]

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c]
    Acked-by: Rik van Riel
    Signed-off-by: Peter Zijlstra
    Acked-by: Chris Metcalf
    Cc: David Howells
    Cc: Hugh Dickins
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Cc: Steven Rostedt
    Cc: Russell King
    Cc: Ralf Baechle
    Cc: David Miller
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: Dave Airlie
    Cc: Li Zefan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Zijlstra
     

30 Mar, 2010

2 commits

  • 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
     
  • f7454c5d5   frv/chris: fix lines with a missing semicolons ... Browse Code »

    Commit b26b2d494b659f9 ("resource/PCI: align functions now return start
    of resource") added lines with missing semicolons.

    Add the missing semicolons to the FRV and CRIS arch code.

    Signed-off-by: David Howells
    Cc: linux@dominikbrodowski.net
    Signed-off-by: Linus Torvalds

    David Howells
     

25 Mar, 2010

1 commit

13 Mar, 2010

1 commit

  • 027491f4b   dma-mapping: frv: remove the obsolete and unnecessary DMA API comments ... Browse Code »

    pci_dma_sync_single was obsoleted long ago.

    All the comments are generic, not architecture specific, simply describes
    some of the DMA-API (and frv has the same comments in three files).
    Documentation/DMA-API.txt have more detailed descriptions.

    This removes the above obsolete and unnecessary DMA API comments. Let's
    describe the DMA API in only Documentation/DMA-API.txt.

    Signed-off-by: FUJITA Tomonori
    Cc: David Howells
    Cc: Jesse Barnes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     

23 Feb, 2010

2 commits

25 Sep, 2009

1 commit

10 Sep, 2009

1 commit

12 Jun, 2009

1 commit

22 Apr, 2009

1 commit

  • 77e38a554   frv: insert PCI root bus resources for the MB93090 devel motherboard ... Browse Code »

    Insert PCI root bus resources for the FRV-based MB93090 development kit
    motherboard. This is required because the CPU's window onto the PCI bus
    address space is considerably smaller than the CPU's full address space
    and non-PCI devices lie outside of the PCI window that we might want to
    access.

    Without this patch, the PCI root bus uses the platform-level bus
    resources, and these are then confined to the PCI window, thus making
    platform_device_add() reject devices outside of this window.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

17 Oct, 2008

2 commits

  • c9af956cf   FRV: Provide dma_map_page() for NOMMU and fix comments ... Browse Code »

    Provide dma_map_page() for the NOMMU-mode FRV arch.

    Also do some fixing on the comments attached to the various DMA functions for
    both MMU and NOMMU mode FRV code.

    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     
  • 9bd8f9c63   frv: use generic pci_enable_resources() ... Browse Code »

    Use the generic pci_enable_resources() instead of the arch-specific code.

    Unlike this arch-specific code, the generic version:
    - checks PCI_NUM_RESOURCES (11), not 6, resources
    - skips resources that have neither IORESOURCE_IO nor IORESOURCE_MEM set
    - skips ROM resources unless IORESOURCE_ROM_ENABLE is set
    - checks for resource collisions with "!r->parent"

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: David Howells
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

28 Jun, 2008

1 commit

  • 0aea53132   PCI: remove unused arch pcibios_update_resource() functions ... Browse Code »

    Russell King did the following back in 2003:

    [PCI] pci-9: Kill per-architecture pcibios_update_resource()

    Kill pcibios_update_resource(), replacing it with pci_update_resource().
    pci_update_resource() uses pcibios_resource_to_bus() to convert a
    resource to a device BAR - the transformation should be exactly the
    same as the transformation used for the PCI bridges.

    pci_update_resource "knows" about 64-bit BARs, but doesn't attempt to
    set the high 32-bits to anything non-zero - currently no architecture
    attempts to do something different. If anyone cares, please fix; I'm
    going to reflect current behaviour for the time being.

    Ivan pointed out the following architectures need to examine their
    pcibios_update_resource() implementation - they should make sure that
    this new implementation does the right thing. #warning's have been
    added where appropriate.

    ia64
    mips
    mips64

    This cset also includes a fix for the problem reported by AKPM where
    64-bit arch compilers complain about the resource mask being placed
    in a u32.

    This patch removes the unused pcibios_update_resource() functions the
    kernel gained since, from FRV, m68k, mips & sh architectures.

    Signed-off-by: Adrian Bunk
    Acked-by: David Howells
    Acked-by: Greg Ungerer
    Acked-by: Paul Mundt
    Acked-by: Ralf Baechle
    Signed-off-by: Jesse Barnes

    Adrian Bunk
     

07 Jun, 2008

1 commit

29 Apr, 2008

1 commit

  • b70d3a2c5   iomap: fix 64 bits resources on 32 bits ... Browse Code »

    Almost all implementations of pci_iomap() in the kernel, including the generic
    lib/iomap.c one, copies the content of a struct resource into unsigned long's
    which will break on 32 bits platforms with 64 bits resources.

    This fixes all definitions of pci_iomap() to use resource_size_t. I also
    "fixed" the 64bits arch for consistency.

    Signed-off-by: Benjamin Herrenschmidt
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     

21 Apr, 2008

2 commits

  • 6355f3d1c   PCI: remove pcibios_fixup_ghosts() ... Browse Code »

    This function was obviously never being used since early 2.5 days as any
    device that it would try to remove would never really be removed from
    the system due to the PCI device list being held in the driver core, not
    the general list of PCI devices.

    As we have not had a single report of a problem here in 4 years, I think
    it's safe to remove now.

    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • 1ba6ab11d   PCI: remove initial bios sort of PCI devices on x86 ... Browse Code »

    We currently keep 2 lists of PCI devices in the system, one in the
    driver core, and one all on its own. This second list is sorted at boot
    time, in "BIOS" order, to try to remain compatible with older kernels
    (2.2 and earlier days). There was also a "nosort" option to turn this
    sorting off, to remain compatible with even older kernel versions, but
    that just ends up being what we have been doing from 2.5 days...

    Unfortunately, the second list of devices is not really ever used to
    determine the probing order of PCI devices or drivers[1]. That is done
    using the driver core list instead. This change happened back in the
    early 2.5 days.

    Relying on BIOS ording for the binding of drivers to specific device
    names is problematic for many reasons, and userspace tools like udev
    exist to properly name devices in a persistant manner if that is needed,
    no reliance on the BIOS is needed.

    Matt Domsch and others at Dell noticed this back in 2006, and added a
    boot option to sort the PCI device lists (both of them) in a
    breadth-first manner to help remain compatible with the 2.4 order, if
    needed for any reason. This option is not going away, as some systems
    rely on them.

    This patch removes the sorting of the internal PCI device list in "BIOS"
    mode, as it's not needed at all anymore, and hasn't for many years.
    I've also removed the PCI flags for this from some other arches that for
    some reason defined them, but never used them.

    This should not change the ordering of any drivers or device probing.

    [1] The old-style pci_get_device and pci_find_device() still used this
    sorting order, but there are very few drivers that use these functions,
    as they are deprecated for use in this manner. If for some reason, a
    driver rely on the order and uses these functions, the breadth-first
    boot option will resolve any problem.

    Cc: Matt Domsch
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

28 Oct, 2007

1 commit

02 Aug, 2007

1 commit

29 Mar, 2007

1 commit

  • bba6f6fc6   [PATCH] MSI-X: fix resume crash ... Browse Code »

    So I think the right solution is to simply make pci_enable_device just
    flip enable bits and move the rest of the work someplace else.

    However a thorough cleanup is a little extreme for this point in the
    release cycle, so I think a quick hack that makes the code not stomp the
    irq when msi irq's are enabled should be the first fix. Then we can
    later make the code not change the irqs at all.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Ingo Molnar
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

26 Sep, 2006

1 commit

11 Jul, 2006

1 commit

  • 9dec17eb5   [PATCH] FRV: Fix FRV arch compile errors ... Browse Code »

    Fix some FRV arch compile errors, including:

    (*) Marking nr_kernel_pages as __meminitdata so that references to it end up
    being properly calculated rather than being assumed to be in the small
    data section (and thus calculated wrt the GP register). Not doing this
    causes the linker to emit errors as the offset is too big to fit into the
    load instruction.

    (*) Move pm_power_off into an unconditionally compiled .c file as it's now
    unconditionally accessed.

    (*) Declare frv_change_cmode() in a header file rather than in a .c file, and
    declare it asmlinkage.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

01 Jul, 2006

1 commit

28 Jun, 2006

1 commit

23 Jun, 2006

1 commit

10 Jan, 2006

2 commits

09 Jan, 2006

2 commits

29 Nov, 2005

1 commit

  • 8080f2312   [PATCH] FRV: Make the FRV arch work again ... Browse Code »

    The attached patch implements a bunch of small changes to the FRV arch to
    make it work again.

    It deals with the following problems:

    (1) SEM_DEBUG should be SEMAPHORE_DEBUG.

    (2) The argument list to pcibios_penalize_isa_irq() has changed.

    (3) CONFIG_HIGHMEM can't be used directly in #if as it may not be defined.

    (4) page->private is no longer directly accessible.

    (5) linux/hardirq.h assumes asm/hardirq.h will include linux/irq.h

    (6) The IDE MMIO access functions are given pointers, not integers, and so
    get type casting errors.

    (7) __pa() is passed an explicit u64 type in drivers/char/mem.c, but that
    can't be cast directly to a pointer on a 32-bit platform.

    (8) SEMAPHORE_DEBUG should not be contingent on WAITQUEUE_DEBUG as that no
    longer exists.

    (9) PREEMPT_ACTIVE is too low a value.

    Signed-off-by: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

28 Oct, 2005

1 commit

12 Jul, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds