* Re: [PATCH 13/25] macintosh/mediabay: add a const qualifier
From: Benjamin Herrenschmidt @ 2012-09-05 2:40 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Arnd Bergmann, Rob Herring, kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1343034810-3386-14-git-send-email-u.kleine-koenig@pengutronix.de>
On Mon, 2012-07-23 at 11:13 +0200, Uwe Kleine-König wrote:
> This prepares *of_device_id.data becoming const. Without this change
> the following warning would occur:
>
> drivers/macintosh/mediabay.c: In function 'media_bay_attach':
> drivers/macintosh/mediabay.c:589:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
Ack all of these assuming you test built (I didn't). Do you need me to
carry any of this via the powerpc tree ?
Cheers,
Ben.
> drivers/macintosh/mediabay.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
> index 831d751..54bf584 100644
> --- a/drivers/macintosh/mediabay.c
> +++ b/drivers/macintosh/mediabay.c
> @@ -63,7 +63,7 @@ struct media_bay_info {
> int value_count;
> int timer;
> struct macio_dev *mdev;
> - struct mb_ops* ops;
> + const struct mb_ops* ops;
> int index;
> int cached_gpio;
> int sleeping;
^ permalink raw reply
* Re: [PATCH v2] powerpc: fix personality handling in ppc64_personality()
From: Benjamin Herrenschmidt @ 2012-09-05 2:54 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Paul Mackerras, Andreas Schwab, linuxppc-dev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1208020907490.14910@pobox.suse.cz>
On Thu, 2012-08-02 at 09:10 +0200, Jiri Kosina wrote:
> Directly comparing current->personality against PER_LINUX32 doesn't work
> in cases when any of the personality flags stored in the top three bytes
> are used.
>
> Directly forcefully setting personality to PER_LINUX32 or PER_LINUX
> discards any flags stored in the top three bytes
>
> Use personality() macro to compare only PER_MASK bytes and make sure that
> we are setting only the bits that should be set, instead of
> overwriting the whole value.
>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>
> changed since v1: fix the bit ops to reflect the fact that PER_LINUX is
> actually 0
Had already merged v1 (oops.. didn't spot the issue with PER_LINUX being
0). Can you send an incremental fixup ?
Cheers,
Ben.
> arch/powerpc/kernel/syscalls.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
> index f2496f2..dc1558e 100644
> --- a/arch/powerpc/kernel/syscalls.c
> +++ b/arch/powerpc/kernel/syscalls.c
> @@ -107,11 +107,11 @@ long ppc64_personality(unsigned long personality)
> long ret;
>
> if (personality(current->personality) == PER_LINUX32
> - && personality == PER_LINUX)
> - personality = PER_LINUX32;
> + && personality(personality) == PER_LINUX)
> + personality |= PER_LINUX32;
> ret = sys_personality(personality);
> - if (ret == PER_LINUX32)
> - ret = PER_LINUX;
> + if (personality(ret) == PER_LINUX32)
> + ret &= ~PER_LINUX32;
> return ret;
> }
> #endif
> --
> 1.7.3.1
>
^ permalink raw reply
* RE: [PATCH] sata_fsl: add workaround for data length mismatch on freescale V2 controller
From: Xie Shaohui-B21989 @ 2012-09-05 3:20 UTC (permalink / raw)
To: David Laight, jgarzik@pobox.com, linux-ide@vger.kernel.org
Cc: Bhartiya Anju-B07263, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6FD6@saturn3.aculab.com>
> -----Original Message-----
> From: David Laight [mailto:David.Laight@ACULAB.COM]
> Sent: Tuesday, September 04, 2012 10:51 PM
> To: Xie Shaohui-B21989; jgarzik@pobox.com; linux-ide@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Bhartiya
> Anju-B07263
> Subject: RE: [PATCH] sata_fsl: add workaround for data length mismatch on
> freescale V2 controller
>=20
> > + /* Read command completed register */
> > + done_mask =3D ioread32(hcr_base + CC);
> > +
> > + if (host_priv->quirks & SATA_FSL_QUIRK_V2_ERRATA) {
> > + if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) {
> > + for (tag =3D 0; tag < ATA_MAX_QUEUE; tag++) {
> > + qc =3D ata_qc_from_tag(ap, tag);
> > + if (qc && ata_is_atapi(qc->tf.protocol))
> {
> > + atapi_flag =3D 1;
> > + break;
> > + }
> > + }
> > + }
> > + }
> > +
> > + /* Workaround for data length mismatch errata */
> > + if (atapi_flag) {
>=20
> Seems to me like the conditionals for this code are all in the wrong
> order - adding code to the normal path.
>=20
> The whole lot should probably be inside:
> if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) { and the
> 'atapi_flag' boolean removed.
[S.H] OK. But I need to move the "done_mask =3D ioread32(hcr_base + CC);" b=
efore these codes,
because these codes will clean command completed register.
>=20
> I also wonder it this is worthy of an actual quirk?
> Might be worth doing anyway.
[S.H] The quirk is useful for our internal use(there is another errata but =
got fixed by silicon upgrade),
but you are right it's worth doing anyway in upstream, since the upstream c=
ode only handles this errata.
Best Regards,=20
Shaohui Xie
^ permalink raw reply
* Re: [PATCH V3 1/3] drivers/char/tpm: Add new device driver to support IBM vTPM
From: Benjamin Herrenschmidt @ 2012-09-05 3:40 UTC (permalink / raw)
To: Kent Yoder
Cc: linux-kernel, Ashley Lai, linux-security-module, tpmdd-devel,
adlai, rcj, linuxppc-dev
In-Reply-To: <20120822214217.GB13519@linux.vnet.ibm.com>
On Wed, 2012-08-22 at 16:42 -0500, Kent Yoder wrote:
> On Wed, Aug 22, 2012 at 04:17:43PM -0500, Ashley Lai wrote:
> > This patch adds a new device driver to support IBM virtual TPM
> > (vTPM) for PPC64. IBM vTPM is supported through the adjunct
> > partition with firmware release 740 or higher. With vTPM
> > support, each lpar is able to have its own vTPM without the
> > physical TPM hardware.
> >
> > This driver provides TPM functionalities by communicating with
> > the vTPM adjunct partition through Hypervisor calls (Hcalls)
> > and Command/Response Queue (CRQ) commands.
>
> Thanks Ashley, I'll include this in my next pull request to James.
Oh ? I was about to put it in the powerpc tree ... But yeah, I notice
there's a change to tpm.h so it probably should be at least acked by the
TPM folks. As for the subsequent patches, they are powerpc specific so I
can add them, I don't think there's a strict dependency, is there ?
Now, while having a look at the driver, I found a few things that I'm
not sure I'm happy with:
Mainly:
> > + */
> > +static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> > +{
> > + struct ibmvtpm_dev *ibmvtpm;
> > + u16 len;
> > +
> > + ibmvtpm = (struct ibmvtpm_dev *)chip->vendor.data;
> > +
> > + if (!ibmvtpm->rtce_buf) {
> > + dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
> > + return 0;
> > + }
> > +
> > + wait_event_interruptible(wq, ibmvtpm->crq_res.len != 0);
> > +
> > + if (count < ibmvtpm->crq_res.len) {
That doesn't look right. The "other side" as far as I can tell is:
> > + case VTPM_TPM_COMMAND_RES:
> > + ibmvtpm->crq_res.valid = crq->valid;
> > + ibmvtpm->crq_res.msg = crq->msg;
> > + ibmvtpm->crq_res.len = crq->len;
> > + ibmvtpm->crq_res.data = crq->data;
> > + wake_up_interruptible(&wq);
That looks racy to me. At the very least it should be doing:
ibmvtpm->crq_res.data = crq->data;
smp_wmb();
ibmvtpm->crq_res.len = crq->len;
IE. Ensure that "len" is written last, and possibly have an
corresponding smp_rmb() after wait_event_interruptible() in the receive
case.
Also, I dislike having a global symbol called "wq". You also don't seem
to have any synchronization on access to that wq, can't you end up with
several clients trying to send messages & wait for responses getting all
mixed up ? You might need to make sure that at least you do a
wake_up_interruptible_all() to ensure you wake them all up (inefficient
but works). Unless you can track per-client ?
Or is the above TPM layer making sure only one command/response happens
at a given point in time ?
You also do an interruptible wait but don't seem to be checking for
signals (and not testing the result from wait_event_interruptible which
might be returning -ERESTARTSYS in this case).
That all sound a bit wrong to me ...
> > +static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
> > +{
> > + struct ibmvtpm_dev *ibmvtpm = (struct ibmvtpm_dev *) vtpm_instance;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&ibmvtpm->lock, flags);
> > + vio_disable_interrupts(ibmvtpm->vdev);
> > + tasklet_schedule(&ibmvtpm->tasklet);
> > + spin_unlock_irqrestore(&ibmvtpm->lock, flags);
> > +
> > + return IRQ_HANDLED;
> > +}
Tasklets ? We still use those things ? That's softirq iirc, do you
really need to offload ? I mean, it allows to limit the amount of time
an interrupt is disabled, but that's only useful if you assume you'll
have quite a lot of traffic here, is that the case ?
You might be actually increasing latency here in favor of throughput, is
that what you are aiming for ? Also keep in mind that
vio_disable/enable_interrupt() being an hcall, it can have significant
overhead. So again, only worth it if you're going to process a bulk of
data at a time.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2] powerpc: Make sure IPI handlers see data written by IPI senders
From: Paul Mackerras @ 2012-09-05 4:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul E. McKenney, Milton Miller
We have been observing hangs, both of KVM guest vcpu tasks and more
generally, where a process that is woken doesn't properly wake up and
continue to run, but instead sticks in TASK_WAKING state. This
happens because the update of rq->wake_list in ttwu_queue_remote()
is not ordered with the update of ipi_message in
smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
scheduler_ipi() is not ordered with the reading of ipi_message in
smp_ipi_demux(). Thus it is possible for the IPI receiver not to see
the updated rq->wake_list and therefore conclude that there is nothing
for it to do.
In order to make sure that anything done before smp_send_reschedule()
is ordered before anything done in the resulting call to scheduler_ipi(),
this adds barriers in smp_muxed_message_pass() and smp_ipi_demux().
The barrier in smp_muxed_message_pass() is a full barrier to ensure that
there is a full ordering between the smp_send_reschedule() caller and
scheduler_ipi(). In smp_ipi_demux(), we use xchg() rather than
xchg_local() because xchg() includes release and acquire barriers.
Using xchg() rather than xchg_local() makes sense given that
ipi_message is not just accessed locally.
This moves the barrier between setting the message and calling the
cause_ipi() function into the individual cause_ipi implementations.
Most of them -- those that used outb, out_8 or similar -- already had
a full barrier because out_8 etc. include a sync before the MMIO
store. This adds an explicit barrier in the two remaining cases.
These changes made no measurable difference to the speed of IPIs as
measured using a simple ping-pong latency test across two CPUs on
different cores of a POWER7 machine.
The analysis of the reason why processes were not waking up properly
is due to Milton Miller.
Cc: stable@vger.kernel.org # v3.0+
Reported-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
v2: Move the barrier between setting message and calling cause_ipi
into the cause_ipi functions
arch/powerpc/kernel/dbell.c | 2 ++
arch/powerpc/kernel/smp.c | 11 +++++++++--
arch/powerpc/sysdev/xics/icp-hv.c | 6 +++++-
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dbell.c b/arch/powerpc/kernel/dbell.c
index 5b25c80..a892680 100644
--- a/arch/powerpc/kernel/dbell.c
+++ b/arch/powerpc/kernel/dbell.c
@@ -28,6 +28,8 @@ void doorbell_setup_this_cpu(void)
void doorbell_cause_ipi(int cpu, unsigned long data)
{
+ /* Order previous accesses vs. msgsnd, which is treated as a store */
+ mb();
ppc_msgsnd(PPC_DBELL, 0, data);
}
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 0321007..8d4214a 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -198,8 +198,15 @@ void smp_muxed_ipi_message_pass(int cpu, int msg)
struct cpu_messages *info = &per_cpu(ipi_message, cpu);
char *message = (char *)&info->messages;
+ /*
+ * Order previous accesses before accesses in the IPI handler.
+ */
+ smp_mb();
message[msg] = 1;
- mb();
+ /*
+ * cause_ipi functions are required to include a full barrier
+ * before doing whatever causes the IPI.
+ */
smp_ops->cause_ipi(cpu, info->data);
}
@@ -211,7 +218,7 @@ irqreturn_t smp_ipi_demux(void)
mb(); /* order any irq clear */
do {
- all = xchg_local(&info->messages, 0);
+ all = xchg(&info->messages, 0);
#ifdef __BIG_ENDIAN
if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNCTION)))
diff --git a/arch/powerpc/sysdev/xics/icp-hv.c b/arch/powerpc/sysdev/xics/icp-hv.c
index 14469cf..df0fc58 100644
--- a/arch/powerpc/sysdev/xics/icp-hv.c
+++ b/arch/powerpc/sysdev/xics/icp-hv.c
@@ -65,7 +65,11 @@ static inline void icp_hv_set_xirr(unsigned int value)
static inline void icp_hv_set_qirr(int n_cpu , u8 value)
{
int hw_cpu = get_hard_smp_processor_id(n_cpu);
- long rc = plpar_hcall_norets(H_IPI, hw_cpu, value);
+ long rc;
+
+ /* Make sure all previous accesses are ordered before IPI sending */
+ mb();
+ rc = plpar_hcall_norets(H_IPI, hw_cpu, value);
if (rc != H_SUCCESS) {
pr_err("%s: bad return code qirr cpu=%d hw_cpu=%d mfrr=0x%x "
"returned %ld\n", __func__, n_cpu, hw_cpu, value, rc);
--
1.7.10
^ permalink raw reply related
* Re: [PATCH] powerpc-powernv: align BARs to PAGE_SIZE on powernv platform
From: Alex Williamson @ 2012-09-05 4:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexey Kardashevskiy, linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1346807803.2257.19.camel@pasglop>
On Wed, 2012-09-05 at 11:16 +1000, Benjamin Herrenschmidt wrote:
> > > It's still bad in more ways that I care to explain...
> >
> > Well it is right before pci_reassigndev_resource_alignment() which is
> > common and does the same thing.
> >
> > > The main one is that you do the "fixup" in a very wrong place anyway and
> > > it might cause cases of overlapping BARs.
> >
> > As far as I can tell it may only happen if someone tries to align resource
> > via kernel command line.
> >
> > But ok. I trust you :)
>
> I have reasons to believe that this realignment crap is wrong too :-)
>
> > > In any case this is wrong. It's a VFIO design bug and needs to be fixed
> > > there (CC'ing Alex).
> >
> > It can be fixed in VFIO only if VFIO will stop treating functions
> > separately and start mapping group's MMIO space as a whole thing. But this
> > is not going to happen.
>
> It still can be fixed without that...
>
> > The example of the problem is NEC USB PCI which has 3 functions, each has
> > one BAR, these BARs are 4K aligned and I cannot see how it can be fixed
> > with 64K page size and VFIO creating memory regions per BAR (not per PHB).
>
> VFIO can perfectly well realize it's the same MR or even map the same
> area 3 times and create 3 MRs, both options work. All it needs is to
> know the offset of the BAR inside the page.
Yep, I think I agree...
> > > IE. We need a way to know where the BAR is within a page at which point
> > > VFIO can still map the page, but can also properly take into account the
> > > offset.
> >
> > It is not about VFIO, it is about KVM. I cannot put non-aligned page to
> > kvm_set_phys_mem(). Cannot understand how we would solve this.
>
> No, VFIO still maps the whole page and creates an MR for the whole page,
> that's fine. But you still need to know the offset within the page.
Do we need an extra region info field, or is it sufficient that we
define a region to be mmap'able with getpagesize() pages when the MMAP
flag is set and simply offset the region within the device fd? ex.
BAR0: 0x10000 /* no offset */
BAR1: 0x21000 /* 4k offset */
BAR2: 0x32000 /* 8k offset */
A second level optimization might make these 0x10000, 0x11000, 0x12000.
This will obviously require some arch hooks w/in vfio as we can't do
this on x86 since we can't guarantee that whatever lives in the
overflow/gaps is in the same group and power is going to need to make
sure we don't accidentally allow msix table mapping... in fact hiding
the msix table might be a lot more troublesome on 64k page hosts.
> Now the main problem here is going to be that the guest itself might
> reallocate the BAR and move it around (well, it's version of the BAR
> which isn't the real thing), and so we cannot create a direct MMU
> mapping between -that- and the real BAR.
>
> IE. We can only allow that direct mapping if the guest BAR mapping has
> the same "offset within page" as the host BAR mapping.
Euw...
> Our guests don't mess with BARs but SLOF does ... it's really tempting
> to look into bringing the whole BAR allocation back into qemu and out of
> SLOF :-( (We might have to if we ever do hotplug anyway). That way qemu
> could set offsets that match appropriately.
BTW, as I mentioned elsewhere, I'm on vacation this week, but I'll try
to keep up as much as I have time for.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH] powerpc-powernv: align BARs to PAGE_SIZE on powernv platform
From: Benjamin Herrenschmidt @ 2012-09-05 5:17 UTC (permalink / raw)
To: Alex Williamson
Cc: Alexey Kardashevskiy, linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1346821074.2225.65.camel@ul30vt.home>
On Tue, 2012-09-04 at 22:57 -0600, Alex Williamson wrote:
> Do we need an extra region info field, or is it sufficient that we
> define a region to be mmap'able with getpagesize() pages when the MMAP
> flag is set and simply offset the region within the device fd? ex.
Alexey ? You mentioned you had ways to get at the offset with the
existing interfaces ?
> BAR0: 0x10000 /* no offset */
> BAR1: 0x21000 /* 4k offset */
> BAR2: 0x32000 /* 8k offset */
>
> A second level optimization might make these 0x10000, 0x11000, 0x12000.
>
> This will obviously require some arch hooks w/in vfio as we can't do
> this on x86 since we can't guarantee that whatever lives in the
> overflow/gaps is in the same group and power is going to need to make
> sure we don't accidentally allow msix table mapping... in fact hiding
> the msix table might be a lot more troublesome on 64k page hosts.
Fortunately, our guests don't access the msix table directly anyway, at
least most of the time :-) There's a paravirt API for it, and our iommu
makes sure that if for some reason the guest still accesses it and does
the wrong thing to it, the side effects will be contained to the guest.
> > Now the main problem here is going to be that the guest itself might
> > reallocate the BAR and move it around (well, it's version of the BAR
> > which isn't the real thing), and so we cannot create a direct MMU
> > mapping between -that- and the real BAR.
> >
> > IE. We can only allow that direct mapping if the guest BAR mapping has
> > the same "offset within page" as the host BAR mapping.
>
> Euw...
Yeah sucks :-) Basically, let's say page size is 64K. Host side BAR
(real BAR) is at 0xf0001000.
qemu maps 0xf0000000..0xf000ffff to a virtual address inside QEMU,
itself 64k aligned, let's say 0x80000000 and knows that the BAR is at
offset 0x1000 in there.
However, the KVM "MR" API is such that we can only map PAGE_SIZE regions
into the guest as well, so if the guest assigns a value ADDR to the
guest BAR, let's say 0x40002000, all KVM can do is an MR that maps
0x40000000 (guest physical) to 0x80000000 (qemu). Any access within that
64K page will have the low bits transferred directly from guest to HW.
So the guest will end up having that 0x2000 offset instead of the 0x1000
needed to actually access the BAR. FAIL.
There are ways to fix that but all are nasty.
- In theory, we have the capability (and use it today) to restrict IO
mappings in the guest to 4K HW pages, so knowing that, KVM could use a
"special" MR that plays tricks here... but that would break all sort of
generic code both in qemu and kvm and generally be very nasty.
- The best approach is to rely on the fact that our guest kernels don't
do BAR assignment, they rely on FW to do it (ie not at all, unlike x86,
we can't even fixup because in the general case, the hypervisor won't
let us anyway). So we could move our guest BAR allocation code out of
our guest firmware (SLOF) back into qemu (where we had it very early
on), which allows us to make sure that the guest BAR values we assign
have the same "offset within the page" as the host side values. This
would also allow us to avoid messing up too many MRs (this can have a
performance impact with KVM) and eventually handle our "group" regions
instead of individual BARs for mappings. We might need to do that anyway
in the long run for hotplug as our hotplug hypervisor APIs also rely on
the "new" hotplugged devices to have the BARs pre-assigned when they get
handed out to the guest.
> > Our guests don't mess with BARs but SLOF does ... it's really tempting
> > to look into bringing the whole BAR allocation back into qemu and out of
> > SLOF :-( (We might have to if we ever do hotplug anyway). That way qemu
> > could set offsets that match appropriately.
>
> BTW, as I mentioned elsewhere, I'm on vacation this week, but I'll try
> to keep up as much as I have time for.
No worries,
Cheers,
Ben.
^ permalink raw reply
* Re: 3.5+: yaboot, Invalid memory access
From: Christian Kujau @ 2012-09-05 5:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Steven Rostedt
In-Reply-To: <1346807308.2257.14.camel@pasglop>
On Wed, 5 Sep 2012 at 11:08, Benjamin Herrenschmidt wrote:
> Try this:
>
> powerpc: Don't use __put_user() in patch_instruction
Perfect! With this patch applied, the machine boots again.
Tested-by: Christian Kujau <lists@nerdbynature.de>
I sure hope that other people will benefit from this as well. I can't
stand the thought that you guys are always putting out fixes for this ol'
PowerBook of mine :-\
Thanks so much,
Christian.
>
> patch_instruction() can be called very early on ppc32, when the kernel
> isn't yet running at it's linked address. That can cause the !
> is_kernel_addr() test in __put_user() to trip and call might_sleep()
> which is very bad at that point during boot.
>
> Use a lower level function instead for now, at least until we get to
> rework ppc32 boot process to do the code patching later, like ppc64
> does.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> index dd223b3..17e5b23 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -20,7 +20,7 @@ int patch_instruction(unsigned int *addr, unsigned int instr)
> {
> int err;
>
> - err = __put_user(instr, addr);
> + __put_user_size(instr, addr, 4, err);
> if (err)
> return err;
> asm ("dcbst 0, %0; sync; icbi 0,%0; sync; isync" : : "r" (addr));
>
>
>
--
BOFH excuse #101:
Collapsed Backbone
^ permalink raw reply
* Re: [PATCH] powerpc-powernv: align BARs to PAGE_SIZE on powernv platform
From: Alexey Kardashevskiy @ 2012-09-05 5:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Alex Williamson, Paul Mackerras, David Gibson
In-Reply-To: <1346822276.2257.46.camel@pasglop>
On 05/09/12 15:17, Benjamin Herrenschmidt wrote:
> On Tue, 2012-09-04 at 22:57 -0600, Alex Williamson wrote:
>
>> Do we need an extra region info field, or is it sufficient that we
>> define a region to be mmap'able with getpagesize() pages when the MMAP
>> flag is set and simply offset the region within the device fd? ex.
>
> Alexey ? You mentioned you had ways to get at the offset with the
> existing interfaces ?
Yes, VFIO_DEVICE_GET_REGION_INFO ioctl of vfio-pci host driver, the "info"
struct has an "offset" field.
I just do not have a place to use it in the QEMU right now as the guest
does the same allocation as the host does (by accident).
>> BAR0: 0x10000 /* no offset */
>> BAR1: 0x21000 /* 4k offset */
>> BAR2: 0x32000 /* 8k offset */
>>
>> A second level optimization might make these 0x10000, 0x11000, 0x12000.
>>
>> This will obviously require some arch hooks w/in vfio as we can't do
>> this on x86 since we can't guarantee that whatever lives in the
>> overflow/gaps is in the same group and power is going to need to make
>> sure we don't accidentally allow msix table mapping... in fact hiding
>> the msix table might be a lot more troublesome on 64k page hosts.
>
> Fortunately, our guests don't access the msix table directly anyway, at
> least most of the time :-)
Not at all in our case. It took me some time to push a QEMU patch which
changes msix table :)
> There's a paravirt API for it, and our iommu
> makes sure that if for some reason the guest still accesses it and does
> the wrong thing to it, the side effects will be contained to the guest.
>>> Now the main problem here is going to be that the guest itself might
>>> reallocate the BAR and move it around (well, it's version of the BAR
>>> which isn't the real thing), and so we cannot create a direct MMU
>>> mapping between -that- and the real BAR.
>>>
>>> IE. We can only allow that direct mapping if the guest BAR mapping has
>>> the same "offset within page" as the host BAR mapping.
>>
>> Euw...
>
> Yeah sucks :-) Basically, let's say page size is 64K. Host side BAR
> (real BAR) is at 0xf0001000.
>
> qemu maps 0xf0000000..0xf000ffff to a virtual address inside QEMU,
> itself 64k aligned, let's say 0x80000000 and knows that the BAR is at
> offset 0x1000 in there.
>
> However, the KVM "MR" API is such that we can only map PAGE_SIZE regions
> into the guest as well, so if the guest assigns a value ADDR to the
> guest BAR, let's say 0x40002000, all KVM can do is an MR that maps
> 0x40000000 (guest physical) to 0x80000000 (qemu). Any access within that
> 64K page will have the low bits transferred directly from guest to HW.
>
> So the guest will end up having that 0x2000 offset instead of the 0x1000
> needed to actually access the BAR. FAIL.
>
> There are ways to fix that but all are nasty.
>
> - In theory, we have the capability (and use it today) to restrict IO
> mappings in the guest to 4K HW pages, so knowing that, KVM could use a
> "special" MR that plays tricks here... but that would break all sort of
> generic code both in qemu and kvm and generally be very nasty.
>
> - The best approach is to rely on the fact that our guest kernels don't
> do BAR assignment, they rely on FW to do it (ie not at all, unlike x86,
> we can't even fixup because in the general case, the hypervisor won't
> let us anyway). So we could move our guest BAR allocation code out of
> our guest firmware (SLOF) back into qemu (where we had it very early
> on), which allows us to make sure that the guest BAR values we assign
> have the same "offset within the page" as the host side values. This
> would also allow us to avoid messing up too many MRs (this can have a
> performance impact with KVM) and eventually handle our "group" regions
> instead of individual BARs for mappings. We might need to do that anyway
> in the long run for hotplug as our hotplug hypervisor APIs also rely on
> the "new" hotplugged devices to have the BARs pre-assigned when they get
> handed out to the guest.
>
>>> Our guests don't mess with BARs but SLOF does ... it's really tempting
>>> to look into bringing the whole BAR allocation back into qemu and out of
>>> SLOF :-( (We might have to if we ever do hotplug anyway). That way qemu
>>> could set offsets that match appropriately.
>>
>> BTW, as I mentioned elsewhere, I'm on vacation this week, but I'll try
>> to keep up as much as I have time for.
>
> No worries,
--
Alexey
^ permalink raw reply
* Re: [PATCH v5 3/3] powerpc: Uprobes port to powerpc
From: Benjamin Herrenschmidt @ 2012-09-05 5:26 UTC (permalink / raw)
To: ananth
Cc: Srikar Dronamraju, peterz, lkml, oleg, Paul Mackerras,
Anton Blanchard, Ingo Molnar, ppcdev
In-Reply-To: <20120824073132.GC32031@in.ibm.com>
On Fri, 2012-08-24 at 13:01 +0530, Ananth N Mavinakayanahalli wrote:
> From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
>
> This is the port of uprobes to powerpc. Usage is similar to x86.
Guys, can you do a minimum of build testing ?
This one breaks due to uprobe_get_swbp_addr() being defined in both
asm and include/linux when CONFIG_UPROBE isn't set. You don't need
to define it at all in fact, the generic code takes care of both the
declaration for CONFIG_UPROBE and the empty inline for !CONFIG_UPROBE.
I'm fixing that one up myself but please, please, get yourself a test
build script or something to make sure you don't at least break the
build when the stuff you're adding isn't enabled (among others).
Cheers,
Ben.
^ permalink raw reply
* Re: 3.5+: yaboot, Invalid memory access
From: Benjamin Herrenschmidt @ 2012-09-05 5:29 UTC (permalink / raw)
To: Christian Kujau; +Cc: linuxppc-dev, Steven Rostedt
In-Reply-To: <alpine.DEB.2.01.1209042222270.25392@trent.utfs.org>
On Tue, 2012-09-04 at 22:25 -0700, Christian Kujau wrote:
> I sure hope that other people will benefit from this as well. I can't
> stand the thought that you guys are always putting out fixes for this
> ol'
> PowerBook of mine :-\
Well, for some strange reason I didn't observe the problem on a couple
of old macs here, might have got lucky or something (could depend on
whether might_sleep() is compiled to do something or not... depends
on .config debug options).
Anyways, I'll send that fix to Linus asap. Thanks for reporting !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 6/6] powerpc/booke64: restore VDSO information on critical exception
From: Benjamin Herrenschmidt @ 2012-09-05 5:38 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1344259628-31161-7-git-send-email-mihai.caraman@freescale.com>
On Mon, 2012-08-06 at 16:27 +0300, Mihai Caraman wrote:
> Critical exception handler on 64-bit booke uses user-visible SPRG3 as scratch.
> Restore VDSO information in SPRG3 on exception prolog.
Breaks the build on !BOOKE because of :
> diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
> index b67db22..a0b0d08 100644
> --- a/arch/powerpc/kernel/vdso.c
> +++ b/arch/powerpc/kernel/vdso.c
> @@ -725,6 +725,8 @@ int __cpuinit vdso_getcpu_init(void)
> mtspr(SPRN_SPRG3, val);
> #ifdef CONFIG_KVM_BOOK3S_HANDLER
> get_paca()->kvm_hstate.sprg3 = val;
> +#elif CONFIG_PPC_BOOK3E
^^^^
You can't "#elif" a CONFIG option.
> + get_paca()->sprg3 = val;
> #endif
>
> put_cpu();
Now, my suggestion is to actually move the bloody thing out of
kvm_hstate on server as well, just make it a common "sprg3" field
accross the board.
I'm dropping this one patch (the other ones seem fine so far and will
land in next soon unless I find another problem).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 3/3] powerpc: Uprobes port to powerpc
From: Ananth N Mavinakayanahalli @ 2012-09-05 5:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Srikar Dronamraju, peterz, lkml, oleg, Paul Mackerras,
Anton Blanchard, Ingo Molnar, ppcdev
In-Reply-To: <1346822819.2257.49.camel@pasglop>
On Wed, Sep 05, 2012 at 03:26:59PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2012-08-24 at 13:01 +0530, Ananth N Mavinakayanahalli wrote:
> > From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> >
> > This is the port of uprobes to powerpc. Usage is similar to x86.
>
> Guys, can you do a minimum of build testing ?
>
> This one breaks due to uprobe_get_swbp_addr() being defined in both
> asm and include/linux when CONFIG_UPROBE isn't set. You don't need
> to define it at all in fact, the generic code takes care of both the
> declaration for CONFIG_UPROBE and the empty inline for !CONFIG_UPROBE.
>
> I'm fixing that one up myself but please, please, get yourself a test
> build script or something to make sure you don't at least break the
> build when the stuff you're adding isn't enabled (among others).
Sorry Ben. That was an oversight. Won't happen again.
Regards,
Ananth
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-09-05 6:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Linux Kernel list
Hi Linus !
Here are a few fixes for 3.6 that were piling up while I was away or
busy (I was mostly MIA a week or two before San Diego). Some fixes from
Anton fixing up issues with our relatively new DSCR control feature,
and a few other fixes that are either regressions or bugs nasty enough
to warrant not waiting.
Cheers,
Ben.
The following changes since commit 5b716ac728bcc01b1f2a7ed6e437196602237c27:
Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 (2012-09-02 11:30:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
for you to fetch changes up to 636802ef96eebe279b22ad9f9dacfe29291e45c7:
powerpc: Don't use __put_user() in patch_instruction (2012-09-05 16:05:23 +1000)
----------------------------------------------------------------
Anton Blanchard (4):
powerpc: Update DSCR on all CPUs when writing sysfs dscr_default
powerpc: Keep thread.dscr and thread.dscr_inherit in sync
powerpc: Fix DSCR inheritance in copy_thread()
powerpc: Restore correct DSCR in context switch
Benjamin Herrenschmidt (1):
powerpc: Don't use __put_user() in patch_instruction
Jesse Larrew (1):
powerpc/vphn: Fix arch_update_cpu_topology() return value
Paul Mackerras (3):
powerpc: Give hypervisor decrementer interrupts their own handler
powerpc/powernv: Always go into nap mode when CPU is offline
powerpc: Make sure IPI handlers see data written by IPI senders
arch/powerpc/include/asm/processor.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/dbell.c | 2 ++
arch/powerpc/kernel/entry_64.S | 23 +++++++++++++++++------
arch/powerpc/kernel/exceptions-64s.S | 3 ++-
arch/powerpc/kernel/idle_power7.S | 2 ++
arch/powerpc/kernel/process.c | 12 ++----------
arch/powerpc/kernel/smp.c | 11 +++++++++--
arch/powerpc/kernel/sysfs.c | 10 ++++++++++
arch/powerpc/kernel/time.c | 9 +++++++++
arch/powerpc/kernel/traps.c | 3 ++-
arch/powerpc/lib/code-patching.c | 2 +-
arch/powerpc/mm/numa.c | 7 ++++---
arch/powerpc/platforms/powernv/smp.c | 10 +---------
arch/powerpc/sysdev/xics/icp-hv.c | 6 +++++-
15 files changed, 68 insertions(+), 34 deletions(-)
^ permalink raw reply
* [PATCH 00/21 V3] powerpc/eeh: PE support
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
The series of patches address explicit PE support as well as probe type
support. For explicit PE support, struct eeh_pe has been introduced.
While designing the struct, following factors have been taken into
account.
* For one particular PE, it might be composed of single PCI device,
or multiple PCI devices and its educed children PCI devices (e.g.
by PCIe bridges). The PE struct has included a linked list to refer
the included PCI devices. Also, the linked list of devices has relected
top-to-bottom fasion of the PCI subtree. That's to say, the first device
in the linked list should be the toppest element in the PCI subtree which
is being managed by the PE.
* PEs correlate to each other. So the existing PEs have to form hierarchy
levels. There're some fields in PE struct (e.g. parent/child/silbing)
have been introduced for the purpose.
* For one PE, it's only meaningful in the PHB domain.
In addition, the mechniasm used to do memory bars restore, error report have
been reworked based on PE. The eeh cache has been reworked for a little bit
based on Ben's suggestion to trace eeh device.
In order for explicit probe support, either OF node or pci device, global
variable and some inline functions are introduced. For pSeries platform, it's
going to support OF node probe and figure out PEs from the corresponding OF
nodes. In contrast, powernv platform has to use pci device probe type since
the PEs are being constructed at PHB fixup time.
The series of patches have been verified on Firebird-L machine using "errinjct"
utility. Here's the command used for that.
errinjct eeh -v -f 0 -p U78AE.001.WZS00M9-P1-C18-L1-T2 -a 0x0 -m 0x0
V2 -> V3:
* Rebase to 3.6.RC4.
V1 -> V2:
* Rebase to 3.5.RC4.
* Use the link list to trace the relationships of PEs, PE and eeh
devices according to Ram's suggestion.
* Simplify the PE tranverse function according to Ram's example.
* Move EEH initialization around according to Ben's suggestion so
that we can do memory allocation through slab.
* Use kzmalloc() to allocate memory chunks for PE and eeh devices.
* More booting messages for EEH initialization functions.
* Introduce global EEH mutex to protect the PEs and eeh devices.
* Added functions to support PE removal.
* Comments cleanup
* Change on the comparison of PE or BDF (Bus/Device/Function)
address so that code looks more readable.
-----
arch/powerpc/include/asm/eeh.h | 132 +++++--
arch/powerpc/include/asm/eeh_event.h | 6 +-
arch/powerpc/include/asm/pci-bridge.h | 2 +
arch/powerpc/include/asm/ppc-pci.h | 15 +-
arch/powerpc/kernel/rtas_pci.c | 5 +-
arch/powerpc/platforms/pseries/Makefile | 5 +-
arch/powerpc/platforms/pseries/eeh.c | 527 +++++------------------
arch/powerpc/platforms/pseries/eeh_cache.c | 19 +-
arch/powerpc/platforms/pseries/eeh_dev.c | 14 +-
arch/powerpc/platforms/pseries/eeh_driver.c | 235 +++++------
arch/powerpc/platforms/pseries/eeh_event.c | 54 +--
arch/powerpc/platforms/pseries/eeh_pe.c | 583 ++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/eeh_pseries.c | 246 ++++++++----
arch/powerpc/platforms/pseries/eeh_sysfs.c | 9 -
arch/powerpc/platforms/pseries/msi.c | 6 +-
arch/powerpc/platforms/pseries/setup.c | 2 -
16 files changed, 1119 insertions(+), 741 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/eeh_pe.c
Thanks,
Gavin
^ permalink raw reply
* [PATCH 01/21] ppc/eeh: move EEH initialization around
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
Currently, we have 3 phases for EEH initialization on pSeries platform
using builtin functions: platform initialization, EEH device creation,
and EEH subsystem enablement. All of them are done no later than
ppc_md.setup_arch. That means that the slab/slub isn't ready yet, so
we have to allocate memory chunks on basis of PAGE_SIZE for those
dynamically created EEH devices. That's pretty expensive.
In order to utilize slab/slub for memory allocation, we have to move
the EEH initialization functions around, but all of them should be
called after slab/slub is ready.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 16 ----------------
arch/powerpc/kernel/rtas_pci.c | 3 ---
arch/powerpc/platforms/pseries/eeh.c | 10 +++++++---
arch/powerpc/platforms/pseries/eeh_dev.c | 6 +++++-
arch/powerpc/platforms/pseries/eeh_pseries.c | 4 +++-
arch/powerpc/platforms/pseries/setup.c | 2 --
6 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index d60f998..06dedff 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -117,11 +117,6 @@ extern int eeh_subsystem_enabled;
void * __devinit eeh_dev_init(struct device_node *dn, void *data);
void __devinit eeh_dev_phb_init_dynamic(struct pci_controller *phb);
-void __init eeh_dev_phb_init(void);
-void __init eeh_init(void);
-#ifdef CONFIG_PPC_PSERIES
-int __init eeh_pseries_init(void);
-#endif
int __init eeh_ops_register(struct eeh_ops *ops);
int __exit eeh_ops_unregister(const char *name);
unsigned long eeh_check_failure(const volatile void __iomem *token,
@@ -156,17 +151,6 @@ static inline void *eeh_dev_init(struct device_node *dn, void *data)
static inline void eeh_dev_phb_init_dynamic(struct pci_controller *phb) { }
-static inline void eeh_dev_phb_init(void) { }
-
-static inline void eeh_init(void) { }
-
-#ifdef CONFIG_PPC_PSERIES
-static inline int eeh_pseries_init(void)
-{
- return 0;
-}
-#endif /* CONFIG_PPC_PSERIES */
-
static inline unsigned long eeh_check_failure(const volatile void __iomem *token, unsigned long val)
{
return val;
diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
index 179af90..140735c 100644
--- a/arch/powerpc/kernel/rtas_pci.c
+++ b/arch/powerpc/kernel/rtas_pci.c
@@ -275,9 +275,6 @@ void __init find_and_init_phbs(void)
of_node_put(root);
pci_devs_phb_init();
- /* Create EEH devices for all PHBs */
- eeh_dev_phb_init();
-
/*
* PCI_PROBE_ONLY and PCI_REASSIGN_ALL_BUS can be set via properties
* in chosen.
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index ecd394c..e819448 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -982,7 +982,7 @@ int __exit eeh_ops_unregister(const char *name)
* Even if force-off is set, the EEH hardware is still enabled, so that
* newer systems can boot.
*/
-void __init eeh_init(void)
+static int __init eeh_init(void)
{
struct pci_controller *hose, *tmp;
struct device_node *phb;
@@ -992,11 +992,11 @@ void __init eeh_init(void)
if (!eeh_ops) {
pr_warning("%s: Platform EEH operation not found\n",
__func__);
- return;
+ return -EEXIST;
} else if ((ret = eeh_ops->init())) {
pr_warning("%s: Failed to call platform init function (%d)\n",
__func__, ret);
- return;
+ return ret;
}
raw_spin_lock_init(&confirm_error_lock);
@@ -1011,8 +1011,12 @@ void __init eeh_init(void)
printk(KERN_INFO "EEH: PCI Enhanced I/O Error Handling Enabled\n");
else
printk(KERN_WARNING "EEH: No capable adapters found\n");
+
+ return ret;
}
+core_initcall_sync(eeh_init);
+
/**
* eeh_add_device_early - Enable EEH for the indicated device_node
* @dn: device node for which to set up EEH
diff --git a/arch/powerpc/platforms/pseries/eeh_dev.c b/arch/powerpc/platforms/pseries/eeh_dev.c
index c4507d0..ab68c59 100644
--- a/arch/powerpc/platforms/pseries/eeh_dev.c
+++ b/arch/powerpc/platforms/pseries/eeh_dev.c
@@ -93,10 +93,14 @@ void __devinit eeh_dev_phb_init_dynamic(struct pci_controller *phb)
* Scan all the existing PHBs and create EEH devices for their OF
* nodes and their children OF nodes
*/
-void __init eeh_dev_phb_init(void)
+static int __init eeh_dev_phb_init(void)
{
struct pci_controller *phb, *tmp;
list_for_each_entry_safe(phb, tmp, &hose_list, list_node)
eeh_dev_phb_init_dynamic(phb);
+
+ return 0;
}
+
+core_initcall(eeh_dev_phb_init);
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
index c33360ec..5e2805a 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -559,7 +559,9 @@ static struct eeh_ops pseries_eeh_ops = {
* EEH initialization on pseries platform. This function should be
* called before any EEH related functions.
*/
-int __init eeh_pseries_init(void)
+static int __init eeh_pseries_init(void)
{
return eeh_ops_register(&pseries_eeh_ops);
}
+
+early_initcall(eeh_pseries_init);
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 51ecac9..5406473 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -388,10 +388,8 @@ static void __init pSeries_setup_arch(void)
/* Find and initialize PCI host bridges */
init_pci_config_tokens();
- eeh_pseries_init();
find_and_init_phbs();
pSeries_reconfig_notifier_register(&pci_dn_reconfig_nb);
- eeh_init();
pSeries_nvram_init();
--
1.7.5.4
^ permalink raw reply related
* [PATCH 03/21] ppc/eeh: more logs for EEH initialization
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
The patch adds more logs to EEH initialization functions for
debugging purpose. Also, the machine type ("pSeries") is checked
in the platform initialization to assure it's the correct platform
to invoke it.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/eeh_dev.c | 2 ++
arch/powerpc/platforms/pseries/eeh_pseries.c | 13 ++++++++++++-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh_dev.c b/arch/powerpc/platforms/pseries/eeh_dev.c
index 8e3443b..a0cee3a 100644
--- a/arch/powerpc/platforms/pseries/eeh_dev.c
+++ b/arch/powerpc/platforms/pseries/eeh_dev.c
@@ -100,6 +100,8 @@ static int __init eeh_dev_phb_init(void)
list_for_each_entry_safe(phb, tmp, &hose_list, list_node)
eeh_dev_phb_init_dynamic(phb);
+ pr_info("EEH: devices created\n");
+
return 0;
}
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
index 5e2805a..46616c8 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -561,7 +561,18 @@ static struct eeh_ops pseries_eeh_ops = {
*/
static int __init eeh_pseries_init(void)
{
- return eeh_ops_register(&pseries_eeh_ops);
+ int ret = -EINVAL;
+
+ if (!machine_is(pseries))
+ return ret;
+
+ ret = eeh_ops_register(&pseries_eeh_ops);
+ if (!ret)
+ pr_info("EEH: pSeries platform initialized\n");
+ else
+ pr_info("EEH: pSeries platform initialization failure\n");
+
+ return ret;
}
early_initcall(eeh_pseries_init);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 05/21] ppc/eeh: introduce global mutex
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
The patch introduces global mutex for EEH so that the core data
structures can be protected by that. Also, 2 inline functions
are exported for that: eeh_lock() and eeh_unlock().
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 15 +++++++++++++++
arch/powerpc/platforms/pseries/eeh.c | 3 +++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index f77b6d7..248b3d9 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -146,6 +146,17 @@ struct eeh_ops {
extern struct eeh_ops *eeh_ops;
extern int eeh_subsystem_enabled;
+extern struct mutex eeh_mutex;
+
+static inline void eeh_lock(void)
+{
+ mutex_lock(&eeh_mutex);
+}
+
+static inline void eeh_unlock(void)
+{
+ mutex_unlock(&eeh_mutex);
+}
/*
* Max number of EEH freezes allowed before we consider the device
@@ -206,6 +217,10 @@ static inline void eeh_add_device_tree_early(struct device_node *dn) { }
static inline void eeh_add_device_tree_late(struct pci_bus *bus) { }
static inline void eeh_remove_bus_device(struct pci_dev *dev) { }
+
+static inline void eeh_lock(void) { }
+static inline void eeh_unlock(void) { }
+
#define EEH_POSSIBLE_ERROR(val, type) (0)
#define EEH_IO_ERROR_VALUE(size) (-1UL)
#endif /* CONFIG_EEH */
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index e819448..0ba7e3b 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -92,6 +92,9 @@ struct eeh_ops *eeh_ops = NULL;
int eeh_subsystem_enabled;
EXPORT_SYMBOL(eeh_subsystem_enabled);
+/* Global EEH mutex */
+DEFINE_MUTEX(eeh_mutex);
+
/* Lock to avoid races due to multiple reports of an error */
static DEFINE_RAW_SPINLOCK(confirm_error_lock);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 04/21] ppc/eeh: Introduce eeh_pe struct
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
As defined in PAPR 2.4, Partitionable Endpoint (PE) is an I/O subtree
that can be treated as a unit for the purposes of partitioning and error
recovery. Therefore, eeh core should be aware of PE. With eeh_pe struct,
we can support PE explicitly. Further more, it makes all the staff as
data centralized. Another important reason is for eeh core to support
multiple platforms. Some of them like pSeries figures out PEs through
OF nodes while others like powernv have to do that through PCI bus/device
tree. With explicit PE support, eeh core will be implemented based on
the centrialized data and platform dependent implementations figure it
out by their feasible ways.
When the struct is designed, following factors are taken in account:
* Reflecting the relationships of PEs. PE might have parent
as well children.
* Reflecting the association of PE and (eeh) devices.
* PEs have PHB boundary.
* PE should have unique address assigned in the corresponding
PHB domain.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 06dedff..f77b6d7 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -32,6 +32,42 @@ struct device_node;
#ifdef CONFIG_EEH
/*
+ * The struct is used to trace PE related EEH functionality.
+ * In theory, there will have one instance of the struct to
+ * be created against particular PE. In nature, PEs corelate
+ * to each other. the struct has to reflect that hierarchy in
+ * order to easily pick up those affected PEs when one particular
+ * PE has EEH errors.
+ *
+ * Also, one particular PE might be composed of PCI device, PCI
+ * bus and its subordinate components. The struct also need ship
+ * the information. Further more, one particular PE is only meaingful
+ * in the corresponding PHB. Therefore, the root PEs should be created
+ * against existing PHBs in on-to-one fashion.
+ */
+#define EEH_PE_PHB 1 /* PHB PE */
+#define EEH_PE_DEVICE 2 /* Device PE */
+#define EEH_PE_BUS 3 /* Bus PE */
+
+#define EEH_PE_ISOLATED (1 << 0) /* Isolated PE */
+#define EEH_PE_RECOVERING (1 << 1) /* Recovering PE */
+
+struct eeh_pe {
+ int type; /* PE type: PHB/Bus/Device */
+ int state; /* PE EEH dependent mode */
+ int config_addr; /* Traditional PCI address */
+ int addr; /* PE configuration address */
+ struct pci_controller *phb; /* Associated PHB */
+ int check_count; /* Times of ignored error */
+ int freeze_count; /* Times of froze up */
+ int false_positives; /* Times of reported #ff's */
+ struct eeh_pe *parent; /* Parent PE */
+ struct list_head child_list; /* Link PE to the child list */
+ struct list_head edevs; /* Link list of EEH devices */
+ struct list_head child; /* Child PEs */
+};
+
+/*
* The struct is used to trace EEH state for the associated
* PCI device node or PCI device. In future, it might
* represent PE as well so that the EEH device to form
@@ -53,6 +89,8 @@ struct eeh_dev {
int freeze_count; /* Times of froze up */
int false_positives; /* Times of reported #ff's */
u32 config_space[16]; /* Saved PCI config space */
+ struct eeh_pe *pe; /* Associated PE */
+ struct list_head list; /* Form link list in the PE */
struct pci_controller *phb; /* Associated PHB */
struct device_node *dn; /* Associated device node */
struct pci_dev *pdev; /* Associated PCI device */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 06/21] ppc/eeh: Create PEs for PHBs
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
For one particular PE, it's only meaningful in the ancestor PHB
domain. Therefore, each PHB should have its own PE hierarchy tree
to trace those PEs created against the PHB.
The patch creates PEs for the PHBs and put those PEs into the
global link list traced by "eeh_phb_pe". The link list of PEs
would be first level of overall PE hierarchy tree across the
system.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 2 +
arch/powerpc/platforms/pseries/Makefile | 5 +-
arch/powerpc/platforms/pseries/eeh_dev.c | 4 +
arch/powerpc/platforms/pseries/eeh_pe.c | 103 ++++++++++++++++++++++++++++++
4 files changed, 112 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/eeh_pe.c
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 248b3d9..7b9c7d6 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -164,6 +164,8 @@ static inline void eeh_unlock(void)
*/
#define EEH_MAX_ALLOWED_FREEZES 5
+int __devinit eeh_phb_pe_create(struct pci_controller *phb);
+
void * __devinit eeh_dev_init(struct device_node *dn, void *data);
void __devinit eeh_dev_phb_init_dynamic(struct pci_controller *phb);
int __init eeh_ops_register(struct eeh_ops *ops);
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index c222189..890622b 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -6,8 +6,9 @@ obj-y := lpar.o hvCall.o nvram.o reconfig.o \
firmware.o power.o dlpar.o mobility.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SCANLOG) += scanlog.o
-obj-$(CONFIG_EEH) += eeh.o eeh_dev.o eeh_cache.o eeh_driver.o \
- eeh_event.o eeh_sysfs.o eeh_pseries.o
+obj-$(CONFIG_EEH) += eeh.o eeh_pe.o eeh_dev.o eeh_cache.o \
+ eeh_driver.o eeh_event.o eeh_sysfs.o \
+ eeh_pseries.o
obj-$(CONFIG_KEXEC) += kexec.o
obj-$(CONFIG_PCI) += pci.o pci_dlpar.o
obj-$(CONFIG_PSERIES_MSI) += msi.o
diff --git a/arch/powerpc/platforms/pseries/eeh_dev.c b/arch/powerpc/platforms/pseries/eeh_dev.c
index a0cee3a..6644234 100644
--- a/arch/powerpc/platforms/pseries/eeh_dev.c
+++ b/arch/powerpc/platforms/pseries/eeh_dev.c
@@ -65,6 +65,7 @@ void * __devinit eeh_dev_init(struct device_node *dn, void *data)
PCI_DN(dn)->edev = edev;
edev->dn = dn;
edev->phb = phb;
+ INIT_LIST_HEAD(&edev->list);
return NULL;
}
@@ -80,6 +81,9 @@ void __devinit eeh_dev_phb_init_dynamic(struct pci_controller *phb)
{
struct device_node *dn = phb->dn;
+ /* EEH PE for PHB */
+ eeh_phb_pe_create(phb);
+
/* EEH device for PHB */
eeh_dev_init(dn, phb);
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c b/arch/powerpc/platforms/pseries/eeh_pe.c
new file mode 100644
index 0000000..20d65dc
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -0,0 +1,103 @@
+/*
+ * The file intends to implement PE based on the information from
+ * platforms. Basically, there have 3 types of PEs: PHB/Bus/Device.
+ * All the PEs should be organized as hierarchy tree. The first level
+ * of the tree will be associated to existing PHBs since the particular
+ * PE is only meaningful in one PHB domain.
+ *
+ * Copyright Benjamin Herrenschmidt & Gavin Shan, IBM Corporation 2012.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/export.h>
+#include <linux/gfp.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/string.h>
+
+#include <asm/pci-bridge.h>
+#include <asm/ppc-pci.h>
+
+static LIST_HEAD(eeh_phb_pe);
+
+/**
+ * eeh_phb_pe_create - Create PHB PE
+ * @phb: PCI controller
+ *
+ * The function should be called while the PHB is detected during
+ * system boot or PCI hotplug in order to create PHB PE.
+ */
+int __devinit eeh_phb_pe_create(struct pci_controller *phb)
+{
+ struct eeh_pe *pe;
+
+ /* Allocate PHB PE */
+ pe = kzalloc(sizeof(struct eeh_pe), GFP_KERNEL);
+ if (!pe) {
+ pr_err("%s: out of memory!\n", __func__);
+ return -ENOMEM;
+ }
+
+ /* Initialize PHB PE */
+ pe->type = EEH_PE_PHB;
+ pe->phb = phb;
+ INIT_LIST_HEAD(&pe->child_list);
+ INIT_LIST_HEAD(&pe->child);
+ INIT_LIST_HEAD(&pe->edevs);
+
+ /* Put it into the list */
+ eeh_lock();
+ list_add_tail(&pe->child, &eeh_phb_pe);
+ eeh_unlock();
+
+ pr_info("EEH: Add PE for PHB#%d\n", phb->global_number);
+
+ return 0;
+}
+
+/**
+ * eeh_phb_pe_get - Retrieve PHB PE based on the given PHB
+ * @phb: PCI controller
+ *
+ * The overall PEs form hierarchy tree. The first layer of the
+ * hierarchy tree is composed of PHB PEs. The function is used
+ * to retrieve the corresponding PHB PE according to the given PHB.
+ */
+static struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb)
+{
+ struct eeh_pe *pe;
+
+ eeh_lock();
+
+ list_for_each_entry(pe, &eeh_phb_pe, child) {
+ /*
+ * Actually, we needn't check the type since
+ * the PE for PHB has been determined when that
+ * was created.
+ */
+ if (pe->type == EEH_PE_PHB &&
+ pe->phb == phb) {
+ eeh_unlock();
+ return pe;
+ }
+ }
+
+ eeh_unlock();
+
+ return NULL;
+}
+
--
1.7.5.4
^ permalink raw reply related
* [PATCH 07/21] ppc/eeh: Search PE based on requirement
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
The patch implements searching PE based on the following
requirements:
* Search PE according to PE address, which is traditional
PE address that is composed of PCI bus/device/function
number, or unified PE address assigned by firmware or
platform.
* Search parent PE according to the given EEH device. It's
useful when creating new PE and put it into right position.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/pseries/eeh_pe.c | 146 +++++++++++++++++++++++++++++++
2 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 7b9c7d6..1cc1388 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -164,6 +164,7 @@ static inline void eeh_unlock(void)
*/
#define EEH_MAX_ALLOWED_FREEZES 5
+typedef void *(*eeh_traverse_func)(void *data, void *flag);
int __devinit eeh_phb_pe_create(struct pci_controller *phb);
void * __devinit eeh_dev_init(struct device_node *dn, void *data);
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c b/arch/powerpc/platforms/pseries/eeh_pe.c
index 20d65dc..f019953 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -101,3 +101,149 @@ static struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb)
return NULL;
}
+/**
+ * eeh_pe_next - Retrieve the next PE in the tree
+ * @pe: current PE
+ * @root: root PE
+ *
+ * The function is used to retrieve the next PE in the
+ * hierarchy PE tree.
+ */
+static struct eeh_pe *eeh_pe_next(struct eeh_pe *pe,
+ struct eeh_pe *root)
+{
+ struct list_head *next = pe->child_list.next;
+
+ if (next == &pe->child_list) {
+ while (1) {
+ if (pe == root)
+ return NULL;
+ next = pe->child.next;
+ if (next != &pe->parent->child_list)
+ break;
+ pe = pe->parent;
+ }
+ }
+
+ return list_entry(next, struct eeh_pe, child);
+}
+
+/**
+ * eeh_pe_traverse - Traverse PEs in the specified PHB
+ * @root: root PE
+ * @fn: callback
+ * @flag: extra parameter to callback
+ *
+ * The function is used to traverse the specified PE and its
+ * child PEs. The traversing is to be terminated once the
+ * callback returns something other than NULL, or no more PEs
+ * to be traversed.
+ */
+static void *eeh_pe_traverse(struct eeh_pe *root,
+ eeh_traverse_func fn, void *flag)
+{
+ struct eeh_pe *pe;
+ void *ret;
+
+ for (pe = root; pe; pe = eeh_pe_next(pe, root)) {
+ ret = fn(pe, flag);
+ if (ret) return ret;
+ }
+
+ return NULL;
+}
+
+/**
+ * __eeh_pe_get - Check the PE address
+ * @data: EEH PE
+ * @flag: EEH device
+ *
+ * For one particular PE, it can be identified by PE address
+ * or tranditional BDF address. BDF address is composed of
+ * Bus/Device/Function number. The extra data referred by flag
+ * indicates which type of address should be used.
+ */
+static void *__eeh_pe_get(void *data, void *flag)
+{
+ struct eeh_pe *pe = (struct eeh_pe *)data;
+ struct eeh_dev *edev = (struct eeh_dev *)flag;
+
+ /* Unexpected PHB PE */
+ if (pe->type == EEH_PE_PHB)
+ return NULL;
+
+ /* We prefer PE address */
+ if (edev->pe_config_addr &&
+ (edev->pe_config_addr == pe->addr))
+ return pe;
+
+ /* Try BDF address */
+ if (edev->pe_config_addr &&
+ (edev->config_addr == pe->config_addr))
+ return pe;
+
+ return NULL;
+}
+
+/**
+ * eeh_pe_get - Search PE based on the given address
+ * @edev: EEH device
+ *
+ * Search the corresponding PE based on the specified address which
+ * is included in the eeh device. The function is used to check if
+ * the associated PE has been created against the PE address. It's
+ * notable that the PE address has 2 format: traditional PE address
+ * which is composed of PCI bus/device/function number, or unified
+ * PE address.
+ */
+static struct eeh_pe *eeh_pe_get(struct eeh_dev *edev)
+{
+ struct eeh_pe *root = eeh_phb_pe_get(edev->phb);
+ struct eeh_pe *pe;
+
+ eeh_lock();
+ pe = eeh_pe_traverse(root, __eeh_pe_get, edev);
+ eeh_unlock();
+
+ return pe;
+}
+
+/**
+ * eeh_pe_get_parent - Retrieve the parent PE
+ * @edev: EEH device
+ *
+ * The whole PEs existing in the system are organized as hierarchy
+ * tree. The function is used to retrieve the parent PE according
+ * to the parent EEH device.
+ */
+static struct eeh_pe *eeh_pe_get_parent(struct eeh_dev *edev)
+{
+ struct device_node *dn;
+ struct eeh_dev *parent;
+
+ /*
+ * It might have the case for the indirect parent
+ * EEH device already having associated PE, but
+ * the direct parent EEH device doesn't have yet.
+ */
+ dn = edev->dn->parent;
+ while (dn) {
+ /* We're poking out of PCI territory */
+ if (!PCI_DN(dn))
+ return NULL;
+
+ parent = of_node_to_eeh_dev(dn);
+
+ /* We're poking out of PCI territory */
+ if (!parent)
+ return NULL;
+
+ if (parent->pe)
+ return parent->pe;
+
+ dn = dn->parent;
+ }
+
+ return NULL;
+}
+
--
1.7.5.4
^ permalink raw reply related
* [PATCH 08/21] ppc/eeh: create PEs duing EEH initialization
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
The patch creates PEs and associated the newly created PEs with
it parent/silbing as well as EEH devices. It would become more
straight to trace EEH errors and recover them accordingly.
Once the EEH functionality on one PCI IOA has been enabled, we
tries to create PE against it. If there's existing PE, to which
the current PCI IOA should be attached, the existing PE will be
converted from "device" type to "bus" type accordingly.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/pseries/eeh.c | 6 ++
arch/powerpc/platforms/pseries/eeh_pe.c | 89 +++++++++++++++++++++++++++++++
3 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 1cc1388..e41107d 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -166,6 +166,7 @@ static inline void eeh_unlock(void)
typedef void *(*eeh_traverse_func)(void *data, void *flag);
int __devinit eeh_phb_pe_create(struct pci_controller *phb);
+int eeh_pe_create(struct eeh_dev *edev);
void * __devinit eeh_dev_init(struct device_node *dn, void *data);
void __devinit eeh_dev_phb_init_dynamic(struct pci_controller *phb);
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 0ba7e3b..99937da 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -895,6 +895,8 @@ static void *eeh_early_enable(struct device_node *dn, void *data)
eeh_subsystem_enabled = 1;
edev->mode |= EEH_MODE_SUPPORTED;
+ eeh_pe_create(edev);
+
pr_debug("EEH: %s: eeh enabled, config=%x pe_config=%x\n",
dn->full_name, edev->config_addr,
edev->pe_config_addr);
@@ -908,6 +910,10 @@ static void *eeh_early_enable(struct device_node *dn, void *data)
/* Parent supports EEH. */
edev->mode |= EEH_MODE_SUPPORTED;
edev->config_addr = of_node_to_eeh_dev(dn->parent)->config_addr;
+ edev->pe_config_addr = of_node_to_eeh_dev(dn->parent)->pe_config_addr;
+
+ eeh_pe_create(edev);
+
return NULL;
}
}
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c b/arch/powerpc/platforms/pseries/eeh_pe.c
index f019953..56aab91 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -247,3 +247,92 @@ static struct eeh_pe *eeh_pe_get_parent(struct eeh_dev *edev)
return NULL;
}
+/**
+ * eeh_pe_create - Create EEH PE according to EEH device
+ * @edev: EEH device
+ *
+ * Create EEH PE according to the specified EEH device and
+ * put the EEH PE into appropriate place in the PE hierarchy
+ * tree.
+ */
+int eeh_pe_create(struct eeh_dev *edev)
+{
+ struct eeh_pe *pe, *parent;
+
+ /*
+ * Search the PE has been existing or not according
+ * to the PE address. If that has been existing, the
+ * PE should be composed of PCI bus and its subordinate
+ * components.
+ */
+ pe = eeh_pe_get(edev);
+ if (pe) {
+ if (!edev->pe_config_addr) {
+ pr_err("%s: PE with addr 0x%x already exists\n",
+ __func__, edev->config_addr);
+ return -EEXIST;
+ }
+
+ /* Mark the PE as type of PCI bus */
+ pe->type = EEH_PE_BUS;
+ edev->pe = pe;
+
+ /* Put the edev to PE */
+ list_add_tail(&edev->list, &pe->edevs);
+
+ pr_info("EEH: Add %s to Bus PE#%x\n",
+ edev->dn->full_name, pe->addr);
+
+ return 0;
+ }
+
+ /* Create a new EEH PE */
+ pe = kzalloc(sizeof(struct eeh_pe), GFP_KERNEL);
+ if (!pe) {
+ pr_err("%s: out of memory!\n", __func__);
+ return -ENOMEM;
+ }
+ pe->addr = edev->pe_config_addr;
+ pe->config_addr = edev->config_addr;
+ pe->type = EEH_PE_DEVICE;
+ pe->phb = edev->phb;
+ INIT_LIST_HEAD(&pe->child_list);
+ INIT_LIST_HEAD(&pe->child);
+ INIT_LIST_HEAD(&pe->edevs);
+
+ /*
+ * Put the new EEH PE into hierarchy tree. If the parent
+ * can't be found, the newly created PE will be attached
+ * to PHB directly. Otherwise, we have to associate the
+ * PE with its parent.
+ */
+ parent = eeh_pe_get_parent(edev);
+ if (!parent) {
+ parent = eeh_phb_pe_get(edev->phb);
+ if (!parent) {
+ pr_err("%s: No PHB PE is found (PHB Domain=%d)\n",
+ __func__, edev->phb->global_number);
+ edev->pe = NULL;
+ kfree(pe);
+ return -EEXIST;
+ }
+
+ pe->parent = parent;
+ } else {
+ pe->parent = parent;
+ }
+
+ /*
+ * Put the newly created PE into the child list and
+ * link the EEH device accordingly.
+ */
+ list_add_tail(&pe->child, &parent->child_list);
+ list_add_tail(&edev->list, &pe->edevs);
+ edev->pe = pe;
+
+ pr_info("EEH: Add %s to Device PE#%x, Parent PE#%x\n",
+ edev->dn->full_name, pe->addr, pe->parent->addr);
+
+ return 0;
+}
+
--
1.7.5.4
^ permalink raw reply related
* [PATCH 09/21] ppc/eeh: remove PE at appropriate time
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
During PCI hotplug and EEH recovery, the PE hierarchy PE might be
changed due to the PCI topology changes. At later point when the
PCI device is added, the PE will be created dynamically again.
The patch introduces new function to remove EEH devices from the
associated PE. That also can cause that the parent PE is removed
from the PE tree if the parent PE doesn't include valid EEH devices
and child PEs.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/pseries/eeh.c | 1 +
arch/powerpc/platforms/pseries/eeh_pe.c | 46 +++++++++++++++++++++++++++++++
3 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index e41107d..fd69584 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -167,6 +167,7 @@ static inline void eeh_unlock(void)
typedef void *(*eeh_traverse_func)(void *data, void *flag);
int __devinit eeh_phb_pe_create(struct pci_controller *phb);
int eeh_pe_create(struct eeh_dev *edev);
+int eeh_pe_remove(struct eeh_dev *edev);
void * __devinit eeh_dev_init(struct device_node *dn, void *data);
void __devinit eeh_dev_phb_init_dynamic(struct pci_controller *phb);
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 99937da..82a5fdc 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -1156,6 +1156,7 @@ static void eeh_remove_device(struct pci_dev *dev)
dev->dev.archdata.edev = NULL;
pci_dev_put(dev);
+ eeh_pe_remove(edev);
pci_addr_cache_remove_device(dev);
eeh_sysfs_remove_device(dev);
}
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c b/arch/powerpc/platforms/pseries/eeh_pe.c
index 56aab91..ed675b8 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -336,3 +336,49 @@ int eeh_pe_create(struct eeh_dev *edev)
return 0;
}
+/**
+ * eeh_pe_remove - Remove one EEH device from the associated PE
+ * @edev: EEH device
+ *
+ * The PE hierarchy tree might be changed when doing PCI hotplug.
+ * Also, the PCI devices or buses could be removed from the system
+ * during EEH recovery.
+ */
+int eeh_pe_remove(struct eeh_dev *edev)
+{
+ struct eeh_pe *pe, *parent;
+
+ if (!edev->pe) {
+ pr_err("%s: No PE found for EEH device %s\n",
+ __func__, edev->dn->full_name);
+ return -EEXIST;
+ }
+
+ /* Remove the EEH device */
+ pe = edev->pe;
+ edev->pe = NULL;
+ list_del(&edev->list);
+
+ /*
+ * Check if the parent PE includes any EEH devices.
+ * If not, we should delete that. Also, we should
+ * delete the parent PE if it doesn't have associated
+ * child PEs and EEH devices.
+ */
+ while (1) {
+ parent = pe->parent;
+ if (pe->type & EEH_PE_PHB)
+ break;
+
+ if (list_empty(&pe->edevs) &&
+ list_empty(&pe->child_list)) {
+ list_del(&pe->child);
+ kfree(pe);
+ }
+
+ pe = parent;
+ }
+
+ return 0;
+}
+
--
1.7.5.4
^ permalink raw reply related
* [PATCH 10/21] ppc/eeh: build EEH event based on PE
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
The original implementation builds EEH event based on EEH device.
We already had dedicated struct to depict PE. It's reasonable to
build EEH event based on PE.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh_event.h | 4 +-
arch/powerpc/platforms/pseries/eeh_event.c | 29 +++++++--------------------
2 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh_event.h b/arch/powerpc/include/asm/eeh_event.h
index c68b012..dc722b5 100644
--- a/arch/powerpc/include/asm/eeh_event.h
+++ b/arch/powerpc/include/asm/eeh_event.h
@@ -28,10 +28,10 @@
*/
struct eeh_event {
struct list_head list; /* to form event queue */
- struct eeh_dev *edev; /* EEH device */
+ struct eeh_pe *pe; /* EEH PE */
};
-int eeh_send_failure_event(struct eeh_dev *edev);
+int eeh_send_failure_event(struct eeh_pe *pe);
struct eeh_dev *handle_eeh_events(struct eeh_event *);
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/platforms/pseries/eeh_event.c b/arch/powerpc/platforms/pseries/eeh_event.c
index 6132772..7f89f1e 100644
--- a/arch/powerpc/platforms/pseries/eeh_event.c
+++ b/arch/powerpc/platforms/pseries/eeh_event.c
@@ -119,36 +119,23 @@ static void eeh_thread_launcher(struct work_struct *dummy)
/**
* eeh_send_failure_event - Generate a PCI error event
- * @edev: EEH device
+ * @pe: EEH PE
*
* This routine can be called within an interrupt context;
* the actual event will be delivered in a normal context
* (from a workqueue).
*/
-int eeh_send_failure_event(struct eeh_dev *edev)
+int eeh_send_failure_event(struct eeh_pe *pe)
{
unsigned long flags;
struct eeh_event *event;
- struct device_node *dn = eeh_dev_to_of_node(edev);
- const char *location;
-
- if (!mem_init_done) {
- printk(KERN_ERR "EEH: event during early boot not handled\n");
- location = of_get_property(dn, "ibm,loc-code", NULL);
- printk(KERN_ERR "EEH: device node = %s\n", dn->full_name);
- printk(KERN_ERR "EEH: PCI location = %s\n", location);
- return 1;
- }
- event = kzalloc(sizeof(*event), GFP_ATOMIC);
- if (event == NULL) {
- printk(KERN_ERR "EEH: out of memory, event not handled\n");
- return 1;
- }
-
- if (edev->pdev)
- pci_dev_get(edev->pdev);
- event->edev = edev;
+ event = kzalloc(sizeof(*event), GFP_ATOMIC);
+ if (!event) {
+ pr_err("EEH: out of memory, event not handled\n");
+ return -ENOMEM;
+ }
+ event->pe = pe;
/* We may or may not be called in an interrupt context */
spin_lock_irqsave(&eeh_eventlist_lock, flags);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 11/21] ppc/eeh: trace EEH state based on PE
From: Gavin Shan @ 2012-09-05 6:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gavin Shan
In-Reply-To: <1346825696-13960-1-git-send-email-shangw@linux.vnet.ibm.com>
Since we've introduced dedicated struct to trace individual PEs,
it's reasonable to trace its state through the dedicated struct
instead of using "eeh_dev" any more.
The patches implements the state tracing based on PE. It's notable
that the PE state will be applied to the specified PE as well as
its child PEs. That complies with the rule that problematic parent
PE will prevent those child PEs from working properly.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 3 +
arch/powerpc/include/asm/ppc-pci.h | 4 +-
arch/powerpc/platforms/pseries/eeh.c | 102 -------------------------------
arch/powerpc/platforms/pseries/eeh_pe.c | 79 ++++++++++++++++++++++++
4 files changed, 84 insertions(+), 104 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index fd69584..493dc7c 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -67,6 +67,9 @@ struct eeh_pe {
struct list_head child; /* Child PEs */
};
+#define eeh_pe_for_each_dev(pe, edev) \
+ list_for_each_entry(edev, &pe->edevs, list)
+
/*
* The struct is used to trace EEH state for the associated
* PCI device node or PCI device. In future, it might
diff --git a/arch/powerpc/include/asm/ppc-pci.h b/arch/powerpc/include/asm/ppc-pci.h
index 80fa704..c7e5bd6 100644
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@ -57,8 +57,8 @@ int eeh_reset_pe(struct eeh_dev *);
void eeh_restore_bars(struct eeh_dev *);
int rtas_write_config(struct pci_dn *, int where, int size, u32 val);
int rtas_read_config(struct pci_dn *, int where, int size, u32 *val);
-void eeh_mark_slot(struct device_node *dn, int mode_flag);
-void eeh_clear_slot(struct device_node *dn, int mode_flag);
+void eeh_pe_state_mark(struct eeh_pe *pe, int state);
+void eeh_pe_state_clear(struct eeh_pe *pe, int state);
struct device_node *eeh_find_device_pe(struct device_node *dn);
void eeh_sysfs_add_device(struct pci_dev *pdev);
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 82a5fdc..c527c46 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -279,108 +279,6 @@ struct device_node *eeh_find_device_pe(struct device_node *dn)
}
/**
- * __eeh_mark_slot - Mark all child devices as failed
- * @parent: parent device
- * @mode_flag: failure flag
- *
- * Mark all devices that are children of this device as failed.
- * Mark the device driver too, so that it can see the failure
- * immediately; this is critical, since some drivers poll
- * status registers in interrupts ... If a driver is polling,
- * and the slot is frozen, then the driver can deadlock in
- * an interrupt context, which is bad.
- */
-static void __eeh_mark_slot(struct device_node *parent, int mode_flag)
-{
- struct device_node *dn;
-
- for_each_child_of_node(parent, dn) {
- if (of_node_to_eeh_dev(dn)) {
- /* Mark the pci device driver too */
- struct pci_dev *dev = of_node_to_eeh_dev(dn)->pdev;
-
- of_node_to_eeh_dev(dn)->mode |= mode_flag;
-
- if (dev && dev->driver)
- dev->error_state = pci_channel_io_frozen;
-
- __eeh_mark_slot(dn, mode_flag);
- }
- }
-}
-
-/**
- * eeh_mark_slot - Mark the indicated device and its children as failed
- * @dn: parent device
- * @mode_flag: failure flag
- *
- * Mark the indicated device and its child devices as failed.
- * The device drivers are marked as failed as well.
- */
-void eeh_mark_slot(struct device_node *dn, int mode_flag)
-{
- struct pci_dev *dev;
- dn = eeh_find_device_pe(dn);
-
- /* Back up one, since config addrs might be shared */
- if (!pcibios_find_pci_bus(dn) && of_node_to_eeh_dev(dn->parent))
- dn = dn->parent;
-
- of_node_to_eeh_dev(dn)->mode |= mode_flag;
-
- /* Mark the pci device too */
- dev = of_node_to_eeh_dev(dn)->pdev;
- if (dev)
- dev->error_state = pci_channel_io_frozen;
-
- __eeh_mark_slot(dn, mode_flag);
-}
-
-/**
- * __eeh_clear_slot - Clear failure flag for the child devices
- * @parent: parent device
- * @mode_flag: flag to be cleared
- *
- * Clear failure flag for the child devices.
- */
-static void __eeh_clear_slot(struct device_node *parent, int mode_flag)
-{
- struct device_node *dn;
-
- for_each_child_of_node(parent, dn) {
- if (of_node_to_eeh_dev(dn)) {
- of_node_to_eeh_dev(dn)->mode &= ~mode_flag;
- of_node_to_eeh_dev(dn)->check_count = 0;
- __eeh_clear_slot(dn, mode_flag);
- }
- }
-}
-
-/**
- * eeh_clear_slot - Clear failure flag for the indicated device and its children
- * @dn: parent device
- * @mode_flag: flag to be cleared
- *
- * Clear failure flag for the indicated device and its children.
- */
-void eeh_clear_slot(struct device_node *dn, int mode_flag)
-{
- unsigned long flags;
- raw_spin_lock_irqsave(&confirm_error_lock, flags);
-
- dn = eeh_find_device_pe(dn);
-
- /* Back up one, since config addrs might be shared */
- if (!pcibios_find_pci_bus(dn) && of_node_to_eeh_dev(dn->parent))
- dn = dn->parent;
-
- of_node_to_eeh_dev(dn)->mode &= ~mode_flag;
- of_node_to_eeh_dev(dn)->check_count = 0;
- __eeh_clear_slot(dn, mode_flag);
- raw_spin_unlock_irqrestore(&confirm_error_lock, flags);
-}
-
-/**
* eeh_dn_check_failure - Check if all 1's data is due to EEH slot freeze
* @dn: device node
* @dev: pci device, if known
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c b/arch/powerpc/platforms/pseries/eeh_pe.c
index ed675b8..3041e32 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -382,3 +382,82 @@ int eeh_pe_remove(struct eeh_dev *edev)
return 0;
}
+/**
+ * __eeh_pe_state_mark - Mark the state for the PE
+ * @data: EEH PE
+ * @flag: state
+ *
+ * The function is used to mark the indicated state for the given
+ * PE. Also, the associated PCI devices will be put into IO frozen
+ * state as well.
+ */
+static void *__eeh_pe_state_mark(void *data, void *flag)
+{
+ struct eeh_pe *pe = (struct eeh_pe *)data;
+ int state = *((int *)flag);
+ struct eeh_dev *tmp;
+ struct pci_dev *pdev;
+
+ /*
+ * Mark the PE with the indicated state. Also,
+ * the associated PCI device will be put into
+ * I/O frozen state to avoid I/O accesses from
+ * the PCI device driver.
+ */
+ pe->state |= state;
+ eeh_pe_for_each_dev(pe, tmp) {
+ pdev = eeh_dev_to_pci_dev(tmp);
+ if (pdev)
+ pdev->error_state = pci_channel_io_frozen;
+ }
+
+ return NULL;
+}
+
+/**
+ * eeh_pe_state_mark - Mark specified state for PE and its associated device
+ * @pe: EEH PE
+ *
+ * EEH error affects the current PE and its child PEs. The function
+ * is used to mark appropriate state for the affected PEs and the
+ * associated devices.
+ */
+void eeh_pe_state_mark(struct eeh_pe *pe, int state)
+{
+ eeh_pe_traverse(pe, __eeh_pe_state_mark, &state);
+}
+
+/**
+ * __eeh_pe_state_clear - Clear state for the PE
+ * @data: EEH PE
+ * @flag: state
+ *
+ * The function is used to clear the indicated state from the
+ * given PE. Besides, we also clear the check count of the PE
+ * as well.
+ */
+static void *__eeh_pe_state_clear(void *data, void *flag)
+{
+ struct eeh_pe *pe = (struct eeh_pe *)data;
+ int state = *((int *)flag);
+
+ pe->state &= ~state;
+ pe->check_count = 0;
+
+ return NULL;
+}
+
+/**
+ * eeh_pe_state_clear - Clear state for the PE and its children
+ * @pe: PE
+ * @state: state to be cleared
+ *
+ * When the PE and its children has been recovered from error,
+ * we need clear the error state for that. The function is used
+ * for the purpose.
+ */
+void eeh_pe_state_clear(struct eeh_pe *pe, int state)
+{
+ eeh_pe_traverse(pe, __eeh_pe_state_clear, &state);
+}
+
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox