On Mon, Jul 2, 2018 at 10:21 AM Finn Thain wrote:
> Don't load the via-pmu68k driver on early PowerBooks. The M50753 PMU
> device found in those models was never supported by this driver.
> Attempting to load the driver usually causes a boot hang.
>
> Cc: Geert Uytterhoeven
> Signed-off-by: Finn
On Mon, Jul 2, 2018 at 10:21 AM Finn Thain wrote:
> Now that the PowerMac via-pmu driver supports m68k PowerBooks,
> switch over to that driver and remove the via-pmu68k driver.
>
> Cc: Geert Uytterhoeven
> Tested-by: Stan Johnson
> Signed-off-by: Finn Thain
Acked-by: Geert Uytterhoeven
Gr{o
On Mon, Jul 30, 2018 at 9:26 AM Geert Uytterhoeven wrote:
> On Mon, Jul 2, 2018 at 10:21 AM Finn Thain wrote:
> > Now that the PowerMac via-pmu driver supports m68k PowerBooks,
> > switch over to that driver and remove the via-pmu68k driver.
> >
> > Cc: Geert Uytterhoeven
> > Tested-by: Stan Joh
Hi Michael,
On Mon, Jul 30, 2018 at 8:47 AM Michael Ellerman wrote:
> Finn Thain writes:
> > Now that the PowerMac via-pmu driver supports m68k PowerBooks,
> > switch over to that driver and remove the via-pmu68k driver.
> >
> > Cc: Geert Uytterhoeven
> > Tested-by: Stan Johnson
> > Signed-off
There is nothing arch specific about PCI or dma-debug, so move this
call to common code just after registering the bus type.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/dma.c | 3 ---
arch/sh/drivers/pci/pci.c | 2 --
arch/x86/kernel/pci-dma.c | 3 ---
drivers/pci/pci-driver.c | 2
kernel/dma/Kconfig already defines NEED_DMA_MAP_STATE, just select it
from PPC64 and NOT_COHERENT_CACHE instead.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/Kconfig | 3 ---
arch/powerpc/platforms/Kconfig.cputype | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
d
2018-07-07 23:59 GMT+09:00 Randy Dunlap :
> On 07/07/2018 05:13 AM, Nicholas Piggin wrote:
>> On Fri, 6 Jul 2018 21:58:29 -0700
>> Randy Dunlap wrote:
>>
>>> On 07/06/2018 06:45 PM, Benjamin Herrenschmidt wrote:
On Thu, 2018-07-05 at 14:30 -0700, Randy Dunlap wrote:
> Hi,
>
> Is t
On 11/07/2018 19:26, Alexey Kardashevskiy wrote:
> On Tue, 10 Jul 2018 16:37:15 -0600
> Alex Williamson wrote:
>
>> On Tue, 10 Jul 2018 14:10:20 +1000
>> Alexey Kardashevskiy wrote:
>>
>>> On Thu, 7 Jun 2018 23:03:23 -0600
>>> Alex Williamson wrote:
>>>
On Fri, 8 Jun 2018 14:14:23 +1
On Fri 27-07-18 12:32:59, John Allen wrote:
> On Wed, Jul 25, 2018 at 10:03:36PM +0200, Michal Hocko wrote:
> > On Wed 25-07-18 13:11:15, John Allen wrote:
> > [...]
> > > Does a failure in do_migrate_range indicate that the range is unmigratable
> > > and the loop in __offline_pages should termina
> +/*
> + * Virtio direct mapping DMA API operations structure
> + *
> + * This defines DMA API structure for all virtio devices which would not
> + * either bring in their own DMA OPS from architecture or they would not
> + * like to use architecture specific IOMMU based DMA OPS because QEMU
> + *
> +const struct dma_map_ops virtio_direct_dma_ops;
This belongs into a header if it is non-static. If you only
use it in this file anyway please mark it static and avoid a forward
declaration.
> +
> int virtio_finalize_features(struct virtio_device *dev)
> {
> int ret = dev->config->fina
> > +
> > + if (xen_domain())
> > + goto skip_override;
> > +
> > + if (virtio_has_iommu_quirk(dev))
> > + set_dma_ops(dev->dev.parent, &virtio_direct_dma_ops);
> > +
> > + skip_override:
> > +
>
> I prefer normal if scoping as opposed to goto spaghetti pls.
> Better yet mo
On Fri, Jul 27, 2018 at 10:58:05AM +0100, Will Deacon wrote:
>
> I just wanted to say that this patch series provides a means for us to
> force the coherent DMA ops for legacy virtio devices on arm64, which in turn
> means that we can enable the SMMU with legacy devices in our fastmodel
> emulatio
Dear Michael,
On 07/30/18 08:43, Michael Ellerman wrote:
> Paul Menzel writes:
>> Am 19.07.2018 um 16:33 schrieb Michael Ellerman:
> ...
>>>
>>> The fix is fairly simple. We need to tell kmemleak to ignore PUD
>>> allocations and never report them as leaks. We can also tell it not to
>>> scan th
The ptp_qoriq driver initialized the 1588 timer with the
configurations provided by the properties of device tree
node. For example,
fsl,tclk-period = <5>;
fsl,tmr-prsc= <2>;
fsl,tmr-add = <0xaaab>;
fsl,tmr-fiper1 = <5>;
fsl,tmr-fiper2 = <0>;
fsl,max-adj =
This patch is to add clocks property for fman ptp timer node.
Signed-off-by: Yangbo Lu
---
arch/powerpc/boot/dts/fsl/qoriq-fman-0.dtsi |1 +
arch/powerpc/boot/dts/fsl/qoriq-fman-1.dtsi |1 +
arch/powerpc/boot/dts/fsl/qoriq-fman3-0.dtsi |1 +
arch/powerpc/boot/dts/fsl/qoriq-fman3
This patch is to add clocks property for fman ptp timer node.
Signed-off-by: Yangbo Lu
---
arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi
b/arch/arm64/boot/dts/freescale/q
On Mon, Jul 30, 2018 at 02:34:14AM -0700, Christoph Hellwig wrote:
> We really need to distinguish between legacy virtual crappy
> virtio (and that includes v1) that totally ignores the bus it pretends
> to be on, and sane virtio (to be defined) that sit on a real (or
> properly emulated including
Rob Herring writes:
> On Thu, Jul 26, 2018 at 11:36 PM Michael Ellerman wrote:
>> When the OF code was originally made common by Grant in commit
>> 51975db0b733 ("of/flattree: merge early_init_dt_scan_memory() common
>> code") (Feb 2010), the common code inherited a hack to handle
>> PPC "longtra
On Mon, Jul 30, 2018 at 01:28:03PM +0300, Michael S. Tsirkin wrote:
> Let me reply to the "crappy" part first:
> So virtio devices can run on another CPU or on a PCI bus. Configuration
> can happen over mupltiple transports. There is a discovery protocol to
> figure out where it is. It has some wa
On Mon, 30 Jul 2018, Christoph Hellwig wrote:
> There is nothing arch specific about PCI or dma-debug, so move this
> call to common code just after registering the bus type.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Thomas Gleixner
We have of_machine_is_compatible() to check if a machine is compatible
with a single compatible string. However some code is able to support
multiple compatible boards, and so wants to check for one of many
compatible strings.
So add of_machine_compatible_match() which takes a NULL terminated
arra
Use of_machine_compatible_match() in platform code rather than open
coding.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/40x/ppc40x_simple.c| 2 +-
arch/powerpc/platforms/512x/mpc512x_generic.c | 2 +-
arch/powerpc/platforms/52xx/lite5200.c| 2 +-
arch/powerpc/platforms
On Mon, Jul 30, 2018 at 04:18:02AM -0700, Christoph Hellwig wrote:
> On Mon, Jul 30, 2018 at 01:28:03PM +0300, Michael S. Tsirkin wrote:
> > Let me reply to the "crappy" part first:
> > So virtio devices can run on another CPU or on a PCI bus. Configuration
> > can happen over mupltiple transports.
Geert Uytterhoeven writes:
> Hi Michael,
>
> On Mon, Jul 30, 2018 at 8:47 AM Michael Ellerman wrote:
>> Finn Thain writes:
>> > Now that the PowerMac via-pmu driver supports m68k PowerBooks,
>> > switch over to that driver and remove the via-pmu68k driver.
>> >
>> > Cc: Geert Uytterhoeven
>> >
Hi Laurent,
Just one comment below.
Laurent Dufour writes:
> diff --git a/arch/powerpc/platforms/pseries/lpar.c
> b/arch/powerpc/platforms/pseries/lpar.c
> index 96b8cd8a802d..41ed03245eb4 100644
> --- a/arch/powerpc/platforms/pseries/lpar.c
> +++ b/arch/powerpc/platforms/pseries/lpar.c
> @@ -4
On Mon, Jul 30, 2018 at 7:15 AM Michael Ellerman wrote:
>
> We have of_machine_is_compatible() to check if a machine is compatible
> with a single compatible string. However some code is able to support
> multiple compatible boards, and so wants to check for one of many
> compatible strings.
>
> S
On Mon, Jul 30, 2018 at 7:15 AM Michael Ellerman wrote:
>
> Use of_machine_compatible_match() in platform code rather than open
> coding.
This is good because I want to get rid of of_root being used outside
of drivers/of/. Can you also convert this one:
drivers/clk/clk-qoriq.c:of_dev
Laurent Dufour writes:
> This feature tells if the hcall H_BLOCK_REMOVE is available.
>
> Cc: "Aneesh Kumar K.V"
> Cc: Nicholas Piggin
> Cc: Michael Ellerman
> Cc: Paul Mackerras
> Cc: Benjamin Herrenschmidt
> Signed-off-by: Laurent Dufour
Reviewed-by: Aneesh Kumar K.V
> ---
> arch/powe
Laurent Dufour writes:
> This part of code will be called also when dealing with H_BLOCK_REMOVE.
>
> Cc: "Aneesh Kumar K.V"
> Cc: Nicholas Piggin
> Cc: Michael Ellerman
> Cc: Paul Mackerras
> Cc: Benjamin Herrenschmidt
> Signed-off-by: Laurent Dufour
Reviewed-by: Aneesh Kumar K.V
> ---
>
Michael Ellerman writes:
> Hi Laurent,
>
> Just one comment below.
>
> Laurent Dufour writes:
>> diff --git a/arch/powerpc/platforms/pseries/lpar.c
>> b/arch/powerpc/platforms/pseries/lpar.c
>> index 96b8cd8a802d..41ed03245eb4 100644
>> --- a/arch/powerpc/platforms/pseries/lpar.c
>> +++ b/arch/
On Mon, Jul 30, 2018 at 06:01:54PM +0800, Yangbo Lu wrote:
> The ptp_qoriq driver initialized the 1588 timer with the
> configurations provided by the properties of device tree
> node. For example,
>
> fsl,tclk-period = <5>;
> fsl,tmr-prsc= <2>;
> fsl,tmr-add = <0xaaab>;
> fsl,
On 7/29/18 8:59 PM, Sam Bobroff wrote:
> EEH recovery currently fails on pSeries for some IOV capable PCI
> devices, if CONFIG_PCI_IOV is on and the hypervisor doesn't provide
> certain device tree properties for the device. (Found on an IOV
> capable device using the ipr driver.)
>
> Recovery fai
Hi, Christophe.
On Fri, Jul 27, 2018 at 06:40:23PM +0200, LEROY Christophe wrote:
> Murilo Opsfelder Araujo a écrit :
>
> > Simplify the message format by using REG_FMT as the register format. This
> > avoids having two different formats and avoids checking for MSR_64BIT.
>
> Are you sure it is
From: Yangbo Lu
Date: Mon, 30 Jul 2018 18:01:54 +0800
> +static unsigned int cksel = DEFAULT_CKSEL;
> +module_param(cksel, uint, 0644);
> +MODULE_PARM_DESC(cksel, "Select reference clock");
> +
> +static unsigned int clk_src;
> +module_param(clk_src, uint, 0644);
> +MODULE_PARM_DESC(clk_src, "Ref
On Mon, 30 Jul 2018 18:58:49 +1000
Alexey Kardashevskiy wrote:
> On 11/07/2018 19:26, Alexey Kardashevskiy wrote:
> > On Tue, 10 Jul 2018 16:37:15 -0600
> > Alex Williamson wrote:
> >
> >> On Tue, 10 Jul 2018 14:10:20 +1000
> >> Alexey Kardashevskiy wrote:
> >>
> >>> On Thu, 7 Jun 2018 23:
Murilo Opsfelder Araujo a écrit :
Hi, Christophe.
On Fri, Jul 27, 2018 at 06:40:23PM +0200, LEROY Christophe wrote:
Murilo Opsfelder Araujo a écrit :
> Simplify the message format by using REG_FMT as the register format. This
> avoids having two different formats and avoids checking for MS
Hi all,
this series switches the powerpc port to use the generic swiotlb
and noncoherent dma ops, and to use more generic code for the
coherent direct mapping, as well as removing dead code.
We need to take the DMA offset and encryption bit into account when selecting
a zone. Add a helper that takes those into account and use it.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/
When a device has a DMA offset the dma capable result will change due
to the difference between the physical and DMA address. Take that into
account.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/dma/dir
This save some duplication for ia64. In the long run this method will
need some additional work including moving over to kernel/dma, but that
will require some additional prep work, so let's do this minimal change
for now.
Signed-off-by: Christoph Hellwig
---
drivers/base/platform.c | 11 ++
ia64 can use the generic implementation in general, and SN2 can just
override it in the dma_map_ops now.
Signed-off-by: Christoph Hellwig
---
arch/ia64/include/asm/dma-mapping.h | 2 --
arch/ia64/include/asm/machvec.h | 7 ---
arch/ia64/include/asm/machvec_init.h | 1 -
arch/ia64/in
For now this allows consolidating the powerpc code. In the long run
we should grow a generic implementation of dma_get_required_mask that
returns the dma mask required to avoid bounce buffering.
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 4
1 file changed, 4 insertions(+)
This is need for powerpc for now. Hopefully we can come up with a clean
generic implementation mid-term.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-noncoherent.h | 6 ++
kernel/dma/Kconfig | 4
kernel/dma/noncoherent.c| 1 +
3 files changed, 11 insertio
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 8fa394520af6..f2a4a7142b1e 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
++
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/dma.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index dbfc7056d7df..3939589aab04 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -286,7 +286,6 @@ const
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/setup_32.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 74457485574b..3c2d093f74c7 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
The implemementation for the CONFIG_NOT_COHERENT_CACHE case doesn't share
any code with the one for systems with coherent caches. Split it off
and merge it with the helpers in dma-noncoherent.c that have no other
callers.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-mapping
Use the standard portable helper instead of the powerpc specific one,
which is about to go away.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/dma-swiotlb.c | 5 ++---
arch/powerpc/kernel/dma.c | 12 ++--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/
Just fold the calculation into __phys_to_dma/__dma_to_phys as those are
the only places that should know about it.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-direct.h | 8 ++--
arch/powerpc/include/asm/dma-mapping.h | 16
2 files changed, 6 insertion
The requirement to disable local irqs over kmap_atomic is long gone,
so remove those calls.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/mm/dma-noncoherent.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/powerpc/mm/dma-noncoherent.c
b/arch/powerpc/mm/dma-non
The ppc32 case of dma_nommu_dma_supported already was a no-op, and the
64-bit case came to the same conclusion as dma_direct_supported, so
replace it with the generic version.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/dma.c | 28 +++---
These do the same functionality as the existing helpers, but do it
simpler, and also allow the (optional) use of CMA.
Note that the swiotlb code now calls into the dma_direct code directly,
given that it doesn't work with noncoherent caches at all, and isn't called
when we have an iommu either, so
These methods are optional to start with, no need to implement no-op
versions.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/dma.c | 16
1 file changed, 16 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 511a4972560d..2cfc45acbb5
These are identical to the arch specific ones, so remove them.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-direct.h | 4
arch/powerpc/include/asm/swiotlb.h| 2 --
arch/powerpc/kernel/dma-swiotlb.c | 28 ++-
arch/powerpc/sysdev/fsl_pci.
The generic dma-noncoherent code provides all that is needed by powerpc.
Note that the cache maintainance in the existing code is a bit odd
as it implements both the sync_to_device and sync_to_cpu callouts,
but never flushes caches when unmapping. This patch keeps both
directions arounds, which w
These are indentical except for additional error checking, so migrate
to the common code, and wire up the get_mapping_error method as well.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/dma.c | 32
1 file changed, 4 insertions(+), 28 deletions(-)
diff
The remaining implementation for coherent caches is functionally
identical to the default provided in common code.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/dma-mapping.h | 7 ---
arch/powerpc/kernel/dma-iommu.c| 1 -
arch/powerpc/kernel/dma.c | 13
On Mon, Jul 30, 2018 at 4:47 AM Michael Ellerman wrote:
>
> Rob Herring writes:
> > On Thu, Jul 26, 2018 at 11:36 PM Michael Ellerman
> > wrote:
> >> When the OF code was originally made common by Grant in commit
> >> 51975db0b733 ("of/flattree: merge early_init_dt_scan_memory() common
> >> cod
crash when using HW tracing kernel filters (2018-07-25
11:46:22 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tags/perf-urgent-for-mingo-4.18-20180730
for you to fetch changes up to 44fe619b1418ff4e9d2f9518a940fbe2fb686a08:
perf
From: Arnaldo Carvalho de Melo
The new 'io_pgetevents' syscall was wired up in PowerPC in the following
cset:
b2f82565f2ca ("powerpc: Wire up io_pgetevents")
Update tools/arch/powerpc/ copy of the asm/unistd.h file so that 'perf
trace' on PowerPC gets it in its syscall table.
This elliminate
See below.
On 07/30/2018 01:31 AM, Michael Ellerman wrote:
> Michael Bringmann writes:
>
>> During LPAR migration, the content of the device tree/sysfs may
>> be updated including deletion and replacement of nodes in the
>> tree. When nodes are added to the internal node structures, they
>> are
[+cc Joerg]
On Mon, Jul 30, 2018 at 09:38:42AM +0200, Christoph Hellwig wrote:
> There is nothing arch specific about PCI or dma-debug, so move this
> call to common code just after registering the bus type.
I assume that previously, even if the user set CONFIG_DMA_API_DEBUG=y
we only got PCI DMA
On Mon, Jul 30, 2018 at 11:59:14AM +1000, Sam Bobroff wrote:
> EEH recovery currently fails on pSeries for some IOV capable PCI
> devices, if CONFIG_PCI_IOV is on and the hypervisor doesn't provide
> certain device tree properties for the device. (Found on an IOV
> capable device using the ipr driv
I only have this message, and patches 5 and 6. This is meaningless
for me to review - I can't tell what you've done as far as my comments
on your previous iteration.
Please arrange to _at least_ copy all patches the appropriate mailing
lists for the set with your complete patch set if you aren't
Hi, Christophe.
On Mon, Jul 30, 2018 at 06:30:47PM +0200, LEROY Christophe wrote:
> Murilo Opsfelder Araujo a écrit :
>
> > Hi, Christophe.
> >
> > On Fri, Jul 27, 2018 at 06:40:23PM +0200, LEROY Christophe wrote:
> > > Murilo Opsfelder Araujo a écrit :
> > >
> > > > Simplify the message format
The menu entry is now defined in the rapidio subtree. Also, re-order
the bus menu so tha the platform-specific RapidIO controller appears
after the entry for the RapidIO subsystem.
Platforms with a PCI bus will be offered the RapidIO menu since they may
be want support for a RapidIO PCI device. P
The top-level Kconfig entry for RapidIO subsystem is currently
duplicated in several architecture-specific Kconfig files. This set of
patches does two things:
1. Move the Kconfig menu definition into the RapidIO subsystem and
remove the duplicate definitions from arch Kconfig files.
2. Enable Rap
Hi Michael,
On 07/27/2018 02:51 AM, Michael Ellerman wrote:
Gustavo Romero writes:
Hi Michael,
On 07/26/2018 09:24 AM, Michael Ellerman wrote:
These tests are currently failing on (some) big endian systems. Until
we can fix that, skip them unless we're on ppc64le.
I can take a look at thi
On 07/29/2018 06:11 AM, Michael Bringmann wrote:
> During LPAR migration, the content of the device tree/sysfs may
> be updated including deletion and replacement of nodes in the
> tree. When nodes are added to the internal node structures, they
> are appended in FIFO order to a list of nodes main
On 07/30/2018 03:50 PM, Alexei Colin wrote:
> The top-level Kconfig entry for RapidIO subsystem is currently
> duplicated in several architecture-specific Kconfig files. This set of
> patches does two things:
>
> 1. Move the Kconfig menu definition into the RapidIO subsystem and
> remove the dupli
An arbitrary error in ppc4xx_msi_probe() quite likely results in a
crash similar to the following, seen after dma_alloc_coherent()
returned an error.
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc001bff0
Oops: Kernel access of bad area, sig:
On 07/30/2018 05:59 PM, Tyrel Datwyler wrote:
> On 07/29/2018 06:11 AM, Michael Bringmann wrote:
>> During LPAR migration, the content of the device tree/sysfs may
>> be updated including deletion and replacement of nodes in the
>> tree. When nodes are added to the internal node structures, they
>
On Wed, 2018-07-25 at 00:03 +1000, Michael Ellerman wrote:
> This makes it easy to run checkpatch with settings that we have
> agreed
> on (bwhahahahah).
>
> Usage is eg:
>
> $ ./arch/powerpc/tools/checkpatch.sh -g origin/master..
>
> To check all commits since origin/master.
>
> Signed-off-b
On 07/30/2018 02:54 PM, Christoph Hellwig wrote:
>> +/*
>> + * Virtio direct mapping DMA API operations structure
>> + *
>> + * This defines DMA API structure for all virtio devices which would not
>> + * either bring in their own DMA OPS from architecture or they would not
>> + * like to use archi
On 31/07/2018 02:29, Alex Williamson wrote:
> On Mon, 30 Jul 2018 18:58:49 +1000
> Alexey Kardashevskiy wrote:
>
>> On 11/07/2018 19:26, Alexey Kardashevskiy wrote:
>>> On Tue, 10 Jul 2018 16:37:15 -0600
>>> Alex Williamson wrote:
>>>
On Tue, 10 Jul 2018 14:10:20 +1000
Alexey Kar
Currently the alignment_handler test prints "Can't open /dev/fb0"
about 80 times per run, which is a little annoying.
Refactor it to check earlier if it can open /dev/fb0 and skip if not,
this results in each test printing something like:
test: test_alignment_handler_vsx_206
tags: git_version
The alignment_handler is documented to only work on Power8/Power9, but
we can make it run on older CPUs by guarding more of the tests with
feature checks.
Signed-off-by: Michael Ellerman
---
.../powerpc/alignment/alignment_handler.c | 76 +++---
1 file changed, 68 insert
On 31/07/18 14:41, Michael Ellerman wrote:
Currently the alignment_handler test prints "Can't open /dev/fb0"
about 80 times per run, which is a little annoying.
Refactor it to check earlier if it can open /dev/fb0 and skip if not,
this results in each test printing something like:
test: test
following changes since commit 7f635ff187ab6be0b350b3ec06791e376af238ab:
>
> perf/core: Fix crash when using HW tracing kernel filters (2018-07-25
> 11:46:22 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
[CC linux-mm for inclusion in -mm tree]
In order to reduce copy/paste of functions across architectures and then
make riscv hugetlb port (and future ports) simpler and smaller, this
patchset intends to factorize the numerous hugetlb primitives that are
defined across all the architectures.
Excep
asm-generic/hugetlb.h proposes generic implementations of hugetlb
related functions: use __HAVE_ARCH_HUGE* defines in order to make arch
specific implementations of hugetlb functions consistent with pgtable.h
scheme.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm64/includ
arm, arm64, mips, parisc, sh, x86 architectures use the
same version of hugetlb_free_pgd_range, so move this generic
implementation into asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb.h | 9 -
arch/arm64/include/asm/
arm, ia64, mips, powerpc, sh, x86 architectures use the
same version of set_huge_pte_at, so move this generic
implementation into asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb-3level.h | 6 --
arch/arm64/include/asm/hugetlb.
arm, ia64, sh, x86 architectures use the
same version of huge_ptep_get_and_clear, so move this generic
implementation into asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb-3level.h | 6 --
arch/arm64/include/asm/hugetlb.h
arm, x86 architectures use the same version of
huge_ptep_clear_flush, so move this generic implementation into
asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb-3level.h | 6 --
arch/arm64/include/asm/hugetlb.h | 1 +
arch/
arm, arm64, ia64, parisc, powerpc, sh, sparc, x86 architectures
use the same version of huge_pte_none, so move this generic
implementation into asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb.h | 5 -
arch/arm64/include/as
arm, arm64, ia64, mips, parisc, powerpc, sh, sparc, x86
architectures use the same version of huge_pte_wrprotect, so move
this generic implementation into asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb.h | 5 -
arch/arm64
arm, arm64, powerpc, sparc, x86 architectures use the same version of
prepare_hugepage_range, so move this generic implementation into
asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb.h | 11 ---
arch/arm64/include/asm/
arm, ia64, mips, sh, x86 architectures use the same version
of huge_ptep_set_wrprotect, so move this generic implementation into
asm-generic/hugetlb.h.
Note: powerpc uses twice for book3s/32 and nohash/32 the same version as
the above architectures, but the modification was not straightforward
and
arm, ia64, sh, x86 architectures use the same version
of huge_ptep_set_access_flags, so move this generic implementation
into asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb-3level.h | 7 ---
arch/arm64/include/asm/hugetlb.h
ia64, mips, parisc, powerpc, sh, sparc, x86 architectures use the
same version of huge_ptep_get, so move this generic implementation into
asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb-3level.h | 1 +
arch/arm64/include/asm/huget
Hi Rob/Frank,
I think we might have a problem with the phandle_cache not interacting
well with of_detach_node():
Michael Bringmann writes:
> See below.
>
> On 07/30/2018 01:31 AM, Michael Ellerman wrote:
>> Michael Bringmann writes:
>>
>>> During LPAR migration, the content of the device tree/
On 07/30/2018 03:00 PM, Christoph Hellwig wrote:
>>> +
>>> + if (xen_domain())
>>> + goto skip_override;
>>> +
>>> + if (virtio_has_iommu_quirk(dev))
>>> + set_dma_ops(dev->dev.parent, &virtio_direct_dma_ops);
>>> +
>>> + skip_override:
>>> +
>>
>> I prefer normal if scoping
Tyrel Datwyler writes:
> On 07/29/2018 06:11 AM, Michael Bringmann wrote:
>> During LPAR migration, the content of the device tree/sysfs may
>> be updated including deletion and replacement of nodes in the
>> tree. When nodes are added to the internal node structures, they
>> are appended in FIFO
Bjorn Helgaas writes:
> On Mon, Jul 30, 2018 at 11:59:14AM +1000, Sam Bobroff wrote:
>> EEH recovery currently fails on pSeries for some IOV capable PCI
>> devices, if CONFIG_PCI_IOV is on and the hypervisor doesn't provide
>> certain device tree properties for the device. (Found on an IOV
>> capa
96 matches
Mail list logo
