On 13/06/19 12:21 AM, Naveen N. Rao wrote:
> The first patch updates DIV64 overflow tests to properly detect error
> conditions. The second patch fixes powerpc64 JIT to generate the proper
> unsigned division instruction for BPF_ALU64.
>
> - Naveen
>
> Naveen N. Rao (2):
> bpf: fix div64 ov
Le 12/06/2019 à 15:59, Horia Geanta a écrit :
On 6/12/2019 8:52 AM, Christophe Leroy wrote:
Le 11/06/2019 à 18:30, Horia Geanta a écrit :
On 6/11/2019 6:40 PM, Christophe Leroy wrote:
Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
This seri
Hi Shengjiu,
On Thu, Jun 13, 2019 at 03:00:58AM +, S.j. Wang wrote:
> > Commit 8973112aa41b ("ASoC: fsl_esai: ETDR and TX0~5 registers are non
> > volatile") removed TX data registers from the volatile_reg list and appended
> > default values for them. However, being data registers of TX, they
Powerpc hw triggers watchpoint before executing the instruction. To
make trigger-after-execute behavior, kernel emulates the instruction.
If the instruction is 'load something into non-volatile register',
exception handler should restore emulated register state while
returning back, otherwise there
Pawel Dembicki writes:
> Enable kernel XZ compression option on PPC_85xx. Tested with
> simpleImage on TP-Link TL-WDR4900 (Freescale P1014 processor).
>
> Suggested-by: Christian Lamparter
> Signed-off-by: Pawel Dembicki
> ---
> arch/powerpc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1
Hi
>
> Commit 8973112aa41b ("ASoC: fsl_esai: ETDR and TX0~5 registers are non
> volatile") removed TX data registers from the volatile_reg list and appended
> default values for them. However, being data registers of TX, they should
> not have been removed from the list because they should not be
> > > 3:
> > > /* Emulate H_SET_DABR/X on P8 for the sake of compat mode
> > > guests */
> > > rlwimi r5, r4, 5, DAWRX_DR | DAWRX_DW
> > > c010b03c: 74 2e 85 50 rlwimi r5,r4,5,25,26
> > > rlwimi r5, r4, 2, DAWRX_WT
> > > c010b040: f6 16 8
Commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
option") screwed up some assembler and corrupted a pointer in
r3. This resulted in crashes like the below:
[ 44.374746] BUG: Kernel NULL pointer dereference at 0x13bf
[ 44.374848] Faulting instruction address: 0xc010
On Thu, 2019-06-13 at 10:16 +1000, Michael Neuling wrote:
> On Wed, 2019-06-12 at 09:43 +0200, Cédric Le Goater wrote:
> > On 12/06/2019 09:22, Michael Neuling wrote:
> > > In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
> > > option") I screwed up some assembler and corrupted a po
On Wed, 2019-06-12 at 09:43 +0200, Cédric Le Goater wrote:
> On 12/06/2019 09:22, Michael Neuling wrote:
> > In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
> > option") I screwed up some assembler and corrupted a pointer in
> > r3. This resulted in crashes like the below from Cédr
Hi Nayna,
>>> Since OPAL can support different types of backend which can vary in the
>>> variable interpretation, a new OPAL API call named OPAL_SECVAR_BACKEND, is
>>> added to retrieve the supported backend version. This helps the consumer
>>> to know how to interpret the variable.
>>>
>> (First
On 06/12/2019 02:17 AM, Daniel Axtens wrote:
Nayna Jain writes:
From: Claudio Carvalho
The X.509 certificates trusted by the platform and other information
required to secure boot the OS kernel are wrapped in secure variables,
which are controlled by OPAL.
This patch adds support to read
The kbuild documentation clearly shows that the documents
there are written at different times: some use markdown,
some use their own peculiar logic to split sections.
Convert everything to ReST without affecting too much
the author's style and avoiding adding uneeded markups.
The conversion is a
On Wed, 2019-06-12 at 14:41 -0500, Larry Finger wrote:
> On 6/12/19 1:55 AM, Christoph Hellwig wrote:
> >
> > Ooops, yes. But I think we could just enable ZONE_DMA on 32-bit
> > powerpc. Crude enablement hack below:
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 8c1c
On 6/12/19 1:55 AM, Christoph Hellwig wrote:
Ooops, yes. But I think we could just enable ZONE_DMA on 32-bit
powerpc. Crude enablement hack below:
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c1c636308c8..1dd71a98b70c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kco
On 6/12/19 2:07 AM, Alexey Kardashevskiy wrote:
On 12/06/2019 15:05, Shawn Anastasio wrote:
On 6/5/19 11:11 PM, Shawn Anastasio wrote:
On 5/30/19 2:03 AM, Alexey Kardashevskiy wrote:
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass m
On 6/12/19 1:16 AM, Oliver O'Halloran wrote:
On Wed, Jun 12, 2019 at 3:06 PM Shawn Anastasio wrote:
On 6/5/19 11:11 PM, Shawn Anastasio wrote:
On 5/30/19 2:03 AM, Alexey Kardashevskiy wrote:
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3
If the result of the division is LLONG_MIN, current tests do not detect
the error since the return value is truncated to a 32-bit value and ends
up being 0.
Signed-off-by: Naveen N. Rao
---
.../testing/selftests/bpf/verifier/div_overflow.c | 14 ++
1 file changed, 10 insertions(+),
BPF_ALU64 div/mod operations are currently using signed division, unlike
BPF_ALU32 operations. Fix the same. DIV64 and MOD64 overflow tests pass
with this fix.
Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended
BPF")
Cc: sta...@vger.kernel.org # v4.8+
Signed-off-by: Nav
The first patch updates DIV64 overflow tests to properly detect error
conditions. The second patch fixes powerpc64 JIT to generate the proper
unsigned division instruction for BPF_ALU64.
- Naveen
Naveen N. Rao (2):
bpf: fix div64 overflow tests to properly detect errors
powerpc/bpf: use uns
On Wed, Jun 12, 2019 at 5:54 PM Greg Kroah-Hartman
wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Because there's no need to check, also make th
Convert kdump documentation to ReST and add it to the
user faced manual, as the documents are mainly focused on
sysadmins that would be enabling kdump.
Note: the vmcoreinfo.rst has one very long title on one of its
sub-sections:
PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwp
Convert docs to ReST and add them to the arch-specific
book.
The conversion here was trivial, as almost every file there
was already using an elegant format close to ReST standard.
The changes were mostly to mark literal blocks and add a few
missing section title identifiers.
One note with regar
Bharata B Rao writes:
> queue_hotplug_event() gets called from interrupt handler code. Use
> GFP_ATOMIC allocations instead of GFP_KERNEL.
https://patchwork.ozlabs.org/patch/1106626/
(That version also adds a missing check for the result of the first
kmalloc.)
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because there's no need to check, also make the return value of the
local debugfs_create_io_x64() call void, as no o
On Wed, Jun 12, 2019 at 11:51:21AM +0200, Arnd Bergmann wrote:
> On Tue, Jun 11, 2019 at 8:13 PM Greg Kroah-Hartman
> wrote:
>
> > @@ -64,8 +64,6 @@ int cxl_debugfs_adapter_add(struct cxl *adapter)
> >
> > snprintf(buf, 32, "card%i", adapter->adapter_num);
> > dir = debugfs_create
queue_hotplug_event() gets called from interrupt handler code. Use
GFP_ATOMIC allocations instead of GFP_KERNEL.
Signed-off-by: Bharata B Rao
---
arch/powerpc/platforms/pseries/dlpar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
Le 12/06/2019 à 12:02, Greg Kroah-Hartman a écrit :
On Wed, Jun 12, 2019 at 11:51:21AM +0200, Arnd Bergmann wrote:
On Tue, Jun 11, 2019 at 8:13 PM Greg Kroah-Hartman
wrote:
@@ -64,8 +64,6 @@ int cxl_debugfs_adapter_add(struct cxl *adapter)
snprintf(buf, 32, "card%i", adapter->ada
current may be cached by the compiler, so remove the volatile asm
restriction. This results in better generated code, as well as being
smaller and fewer dependent loads, it can avoid store-hit-load flushes
like this one that shows up in irq_exit():
preempt_count_sub(HARDIRQ_OFFSET);
if (!i
On 6/12/2019 8:52 AM, Christophe Leroy wrote:
>
>
> Le 11/06/2019 à 18:30, Horia Geanta a écrit :
>> On 6/11/2019 6:40 PM, Christophe Leroy wrote:
>>>
>>>
>>> Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> This series is the last set of fixe
On 6/12/2019 8:49 AM, Christophe Leroy wrote:
> Below commit came with a typo in the CONFIG_ symbol, leading
> to a permanently reduced max key size regarless of the driver
> capabilities.
>
> Reported-by: Horia Geantă
> Fixes: b8fbdc2bc4e7 ("crypto: talitos - reduce max key size for SEC1")
> Sig
On Wed, Jun 12, 2019 at 4:53 PM Christoph Hellwig wrote:
>
> On Wed, Jun 12, 2019 at 04:35:22PM +1000, Oliver O'Halloran wrote:
> > Setting a 48 bit DMA mask doesn't work today because we only allocate
> > IOMMU tables to cover the 0..2GB range of PCI bus addresses.
>
> I don't think that is true
On Wed, Jun 12, 2019 at 11:51:21AM +0200, Arnd Bergmann wrote:
> On Tue, Jun 11, 2019 at 8:13 PM Greg Kroah-Hartman
> wrote:
>
> > @@ -64,8 +64,6 @@ int cxl_debugfs_adapter_add(struct cxl *adapter)
> >
> > snprintf(buf, 32, "card%i", adapter->adapter_num);
> > dir = debugfs_create
Hi Michael,
A gentle ping.
On 2019/5/29 17:21, Shaokun Zhang wrote:
> pr_info shows SPR and timebase as a decimal value with a '0x'
> prefix, which is somewhat misleading.
>
> Fix it to print hexadecimal, as was intended.
>
> Fixes: 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C"
On Tue, Jun 11, 2019 at 8:13 PM Greg Kroah-Hartman
wrote:
> @@ -64,8 +64,6 @@ int cxl_debugfs_adapter_add(struct cxl *adapter)
>
> snprintf(buf, 32, "card%i", adapter->adapter_num);
> dir = debugfs_create_dir(buf, cxl_debugfs);
> - if (IS_ERR(dir))
> - return P
Le 12/06/2019 à 11:23, Paul Mackerras a écrit :
On Wed, Jun 12, 2019 at 09:42:52AM +0200, Christophe Leroy wrote:
Le 12/06/2019 à 09:22, Michael Neuling a écrit :
In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
option") I screwed up some assembler and corrupted a pointer i
On Wed, Jun 12, 2019 at 09:42:52AM +0200, Christophe Leroy wrote:
>
>
> Le 12/06/2019 à 09:22, Michael Neuling a écrit :
> >In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
> >option") I screwed up some assembler and corrupted a pointer in
> >r3. This resulted in crashes like the
On Wed, 2019-06-12 at 09:25 +0300, Oded Gabbay wrote:
>
> > You can't. Your device is broken. Devices that don't support DMAing to
> > the full 64-bit deserve to be added to the trash pile.
> >
>
> Hmm... right know they are added to customers data-centers but what do I know
> ;)
Well, some cu
On Wed, 2019-06-12 at 15:45 +1000, Oliver O'Halloran wrote:
>
> Also, are you sure about the MSI thing? The IODA3 spec says the only
> important bits for a 64bit MSI are bits 61:60 (to hit the window) and
> the lower bits that determine what IVE to use. Everything in between
> is ignored so ORing
On 12/06/2019 09:22, Michael Neuling wrote:
> In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
> option") I screwed up some assembler and corrupted a pointer in
> r3. This resulted in crashes like the below from Cédric:
>
> [ 44.374746] BUG: Kernel NULL pointer dereference at 0
Le 12/06/2019 à 09:22, Michael Neuling a écrit :
In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
option") I screwed up some assembler and corrupted a pointer in
r3. This resulted in crashes like the below from Cédric:
Iaw Documentation/process/submitting-patches.rst:
Descri
In commit c1fe190c0672 ("powerpc: Add force enable of DAWR on P9
option") I screwed up some assembler and corrupted a pointer in
r3. This resulted in crashes like the below from Cédric:
[ 44.374746] BUG: Kernel NULL pointer dereference at 0x13bf
[ 44.374848] Faulting instruction addres
These Kconfig options has been removed in
commit 4c145dce2601 ("xfrm: make xfrm modes builtin")
So there is no point to keep it in defconfigs any longer.
Signed-off-by: YueHaibing
---
arch/arc/configs/axs101_defconfig | 3 ---
arch/arc/configs/axs103_defconfig | 3 ---
Pls ignore this, will fix and resend.
On 2019/6/12 15:06, YueHaibing wrote:
> These Kconfig options has been removed in
> commit 4c145dce2601 ("xfrm: make xfrm modes builtin")
> So there is no point to keep it in defconfigs any longer.
>
> Signed-off-by: YueHaibing
> ---
> arch/arc/configs/axs1
On 12/06/2019 15:05, Shawn Anastasio wrote:
> On 6/5/19 11:11 PM, Shawn Anastasio wrote:
>> On 5/30/19 2:03 AM, Alexey Kardashevskiy wrote:
>>> This is an attempt to allow DMA masks between 32..59 which are not large
>>> enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
>>>
These Kconfig options has been removed in
commit 4c145dce2601 ("xfrm: make xfrm modes builtin")
So there is no point to keep it in defconfigs any longer.
Signed-off-by: YueHaibing
---
arch/arc/configs/axs101_defconfig | 3 ---
arch/arc/configs/axs103_defconfig | 3 ---
46 matches
Mail list logo