On 09/04/16 16:13, Aneesh Kumar K.V wrote:
> Only code movement. No functionality change.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/64/pgtable.h | 142
> +--
> 1 file changed, 71 insertions(+), 71 deletions(-)
Acked-by: balbir Singh
On Wed, 2016-04-13 at 15:22 +0200, Jiri Kosina wrote:
> On Wed, 13 Apr 2016, Miroslav Benes wrote:
> > > This series adds live patching support for powerpc (ppc64le only ATM).
> > >
> > > It's unchanged since the version I posted on March 24, with the exception
> > > that
> > > I've dropped the f
Dear all,
I am hoping someone could help me diagnose the following bug report:
https://bugs.debian.org/798102
[...]
After waking from hibernate, I get lots of kworker activity that makes my
fans kick in. Top shows a process called kworker/0:3 always active using
around 3% cpu, and Powertop show
On 13/04/16 04:06, Akshay Adiga wrote:
> This patch brings down global pstate at a slower rate than the local
> pstate. As the frequency transition latency from pmin to pmax is
> observed to be in few millisecond granurality. It takes a performance
> penalty during sudden frequency rampup. Hence
On Thu, Apr 14, 2016 at 01:26:51PM +1000, Alexey Kardashevskiy wrote:
.../...
>>
>>Do you mean physically pull the adapter out and insert the same
>>adapter back? What's the point for the test case?
>
>
>Because this is what the patchset is for - to replace a physical device on a
>physical machin
From: Zhaoxiu Zeng
When I do "grep parity -r linux", I found many parity calculations
distributed in many drivers.
This patch series does:
1. provide generic and architecture-specific parity calculations
2. remove drivers' local parity calculations, use bitops' parity
functions instead
On Wed, 13 Apr 2016 21:39 -0300
Thiago Jung Bauermann wrote:
> People seem to be considering patches for next, so this looks like a good
> moment to ping about this one.
Your timing is fine with respect to the merge window. I'm currently
traveling, but I'll get to it on Monday. I have it marke
On 04/14/2016 11:30 AM, Gavin Shan wrote:
On Thu, Apr 14, 2016 at 09:57:32AM +1000, Alistair Popple wrote:
Hi Gavin,
Why exactly cannot EEH reset changes go to a smaller separate patchset
(before hotplug)?
As I explained before, the patchset's order is: PCI generic part,
PowerNV PCI relat
On 04/14/2016 09:54 AM, Gavin Shan wrote:
On Wed, Apr 13, 2016 at 06:29:42PM +1000, Alexey Kardashevskiy wrote:
On 02/17/2016 02:43 PM, Gavin Shan wrote:
Currently, there is one macro (TCE32_TABLE_SIZE) representing the
TCE table size for one DMA32 segment. The constant representing
the DMA32 s
On 04/14/2016 09:42 AM, Gavin Shan wrote:
On Wed, Apr 13, 2016 at 07:14:59PM +1000, Alexey Kardashevskiy wrote:
On 04/13/2016 05:42 PM, Gavin Shan wrote:
On Wed, Apr 13, 2016 at 05:28:15PM +1000, Alexey Kardashevskiy wrote:
On 02/17/2016 02:43 PM, Gavin Shan wrote:
This series of patches reba
From: Zhaoxiu Zeng
Use runtime patching for ppc64, lifted from hweight_64
Signed-off-by: Zhaoxiu Zeng
---
arch/powerpc/include/asm/bitops.h | 11 +++
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/parity_64.S | 142 ++
arch/powerpc/lib/pp
From: Zhaoxiu Zeng
When I do "grep parity -r linux", I found many parity calculations
distributed in many drivers.
This patch series does:
1. provide generic and architecture-specific parity calculations
2. remove drivers' local parity calculations, use bitops' parity
functions instead
On 13-04-16, 23:27, Akshay Adiga wrote:
> On 04/13/2016 10:33 AM, Viresh Kumar wrote:
> >>+void gpstate_timer_handler(unsigned long data)
> >>+{
> >>+ struct cpufreq_policy *policy = (struct cpufreq_policy *) data;
> >no need to cast.
>
> May be i need a cast here, because data is unsigned long
On Fri, Apr 08, 2016 at 04:36:43PM +1000, Alexey Kardashevskiy wrote:
> IBM PPC IOMMU API users always set IOMMU data and IOMMU release callback
> to an IOMMU group. At the moment the callback clears one pointer in
> iommu_table_group and that's it.
>
> The platform code calls iommu_group_put() an
On Fri, Apr 08, 2016 at 04:36:44PM +1000, Alexey Kardashevskiy wrote:
> When SRIOV is disabled, the existing code presumes there is no
> virtual function (VF) in use and destroys all associated PEs.
> However it is possible to get into the situation when the user
> activated SRIOV disabling while a
On Thu, Apr 14, 2016 at 09:57:32AM +1000, Alistair Popple wrote:
>Hi Gavin,
>
>
>
>> >Why exactly cannot EEH reset changes go to a smaller separate patchset
>> >(before hotplug)?
>> >
>>
>> As I explained before, the patchset's order is: PCI generic part,
>> PowerNV PCI related, EEH related, devic
On 12/04/16 19:10, Naveen N. Rao wrote:
> This patchset fixes three issues found with perf probe on ppc64le:
> 1. 'perf test kallsyms' failure on ppc64le (reported by Michael
> Ellerman). This was due to the symbols being fixed up during symbol
> table load. This is fixed in patch 2 by delaying s
Hello,
People seem to be considering patches for next, so this looks like a good
moment to ping about this one.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
Am Donnerstag, 31 März 2016, 17:10:40 schrieb Thiago Jung Bauermann:
> Fixes the following testsuite failure:
>
> $ sud
Hello,
Am Freitag, 01 April 2016, 18:28:06 schrieb Thiago Jung Bauermann:
> Am Samstag, 02 April 2016, 03:51:21 schrieb kbuild test robot:
> > >> arch/powerpc/include/asm/ftrace.h:62:5: error: "CONFIG_PPC64" is not
> > >> defined [-Werror=undef]
> > >>
> > #if CONFIG_PPC64 && (!defined(_CALL_
Hi Gavin,
> >Why exactly cannot EEH reset changes go to a smaller separate patchset
> >(before hotplug)?
> >
>
> As I explained before, the patchset's order is: PCI generic part,
> PowerNV PCI related, EEH related, device-tree part and hotplug driver.
>
> The EEH reset change is included in PA
On Wed, Apr 13, 2016 at 06:29:42PM +1000, Alexey Kardashevskiy wrote:
>On 02/17/2016 02:43 PM, Gavin Shan wrote:
>>Currently, there is one macro (TCE32_TABLE_SIZE) representing the
>>TCE table size for one DMA32 segment. The constant representing
>>the DMA32 segment size (1 << 28) is still used in
On Wed, 2016-04-13 at 12:52 -0500, Jack Miller wrote:
> Hi Anton.
>
> On Wed, Apr 13, 2016 at 5:51 AM, Anton Blanchard wrote:
> > Hi Jack,
> >
> > > Previously we just saved the FSCR, but only restored it in some
> > > settings, and never copied it thread to thread. This patch always
> > > re
On Wed, Apr 13, 2016 at 07:14:59PM +1000, Alexey Kardashevskiy wrote:
>On 04/13/2016 05:42 PM, Gavin Shan wrote:
>>On Wed, Apr 13, 2016 at 05:28:15PM +1000, Alexey Kardashevskiy wrote:
>>>On 02/17/2016 02:43 PM, Gavin Shan wrote:
This series of patches rebases on powerpc/next branch, plus below
Hi Anton.
On Wed, Apr 13, 2016 at 5:51 AM, Anton Blanchard wrote:
> Hi Jack,
>
>> Previously we just saved the FSCR, but only restored it in some
>> settings, and never copied it thread to thread. This patch always
>> restores the FSCR and formalizes new threads inheriting its setting so
>> that
Thanks, yeah, that's more readable and more correct. I'll change it in
the next spin.
- Jack
On Tue, Apr 12, 2016 at 12:40 AM, Segher Boessenkool
wrote:
> Hi,
>
> On Mon, Apr 11, 2016 at 01:57:44PM -0500, Jack Miller wrote:
>> __init_FSCR:
>> mfspr r3,SPRN_FSCR
>> + andi. r3,r3,(~
On 04/13/2016 07:15 AM, Pan Xinhui wrote:
Hello Peter,
On 2016年04月12日 22:30, Peter Zijlstra wrote:
I am working on the qspinlock implementation on PPC.
Your and Waiman's patches are so nice. :)
Thanks!, last time I looked at PPC spinlocks they could not use things
like ticket locks because PP
+++ Miroslav Benes [13/04/16 15:01 +0200]:
On Wed, 13 Apr 2016, Michael Ellerman wrote:
This series adds live patching support for powerpc (ppc64le only ATM).
It's unchanged since the version I posted on March 24, with the exception that
I've dropped the first patch, which was a testing-only p
Hi Viresh ,
Thanks for reviewing in detail.
I will correct all comments related to coding standards in my next patch.
On 04/13/2016 10:33 AM, Viresh Kumar wrote:
Comments mostly on the coding standards which you have *not* followed.
Also, please run checkpatch --strict next time you send patc
On Tue, Apr 12, 2016 at 11:05:06AM +1000, Suraj Jitindar Singh wrote:
> Add a binding to Documentation/devicetree/bindings/powerpc/opal
> (oppanel-opal.txt) for the operator panel which is present on IBM
> pseries machines with FSPs.
>
> Signed-off-by: Suraj Jitindar Singh
> ---
> .../devicetree
On Fri, 2015-06-11 at 10:05:46 UTC, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 6 Nov 2015 11:00:23 +0100
>
> The kfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using
On Wed, 2016-06-01 at 00:45:50 UTC, Daniel Axtens wrote:
> As sparse suggests, these should be made static.
>
> Signed-off-by: Daniel Axtens
> Reviewed-by: Andrew Donnellan
> Reviewed-by: Stewart Smith
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/635218c785bef355bc
On Sun, 2016-10-04 at 19:53:47 UTC, Aaro Koskinen wrote:
> Limit idle ticks to total ticks. This prevents the annoying rackmeter
> leds fully ON / OFF blinking state that happens on fully idling
> G5 Xserve systems.
>
> Signed-off-by: Aaro Koskinen
Series applied to powerpc next, thanks.
https:
On Wed, 13 Apr 2016, Miroslav Benes wrote:
> > This series adds live patching support for powerpc (ppc64le only ATM).
> >
> > It's unchanged since the version I posted on March 24, with the exception
> > that
> > I've dropped the first patch, which was a testing-only patch.
> >
> > If there's n
On Wed, 13 Apr 2016, Michael Ellerman wrote:
> This series adds live patching support for powerpc (ppc64le only ATM).
>
> It's unchanged since the version I posted on March 24, with the exception that
> I've dropped the first patch, which was a testing-only patch.
>
> If there's no further comme
Add the kconfig logic & assembly support for handling live patched
functions. This depends on DYNAMIC_FTRACE_WITH_REGS, which in turn
depends on the new -mprofile-kernel ftrace ABI, which is only supported
currently on ppc64le.
Live patching is handled by a special ftrace handler. This means it ru
In order to support live patching we need to maintain an alternate
stack of TOC & LR values. We use the base of the stack for this, and
store the "live patch stack pointer" in struct thread_info.
Unlike the other fields of thread_info, we can not statically initialise
that value, so it must be don
Add the powerpc specific livepatch definitions. In particular we provide
a non-default implementation of klp_get_ftrace_location().
This is required because the location of the mcount call is not constant
when using -mprofile-kernel (which we always do for live patching).
Signed-off-by: Torsten D
When livepatch tries to patch a function it takes the function address
and asks ftrace to install the livepatch handler at that location.
ftrace will look for an mcount call site at that exact address.
On powerpc the mcount location is not the first instruction of the
function, and in fact it's no
In order to support live patching on powerpc we would like to call
ftrace_location_range(), so make it global.
Signed-off-by: Torsten Duwe
Signed-off-by: Balbir Singh
Signed-off-by: Michael Ellerman
---
include/linux/ftrace.h | 1 +
kernel/trace/ftrace.c | 14 +-
2 files changed,
This series adds live patching support for powerpc (ppc64le only ATM).
It's unchanged since the version I posted on March 24, with the exception that
I've dropped the first patch, which was a testing-only patch.
If there's no further comments I'll put this in a topic branch in the next day
or two
On Wed, 13 Apr 2016 11:48:05 +0200
Rafał Miłecki wrote:
> It also contains some minor related changes:
> 1) Don't warn if kzalloc fails as it dumps stack on its own
> 2) Use %pR format for displaying whole resource to avoid:
> warning: format ‘%08llx’ expects type ‘long long unsigned int’, but ar
From: Paul Mackerras
xmon has commands for reading and writing SPRs, but they don't work
currently for several reasons. They attempt to synthesize a small
function containing an mfspr or mtspr instruction and call it. However,
the instructions are on the stack, which is usually not executable.
Al
* Michael Ellerman wrote:
> On Wed, 2016-04-13 at 09:43 +0200, Ingo Molnar wrote:
> > * Srikar Dronamraju wrote:
> >
> > > * Anton Blanchard [2016-04-06 21:59:50]:
> > >
> > > > Looks good, and the patch below does fix the oops for me.
> > > >
> > > > Anton
> > > > --
> > > >
> > > > task_
Hello Peter,
On 2016年04月12日 22:30, Peter Zijlstra wrote:
> On Sun, Apr 10, 2016 at 10:17:28PM +0800, Pan Xinhui wrote:
>>
>> On 2016年04月08日 15:47, Peter Zijlstra wrote:
>>> On Fri, Apr 08, 2016 at 02:41:46PM +0800, Pan Xinhui wrote:
From: pan xinhui
Implement xchg{u8,u16}{local,rel
On 04/11/2016 07:21 PM, Balbir Singh wrote:
>
>
> On 07/04/16 15:37, Anshuman Khandual wrote:
>> Currently the function 'huge_pte_alloc' has got two versions, one for the
>> BOOK3S server and the other one for the BOOK3E embedded platforms. This
>> change splits only the BOOK3S server version int
On Wed, 2016-04-13 at 09:43 +0200, Ingo Molnar wrote:
> * Srikar Dronamraju wrote:
>
> > * Anton Blanchard [2016-04-06 21:59:50]:
> >
> > > Looks good, and the patch below does fix the oops for me.
> > >
> > > Anton
> > > --
> > >
> > > task_pt_regs() can return NULL for kernel threads, so ad
Hi Jack,
> Previously we just saved the FSCR, but only restored it in some
> settings, and never copied it thread to thread. This patch always
> restores the FSCR and formalizes new threads inheriting its setting so
> that later we can manipulate FSCR bits in start_thread.
Will this break the exi
On 04/13/2016 05:53 PM, Gavin Shan wrote:
On Wed, Apr 13, 2016 at 04:21:07PM +1000, Alexey Kardashevskiy wrote:
On 02/17/2016 02:43 PM, Gavin Shan wrote:
There are two arrays for IO and M32 segment maps on every PHB.
The index of the arrays are segment number and the value stored
in the corresp
It also contains some minor related changes:
1) Don't warn if kzalloc fails as it dumps stack on its own
2) Use %pR format for displaying whole resource to avoid:
warning: format ‘%08llx’ expects type ‘long long unsigned int’, but argument 2
has type ‘resource_size_t’
Signed-off-by: Rafał Miłecki
On 04/13/2016 05:42 PM, Gavin Shan wrote:
On Wed, Apr 13, 2016 at 05:28:15PM +1000, Alexey Kardashevskiy wrote:
On 02/17/2016 02:43 PM, Gavin Shan wrote:
This series of patches rebases on powerpc/next branch, plus below additional
patches:
https://patchwork.ozlabs.org/patch/58131
On 02/17/2016 02:43 PM, Gavin Shan wrote:
PEs are put into PHB DMA32 list (phb->ioda.pe_dma_list) according
to their DMA32 weight. The PEs on the list are iterated to setup
their TCE32 tables at system booting time. The list is used for
once and there is for keep having it.
"there is no need to
On 02/17/2016 02:43 PM, Gavin Shan wrote:
Currently, there is one macro (TCE32_TABLE_SIZE) representing the
TCE table size for one DMA32 segment. The constant representing
the DMA32 segment size (1 << 28) is still used in the code.
This defines PNV_IODA1_DMA32_SEGSIZE representing one DMA32
segm
task_pt_regs() can return NULL for kernel threads, so add a check.
This fixes an oops at boot on ppc64.
Fixes: d740037fac70 ("sched/cpuacct: Split usage accounting into user_usage and
sys_usage")
Signed-off-by: Anton Blanchard
Reported-and-Tested-by: Srikar Dronamraju
---
diff --git a/kernel/s
On Thu 07-04-16 11:07:35, Anshuman Khandual wrote:
> The commit 091d0d55b286 ("shm: fix null pointer deref when userspace
> specifies invalid hugepage size") had replaced MAP_HUGE_MASK with
> SHM_HUGE_MASK. Though both of them contain the same numeric value of
> 0x3f, MAP_HUGE_MASK flag sounds more
On Wed, Apr 13, 2016 at 04:21:07PM +1000, Alexey Kardashevskiy wrote:
>On 02/17/2016 02:43 PM, Gavin Shan wrote:
>>There are two arrays for IO and M32 segment maps on every PHB.
>>The index of the arrays are segment number and the value stored
>>in the corresponding element is PE number, indicating
On 02/17/2016 02:43 PM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can be owned by one particular PE# exclusively or divided
evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and ea
Hi,
On Sat, 9 Apr 2016 12:50:35 +0300
Andy Shevchenko wrote:
> On Fri, Apr 8, 2016 at 2:13 PM, Rafał Miłecki wrote:
> > 1) Use pr_fmt to keep messages consistent
> > 2) Don't warn if kzalloc fails as it dumps stack on its own
> > 3) Use %pR format for displaying whole resource to avoid:
> > war
* Srikar Dronamraju wrote:
> * Anton Blanchard [2016-04-06 21:59:50]:
>
> > Looks good, and the patch below does fix the oops for me.
> >
> > Anton
> > --
> >
> > task_pt_regs() can return NULL for kernel threads, so add a check.
> > This fixes an oops at boot on ppc64.
> >
> > Signed-off-b
On Wed, Apr 13, 2016 at 05:28:15PM +1000, Alexey Kardashevskiy wrote:
>On 02/17/2016 02:43 PM, Gavin Shan wrote:
>>This series of patches rebases on powerpc/next branch, plus below additional
>>patches:
>>
>>
>>
>>https://patchwork.ozlabs.org/patch/581315/(PATCH[1/9] Richard's
On 02/17/2016 02:43 PM, Gavin Shan wrote:
This renames pnv_pci_ioda_setup_dma_pe() to pnv_pci_ioda1_setup_dma_pe()
as it's the counter-part of IODA2's pnv_pci_ioda2_setup_dma_pe().
No logical changes introduced.
Signed-off-by: Gavin Shan
Reviewed-by: Alexey Kardashevskiy
---
arch/powe
On 02/17/2016 02:43 PM, Gavin Shan wrote:
This series of patches rebases on powerpc/next branch, plus below additional
patches:
https://patchwork.ozlabs.org/patch/581315/ (PATCH[1/9] Richard's SRIOV EEH)
https://patchwork.ozlabs.org/patch/582639/ (PATCH[1/1] Gavin's EEH fix)
On 02/17/2016 02:43 PM, Gavin Shan wrote:
This renames those functions picking PE number based on consumed
M64 segments, mapping M64 segments to PEs as those functions are
going to be shared by IODA1/IODA2 in next patch. No logical changes
introduced.
Signed-off-by: Gavin Shan
Reviewed-by: A
On 02/17/2016 02:43 PM, Gavin Shan wrote:
When unplugging PCI devices, their parent PEs might be offline.
The consumed M64 resource by the PEs should be released at that
time. As we track M32 segment consumption, this introduces an
array to the PHB to track the mapping between M64 segment and
PE
63 matches
Mail list logo