Eric Lee / smarc-fsl-linux-kernel

29 Apr, 2008

1 commit

  • 74bc7ceeb   dma: add dma_*map*_attrs() interfaces ... Browse Code »

    Introduce new interfaces, dma_*map*_attrs(), for passing architecture-specific
    attributes when memory is mapped and unmapped for DMA. Give the interfaces
    default implementations which ignore attributes. Also introduce the
    dma_{set|get}_attr() interfaces for setting and retrieving individual
    attributes. Define one attribute, DMA_ATTR_WRITE_BARRIER, in anticipation of
    its use by ia64/sn. Select whether architectures implement arch-specific
    versions of the dma_*map*_attrs() interfaces via HAVE_DMA_ATTRS in Kconfig.

    [markn@au1.ibm.com: dma_{set,get}_attr() have to be static inline]
    Signed-off-by: Arthur Kepner
    Cc: Tony Luck
    Cc: Jesse Barnes
    Cc: Jes Sorensen
    Cc: Randy Dunlap
    Cc: Roland Dreier
    Cc: James Bottomley
    Cc: David Miller
    Cc: Benjamin Herrenschmidt
    Cc: Grant Grundler
    Cc: Michael Ellerman
    Signed-off-by: Mark Nelson
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arthur Kepner
     

05 Mar, 2008

1 commit

  • 9edddaa20   Kprobes: indicate kretprobe support in Kconfig ... Browse Code »

    Add CONFIG_HAVE_KRETPROBES to the arch//Kconfig file for relevant
    architectures with kprobes support. This facilitates easy handling of
    in-kernel modules (like samples/kprobes/kretprobe_example.c) that depend on
    kretprobes being present in the kernel.

    Thanks to Sam Ravnborg for helping make the patch more lean.

    Per Mathieu's suggestion, added CONFIG_KRETPROBES and fixed up dependencies.

    Signed-off-by: Ananth N Mavinakayanahalli
    Acked-by: Mathieu Desnoyers
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ananth N Mavinakayanahalli
     

03 Feb, 2008

2 commits

  • 125e56458   Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig ... Browse Code »

    Move the instrumentation Kconfig to

    arch/Kconfig for architecture dependent options
    - oprofile
    - kprobes

    and

    init/Kconfig for architecture independent options
    - profiling
    - markers

    Remove the "Instrumentation Support" menu. Everything moves to "General setup".
    Delete the kernel/Kconfig.instrumentation file.

    Signed-off-by: Mathieu Desnoyers
    Cc: Linus Torvalds
    Cc:
    Signed-off-by: Sam Ravnborg

    Mathieu Desnoyers
     
  • fb32e03fd   Create arch/Kconfig ... Browse Code »

    Puts the content of arch/Kconfig in the "General setup" menu.

    Linus:

    > Should it come with a re-duplication of it's content into each
    > architecture, which was the case previously ? The oprofile and kprobes
    > menu entries were litteraly cut and pasted from one architecture to
    > another. Should we put its content in init/Kconfig then ?

    I don't think it's a good idea to go back to making it per-architecture,
    although that extensive "depends on " might
    indicate that there certainly is room for cleanup there.

    And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I
    just think it's wrong to (a) lump the code together when it really doesn't
    necessarily need to and (b) show it to users as some kind of choice that
    is tied together (whether it then has common code or not).

    On the per-architecture side, I do think it would be better to *not* have
    internal architecture knowledge in a generic file, and as such a line like

    depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32

    really shouldn't exist in a file like kernel/Kconfig.instrumentation.

    It would be much better to do

    depends on ARCH_SUPPORTS_KPROBES

    in that generic file, and then architectures that do support it would just
    have a

    bool ARCH_SUPPORTS_KPROBES
    default y

    in *their* architecture files. That would seem to be much more logical,
    and is readable both for arch maintainers *and* for people who have no
    clue - and don't care - about which architecture is supposed to support
    which interface...

    Sam Ravnborg:

    Stuff it into a new file: arch/Kconfig
    We can then extend this file to include all the 'trailing'
    Kconfig things that are anyway equal for all ARCHs.

    But it should be kept clean - so if we introduce such a file
    then we should use ARCH_HAS_whatever in the arch specific Kconfig
    files to enable stuff that is not shared.

    [...]

    The above suggestion is actually not exactly the best way to do it...
    First the naming..
    A quick grep shows following usage today (in Kconfig files)
    ARCH_HAS 51
    ARCH_SUPPORTS 4
    HAVE_ARCH 7

    ARCH_HAS is the clear winner.

    In the common Kconfig file do:

    config FOO
    depends on ARCH_HAS_FOO
    bool "bla bla"

    config ARCH_HAS_FOO
    def_bool n

    In the arch specific Kconfig file in a suitable place do:

    config SUITABLE_OPTION
    select ARCH_HAS_FOO

    The naming of ARCH_HAS_ is fixed and shall be:
    ARCH_HAS_

    Only a single line added pr. architecture.
    And we will end up with a (maybe even commented) list of trivial selects.

    - Yet another update :

    Moving to HAVE_* now.

    Signed-off-by: Mathieu Desnoyers
    Cc: Jeff Dike
    Cc: David Howells
    Cc: Ananth N Mavinakayanahalli
    Signed-off-by: Sam Ravnborg

    Mathieu Desnoyers