Hi Denis,
On Wed, 21 Oct 2015 08:56:44 +0300 Denis Kirjanov
wrote:
>
> diff --git a/arch/powerpc/include/asm/msi_bitmap.h
> b/arch/powerpc/include/asm/msi_bitmap.h
> index 1ec7125..fbd3424 100644
> --- a/arch/powerpc/include/asm/msi_bitmap.h
> +++ b/arch/powerpc/include/asm/msi_bitmap.h
> @@ -2
On Wednesday 21 October 2015 08:56:44 Denis Kirjanov wrote:
> Building with CONFIG_DEBUG_SECTION_MISMATCH
> gives the following warning:
>
> WARNING: vmlinux.o(.text+0x41fa8): Section mismatch in reference from
> the function .msi_bitmap_alloc() to the function
> .init.text:.memblock_virt_alloc_tr
On Wed, Oct 21, 2015 at 11:44:26AM +1100, Gavin Shan wrote:
>On Tue, Oct 20, 2015 at 05:03:00PM +0800, Wei Yang wrote:
>>On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
>^
>
>s/PHB_IODA2/PHB3 or s/PHB_IODA2/IODA2 PHB
>
>>a SRIOV device's IOV BAR is not 64bit-p
This fixes a bug where it is possible for an off-line CPU to fail to
go into a low-power state (nap/sleep/winkle), and to become unresponsive
to requests from the KVM subsystem to wake up and run a VCPU. What
can happen is that a maskable interrupt of some kind (external,
decrementer, hypervisor d
This reverts commit 9678cdaae93932473f696fdea5debf3eee1e1260 because
the original commit had multiple, partly self-cancelling bugs, that
could cause occasional memory corruption. In fact the logmpp instruction
was using register r0 as the source of the buffer address and operation
code, and depend
Building with CONFIG_DEBUG_SECTION_MISMATCH
gives the following warning:
WARNING: vmlinux.o(.text+0x41fa8): Section mismatch in reference from
the function .msi_bitmap_alloc() to the function
.init.text:.memblock_virt_alloc_try_nid()
The function .msi_bitmap_alloc() references
the function __init
On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
> Instead of trying to match and probe platform and AMBA devices right
> after each is registered, delay their probes until device_initcall_sync.
>
> This means that devices will start probing once all built-in drivers
> have registered, and a
of_get_property() is used inside the loop, but then the reference to the
node is dropped before dereferencing the prop pointer, which could by then
point to junk if the node has been freed.
Instead use of_property_read_u32() to actually read the property
value before dropping the reference.
Use of
On Tue, Oct 20, 2015 at 05:03:00PM +0800, Wei Yang wrote:
>On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
^
s/PHB_IODA2/PHB3 or s/PHB_IODA2/IODA2 PHB
>a SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned
>from 64bit prefetchable window,
[Re: [PATCH 0/5] drivers/tty: make more bool drivers explicitly non-modular] On
20/10/2015 (Tue 17:10) Alexandre Belloni wrote:
> On 18/10/2015 at 18:21:13 -0400, Paul Gortmaker wrote :
> > The one common thread here for all the patches is that we also
> > scrap the .remove functions which would
On Mon, Oct 19, 2015 at 09:17:18AM +0800, Boqun Feng wrote:
> On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> > On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
> [snip]
> > >
> > > So lots of little confusions added up to complete fail :-{
> > >
> > > Mostly I think
On Tue, Oct 20, 2015 at 11:21:47AM +0200, Peter Zijlstra wrote:
> On Tue, Oct 20, 2015 at 03:15:32PM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > >
> > > Am I missing something here? If not, it seems to me that you need
> > > the leading lwsyn
Hi Michael,
On Tue, 20 Oct 2015 21:06:51 +1100 Michael Ellerman wrote:
>
> On Tue, 2015-10-20 at 16:21 +1100, Stephen Rothwell wrote:
>
> > After merging the powerpc tree, today's linux-next build (powerpc
> > allyesconfig) produced this warning:
> >
> > WARNING: vmlinux.o(.text+0x9367c): Secti
From: Luis de Bethencourt
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt
---
Hi,
This is a resend of a patch sent September 17 [0]
This patch adds the missing MODULE_DEVICE_
From: Luis de Bethencourt
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt
---
arch/powerpc/sysdev/axonram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sys
From: Luis de Bethencourt
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt
---
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/
Hi,
This is a resend of this patch series. It was posted on September 18 [0]
These patches add the missing MODULE_DEVICE_TABLE() for OF to export
the information so modules have the correct aliases built-in and
autoloading works correctly.
A longer explanation by Javier Canillas can be found her
Now that we don't track 4k subpage slot details, get rid of real_pte
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash-64k.h| 15 -
arch/powerpc/include/asm/book3s/64/pgtable.h | 24
arch/powerpc/include/asm/nohash/64/pgtable-64k
Use the #define instead of open-coding the same
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash-64k.h | 2 +-
arch/powerpc/include/asm/book3s/64/pgtable.h | 2 +-
arch/powerpc/include/asm/nohash/64/pgtable.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
---
arch/powerpc/include/asm/book3s/64/hash-64k.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h
b/arch/powerpc/include/asm/book3s/64/hash-64k.h
index 5062c6d423fd..a28dbfe2baed 100644
--- a/arch/powerpc/include/asm/book3s/6
Hi,
This patch series is on top of the series posted at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-October/135299.html
"[PATCH V4 00/31] powerpc/mm: Update page table format for book3s 64". In this
series we remove 4k subpage tracking with 64K config. Instead we do a hash
table lookup
We search the hash table to find the slot information. This slows down
the lookup, but we do that only for 4k subpage config
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash-64k.h | 33 +--
arch/powerpc/include/asm/machdep.h| 2 +
arch/powerpc/
Now that we don't really use real_pte_t drop them from iterator argument
list. The follow up patch will remove real_pte_t completely
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash-64k.h | 5 +++--
arch/powerpc/include/asm/book3s/64/pgtable.h | 7 +++
arch/powe
They don't need to track 4k subpage slot details and hence don't need
second half of pgtable_t.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/nohash/64/pgtable-64k.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/nohash/64/pgtabl
pte and pmd table size are dependent on config items. Don't
hard code the same. This make sure we use the right value
when masking pmd entries and also while checking pmd_bad
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/hash-64k.h| 30 ++--
arch/
On 18/10/2015 at 18:21:13 -0400, Paul Gortmaker wrote :
> The one common thread here for all the patches is that we also
> scrap the .remove functions which would only be used for module
> unload (impossible) and driver unbind. For the drivers here, there
> doesn't seem to be a sensible unbind use
On Mon, Oct 12, 2015 at 04:30:48PM -0700, Paul E. McKenney wrote:
> On Fri, Oct 09, 2015 at 07:33:28PM +0100, Will Deacon wrote:
> > On Fri, Oct 09, 2015 at 10:43:27AM -0700, Paul E. McKenney wrote:
> > > On Fri, Oct 09, 2015 at 10:51:29AM +0100, Will Deacon wrote:
[snip]
>
> > > > We could also i
On Tuesday 20 October 2015 09:50 AM, Madhavan Srinivasan wrote:
On Monday 19 October 2015 05:48 PM, Anju T wrote:
From: Anju
The registers to sample are passed through the sample_regs_intr bitmask.
The name and bit position for each register is defined in asm/perf_regs.h.
This feature can be
Hi maddy,
On Tuesday 20 October 2015 09:46 AM, Madhavan Srinivasan wrote:
On Monday 19 October 2015 05:48 PM, Anju T wrote:
From: Anju
The enum definition assigns an 'id' to each register in power.
I guess it should be "each register in "struct pt_regs" of arch/powerpc
Right, that seems bet
On Tue, 2015-10-20 at 16:21 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
>
> WARNING: vmlinux.o(.text+0x9367c): Section mismatch in reference from the
> function .msi_bitmap_alloc() to the f
On Tue, Oct 20, 2015 at 03:15:32PM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> >
> > Am I missing something here? If not, it seems to me that you need
> > the leading lwsync to instead be a sync.
> >
> > Of course, if I am not missing something,
At the moment 64bit-prefetchable window can be maximum 64GB, which is
currently got from device tree. This means that in shared mode the maximum
supported VF BAR size is 64GB/256=256MB. While this size could exhaust the
whole 64bit-prefetchable window. This is a design decision to set a
boundary to
When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
sparse.
This patch restructures the code to allocate sparse PE# for VFs when M64
BAR is set to Single PE mode. Also it rename the offset to pe_num_map to
reflect the content is the PE number.
Signed-off-by: Wei Yang
Reviewed-
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BARs in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
And in this patch, m64_wins is renamed to m
The alignment of IOV BAR on PowerNV platform is the total size of the IOV
BAR. No matter whether the IOV BAR is extended with number of
roundup_pow_of_two(total_vfs) or number of max PE number (256), the total
size could be calculated by (vfs_expanded * VF_BAR_size).
This patch simplifies the pnv_
Each VF could have 6 BARs at most. When the total BAR size exceeds the
gate, after expanding it will also exhaust the M64 Window.
This patch limits the boundary by checking the total VF BAR size instead of
the individual BAR.
Signed-off-by: Wei Yang
Reviewed-by: Gavin Shan
Acked-by: Alexey Kard
On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
a SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned
from 64bit prefetchable window, which means M64 BAR can't work on it.
The reason is PCI bridges support only 2 windows and the kernel code
programs br
In original design, it tries to group VFs to enable more number of VFs in the
system, when VF BAR is bigger than 64MB. This design has a flaw in which one
error on a VF will interfere other VFs in the same group.
This patch series change this design by using M64 BAR in Single PE mode to
cover only
On Mon, Oct 19, 2015 at 12:23:24PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:17:18AM +0800, Boqun Feng wrote:
> > This is confusing me right now. ;-)
> >
> > Let's use a simple example for only one primitive, as I understand it,
> > if we say a primitive A is "fully ordered", we ac
On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
>
> Am I missing something here? If not, it seems to me that you need
> the leading lwsync to instead be a sync.
>
> Of course, if I am not missing something, then this applies also to the
> value-returning RMW atomic operations t
40 matches
Mail list logo