* Re: Re: [PATCH v4] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Michael Ellerman @ 2014-07-02 4:41 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Jeremy Fitzhardinge, linux-ia64, sparse,
Linux Kernel Mailing List, Paul Mackerras, H. Peter Anvin,
akataria, linux-tip-commits, anil.s.keshavamurthy, Ingo Molnar,
Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, Thomas Gleixner, Tony Luck,
Kevin Hao, Linus Torvalds, rdunlap, Tony Luck, dl9pf,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <53B21B0E.8010707@hitachi.com>
On Tue, 2014-07-01 at 11:21 +0900, Masami Hiramatsu wrote:
> (2014/06/30 20:36), Michael Ellerman wrote:
> > On Mon, 2014-06-30 at 12:14 +0900, Masami Hiramatsu wrote:
> >> Ping? :)
> >
> > Yeah sorry. I started looking at this and got dragged into another mess.
> >
> > You seem to have duplicated the functionality of arch_deref_entry_point(),
> > which was also added for kprobes, and for the same reason - ie. because some
> > arches have strange function pointers. Is there some reason you can't use it?
>
> Ah, right! Hmm, it seems some more work to update it. but basically, we can do.
> BTW, is there any other users who need to access the actual function entry (for
> kallsyms case)?
Not that I'm aware of. We have had function descriptors on 64-bit powerpc for
ever, so in theory by now we should have already found any cases where we need
that sort of wrapper.
cheers
^ permalink raw reply
* Re: [PATCH 2/6] KVM: PPC: BOOK3S: HV: Deny virtual page class key update via h_protect
From: Paul Mackerras @ 2014-07-02 4:50 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <1404040655-12076-4-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Sun, Jun 29, 2014 at 04:47:31PM +0530, Aneesh Kumar K.V wrote:
> This makes it consistent with h_enter where we clear the key
> bits. We also want to use virtual page class key protection mechanism
> for indicating host page fault. For that we will be using key class
> index 30 and 31. So prevent the guest from updating key bits until
> we add proper support for virtual page class protection mechanism for
> the guest. This will not have any impact for PAPR linux guest because
> Linux guest currently don't use virtual page class key protection model
As things stand, without this patch series, we do actually have
everything we need in the kernel for guests to use virtual page class
keys. Arguably we should have a capability to tell userspace how many
storage keys the guest can use, but that's the only missing piece as
far as I can see.
If we add such a capability, I can't see any reason why we should need
to disable guest use of storage keys in this patchset.
Paul.
^ permalink raw reply
* Re: [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte update
From: Paul Mackerras @ 2014-07-02 5:41 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <1404040655-12076-7-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Sun, Jun 29, 2014 at 04:47:34PM +0530, Aneesh Kumar K.V wrote:
> As per ISA, we first need to mark hpte invalid (V=0) before we update
> the hpte lower half bits. With virtual page class key protection mechanism we want
> to send any fault other than key fault to guest directly without
> searching the hash page table. But then we can get NO_HPTE fault while
> we are updating the hpte. To track that add a vm specific atomic
> variable that we check in the fault path to always send the fault
> to host.
[...]
> @@ -750,13 +751,15 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct kvm_vcpu *vcpu,
> r &= rcbits | ~(HPTE_R_R | HPTE_R_C);
>
> if (be64_to_cpu(hptep[0]) & HPTE_V_VALID) {
> - /* HPTE was previously valid, so we need to invalidate it */
> + /*
> + * If we had mapped this hpte before, we now need to
> + * invalidate that.
> + */
> unlock_rmap(rmap);
> - /* Always mark HPTE_V_ABSENT before invalidating */
> - kvmppc_unmap_host_hpte(kvm, hptep);
> kvmppc_invalidate_hpte(kvm, hptep, index);
> /* don't lose previous R and C bits */
> r |= be64_to_cpu(hptep[1]) & (HPTE_R_R | HPTE_R_C);
> + hpte_invalidated = true;
So now we're not setting the ABSENT bit before invalidating the HPTE.
That means that another guest vcpu could do an H_ENTER which could
think that this HPTE is free and use it for another unrelated guest
HPTE, which would be bad...
> @@ -1144,8 +1149,8 @@ static int kvm_test_clear_dirty_npages(struct kvm *kvm, unsigned long *rmapp)
> npages_dirty = n;
> eieio();
> }
> - kvmppc_map_host_hpte(kvm, &v, &r);
> - hptep[0] = cpu_to_be64(v & ~HPTE_V_HVLOCK);
> + hptep[0] = cpu_to_be64(v & ~HPTE_V_LOCK);
> + atomic_dec(&kvm->arch.hpte_update_in_progress);
Why are we using LOCK rather than HVLOCK now? (And why didn't you
mention this change and its rationale in the patch description?)
Paul.
^ permalink raw reply
* Re: Re: Re: [PATCH v4] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Masami Hiramatsu @ 2014-07-02 6:39 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jeremy Fitzhardinge, linux-ia64, sparse,
Linux Kernel Mailing List, Paul Mackerras, H. Peter Anvin,
akataria, linux-tip-commits, anil.s.keshavamurthy, Ingo Molnar,
Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, Thomas Gleixner, Tony Luck,
Kevin Hao, Linus Torvalds, rdunlap, Tony Luck, dl9pf,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1404276081.7254.1.camel@concordia>
(2014/07/02 13:41), Michael Ellerman wrote:
> On Tue, 2014-07-01 at 11:21 +0900, Masami Hiramatsu wrote:
>> (2014/06/30 20:36), Michael Ellerman wrote:
>>> On Mon, 2014-06-30 at 12:14 +0900, Masami Hiramatsu wrote:
>>>> Ping? :)
>>>
>>> Yeah sorry. I started looking at this and got dragged into another mess.
>>>
>>> You seem to have duplicated the functionality of arch_deref_entry_point(),
>>> which was also added for kprobes, and for the same reason - ie. because some
>>> arches have strange function pointers. Is there some reason you can't use it?
>>
>> Ah, right! Hmm, it seems some more work to update it. but basically, we can do.
>> BTW, is there any other users who need to access the actual function entry (for
>> kallsyms case)?
>
> Not that I'm aware of. We have had function descriptors on 64-bit powerpc for
> ever, so in theory by now we should have already found any cases where we need
> that sort of wrapper.
OK, then I'll update this patch to use arch_deref_entry_point(), and add additional
patch which update to support PPC64 ABIv2.
Thank you!
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply
* Re: Re: Re: [PATCH v4] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Michael Ellerman @ 2014-07-02 6:56 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Jeremy Fitzhardinge, linux-ia64, sparse,
Linux Kernel Mailing List, Paul Mackerras, H. Peter Anvin,
akataria, linux-tip-commits, anil.s.keshavamurthy, Ingo Molnar,
Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, Thomas Gleixner, Tony Luck,
Kevin Hao, Linus Torvalds, rdunlap, Tony Luck, dl9pf,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <53B3A91D.2040107@hitachi.com>
On Wed, 2014-07-02 at 15:39 +0900, Masami Hiramatsu wrote:
> (2014/07/02 13:41), Michael Ellerman wrote:
> > On Tue, 2014-07-01 at 11:21 +0900, Masami Hiramatsu wrote:
> >> (2014/06/30 20:36), Michael Ellerman wrote:
> >>> On Mon, 2014-06-30 at 12:14 +0900, Masami Hiramatsu wrote:
> >>>> Ping? :)
> >>>
> >>> Yeah sorry. I started looking at this and got dragged into another mess.
> >>>
> >>> You seem to have duplicated the functionality of arch_deref_entry_point(),
> >>> which was also added for kprobes, and for the same reason - ie. because some
> >>> arches have strange function pointers. Is there some reason you can't use it?
> >>
> >> Ah, right! Hmm, it seems some more work to update it. but basically, we can do.
> >> BTW, is there any other users who need to access the actual function entry (for
> >> kallsyms case)?
> >
> > Not that I'm aware of. We have had function descriptors on 64-bit powerpc for
> > ever, so in theory by now we should have already found any cases where we need
> > that sort of wrapper.
>
> OK, then I'll update this patch to use arch_deref_entry_point(), and add additional
> patch which update to support PPC64 ABIv2.
I've already done the latter:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2f0143c91d30823f6f6e7d94d7fa818f7ab18a18
cheers
^ permalink raw reply
* [PATCH v5 1/2] kprobes/powerpc: Fix arch_deref_entry_point to support ABIv2
From: Masami Hiramatsu @ 2014-07-02 7:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Tony Luck
Cc: Jeremy Fitzhardinge, Rusty Russell, Anoop Thomas Mathew,
Andrew Morton, Arnd Bergmann, linux-tip-commits, Jiri Kosina,
sparse, rdunlap, H. Peter Anvin, Linux Kernel Mailing List,
anil.s.keshavamurthy, Ingo Molnar, Chris Wright, linuxppc-dev,
Thomas Gleixner, dl9pf, yrl.pp-manager.tt, akataria,
Linus Torvalds, David S. Miller
In-Reply-To: <1404276081.7254.1.camel@concordia>
Since PowerPC64 ABIv2 doesn't have function descriptor
any more, arch_deref_entry_point(), which returns function
entry point from function descriptor, should be updated.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anoop Thomas Mathew <atm@profoundis.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/kprobes.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 90fab64..72a1034 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -491,7 +491,12 @@ int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
return ret;
}
-#ifdef CONFIG_PPC64
+#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
+/*
+ * On PPC64 ABIv1 the function pointer actually points to the
+ * function's descriptor. The first entry in the descriptor is the
+ * address of the function text.
+ */
unsigned long arch_deref_entry_point(void *entry)
{
return ((func_descr_t *)entry)->entry;
^ permalink raw reply related
* [PATCH v5 2/2] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Masami Hiramatsu @ 2014-07-02 7:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Tony Luck
Cc: Jeremy Fitzhardinge, linux-ia64, sparse, H. Peter Anvin, akataria,
linux-tip-commits, anil.s.keshavamurthy, Ingo Molnar,
Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, Thomas Gleixner, Tony Luck,
Kevin Hao, Linus Torvalds, rdunlap, Linux Kernel Mailing List,
dl9pf, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1404276081.7254.1.camel@concordia>
On ia64 and ppc64, the function pointer does not point the
entry address of the function, but the address of function
discriptor (which contains the entry address and misc
data.) Since the kprobes passes the function pointer stored
by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
initalizing its blacklist, it fails and reports many errors
as below.
Failed to find blacklist 0001013168300000
Failed to find blacklist 0001013000f0a000
Failed to find blacklist 000101315f70a000
Failed to find blacklist 000101324c80a000
Failed to find blacklist 0001013063f0a000
Failed to find blacklist 000101327800a000
Failed to find blacklist 0001013277f0a000
Failed to find blacklist 000101315a70a000
Failed to find blacklist 0001013277e0a000
Failed to find blacklist 000101305a20a000
Failed to find blacklist 0001013277d0a000
Failed to find blacklist 00010130bdc0a000
Failed to find blacklist 00010130dc20a000
Failed to find blacklist 000101309a00a000
Failed to find blacklist 0001013277c0a000
Failed to find blacklist 0001013277b0a000
Failed to find blacklist 0001013277a0a000
Failed to find blacklist 000101327790a000
Failed to find blacklist 000101303140a000
Failed to find blacklist 0001013a3280a000
To fix this bug, this introduces function_entry() macro to
retrieve the entry address from the given function pointer,
and uses for kallsyms_lookup_size_offset() while initializing
blacklist.
Changes in v5:
- Use arch_deref_entry_point() instead of function_entry().
Changes in v4:
- Add kernel_text_address() check for verifying the address.
- Moved on the latest linus tree.
Changes in v3:
- Fix a bug to get blacklist address based on function entry
instead of function descriptor. (Suzuki's work, Thanks!)
Changes in V2:
- Use function_entry() macro when lookin up symbols instead
of storing it.
- Update for the latest -next.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Reported-by: Tony Luck <tony.luck@gmail.com>
Tested-by: Tony Luck <tony.luck@intel.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Suzuki K. Poulose <suzuki@in.ibm.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Kevin Hao <haokexin@gmail.com>
Cc: linux-ia64@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
---
kernel/kprobes.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 3214289..ec370cc 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -32,6 +32,7 @@
* <prasanna@in.ibm.com> added function-return probes.
*/
#include <linux/kprobes.h>
+#include <linux/types.h>
#include <linux/hash.h>
#include <linux/init.h>
#include <linux/slab.h>
@@ -2037,19 +2038,23 @@ static int __init populate_kprobe_blacklist(unsigned long *start,
{
unsigned long *iter;
struct kprobe_blacklist_entry *ent;
- unsigned long offset = 0, size = 0;
+ unsigned long entry, offset = 0, size = 0;
for (iter = start; iter < end; iter++) {
- if (!kallsyms_lookup_size_offset(*iter, &size, &offset)) {
- pr_err("Failed to find blacklist %p\n", (void *)*iter);
+ entry = arch_deref_entry_point((void *)*iter);
+
+ if (!kernel_text_address(entry) ||
+ !kallsyms_lookup_size_offset(entry, &size, &offset)) {
+ pr_err("Failed to find blacklist at %p\n",
+ (void *)entry);
continue;
}
ent = kmalloc(sizeof(*ent), GFP_KERNEL);
if (!ent)
return -ENOMEM;
- ent->start_addr = *iter;
- ent->end_addr = *iter + size;
+ ent->start_addr = entry;
+ ent->end_addr = entry + size;
INIT_LIST_HEAD(&ent->list);
list_add_tail(&ent->list, &kprobe_blacklist);
}
^ permalink raw reply related
* Re: [PATCH v4] flexcan: add err_irq handler for flexcan
From: Marc Kleine-Budde @ 2014-07-02 7:04 UTC (permalink / raw)
To: qiang.zhao@freescale.com, linuxppc-dev@lists.ozlabs.org,
wg@grandegger.com, linux-can@vger.kernel.org, Scott Wood
In-Reply-To: <a77a3b25e46f45c4951e0ec517904460@BLUPR03MB341.namprd03.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
On 07/02/2014 04:00 AM, qiang.zhao@freescale.com wrote:
>>> +static irqreturn_t flexcan_err_irq(int irq, void *dev_id) {
>>> + struct net_device *dev = dev_id;
>>> + struct flexcan_priv *priv = netdev_priv(dev);
>>> + struct flexcan_regs __iomem *regs = priv->base;
>>> + u32 reg_ctrl, reg_esr;
>>> +
>>> + reg_esr = flexcan_read(®s->esr);
>>> + reg_ctrl = flexcan_read(®s->ctrl);
>>> +
>>> + if (reg_esr & FLEXCAN_ESR_ALL_INT) {
>>> + if (reg_esr & FLEXCAN_ESR_ERR_INT)
>>> + flexcan_write(reg_ctrl & ~FLEXCAN_CTRL_ERR_MSK,
>>> + ®s->ctrl);
>>> + flexcan_irq(irq, dev);
>>
>> I still don't understand why you need a special flexcan_err_irq()
>> function. Why don't you just call:
>>
>> request_irq(priv->err_irq, flexcan_irq, IRQF_SHARED, dev->name, dev);
>>
>> instead?
>
> Flexcan_irq is for flexcan normal interrupt(such as Message Buffer, Wake up and so on).
> And it will return IRQ_HANDLED if flexcan_irq is triggered.
> But err_irq is shared with other devices, it should return IRQ_HANDLED when the interrupt
> is triggered by flexcan device, if not return IRQ_NONE.
What about fixing flexcan_irq() first and the make use of it?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]
^ permalink raw reply
* Re: Re: Re: Re: [PATCH v4] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Masami Hiramatsu @ 2014-07-02 7:16 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jeremy Fitzhardinge, linux-ia64, sparse,
Linux Kernel Mailing List, Paul Mackerras, H. Peter Anvin,
akataria, linux-tip-commits, anil.s.keshavamurthy, Ingo Molnar,
Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann, Rusty Russell,
Chris Wright, yrl.pp-manager.tt, Thomas Gleixner, Tony Luck,
Kevin Hao, Linus Torvalds, rdunlap, Tony Luck, dl9pf,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1404284165.7254.2.camel@concordia>
(2014/07/02 15:56), Michael Ellerman wrote:
> On Wed, 2014-07-02 at 15:39 +0900, Masami Hiramatsu wrote:
>> (2014/07/02 13:41), Michael Ellerman wrote:
>>> On Tue, 2014-07-01 at 11:21 +0900, Masami Hiramatsu wrote:
>>>> (2014/06/30 20:36), Michael Ellerman wrote:
>>>>> On Mon, 2014-06-30 at 12:14 +0900, Masami Hiramatsu wrote:
>>>>>> Ping? :)
>>>>>
>>>>> Yeah sorry. I started looking at this and got dragged into another mess.
>>>>>
>>>>> You seem to have duplicated the functionality of arch_deref_entry_point(),
>>>>> which was also added for kprobes, and for the same reason - ie. because some
>>>>> arches have strange function pointers. Is there some reason you can't use it?
>>>>
>>>> Ah, right! Hmm, it seems some more work to update it. but basically, we can do.
>>>> BTW, is there any other users who need to access the actual function entry (for
>>>> kallsyms case)?
>>>
>>> Not that I'm aware of. We have had function descriptors on 64-bit powerpc for
>>> ever, so in theory by now we should have already found any cases where we need
>>> that sort of wrapper.
>>
>> OK, then I'll update this patch to use arch_deref_entry_point(), and add additional
>> patch which update to support PPC64 ABIv2.
>
> I've already done the latter:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2f0143c91d30823f6f6e7d94d7fa818f7ab18a18
Oh, thanks!
In that case, my 1/2 patch should be dropped.
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply
* Re: [PATCH v5 1/2] kprobes/powerpc: Fix arch_deref_entry_point to support ABIv2
From: Masami Hiramatsu @ 2014-07-02 7:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Tony Luck
Cc: Jeremy Fitzhardinge, Rusty Russell, Anoop Thomas Mathew,
Andrew Morton, Arnd Bergmann, linux-tip-commits, Jiri Kosina,
sparse, rdunlap, H. Peter Anvin, Linux Kernel Mailing List,
anil.s.keshavamurthy, Ingo Molnar, Chris Wright, linuxppc-dev,
Thomas Gleixner, dl9pf, yrl.pp-manager.tt, akataria,
Linus Torvalds, David S. Miller
In-Reply-To: <20140702070022.14689.7254.stgit@kbuild-fedora.novalocal>
(2014/07/02 16:00), Masami Hiramatsu wrote:
> Since PowerPC64 ABIv2 doesn't have function descriptor
> any more, arch_deref_entry_point(), which returns function
> entry point from function descriptor, should be updated.
Please ignore this patch, since it is already fixed by Michael
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2f0143c91d30823f6f6e7d94d7fa818f7ab18a18
We only need 2/2.
Thank you,
>
> Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Anoop Thomas Mathew <atm@profoundis.com>
> Cc: Jiri Kosina <jkosina@suse.cz>
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/powerpc/kernel/kprobes.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 90fab64..72a1034 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -491,7 +491,12 @@ int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
> return ret;
> }
>
> -#ifdef CONFIG_PPC64
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> +/*
> + * On PPC64 ABIv1 the function pointer actually points to the
> + * function's descriptor. The first entry in the descriptor is the
> + * address of the function text.
> + */
> unsigned long arch_deref_entry_point(void *entry)
> {
> return ((func_descr_t *)entry)->entry;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply
* Re: [PATCH 1/3] iommu/fsl: Fix PAMU window size check.
From: Emil Medve @ 2014-07-02 7:46 UTC (permalink / raw)
To: Varun Sethi, iommu, joro, linux-kernel, linuxppc-dev,
alex.williamson
In-Reply-To: <1403618237-26248-2-git-send-email-Varun.Sethi__13822.953499812$1403630309$gmane$org@freescale.com>
On 06/24/2014 08:57 AM, Varun Sethi wrote:
> is_power_of_2 requires an unsigned long parameter which would
> lead to truncation of 64 bit values on 32 bit architectures.
>
> __ffs also expects an unsigned long parameter thus won't work
> for 64 bit values on 32 bit architectures.
>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> ---
> drivers/iommu/fsl_pamu.c | 8 ++++----
> drivers/iommu/fsl_pamu_domain.c | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
Tested-by: Emil Medve <Emilian.Medve@Freescale.com>
On a P4080 DS (i.e. 32-bit SoC)
Cheers,
^ permalink raw reply
* RE: [PATCH v4] flexcan: add err_irq handler for flexcan
From: qiang.zhao @ 2014-07-02 8:32 UTC (permalink / raw)
To: Marc Kleine-Budde, linuxppc-dev@lists.ozlabs.org,
wg@grandegger.com, linux-can@vger.kernel.org, Scott Wood
In-Reply-To: <53B3AEEC.4060507@pengutronix.de>
T24gMDcvMDIvMjAxNCAwMzowNCBQTSwgTWFyYyBLbGVpbmUtQnVkZGUgd3JvdGU6DQo+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcmMgS2xlaW5lLUJ1ZGRlIFttYWlsdG86
bWtsQHBlbmd1dHJvbml4LmRlXQ0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMDIsIDIwMTQgMzow
NCBQTQ0KPiBUbzogWmhhbyBRaWFuZy1CNDU0NzU7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMu
b3JnOyB3Z0BncmFuZGVnZ2VyLmNvbTsNCj4gbGludXgtY2FuQHZnZXIua2VybmVsLm9yZzsgV29v
ZCBTY290dC1CMDc0MjENCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NF0gZmxleGNhbjogYWRkIGVy
cl9pcnEgaGFuZGxlciBmb3IgZmxleGNhbg0KPiANCj4gT24gMDcvMDIvMjAxNCAwNDowMCBBTSwg
cWlhbmcuemhhb0BmcmVlc2NhbGUuY29tIHdyb3RlOg0KPiA+Pj4gK3N0YXRpYyBpcnFyZXR1cm5f
dCBmbGV4Y2FuX2Vycl9pcnEoaW50IGlycSwgdm9pZCAqZGV2X2lkKSB7DQo+ID4+PiArCXN0cnVj
dCBuZXRfZGV2aWNlICpkZXYgPSBkZXZfaWQ7DQo+ID4+PiArCXN0cnVjdCBmbGV4Y2FuX3ByaXYg
KnByaXYgPSBuZXRkZXZfcHJpdihkZXYpOw0KPiA+Pj4gKwlzdHJ1Y3QgZmxleGNhbl9yZWdzIF9f
aW9tZW0gKnJlZ3MgPSBwcml2LT5iYXNlOw0KPiA+Pj4gKwl1MzIgcmVnX2N0cmwsIHJlZ19lc3I7
DQo+ID4+PiArDQo+ID4+PiArCXJlZ19lc3IgPSBmbGV4Y2FuX3JlYWQoJnJlZ3MtPmVzcik7DQo+
ID4+PiArCXJlZ19jdHJsID0gZmxleGNhbl9yZWFkKCZyZWdzLT5jdHJsKTsNCj4gPj4+ICsNCj4g
Pj4+ICsJaWYgKHJlZ19lc3IgJiBGTEVYQ0FOX0VTUl9BTExfSU5UKSB7DQo+ID4+PiArCQlpZiAo
cmVnX2VzciAmIEZMRVhDQU5fRVNSX0VSUl9JTlQpDQo+ID4+PiArCQkJZmxleGNhbl93cml0ZShy
ZWdfY3RybCAmIH5GTEVYQ0FOX0NUUkxfRVJSX01TSywNCj4gPj4+ICsJCQkJICAgICAgJnJlZ3Mt
PmN0cmwpOw0KPiA+Pj4gKwkJZmxleGNhbl9pcnEoaXJxLCBkZXYpOw0KPiA+Pg0KPiA+PiBJIHN0
aWxsIGRvbid0IHVuZGVyc3RhbmQgd2h5IHlvdSBuZWVkIGEgc3BlY2lhbCBmbGV4Y2FuX2Vycl9p
cnEoKQ0KPiA+PiBmdW5jdGlvbi4gV2h5IGRvbid0IHlvdSBqdXN0IGNhbGw6DQo+ID4+DQo+ID4+
IHJlcXVlc3RfaXJxKHByaXYtPmVycl9pcnEsIGZsZXhjYW5faXJxLCBJUlFGX1NIQVJFRCwgZGV2
LT5uYW1lLCBkZXYpOw0KPiA+Pg0KPiA+PiBpbnN0ZWFkPw0KPiA+DQo+ID4gRmxleGNhbl9pcnEg
aXMgZm9yIGZsZXhjYW4gbm9ybWFsIGludGVycnVwdChzdWNoIGFzIE1lc3NhZ2UgQnVmZmVyLA0K
PiBXYWtlIHVwIGFuZCBzbyBvbikuDQo+ID4gQW5kIGl0IHdpbGwgcmV0dXJuIElSUV9IQU5ETEVE
IGlmIGZsZXhjYW5faXJxIGlzIHRyaWdnZXJlZC4NCj4gPiBCdXQgZXJyX2lycSBpcyBzaGFyZWQg
d2l0aCBvdGhlciBkZXZpY2VzLCBpdCBzaG91bGQgcmV0dXJuIElSUV9IQU5ETEVEDQo+ID4gd2hl
biB0aGUgaW50ZXJydXB0IGlzIHRyaWdnZXJlZCBieSBmbGV4Y2FuIGRldmljZSwgaWYgbm90IHJl
dHVybg0KPiBJUlFfTk9ORS4NCj4gDQo+IFdoYXQgYWJvdXQgZml4aW5nIGZsZXhjYW5faXJxKCkg
Zmlyc3QgYW5kIHRoZSBtYWtlIHVzZSBvZiBpdD8NCg0KRXJyX2lycSBpcyBhIHNoYXJlZCBpbnRl
cnJ1cHQgd2l0aCBvdGhlciBkZXZpY2UsIA0KSSBob3BlIHRoYXQgaXRzIGhhbmRsZXIgaXMgaW5k
ZXBlbmRlbnQuDQpIb3dldmVyLCBpZiB5b3UgcGVyc2lzdCBpbiB5b3VyIG9waW5pb24sIEkgd2ls
bCBkbyBpdCBhcyB5b3Ugc2FpZC4NCg0KPiANCj4gTWFyYw0KPiANCj4gLS0NCj4gUGVuZ3V0cm9u
aXggZS5LLiAgICAgICAgICAgICAgICAgIHwgTWFyYyBLbGVpbmUtQnVkZGUgICAgICAgICAgIHwN
Cj4gSW5kdXN0cmlhbCBMaW51eCBTb2x1dGlvbnMgICAgICAgIHwgUGhvbmU6ICs0OS0yMzEtMjgy
Ni05MjQgICAgIHwNCj4gVmVydHJldHVuZyBXZXN0L0RvcnRtdW5kICAgICAgICAgIHwgRmF4OiAg
ICs0OS01MTIxLTIwNjkxNy01NTU1IHwNCj4gQW10c2dlcmljaHQgSGlsZGVzaGVpbSwgSFJBIDI2
ODYgIHwgaHR0cDovL3d3dy5wZW5ndXRyb25peC5kZSAgIHwNCg0K
^ permalink raw reply
* RE: [PATCH 1/3] iommu/fsl: Fix PAMU window size check.
From: Varun Sethi @ 2014-07-02 8:58 UTC (permalink / raw)
To: Emilian Medve, iommu@lists.linux-foundation.org, joro@8bytes.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
alex.williamson@redhat.com
In-Reply-To: <53B3B8B9.30400@Freescale.com>
VGhhbmtzIEVtaWwuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRW1p
bCBNZWR2ZSBbbWFpbHRvOkVtaWxpYW4uTWVkdmVARnJlZXNjYWxlLmNvbV0NCj4gU2VudDogV2Vk
bmVzZGF5LCBKdWx5IDAyLCAyMDE0IDE6MTYgUE0NCj4gVG86IFNldGhpIFZhcnVuLUIxNjM5NTsg
aW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmc7DQo+IGpvcm9AOGJ5dGVzLm9yZzsgbGlu
dXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtDQo+IGRldkBsaXN0cy5vemxhYnMu
b3JnOyBhbGV4LndpbGxpYW1zb25AcmVkaGF0LmNvbQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDEv
M10gaW9tbXUvZnNsOiBGaXggUEFNVSB3aW5kb3cgc2l6ZSBjaGVjay4NCj4gDQo+IE9uIDA2LzI0
LzIwMTQgMDg6NTcgQU0sIFZhcnVuIFNldGhpIHdyb3RlOg0KPiA+IGlzX3Bvd2VyX29mXzIgcmVx
dWlyZXMgYW4gdW5zaWduZWQgbG9uZyBwYXJhbWV0ZXIgd2hpY2ggd291bGQgbGVhZCB0bw0KPiA+
IHRydW5jYXRpb24gb2YgNjQgYml0IHZhbHVlcyBvbiAzMiBiaXQgYXJjaGl0ZWN0dXJlcy4NCj4g
Pg0KPiA+IF9fZmZzIGFsc28gZXhwZWN0cyBhbiB1bnNpZ25lZCBsb25nIHBhcmFtZXRlciB0aHVz
IHdvbid0IHdvcmsgZm9yIDY0DQo+ID4gYml0IHZhbHVlcyBvbiAzMiBiaXQgYXJjaGl0ZWN0dXJl
cy4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFZhcnVuIFNldGhpIDxWYXJ1bi5TZXRoaUBmcmVl
c2NhbGUuY29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL2lvbW11L2ZzbF9wYW11LmMgICAgICAg
IHwgICAgOCArKysrLS0tLQ0KPiA+ICBkcml2ZXJzL2lvbW11L2ZzbF9wYW11X2RvbWFpbi5jIHwg
ICAgMiArLQ0KPiA+ICAyIGZpbGVzIGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlv
bnMoLSkNCj4gDQo+IFRlc3RlZC1ieTogRW1pbCBNZWR2ZSA8RW1pbGlhbi5NZWR2ZUBGcmVlc2Nh
bGUuY29tPg0KPiANCj4gT24gYSBQNDA4MCBEUyAoaS5lLiAzMi1iaXQgU29DKQ0KPiANCj4gDQo+
IENoZWVycywNCg==
^ permalink raw reply
* Re: [PATCH v4] flexcan: add err_irq handler for flexcan
From: Marc Kleine-Budde @ 2014-07-02 9:02 UTC (permalink / raw)
To: qiang.zhao@freescale.com, linuxppc-dev@lists.ozlabs.org,
wg@grandegger.com, linux-can@vger.kernel.org, Scott Wood
In-Reply-To: <175067a435ce4d5c9a194a459e950544@BLUPR03MB341.namprd03.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]
On 07/02/2014 10:32 AM, qiang.zhao@freescale.com wrote:
> On 07/02/2014 03:04 PM, Marc Kleine-Budde wrote:
>> -----Original Message-----
>> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
>> Sent: Wednesday, July 02, 2014 3:04 PM
>> To: Zhao Qiang-B45475; linuxppc-dev@lists.ozlabs.org; wg@grandegger.com;
>> linux-can@vger.kernel.org; Wood Scott-B07421
>> Subject: Re: [PATCH v4] flexcan: add err_irq handler for flexcan
>>
>> On 07/02/2014 04:00 AM, qiang.zhao@freescale.com wrote:
>>>>> +static irqreturn_t flexcan_err_irq(int irq, void *dev_id) {
>>>>> + struct net_device *dev = dev_id;
>>>>> + struct flexcan_priv *priv = netdev_priv(dev);
>>>>> + struct flexcan_regs __iomem *regs = priv->base;
>>>>> + u32 reg_ctrl, reg_esr;
>>>>> +
>>>>> + reg_esr = flexcan_read(®s->esr);
>>>>> + reg_ctrl = flexcan_read(®s->ctrl);
>>>>> +
>>>>> + if (reg_esr & FLEXCAN_ESR_ALL_INT) {
>>>>> + if (reg_esr & FLEXCAN_ESR_ERR_INT)
>>>>> + flexcan_write(reg_ctrl & ~FLEXCAN_CTRL_ERR_MSK,
>>>>> + ®s->ctrl);
>>>>> + flexcan_irq(irq, dev);
>>>>
>>>> I still don't understand why you need a special flexcan_err_irq()
>>>> function. Why don't you just call:
>>>>
>>>> request_irq(priv->err_irq, flexcan_irq, IRQF_SHARED, dev->name, dev);
>>>>
>>>> instead?
>>>
>>> Flexcan_irq is for flexcan normal interrupt(such as Message Buffer,
>> Wake up and so on).
>>> And it will return IRQ_HANDLED if flexcan_irq is triggered.
>>> But err_irq is shared with other devices, it should return IRQ_HANDLED
>>> when the interrupt is triggered by flexcan device, if not return
>> IRQ_NONE.
>>
>> What about fixing flexcan_irq() first and the make use of it?
>
> Err_irq is a shared interrupt with other device,
> I hope that its handler is independent.
> However, if you persist in your opinion, I will do it as you said.
There is another option, you can move all of the error interrupt
handling code from flexcan_irq() to flexcan_irq_err(). To keep the ARM
SoCs supported, you need to call flexcan_irq_err() form the
flexcan_irq() handler.
What I don't want is a) code duplication and b) no fishy wrapper
functions around flexcan_irq() that work around flexcan_irq() returning
IRQ_HANDLED unconditionally.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] KVM: PPC: BOOK3S: HV: Use new functions for mapping/unmapping hpte in host
From: Aneesh Kumar K.V @ 2014-07-02 11:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <20140702042831.GB16865@drongo>
Paul Mackerras <paulus@samba.org> writes:
> On Sun, Jun 29, 2014 at 04:47:33PM +0530, Aneesh Kumar K.V wrote:
>> We want to use virtual page class key protection mechanism for
>> indicating a MMIO mapped hpte entry or a guest hpte entry that is swapped out
>> in the host. Those hptes will be marked valid, but have virtual page
>> class key set to 30 or 31. These virtual page class numbers are
>> configured in AMR to deny read/write. To accomodate such a change, add
>> new functions that map, unmap and check whether a hpte is mapped in the
>> host. This patch still use HPTE_V_VALID and HPTE_V_ABSENT and don't use
>> virtual page class keys. But we want to differentiate in the code
>> where we explicitly check for HPTE_V_VALID with places where we want to
>> check whether the hpte is host mapped. This patch enables a closer
>> review for such a change.
>
> [...]
>
>> /* Check for pending invalidations under the rmap chain lock */
>> if (kvm->arch.using_mmu_notifiers &&
>> mmu_notifier_retry(kvm, mmu_seq)) {
>> - /* inval in progress, write a non-present HPTE */
>> - pteh |= HPTE_V_ABSENT;
>> - pteh &= ~HPTE_V_VALID;
>> + /*
>> + * inval in progress in host, write host unmapped pte.
>> + */
>> + host_unmapped_hpte = 1;
>
> This isn't right. We already have HPTE_V_VALID set here, and you now
> don't clear it here, and it doesn't get cleared by the
> __kvmppc_unmap_host_hpte() call below either.
Ok missed that. Will fix that in the next update. In the earlier version
I had kvmppc_unmap_host_hpte always clearing V_VALID.
-aneesh
^ permalink raw reply
* Re: [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte update
From: Aneesh Kumar K.V @ 2014-07-02 11:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <20140702054156.GD16865@drongo>
Paul Mackerras <paulus@samba.org> writes:
> On Sun, Jun 29, 2014 at 04:47:34PM +0530, Aneesh Kumar K.V wrote:
>> As per ISA, we first need to mark hpte invalid (V=0) before we update
>> the hpte lower half bits. With virtual page class key protection mechanism we want
>> to send any fault other than key fault to guest directly without
>> searching the hash page table. But then we can get NO_HPTE fault while
>> we are updating the hpte. To track that add a vm specific atomic
>> variable that we check in the fault path to always send the fault
>> to host.
>
> [...]
>
>> @@ -750,13 +751,15 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct kvm_vcpu *vcpu,
>> r &= rcbits | ~(HPTE_R_R | HPTE_R_C);
>>
>> if (be64_to_cpu(hptep[0]) & HPTE_V_VALID) {
>> - /* HPTE was previously valid, so we need to invalidate it */
>> + /*
>> + * If we had mapped this hpte before, we now need to
>> + * invalidate that.
>> + */
>> unlock_rmap(rmap);
>> - /* Always mark HPTE_V_ABSENT before invalidating */
>> - kvmppc_unmap_host_hpte(kvm, hptep);
>> kvmppc_invalidate_hpte(kvm, hptep, index);
>> /* don't lose previous R and C bits */
>> r |= be64_to_cpu(hptep[1]) & (HPTE_R_R | HPTE_R_C);
>> + hpte_invalidated = true;
>
> So now we're not setting the ABSENT bit before invalidating the HPTE.
> That means that another guest vcpu could do an H_ENTER which could
> think that this HPTE is free and use it for another unrelated guest
> HPTE, which would be bad...
But henter looks at HPTE_V_HVLOCK, and we keep that set through out. But
I will double the code again to make sure it is safe in the above
scenario.
>
>> @@ -1144,8 +1149,8 @@ static int kvm_test_clear_dirty_npages(struct kvm *kvm, unsigned long *rmapp)
>> npages_dirty = n;
>> eieio();
>> }
>> - kvmppc_map_host_hpte(kvm, &v, &r);
>> - hptep[0] = cpu_to_be64(v & ~HPTE_V_HVLOCK);
>> + hptep[0] = cpu_to_be64(v & ~HPTE_V_LOCK);
>> + atomic_dec(&kvm->arch.hpte_update_in_progress);
>
> Why are we using LOCK rather than HVLOCK now? (And why didn't you
> mention this change and its rationale in the patch description?)
Sorry, that is a typo. I intend to use HPTE_V_HVLOCK.
-aneesh
^ permalink raw reply
* Re: [PATCH 2/6] KVM: PPC: BOOK3S: HV: Deny virtual page class key update via h_protect
From: Aneesh Kumar K.V @ 2014-07-02 12:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, agraf, kvm-ppc, kvm
In-Reply-To: <20140702045002.GC16865@drongo>
Paul Mackerras <paulus@samba.org> writes:
> On Sun, Jun 29, 2014 at 04:47:31PM +0530, Aneesh Kumar K.V wrote:
>> This makes it consistent with h_enter where we clear the key
>> bits. We also want to use virtual page class key protection mechanism
>> for indicating host page fault. For that we will be using key class
>> index 30 and 31. So prevent the guest from updating key bits until
>> we add proper support for virtual page class protection mechanism for
>> the guest. This will not have any impact for PAPR linux guest because
>> Linux guest currently don't use virtual page class key protection model
>
> As things stand, without this patch series, we do actually have
> everything we need in the kernel for guests to use virtual page class
> keys. Arguably we should have a capability to tell userspace how many
> storage keys the guest can use, but that's the only missing piece as
> far as I can see.
yes.
>
> If we add such a capability, I can't see any reason why we should need
> to disable guest use of storage keys in this patchset.
With this patchset, we would need additonal changes to find out whether the key
fault happened because of the guest's usage of the key. I was planning to do
that as an add-on series to keep the changes in this minimal. Also since
linux didn't use keys i was not sure whether guest support of keys is an
important item.
-aneesh
^ permalink raw reply
* Re: Regression in 3.15 on POWER8 with multipath SCSI
From: Bart Van Assche @ 2014-07-02 15:30 UTC (permalink / raw)
To: Mike Snitzer, Paul Mackerras
Cc: Vladimir Davydov, linux-kernel, linuxppc-dev, dm-devel,
Andrew Morton, Linus Torvalds
In-Reply-To: <20140701193907.GA15306@redhat.com>
On 07/01/14 21:39, Mike Snitzer wrote:
> (btw, Bart Van Assche also has issues with commit e8099177 due to hangs
> during cable pull testing of mpath devices -- Bart: curious to know if
> your cable pull tests pass if you just revert bcccff93).
Sorry but even with bcccff93 reverted after a few iterations my cable
pull simulation test still causes several tasks to hang in sleep_on_page().
Bart.
^ permalink raw reply
* Re: [PATCH v2] spi: deal with a compile warning
From: Mark Brown @ 2014-07-02 19:50 UTC (permalink / raw)
To: Zhao Qiang; +Cc: B07421, linuxppc-dev, linux-spi
In-Reply-To: <1403753203-13473-1-git-send-email-B45475@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
On Thu, Jun 26, 2014 at 11:26:43AM +0800, Zhao Qiang wrote:
> ret is unused when CONFIG_FSL_SOC defined,
> so return ret instead of -ENOMEM when the
> kzalloc fails to avoid it.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()
From: Bjorn Helgaas @ 2014-07-02 20:22 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-mips, linux-s390, linux-pci, x86, linux-doc, linux-kernel,
linux-ide, iommu, xen-devel, linuxppc-dev
In-Reply-To: <4fef62a2e647a7c38e9f2a1ea4244b3506a85e2b.1402405331.git.agordeev@redhat.com>
On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
> There are PCI devices that require a particular value written
> to the Multiple Message Enable (MME) register while aligned on
> power of 2 boundary value of actually used MSI vectors 'nvec'
> is a lesser of that MME value:
>
> roundup_pow_of_two(nvec) < 'Multiple Message Enable'
>
> However the existing pci_enable_msi_block() interface is not
> able to configure such devices, since the value written to the
> MME register is calculated from the number of requested MSIs
> 'nvec':
>
> 'Multiple Message Enable' = roundup_pow_of_two(nvec)
For MSI, software learns how many vectors a device requests by reading
the Multiple Message Capable (MMC) field. This field is encoded, so a
device can only request 1, 2, 4, 8, etc., vectors. It's impossible
for a device to request 3 vectors; it would have to round up that up
to a power of two and request 4 vectors.
Software writes similarly encoded values to MME to tell the device how
many vectors have been allocated for its use. For example, it's
impossible to tell the device that it can use 3 vectors; the OS has to
round that up and tell the device it can use 4 vectors.
So if I understand correctly, the point of this series is to take
advantage of device-specific knowledge, e.g., the device requests 4
vectors via MMC, but we "know" the device is only capable of using 3.
Moreover, we tell the device via MME that 4 vectors are available, but
we've only actually set up 3 of them.
This makes me uneasy because we're lying to the device, and the device
is perfectly within spec to use all 4 of those vectors. If anything
changes the number of vectors the device uses (new device revision,
firmware upgrade, etc.), this is liable to break.
Can you quantify the benefit of this? Can't a device already use
MSI-X to request exactly the number of vectors it can use? (I know
not all devices support MSI-X, but maybe we should just accept MSI for
what it is and encourage the HW guys to use MSI-X if MSI isn't good
enough.)
> In this case the result written to the MME register may not
> satisfy the aforementioned PCI devices requirement and therefore
> the PCI functions will not operate in a desired mode.
I'm not sure what you mean by "will not operate in a desired mode."
I thought this was an optimization to save vectors and that these
changes would be completely invisible to the hardware.
Bjorn
> This update introduces pci_enable_msi_partial() extension to
> pci_enable_msi_block() interface that accepts extra 'nvec_mme'
> argument which is then written to MME register while the value
> of 'nvec' is still used to setup as many interrupts as requested.
>
> As result of this change, architecture-specific callbacks
> arch_msi_check_device() and arch_setup_msi_irqs() get an extra
> 'nvec_mme' parameter as well, but it is ignored for now.
> Therefore, this update is a placeholder for architectures that
> wish to support pci_enable_msi_partial() function in the future.
>
> Cc: linux-doc@vger.kernel.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-s390@vger.kernel.org
> Cc: x86@kernel.org
> Cc: xen-devel@lists.xenproject.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-ide@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
> ---
> Documentation/PCI/MSI-HOWTO.txt | 36 ++++++++++++++--
> arch/mips/pci/msi-octeon.c | 2 +-
> arch/powerpc/kernel/msi.c | 4 +-
> arch/s390/pci/pci.c | 2 +-
> arch/x86/kernel/x86_init.c | 2 +-
> drivers/pci/msi.c | 83 ++++++++++++++++++++++++++++++++++-----
> include/linux/msi.h | 5 +-
> include/linux/pci.h | 3 +
> 8 files changed, 115 insertions(+), 22 deletions(-)
>
> diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
> index 10a9369..c8a8503 100644
> --- a/Documentation/PCI/MSI-HOWTO.txt
> +++ b/Documentation/PCI/MSI-HOWTO.txt
> @@ -195,14 +195,40 @@ By contrast with pci_enable_msi_range() function, pci_enable_msi_exact()
> returns zero in case of success, which indicates MSI interrupts have been
> successfully allocated.
>
> -4.2.4 pci_disable_msi
> +4.2.4 pci_enable_msi_partial
> +
> +int pci_enable_msi_partial(struct pci_dev *dev, int nvec, int nvec_mme)
> +
> +This variation on pci_enable_msi_exact() call allows a device driver to
> +setup 'nvec_mme' number of multiple MSIs with the PCI function, while
> +setup only 'nvec' (which could be a lesser of 'nvec_mme') number of MSIs
> +in operating system. The MSI specification only allows 'nvec_mme' to be
> +allocated in powers of two, up to a maximum of 2^5 (32).
> +
> +This function could be used when a PCI function is known to send 'nvec'
> +MSIs, but still requires a particular number of MSIs 'nvec_mme' to be
> +initialized with. As result, 'nvec_mme' - 'nvec' number of unused MSIs
> +do not waste system resources.
> +
> +If this function returns 0, it has succeeded in allocating 'nvec_mme'
> +interrupts and setting up 'nvec' interrupts. In this case, the function
> +enables MSI on this device and updates dev->irq to be the lowest of the
> +new interrupts assigned to it. The other interrupts assigned to the
> +device are in the range dev->irq to dev->irq + nvec - 1.
> +
> +If this function returns a negative number, it indicates an error and
> +the driver should not attempt to request any more MSI interrupts for
> +this device.
> +
> +4.2.5 pci_disable_msi
>
> void pci_disable_msi(struct pci_dev *dev)
>
> -This function should be used to undo the effect of pci_enable_msi_range().
> -Calling it restores dev->irq to the pin-based interrupt number and frees
> -the previously allocated MSIs. The interrupts may subsequently be assigned
> -to another device, so drivers should not cache the value of dev->irq.
> +This function should be used to undo the effect of pci_enable_msi_range()
> +or pci_enable_msi_partial(). Calling it restores dev->irq to the pin-based
> +interrupt number and frees the previously allocated MSIs. The interrupts
> +may subsequently be assigned to another device, so drivers should not cache
> +the value of dev->irq.
>
> Before calling this function, a device driver must always call free_irq()
> on any interrupt for which it previously called request_irq().
> diff --git a/arch/mips/pci/msi-octeon.c b/arch/mips/pci/msi-octeon.c
> index 2b91b0e..2be7979 100644
> --- a/arch/mips/pci/msi-octeon.c
> +++ b/arch/mips/pci/msi-octeon.c
> @@ -178,7 +178,7 @@ msi_irq_allocated:
> return 0;
> }
>
> -int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int nvec_mme, int type)
> {
> struct msi_desc *entry;
> int ret;
> diff --git a/arch/powerpc/kernel/msi.c b/arch/powerpc/kernel/msi.c
> index 8bbc12d..c60aee3 100644
> --- a/arch/powerpc/kernel/msi.c
> +++ b/arch/powerpc/kernel/msi.c
> @@ -13,7 +13,7 @@
>
> #include <asm/machdep.h>
>
> -int arch_msi_check_device(struct pci_dev* dev, int nvec, int type)
> +int arch_msi_check_device(struct pci_dev *dev, int nvec, int nvec_mme, int type)
> {
> if (!ppc_md.setup_msi_irqs || !ppc_md.teardown_msi_irqs) {
> pr_debug("msi: Platform doesn't provide MSI callbacks.\n");
> @@ -32,7 +32,7 @@ int arch_msi_check_device(struct pci_dev* dev, int nvec, int type)
> return 0;
> }
>
> -int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int nvec_mme, int type)
> {
> return ppc_md.setup_msi_irqs(dev, nvec, type);
> }
> diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
> index 9ddc51e..3cf38a8 100644
> --- a/arch/s390/pci/pci.c
> +++ b/arch/s390/pci/pci.c
> @@ -398,7 +398,7 @@ static void zpci_irq_handler(struct airq_struct *airq)
> }
> }
>
> -int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
> +int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int nvec_mme, int type)
> {
> struct zpci_dev *zdev = get_zdev(pdev);
> unsigned int hwirq, msi_vecs;
> diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
> index e48b674..b65bf95 100644
> --- a/arch/x86/kernel/x86_init.c
> +++ b/arch/x86/kernel/x86_init.c
> @@ -121,7 +121,7 @@ struct x86_msi_ops x86_msi = {
> };
>
> /* MSI arch specific hooks */
> -int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int nvec_mme, int type)
> {
> return x86_msi.setup_msi_irqs(dev, nvec, type);
> }
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 27a7e67..0410d9b 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -56,7 +56,8 @@ void __weak arch_teardown_msi_irq(unsigned int irq)
> chip->teardown_irq(chip, irq);
> }
>
> -int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_msi_check_device(struct pci_dev *dev,
> + int nvec, int nvec_mme, int type)
> {
> struct msi_chip *chip = dev->bus->msi;
>
> @@ -66,7 +67,8 @@ int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
> return chip->check_device(chip, dev, nvec, type);
> }
>
> -int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> +int __weak arch_setup_msi_irqs(struct pci_dev *dev,
> + int nvec, int nvec_mme, int type)
> {
> struct msi_desc *entry;
> int ret;
> @@ -598,6 +600,7 @@ error_attrs:
> * msi_capability_init - configure device's MSI capability structure
> * @dev: pointer to the pci_dev data structure of MSI device function
> * @nvec: number of interrupts to allocate
> + * @nvec_mme: number of interrupts to write to Multiple Message Enable register
> *
> * Setup the MSI capability structure of the device with the requested
> * number of interrupts. A return value of zero indicates the successful
> @@ -605,7 +608,7 @@ error_attrs:
> * an error, and a positive return value indicates the number of interrupts
> * which could have been allocated.
> */
> -static int msi_capability_init(struct pci_dev *dev, int nvec)
> +static int msi_capability_init(struct pci_dev *dev, int nvec, int nvec_mme)
> {
> struct msi_desc *entry;
> int ret;
> @@ -640,7 +643,7 @@ static int msi_capability_init(struct pci_dev *dev, int nvec)
> list_add_tail(&entry->list, &dev->msi_list);
>
> /* Configure MSI capability structure */
> - ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSI);
> + ret = arch_setup_msi_irqs(dev, nvec, nvec_mme, PCI_CAP_ID_MSI);
> if (ret) {
> msi_mask_irq(entry, mask, ~mask);
> free_msi_irqs(dev);
> @@ -758,7 +761,8 @@ static int msix_capability_init(struct pci_dev *dev,
> if (ret)
> return ret;
>
> - ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
> + /* Parameter 'nvec_mme' does not make sense in case of MSI-X */
> + ret = arch_setup_msi_irqs(dev, nvec, 0, PCI_CAP_ID_MSIX);
> if (ret)
> goto out_avail;
>
> @@ -812,13 +816,15 @@ out_free:
> * pci_msi_check_device - check whether MSI may be enabled on a device
> * @dev: pointer to the pci_dev data structure of MSI device function
> * @nvec: how many MSIs have been requested ?
> + * @nvec_mme: how many MSIs write to Multiple Message Enable register ?
> * @type: are we checking for MSI or MSI-X ?
> *
> * Look at global flags, the device itself, and its parent buses
> * to determine if MSI/-X are supported for the device. If MSI/-X is
> * supported return 0, else return an error code.
> **/
> -static int pci_msi_check_device(struct pci_dev *dev, int nvec, int type)
> +static int pci_msi_check_device(struct pci_dev *dev,
> + int nvec, int nvec_mme, int type)
> {
> struct pci_bus *bus;
> int ret;
> @@ -846,7 +852,7 @@ static int pci_msi_check_device(struct pci_dev *dev, int nvec, int type)
> if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
> return -EINVAL;
>
> - ret = arch_msi_check_device(dev, nvec, type);
> + ret = arch_msi_check_device(dev, nvec, nvec_mme, type);
> if (ret)
> return ret;
>
> @@ -878,6 +884,62 @@ int pci_msi_vec_count(struct pci_dev *dev)
> }
> EXPORT_SYMBOL(pci_msi_vec_count);
>
> +/**
> + * pci_enable_msi_partial - configure device's MSI capability structure
> + * @dev: device to configure
> + * @nvec: number of interrupts to configure
> + * @nvec_mme: number of interrupts to write to Multiple Message Enable register
> + *
> + * This function tries to allocate @nvec number of interrupts while setup
> + * device's Multiple Message Enable register with @nvec_mme interrupts.
> + * It returns a negative errno if an error occurs. If it succeeds, it returns
> + * zero and updates the @dev's irq member to the lowest new interrupt number;
> + * the other interrupt numbers allocated to this device are consecutive.
> + */
> +int pci_enable_msi_partial(struct pci_dev *dev, int nvec, int nvec_mme)
> +{
> + int maxvec;
> + int rc;
> +
> + if (dev->current_state != PCI_D0)
> + return -EINVAL;
> +
> + WARN_ON(!!dev->msi_enabled);
> +
> + /* Check whether driver already requested MSI-X irqs */
> + if (dev->msix_enabled) {
> + dev_info(&dev->dev, "can't enable MSI "
> + "(MSI-X already enabled)\n");
> + return -EINVAL;
> + }
> +
> + if (!is_power_of_2(nvec_mme))
> + return -EINVAL;
> + if (nvec > nvec_mme)
> + return -EINVAL;
> +
> + maxvec = pci_msi_vec_count(dev);
> + if (maxvec < 0)
> + return maxvec;
> + else if (nvec_mme > maxvec)
> + return -EINVAL;
> +
> + rc = pci_msi_check_device(dev, nvec, nvec_mme, PCI_CAP_ID_MSI);
> + if (rc < 0)
> + return rc;
> + else if (rc > 0)
> + return -ENOSPC;
> +
> + rc = msi_capability_init(dev, nvec, nvec_mme);
> + if (rc < 0)
> + return rc;
> + else if (rc > 0)
> + return -ENOSPC;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(pci_enable_msi_partial);
> +
> void pci_msi_shutdown(struct pci_dev *dev)
> {
> struct msi_desc *desc;
> @@ -957,7 +1019,7 @@ int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
> if (!entries || !dev->msix_cap || dev->current_state != PCI_D0)
> return -EINVAL;
>
> - status = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSIX);
> + status = pci_msi_check_device(dev, nvec, 0, PCI_CAP_ID_MSIX);
> if (status)
> return status;
>
> @@ -1110,7 +1172,8 @@ int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
> nvec = maxvec;
>
> do {
> - rc = pci_msi_check_device(dev, nvec, PCI_CAP_ID_MSI);
> + rc = pci_msi_check_device(dev, nvec, roundup_pow_of_two(nvec),
> + PCI_CAP_ID_MSI);
> if (rc < 0) {
> return rc;
> } else if (rc > 0) {
> @@ -1121,7 +1184,7 @@ int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
> } while (rc);
>
> do {
> - rc = msi_capability_init(dev, nvec);
> + rc = msi_capability_init(dev, nvec, roundup_pow_of_two(nvec));
> if (rc < 0) {
> return rc;
> } else if (rc > 0) {
> diff --git a/include/linux/msi.h b/include/linux/msi.h
> index 92a2f99..b9f89ee 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -57,9 +57,10 @@ struct msi_desc {
> */
> int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
> void arch_teardown_msi_irq(unsigned int irq);
> -int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
> +int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int nvec_mme, int type);
> void arch_teardown_msi_irqs(struct pci_dev *dev);
> -int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
> +int arch_msi_check_device(struct pci_dev *dev,
> + int nvec, int nvec_mme, int type);
> void arch_restore_msi_irqs(struct pci_dev *dev);
>
> void default_teardown_msi_irqs(struct pci_dev *dev);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 71d9673..7360bd2 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1184,6 +1184,7 @@ void pci_disable_msix(struct pci_dev *dev);
> void msi_remove_pci_irq_vectors(struct pci_dev *dev);
> void pci_restore_msi_state(struct pci_dev *dev);
> int pci_msi_enabled(void);
> +int pci_enable_msi_partial(struct pci_dev *dev, int nvec, int nvec_mme);
> int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec);
> static inline int pci_enable_msi_exact(struct pci_dev *dev, int nvec)
> {
> @@ -1215,6 +1216,8 @@ static inline void pci_disable_msix(struct pci_dev *dev) { }
> static inline void msi_remove_pci_irq_vectors(struct pci_dev *dev) { }
> static inline void pci_restore_msi_state(struct pci_dev *dev) { }
> static inline int pci_msi_enabled(void) { return 0; }
> +static int pci_enable_msi_partial(struct pci_dev *dev, int nvec, int nvec_mme)
> +{ return -ENOSYS; }
> static inline int pci_enable_msi_range(struct pci_dev *dev, int minvec,
> int maxvec)
> { return -ENOSYS; }
> --
> 1.7.7.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [1/3,v4] powerpc/fsl-booke: Add support for T2080/T2081 SoC
From: Scott Wood @ 2014-07-02 22:39 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linuxppc-dev
In-Reply-To: <20140702014324.GA21768@home.buserror.net>
On Tue, 2014-07-01 at 20:43 -0500, Scott Wood wrote:
> On Wed, Jun 11, 2014 at 06:10:04PM +0800, Shengzhou Liu wrote:
> > +/* controller at 0x240000 */
> > +&pci0 {
> > + compatible = "fsl,t2080-pcie", "fsl,qoriq-pcie";
>
> None of your patches add "fsl,qoriq-pcie" to of_device_ids[] in
> corenet_generic.c, so PCIe will not get probed.
>
> Worse, if I add that string, the kernel hangs trying to access a PCIe
> controller that is disabled by the RCW. This is because U-Boot is
> expecting "fsl,qoriq-pcie-v3.0", and thus can't find the disabled node in
> order to delete it.
>
> Did you test PCIe at all on these boards?
>
> Did you test other peripherals?
I'll add fsl,qoriq-pcie-v3.0 when applying. Could you reply to the
question on patch 3/3?
-Scott
^ permalink raw reply
* [PATCH v2] memory: Freescale CoreNet Coherency Fabric error reporting driver
From: Scott Wood @ 2014-07-02 23:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Bharat Bhushan, linux-kernel
The CoreNet Coherency Fabric is part of the memory subsystem on
some Freescale QorIQ chips. It can report coherency violations (e.g.
due to misusing memory that is mapped noncoherent) as well as
transactions that do not hit any local access window, or which hit a
local access window with an invalid target ID.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
v2:
- s/cecadr/cecaddr/ to consistently use ccf2 names
- fix ERRDET_CTYPE_MASK value
- use the ccf2 value for CECADDRH_ADDRH (harmless on ccf1)
- add comment explaining why we disable detection on remove for
ccf1 but not ccf2
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
drivers/memory/Kconfig | 10 ++
drivers/memory/Makefile | 1 +
drivers/memory/fsl-corenet-cf.c | 251 +++++++++++++++++++++++++++
5 files changed, 264 insertions(+)
create mode 100644 drivers/memory/fsl-corenet-cf.c
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index 7d0c837..6a3c58a 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -180,3 +180,4 @@ CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_DEV_FSL_CAAM=y
+CONFIG_FSL_CORENET_CF=y
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 6ae07e1..4b07bad 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -179,3 +179,4 @@ CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_DEV_FSL_CAAM=y
+CONFIG_FSL_CORENET_CF=y
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index c59e9c9..fab81a1 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -61,6 +61,16 @@ config TEGRA30_MC
analysis, especially for IOMMU/SMMU(System Memory Management
Unit) module.
+config FSL_CORENET_CF
+ tristate "Freescale CoreNet Error Reporting"
+ depends on FSL_SOC_BOOKE
+ help
+ Say Y for reporting of errors from the Freescale CoreNet
+ Coherency Fabric. Errors reported include accesses to
+ physical addresses that mapped by no local access window
+ (LAW) or an invalid LAW, as well as bad cache state that
+ represents a coherency violation.
+
config FSL_IFC
bool
depends on FSL_SOC
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 71160a2..4055c47 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_OF) += of_memory.o
endif
obj-$(CONFIG_TI_AEMIF) += ti-aemif.o
obj-$(CONFIG_TI_EMIF) += emif.o
+obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o
obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet-cf.c
new file mode 100644
index 0000000..c9443fc
--- /dev/null
+++ b/drivers/memory/fsl-corenet-cf.c
@@ -0,0 +1,251 @@
+/*
+ * CoreNet Coherency Fabric error reporting
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+
+enum ccf_version {
+ CCF1,
+ CCF2,
+};
+
+struct ccf_info {
+ enum ccf_version version;
+ int err_reg_offs;
+};
+
+static const struct ccf_info ccf1_info = {
+ .version = CCF1,
+ .err_reg_offs = 0xa00,
+};
+
+static const struct ccf_info ccf2_info = {
+ .version = CCF2,
+ .err_reg_offs = 0xe40,
+};
+
+static const struct of_device_id ccf_matches[] = {
+ {
+ .compatible = "fsl,corenet1-cf",
+ .data = &ccf1_info,
+ },
+ {
+ .compatible = "fsl,corenet2-cf",
+ .data = &ccf2_info,
+ },
+ {}
+};
+
+struct ccf_err_regs {
+ u32 errdet; /* 0x00 Error Detect Register */
+ /* 0x04 Error Enable (ccf1)/Disable (ccf2) Register */
+ u32 errdis;
+ /* 0x08 Error Interrupt Enable Register (ccf2 only) */
+ u32 errinten;
+ u32 cecar; /* 0x0c Error Capture Attribute Register */
+ u32 cecaddrh; /* 0x10 Error Capture Address High */
+ u32 cecaddrl; /* 0x14 Error Capture Address Low */
+ u32 cecar2; /* 0x18 Error Capture Attribute Register 2 */
+};
+
+/* LAE/CV also valid for errdis and errinten */
+#define ERRDET_LAE (1 << 0) /* Local Access Error */
+#define ERRDET_CV (1 << 1) /* Coherency Violation */
+#define ERRDET_CTYPE_SHIFT 26 /* Capture Type (ccf2 only) */
+#define ERRDET_CTYPE_MASK (0x1f << ERRDET_CTYPE_SHIFT)
+#define ERRDET_CAP (1 << 31) /* Capture Valid (ccf2 only) */
+
+#define CECAR_VAL (1 << 0) /* Valid (ccf1 only) */
+#define CECAR_UVT (1 << 15) /* Unavailable target ID (ccf1) */
+#define CECAR_SRCID_SHIFT_CCF1 24
+#define CECAR_SRCID_MASK_CCF1 (0xff << CECAR_SRCID_SHIFT_CCF1)
+#define CECAR_SRCID_SHIFT_CCF2 18
+#define CECAR_SRCID_MASK_CCF2 (0xff << CECAR_SRCID_SHIFT_CCF2)
+
+#define CECADDRH_ADDRH 0xff
+
+struct ccf_private {
+ const struct ccf_info *info;
+ struct device *dev;
+ void __iomem *regs;
+ struct ccf_err_regs __iomem *err_regs;
+};
+
+static irqreturn_t ccf_irq(int irq, void *dev_id)
+{
+ struct ccf_private *ccf = dev_id;
+ static DEFINE_RATELIMIT_STATE(ratelimit, DEFAULT_RATELIMIT_INTERVAL,
+ DEFAULT_RATELIMIT_BURST);
+ u32 errdet, cecar, cecar2;
+ u64 addr;
+ u32 src_id;
+ bool uvt = false;
+ bool cap_valid = false;
+
+ errdet = ioread32be(&ccf->err_regs->errdet);
+ cecar = ioread32be(&ccf->err_regs->cecar);
+ cecar2 = ioread32be(&ccf->err_regs->cecar2);
+ addr = ioread32be(&ccf->err_regs->cecaddrl);
+ addr |= ((u64)(ioread32be(&ccf->err_regs->cecaddrh) &
+ CECADDRH_ADDRH)) << 32;
+
+ if (!__ratelimit(&ratelimit))
+ goto out;
+
+ switch (ccf->info->version) {
+ case CCF1:
+ if (cecar & CECAR_VAL) {
+ if (cecar & CECAR_UVT)
+ uvt = true;
+
+ src_id = (cecar & CECAR_SRCID_MASK_CCF1) >>
+ CECAR_SRCID_SHIFT_CCF1;
+ cap_valid = true;
+ }
+
+ break;
+ case CCF2:
+ if (errdet & ERRDET_CAP) {
+ src_id = (cecar & CECAR_SRCID_MASK_CCF2) >>
+ CECAR_SRCID_SHIFT_CCF2;
+ cap_valid = true;
+ }
+
+ break;
+ }
+
+ dev_crit(ccf->dev, "errdet 0x%08x cecar 0x%08x cecar2 0x%08x\n",
+ errdet, cecar, cecar2);
+
+ if (errdet & ERRDET_LAE) {
+ if (uvt)
+ dev_crit(ccf->dev, "LAW Unavailable Target ID\n");
+ else
+ dev_crit(ccf->dev, "Local Access Window Error\n");
+ }
+
+ if (errdet & ERRDET_CV)
+ dev_crit(ccf->dev, "Coherency Violation\n");
+
+ if (cap_valid) {
+ dev_crit(ccf->dev, "address 0x%09llx, src id 0x%x\n",
+ addr, src_id);
+ }
+
+out:
+ iowrite32be(errdet, &ccf->err_regs->errdet);
+ return errdet ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static int ccf_probe(struct platform_device *pdev)
+{
+ struct ccf_private *ccf;
+ struct resource *r;
+ const struct of_device_id *match;
+ int ret, irq;
+
+ match = of_match_device(ccf_matches, &pdev->dev);
+ if (WARN_ON(!match))
+ return -ENODEV;
+
+ ccf = devm_kzalloc(&pdev->dev, sizeof(*ccf), GFP_KERNEL);
+ if (!ccf)
+ return -ENOMEM;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!r) {
+ dev_err(&pdev->dev, "%s: no mem resource\n", __func__);
+ return -ENXIO;
+ }
+
+ ccf->regs = devm_ioremap_resource(&pdev->dev, r);
+ if (IS_ERR(ccf->regs)) {
+ dev_err(&pdev->dev, "%s: can't map mem resource\n", __func__);
+ return PTR_ERR(ccf->regs);
+ }
+
+ ccf->dev = &pdev->dev;
+ ccf->info = match->data;
+ ccf->err_regs = ccf->regs + ccf->info->err_reg_offs;
+
+ dev_set_drvdata(&pdev->dev, ccf);
+
+ irq = platform_get_irq(pdev, 0);
+ if (!irq) {
+ dev_err(&pdev->dev, "%s: no irq\n", __func__);
+ return -ENXIO;
+ }
+
+ ret = devm_request_irq(&pdev->dev, irq, ccf_irq, 0, pdev->name, ccf);
+ if (ret) {
+ dev_err(&pdev->dev, "%s: can't request irq\n", __func__);
+ return ret;
+ }
+
+ switch (ccf->info->version) {
+ case CCF1:
+ /* On CCF1 this register enables rather than disables. */
+ iowrite32be(ERRDET_LAE | ERRDET_CV, &ccf->err_regs->errdis);
+ break;
+
+ case CCF2:
+ iowrite32be(0, &ccf->err_regs->errdis);
+ iowrite32be(ERRDET_LAE | ERRDET_CV, &ccf->err_regs->errinten);
+ break;
+ }
+
+ return 0;
+}
+
+static int ccf_remove(struct platform_device *pdev)
+{
+ struct ccf_private *ccf = dev_get_drvdata(&pdev->dev);
+
+ switch (ccf->info->version) {
+ case CCF1:
+ iowrite32be(0, &ccf->err_regs->errdis);
+ break;
+
+ case CCF2:
+ /*
+ * We clear errdis on ccf1 because that's the only way to
+ * disable interrupts, but on ccf2 there's no need to disable
+ * detection.
+ */
+ iowrite32be(0, &ccf->err_regs->errinten);
+ break;
+ }
+
+ return 0;
+}
+
+static struct platform_driver ccf_driver = {
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .owner = THIS_MODULE,
+ .of_match_table = ccf_matches,
+ },
+ .probe = ccf_probe,
+ .remove = ccf_remove,
+};
+
+module_platform_driver(ccf_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Freescale Semiconductor");
+MODULE_DESCRIPTION("Freescale CoreNet Coherency Fabric error reporting");
--
1.9.1
^ permalink raw reply related
* Pull request: scottwood/linux.git next
From: Scott Wood @ 2014-07-03 0:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Highlights include MAINTAINERS updates, t4240rdb and t2080qds support,
removal of the long-broken mpc8xx pcmcia driver, and various minor fixes
and updates.
The following changes since commit 68986c9f0f4552c34c248501eb0c690553866d6e:
Revert "offb: Add palette hack for little endian" (2014-06-16 19:45:45 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to cd1154770ba984f4c766cac5ea42c38880080b1d:
powerpc/85xx: drop hypervisor specific board compatibles (2014-07-02 17:33:10 -0500)
----------------------------------------------------------------
Bharat Bhushan (1):
booke/powerpc: define wimge shift mask to fix compilation error
Chunhe Lan (2):
t4240/dts: Enable third elo3 DMA engine support
powerpc/85xx: Add T4240RDB board support
Laurentiu TUDOR (1):
powerpc/85xx: drop hypervisor specific board compatibles
Laurentiu Tudor (1):
powerpc/booke64: wrap tlb lock and search in htw miss with FTR_SMT
Marcelo Tosatti (1):
MAINTAINERS: Update PPC 8xx entry
Scott Wood (6):
powerpc/e6500: hw tablewalk: clear TID in kernel indirect entries
powerpc/e6500: hw tablewalk: fix recursive tlb lock on cpu 0
powerpc/e500mc: Fix wrong value of MCSR_L2MMU_MHIT
MAINTAINERS: Update Linux for Freescale PowerPC
pcmcia: Remove m8xx_pcmcia driver
powerpc/8xx: Remove empty asm/mpc8xx.h
Shengzhou Liu (3):
powerpc/defconfig: update RTC support
powerpc/fsl-booke: Add support for T2080/T2081 SoC
powerpc/fsl-booke: Add initial T208x QDS board support
Valentin Longchamp (1):
powerpc/mpc85xx: fix fsl/p2041-post.dtsi clockgen mux2
Wladislav Wiebe (1):
powerpc/traps/e500: fix misleading error output
MAINTAINERS | 3 +-
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/t2080si-post.dtsi | 69 ++
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 435 ++++++++
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 99 ++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 1 +
arch/powerpc/boot/dts/t2080qds.dts | 57 ++
arch/powerpc/boot/dts/t2081qds.dts | 46 +
arch/powerpc/boot/dts/t208xqds.dtsi | 239 +++++
arch/powerpc/boot/dts/t4240rdb.dts | 186 ++++
arch/powerpc/configs/corenet32_smp_defconfig | 3 +-
arch/powerpc/configs/corenet64_smp_defconfig | 4 +
arch/powerpc/configs/mpc85xx_defconfig | 3 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 3 +
arch/powerpc/include/asm/fs_pd.h | 1 -
arch/powerpc/include/asm/mpc85xx.h | 2 +
arch/powerpc/include/asm/mpc8xx.h | 12 -
arch/powerpc/include/asm/pte-fsl-booke.h | 2 +
arch/powerpc/include/asm/reg_booke.h | 2 +-
arch/powerpc/kernel/traps.c | 2 +-
arch/powerpc/mm/tlb_low_64e.S | 19 +-
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 52 +-
arch/powerpc/platforms/8xx/m8xx_setup.c | 3 -
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 62 --
arch/powerpc/platforms/8xx/tqm8xx_setup.c | 1 -
arch/powerpc/sysdev/micropatch.c | 1 -
drivers/net/ethernet/freescale/fs_enet/mac-fec.c | 1 -
drivers/net/ethernet/freescale/fs_enet/mac-scc.c | 1 -
drivers/pcmcia/Kconfig | 10 -
drivers/pcmcia/Makefile | 1 -
drivers/pcmcia/m8xx_pcmcia.c | 1168 ----------------------
33 files changed, 1189 insertions(+), 1303 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi
create mode 100644 arch/powerpc/boot/dts/t2080qds.dts
create mode 100644 arch/powerpc/boot/dts/t2081qds.dts
create mode 100644 arch/powerpc/boot/dts/t208xqds.dtsi
create mode 100644 arch/powerpc/boot/dts/t4240rdb.dts
delete mode 100644 arch/powerpc/include/asm/mpc8xx.h
delete mode 100644 drivers/pcmcia/m8xx_pcmcia.c
^ permalink raw reply
* [PATCH v5] flexcan: add err_irq handler for flexcan
From: Zhao Qiang @ 2014-07-03 2:23 UTC (permalink / raw)
To: linuxppc-dev, wg, mkl, linux-can, B07421; +Cc: Zhao Qiang
when flexcan is not physically linked, command 'cantest' will
trigger an err_irq, add err_irq handler for it.
Signed-off-by: Zhao Qiang <B45475@freescale.com>
---
Changes for v2:
- use a space instead of tab
- use flexcan_poll_state instead of print
Changes for v3:
- return IRQ_HANDLED if err is triggered
- stop transmitted packets when there is an err_interrupt
Changes for v4:
- call flexcan_irq
Changes for v5:
- move err_int_handling code from flexcan_irq to flexcan_err_irq
- call flexcan_err_irq from flexcan_irq
drivers/net/can/flexcan.c | 55 ++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index f425ec2..a12d3a4 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -208,6 +208,7 @@ struct flexcan_priv {
void __iomem *base;
u32 reg_esr;
u32 reg_ctrl_default;
+ int err_irq;
struct clk *clk_ipg;
struct clk *clk_per;
@@ -690,19 +691,22 @@ static int flexcan_poll(struct napi_struct *napi, int quota)
return work_done;
}
-static irqreturn_t flexcan_irq(int irq, void *dev_id)
+static irqreturn_t flexcan_err_irq(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
- struct net_device_stats *stats = &dev->stats;
struct flexcan_priv *priv = netdev_priv(dev);
struct flexcan_regs __iomem *regs = priv->base;
- u32 reg_iflag1, reg_esr;
+ u32 reg_ctrl, reg_esr, reg_iflag1;
+ irqreturn_t ret = IRQ_NONE;
- reg_iflag1 = flexcan_read(®s->iflag1);
reg_esr = flexcan_read(®s->esr);
- /* ACK all bus error and state change IRQ sources */
- if (reg_esr & FLEXCAN_ESR_ALL_INT)
+ reg_ctrl = flexcan_read(®s->ctrl);
+ reg_iflag1 = flexcan_read(®s->iflag1);
+
+ if (reg_esr & FLEXCAN_ESR_ALL_INT) {
flexcan_write(reg_esr & FLEXCAN_ESR_ALL_INT, ®s->esr);
+ ret = IRQ_HANDLED;
+ }
/*
* schedule NAPI in case of:
@@ -725,6 +729,23 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
napi_schedule(&priv->napi);
}
+ if (reg_esr & FLEXCAN_ESR_ERR_INT)
+ flexcan_write(reg_ctrl & ~FLEXCAN_CTRL_ERR_MSK, ®s->ctrl);
+
+ return ret;
+}
+
+static irqreturn_t flexcan_irq(int irq, void *dev_id)
+{
+ struct net_device *dev = dev_id;
+ struct net_device_stats *stats = &dev->stats;
+ struct flexcan_priv *priv = netdev_priv(dev);
+ struct flexcan_regs __iomem *regs = priv->base;
+ u32 reg_iflag1;
+
+ reg_iflag1 = flexcan_read(®s->iflag1);
+
+ flexcan_err_irq(irq, dev);
/* FIFO overflow */
if (reg_iflag1 & FLEXCAN_IFLAG_RX_FIFO_OVERFLOW) {
flexcan_write(FLEXCAN_IFLAG_RX_FIFO_OVERFLOW, ®s->iflag1);
@@ -944,10 +965,17 @@ static int flexcan_open(struct net_device *dev)
if (err)
goto out_close;
+ if (priv->err_irq) {
+ err = request_irq(priv->err_irq, flexcan_err_irq, IRQF_SHARED,
+ dev->name, dev);
+ if (err)
+ goto out_free_irq;
+ }
+
/* start chip and queuing */
err = flexcan_chip_start(dev);
if (err)
- goto out_free_irq;
+ goto out_free_err_irq;
can_led_event(dev, CAN_LED_EVENT_OPEN);
@@ -956,6 +984,9 @@ static int flexcan_open(struct net_device *dev)
return 0;
+ out_free_err_irq:
+ if (priv->err_irq)
+ free_irq(priv->err_irq, dev);
out_free_irq:
free_irq(dev->irq, dev);
out_close:
@@ -977,6 +1008,9 @@ static int flexcan_close(struct net_device *dev)
flexcan_chip_stop(dev);
free_irq(dev->irq, dev);
+ if (priv->err_irq)
+ free_irq(priv->err_irq, dev);
+
clk_disable_unprepare(priv->clk_per);
clk_disable_unprepare(priv->clk_ipg);
@@ -1099,7 +1133,7 @@ static int flexcan_probe(struct platform_device *pdev)
struct resource *mem;
struct clk *clk_ipg = NULL, *clk_per = NULL;
void __iomem *base;
- int err, irq;
+ int err, irq, err_irq;
u32 clock_freq = 0;
if (pdev->dev.of_node)
@@ -1126,6 +1160,10 @@ static int flexcan_probe(struct platform_device *pdev)
if (irq <= 0)
return -ENODEV;
+ err_irq = platform_get_irq(pdev, 1);
+ if (err_irq <= 0)
+ err_irq = 0;
+
base = devm_ioremap_resource(&pdev->dev, mem);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -1149,6 +1187,7 @@ static int flexcan_probe(struct platform_device *pdev)
dev->flags |= IFF_ECHO;
priv = netdev_priv(dev);
+ priv->err_irq = err_irq;
priv->can.clock.freq = clock_freq;
priv->can.bittiming_const = &flexcan_bittiming_const;
priv->can.do_set_mode = flexcan_set_mode;
--
1.8.5
^ permalink raw reply related
* RE: [PATCH v2] memory: Freescale CoreNet Coherency Fabric error reporting driver
From: Bharat.Bhushan @ 2014-07-03 3:37 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev@lists.ozlabs.org; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20140702235211.GA3898@home.buserror.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, July 03, 2014 5:22 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org; Bhushan Bharat-R65777
> Subject: [PATCH v2] memory: Freescale CoreNet Coherency Fabric error repo=
rting
> driver
>=20
> The CoreNet Coherency Fabric is part of the memory subsystem on
> some Freescale QorIQ chips. It can report coherency violations (e.g.
> due to misusing memory that is mapped noncoherent) as well as
> transactions that do not hit any local access window, or which hit a
> local access window with an invalid target ID.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Regards
-Bharat
> ---
> v2:
> - s/cecadr/cecaddr/ to consistently use ccf2 names
> - fix ERRDET_CTYPE_MASK value
> - use the ccf2 value for CECADDRH_ADDRH (harmless on ccf1)
> - add comment explaining why we disable detection on remove for
> ccf1 but not ccf2
> ---
> arch/powerpc/configs/corenet32_smp_defconfig | 1 +
> arch/powerpc/configs/corenet64_smp_defconfig | 1 +
> drivers/memory/Kconfig | 10 ++
> drivers/memory/Makefile | 1 +
> drivers/memory/fsl-corenet-cf.c | 251 +++++++++++++++++++++=
++++++
> 5 files changed, 264 insertions(+)
> create mode 100644 drivers/memory/fsl-corenet-cf.c
>=20
> diff --git a/arch/powerpc/configs/corenet32_smp_defconfig
> b/arch/powerpc/configs/corenet32_smp_defconfig
> index 7d0c837..6a3c58a 100644
> --- a/arch/powerpc/configs/corenet32_smp_defconfig
> +++ b/arch/powerpc/configs/corenet32_smp_defconfig
> @@ -180,3 +180,4 @@ CONFIG_CRYPTO_SHA512=3Dy
> CONFIG_CRYPTO_AES=3Dy
> # CONFIG_CRYPTO_ANSI_CPRNG is not set
> CONFIG_CRYPTO_DEV_FSL_CAAM=3Dy
> +CONFIG_FSL_CORENET_CF=3Dy
> diff --git a/arch/powerpc/configs/corenet64_smp_defconfig
> b/arch/powerpc/configs/corenet64_smp_defconfig
> index 6ae07e1..4b07bad 100644
> --- a/arch/powerpc/configs/corenet64_smp_defconfig
> +++ b/arch/powerpc/configs/corenet64_smp_defconfig
> @@ -179,3 +179,4 @@ CONFIG_CRYPTO_SHA256=3Dy
> CONFIG_CRYPTO_SHA512=3Dy
> # CONFIG_CRYPTO_ANSI_CPRNG is not set
> CONFIG_CRYPTO_DEV_FSL_CAAM=3Dy
> +CONFIG_FSL_CORENET_CF=3Dy
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index c59e9c9..fab81a1 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -61,6 +61,16 @@ config TEGRA30_MC
> analysis, especially for IOMMU/SMMU(System Memory Management
> Unit) module.
>=20
> +config FSL_CORENET_CF
> + tristate "Freescale CoreNet Error Reporting"
> + depends on FSL_SOC_BOOKE
> + help
> + Say Y for reporting of errors from the Freescale CoreNet
> + Coherency Fabric. Errors reported include accesses to
> + physical addresses that mapped by no local access window
> + (LAW) or an invalid LAW, as well as bad cache state that
> + represents a coherency violation.
> +
> config FSL_IFC
> bool
> depends on FSL_SOC
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index 71160a2..4055c47 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_OF) +=3D of_memory.o
> endif
> obj-$(CONFIG_TI_AEMIF) +=3D ti-aemif.o
> obj-$(CONFIG_TI_EMIF) +=3D emif.o
> +obj-$(CONFIG_FSL_CORENET_CF) +=3D fsl-corenet-cf.o
> obj-$(CONFIG_FSL_IFC) +=3D fsl_ifc.o
> obj-$(CONFIG_MVEBU_DEVBUS) +=3D mvebu-devbus.o
> obj-$(CONFIG_TEGRA20_MC) +=3D tegra20-mc.o
> diff --git a/drivers/memory/fsl-corenet-cf.c b/drivers/memory/fsl-corenet=
-cf.c
> new file mode 100644
> index 0000000..c9443fc
> --- /dev/null
> +++ b/drivers/memory/fsl-corenet-cf.c
> @@ -0,0 +1,251 @@
> +/*
> + * CoreNet Coherency Fabric error reporting
> + *
> + * Copyright 2014 Freescale Semiconductor Inc.
> + *
> + * 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 y=
our
> + * option) any later version.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/irq.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +#include <linux/platform_device.h>
> +
> +enum ccf_version {
> + CCF1,
> + CCF2,
> +};
> +
> +struct ccf_info {
> + enum ccf_version version;
> + int err_reg_offs;
> +};
> +
> +static const struct ccf_info ccf1_info =3D {
> + .version =3D CCF1,
> + .err_reg_offs =3D 0xa00,
> +};
> +
> +static const struct ccf_info ccf2_info =3D {
> + .version =3D CCF2,
> + .err_reg_offs =3D 0xe40,
> +};
> +
> +static const struct of_device_id ccf_matches[] =3D {
> + {
> + .compatible =3D "fsl,corenet1-cf",
> + .data =3D &ccf1_info,
> + },
> + {
> + .compatible =3D "fsl,corenet2-cf",
> + .data =3D &ccf2_info,
> + },
> + {}
> +};
> +
> +struct ccf_err_regs {
> + u32 errdet; /* 0x00 Error Detect Register */
> + /* 0x04 Error Enable (ccf1)/Disable (ccf2) Register */
> + u32 errdis;
> + /* 0x08 Error Interrupt Enable Register (ccf2 only) */
> + u32 errinten;
> + u32 cecar; /* 0x0c Error Capture Attribute Register */
> + u32 cecaddrh; /* 0x10 Error Capture Address High */
> + u32 cecaddrl; /* 0x14 Error Capture Address Low */
> + u32 cecar2; /* 0x18 Error Capture Attribute Register 2 */
> +};
> +
> +/* LAE/CV also valid for errdis and errinten */
> +#define ERRDET_LAE (1 << 0) /* Local Access Error */
> +#define ERRDET_CV (1 << 1) /* Coherency Violation */
> +#define ERRDET_CTYPE_SHIFT 26 /* Capture Type (ccf2 only) */
> +#define ERRDET_CTYPE_MASK (0x1f << ERRDET_CTYPE_SHIFT)
> +#define ERRDET_CAP (1 << 31) /* Capture Valid (ccf2 only) */
> +
> +#define CECAR_VAL (1 << 0) /* Valid (ccf1 only) */
> +#define CECAR_UVT (1 << 15) /* Unavailable target ID (ccf1) */
> +#define CECAR_SRCID_SHIFT_CCF1 24
> +#define CECAR_SRCID_MASK_CCF1 (0xff << CECAR_SRCID_SHIFT_CCF1)
> +#define CECAR_SRCID_SHIFT_CCF2 18
> +#define CECAR_SRCID_MASK_CCF2 (0xff << CECAR_SRCID_SHIFT_CCF2)
> +
> +#define CECADDRH_ADDRH 0xff
> +
> +struct ccf_private {
> + const struct ccf_info *info;
> + struct device *dev;
> + void __iomem *regs;
> + struct ccf_err_regs __iomem *err_regs;
> +};
> +
> +static irqreturn_t ccf_irq(int irq, void *dev_id)
> +{
> + struct ccf_private *ccf =3D dev_id;
> + static DEFINE_RATELIMIT_STATE(ratelimit, DEFAULT_RATELIMIT_INTERVAL,
> + DEFAULT_RATELIMIT_BURST);
> + u32 errdet, cecar, cecar2;
> + u64 addr;
> + u32 src_id;
> + bool uvt =3D false;
> + bool cap_valid =3D false;
> +
> + errdet =3D ioread32be(&ccf->err_regs->errdet);
> + cecar =3D ioread32be(&ccf->err_regs->cecar);
> + cecar2 =3D ioread32be(&ccf->err_regs->cecar2);
> + addr =3D ioread32be(&ccf->err_regs->cecaddrl);
> + addr |=3D ((u64)(ioread32be(&ccf->err_regs->cecaddrh) &
> + CECADDRH_ADDRH)) << 32;
> +
> + if (!__ratelimit(&ratelimit))
> + goto out;
> +
> + switch (ccf->info->version) {
> + case CCF1:
> + if (cecar & CECAR_VAL) {
> + if (cecar & CECAR_UVT)
> + uvt =3D true;
> +
> + src_id =3D (cecar & CECAR_SRCID_MASK_CCF1) >>
> + CECAR_SRCID_SHIFT_CCF1;
> + cap_valid =3D true;
> + }
> +
> + break;
> + case CCF2:
> + if (errdet & ERRDET_CAP) {
> + src_id =3D (cecar & CECAR_SRCID_MASK_CCF2) >>
> + CECAR_SRCID_SHIFT_CCF2;
> + cap_valid =3D true;
> + }
> +
> + break;
> + }
> +
> + dev_crit(ccf->dev, "errdet 0x%08x cecar 0x%08x cecar2 0x%08x\n",
> + errdet, cecar, cecar2);
> +
> + if (errdet & ERRDET_LAE) {
> + if (uvt)
> + dev_crit(ccf->dev, "LAW Unavailable Target ID\n");
> + else
> + dev_crit(ccf->dev, "Local Access Window Error\n");
> + }
> +
> + if (errdet & ERRDET_CV)
> + dev_crit(ccf->dev, "Coherency Violation\n");
> +
> + if (cap_valid) {
> + dev_crit(ccf->dev, "address 0x%09llx, src id 0x%x\n",
> + addr, src_id);
> + }
> +
> +out:
> + iowrite32be(errdet, &ccf->err_regs->errdet);
> + return errdet ? IRQ_HANDLED : IRQ_NONE;
> +}
> +
> +static int ccf_probe(struct platform_device *pdev)
> +{
> + struct ccf_private *ccf;
> + struct resource *r;
> + const struct of_device_id *match;
> + int ret, irq;
> +
> + match =3D of_match_device(ccf_matches, &pdev->dev);
> + if (WARN_ON(!match))
> + return -ENODEV;
> +
> + ccf =3D devm_kzalloc(&pdev->dev, sizeof(*ccf), GFP_KERNEL);
> + if (!ccf)
> + return -ENOMEM;
> +
> + r =3D platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!r) {
> + dev_err(&pdev->dev, "%s: no mem resource\n", __func__);
> + return -ENXIO;
> + }
> +
> + ccf->regs =3D devm_ioremap_resource(&pdev->dev, r);
> + if (IS_ERR(ccf->regs)) {
> + dev_err(&pdev->dev, "%s: can't map mem resource\n", __func__);
> + return PTR_ERR(ccf->regs);
> + }
> +
> + ccf->dev =3D &pdev->dev;
> + ccf->info =3D match->data;
> + ccf->err_regs =3D ccf->regs + ccf->info->err_reg_offs;
> +
> + dev_set_drvdata(&pdev->dev, ccf);
> +
> + irq =3D platform_get_irq(pdev, 0);
> + if (!irq) {
> + dev_err(&pdev->dev, "%s: no irq\n", __func__);
> + return -ENXIO;
> + }
> +
> + ret =3D devm_request_irq(&pdev->dev, irq, ccf_irq, 0, pdev->name, ccf);
> + if (ret) {
> + dev_err(&pdev->dev, "%s: can't request irq\n", __func__);
> + return ret;
> + }
> +
> + switch (ccf->info->version) {
> + case CCF1:
> + /* On CCF1 this register enables rather than disables. */
> + iowrite32be(ERRDET_LAE | ERRDET_CV, &ccf->err_regs->errdis);
> + break;
> +
> + case CCF2:
> + iowrite32be(0, &ccf->err_regs->errdis);
> + iowrite32be(ERRDET_LAE | ERRDET_CV, &ccf->err_regs->errinten);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static int ccf_remove(struct platform_device *pdev)
> +{
> + struct ccf_private *ccf =3D dev_get_drvdata(&pdev->dev);
> +
> + switch (ccf->info->version) {
> + case CCF1:
> + iowrite32be(0, &ccf->err_regs->errdis);
> + break;
> +
> + case CCF2:
> + /*
> + * We clear errdis on ccf1 because that's the only way to
> + * disable interrupts, but on ccf2 there's no need to disable
> + * detection.
> + */
> + iowrite32be(0, &ccf->err_regs->errinten);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static struct platform_driver ccf_driver =3D {
> + .driver =3D {
> + .name =3D KBUILD_MODNAME,
> + .owner =3D THIS_MODULE,
> + .of_match_table =3D ccf_matches,
> + },
> + .probe =3D ccf_probe,
> + .remove =3D ccf_remove,
> +};
> +
> +module_platform_driver(ccf_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Freescale Semiconductor");
> +MODULE_DESCRIPTION("Freescale CoreNet Coherency Fabric error reporting")=
;
> --
> 1.9.1
^ permalink raw reply
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