As suggested by Linus, align functions should return the start
of a resource, not void. An update of "res->start" is no longer
necessary.

Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Mirrors powerpc commits bb209c82
("powerpc/pci: Add calls to set_pcie_port_type() and set_pcie_hotplug_bridge()")
and 26b4a0ca
("powerpc/pci: Add missing hookup to pci_slot")

We also need to initialize ->dma_mask explicitly here too.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Exporting an inline function breaks the new assembler-based alphabetical
sorted symbol list.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

sparc64 is now the only user of PCI_CACHE_LINE_BYTES.  Drop it and set
pci_dfl_cache_line_size from pcibios_init() instead and drop
PCI_CACHE_LINE_BYTES handling from generic pci code.

Orignally-From: David Miller <davem@davemloft.net>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This converts SPARC to use asm-generic/pci-dma-compat instead
of the homegrown mechnism.

SPARC32 has two dma_map_ops structures for pci and sbus
(removing arch/sparc/kernel/dma.c, PCI and SBUS DMA accessor).
The global 'dma_ops' is set to sbus_dma_ops and get_dma_ops()
returns pci32_dma_ops for pci devices so we can use the
appropriate dma mapping operations.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Tested-by: NRobert Reif <reif@earthlink.net>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Cc: tony.luck@intel.com
Cc: fenghua.yu@intel.com
LKML-Reference: <1249872797-1314-8-git-send-email-fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

This function was only used by pci_claim_resource(), and the last commit
deleted that use.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Move all applicable EXPORT_SYMBOL()s to the file where the respective
symbol is defined.

Removed all the includes that are no longer needed in sparc_ksyms_64.c

Comment all remaining EXPORT_SYMBOL()s in sparc_ksyms_64.c
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>

Additions by Julian Calaby:
* Moved EXPORT_SYMBOL()s for prom functions to their rightful places.
* Made some minor cleanups to the includes and comments of sparc_ksyms_64.c
* Updated and tidied commit message.
* Rebased patch over sparc-2.6.git HEAD.
* Ensured that all modified files have the correct includes.
Signed-off-by: NJulian Calaby <julian.calaby@gmail.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>

There is a problem discovered in recent versions of ATI Mach64 driver
in X.org on sparc64 architecture. In short, the driver fails to mmap
MMIO aperture (PCI resource #2).

I've found that kernel's __pci_mmap_make_offset() returns EINVAL. It
checks whether user attempts to mmap more than the resource length,
which is 0x1000 bytes in our case. But PAGE_SIZE on SPARC64 is 0x2000
and this is what actually is being mmaped. So __pci_mmap_make_offset()
failed for this PCI resource.
Signed-off-by: NMax Dmitrichenko <dmitrmax@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Just like in the arch/sparc64/kernel/of_device.c code fix commit
071d7f4c3b411beae08d27656e958070c43b78b4 ("sparc64: Fix SMP bootup
with CONFIG_STACK_DEBUG or ftrace.") we have to check the OF device
node name for "pci" instead of relying upon the 'device_type' property
being there on all PCI bridges.

Tested by Meelis Roos, and confirmed to make the PCI QFE devices
reappear on the E3500 system.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

1) Declare pci_poke_* in pci_impl.h
2) of_create_pci_dev() should be static
3) ->setup_msi_irq() wants an unsigned int pointer not a plain
   int one
4) void value expression return in arch_teardown_msi_irq()
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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

It is just used as a parent to encapsulate two PBM objects.

But that layout is only really relevant and necessary for
psycho PCI controllers, which unlike all the others share
a single IOMMU instance between sibling PCI busses.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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

And now all the by-hand PCI controller probing junk in pci.c can die too.
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>

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

The idea is to convert all of the PCI controller drivers into
genuine OF drivers, then we can get rid of this terrible probing
table and infrastructure in arch/sparc64/kernel/pci.c
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

That's just silly, use device_initcall() instead.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

All that remains is the EBUS DMA programming library for
sparc64.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In order to convert EBUS drivers doing DMA into pure OF drivers,
we need the of_device->dev.archdata setup properly.

EBUS instances that can provide DMA for device nodes sit on PCI,
so detect and propagate the information there.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This also allows arch/sparc64/kernel/pci.c to be properly CONFIG_PCI
conditional compiled in the Makefile.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This converts all instances of bus_id in the sparc core kernel to use
either dev_set_name(), or dev_name() depending on the need.

This is done in anticipation of removing the bus_id field from struct
driver.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Also fixes up the sparc code that was assuming this is not a constant.
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

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>

No more drivers use this, and therefore it can die.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Record and propagate NUMA information for devices.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

And also it's helper function pci_is_controller().  Both
are unused.

I can't remove the equivalent from sparc32 yet as some
ancient bus probing code still uses that platform's version.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This makes libpciaccess able to mmap() resources of the
device properly.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAlejandro Martinez Ruiz <alex@flawedcode.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It is totally unnecessary as the needed information is properly
encoded in the resources.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On the root PCI bus, the OBP device tree lists device 3 twice.
Once as 'pm' and once as 'lomp'.

Everything goes downhill from there.

Ignore the second instance to workaround this.

Thanks to Kövedi_Krisztián for the bug report and
testing the fix.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

1) sun4{u,v}_build_msi() have improper return value handling.

   We should always return negative error codes, instead of
   using the magic value "0" which could in fact be a valid
   MSI number.

2) sun4{u,v}_build_msi() should return -ENOMEM instead of
   calling prom_prom() halt with kzalloc() of the interrupt
   data fails.

3) We 'remembered' the MSI number using a singleton in the
   struct device archdata area, this doesn't work for MSI-X
   which can cause multiple MSIs assosciated with one device.

   Delete that archdata member, and instead store the MSI
   number in the IRQ chip data area.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fully unify all of the DMA ops so that subordinate bus types to
the DMA operation providers (such as ebus, isa, of_device) can
work transparently.

Basically, we just make sure that for every system device we
create, the dev->archdata 'iommu' and 'stc' fields are filled
in.

Then we have two platform variants of the DMA ops, one for SUN4U which
actually programs the real hardware, and one for SUN4V which makes
hypervisor calls.

This also fixes the crashes in parport_pc on sparc64, reported by
Meelis Roos.
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>

Currently there are 97 occurrences where drivers need the pci
revision ID. We can do this once for all devices. Even the pci
subsystem needs the revision several times for quirks. The extra
u8 member pads out nicely in the pci_dev struct.
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This fixes the IDE controller not showing up on Netra-T1
systems.

Just like Simba bridges, some PCI bridges can lack the
'ranges' OBP property.  So we handle this similarly to
the existing Simba code:

1) In of_device register address resolving, we push the
   translation to the parent.

2) In PCI device scanning, we interrogate the PCI config
   space registers of the PCI bus device in order to resolve
   the resources, just like the generic Linux PCI probing
   code does.

With much help and testing from Fabio, who also reported
the initial problem.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NFabio Massimo Di Nitto <fabbione@ubuntu.com>

These messages were very useful when bringing up the
OBP based PCI device scan code, but it's just a lot
of noise every bootup now especially on big machines.

The messages can be re-enabled via 'ofpci_debug=1' on
the kernel command line.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>