From: Ian Munsie
A recent change in gcc caused this build failure:
/var/lib/jenkins/workspace/gcc_kernel_build/linux/drivers/misc/cxl/cxl.h:72:27:
error: ‘CXL_PSL_DLCNTL’ defined but not used [-Werror=unused-const-variable]
static const cxl_p1_reg_t CXL_PSL_DLCNTL = {0x0060};
Because of this
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Currently the first thing we do in cxl_probe is to grab a reference
on the pci device. Later on, we call device_register on our adapter.
In our remove path, we call device_unregister, but we never call
pci_dev_put. We therefore leak the device every time we do a
reflash.
device_register/unregister
On 09/14/2015 09:54 PM, Nishanth Aravamudan wrote:
> On 14.09.2015 [18:59:25 +0530], Aneesh Kumar K.V wrote:
>> > Anshuman Khandual writes:
>> >
>>> > > When a 16GB huge page is requested on POWER platform through kernel
>>> > > command
>>> > > line interface, it silently fails because of the la
On 09/15/2015 07:38 AM, Raghavendra K T wrote:
The functions used in the patch are in slowpath, which gets called
whenever alloc_super is called during mounts.
Though this should not make difference for the architectures with
sequential numa node ids, for the powerpc which can potentially have
s
Many places in the kernel use 'for' loop with nr_node_ids. For the architectures
which supports sparse numa ids, this will result in some unnecessary allocations
for non existing nodes.
(for e.g., numa node numbers such as 0,1,16,17 is common in powerpc.)
So replace the for loop with for_each_node
Signed-off-by: Raghavendra K T
---
arch/powerpc/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 8b9502a..8d8a541 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -80,7 +80,7 @@ static void __ini
The functions used in the patch are in slowpath, which gets called
whenever alloc_super is called during mounts.
Though this should not make difference for the architectures with
sequential numa node ids, for the powerpc which can potentially have
sparse node ids (for e.g., 4 node system having nu
The kernel does it, not the boot wrapper, which breaks with some
cross compilers that still default to ABI v1.
Signed-off-by: Benjamin Herrenschmidt
CC: sta...@vger.kernel.org
--
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 73eddda..4eec430 100644
--- a/arch/powerpc
On Mon, 2015-09-14 at 09:24 -0700, Nishanth Aravamudan wrote:
> On 14.09.2015 [18:59:25 +0530], Aneesh Kumar K.V wrote:
> > Anshuman Khandual writes:
> >
> > > When a 16GB huge page is requested on POWER platform through kernel
> > > command
> > > line interface, it silently fails because of the
On Mon, 2015-09-14 at 11:13 -0500, Scott Wood wrote:
> On Mon, 2015-09-14 at 17:44 +0200, Christophe LEROY wrote:
> > Le 14/09/2015 17:20, Scott Wood a écrit :
> > > On Mon, 2015-09-14 at 08:21 +0200, Christophe Leroy wrote:
> > > > diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32
Refresh and remove obsolete CONFIG_EXT3_FS.
Signed-off-by: Geoff Levand
---
V2: Remove ext3 as suggested by Geert.
arch/powerpc/configs/ps3_defconfig | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/configs/ps3_defconfig
b/arch/powerpc/configs/ps3_defconfig
index adc14e8..6
Hi Geoff,
On Mon, Sep 14, 2015 at 9:35 PM, Geoff Levand wrote:
> diff --git a/arch/powerpc/configs/ps3_defconfig
> b/arch/powerpc/configs/ps3_defconfig
> index adc14e8..09f117e 100644
> --- a/arch/powerpc/configs/ps3_defconfig
> +++ b/arch/powerpc/configs/ps3_defconfig
> @@ -142,7 +141,6 @@ CON
Signed-off-by: Geoff Levand
---
arch/powerpc/configs/ps3_defconfig | 4
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc/configs/ps3_defconfig
b/arch/powerpc/configs/ps3_defconfig
index adc14e8..09f117e 100644
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_
On the unlikely event that drv is null, the current code will
perform a null pointer dereference with it when printing a dev_dbg
message. Instead, the BUG_ON check on drv should be performed
before we emit the dev_dbg message.
Signed-off-by: Colin Ian King
Signed-off-by: Geoff Levand
---
drive
Fixed a coding style issue.
Signed-off-by: Rudhresh Kumar J
Signed-off-by: Geoff Levand
---
drivers/ps3/ps3-lpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ps3/ps3-lpm.c b/drivers/ps3/ps3-lpm.c
index cb7d3a6..e34de9a 100644
--- a/drivers/ps3/ps3-lpm.c
+++ b/dri
A few minor updates for PS3. Please apply.
-Geoff
The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git
for-merge-po
Log a 'critical' message if the max frequency is reduced below nominal
frequency. We already log 'info' message if the max frequency is
capped below turbo frequency. CPU should guarantee atleast nominal
frequency, but not turbo frequency in all system configurations and
environments. So report the
On Mon, Sep 14, 2015 at 04:38:48PM +0100, Will Deacon wrote:
> On Mon, Sep 14, 2015 at 01:11:56PM +0100, Peter Zijlstra wrote:
> > On Mon, Sep 14, 2015 at 02:01:53PM +0200, Peter Zijlstra wrote:
> > > The scenario is:
> > >
> > > CPU0CPU1
> > >
> > >
On Sat, 2015-09-12 at 11:57 +0200, christophe leroy wrote:
> Le 11/09/2015 03:24, Michael Ellerman a écrit :
> > On Thu, 2015-09-10 at 17:05 -0500, Scott Wood wrote:
> > >
> > > I don't think this duplication is what Michael meant by "the normal cpu
> > > feature sections". What else is going to
On 14.09.2015 [18:59:25 +0530], Aneesh Kumar K.V wrote:
> Anshuman Khandual writes:
>
> > When a 16GB huge page is requested on POWER platform through kernel command
> > line interface, it silently fails because of the lack of any gigantic pages
> > on the system which the platform should have co
On Mon, 2015-09-14 at 17:44 +0200, Christophe LEROY wrote:
> Le 14/09/2015 17:20, Scott Wood a écrit :
> > On Mon, 2015-09-14 at 08:21 +0200, Christophe Leroy wrote:
> > > memset() uses instruction dcbz to speed up clearing by not wasting time
> > > loading cache line with data that will be overwri
Le 14/09/2015 17:20, Scott Wood a écrit :
On Mon, 2015-09-14 at 08:21 +0200, Christophe Leroy wrote:
memset() uses instruction dcbz to speed up clearing by not wasting time
loading cache line with data that will be overwritten.
Some platform like mpc52xx do no have cache active at startup and
On Mon, Sep 14, 2015 at 01:11:56PM +0100, Peter Zijlstra wrote:
> On Mon, Sep 14, 2015 at 02:01:53PM +0200, Peter Zijlstra wrote:
> > The scenario is:
> >
> > CPU0CPU1
> >
> > unlock(x)
> > smp_store_release(&x->loc
On Mon, 2015-09-14 at 08:21 +0200, Christophe Leroy wrote:
> memset() uses instruction dcbz to speed up clearing by not wasting time
> loading cache line with data that will be overwritten.
> Some platform like mpc52xx do no have cache active at startup and
> can therefore not use memset(). Allthou
Anshuman Khandual writes:
> When a 16GB huge page is requested on POWER platform through kernel command
> line interface, it silently fails because of the lack of any gigantic pages
> on the system which the platform should have communicated through 16GB memory
> blocks in the device tree during
On Mon, Sep 14, 2015 at 06:35:59PM +0530, Raghavendra K T wrote:
> On 09/14/2015 05:34 PM, Vladimir Davydov wrote:
> >On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
> >>On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
> >>>On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T w
On 09/14/2015 05:34 PM, Vladimir Davydov wrote:
On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
The functions used in the patch are in slowpath, which gets called
w
On Mon, Sep 14, 2015 at 02:01:53PM +0200, Peter Zijlstra wrote:
> The scenario is:
>
> CPU0CPU1
>
> unlock(x)
> smp_store_release(&x->lock, 0);
>
> unlock(y)
> smp_store_release(&next->lock, 1);
On Mon, Sep 14, 2015 at 05:09:31PM +0530, Raghavendra K T wrote:
> On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
> >On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
> >>The functions used in the patch are in slowpath, which gets called
> >>whenever alloc_super is called during mou
On Mon, Sep 14, 2015 at 01:35:20PM +0200, Peter Zijlstra wrote:
>
> Sorry for being tardy, I had a wee spell of feeling horrible and then I
> procrastinated longer than I should have.
>
> On Fri, Sep 11, 2015 at 01:45:07PM +0100, Will Deacon wrote:
>
> > Peter, any thoughts? I'm not au fait with
On 09/14/2015 02:30 PM, Vladimir Davydov wrote:
Hi,
On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
The functions used in the patch are in slowpath, which gets called
whenever alloc_super is called during mounts.
Though this should not make difference for the architectures wit
Sorry for being tardy, I had a wee spell of feeling horrible and then I
procrastinated longer than I should have.
On Fri, Sep 11, 2015 at 01:45:07PM +0100, Will Deacon wrote:
> Peter, any thoughts? I'm not au fait with the x86 memory model, but what
> Paul's saying is worrying.
Right, so Paul i
On 9/14/15, Catalin Marinas wrote:
> On Mon, Sep 14, 2015 at 07:36:49PM +1000, Michael Ellerman wrote:
>> On Mon, 2015-09-14 at 10:15 +0100, Catalin Marinas wrote:
>> > You could add some flag to struct msi_bitmap based on mem_init_done to
>> > be able to reclaim some slab memory later. If the bit
On 14-09-15, 14:01, Shilpasri G Bhat wrote:
> Log a 'critical' message if the max frequency is reduced below nominal
> frequency. We already log 'info' message if the max frequency is
> capped below turbo frequency. CPU should guarantee atleast nominal
> frequency, but not turbo frequency in all sy
On Wed, 2015-09-09 at 16:56 +1000, Daniel Axtens wrote:
> Ahaha so I was wrong, device_add does grab a reference.
>
> > Currently, cxl_probe(pdev):
> > 1) calls pci_dev_get(pdev)
> > 2) calls cxl_adapter_init
> > a) init calls cxl_adapter_alloc, which creates a struct cxl,
> >conve
On Mon, Sep 14, 2015 at 07:36:49PM +1000, Michael Ellerman wrote:
> On Mon, 2015-09-14 at 10:15 +0100, Catalin Marinas wrote:
> > You could add some flag to struct msi_bitmap based on mem_init_done to
> > be able to reclaim some slab memory later. If the bitmap is small and
> > such allocation does
On Sat, 2015-09-12 at 11:57 +0200, christophe leroy wrote:
>
> Le 11/09/2015 03:24, Michael Ellerman a écrit :
> > On Thu, 2015-09-10 at 17:05 -0500, Scott Wood wrote:
> >>
> >> I don't think this duplication is what Michael meant by "the normal cpu
> >> feature sections". What else is going to u
Hi,
On Wed, Sep 09, 2015 at 12:01:46AM +0530, Raghavendra K T wrote:
> The functions used in the patch are in slowpath, which gets called
> whenever alloc_super is called during mounts.
>
> Though this should not make difference for the architectures with
> sequential numa node ids, for the power
On Mon, 2015-09-14 at 10:15 +0100, Catalin Marinas wrote:
> On Mon, Sep 14, 2015 at 04:04:37PM +1000, Michael Ellerman wrote:
> > On Sun, 2015-09-13 at 21:36 +0300, Denis Kirjanov wrote:
> > > The comment in msi_bitmap_free() states that we can't free
> > > the bitmap so mark it with the kmemleak_n
On Mon, Sep 14, 2015 at 04:04:37PM +1000, Michael Ellerman wrote:
> On Sun, 2015-09-13 at 21:36 +0300, Denis Kirjanov wrote:
> > During the MSI bitmap test on boot kmemleak spews the following trace:
> >
> > unreferenced object 0xc0016e86c900 (size 64):
> > comm "swapper/0", pid 1, jiffies
On Mon, Sep 14 2015, Christophe Leroy wrote:
> memset() uses instruction dcbz to speed up clearing by not wasting time
> loading cache line with data that will be overwritten.
> Some platform like mpc52xx do no have cache active at startup and
> can therefore not use memset(). Allthough no part of
On 14-09-15, 10:47, Shilpasri G Bhat wrote:
> Log a 'critical' message if the max frequency is reduced below nominal
> frequency. We already log 'info' message if the max frequency is
> capped below turbo frequency. CPU should guarantee atleast nominal
> frequency, but not turbo frequency in all sy
43 matches
Mail list logo
