Re: [PATCH kernel 05/10] powerpc/powernv/npu: Use the correct IOMMU page size

On Wed, Mar 09, 2016 at 05:29:01PM +1100, Alexey Kardashevskiy wrote: > This uses the page size from iommu_table instead of hard-coded 4K. > This should cause no change in behavior. > > While we are here, move bits around to prepare for further rework > which will define and use

Re: [PATCH kernel 04/10] powerpc/powernv/npu: TCE Kill helpers cleanup

On Wed, Mar 09, 2016 at 05:29:00PM +1100, Alexey Kardashevskiy wrote: > NPU PHB TCE Kill register is exactly the same as in the rest of POWER8 > so let's reuse the existing code for NPU. The only bit missing is > a helper to reset the entire TCE cache so this moves such a helper > from NPU code

Re: [PATCH kernel 03/10] powerpc/powernv: Define TCE Kill flags

On Wed, Mar 09, 2016 at 05:28:59PM +1100, Alexey Kardashevskiy wrote: > This replaces magic constants for TCE Kill IODA2 register with macros. > > Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson > --- >

Re: [PATCH kernel 01/10] vfio/spapr: Relax the IOMMU compatibility check

On Wed, Mar 09, 2016 at 05:28:57PM +1100, Alexey Kardashevskiy wrote: > We are going to have multiple different types of PHB on the same system > with POWER8 + NVLink and PHBs will have different IOMMU ops. However > we only really care about one callback - create_table - so we can > relax the

Re: [PATCH kernel 02/10] powerpc/powernv: Rename pnv_pci_ioda2_tce_invalidate_entire

On Wed, Mar 09, 2016 at 05:28:58PM +1100, Alexey Kardashevskiy wrote: > As in fact pnv_pci_ioda2_tce_invalidate_entire() invalidates TCEs for > the specific PE rather than the entire cache, rename it to > pnv_pci_ioda2_tce_invalidate_pe(). In later patches we will add > a proper

Re: [PATCH 1/2] powerpc: Batch up loads/stores on saving and restoring Altivec

On Thu, 10 Mar 2016 10:01:07 +1100 Michael Neuling wrote: > On Tue, 2016-03-01 at 16:55 +1100, Cyril Bur wrote: > > > Currently the assembly to save and restore Altivec registers boils down to > > a load immediate of the offset of the specific Altivec register in memory > >

Re: [RFC 4/9] powerpc/mm: Split huge_pte_alloc function for BOOK3S 64K

On 03/10/2016 01:25 AM, Aneesh Kumar K.V wrote: > Anshuman Khandual writes: > >> > [ text/plain ] >> > From: root >> > >> > Currently the 'huge_pte_alloc' function has two versions, one for the >> > BOOK3S and the other one

Re: [PATCH kernel 9/9] KVM: PPC: VFIO device: support SPAPR TCE

On Wed, Mar 09, 2016 at 08:20:12PM +1100, Alexey Kardashevskiy wrote: > On 03/09/2016 04:45 PM, David Gibson wrote: > >On Mon, Mar 07, 2016 at 02:41:17PM +1100, Alexey Kardashevskiy wrote: > >>sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap > >>via hypercalls which take a logical

Re: [PATCH kernel 8/9] KVM: PPC: Add in-kernel handling for VFIO

On Wed, Mar 09, 2016 at 07:46:47PM +1100, Alexey Kardashevskiy wrote: > On 03/08/2016 10:08 PM, David Gibson wrote: > >On Mon, Mar 07, 2016 at 02:41:16PM +1100, Alexey Kardashevskiy wrote: > >>This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT > >>and H_STUFF_TCE requests targeted

Re: [RFC 6/9] powerpc/hugetlb: Enable ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K

On 03/10/2016 01:28 AM, Aneesh Kumar K.V wrote: > Anshuman Khandual writes: > >> > [ text/plain ] >> > This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig. >> > It also implements a new function 'pte_huge' which is required by >> > function

