Hi Arnd,
On Thu, Jan 10, 2019 at 11:43 PM Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 7:11 PM Geert Uytterhoeven
> wrote:
> > On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann wrote:
> > > On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven
> > > wrote:
> > > > On Thu, Jan 10, 2019 at 5:26 PM
Christophe Leroy writes:
> Le 10/01/2019 à 12:57, Michael Ellerman a écrit :
>> Using pr_cont() risks having our output interleaved with other output
>> from other CPUs. Instead print everything in a single printk() call.
>>
>> Signed-off-by: Michael Ellerman
>
> Reviewed-by: Christophe Leroy
>
On Fri, Jan 11, 2019 at 05:06:12PM +1100, Michael Ellerman wrote:
> Tyrel Datwyler writes:
> > It is basically the predecessor to PAPR "Power Architecture Platform
> > Reference".
> > Which the LoPAPR document is available through power.org. Not sure if there
> > is
> > any desire to adopt PAPR
Corentin Labbe writes:
> I wanted to test the virtex440-ml507 qemu machine and found that the dtb
> for it was not builded.
> All powerpc DTB are only built when CONFIG_OF_ALL_DTBS is set which depend on
> COMPILE_TEST.
>
> This patchs adds build of virtex dtbs depending on
> CONFIG_XILINX_VIRTEX
Christian Lamparter writes:
> On Tuesday, January 8, 2019 10:54:28 AM CET Michael Ellerman wrote:
>> Christian Lamparter writes:
...
>> diff --git a/arch/powerpc/platforms/4xx/ocm.c
>> b/arch/powerpc/platforms/4xx/ocm.c
>> index a1aaa1569d7c..f0e488d97567 100644
>> --- a/arch/powerpc/platforms/4
On Tue, 8 Jan 2019 11:09:19 +0800, Xiaowei Bao wrote:
> Add the documentation for the Device Tree binding for the layerscape PCIe
> controller with EP mode.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - Add the SoC specific compatibles.
> v3:
> - modify the commit message.
> v4:
> - no chang
We have encountered cases where DLPAR CPU 'readd' fails on single
CPU platforms, because the system needs a minimum amount of resources
to keep operating. The current implementation attempts to add, and
remove all of the threads of a specified core at once, and will fail
if there is a problem remo
On Thu, Jan 10, 2019 at 9:36 PM Heiko Carstens
wrote:
> On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> Since you only need/want the system call numbers, could you please
> change these lines to:
>
> > +384 common pkey_alloc - -
> > +3
On Thu, Jan 10, 2019 at 9:33 PM Heiko Carstens
wrote:
> On Thu, Jan 10, 2019 at 05:24:34PM +0100, Arnd Bergmann wrote:
> > diff --git a/arch/s390/kernel/syscalls/syscall.tbl
> > b/arch/s390/kernel/syscalls/syscall.tbl
> > index 022fc099b628..428cf512a757 100644
> > --- a/arch/s390/kernel/syscall
Just returning the physical address when not map_resource method is
present is highly dangerous as it doesn't take any offset in the
direct mapping into account and does the completely wrong thing for
IOMMUs. Instead provide a proper implementation in the direct mapping
code, and also wire it up f
Use WARN_ON_ONCE to print a stack trace and return a proper error
code instead.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index d3087829a6df..91a
Hi all,
this series fixes a rather gross layering violation in videobuf2, which
pokes into arm DMA mapping internals to get a DMA address for memory that
does not have a page structure, and to do so fixes up the dma_map_resource
implementation to be practically useful.
vb2_dc_get_userptr pokes into arm direct mapping details to get the
resemblance of a dma address for a a physical address that does is
not backed by a page struct. Not only is this not portable to other
architectures with dma direct mapping offsets, but also not to uses
of IOMMUs of any kind. Swi
On Thu, Jan 10, 2019 at 12:11:53PM -0800, Tyrel Datwyler wrote:
> This allocation isn't a single use allocation. The driver is just lazy about
> allocating our ext_list area for large SG lists (ie. SG_ALL). When the driver
> was first written it only supported up to 10 indirect SRP buffers. James
On Thu, Jan 10, 2019 at 03:15:35PM -0800, Tyrel Datwyler wrote:
> On a secondary note I was unaware of the GFP_ATOMIC limitations. Should this
> be
> added to the documentation somewhere? I don't see any mention here form
> DMA-API-HOWTO.txt.
The DMA documentation unfortauntely doesn't seem very
On Tue, Jan 08, 2019 at 01:05:43PM +, Viorel Suman wrote:
> The patchset adds NXP Audio Mixer (AUDMIX) device and machine
> drivers and related DT bindings documentation.
>
> Changes since V1:
> 1. Original patch split into distinct patches for the device driver and
> DT binding documentatio
Hello,
Arnd Bergmann wrote:
> While reading through the sysvipc implementation, I noticed that the n32
> semctl/shmctl/msgctl system calls behave differently based on whether
> o32 support is enabled or not: Without o32, the IPC_64 flag passed by
> user space is rejected but calls without that fla
Em Fri, 11 Jan 2019 19:17:31 +0100
Christoph Hellwig escreveu:
> vb2_dc_get_userptr pokes into arm direct mapping details to get the
> resemblance of a dma address for a a physical address that does is
> not backed by a page struct. Not only is this not portable to other
> architectures with dma
> -Original Message-
> From: Nicholas Mc Guire
> Sent: Thursday, January 10, 2019 8:44 PM
> To: Leo Li
> Cc: Scott Wood ; linuxppc-dev d...@lists.ozlabs.org>; lkml ; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE ker...@lists.infradead.org>; Nicholas Mc Guire
> Subject: R
Reuse the string machine from the device tree data structure instead
of duplicating the data again. This also prevents a potential memory
allocation failure that was not handled previously. Also fixes an early
put of root device node.
Reported-by: Nicholas Mc Guire
Signed-off-by: Li Yang
---
In the ld documentation under Builtin Functions:
BLOCK(exp)
This is a synonym for ALIGN, for compatibility with older linker scripts.
Clang's linker (lld) doesn't know about BLOCK so remove this use of it.
Link: https://github.com/ClangBuiltLinux/linux/issues/253
Signed-off-by: Joel Stanl
On Wed, Jan 09, 2019 at 01:23:29PM +0300, Dan Carpenter wrote:
> There is a typo so we accidentally allocate enough memory for a pointer
> when we wanted to allocate enough for a struct.
>
> Fixes: 0bd971676e68 ("powerpc/powernv/npu: Add compound IOMMU groups")
> Signed-off-by: Dan Carpenter
> --
On Thu, Jan 10, 2019 at 04:14:00PM -0500, Joe Lawrence wrote:
> Hi all,
>
> tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
>about?
>
> I am looking at a bug in which ~10% of livepatch tests on RHEL-7 and
> RHEL-8 distro kernels, the ppc64le reliable stack unwinder con
On Sat, Jan 12, 2019 at 11:30:35AM +1100, Balbir Singh wrote:
> On Wed, Jan 09, 2019 at 01:23:29PM +0300, Dan Carpenter wrote:
> > There is a typo so we accidentally allocate enough memory for a pointer
> > when we wanted to allocate enough for a struct.
> >
> > Fixes: 0bd971676e68 ("powerpc/power
On Sat, Jan 12, 2019 at 08:44:26AM +0300, Dan Carpenter wrote:
> On Sat, Jan 12, 2019 at 11:30:35AM +1100, Balbir Singh wrote:
> > On Wed, Jan 09, 2019 at 01:23:29PM +0300, Dan Carpenter wrote:
> > > There is a typo so we accidentally allocate enough memory for a pointer
> > > when we wanted to all
25 matches
Mail list logo
