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
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
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,
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
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
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:
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
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
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.
>>>
>>
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
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
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
+++
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
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:
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
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
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:
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
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
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 =
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",
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
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
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")
>
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 =
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
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
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
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
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
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:
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
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
> ---
>
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
On Tue, Jun 11, 2019 at 05:20:12PM -0500, Larry Finger wrote:
> Your first patch did not work as the configuration does not have
> CONFIG_ZONE_DMA. As a result, the initial value of min_mask always starts
> at 32 bits and is taken down to 31 with the maximum pfn minimization. When
> I forced
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 upstream, and if it is we need to fix bug
in the powerpc code.
On Wed, Jun 12, 2019 at 3:25 AM Oded Gabbay wrote:
>
> On Tue, Jun 11, 2019 at 8:03 PM Oded Gabbay wrote:
> >
> > On Tue, Jun 11, 2019 at 6:26 PM Greg KH wrote:
> > > *snip*
> >
> > Now, when I tried to integrate Goya into a POWER9 machine, I got a
> > reject from the call to
Paul Clarke wrote:
What are the circumstances in which raw_syscalls:sys_exit reports "-1" for the
syscall ID?
perf 5375 [007] 59632.478528: raw_syscalls:sys_enter: NR 1 (3, 9fb888,
8, 2d83740, 1, 7)
perf 5375 [007] 59632.478532:raw_syscalls:sys_exit: NR 1 = 8
perf
On 2019/6/12 13:16, Borislav Petkov wrote:
> On Thu, May 30, 2019 at 11:48:26AM +0800, Zhen Lei wrote:
>> This patch removes the ifdefs around CONFIG_IOMMU_DEFAULT_PASSTHROUGH to
>> improve readablity.
>
> Avoid having "This patch" or "This commit" in the commit message. It is
> tautologically
On Wed, Jun 12, 2019 at 1:53 AM Benjamin Herrenschmidt
wrote:
>
> On Tue, 2019-06-11 at 20:22 +0300, Oded Gabbay wrote:
> >
> > > So, to summarize:
> > > If I call pci_set_dma_mask with 48, then it fails on POWER9. However,
> > > in runtime, I don't know if its POWER9 or not, so upon failure I
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 OPAL secure variables through
>
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 bypass mode or a sketchy bypass.
54 matches
Mail list logo
