PCI: fix bridge I/O window bus-to-resource conversion

In 5bfa14ed9f3c, I forgot to initialize res2.flags before calling
pcibios_bus_to_resource(), which depends on the resource type to locate the
correct aperture.  This bug won't hurt x86, which currently never has an
offset between bus and CPU addresses, but will affect other architectures.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
(cherry picked from commit cf48fb6a2bf2e59990e1438d0dedc706df911996)
powerpc/PCI: compute I/O space bus-to-resource offset consistently

Make sure we compute CPU addresses (resource start/end) the same way both
when we set up the I/O aperture (hose->io_resource) and when we use
pcibios_bus_to_resource() to convert BAR values into resources.

This fixes a build failure ("cast from pointer to integer of different
size" in configs where resource_size_t is 64 bits but pointers are 32 bits)
I introduced in 6c5705fec63d.

Acked-By: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
(cherry picked from commit 38973ba7903fa0660a31b2bdc50ff711ec8d08c9)
powerpc/PCI: convert devtree bus addresses to resource

Normal PCI enumeration via PCI config space uses __pci_read_base(), where
the PCI core applies any bus-to-resource offset.  But powerpc doesn't use
that path when enumerating via the device tree.

In 6c5705fec63d, I converted powerpc to use the PCI core bus-to-resource
conversion, but I missed these powerpc-specific paths.  Some powerpc
platforms fail to boot ("Cannot allocate resource region," "device not
available," etc.) between that commit and this one.

This adds the corresponding bus-to-resource conversion in the paths that
read BAR values from the OF device tree.

CC: Anton Blanchard <anton@samba.org>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
(cherry picked from commit 39aa146aad3711317baa661e6c421e979c432f2d)
powerpc/eeh: Remove eeh device from OF node

Originally, the PCI sensitive OF node is tracing the eeh device
through struct device_node->edev. However, it was regarded as
bad idea.

The patch removes struct device_node->edev and uses PCI_DN to
trace the corresponding eeh device according to BenH's comments.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 2a0352fa4a78081c76be1e450b51a6aa27c92616)

Conflicts:
	include/linux/of.h
powerpc/eeh: Remove eeh information from pci_dn

The patch removes the eeh information from pci_dn since the eeh
device (struct eeh_dev) already contained those information and
the copy in pci_dn is no longer used except for the pseries iommu
mapping code, which we change to retrieve the PE address from eeh
device instead.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 39baadbf36cee3ede5fdb8a34006d9109e5e2570)
powerpc/eeh: Retrieve PHB from global list

Currently, the existing PHBs are retrieved from the FDT (Flat
Device Tree) based on the name of FDT node. Specificly, those
FDT nodes whose names have prefix "pci" are regarded as PHBs.
That's inappropriate because some PCI bridges possibilly have
names leading with "pci". It caused EEH is enabled on same
PCI devices for towice.

The patch fixes the above issue. Besides, the PHBs are expected
to be figured out from FDT before enable EEH on them. Therefore,
it's resonable to retrieve the PHBs from the global linked list
traced by variable "hose_list" insteading poking them from FDT.

For the EEH implementation on pSeries platform, RTAS is critical
because all low-level functions are implemented based on RTAS.
Therefore, we should make sure "/rtas" OF node is available and
ready before to enable EEH core. However, it actually introduced
duplicate since the previous pSeries platform dependent initialization
function already do the check. Besides, we want to make eeh core
platform independent, so RTAS related staff should be removed there.
The patch removes the duplicate check on "/rtas" OF node for eeh
core.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 1a5c2e63f497bdb5912138888053a02870ed1153)
powerpc: Remove NO_IRQ_IGNORE

Now that legacy iSeries is gone, this is no longer used.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 7ba3e4f5877466b0f81dcd3cb78db5d75b267645)
powerpc: Random little legacy iSeries removal tidy ups

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 1d9a47315042606b4217691bcea36cfa6ccbde66)
powerpc/eeh: Remove eeh_event_handler()->daemonize()

daemonize() is only needed when a user-space task does kernel_thread().

eeh_event_handler() thread is created by the worker kthread, and thus it
doesn't need the soon-to-be-deprecated daemonize().

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Linas Vepstas <linasvepstas@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 37ef9bd48af6ab9a3d1fd28df4f929abc19f2cc3)
powerpc/eeh: Fix use of set_current_state() in eeh event handling set_current_state() wart

That set_current_state() won't work very well: the subsequent mutex_lock()
might flip the task back into TASK_RUNNING.

Attempt to put it somewhere where it might have been meant to be, and
attempt to describe why it might have been added.

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 9b218f63e50e590fe0c7724a0838d7eaa6dae5ce)
powerpc: Fix typo in runlatch code

Commit fe1952fc0afb9a2e4c79f103c08aef5d13db1873
"powerpc: Rework runlatch code" has a nasty typo
where it uses "TLF_RUNLATCH" instead of "_TLF_RUNLATCH"
(bit number instead of bit mask), causing some flags to
be potentially lost such as _TLF_RESTORE_SIGMASK

