On Wednesday 03 June 2015 06:36 AM, Daniel Axtens wrote:
> On Tue, 2015-06-02 at 21:29 +0530, Madhavan Srinivasan wrote:
>> Patch adds common event attribute function and Nest pmu registration call.
>>
>> Cc: Michael Ellerman
>> Cc: Benjamin Herrenschmidt
>> Cc: Paul Mackerras
>> Cc: Sukadev B
On Fri, 2015-06-05 at 16:35 +1000, Alexey Kardashevskiy wrote:
> So far one TCE table could only be used by one IOMMU group. However
> IODA2 hardware allows programming the same TCE table address to
> multiple PE allowing sharing tables.
...
> diff --git a/arch/powerpc/platforms/powernv/pci.c
>
On Mon, 2015-06-08 at 21:19 -0500, Jia Hongtao-B38951 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, May 27, 2015 3:38 AM
> > To: Jia Hongtao-B38951
> > Cc: edubez...@gmail.com; linuxppc-dev@lists.ozlabs.org;
> > devicet...@vger.kernel.org; robh...@kernel.org
On Tue, 2015-06-09 at 09:53 +0800, yuantian.t...@freescale.com wrote:
> From: Tang Yuantian
>
> Various e500 core have different cache architecture, so they
> need different cache flush operations. Therefore, add a callback
> function cpu_flush_caches to the struct cpu_spec. The cache flush
> ope
Commit 4fc9b87bae25 ("net: fs_enet: Implement NETIF_F_SG feature")
brings a trouble to Freescale MPC512x: a kernel oops happens
during sending non-linear sk_buff with .data not aligned by 4.
Log quotation:
Unable to handle kernel paging request for data at address 0xd067c000
Faulting instruction
From: Alexander Popov
Date: Wed, 10 Jun 2015 02:57:42 +0300
> skb_copy_from_linear_data() which doesn't work well for non-linear sk_buff:
The correct fix is to use an SKB copy routine which can
handle non-linear data.
___
Linuxppc-dev mailing list
Lin
Please see my replay inline.
From: Wood Scott-B07421
Sent: Wednesday, June 10, 2015 6:28 AM
To: Tang Yuantian-B29983
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
linux-ker...@vger.kernel.org; Zhao Chenhui-B35336; Tang Yuantian
Subject: Re: [PATCH v
On Tue, 2015-06-09 at 21:00 -0500, Tang Yuantian-B29983 wrote:
> Please see my replay inline.
>
> From: Wood Scott-B07421
> Sent: Wednesday, June 10, 2015 6:28 AM
> To: Tang Yuantian-B29983
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> linux-ker
From: Tang Yuantian
Various e500 core have different cache architecture, so they
need different cache flush operations. Therefore, add a callback
function cpu_flush_caches to the struct cpu_spec. The cache flush
operation for the specific kind of e500 is selected at init time.
The callback functi
The code introduced in
"[PATCH kernel v12 17/34]
powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group"
checks that an IOMMU group was registered for the specific
table group which is not true when CONFIG_IOMMU_API is off as
iommu_register_group() is a stub in this case.
This makes
Hi Anshuman,
Was there a cover letter for this series that I missed?
On Mon, 2015-06-08 at 17:08 +0530, Anshuman Khandual wrote:
> BHRB is a rolling buffer. Hence we might end up in a situation where
Could you spell out what BHRB stands for?
> we have read one target address but when we try to r
In the subject line, privilege should only have 1 l, and I think it
should probably start with "powerpc/perf:" rather than "powerpc, perf:".
On Mon, 2015-06-08 at 17:08 +0530, Anshuman Khandual wrote:
> From: "khand...@linux.vnet.ibm.com"
>
> 'commit 9de5cb0f6df8 ("powerpc/perf: Add per-event ex
On 06/04/2015 04:41 PM, Gavin Shan wrote:
The patch cleans up DMA32 in pci-ioda.c. It shouldn't introduce
behavioural changes:
* Rename various fields in "struct pnv_phb" and "struct pnv_ioda_pe"
as 32-bits DMA should be related to "DMA", not "TCE", and move
them around to reflec
> +void update_branch_entry(struct cpu_hw_events *cpuhw,
> + int index, u64 from, u64 to, int pred)
> +{
> + cpuhw->bhrb_entries[index].from = from;
> + cpuhw->bhrb_entries[index].to = to;
> + cpuhw->bhrb_entries[index].mispred = pred;
> + cpuhw->bhrb_entries[in
On 06/04/2015 04:41 PM, Gavin Shan wrote:
Each PHB maintains an array helping to translate RID (Request
ID) to PE# with the assumption that PE# takes 8 bits, indicating
that we can't have more than 256 PEs. However, pci_dn->pe_number
already had 4-bytes for the PE#.
The patch extends the PE# cap
On 06/04/2015 04:41 PM, Gavin Shan wrote:
Each PHB maintains one instance of "struct pci_controller_ops",
which includes various callbacks called by PCI subsystem. In the
definition of this struct, some callbacks have explicit names for
its arguments, but the left don't have.
The patch removes a
Node distance will not get initialized in certain cases as
dynamic-reconfiguration path does not initialize the lookup table.
There is an assumption about the associativity list in
initialize_distance_lookup_table(). Associativity list has two forms:
a) [cpu,memory]@x/ibm,associativity has follow
> /* Every thing else is unsupported */
> return -1;
You're returning -1 as a unsigned 64bit number. Other code that reads
this value tests for -1 and I think it works everywhere just because it
wraps around consistently. But I would still rather not do this and I'm
surprised it doesn'
Reworded commit log:
From: Nikunj A Dadhania
powerpc/numa: initialize distance lookup table from drconf path
In some situations, a NUMA guest that supports
ibm,dynamic-memory-reconfiguration node will end up having flat NUMA
distances between nodes. This is because of two problems in the
curre
> +static int instr_is_branch_xlform(unsigned int instr)
> +{
> + return branch_opcode(instr) == 19;
> +}
Why do these not return bool? The functions below do.
> +
> +static int is_xlform_lr(unsigned int instr)
> +{
> + return (instr & XL_FORM_LR) == XL_FORM_LR;
> +}
> +
> +static int is_b
On Mon, 2015-06-08 at 17:08 +0530, Anshuman Khandual wrote:
> The kernel now supports SW based branch filters for book3s systems with
> some specific requirements while dealing with HW supported branch filters
> in order to achieve overall OR semantics prevailing in perf branch stack
> sampling fra
On Wed, Jun 10, 2015 at 02:17:26PM +1000, Alexey Kardashevskiy wrote:
>On 06/04/2015 04:41 PM, Gavin Shan wrote:
>>The patch cleans up DMA32 in pci-ioda.c. It shouldn't introduce
>>behavioural changes:
>>
>>* Rename various fields in "struct pnv_phb" and "struct pnv_ioda_pe"
>> as 32-bits
On Wed, Jun 10, 2015 at 02:41:13PM +1000, Alexey Kardashevskiy wrote:
>On 06/04/2015 04:41 PM, Gavin Shan wrote:
>>Each PHB maintains an array helping to translate RID (Request
>>ID) to PE# with the assumption that PE# takes 8 bits, indicating
>>that we can't have more than 256 PEs. However, pci_dn
On Wed, Jun 10, 2015 at 02:43:57PM +1000, Alexey Kardashevskiy wrote:
>On 06/04/2015 04:41 PM, Gavin Shan wrote:
>>Each PHB maintains one instance of "struct pci_controller_ops",
>>which includes various callbacks called by PCI subsystem. In the
>>definition of this struct, some callbacks have expl
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+jianhua.xie=freescale@lists.ozlabs.org] On Behalf Of Madalin
> Bucur
> Sent: Wednesday, April 29, 2015 10:57 PM
> To: net...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Cc: linux-ker...@vger.kernel.org; Buc
On Mon, Jun 08, 2015 at 10:34:13PM +0100, Grant Likely wrote:
>On Mon, Jun 8, 2015 at 9:57 PM, Benjamin Herrenschmidt
> wrote:
>> On Sun, 2015-06-07 at 08:54 +0100, Grant Likely wrote:
>>> > IE. conceptually, what overlays do today is quite rooted around the idea
>>> > of having a fixed "base" DT a
26 matches
Mail list logo
