On Tue, Aug 28, 2018 at 4:56 AM Rob Herring wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
> + if (snprintf(node_name, sizeof(node_name), "%pOFn", np) != 5)
> return 0;
> + i
On Tue, Aug 28, 2018 at 4:57 AM Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
> + snprintf((char *)dai->platform_name, DAI_NAME_SIZE, "%llx.%pOFn",
> +(unsigned long lon
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/tlb-radix.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/mm/tlb-radix.c b/arch/powerpc/mm/tlb-radix.c
index c867999ce722..ad1db9967220 100644
--- a/arch/powerpc/mm/tlb-radix.c
+++ b/arch/powerpc/mm/tlb-radix.c
@@ -1018,7 +1018,
On Mon, Aug 27, 2018 at 08:52:44PM -0500, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Qiang Zhao
> Cc: Li Yang
> Cc: Andy Gross
> Cc: David Brown
> Cc: Heiko Stuebner
> Cc: Thier
Here are some patches that didn't get much comment last time. It
looks like x86 might benefit too though, so that might get people
interested.
I improved changelogs and added some comments, but no real logic
changes.
I hope I didn't get the x86 numbers wrong, they're more significant
than I expe
This is the THP equivalent for 1b2de5d039c8 ("mm/cow: don't bother write
protecting already write-protected pages").
Explicit hugetlb pages don't get the same treatment because they don't
appear to have the right accessor functions.
Signed-off-by: Nicholas Piggin
---
mm/huge_memory.c | 14 +
fork clears dirty/accessed bits from new ptes in the child. This logic
has existed since mapped page reclaim was done by scanning ptes when
it may have been quite important. Today with physical based pte
scanning, there is less reason to clear these bits. Dirty bits are all
tested and cleared toget
Similarly to the previous patch, this tries to optimise dirty/accessed
bits in ptes to avoid access costs of hardware setting them.
Signed-off-by: Nicholas Piggin
---
mm/huge_memory.c | 12 +++-
mm/memory.c | 8 +---
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git
Hello!
I have a 83xx platform and I am using non tsa mode in the fsl hdlc driver to
enable ethernet over hdlc. These patches are the minimal changes that I needed
to do in order to get it to work with our legacy products that used old FSL SDK
driver. Please review.
Best Regards,
David Gounaris
The following bits in the GUMR is changed for non
tsa mode: CDS, CTSP and CTSS are set to zero.
When set, there is no tx interrupts from the controller.
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wan/fs
Set default HMASK to 0x to use
promiscuous mode in the hdlc controller.
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.h b/drivers/net/wan/fsl_ucc_hdlc.h
index c21134c1f180..5bc
This was done to avoid discarding ethernet
packets when using HDLC_ETH protocol.
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 963b3b5ae15e..54e2b214
There is a need to allow higher indexes to be
able to support MPC83xx platforms. (UCC1-UCC5)
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 3c0e0a1d19ba..963b3b5ae15e 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan
Added tx timerout handler. This helps
when troubleshooting.
Signed-off-by: David Gounaris
---
drivers/net/wan/fsl_ucc_hdlc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index e6154a6547e6..30f416bace2c 100644
--- a/driv
Reimplement Book3S idle code in C, moving POWER7/8/9 implementation
speific HV idle code to the powernv platform code.
Book3S assembly stubs are kept in common code and used only to save
the stack frame and non-volatile GPRs before executing architected
idle instructions, and restoring the stack a
Le 28/08/2018 à 13:09, David Gounaris a écrit :
There is a need to allow higher indexes to be
able to support MPC83xx platforms. (UCC1-UCC5)
As far as I can see, MPC8358 has 8 UCCs (ref
https://www.nxp.com/products/processors-and-microcontrollers/power-architecture-processors/powerquicc-pro
Le 28/08/2018 à 13:09, David Gounaris a écrit :
This was done to avoid discarding ethernet
packets when using HDLC_ETH protocol.
Maybe use 'present' form instead of 'past form', ie 'This patch is to
avoid discarding ethernet ...'
Christophe
Signed-off-by: David Gounaris
---
drivers/
Hello Andreas, Nick,
On 28 August 2018 at 06:06, Nicholas Piggin wrote:
> On Mon, 27 Aug 2018 19:11:01 +0200
> Andreas Schwab wrote:
>
>> I'm getting this Oops when running iptables -F OUTPUT:
>>
>> [ 91.139409] Unable to handle kernel paging request for data at address
>> 0xd001fff12f34
This is a note to let you know that I've just added the patch titled
usb/phy: fix PPC64 build errors in phy-fsl-usb.c
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-p
This is a note to let you know that I've just added the patch titled
usb/phy: fix PPC64 build errors in phy-fsl-usb.c
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-ph
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Carlo Caione
Cc: Kevin H
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Johannes Berg
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: linuxppc-dev@lists.ozlabs.org
Cc: alsa-de...@alsa-project.org
Signed-off-by: Rob Herring
---
v2:
- Fix erro
On 28 August 2018 at 15:56, Ard Biesheuvel wrote:
> Hello Andreas, Nick,
>
> On 28 August 2018 at 06:06, Nicholas Piggin wrote:
>> On Mon, 27 Aug 2018 19:11:01 +0200
>> Andreas Schwab wrote:
>>
>>> I'm getting this Oops when running iptables -F OUTPUT:
>>>
>>> [ 91.139409] Unable to handle ker
These are a few bits and pieces I collected I'll get out of the
way ahead of the SLB rewrite in C patch and subsequent improvements.
Nicholas Piggin (3):
powerpc/64s/hash: Fix stab_rr off by one initialization
powerpc/64s/hash: Use POWER9 SLBIA IH=3 variant in switch_mm
powerpc/64s/hash: avo
This causes SLB alloation to start 1 beyond the start of the SLB.
There is no real problem because after it wraps it stats behaving
properly, it's just surprisig to see when looking at SLB traces.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/slb.c | 2 +-
1 file changed, 1 insertion(+), 1
POWER9 introduces SLBIA IH=3, which invalidates all SLB entries
and associated lookaside information that have a class value of
1, which Linux assigns to user addresses. This matches what
switch_slb wants, and allows a simple fast implementation that
avoids the slb_cache complexity.
As a side-effe
I only have POWER8/9 to test, so just remove it for those.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/entry_64.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2206912ea4f0..77a888bfcb53 100644
--- a/arch/po
On Aug 28 2018, Ard Biesheuvel wrote:
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 6a501b25dd85..57d09d5ceb1a 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -779,7 +779,6 @@ EXPORT_SYMBOL(__per_cpu_offset);
>
>
On Tue, Aug 28, 2018 at 10:44:28AM -0500, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
Please don't send new patches in reply to existing threads, it makes it
harder to follow what the current
On Mon, Aug 27, 2018 at 8:57 PM Rob Herring wrote:
>
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
Please forgive my ignorance, but what is this format specifier do
exactly? I cannot find anything listed in th
Hello Scott
On 27/08/2018, Scott Wood wrote:
> On Mon, 2018-08-27 at 20:15 +0200, Christian Zigotzky wrote:
>> Hello,
>>
>> Our users tested the RC1 of kernel 4.19 on their P5020 boards today.
>> Unfortunately the USB bug still exists. With mem values bigger than 4096M,
>> the USB mouse and keybo
On 08/28/2018 11:48 AM, Li Yang wrote:
> On Mon, Aug 27, 2018 at 8:57 PM Rob Herring wrote:
>>
>> In preparation to remove the node name pointer from struct device_node,
>> convert printf users to use the %pOFn format specifier.
>
> Please forgive my ignorance, but what is this format specifier d
On Tue, Aug 28, 2018 at 5:16 PM Tyrel Datwyler
wrote:
>
> On 08/28/2018 11:48 AM, Li Yang wrote:
> > On Mon, Aug 27, 2018 at 8:57 PM Rob Herring wrote:
> >>
> >> In preparation to remove the node name pointer from struct device_node,
> >> convert printf users to use the %pOFn format specifier.
>
On 08/28/2018 03:29 PM, Li Yang wrote:
> On Tue, Aug 28, 2018 at 5:16 PM Tyrel Datwyler
> wrote:
>>
>> On 08/28/2018 11:48 AM, Li Yang wrote:
>>> On Mon, Aug 27, 2018 at 8:57 PM Rob Herring wrote:
In preparation to remove the node name pointer from struct device_node,
convert print
On Fri, Aug 24, 2018 at 9:54 AM Roy Pledge wrote:
>
> On 8/23/2018 5:36 PM, Alexandre Belloni wrote:
> > If the qman driver (qman_ccsr) doesn't probe or fail to probe before
> > qman_portal, qm_ccsr_start will be either NULL or a stale pointer to an
> > unmapped page.
> >
> > This leads to a crash
Quoting Vabhav Sharma (2018-08-19 23:47:14)
> From: Yogesh Gaur
>
> Add clockgen support for lx2160a.
> Added entry for compat 'fsl,lx2160a-clockgen'.
> As LX2160A is 16 core, so modified value for NUM_CMUX
>
> Signed-off-by: Tang Yuantian
> Signed-off-by: Yogesh Gaur
> Signed-off-by: Vabhav S
Hi Breno,
On 08/21/2018 03:56 PM, Breno Leitao wrote:
There are cases where the test is not expecting to have the transaction
aborted, but, the test process might have been rescheduled, either in the OS
level or by KVM (if it is running on a KVM guest machine). The process
reschedule will cause
On Mon, 2018-08-20 at 12:17 +0530, Vabhav Sharma wrote:
> From: Yogesh Gaur
>
> Add clockgen support for lx2160a.
> Added entry for compat 'fsl,lx2160a-clockgen'.
> As LX2160A is 16 core, so modified value for NUM_CMUX
>
> Signed-off-by: Tang Yuantian
> Signed-off-by: Yogesh Gaur
> Signed-off-
On Tue, 2018-08-21 at 15:45 -0500, Rob Herring wrote:
> On Mon, Aug 20, 2018 at 1:52 PM Vabhav Sharma wrote:
> > +/ {
> > + model = "NXP Layerscape LX2160ARDB";
> > + compatible = "fsl,lx2160a-rdb", "fsl,lx2160a";
> > +
> > + aliases {
> > + crypto = &crypto;
>
> D
From: David Gounaris
Date: 2018/8/28 19:09
> Subject: [PATCH 4/6] net/wan/fsl_ucc_hdlc: default hmask value
>
> Set default HMASK to 0x to use
> promiscuous mode in the hdlc controller.
>
> Signed-off-by: David Gounaris
> ---
> drivers/net/wan/fsl_ucc_hdlc.h | 2 +-
> 1 file changed, 1 ins
On Tue, 28 Aug 2018 14:06:32 +1000
Nicholas Piggin wrote:
> On Mon, 27 Aug 2018 19:11:01 +0200
> Andreas Schwab wrote:
>
> > I'm getting this Oops when running iptables -F OUTPUT:
> >
> > [ 91.139409] Unable to handle kernel paging request for data at address
> > 0xd001fff12f34
> > [
On Wed, 29 Aug 2018 13:28:27 +1000
Nicholas Piggin wrote:
> On Tue, 28 Aug 2018 14:06:32 +1000
> Nicholas Piggin wrote:
>
> > On Mon, 27 Aug 2018 19:11:01 +0200
> > Andreas Schwab wrote:
> >
> > > I'm getting this Oops when running iptables -F OUTPUT:
> > >
> > > [ 91.139409] Unable to h
On Tue, 28 Aug 2018 18:09:09 +0200
Ard Biesheuvel wrote:
> On 28 August 2018 at 15:56, Ard Biesheuvel wrote:
> > Hello Andreas, Nick,
> >
> > On 28 August 2018 at 06:06, Nicholas Piggin
> > wrote:
> >> On Mon, 27 Aug 2018 19:11:01 +0200
> >> Andreas Schwab wrote:
> >>
> >>> I'm getting th
The newly added code that emits ksymtab entries as pairs of 32-bit
relative references interacts poorly with the way powerpc lays out
its address space: when a module exports a per-CPU variable, the
primary module region covering the ksymtab entry -and thus the 32-bit
relative reference- is too far
45 matches
Mail list logo