(Brown paper bag for me ! We should be able to make
that break at compile time with a bit of magic, any
volunteer ?)

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit fae2e0fb24c61ca68c98d854a34732549ebc1854)
powerpc/eeh: Fix crash caused by null eeh_dev

The problem was reported by Anton Blanchard. While EEH error
happened to the PCI device without the corresponding device
driver, kernel crash was seen. Eventually, I successfully
reproduced the problem on Firebird-L machine with utility
"errinjct". Initially, the device driver for Emulex ethernet
MAC has been disabled from .config and force data parity on
the Emulex ethernet MAC with help of "errinjct". Eventually,
I saw the kernel crash after issueing couple of "lspci -v"
command.

The root cause behind is that the PCI device, including the
reference to the corresponding eeh device, will be removed
from the system while EEH does recovery. Afterwards, the
PCI device will be probed again and added into the system
accordingly. So it's not safe to retrieve the eeh device from
the corresponding PCI device after the PCI device has been removed
and not added again.

The patch fixes the issue and retrieve the eeh device from OF node
instead of PCI device after the PCI device has been removed.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Tested-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 2ef822c55371b20548d4f58193c580407a5d738d)
powerpc/pseries: Rivet CONFIG_EEH for pSeries platform

Recently, Ryan Wang tried to compile PPC pSeries platform without
CONFIG_EEH and eventually run into errors. Nishanth Aravamudan
helped to narrow down the root cause. Actually, the pSeries platform
depends on CONFIG_EEH heavily and that won't work properly without
EEH support.

According to Ben's suggestion, the patch make CONFIG_EEH invisible
and keep it as always selected on pSeries platform.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit e49f7a9997c61cf800f2db5decba68d318352ef0)
powerpc/irq: Fix bug with new lazy IRQ handling code

We had a case where we could turn on hard interrupts while
leaving the PACA_IRQ_HARD_DIS bit set in the PACA. This can
in turn cause a BUG_ON() to hit in __check_irq_replay() due
to interrupt state getting out of sync.

The assembly code was also way too convoluted. Instead, we
now leave it to the C code to do the right thing which ends
up being smaller and more readable.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 56dfa7fa19e36db352a94be022243ed461710119)
powerpc/irq: Make alignment & program interrupt behave the same

Alignment was the last user of the ENABLE_INTS macro, which we can
now remove. All non-syscall exceptions now disable interrupts on
entry, they get re-enabled conditionally from C code. Don't
unconditionally re-enable in program check either, check the
original context.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit a3512b2dd57cb653bb33645ca9c934436e547e3c)
powerpc/irq: Fix another case of lazy IRQ state getting out of sync

So we have another case of paca->irq_happened getting out of
sync with the HW irq state. This can happen when a perfmon
interrupt occurs while soft disabled, as it will return to a
soft disabled but hard enabled context while leaving a stale
PACA_IRQ_HARD_DIS flag set.

This patch fixes it, and also adds a test for the condition
of those flags being out of sync in arch_local_irq_restore()
when CONFIG_TRACE_IRQFLAGS is enabled.

This helps catching those gremlins faster (and so far I
can't seem see any anymore, so that's good news).

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 7c0482e3d055e5de056d3c693b821e39205b99ae)
powerpc: Use WARN instead of dump_stack when printing EEH error backtrace

When we get an EEH error we just print a backtrace with dump_stack
which is rather cryptic. We really should print something before
spewing out the backtrace.

Also switch from dump_stack to WARN so we get more information about
the fail - what modules were loaded, what process was running etc.
This was useful information when debugging a recent EEH subsystem bug.

The standard WARN output should also get picked up by monitoring
tools like kerneloops.

The register dump is of questionable value here but I figured it was
better to use something standard and not roll my own.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 14fb1fa6e266fb9c4622b210d2636a2004a47e2b)
powerpc: Fix irq distribution

setting CONFIG_IRQ_ALL_CPUS distributes IRQs to CPUs only when
the number of online CPUs equals NR_CPUS.  See commit
280ff97494e0fef4124bee5c52e39b23a18dd283 "sparc64: fix and
optimize irq distribution" for more details.

Using the online mask fixes IRQ-to-CPU distribution on systems
that boot with less than NR_CPUS.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(cherry picked from commit 2074b1d9d53ae696dd3f49482bad43254f40f01d)
powerpc/time: Sanity check of decrementer expiration is necessary

This reverts 68568add2c ("powerpc/time: Remove unnecessary sanity check
of decrementer expiration").  We do need to check whether we have reached
the expiration time of the next event, because we sometimes get an early
decrementer interrupt, most notably when we set the decrementer to 1 in
arch_irq_work_raise().  The effect of not having the sanity check is that
if timer_interrupt() gets called early, we leave the decrementer set to
its maximum value, which means we then don't get any more decrementer
interrupts for about 4 seconds (or longer, depending on timebase
frequency).  I saw these pauses as a consequence of getting a stray
hypervisor decrementer interrupt left over from exiting a KVM guest.

This isn't quite a straight revert because of changes to the surrounding
code, but it restores the same algorithm as was previously used.

Cc: stable@vger.kernel.org
Acked-by: Anton Blanchard <anton@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
(cherry picked from commit 860aed25a1f0936d4852ab936252b47cd1e630f1)