summaryrefslogtreecommitdiffstats
path: root/fs/proc/proc_devtree.c
AgeCommit message (Collapse)AuthorFilesLines
2006-03-28[PATCH] powerpc: Cope with duplicate node & property names in /proc/device-treeMichael Ellerman1-23/+80
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 <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-26[PATCH] protect remove_proc_entrySteven Rostedt1-0/+2
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 <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-13[PATCH] powerpc: Add/remove/update properties in /proc/device-treeDave C Boutcher1-0/+24
Add support to the proc_device_tree file for removing and updating properties. Remove just removes the proc file, update changes the data pointer within the proc file. The remainder of the device-tree changes occur elsewhere. Signed-off-by: Dave Boutcher <sleddog@us.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-08[PATCH] ppc64: SMU partition recoveryBenjamin Herrenschmidt1-22/+35
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 <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-06-01[PATCH] ppc32/ppc64: cleanup /proc/device-treeBenjamin Herrenschmidt1-67/+38
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 <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+165
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!