David reported that a T5-8 sparc system failed to boot with:

  pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [io  0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff])
  pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff])
  pci 0000:00:01.0: can't claim BAR 15 [mem 0x100000000-0x4afffffff pref]: no compatible bridge window

Note that we don't know about a host bridge aperture that contains
BAR 15.  OF does report a MEM64 aperture, but before this patch,
pci_determine_mem_io_space() ignored it.

Add support for host bridge apertures with 64-bit PCI addresses.  Also
set IORESOURCE_MEM_64 for PCI device and bridge resources in PCI 64-bit
memory space.

Sparc doesn't actually print the device and bridge resources, but after
this patch, we should have the equivalent of this:

  pci_sun4v f02dbcfc: PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [io  0x804000000000-0x80400fffffff] (bus address [0x0000-0xfffffff])
  pci_bus 0000:00: root bus resource [mem 0x800000000000-0x80007effffff] (bus address [0x00000000-0x7effffff])
  pci_bus 0000:00: root bus resource [mem 0x800100000000-0x8007ffffffff] (bus address [0x100000000-0x7ffffffff])
  pci 0000:00:01.0:   bridge window [mem 0x800100000000-0x8004afffffff 64bit pref]

[bhelgaas: changelog, URL to David's report]
Fixes: d63e2e1f ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Link: http://lkml.kernel.org/r/5514391F.2030300@oracle.comReported-by: NDavid Ahern <david.ahern@oracle.com>
Tested-by: NDavid Ahern <david.ahern@oracle.com>
Tested-by: NKhalid Aziz <khalid.aziz@oracle.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Semicolons are not necessary after switch/while/for/if braces
so remove them.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Most of the warnings emitted (we fail arch/sparc file
builds with -Werror) were legitimate but harmless, however
one case (n2_pcr_write) was a genuine bug.

Based almost entirely upon a patch by Sam Ravnborg.
Reported-by: NDennis Gilmore <dennis@ausil.us>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The following structure elements duplicate the information in
'struct device.of_node' and so are being eliminated.  This patch
makes all readers of these elements use device.of_node instead.

(struct of_device *)->node
(struct dev_archdata *)->prom_node (sparc)
(struct dev_archdata *)->of_node (powerpc & microblaze)
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Found by kmemleak.

If request_resource() fails, we leak the struct resource we
allocated to represent the IOMMU mapping area.

This actually happens on sun4v machines because the IOMEM area is only
reported sans the IOMMU region, unlike all previous systems.  I'll
need to fix that at some point, but for now fix the leak.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When you compile kernel on Sparc64 with heap memory checking and type
"cat /proc/iomem", you get a crash, because pointers in struct
resource are uninitialized.

Most code fills struct resource with zeros, so I assume that it is
responsibility of the caller of request_resource to initialized it,
not the responsibility of request_resource functuion.

After 2.6.29 is out, there could be a check for uninitialized fields
added to request_resource to avoid crashes like this.
Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Andrew Morton wrote:

    People keep on doing

            printk("%llu", some_u64);

    testing it only on x86_64 and this generates a warning storm on
    powerpc, sparc64, etc.  Because they use `long', not `long long'.

    Quite a few 64-bit architectures are using `long' for their
    s64/u64 types.  We should convert them all to `long long'.

Update types.h so we use unsigned long long for u64 and
fix all warnings in sparc64 code.
Tested with an allnoconfig, defconfig and allmodconfig builds.

This patch introduces additional warnings in several drivers.
These will be dealt with in separate patches.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

o Move all files from sparc64/kernel/ to sparc/kernel
  - rename as appropriate
o Update sparc/Makefile to the changes
o Update sparc/kernel/Makefile to include the sparc64 files

NOTE: This commit changes link order on sparc64!

Link order had to change for either of sparc32 and sparc64.
And assuming sparc64 see more testing than sparc32 change link
order on sparc64 where issues will be caught faster.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use linux/of_device.h instead.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It just creates confusion, errors, and bugs.

For one thing, this can cause dup sysfs or procfs nodes to get
created:

[    1.198015] proc_dir_entry '00.0' already registered
[    1.198036] Call Trace:
[    1.198052]  [00000000004f2534] create_proc_entry+0x7c/0x98
[    1.198092]  [00000000005719e4] pci_proc_attach_device+0xa4/0xd4
[    1.198126]  [00000000007d991c] pci_proc_init+0x64/0x88
[    1.198158]  [00000000007c62a4] kernel_init+0x190/0x330
[    1.198183]  [0000000000426cf8] kernel_thread+0x38/0x48
[    1.198210]  [00000000006a0d90] rest_init+0x18/0x5c
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the PCI controller lacks the 'ranges' property nothing
is going to work.

Noticed by Al Viro.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The PCI-E slot on T1000 connects directly to the Fire PCI chip with no
intervening bridges visible in the OBP tree.

Unfortunately the bus numbering of the device in that slot is
different (2) from the PCI host controller (0), and thus the
pci_bus_{read,write}_config_*() calls don't work out.

Complicating things further the Fire PCI controller has no config
space it responds to either.

For now treat this case specially so that devices in the slot work.

Longer term we need to perhaps cons up a dummy bridge between the Fire
and the PCI-E slot so that the bus hierarchy is complete inside of the
kernel and thus the bus numbering all works out right.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Don't provide fake PCI config space for sun4u.

Also, put back the funny host controller space handling that
at least Sabre needs.  You have to read PCI host controller
registers at their nature size otherwise you get zeros instead
of correct values.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In pci_determine_mem_io_space(), do not hard code the region sizes.
Instead, use the values given to us in the ranges property.

Thanks goes to Mikael Petterson for the original Xorg failure
bug repoert, and strace dumps from Mikael and Dmitry Artamonow.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

All the sun4u controllers do the same thing to compute the physical
I/O address to poke, and we can move the sun4v code into this common
location too.

This one needs a bit of testing, in particular the Sabre code had some
funny stuff that would break up u16 and/or u32 accesses into pieces
and I didn't think that was needed any more.  If it is we need to find
out why and add back code to do it again.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Everything it contains can be hidden in pci_impl.h
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Namely bus-range and ino-bitmap.

This allows us also to eliminate pci_controller_info's
pci_{first,last}_busno fields as only the pbm ones are
used now.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It is only used in one spot and we can just fetch the
OF property right there.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It can be done for every PCI configuration using OF properties.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Almost entirely taken from the 64-bit PowerPC PCI code.

This allowed to eliminate a ton of cruft from the sparc64
PCI layer.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NFabio Massimo Di Nitto <fabbione@ubuntu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For Hummingbird PCI controllers, we should create the root
PCI memory space resource as the full 4GB area, and then
allocate the IOMMU DMA translation window out of there.

The old code just assumed that the IOMMU DMA translation base
to the top of the 4GB area was unusable.  This is not true on
many systems such as SB100 and SB150, where the IOMMU DMA
translation window sits at 0xc0000000->0xdfffffff.

So what would happen is that any device mapped by the firmware
at the top section 0xe0000000->0xffffffff would get remapped
by Linux somewhere else leading to all kinds of problems and
boot failures.

While we're here, report more cases of OBP resource assignment
conflicts.  The only truly valid ones are ROM resource conflicts.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Do IRQ determination generically by parsing the PROM properties,
and using IRQ controller drivers for final resolution.

One immediate positive effect is that all of the IRQ frobbing
in the EBUS, ISA, and PCI controller layers has been eliminated.
We just look up the of_device and use the properly computed
value.

The PCI controller irq_build() routines are gone and no longer
used.  Unfortunately sbus_build_irq() has to remain as there is
a direct reference to this in the sunzilog driver.  That can be
killed off once the sparc32 side of this is written and the
sunzilog driver is transformed into an "of" bus driver.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

One thing this change pointed out was that we really should
pull the "get 'local-mac-address' property" logic into a helper
function all the network drivers can call.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Allow them to be enabled with "pci=irq_verbose" on the
boot command line.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It can be pushed even further down, but this is a first step.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

this patch converts arch/sparc64 to kzalloc usage.
Crosscompile tested with allyesconfig.
Signed-off-by: NEric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the top-level cnode had multi entries in it's "reg"
property, we'd fail.  The buffer wasn't large enough in
such cases.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The whole algorithm was wrong.  What we need to do is:

1) Walk each PCI bus above this device on the path to the
   PCI controller nexus, and for each:
      a) If interrupt-map exists, apply it, record IRQ controller node
      b) Else, swivel interrupt number using PCI_SLOT(), use PCI bus
	 parent OBP node as controller node
      c) Walk up to "controller node" until we hit the first PCI bus
	 in this domain, or "controller node" is the PCI controller
	 OBP node
2) If we walked to PCI controller OBP node, we're done.
3) Else, apply PCI controller interrupt-map to interrupt.

There is some stuff that needs to be checked out for ebus and
isa, but the PCI part is good to go.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When crawling up the PCI bus chain, stop at the first node
that has an interrupt-map property before we hit the root.

Also, if we use a bus interrupt-{map,mask} do not forget to
update the 'intmask' pointer as we do for the 'intmap' pointer.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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!