Re: [RFC 9/9] selfttest/powerpc: Add memory page migration tests

On 03/10/2016 01:31 AM, Aneesh Kumar K.V wrote: > Anshuman Khandual writes: > >> > [ text/plain ] >> > This adds two tests for memory page migration. One for normal page >> > migration which works for both 4K or 64K base page size kernel and >> > the other one is for

Re: [RFC PATCH v4 1/7] PCI: Add a new option for resource_alignment to reassign alignment

On 2016/3/10 10:19, Alexey Kardashevskiy wrote: On 03/07/2016 06:48 PM, Yongji Xie wrote: When using resource_alignment kernel parameter, the current implement reassigns the alignment by changing resources' size which can potentially break some drivers. How can this possibly break any

Re: [PATCH 0/6] rtc: generic: follow up for COMPILE_TEST

Hi, On 01/03/2016 at 17:59:56 +0100, Arnd Bergmann wrote : > Today's linux-next kernel allowed building the rtc-generic > driver (and most other rtc drivers) on all architectures, > but this caused some errors on architectures without asm/rtc.h. > > This series reworks that driver to avoid the

Re: [PATCH 4/6] parisc: rtc: provide rtc_class_ops directly

On 01/03/2016 at 18:00:00 +0100, Arnd Bergmann wrote : > - pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0); > + pdev = platform_device_register_data(NULL, "rtc-generic", -1, > + _generic_ops, > +

Re: [RFC 5/9] powerpc/mm: Split huge_pte_offset function for BOOK3S 64K

On 03/10/2016 04:27 AM, Dave Hansen wrote: > On 03/09/2016 04:10 AM, Anshuman Khandual wrote: >> > Currently the 'huge_pte_offset' function has only one version for >> > all the configuations and platforms. This change splits the function >> > into two versions, one for 64K page size based BOOK3S

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

On Wed, 2016-03-09 at 20:07 +0530, Vaibhav Jain wrote: > Hi Ian, > > Sorry for getting into this discussion late. I have few suggestions. > > Ian Munsie writes: > > > > diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig > > index 8756d06..560412c 100644 > >

Re: [RFC PATCH v4 1/7] PCI: Add a new option for resource_alignment to reassign alignment

On 03/07/2016 06:48 PM, Yongji Xie wrote: When using resource_alignment kernel parameter, the current implement reassigns the alignment by changing resources' size which can potentially break some drivers. How can this possibly break any driver?... It rounds up, not down, what do I miss here?

Re: cxl: Ignore probes for virtual afu pci devices

On Mon, 2016-29-02 at 05:40:53 UTC, Vaibhav Jain wrote: > Add a check at the beginning of cxl_probe function to ignore virtual pci > devices created for each afu registered. This fixes the the errors > messages logged about missing CXL vsec, when cxl probe is unable to > find necessary vsec

Re: [v6, 01/20] cxl: Move common code away from bare-metal-specific files

On Fri, 2016-04-03 at 11:26:25 UTC, Frederic Barrat wrote: > From: Christophe Lombard > > Move around some functions which will be accessed from the bare-metal > and guest environments. > Code in native.c and pci.c is meant to be bare-metal specific. > Other files

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

Excerpts from Frederic Barrat's message of 2016-03-09 20:27:20 +1100: > It would also avoid entering > WARN(1, "afu_read must be buggy\n"); > if the driver changes its mind between the 2 calls :-) Honestly, it had better not - that would be a gross violation of the poll & read semantics

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

Excerpts from Vaibhav Jain's message of 2016-03-10 01:37:56 +1100: > > +select CXL_AFU_DRIVER_OPS > I suggest wrapping the driver_ops struct definition and other related > functions inside a #ifdef CONFIG_CXL_AFU_DRIVER_OPS. No, the kconfig option is there so that cxlflash can add support for

Re: [PATCH 2/2] powerpc: Batch up loads/stores on saving and restoring VSX

On Thu, 10 Mar 2016 11:09:32 +1100 Michael Neuling wrote: > On Tue, 2016-03-01 at 16:55 +1100, Cyril Bur wrote: > > > Currently the assembly to save and restore VSX registers boils down to a > > load immediate of the offset of the specific VSX register in memory > > followed

Re: [PATCH 1/2] powerpc: Batch up loads/stores on saving and restoring Altivec

On Thu, 10 Mar 2016 10:01:07 +1100 Michael Neuling wrote: > On Tue, 2016-03-01 at 16:55 +1100, Cyril Bur wrote: > > > Currently the assembly to save and restore Altivec registers boils down to > > a load immediate of the offset of the specific Altivec register in memory > >

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

Excerpts from Frederic Barrat's message of 2016-03-09 20:27:20 +1100: > So on afu_read(), we may call afu_driver_ops->event_pending() twice > before calling afu_driver_ops->deliver_event(). Actually, in the > (likely) scenario where there's only an afu_driver event pending, we > *will* call

Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

On 09/03/16 20:19, Torsten Duwe wrote: > On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote: >> The previous revision was nacked by Torsten, but compared to the alternatives > I nacked it because I was confident it couldn't work. Same goes > for this one, sorry. My good intention was

[PATCH] powerpc/xmon: Fix SPR read/write commands and add command to dump SPRs

Xmon has commands for reading and writing SPRs, but they don't work currently for several reasons. They attempt to synthesize a small function containing an mfspr or mtspr instruction and call it. However, the instructions are on the stack, which is usually not executable. Also, for 64-bit we

Re: [PATCH 2/2] powerpc/mm: Enable page parallel initialisation

On Wed, 2016-03-09 at 13:42 -0800, Andrew Morton wrote: > On Tue, 08 Mar 2016 20:36:34 +1100 Michael Ellerman > wrote: > > > Given that, I think it would be best if Andrew merged both of these patches. > > Because this patch is pretty trivial, whereas the patch to mm/ is

Re: livepatch: Add some basic LivePatch documentation

+++ Petr Mladek [09/03/16 15:01 +0100]: LivePatch framework deserves some documentation, definitely. This is an attempt to provide some basic info. I hope that it will be useful for both LivePatch producers and also potential developers of the framework itself. Signed-off-by: Petr Mladek

Re: [PATCH 2/2] powerpc: Batch up loads/stores on saving and restoring VSX

On Tue, 2016-03-01 at 16:55 +1100, Cyril Bur wrote: > Currently the assembly to save and restore VSX registers boils down to a > load immediate of the offset of the specific VSX register in memory > followed by the load/store which repeats in sequence for each VSX register. > > This patch

Re: [PATCH] cxl: Remove dead code

On Wed, 2016-03-09 at 12:53 +0100, Frederic Barrat wrote: > Function cxl_get_phys_dev() was removed from the kernel API by a > previous patch, but it's actually dead code. Remove it. > > Signed-off-by: Frederic Barrat Acked-by: Michael Neuling >

Re: [PATCH kernel 3/9] KVM: PPC: Use preregistered memory API to access TCE list

On Wed, Mar 09, 2016 at 07:55:53PM +1100, Alexey Kardashevskiy wrote: > On 03/08/2016 05:30 PM, David Gibson wrote: > >On Tue, Mar 08, 2016 at 04:47:20PM +1100, Alexey Kardashevskiy wrote: > >>On 03/07/2016 05:00 PM, David Gibson wrote: > >>>On Mon, Mar 07, 2016 at 02:41:11PM +1100, Alexey

Re: [PATCH] cxl: Remove dead code

On 09/03/16 22:53, Frederic Barrat wrote: Function cxl_get_phys_dev() was removed from the kernel API by a previous patch, but it's actually dead code. Remove it. Signed-off-by: Frederic Barrat For those playing along at home, this applies on top of the cxl

Re: [PATCH] cxl: Remove dead code

Acked-by: Ian Munsie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] powerpc: Batch up loads/stores on saving and restoring Altivec

