Re: [PATCH] powerpc: process.c: fix Kconfig typo

Cyril Bur writes: > On Wed, 2016-10-05 at 07:57 +0200, Valentin Rothberg wrote: >> s/ALIVEC/ALTIVEC/ >> > > Oops, nice catch > >> Signed-off-by: Valentin Rothberg > > Reviewed-by: Cyril Bur How did we not notice? Sounds like

[PATCH v3 2/2] PCI: Disable VF's memory space on updating IOV BAR in pci_update_resource()

pci_update_resource() might be called to update (shift) IOV BARs in PPC PowerNV specific pcibios_sriov_enable() when enabling PF's SRIOV capability. At that point, the PF have been functional if the SRIOV is enabled through sysfs entry "sriov_numvfs". The PF's memory decoding (0x2 in PCI_COMMAND)

[PATCH v3 0/2] Disable VF's memory space on updating IOV BARs

This moves pcibios_sriov_enable() to the point before VF and VF BARs are enabled on PowerNV platform. Also, pci_update_resource() is used to update IOV BARs on PowerNV platform, the PF might have been functional when the function is called. We shouldn't disable PF's memory decoding at that point.

[PATCH v3 1/2] PCI: Call pcibios_sriov_enable() before IOV BARs are enabled

In current implementation, pcibios_sriov_enable() is used by PPC PowerNV platform only. In PowerNV specific pcibios_sriov_enable(), PF's IOV BARs might be updated (shifted) by pci_update_resource(). It means the IOV BARs aren't ready for decoding incoming memory address until

Re: [PATCH v2 2/2] PCI: Don't disable PF's memory decoding when enabling SRIOV

On Mon, Oct 24, 2016 at 10:51:13PM -0500, Bjorn Helgaas wrote: >On Tue, Oct 25, 2016 at 12:47:28PM +1100, Gavin Shan wrote: >> On Mon, Oct 24, 2016 at 09:03:16AM -0500, Bjorn Helgaas wrote: >> >On Mon, Oct 24, 2016 at 10:28:02AM +1100, Gavin Shan wrote: >> >> On Fri, Oct 21, 2016 at 11:50:34AM

Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific

On Wed, Oct 26, 2016 at 09:34:18AM +1100, Balbir Singh wrote: I still believe we need your changes, I was wondering if we've tested it against normal memory nodes and checked if any memblock allocations end up there. Michael showed me some memblock allocations on node 1 of a two node machine

[PATCH net-next] ibmveth: v1 calculate correct gso_size and set gso_type

We recently encountered a bug where a few customers using ibmveth on the same LPAR hit an issue where a TCP session hung when large receive was enabled. Closer analysis revealed that the session was stuck because the one side was advertising a zero window repeatedly. We narrowed this down to

Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific

On 26/10/16 02:55, Reza Arbab wrote: > On Tue, Oct 25, 2016 at 11:15:40PM +1100, Balbir Singh wrote: >> After the ack, I realized there were some more checks needed, IOW >> questions for you :) > > Hey! No takebacks! > I still believe we need your changes, I was wondering if we've tested it

Re: [PATCH V6 7/8] powerpc: Check arch.vec earlier during boot for memory features

: > On 09/21/2016 09:17 AM, Michael Bringmann wrote: >> architecture.vec5 features: The boot-time memory management needs to >> know the form of the "ibm,dynamic-memory-v2" property early during >> scanning of the flattened device tree. This patch moves execution of >> the function

Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific

On 26/10/16 02:55, Reza Arbab wrote: > On Tue, Oct 25, 2016 at 11:15:40PM +1100, Balbir Singh wrote: >> After the ack, I realized there were some more checks needed, IOW >> questions for you :) > > Hey! No takebacks! > I still believe we need your changes, I was wondering if we've tested it

[net-next PATCH 18/27] arch/powerpc: Add option to skip DMA sync as a part of mapping

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to avoid invoking cache line invalidation if the driver will just handle it via a sync_for_cpu or sync_for_device call. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael

[PATCH V8 0/8] powerpc/devtree: Add support for 2 new DRC properties

Several properties in the DRC device tree format are replaced by more compact representations to allow, for example, for the encoding of vast amounts of memory, and or reduced duplication of information in related data structures. "ibm,drc-info": This property, when present, replaces the

Re: [PATCH net-next] ibmveth: calculate correct gso_size and set gso_type

>> + u16 hdr_len = ETH_HLEN + sizeof(struct tcphdr); > Compiler may optmize this, but maybe move hdr_len to [*] ?> There are other places in the stack where a u16 is used for the same purpose. So I'll rather stick to that convention. I'll make the other formatting changes you suggested and

[PATCHv2 7/7] mm: kill arch_mremap

