The only real user of this file outside platforms/iseries was
drivers/net/iseries_veth.c but all it wanted was ISERIES_HV_ADDR()
so we move that to abs_addr.h (and lowercase it).
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
This patch pulls the PCI-related junk out of struct device_node and
puts it in a separate structure, struct pci_dn. The device_node now
just has a void * pointer in it, which points to a struct pci_dn for
nodes that represent PCI devices. It could potentially be used in
future for device-specific data for other sorts of devices, such as
virtual I/O devices.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch updates the format of the flattened device-tree passed
between the boot trampoline and the kernel to support a more compact
representation, for use by embedded systems mostly.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
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!
Stephen Rothwell