Re: [PATCH 0/3] System call table generation support

2018-11-30 Thread Firoz Khan
Hi Satheesh, On Fri, 30 Nov 2018 at 12:32, Satheesh Rajendran wrote: > > On Thu, Nov 29, 2018 at 01:48:16PM +0530, Firoz Khan wrote: > > Hi Sathish, > > > > Thanks for your email. > > > > On Thu, 29 Nov 2018 at 12:05, Satheesh Rajendran > > wrote: > > > > > > On Fri, Sep 14, 2018 at 02:02:57PM +

Re: use generic DMA mapping code in powerpc V4

2018-11-30 Thread Christoph Hellwig
Hi Rui, can you check if the patch below fixes the issue for you? diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c index 2e24fc87ed84..809797dbe169 100644 --- a/arch/powerpc/sysdev/dart_iommu.c +++ b/arch/powerpc/sysdev/dart_iommu.c @@ -392,7 +392,9 @@ static void

Re: use generic DMA mapping code in powerpc V4

2018-11-30 Thread Christoph Hellwig
Hi Christian, for such a diverse architecture like powerpc we'll have to rely on users / non core developers like you to help with testing. Can you try the patch below for he cyrus config? For the nemo one I have no idea yet, there is no chance I could trick you into a git bisect to see which pa

Re: [PATCHv2 3/6] PCI: layerscape: Add the EP mode support

2018-11-30 Thread Lorenzo Pieralisi
On Mon, Nov 05, 2018 at 04:46:50PM +0800, Xiaowei Bao wrote: > Add the EP mode support. > > Signed-off-by: Xiaowei Bao > --- > v2: > - Add the SoC specific compatibles. > > .../devicetree/bindings/pci/layerscape-pci.txt |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) Wrong

Re: use generic DMA mapping code in powerpc V4

2018-11-30 Thread Rui Salvaterra
On Fri, 30 Nov 2018 at 10:32, Christoph Hellwig wrote: > > Hi Rui, > > can you check if the patch below fixes the issue for you? > > diff --git a/arch/powerpc/sysdev/dart_iommu.c > b/arch/powerpc/sysdev/dart_iommu.c > index 2e24fc87ed84..809797dbe169 100644 > --- a/arch/powerpc/sysdev/dart_iommu.

Re: use generic DMA mapping code in powerpc V4

2018-11-30 Thread Christian Zigotzky
Hi Christoph, Thanks a lot for your fast reply. On 30 November 2018 at 11:53AM, Christoph Hellwig wrote: Hi Christian, for such a diverse architecture like powerpc we'll have to rely on users / non core developers like you to help with testing. I see. I will help as good as I can. Can you t

Re: use generic DMA mapping code in powerpc V4

2018-11-30 Thread Christoph Hellwig
On Fri, Nov 30, 2018 at 01:23:20PM +0100, Christian Zigotzky wrote: > Hi Christoph, > > Thanks a lot for your fast reply. > > On 30 November 2018 at 11:53AM, Christoph Hellwig wrote: >> Hi Christian, >> >> for such a diverse architecture like powerpc we'll have to rely on >> users / non core develo

Re: [PATCH] powerpc: Look for "stdout-path" when setting up legacy consoles

2018-11-30 Thread Rob Herring
On Thu, Nov 29, 2018 at 9:54 PM Benjamin Herrenschmidt wrote: > > Commit 78e5dfea8 "powerpc: dts: replace 'linux,stdout-path' with > 'stdout-path'" > broke the default console on a number of embedded PowerPC systems, because it > failed to also update the code in arch/powerpc/kernel/legacy_serial

Re: use generic DMA mapping code in powerpc V4

2018-11-30 Thread Christian Zigotzky
Hello Christoph, Thanks for your reply. On 30 November 2018 at 2:10PM, Christoph Hellwig wrote: On Fri, Nov 30, 2018 at 01:23:20PM +0100, Christian Zigotzky wrote: Yes, of course. I patched your Git kernel and after that I compiled it again. U-Boot loads the kernel and the dtb file. Then the k

