On Thu, 1970-01-01 at 00:00 +, Madalin-cristian Bucur wrote:
>
> > -Original Message-
> > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > Sent: Tuesday, January 16, 2018 7:58 PM
> > To: and...@lunn.ch
> > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
Christophe Leroy writes:
> In preparation for the following patch which will fix an issue on
> the 8xx by re-using the 'slices', this patch enhances the
> 'slices' implementation to support 32 bits CPUs.
>
> On PPC32, the address space is limited to 4Gbytes, hence only the low
> slices will be us
Christophe Leroy writes:
> On the 8xx, the page size is set in the PMD entry and applies to
> all pages of the page table pointed by the said PMD entry.
>
> When an app has some regular pages allocated (e.g. see below) and tries
> to mmap() a huge page at a hint address covered by the same PMD en
Christophe Leroy writes:
> While the implementation of the "slices" address space allows
> a significant amount of high slices, it limits the number of
> low slices to 16 due to the use of a single u64 low_slices_psize
> element in struct mm_context_t
>
> On the 8xx, the minimum slice size is the
Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch enhances the
'slices' implementation to support 32 bits CPUs.
On PPC32, the address space is limited to 4
Le 19/01/2018 à 09:26, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
On the 8xx, the page size is set in the PMD entry and applies to
all pages of the page table pointed by the said PMD entry.
When an app has some regular pages allocated (e.g. see below) and tries
to mmap() a huge pag
The recent changes to TLB handling broke the PS3 build:
arch/powerpc/include/asm/book3s/64/tlbflush.h:30: undefined reference to
`.hash__tlbiel_all'
Fix it by adding an fallback version of tlbiel_all() for non-native
builds. It should never be called, due to checks in callers so it
calls BUG()
Le 19/01/2018 à 09:30, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
While the implementation of the "slices" address space allows
a significant amount of high slices, it limits the number of
low slices to 16 due to the use of a single u64 low_slices_psize
element in struct mm_context_
On 01/19/2018 02:14 PM, Christophe LEROY wrote:
Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch enhances the
'slices' implementation to support 32 bits
On 01/19/2018 02:29 PM, Christophe LEROY wrote:
Le 19/01/2018 à 09:30, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
While the implementation of the "slices" address space allows
a significant amount of high slices, it limits the number of
low slices to 16 due to the use of a single
Le 19/01/2018 à 10:02, Aneesh Kumar K.V a écrit :
On 01/19/2018 02:14 PM, Christophe LEROY wrote:
Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch en
On 01/19/2018 02:37 PM, Christophe LEROY wrote:
Le 19/01/2018 à 10:02, Aneesh Kumar K.V a écrit :
On 01/19/2018 02:14 PM, Christophe LEROY wrote:
Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
In preparation for the following patch which will fix an issue
Le 19/01/2018 à 10:13, Aneesh Kumar K.V a écrit :
On 01/19/2018 02:37 PM, Christophe LEROY wrote:
Le 19/01/2018 à 10:02, Aneesh Kumar K.V a écrit :
On 01/19/2018 02:14 PM, Christophe LEROY wrote:
Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
In prepar
Did a reply instead of reply-all.
Aneesh Kumar K.V writes:
> Christophe LEROY writes:
>
>> Le 17/01/2018 à 04:19, Aneesh Kumar K.V a écrit :
>>>
>>>
>>> On 01/16/2018 10:18 PM, Christophe LEROY wrote:
Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit :
> Christophe Leroy wr
On 15/01/2018 14:39, Philippe Bergheaud wrote:
> Configure the P9 XSL_DSNCTL register with PHB indications found
> in the device tree, or else use legacy hard-coded values.
>
> Signed-off-by: Philippe Bergheaud
> ---
> Changelog:
>
> v2: New patch. Use the new device tree property "ibm,phb-indic
Bjorn Helgaas writes:
> On Thu, Jan 04, 2018 at 03:12:12PM -0600, Rob Herring wrote:
>> Most subsystem specific functions have been moved into the respective
>> subsystems. Only PCI and networking remain. This series moves most of the
>> PCI related code to drivers/pci/of.c. Some bus address func
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
> arch/powerpc/kernel/setup-common.c
>
> between commit:
>
> 349524bc0da6 ("powerpc: Don't preempt_disable() in show_cpuinfo()")
>
> from the powerpc-fixes tree and commit:
>
> f5f563012
Ananth N Mavinakayanahalli writes:
> On Wed, Jan 17, 2018 at 05:52:24PM +0530, Naveen N. Rao wrote:
>> Michael Ellerman reported the following call trace when running
>> ftracetest:
>>
>> BUG: using __this_cpu_write() in preemptible [] code: ftracetest/6178
>> caller is opt_pre_handler+0
Hi Linus,
Please pull some more powerpc fixes for 4.15:
The following changes since commit 6e032b350cd1fdb830f18f8320ef0e13b4e24094:
powerpc/powernv: Check device-tree for RFI flush settings (2018-01-10
21:27:16 +1100)
are available in the Git repository at:
https://git.kernel.org/pub/scm
Michael Ellerman wrote:
Ananth N Mavinakayanahalli writes:
On Wed, Jan 17, 2018 at 05:52:24PM +0530, Naveen N. Rao wrote:
Michael Ellerman reported the following call trace when running
ftracetest:
BUG: using __this_cpu_write() in preemptible [] code: ftracetest/6178
caller is opt_pr
> > commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> > Author: Florian Fainelli
> > Date: Tue Aug 22 15:24:47 2017 -0700
> > fsl/man: Inherit parent device and of_node
> >
> > and was later addressed by this patch set:
> >
> > http://patchwork.ozlabs.org/project/netdev/list/?series=8462&state=*
On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> > > commit 4d8ee1935bcd666360311dfdadeee235d682d69a
> > > Autho
Ram Pai writes:
> Currently the architecture specific code is expected to
> display the protection keys in smap for a given vma.
> This can lead to redundant code and possibly to divergent
> formats in which the key gets displayed.
>
> This patch changes the implementation. It displays
On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote:
> Ram Pai writes:
>
> > Currently the architecture specific code is expected to
> > display the protection keys in smap for a given vma.
> > This can lead to redundant code and possibly to divergent
> > formats in which th
Ram Pai writes:
> On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote:
>> Ram Pai writes:
>>
>> > Currently the architecture specific code is expected to
>> > display the protection keys in smap for a given vma.
>> > This can lead to redundant code and possibly to divergen
On Mon, Jan 15, 2018 at 04:13:59AM +0100, Jonathan Neuschäfer wrote:
> Signed-off-by: Jonathan Neuschäfer
> ---
> .../bindings/gpio/nintendo,hollywood-gpio.txt | 27
> ++
> .../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +---
> 2 files changed, 28 insertions
On Fri, Jan 19, 2018 at 05:05:21PM -0600, Rob Herring wrote:
> On Mon, Jan 15, 2018 at 04:13:59AM +0100, Jonathan Neuschäfer wrote:
> > Signed-off-by: Jonathan Neuschäfer
> > ---
> > .../bindings/gpio/nintendo,hollywood-gpio.txt | 27
> > ++
> > .../devicetree/bindings/p
On 01/18/2018 03:11 AM, Christophe Leroy wrote:
commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has the
effect of deferring timer handling in case of high CPU load, hence
delaying the delayed work allthought the worker is running which
high realtime priority.
As hrtimers are not manag
28 matches
Mail list logo