This reverts commit 4abad2ca4a4d ("mm: new arch_remap() hook") and commit 2ae416b142b6 ("mm: new mm hook framework"). It also keeps the same functionality of mremapping vDSO blob with introducing vm_special_mapping mremap op for powerpc. Cc: Laurent Dufour Cc:

unsubscribe

unsubscribe

Re: [PATCH] powerpc: Use pr_warn instead of pr_warning

On 10/24/2016 09:00 PM, Joe Perches wrote: > At some point, pr_warning will be removed so all logging messages use > a consistent _warn style. > > Update arch/powerpc/ > arch/powerpc/platforms/ps3/device-init.c| 12 +--- > arch/powerpc/platforms/ps3/mm.c | 4

Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific

On Tue, Oct 25, 2016 at 11:15:40PM +1100, Balbir Singh wrote: After the ack, I realized there were some more checks needed, IOW questions for you :) Hey! No takebacks! The short answer is that neither of these is a concern. Longer; if you use "movable_node", x86 can identify these nodes at

[PATCH 4/7] powerpc/vdso: introduce init_vdso{32,64}_pagelist

Common code with allocation/initialization of vDSO's pagelist. Impact: cleanup Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski Cc: Oleg Nesterov Cc:

[PATCH 3/7] powerpc/vdso: separate common code in vdso_common

Impact: cleanup I also switched usage of printk(KERNEL_,...) on pr_(...) and used pr_fmt() macro for "vDSO{32,64}: " prefix. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski

[PATCH 7/7] mm: kill arch_mremap

This reverts commit 4abad2ca4a4d ("mm: new arch_remap() hook") and commit 2ae416b142b6 ("mm: new mm hook framework"). It also keeps the same functionality of mremapping vDSO blob with introducing vm_special_mapping mremap op for powerpc. Cc: Laurent Dufour Cc:

[PATCH 6/7] powerpc/vdso: switch from legacy_special_mapping_vmops

This will allow to introduce mremap hook (the next patch). Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski Cc: Oleg Nesterov Cc:

[PATCH 5/7] powerpc/vdso: split map_vdso from arch_setup_additional_pages

I'll be easier to introduce vm_special_mapping struct in a smaller map_vdso() function (see the next patches). Impact: cleanup Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski

[PATCH 2/7] powerpc/vdso: remove unused params in vdso_do_func_patch{32, 64}

Impact: cleanup Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski Cc: Oleg Nesterov Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@kvack.org

[PATCH 1/7] powerpc/vdso: unify return paths in setup_additional_pages

Impact: cleanup Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Andy Lutomirski Cc: Oleg Nesterov Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@kvack.org

[PATCH 0/7] powerpc/mm: refactor vDSO mapping code

Cleanup patches for vDSO on powerpc. Originally, I wanted to add vDSO remapping on arm/aarch64 and I decided to cleanup that part on powerpc. I've add a hook for vm_ops for vDSO just like I did for x86. Other changes - reduce exhaustive code duplication. No visible to userspace changes expected.

Re: [Patch v5 04/12] irqchip: xilinx: Add support for parent intc

On 25/10/16 15:44, Sören Brinkmann wrote: > On Tue, 2016-10-25 at 12:49:33 +0200, Thomas Gleixner wrote: >> On Tue, 25 Oct 2016, Zubair Lutfullah Kakakhel wrote: >>> On 10/21/2016 10:48 AM, Marc Zyngier wrote: Shouldn't you return an error if irq is zero? >>> >>> I'll add the following

Re: [Patch v5 04/12] irqchip: xilinx: Add support for parent intc

On Tue, 2016-10-25 at 12:49:33 +0200, Thomas Gleixner wrote: > On Tue, 25 Oct 2016, Zubair Lutfullah Kakakhel wrote: > > On 10/21/2016 10:48 AM, Marc Zyngier wrote: > > > Shouldn't you return an error if irq is zero? > > > > > > > I'll add the following for the error case > > > >

Re: [PATCH] powerpc/pseries: fix spelling mistake: "Attemping" -> "Attempting"

On 10/24/2016 05:02 PM, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake in pr_debug message > > Signed-off-by: Colin Ian King Reviewed-by: Nathan Fontenot > --- >

Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific

On 11/10/16 23:26, Balbir Singh wrote: > > > On 07/10/16 05:36, Reza Arbab wrote: >> Currently, CONFIG_MOVABLE_NODE depends on X86_64. In preparation to >> enable it for other arches, we need to factor a detail which is unique >> to x86 out of the generic mm code. >> >> Specifically, as

Re: [PATCH 2/2] powerpc/64: Fix race condition in setting lock bit in idle/wakeup code