Re: [PATCHv2 5/6] pci: layerscape: Add the EP mode support.

2018-11-30 Thread Lorenzo Pieralisi
On Mon, Nov 05, 2018 at 04:46:52PM +0800, Xiaowei Bao wrote: > Add the PCIe EP mode support for layerscape platform. > > Signed-off-by: Xiaowei Bao > --- > v2: > - remove the EP mode check function. > > drivers/pci/controller/dwc/Makefile|2 +- > drivers/pci/controller/dwc/pci-

Re: use generic DMA mapping code in powerpc V4

2018-11-30 Thread Rui Salvaterra
Hi, Christoph, Your powerpc-dma.5 branch seems to be working fine on my G5, so Tested-by: Rui Salvaterra Thanks again! Rui

[PATCH RFCv2 1/4] mm/memory_hotplug: Introduce memory block types

2018-11-30 Thread David Hildenbrand
Memory onlining should always be handled by user space, because only user space knows which use cases it wants to satisfy. E.g. memory might be onlined to the MOVABLE zone even if it can never be removed from the system, e.g. to make usage of huge pages more reliable. However to implement such rul

[PATCH RFCv2 2/4] mm/memory_hotplug: Replace "bool want_memblock" by "int type"

2018-11-30 Thread David Hildenbrand
Let's pass a memory block type instead. Pass "MEMORY_BLOCK_NONE" for device memory and for now "MEMORY_BLOCK_UNSPECIFIED" for anything else. No functional change. Cc: Tony Luck Cc: Fenghua Yu Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Martin Schwidefsky Cc: Heiko

Re: [PATCH 12/36] dt-bindings: arm: Convert cpu binding to json-schema

2018-11-30 Thread Rob Herring
On Thu, Nov 8, 2018 at 2:49 AM Michal Simek wrote: > > Hi Rob, > > On 05. 10. 18 18:58, Rob Herring wrote: > > Convert ARM CPU binding to DT schema format using json-schema. > > > > Cc: Mark Rutland > > Cc: Matthias Brugger > > Cc: devicet...@vger.kernel.org > > Cc: linux-arm-ker...@lists.infrad

[PATCH RFCv2 3/4] mm/memory_hotplug: Introduce and use more memory types

2018-11-30 Thread David Hildenbrand
Let's introduce new types for different kinds of memory blocks and use them in existing code. As I don't see an easy way to split this up, do it in one hunk for now. acpi: Use DIMM or DIMM_UNREMOVABLE depending on hotremove support in the kernel. Properly change the type when trying to add memor

[PATCH RFCv2 4/4] mm/memory_hotplug: Drop MEMORY_TYPE_UNSPECIFIED

2018-11-30 Thread David Hildenbrand
We now have proper types for all users, we can drop this one. Cc: Greg Kroah-Hartman Cc: "Rafael J. Wysocki" Cc: Andrew Morton Cc: Ingo Molnar Cc: Pavel Tatashin Cc: Stephen Rothwell Cc: Andrew Banman Cc: "mike.tra...@hpe.com" Cc: Oscar Salvador Cc: Dave Hansen Cc: Michal Hocko Cc: Mich

Re: [PATCH RFCv2 1/4] mm/memory_hotplug: Introduce memory block types

2018-11-30 Thread Wei Yang
On Fri, Nov 30, 2018 at 06:59:19PM +0100, David Hildenbrand wrote: >Memory onlining should always be handled by user space, because only user >space knows which use cases it wants to satisfy. E.g. memory might be >onlined to the MOVABLE zone even if it can never be removed from the >system, e.g. to

Re: [PATCH RFCv2 2/4] mm/memory_hotplug: Replace "bool want_memblock" by "int type"

2018-11-30 Thread Wei Yang
On Fri, Nov 30, 2018 at 06:59:20PM +0100, David Hildenbrand wrote: >Let's pass a memory block type instead. Pass "MEMORY_BLOCK_NONE" for device >memory and for now "MEMORY_BLOCK_UNSPECIFIED" for anything else. No >functional change. I would suggest to put more words to this. " Function arch_add_m