On Tue, 2016-03-01 at 16:55 +1100, Cyril Bur wrote: > Currently the assembly to save and restore Altivec registers boils down to > a load immediate of the offset of the specific Altivec register in memory > followed by the load/store which repeats in sequence for each Altivec > register. > >

Re: [RFC 5/9] powerpc/mm: Split huge_pte_offset function for BOOK3S 64K

On 03/09/2016 04:10 AM, Anshuman Khandual wrote: > Currently the 'huge_pte_offset' function has only one version for > all the configuations and platforms. This change splits the function > into two versions, one for 64K page size based BOOK3S implementation > and the other one for everything

Re: [PATCH 2/2] powerpc/mm: Enable page parallel initialisation

On Tue, 08 Mar 2016 20:36:34 +1100 Michael Ellerman wrote: > Given that, I think it would be best if Andrew merged both of these patches. > Because this patch is pretty trivial, whereas the patch to mm/ is less so. > > Is that OK Andrew? Yep, no probs.

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

On Wed, 2016-03-09 at 11:28 +0100, Gabriel Paubert wrote: > On Wed, Mar 09, 2016 at 12:38:18AM -0600, Scott Wood wrote: > > On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > > > The mtmsr() function hangs during restart. Make reboot works on > > > MVME5100 removing that

