After bc3551257a ("powerpc/64: Allow for relocation-on interrupts from
guest to host"), a getppid() system call goes from 307 cycles to 358
cycles (+17%). This is due significantly to the scratch SPR used by the
hypercall.
It turns out there are a some volatile registers common to both system
call
With OPAL msglog driver, there are two interfaces to retrieve the
firmware (skiboot) logs: /sys/firmware/opal/msglog and xmon "do"
command. The memory console header (descritpor) and output buffer
are resident in memory blocks whose addresses are greater than
0x3000. The memory blocks needn't b
On Wednesday 15 March 2017 05:53 PM, Peter Zijlstra wrote:
On Wed, Mar 15, 2017 at 05:20:15PM +1100, Michael Ellerman wrote:
I see no implementation; so why are you poking at it.
Maddy has posted an implementation of the kernel part for powerpc in
patch 2 of this series, but maybe you're not
On Wednesday 15 March 2017 11:50 AM, Michael Ellerman wrote:
Hi Peter,
Peter Zijlstra writes:
On Tue, Mar 14, 2017 at 02:31:51PM +0530, Madhavan Srinivasan wrote:
Huh? PPC hasn't yet implemented this? Then why are you fixing it?
yes, PPC hasn't implemented this (until now).
until now whe
"Andrew F. Davis" writes:
> When CONFIG_MACINTOSH_DRIVERS is not set make will still descend into the
> macintosh directory but nothing will be built. This produces unneeded
> build artifacts and messages in addition to slowing the build.
> Fix this here.
>
> Signed-off-by: Andrew F. Davis
> ---
On Wed, Mar 15, 2017 at 10:18:18AM -0600, Alex Williamson wrote:
> On Wed, 15 Mar 2017 15:40:14 +1100
> David Gibson wrote:
> > > > diff --git a/arch/powerpc/kvm/book3s_64_vio.c
> > > > b/arch/powerpc/kvm/book3s_64_vio.c
> > > > index e96a4590464c..be18cda01e1b 100644
> > > > --- a/arch/powerpc/k
Currently if we oops caused by an 0x380 or 0x480 exception, we get a
print which assumes SLB problems. With radix, these vectors have
different meanings.
This patch updates the oops message to reflect these different
meanings.
Signed-off-by: Michael Neuling
---
arch/powerpc/xmon/xmon.c | 14 +++
On 16/03/17 03:39, Alex Williamson wrote:
> On Thu, 16 Mar 2017 00:21:07 +1100
> Alexey Kardashevskiy wrote:
>
>> On 15/03/17 08:05, Alex Williamson wrote:
>>> On Fri, 10 Mar 2017 14:53:37 +1100
>>> Alexey Kardashevskiy wrote:
>>>
This allows the host kernel to handle H_PUT_TCE, H_PUT_TC
On 03/15/2017 04:03 PM, Arnd Bergmann wrote:
> On Wed, Mar 15, 2017 at 5:37 PM, Andrew F. Davis wrote:
>> Hello all,
>>
>> I was building a kernel for x86 and noticed Make still descended into
>> directories like drivers/gpu/drm/hisilicon, this seems kind of odd given
>> nothing will be built here
Hi David,
> While not part of this change, the unrolled loops look as though
> they just destroy the cpu cache.
> I'd like be convinced that anything does CRC over long enough buffers
> to make it a gain at all.
>
> With modern (not that modern now) superscalar cpus you can often
> get the loop in
On Wed, 15 Mar 2017, Rich Felker wrote:
> On Wed, Mar 15, 2017 at 12:44:47PM -0700, Till Smejkal wrote:
> > On Wed, 15 Mar 2017, Andy Lutomirski wrote:
> > > > One advantage of VAS segments is that they can be globally queried by
> > > > user programs
> > > > which means that VAS segments can be s
On Wed, Mar 15, 2017 at 12:44 PM, Till Smejkal
wrote:
> On Wed, 15 Mar 2017, Andy Lutomirski wrote:
>> > One advantage of VAS segments is that they can be globally queried by user
>> > programs
>> > which means that VAS segments can be shared by applications that not
>> > necessarily have
>> > t
On Wed, Mar 15, 2017 at 12:44:47PM -0700, Till Smejkal wrote:
> On Wed, 15 Mar 2017, Andy Lutomirski wrote:
> > > One advantage of VAS segments is that they can be globally queried by
> > > user programs
> > > which means that VAS segments can be shared by applications that not
> > > necessarily
On Wed, 15 Mar 2017, Andy Lutomirski wrote:
> > One advantage of VAS segments is that they can be globally queried by user
> > programs
> > which means that VAS segments can be shared by applications that not
> > necessarily have
> > to be related. If I am not mistaken, MAP_SHARED of pure in memo
On Wed, Mar 15, 2017 at 09:51:31AM -0700, Andy Lutomirski wrote:
> > VAS segments on the other side allow sharing of pure in memory data by
> > arbitrary related tasks without the need of a file. This becomes especially
> > interesting if one combines VAS segments with non-volatile memory since one
On Tue, Mar 14, 2017 at 9:12 AM, Till Smejkal
wrote:
> On Mon, 13 Mar 2017, Andy Lutomirski wrote:
>> On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal
>> wrote:
>> > On Mon, 13 Mar 2017, Andy Lutomirski wrote:
>> >> This sounds rather complicated. Getting TLB flushing right seems
>> >> tricky. Why
On Wed, Mar 15, 2017 at 10:15 PM, Andrew F. Davis wrote:
> On 03/15/2017 04:03 PM, Arnd Bergmann wrote:
>> On Wed, Mar 15, 2017 at 5:37 PM, Andrew F. Davis wrote:
>>> Hello all,
>>>
>>> I was building a kernel for x86 and noticed Make still descended into
>>> directories like drivers/gpu/drm/hisi
On Wed, Mar 15, 2017 at 5:37 PM, Andrew F. Davis wrote:
> Hello all,
>
> I was building a kernel for x86 and noticed Make still descended into
> directories like drivers/gpu/drm/hisilicon, this seems kind of odd given
> nothing will be built here. It looks to be due to some directories being
> inc
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 84e5b549214f2160c12318aac549de85f600c79a:
>
> Merge tag 'perf-core-for-mingo-4.11-20170306' of
> git
On Wed, Mar 15, 2017 at 01:11:19PM -0500, Reza Arbab wrote:
https://groups.google.com/forum/#!topic/golang-nuts/K5NoG8slez0
Oops.
https://groups.google.com/d/msg/golang-nuts/K5NoG8slez0/mixUse17iaMJ
--
Reza Arbab
On Wed, 2017-03-15 at 16:35 +1100, Michael Ellerman wrote:
> Arnd Bergmann writes:
>
> >
> > On Tue, Mar 14, 2017 at 11:51 AM, Michael Ellerman
> > wrote:
> > >
> > > Michael Ellerman writes:
> > >
> > > >
> > > > We'd like to eventually remove NO_IRQ on powerpc, so remove usages of
> > > >
The patch
ASoC: fsl: constify snd_soc_ops structures
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linu
On Tue, Mar 14, 2017 at 10:37:44AM +, Harshal Patil wrote:
Our guess is the ioctls in ppc64le differ than x86_64, and thats why
the code which is clearing onclr bit
([4]https://github.com/opencontainers/runc/commit/eea28f480db435dbef4a275de9776b9934818b8c#diff-5f5c07d0cab3ce2086437d3d43c0d25
When CONFIG_MACINTOSH_DRIVERS is not set make will still descend into the
macintosh directory but nothing will be built. This produces unneeded
build artifacts and messages in addition to slowing the build.
Fix this here.
Signed-off-by: Andrew F. Davis
---
drivers/Makefile | 2 +-
1 file changed
When CONFIG_LGUEST is not set make will still descend into the lguest
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(
Hello all,
I was building a kernel for x86 and noticed Make still descended into
directories like drivers/gpu/drm/hisilicon, this seems kind of odd given
nothing will be built here. It looks to be due to some directories being
included in obj-y unconditionally instead of only when the relevant
CON
When CONFIG_MMC is not set make will still descend into the mmc
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1
When CONFIG_NFC is not set make will still descend into the nfc
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis
---
drivers/Makefile | 6 +-
1 file changed, 5 insertions(+
When CONFIG_ARM_AMBA is not set make will still descend into the amba
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(
When CONFIG_PWM is not set make will still descend into the pwm
directory but nothing will be built. This produces unneeded build
artifacts and messages in addition to slowing the build. Fix this here.
Signed-off-by: Andrew F. Davis
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1
When CONFIG_AUXDISPLAY is not set make will still descend into the
auxdisplay directory but nothing will be built. This produces unneeded
build artifacts and messages in addition to slowing the build.
Fix this here.
Signed-off-by: Andrew F. Davis
---
drivers/Makefile | 2 +-
1 file changed, 1 in
On Thu, 16 Mar 2017 00:21:07 +1100
Alexey Kardashevskiy wrote:
> On 15/03/17 08:05, Alex Williamson wrote:
> > On Fri, 10 Mar 2017 14:53:37 +1100
> > Alexey Kardashevskiy wrote:
> >
> >> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
> >> and H_STUFF_TCE requests targeted
On Wed, 15 Mar 2017 15:40:14 +1100
David Gibson wrote:
> > > diff --git a/arch/powerpc/kvm/book3s_64_vio.c
> > > b/arch/powerpc/kvm/book3s_64_vio.c
> > > index e96a4590464c..be18cda01e1b 100644
> > > --- a/arch/powerpc/kvm/book3s_64_vio.c
> > > +++ b/arch/powerpc/kvm/book3s_64_vio.c
> > > @@ -28,
From: Linuxppc-dev Daniel Axtens
> Sent: 15 March 2017 12:38
> The core nuts and bolts of the crc32c vpmsum algorithm will
> also work for a number of other CRC algorithms with different
> polynomials. Factor out the function into a new asm file.
>
> To handle multiple users of the function, a use
Hi,
I would like to start using a dedicated stack for system reset interrupt
and treat it as a Linux nmi, which makes it tricky to call complex
interrupt handlers directly from the system reset trap handler.
So I would like to remove the decrementer and external handler calls from
Cell and Pasemi
On Tue, Mar 14, 2017 at 11:37 AM, Harshal Patil
wrote:
> Hello,
>
> I am looking into a bug,
> https://bugzilla.linux.ibm.com/show_bug.cgi?id=152493 ( external mirror is
> at, https://github.com/opencontainers/runc/issues/1364)
>
> Recently in runc code, they added this code
> https://github.com/o
On 2017/03/15 09:11AM, Steven Rostedt wrote:
> On Wed, 15 Mar 2017 14:35:16 +0530
> "Naveen N. Rao" wrote:
>
> > I don't have a strong opinion about this, but I feel that x86 can simply
> > use ftrace_64.S, seeing as the current name is mcount_64.S.
> >
> > Other architectures could do somethin
On 15/03/17 08:05, Alex Williamson wrote:
> On Fri, 10 Mar 2017 14:53:37 +1100
> Alexey Kardashevskiy wrote:
>
>> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
>> and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO
>> without passing them to user space which s
On Wed, 15 Mar 2017 14:35:16 +0530
"Naveen N. Rao" wrote:
> I don't have a strong opinion about this, but I feel that x86 can simply
> use ftrace_64.S, seeing as the current name is mcount_64.S.
>
> Other architectures could do something similar too, or fall back to
> ftrace_hook.S. That way,
The core nuts and bolts of the crc32c vpmsum algorithm will
also work for a number of other CRC algorithms with different
polynomials. Factor out the function into a new asm file.
To handle multiple users of the function, a user simply
provides constants, defines the name of their CRC function,
an
vpmsum implementations often don't kick in for short test vectors.
This is a simple test module that does a configurable number of
random tests, each up to 64kB and each with random offsets.
Both CRC-T10DIF and CRC32C are tested.
Cc: Anton Blanchard
Signed-off-by: Daniel Axtens
--
Not super f
T10DIF is a CRC16 used heavily in NVMe.
It turns out we can accelerate it with a CRC32 library and a few
little tricks.
Provide the accelerator based the refactored CRC32 code.
Cc: Anton Blanchard
Thanks-to: Hong Bo Peng
Signed-off-by: Daniel Axtens
---
arch/powerpc/crypto/Makefile
When CRC32c was included in the kernel, Anton ripped out
the #ifdefs around reflected polynomials, because CRC32c
is always reflected. However, not all CRCs use reflection
so we'd like to make it optional.
Restore the REFLECT parts from Anton's original CRC32
implementation (https://github.com/ant
On Wed, Mar 15, 2017 at 05:20:15PM +1100, Michael Ellerman wrote:
> > I see no implementation; so why are you poking at it.
>
> Maddy has posted an implementation of the kernel part for powerpc in
> patch 2 of this series, but maybe you're not on Cc?
I am not indeed. That and a completely inadeq
On Wed, Mar 15, 2017 at 6:35 AM, Michael Ellerman wrote:
> Arnd Bergmann writes:
>> On Tue, Mar 14, 2017 at 11:51 AM, Michael Ellerman
>> wrote:
>>> Michael Ellerman writes:
>>>
>>
>> drivers/ata/pata_mpc52xx.c: if (ata_irq == NO_IRQ) {
>> drivers/ata/sata_dwc_460ex.c:#ifndef NO_IRQ
>> dri
Oliver O'Halloran writes:
> Currently the code to perform an OPAL call is duplicated between the
> normal path and path taken when tracepoints are enabled. There's no
> real need for this and combining them makes opal_tracepoint_entry
> considerably easier to understand.
Sorry I missed this when
Balbir Singh writes:
> On 02/03/17 11:49, Oliver O'Halloran wrote:
>> In previous generations of Power processors each core had a private L2
>> cache. The Power9 processor has a slightly different architecture where
>> the L2 cache is shared among pairs of cores rather than being completely
>> pr
Oliver O'Halloran writes:
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 5571f30ff72d..5e1811b24415 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -724,10 +724,17 @@ static void update_cpu_masks(int cpu, bool onlining)
>
> upd
Oliver O'Halloran writes:
> Traditionally we have only ever tracked which CPUs are in the same core
> (cpu_sibling_mask) and on the same die (cpu_core_mask). For Power9 we
> need to be aware of which CPUs share cache with each other so this patch
> adds cpu_cache_mask and the underlying cpu_cache
Oliver O'Halloran writes:
> When adding and removing a CPU from the system the per-cpu masks that
> are used by the scheduler to construct scheduler domains need to be updated
> to account for the cpu entering or exiting the system. Currently logic this
> is open-coded for the thread sibling mask
Oliver O'Halloran writes:
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index dfe0e1d9cd06..1c531887ca51 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -377,6 +377,25 @@ static void smp_store_cpu_info(int id)
> #endif
> }
>
> +/*
> + *
Oliver O'Halloran writes:
> To determine which logical CPUs are on the same core the kernel uses the
> ibm,chipid property from the device tree node associated with that cpu.
> The lookup for this this information is currently open coded in both
> traverse_siblings() and traverse_siblings_chip_id
Hi Nick,
Thanks for reviewing the patch.
On Wed, Mar 15, 2017 at 12:05:43AM +1000, Nicholas Piggin wrote:
> On Mon, 13 Mar 2017 11:31:27 +0530
> "Gautham R. Shenoy" wrote:
>
> > From: "Gautham R. Shenoy"
> >
> > Currently during idle-init on power9, if we don't find suitable stop
> > states i
>> So you suggest that adding of_node_get() to __of_attach_node_sysfs()
>> is the right fix ?
>
> If I understand that this only creates for hot-added cpus then no. Also
> for this to be the correct fix I would expect to see this recreate for
> all hot-remove operations such as memory and pci dev
Hi Michael,
On Wed, Mar 15, 2017 at 10:30 AM, Michael Ellerman wrote:
> Geert Uytterhoeven writes:
>> On Wed, Mar 15, 2017 at 1:19 AM, Michael Ellerman
>> wrote:
>>> Geert Uytterhoeven writes:
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer
Geert Uytterhoeven writes:
> On Wed, Mar 15, 2017 at 1:19 AM, Michael Ellerman wrote:
>> Geert Uytterhoeven writes:
>>> Submitters of device tree binding documentation may forget to CC
>>> the subsystem maintainer if this is missing.
>>>
>>> Signed-off-by: Geert Uytterhoeven
>>> Cc: Benjamin He
On 2017/03/14 10:18AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Mar 09, 2017 at 05:37:38PM +1100, Michael Ellerman escreveu:
> > "Naveen N. Rao" writes:
> > > On 2017/03/08 11:29AM, Arnaldo Carvalho de Melo wrote:
> > >> > I wasn't sure if you were planning on picking up KPROBES_ON_FTRACE for
>
On 2017/03/10 11:54AM, Steven Rostedt wrote:
> On Fri, 10 Mar 2017 21:38:53 +0530
> "Naveen N. Rao" wrote:
>
> > On 2017/03/10 10:45AM, Steven Rostedt wrote:
> > > On Thu, 02 Mar 2017 20:38:53 +1100
> > > Michael Ellerman wrote:
>
> > > > So if we drop that we're left with ftrace.S - which seem
Balbir Singh writes:
> Introduce a helper pgtable_get_gfp_flags() which
Can we just call it pgtable_gfp_flags() ?
> just returns the current gfp flags. In a future
> patch, we can enable __GFP_ACCOUNT based on the
> calling context.
>
> Signed-off-by: Balbir Singh
> ---
> arch/powerpc/include
From: "Gautham R. Shenoy"
The various properties associated with powernv idle states such as
names, flags, residency-ns, latencies-ns, psscr, psscr-mask are
exposed in the device-tree as property arrays such the pointwise
entries in each of these arrays correspond to the properties of the
same id
Hi Michael,
On Wed, Mar 15, 2017 at 1:19 AM, Michael Ellerman wrote:
> Geert Uytterhoeven writes:
>> Submitters of device tree binding documentation may forget to CC
>> the subsystem maintainer if this is missing.
>>
>> Signed-off-by: Geert Uytterhoeven
>> Cc: Benjamin Herrenschmidt
>> Cc: Pau
61 matches
Mail list logo
