03 Mar, 2011

1 commit


14 Jun, 2010

1 commit

  • Some bogus firmwares include properties with "/" in their name. This
    causes problems when creating the /proc/device-tree file system,
    because the slash is taken to indicate a directory.

    We don't care about those properties, and we don't want to encourage
    them, so just throw them away when creating /proc/device-tree.

    Signed-off-by: Michael Ellerman
    Tested-by: Christian Kujau
    Signed-off-by: Grant Likely

    Michael Ellerman
     

30 Mar, 2010

1 commit

  • …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
     

14 Feb, 2010

1 commit

  • Commit e22f628395432b967f2f505858c64450f7835365 introduced a build
    breakage for ARM devtree work: the THIS_MODULE macro was added, but we
    don't have module.h

    This change adds the necessary #include to get THIS_MODULE defined.
    While we could just replace it with NULL (PROC_FS is a bool, not a
    tristate), using THIS_MODULE will prevent unexpected breakage if we
    ever do compile this as a module.

    Signed-off-by: Jeremy Kerr
    Signed-off-by: Grant Likely
    Acked-by: Benjamin Herrenschmidt
    Acked-by: Michal Simek

    Jeremy Kerr
     

09 Feb, 2010

2 commits

  • Currenly, proc_devtree.c depends on asm/prom.h to include linux/of.h, to
    provide some device-tree definitions (eg, struct property).

    Instead, include linux/of.h directly. We still need asm/prom.h for
    HAVE_ARCH_DEVTREE_FIXUPS.

    Signed-off-by: Jeremy Kerr
    Signed-off-by: Grant Likely

    Jeremy Kerr
     
  • We only need set_node_proc_entry in proc_devtree.c, so move it there.

    This fixes the !HAVE_ARCH_DEVTREE_FIXUPS build, as we can't make make
    the definition in linux/of.h conditional on this #define (definitions in
    asm/prom.h can't be exposed to linux/of.h, due to the enforced #include
    ordering).

    Signed-off-by: Jeremy Kerr
    Signed-off-by: Grant Likely

    Jeremy Kerr
     

30 Oct, 2009

1 commit


19 Jun, 2009

1 commit

  • CHECK fs/proc/proc_devtree.c
    fs/proc/proc_devtree.c:197:14: warning: Using plain integer as NULL pointer
    fs/proc/proc_devtree.c:203:34: warning: Using plain integer as NULL pointer
    fs/proc/proc_devtree.c:210:14: warning: Using plain integer as NULL pointer
    fs/proc/proc_devtree.c:223:26: warning: Using plain integer as NULL pointer
    fs/proc/proc_devtree.c:226:14: warning: Using plain integer as NULL pointer

    Signed-off-by: Michal Simek
    Cc: Alexey Dobriyan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Simek
     

12 Jun, 2009

1 commit


16 Dec, 2008

1 commit


23 Oct, 2008

1 commit


13 Apr, 2007

1 commit


28 Mar, 2006

1 commit

  • Various dodgy firmware might give us nodes and/or properties in the device
    tree with conflicting names. That's generally ok, except for when we export
    the device tree via /proc, so check when we're creating the proc device tree
    and munge names accordingly.

    Tested on a faked device tree with kexec, would be good if someone with
    actual bogus firmware could try it, but just for completeness.

    Signed-off-by: Michael Ellerman
    Signed-off-by: Paul Mackerras

    Michael Ellerman
     

27 Mar, 2006

1 commit

  • It has been discovered that the remove_proc_entry has a race in the removing
    of entries in the proc file system that are siblings. There's no protection
    around the traversing and removing of elements that belong in the same
    subdirectory.

    This subdirectory list is protected in other areas by the BKL. So the BKL was
    at first used to protect this area too, but unfortunately, remove_proc_entry
    may be called with spinlocks held. The BKL may schedule, so this was not a
    solution.

    The final solution was to add a new global spin lock to protect this list,
    called proc_subdir_lock. This lock now protects the list in
    remove_proc_entry, and I also went around looking for other areas that this
    list is modified and added this protection there too. Care must be taken
    since these locations call several functions that may also schedule.

    Since I don't see any location that these functions that modify the
    subdirectory list are called by interrupts, the irqsave/restore versions of
    the spin lock was _not_ used.

    Signed-off-by: Steven Rostedt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Steven Rostedt
     

13 Jan, 2006

1 commit


08 Nov, 2005

1 commit

  • This patch adds the ability to the SMU driver to recover missing
    calibration partitions from the SMU chip itself. It also adds some
    dynamic mecanism to /proc/device-tree so that new properties are visible
    to userland.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Paul Mackerras

    Benjamin Herrenschmidt
     

01 Jun, 2005

1 commit

  • This cleans up the /proc/device-tree representation of the Open Firmware
    device-tree on ppc and ppc64. It does the following things:

    - Workaround an issue in some Apple device-trees where a property may
    exist with the same name as a child node of the parent. We now
    simply "drop" the property instead of creating duplicate entries in
    /proc with random result...

    - Do not try to chop off the "@0" at the end of a node name whose unit
    address is 0. This is not useful, inconsistent, and the code was
    buggy and didn't always work anyway.

    - Do not create symlinks for the short name and unit address parts of a
    node. These were never really used, bloated the memory footprint of
    the device-tree with useless struct proc_dir_entry and their matching
    dentry and inode cache bloat.

    This results in smaller code, smaller memory footprint, and a more
    accurate view of the tree presented to userland.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     

17 Apr, 2005

1 commit

  • 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