Re: [PATCH] livepatch: Add some basic LivePatch documentation

On 03/09/2016 04:01 PM, Petr Mladek wrote: > LivePatch framework deserves some documentation, definitely. > This is an attempt to provide some basic info. I hope that > it will be useful for both LivePatch producers and also > potential developers of the framework itself. > > Signed-off-by:

Re: [RFC 9/9] selfttest/powerpc: Add memory page migration tests

Anshuman Khandual writes: > [ text/plain ] > This adds two tests for memory page migration. One for normal page > migration which works for both 4K or 64K base page size kernel and > the other one is for huge page migration which works only on 64K > base page sized

Re: [RFC 6/9] powerpc/hugetlb: Enable ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K

Anshuman Khandual writes: > [ text/plain ] > This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig. > It also implements a new function 'pte_huge' which is required by > function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K > specific functions

Re: [RFC 4/9] powerpc/mm: Split huge_pte_alloc function for BOOK3S 64K

Anshuman Khandual writes: > [ text/plain ] > From: root > > Currently the 'huge_pte_alloc' function has two versions, one for the > BOOK3S and the other one for the BOOK3E platforms. This change splits > the BOOK3S version

Re: [PATCH v2] powerpc: mm: fixup preempt undefflow with huge pages

Sebastian Andrzej Siewior writes: > [ text/plain ] > hugepd_free() used __get_cpu_var() once. Nothing ensured that the code > accessing the variable did not migrate from one CPU to another and soon > this was noticed by Tiejun Chen in 94b09d755462 ("powerpc/hugetlb: >

[PATCH 2/2] ppc64le live patch: get rid of mini stack frame

After the mini stack frame is no longer required for TOC storage, it can be eliminated iff the functionality of klp_return_helper, which required a stack frame for the extra return address previously, is carried out by the replacement function now. This requires _every_ live patch replacement

[PATCH 1/2] ppc64le live patch: clear out storage location(s) in mini stack frame

This can be applied on top of Petr Mladek's v4 rework of the ppc64le live patching. Inspired by Balbir Singh's v5, information about the callee's r2 is stored in a "reserved" 32 bit location in the caller's stack frame, instead of 64 bits in the newly created mini frame 24(r1). It only needs to

Re: [v5][PATCH] livepatch/ppc: Enable livepatching on powerpc

On Wed, Mar 09, 2016 at 05:10:25PM +0100, Petr Mladek wrote: > On Tue 2016-03-08 16:34:35, Torsten Duwe wrote: > > /* compile using "-ffixed-r14"! */ > > register unsigned long pass_TOC asm("r14"); > > BTW: Is this reentrant, please? I mean, is it possible to use this > hack for two functions?

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

Hi Vaibhav, Le 09/03/2016 15:37, Vaibhav Jain a écrit : I would propose these two apis. /* * fetches an event from the driver event queue. NULL means that queue * is empty. Can sleep if needed. The memory for cxl_event is allocated * by module being called. Hence it can be potentially be

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

> On Mar 9, 2016, at 8:37 AM, Vaibhav Jain wrote: >> +/* >> + * AFU driver ops allows an AFU driver to create their own events to pass to >> + * userspace through the file descriptor as a simpler alternative to >> overriding >> + * the read() and poll() calls that

Re: [v5][PATCH] livepatch/ppc: Enable livepatching on powerpc

On Tue 2016-03-08 16:34:35, Torsten Duwe wrote: > On Wed, Mar 09, 2016 at 12:52:03AM +1100, Balbir Singh wrote: > > > > On 08/03/16 21:45, Torsten Duwe wrote: > > > To be fair, my last mail still was not 100% correct, but the conclusion > > Wrote a correction to the correction. It should be

Re: [PATCH] dmaengine:fsldma: fix memory leak

On Tue, Mar 08, 2016 at 02:02:01PM +0800, xuelin@nxp.com wrote: > From: Xuelin Shi > > adding unmap of sources and destinations while doing dequeue. Applied, thanks -- ~Vinod ___ Linuxppc-dev mailing list

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

Hi Ian, Sorry for getting into this discussion late. I have few suggestions. Ian Munsie writes: > > diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig > index 8756d06..560412c 100644 > --- a/drivers/misc/cxl/Kconfig > +++ b/drivers/misc/cxl/Kconfig > @@ -15,12

Re: [v6,12/20] cxl: Add guest-specific code

Le 09/03/2016 13:42, Michael Ellerman a écrit : I've applied the following patch, let me know if there's anything wrong with it. It would be great if we could do something cleaner. I think this is fine. I've built pseries_le_defconfig and powernv_defconfig, and did minimum of testing with

[PATCH] livepatch: Add some basic LivePatch documentation

LivePatch framework deserves some documentation, definitely. This is an attempt to provide some basic info. I hope that it will be useful for both LivePatch producers and also potential developers of the framework itself. Signed-off-by: Petr Mladek --- This patch was motivated

Re: [v6,12/20] cxl: Add guest-specific code

On Wed, 2016-03-09 at 23:42 +1100, Michael Ellerman wrote: > On Fri, 2016-04-03 at 11:26:36 UTC, Frederic Barrat wrote: > > From: Christophe Lombard > > diff --git a/drivers/misc/cxl/Makefile b/drivers/misc/cxl/Makefile > > index be2ac5c..a3d4bef 100644 > > ---

Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

On Wed 2016-03-09 12:16:47, Torsten Duwe wrote: > On Wed, Mar 09, 2016 at 11:13:05AM +0100, Jiri Kosina wrote: > > On Wed, 9 Mar 2016, Torsten Duwe wrote: > > > was my first choice. Arguments on the stack? I thought we'll deal with > > > them > > > once we get there (e.g. _really_ need to patch a

Re: [v2] powerpc/eeh: Remove duplicated check in eeh_dump_pe_log()

On Fri, 2016-26-02 at 00:14:00 UTC, Gavin Shan wrote: > When eeh_dump_pe_log() is only called by eeh_slot_error_detail(), > we already have the check that the PE isn't in PCI config blocked > state in eeh_slot_error_detail(). So we needn't the duplicated > check in eeh_dump_pe_log(). > > This

Re: powerpc/eeh: eeh_pci_enable(): fix checking of post-request state

On Fri, 2015-23-10 at 06:19:46 UTC, Andrew Donnellan wrote: > In eeh_pci_enable(), after making the request to set the new options, we > call eeh_ops->wait_state() to check that the request finished successfully. > > At the moment, if eeh_ops->wait_state() returns 0, we return 0 without >

Re: [v2,3/4] powerpc/eeh: Reworked eeh_pe_bus_get()

On Tue, 2016-09-02 at 04:50:23 UTC, Gavin Shan wrote: > The original implementation is ugly: unnecessary if statements and > "out" tag. This reworks the function to avoid above weaknesses. No > functional changes introduced. > > Signed-off-by: Gavin Shan > Reviewed-by:

Re: [v15,01/12] PCI/IOV: Rename and export virtfn_{add, remove}

On Thu, 2016-03-03 at 23:53:03 UTC, Gavin Shan wrote: > From: Wei Yang > > During EEH recovery, hotplug is applied to the devices which don't > have drivers or their drivers don't support EEH. However, the hotplug, > which was implemented based on PCI bus, can't be

Re: [v6,12/20] cxl: Add guest-specific code

On Fri, 2016-04-03 at 11:26:36 UTC, Frederic Barrat wrote: > From: Christophe Lombard > > The new of.c file contains code to parse the device tree to find out > about cxl adapters and AFUs. > > guest.c implements the guest-specific callbacks for the backend API. >

[RFC 9/9] selfttest/powerpc: Add memory page migration tests

This adds two tests for memory page migration. One for normal page migration which works for both 4K or 64K base page size kernel and the other one is for huge page migration which works only on 64K base page sized 16MB huge page implemention at the PMD level. Signed-off-by: Anshuman Khandual

[RFC 8/9] powerpc/mm: Enable HugeTLB page migration

This change enables HugeTLB page migration for PPC64_BOOK3S systems for HugeTLB pages implemented at the PMD level. It enables the kernel configuration option ARCH_ENABLE_HUGEPAGE_MIGRATION which turns on 'hugepage_migration_supported' function which is checked for feature presence during

[RFC 7/9] powerpc/hugetlb: Change follow_huge_* routines for BOOK3S 64K

With this change, BOOK3S 64K platforms will not use 'follow_huge_addr' function any more and always return ERR_PTR(-ENIVAL), hence skipping the BUG_ON(flags & FOLL_GET) test in 'follow_page_mask' function. These platforms will then fall back on generic follow_huge_* functions for everything else.

[RFC 3/9] mm/gup: Make follow_page_mask function PGD implementation aware

Currently the function 'follow_page_mask' does not take into account PGD based huge page implementation. This change achieves that and makes it complete. Signed-off-by: Anshuman Khandual --- mm/gup.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/gup.c

[RFC 6/9] powerpc/hugetlb: Enable ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K

This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig. It also implements a new function 'pte_huge' which is required by function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K specific functions 'huge_pte_alloc' and 'huge_pte_offset' (which are no longer required) are removed

[RFC 1/9] mm/hugetlb: Make GENERAL_HUGETLB functions PGD implementation aware

Currently both the ARCH_WANT_GENERAL_HUGETLB functions 'huge_pte_alloc' and 'huge_pte_offset' dont take into account huge page implementation at the PGD level. With addition of PGD awareness into these functions, more architectures like POWER which also implements huge pages at PGD level (along

[RFC 5/9] powerpc/mm: Split huge_pte_offset function for BOOK3S 64K

Currently the 'huge_pte_offset' function has only one version for all the configuations and platforms. This change splits the function into two versions, one for 64K page size based BOOK3S implementation and the other one for everything else. This change is also one of the prerequisites towards

[RFC 2/9] mm/hugetlb: Add follow_huge_pgd function

This just adds 'follow_huge_pgd' function which is will be used later in this series to make 'follow_page_mask' function aware of PGD based huge page implementation. Signed-off-by: Anshuman Khandual --- include/linux/hugetlb.h | 3 +++ mm/hugetlb.c| 10

[RFC 4/9] powerpc/mm: Split huge_pte_alloc function for BOOK3S 64K

From: root Currently the 'huge_pte_alloc' function has two versions, one for the BOOK3S and the other one for the BOOK3E platforms. This change splits the BOOK3S version into two parts, one for the 4K page size based implementation and the other one for

[PATCH] cxl: Remove dead code

Function cxl_get_phys_dev() was removed from the kernel API by a previous patch, but it's actually dead code. Remove it. Signed-off-by: Frederic Barrat --- drivers/misc/cxl/api.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/misc/cxl/api.c

Re: [v6,20/20] cxl: Remove cxl_get_phys_dev() kernel API

Le 09/03/2016 12:09, Michael Ellerman a écrit : This appears to make cxl_get_phys_dev() completely unused, doesn't it? If so, please send me a follow-up patch to remove it entirely. I would have sworn there was one internal call to it, but I was confused by some older version. Follow-up

[PATCH v2] dts/fsl/powerpc: add "jedec, spi-nor" flash compatible binding

From: Hou Zhiqiang Starting with commit <8947e396a829> ("Documentation: dt: mtd: replace "nor-jedec" binding with "jedec, spi-nor"") we have "jedec,spi-nor" binding indicating support for JEDEC identification. Use it for all flashes that are supposed to support READ

Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

On Wed, Mar 09, 2016 at 11:13:05AM +0100, Jiri Kosina wrote: > On Wed, 9 Mar 2016, Torsten Duwe wrote: > > was my first choice. Arguments on the stack? I thought we'll deal with them > > once we get there (e.g. _really_ need to patch a varargs function or one > > with a silly signature). > >

Re: [v6,20/20] cxl: Remove cxl_get_phys_dev() kernel API

On Fri, 2016-04-03 at 11:26:44 UTC, Frederic Barrat wrote: > The cxl_get_phys_dev() API returns a struct device pointer which could > belong to either a struct pci_dev (bare-metal) or platform_device > (powerVM). To avoid potential problems in drivers, remove that API. It > was introduced to allow

[v6, 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl

Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common header file. It has been used for mpc85xx and it will be used for ARM-based SoC as well. Signed-off-by: Yangbo Lu --- Changes for v2: - None Changes for v3: - None Changes for v4: -

[v6, 1/5] ARM64: dts: ls2080a: add device configuration node

Add the dts node for device configuration unit that provides general purpose configuration and status for the device. Signed-off-by: Yangbo Lu --- Changes for v2: - None Changes for v3: - None Changes for v4: - None Changes for v5: - Added this

[v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0

The eSDHC of T4240-R1.0-R2.0 has incorrect vender version and spec version. Acturally the right version numbers should be VVN=0x13 and SVN = 0x1. This patch adds the GUTS driver support for eSDHC driver to get SVR(System version register). And fix host version to avoid that incorrect version

[v6, 2/5] soc: fsl: add GUTS driver for QorIQ platforms

The global utilities block controls power management, I/O device enabling, power-onreset(POR) configuration monitoring, alternate function selection for multiplexed signals,and clock control. This patch adds GUTS driver to manage and access global utilities block. Signed-off-by: Yangbo Lu

[v6, 0/5] Fix eSDHC host version register bug

This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0 eSDHC controller. To get the SoC version and revision, it's needed to add the GUTS driver to access the global utilities registers. So, the first three patches are to add the GUTS driver. The following two patches are

[v6, 3/5] dt: move guts devicetree doc out of powerpc directory

Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/ since it's used by not only PowerPC but also ARM. And add a specification for 'little-endian' property. Signed-off-by: Yangbo Lu --- Changes for v2: - None Changes for v3: - None Changes for

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

On Wed, Mar 09, 2016 at 12:38:18AM -0600, Scott Wood wrote: > On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > > The mtmsr() function hangs during restart. Make reboot works on > > MVME5100 removing that function call. > > --- > >

Re: [v6,12/20] cxl: Add guest-specific code

On Wed, 2016-03-09 at 10:14 +0100, Frederic Barrat wrote: > Hi Michael, > > Le 09/03/2016 06:55, Michael Ellerman a écrit : > > This breaks the SMP=n build: > > Arg! I'm adding it to my checklist. Don't worry about it too much. It's pretty obscure, and I have an automated test for it. We've

Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

On Wed, 2016-03-09 at 11:03 +0100, Torsten Duwe wrote: > On Wed, Mar 09, 2016 at 10:44:23AM +0100, Petr Mladek wrote: > > find a solution that would work transparently. I mean that adding > > an extra hacks into selected functions in the patch might be quite > > error prone and problems hard to

Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

On Wed, 9 Mar 2016, Torsten Duwe wrote: > > find a solution that would work transparently. I mean that adding > > an extra hacks into selected functions in the patch might be quite > > error prone and problems hard to debug. I think that we all want this > > but I wanted to be sure :-) > > Full

Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

On Wed, Mar 09, 2016 at 10:44:23AM +0100, Petr Mladek wrote: > find a solution that would work transparently. I mean that adding > an extra hacks into selected functions in the patch might be quite > error prone and problems hard to debug. I think that we all want this > but I wanted to be sure

[PATCH kernel 09/10] powerpc/powernv/ioda2: Export some helpers

We are going to support VFIO on NPU PHB type which will share some code with the normal IODA2 PHB. This exports pnv_pci_ioda2_create_table and pnv_pci_ioda2_get_table_size. This exports debugging helper pe_level_printk() as well. Signed-off-by: Alexey Kardashevskiy ---

Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

On Wed 2016-03-09 10:19:04, Torsten Duwe wrote: > On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote: > > > > The previous revision was nacked by Torsten, but compared to the > > alternatives > > I nacked it because I was confident it couldn't work. Same goes > for this one, sorry. My

Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver specific events

Hi Ian, Le 08/03/2016 02:48, Ian Munsie a écrit : diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c ... +static inline bool ctx_event_pending(struct cxl_context *ctx) +{ + if (ctx->pending_irq || ctx->pending_fault || ctx->pending_afu_err) + return true; + +

Re: [PATCH kernel 9/9] KVM: PPC: VFIO device: support SPAPR TCE

On 03/09/2016 04:45 PM, David Gibson wrote: On Mon, Mar 07, 2016 at 02:41:17PM +1100, Alexey Kardashevskiy wrote: sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap via hypercalls which take a logical bus id (LIOBN) as a target IOMMU identifier. LIOBNs are made up, advertised to

Re: [PATCH][v6][RFC] livepatch/ppc: Enable livepatching on powerpc

On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote: > > The previous revision was nacked by Torsten, but compared to the alternatives I nacked it because I was confident it couldn't work. Same goes for this one, sorry. My good intention was to save us all some work. > @@ -1265,6

Re: [v6,12/20] cxl: Add guest-specific code

Hi Michael, Le 09/03/2016 06:55, Michael Ellerman a écrit : This breaks the SMP=n build: Arg! I'm adding it to my checklist. Thanks for the fix. Fred I've fixed it up with: diff --git a/drivers/misc/cxl/hcalls.c b/drivers/misc/cxl/hcalls.c index f01d4c012620..d6d11f4056d7 100644 ---

Re: [PATCH kernel 3/9] KVM: PPC: Use preregistered memory API to access TCE list

On 03/08/2016 05:30 PM, David Gibson wrote: On Tue, Mar 08, 2016 at 04:47:20PM +1100, Alexey Kardashevskiy wrote: On 03/07/2016 05:00 PM, David Gibson wrote: On Mon, Mar 07, 2016 at 02:41:11PM +1100, Alexey Kardashevskiy wrote: VFIO on sPAPR already implements guest memory pre-registration

Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100

Hi Scott, On 9 March 2016 at 07:38, Scott Wood wrote: > On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: >> The mtmsr() function hangs during restart. Make reboot works on >> MVME5100 removing that function call. [...] > Do you know why MSR_IP was there to

Re: [PATCH kernel 8/9] KVM: PPC: Add in-kernel handling for VFIO

On 03/08/2016 10:08 PM, David Gibson wrote: On Mon, Mar 07, 2016 at 02:41:16PM +1100, Alexey Kardashevskiy wrote: This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT and H_STUFF_TCE requests targeted an IOMMU TCE table used for VFIO without passing them to user space which saves