Hi Paul, On Fri, Oct 21, 2016 at 08:04:17PM +1100, Paul Mackerras wrote: > This fixes a race condition where one thread that is entering or > leaving a power-saving state can inadvertently ignore the lock bit > that was set by another thread, and potentially also clear it. > The

Re: [Patch v5 04/12] irqchip: xilinx: Add support for parent intc

On Tue, 25 Oct 2016, Zubair Lutfullah Kakakhel wrote: > On 10/21/2016 10:48 AM, Marc Zyngier wrote: > > Shouldn't you return an error if irq is zero? > > > > I'll add the following for the error case > > pr_err("%s: Parent exists but interrupts property not defined\n" , > __func__);

Re: [PATCH net-next] ibmveth: calculate correct gso_size and set gso_type

On Tue, Oct 25, 2016 at 04:13:41PM +1100, Jon Maxwell wrote: > We recently encountered a bug where a few customers using ibmveth on the > same LPAR hit an issue where a TCP session hung when large receive was > enabled. Closer analysis revealed that the session was stuck because the > one side

Re: [PATCH 1/2] powerpc/64: Re-fix race condition between going idle and entering guest

Hi Paul, [Added Shreyas's current e-mail address ] On Fri, Oct 21, 2016 at 08:03:05PM +1100, Paul Mackerras wrote: > Commit 8117ac6a6c2f ("powerpc/powernv: Switch off MMU before entering > nap/sleep/rvwinkle mode", 2014-12-10) fixed a race condition where one > thread entering a KVM guest could

Re: [Patch v5 04/12] irqchip: xilinx: Add support for parent intc

Hi, Thanks for the review. Some comments in-line. On 10/21/2016 10:48 AM, Marc Zyngier wrote: On 17/10/16 17:52, Zubair Lutfullah Kakakhel wrote: The MIPS based xilfpga platform has the following IRQ structure Peripherals --> xilinx_intcontroller -> mips_cpu_int controller Add support for

Re: [PATCH v4 3/5] powerpc/mm: allow memory hotplug into a memoryless node

Balbir Singh writes: > FYI, these checks were temporary to begin with > > I found this in git history > > b226e462124522f2f23153daff31c311729dfa2f (powerpc: don't add memory to empty > node/zone) Nice thanks for digging it up. commit

[GIT PULL v2 0/5] cpu_relax: drop lowlatency, introduce yield

Peter, here is v2 with some improved patch descriptions and some fixes. The previous version has survived one day of linux-next and I only changed small parts. So unless there is some other issue, feel free to pull (or to apply the patches) to tip/locking. The following changes since commit

[GIT PULL v2 1/5] processor.h: introduce cpu_relax_yield

For spinning loops people do often use barrier() or cpu_relax(). For most architectures cpu_relax and barrier are the same, but on some architectures cpu_relax can add some latency. For example on power,sparc64 and arc, cpu_relax can shift the CPU towards other hardware threads in an SMT

[GIT PULL v2 5/5] processor.h: remove cpu_relax_lowlatency

As there are no users left, we can remove cpu_relax_lowlatency. Signed-off-by: Christian Borntraeger --- arch/alpha/include/asm/processor.h | 1 - arch/arc/include/asm/processor.h| 2 -- arch/arm/include/asm/processor.h| 1 -

[GIT PULL v2 3/5] s390: make cpu_relax a barrier again

stop_machine seemed to be the only important place for yielding during cpu_relax. This was fixed by using cpu_relax_yield. Therefore, we can now redefine cpu_relax to be a barrier instead on s390, making s390 identical to all other architectures. Signed-off-by: Christian Borntraeger

[GIT PULL v2 2/5] stop_machine: yield CPU during stop machine

Some time ago commit 57f2ffe14fd125c2 ("s390: remove diag 44 calls from cpu_relax()") did stop cpu_relax on s390 yielding to the hypervisor. As it turns out this made stop_machine run really slow on virtualized overcommited systems. For example the kprobes test during bootup took several seconds

[GIT PULL v2 4/5] processor.h: Remove cpu_relax_lowlatency users

With the s390 special case of a yielding cpu_relax implementation gone, we can now remove all users of cpu_relax_lowlatency and replace them with cpu_relax. Signed-off-by: Christian Borntraeger --- drivers/gpu/drm/i915/i915_gem_request.c | 2 +- drivers/vhost/net.c

Re: [PATCH v3 02/16] scsi: don't use fc_bsg_job::request and fc_bsg_job::reply directly

On Fri, Oct 14, 2016 at 09:38:21AM +0200, Johannes Thumshirn wrote: > On Thu, Oct 13, 2016 at 05:55:11PM +0200, Steffen Maier wrote: > > Hm, still behaves for me like I reported for v2: > > http://marc.info/?l=linux-scsi=147637177902937=2 > > Hi Steffen, > > Can you please try the following on