Re: powerpc/mpc5xxx: Use of_get_next_parent to simplify code

[Michael Ellerman]

On Sun, 2015-11-10 at 20:27:40 UTC, Christophe Jaillet wrote:
> of_get_next_parent can be used to simplify the while() loop and
> avoid the need of a temp variable.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  arch/powerpc/sysdev/mpc5xxx_clocks.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/sysdev/mpc5xxx_clocks.c 
> b/arch/powerpc/sysdev/mpc5xxx_clocks.c
> index f4f0301..5732926 100644
> --- a/arch/powerpc/sysdev/mpc5xxx_clocks.c
> +++ b/arch/powerpc/sysdev/mpc5xxx_clocks.c
> @@ -13,7 +13,6 @@
>  
>  unsigned long mpc5xxx_get_bus_frequency(struct device_node *node)
>  {
> - struct device_node *np;
>   const unsigned int *p_bus_freq = NULL;
>  
>   of_node_get(node);
> @@ -22,9 +21,7 @@ unsigned long mpc5xxx_get_bus_frequency(struct device_node 
> *node)
>   if (p_bus_freq)
>   break;
>  
> - np = of_get_parent(node);
> - of_node_put(node);
> - node = np;
> + node = of_get_next_parent(node);
>   }
>   of_node_put(node);


This conversion is OK, but the logic in the function is still wrong.

It uses of_get_property() inside the loop, but then drops the reference to the
node before dereferencing the p_bus_freq pointer, which could by then point to
junk if the node has been freed.

Instead it should use of_property_read_u32() to actually read the property
value before dropping the reference.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/cell: Drop CONFIG_TUNE_CELL in favour of CONFIG_CELL_CPU

[Michael Ellerman]

The TUNE_CELL option allows you to build a kernel that runs on multiple
CPUs but is tuned (ie. optimised) to run on Cell CPUs. Now days no one
is building a distro in that fashion, and any users who are building
custom kernels for their Cell machines are better off building with
CONFIG_CELL_CPU, which builds a kernel that only runs on Cell and
therefore can be optimised even more aggresively.

Dropping the option also avoids confusing other users, who are presented
with an option to tune for Cell when they are not building for a Cell
CPU at all.

Suggested-by: Thomas Huth 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/Makefile  |  2 --
 arch/powerpc/configs/cell_defconfig|  2 +-
 arch/powerpc/configs/ps3_defconfig |  2 +-
 arch/powerpc/platforms/Kconfig.cputype | 11 ---
 4 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index b9b4af2af9a5..1a205c4e5bb8 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -157,8 +157,6 @@ CFLAGS-$(CONFIG_E500) += $(call cc-option,-mcpu=8540 
-msoft-float,-mcpu=powerpc)
 endif
 endif
 
-CFLAGS-$(CONFIG_TUNE_CELL) += $(call cc-option,-mtune=cell)
-
 asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
 
 KBUILD_CPPFLAGS+= -Iarch/$(ARCH) $(asinstr)
diff --git a/arch/powerpc/configs/cell_defconfig 
b/arch/powerpc/configs/cell_defconfig
index 9227b517560a..db328e618bb9 100644
--- a/arch/powerpc/configs/cell_defconfig
+++ b/arch/powerpc/configs/cell_defconfig
@@ -1,5 +1,5 @@
 CONFIG_PPC64=y
-CONFIG_TUNE_CELL=y
+CONFIG_CELL_CPU=y
 CONFIG_ALTIVEC=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=4
diff --git a/arch/powerpc/configs/ps3_defconfig 
b/arch/powerpc/configs/ps3_defconfig
index adc14e813a49..391c2ceab73a 100644
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -1,5 +1,5 @@
 CONFIG_PPC64=y
-CONFIG_TUNE_CELL=y
+CONFIG_CELL_CPU=y
 CONFIG_ALTIVEC=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=2
diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index c140e94c7c72..142dff5e96d6 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -147,17 +147,6 @@ config 6xx
depends on PPC32 && PPC_BOOK3S
select PPC_HAVE_PMU_SUPPORT
 
-config TUNE_CELL
-   bool "Optimize for Cell Broadband Engine"
-   depends on PPC64 && PPC_BOOK3S
-   help
- Cause the compiler to optimize for the PPE of the Cell Broadband
- Engine. This will make the code run considerably faster on Cell
- but somewhat slower on other machines. This option only changes
- the scheduling of instructions, not the selection of instructions
- itself, so the resulting kernel will keep running on all other
- machines.
-
 # this is temp to handle compat with arch=ppc
 config 8xx
bool
-- 
2.1.4

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

Re: [v7,58/60] PCI: Introduce resource_disabled()

[Michael Ellerman]

On Thu, 2015-08-10 at 21:39:17 UTC, Yinghai Lu wrote:
> Current is using !flags, and we are going to use
> IORESOURCE_DISABLED instead of clearing resource flags.
> 
> Let's convert all !flags to helper function resource_disabled().
> resource_disabled will check !flags and IORESOURCE_DISABLED both.
> 
> diff --git a/arch/powerpc/kernel/pci-common.c 
> b/arch/powerpc/kernel/pci-common.c
> index 8853667..a830e0c 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -810,7 +810,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
>   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>   struct resource *res = dev->resource + i;
>   struct pci_bus_region reg;
> - if (!res->flags)
> + if (resource_disabled(res))
>   continue;
>  
>   /* If we're going to re-assign everything, we mark all resources
> @@ -919,7 +919,7 @@ static void pcibios_fixup_bridge(struct pci_bus *bus)
>   struct pci_dev *dev = bus->self;
>  
>   pci_bus_for_each_resource(bus, res, i) {
> - if (!res || !res->flags)
> + if (!res || resource_disabled(res))
>   continue;
>   if (i >= 3 && bus->self->transparent)
>   continue;
> @@ -1160,7 +1160,8 @@ static void pcibios_allocate_bus_resources(struct 
> pci_bus *bus)
>pci_domain_nr(bus), bus->number);
>  
>   pci_bus_for_each_resource(bus, res, i) {
> - if (!res || !res->flags || res->start > res->end || res->parent)
> + if (!res || resource_disabled(res) ||
> + res->start > res->end || res->parent)
>   continue;
>  
>   /* If the resource was left unset at this point, we clear it */
> @@ -1255,7 +1256,8 @@ static void __init pcibios_allocate_resources(int pass)
>   r = >resource[idx];
>   if (r->parent)  /* Already allocated */
>   continue;
> - if (!r->flags || (r->flags & IORESOURCE_UNSET))
> + if (resource_disabled(r) ||
> + (r->flags & IORESOURCE_UNSET))
>   continue;   /* Not assigned at all */
>   /* We only allocate ROMs on pass 1 just in case they
>* have been screwed up by firmware
> @@ -1393,7 +1395,7 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
>   for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>   struct resource *r = >resource[i];
>  
> - if (r->parent || !r->start || !r->flags)
> + if (r->parent || !r->start || resource_disabled(r))
>   continue;
>  
>   pr_debug("PCI: Claiming %s: Resource %d: %pR\n",
> @@ -1474,7 +1476,7 @@ static void pcibios_setup_phb_resources(struct 
> pci_controller *hose,
>   /* Hookup PHB IO resource */
>   res = >io_resource;
>  
> - if (!res->flags) {
> + if (resource_disabled(res)) {
>   pr_info("PCI: I/O resource not set for host"
>  " bridge %s (domain %d)\n",
>  hose->dn->full_name, hose->global_number);
> @@ -1489,7 +1491,7 @@ static void pcibios_setup_phb_resources(struct 
> pci_controller *hose,
>   /* Hookup PHB Memory resources */
>   for (i = 0; i < 3; ++i) {
>   res = >mem_resources[i];
> - if (!res->flags) {
> + if (resource_disabled(res)) {
>   if (i == 0)
>   printk(KERN_ERR "PCI: Memory resource 0 not set 
> for "
>  "host bridge %s (domain %d)\n",
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 414fd1a..81484c1 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -874,7 +874,7 @@ static int pnv_pci_vf_resource_shift(struct pci_dev *dev, 
> int offset)
>   num_vfs = pdn->num_vfs;
>   for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
>   res = >resource[i + PCI_IOV_RESOURCES];
> - if (!res->flags || !res->parent)
> + if (resource_disabled(res) || !res->parent)
>   continue;
>  
>   if (!pnv_pci_is_mem_pref_64(res->flags))
> @@ -905,7 +905,7 @@ static int pnv_pci_vf_resource_shift(struct pci_dev *dev, 
> int offset)
>*/
>   for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
>   res = >resource[i + PCI_IOV_RESOURCES];
> - if (!res->flags || !res->parent)
> + if (resource_disabled(res) || !res->parent)
>   continue;
>  
>   if (!pnv_pci_is_mem_pref_64(res->flags))
> @@ -1188,7 +1188,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev *pdev, 
> u16 num_vfs)
>  

Re: [PATCH v3 10/31] powerpc/mm: Don't use pmd_val,pud_val and pgd_val as lvalue

[Michael Ellerman]

On Tue, 2015-10-13 at 10:53 +0530, Aneesh Kumar K.V wrote:
> Michael Ellerman  writes:
> 
> > On Tue, 2015-10-13 at 00:09 +0530, Aneesh Kumar K.V wrote:
> >> We convert them static inline function here as we did with pte_val in
> >> the previous patch
> >
> > This breaks ppc40x_defconfig & 40x/ep405_defconfig with:
> 
> How about
> 
> diff --git a/arch/powerpc/mm/40x_mmu.c b/arch/powerpc/mm/40x_mmu.c
> index 5810967511d4..31a5d42df8c9 100644
> --- a/arch/powerpc/mm/40x_mmu.c
> +++ b/arch/powerpc/mm/40x_mmu.c
> @@ -110,10 +110,10 @@ unsigned long __init mmu_mapin_ram(unsigned long top)
>   unsigned long val = p | _PMD_SIZE_16M | _PAGE_EXEC | 
> _PAGE_HWWRITE;
>  
>   pmdp = pmd_offset(pud_offset(pgd_offset_k(v), v), v);
> - pmd_val(*pmdp++) = val;
> - pmd_val(*pmdp++) = val;
> - pmd_val(*pmdp++) = val;
> - pmd_val(*pmdp++) = val;
> + *pmdp++ = __pmd(val);
> + *pmdp++ = __pmd(val);
> + *pmdp++ = __pmd(val);
> + *pmdp++ = __pmd(val);
>  
>   v += LARGE_PAGE_SIZE_16M;
>   p += LARGE_PAGE_SIZE_16M;
> @@ -125,7 +125,7 @@ unsigned long __init mmu_mapin_ram(unsigned long top)
>   unsigned long val = p | _PMD_SIZE_4M | _PAGE_EXEC | 
> _PAGE_HWWRITE;
>  
>   pmdp = pmd_offset(pud_offset(pgd_offset_k(v), v), v);
> - pmd_val(*pmdp) = val;
> + *pmdp = __pmd(val);


Yep that fixes it, I've squashed that in for now to get it building.

cheers


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

Re: [v2,1/1] powerpc: Individual System V IPC system calls

[Michael Ellerman]

On Tue, 2015-13-10 at 01:49:28 UTC, Sam bobroff wrote:
> This patch provides individual system call numbers for the following
> System V IPC system calls, on PowerPC, so that they do not need to be
> multiplexed:
> * semop, semget, semctl, semtimedop
> * msgsnd, msgrcv, msgget, msgctl
> * shmat, shmdt, shmget, shmctl

You tested this right? :)  Tell me about it.

Also we could make these available to SPU programs, but I don't think there's
any point, no one's going to do a libc update for that.

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v7,51/60] PCI: Unify skip_ioresource_align()

[Michael Ellerman]

On Thu, 2015-08-10 at 21:39:10 UTC, Yinghai Lu wrote:
> There are powerpc generic version and x86 local version for
> skip_ioresource_align().
> 
> Move the powerpc version to setup-bus.c, and kill x86 local version.
> 
> Also kill dummy version in microblaze.
> 
> Cc: Michal Simek 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Arnd Bergmann 
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-a...@vger.kernel.org
> Signed-off-by: Yinghai Lu 
> Reviewed-by: Thomas Gleixner 
> 
> diff --git a/arch/powerpc/kernel/pci-common.c 
> b/arch/powerpc/kernel/pci-common.c
> index 7587b2a..8853667 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -1052,15 +1052,6 @@ void pci_fixup_cardbus(struct pci_bus *bus)
>   pcibios_setup_bus_devices(bus);
>  }
>  
> -
> -static int skip_isa_ioresource_align(struct pci_dev *dev)
> -{
> - if (pci_has_flag(PCI_CAN_SKIP_ISA_ALIGN) &&
> - !(dev->bus->bridge_ctl & PCI_BRIDGE_CTL_ISA))
> - return 1;
> - return 0;
> -}
> -
>  /*
>   * We need to avoid collisions with `mirrored' VGA ports
>   * and other strange ISA hardware, so we always want the
> @@ -1081,7 +1072,7 @@ resource_size_t pcibios_align_resource(void *data, 
> const struct resource *res,
>   resource_size_t start = res->start;
>  
>   if (res->flags & IORESOURCE_IO) {
> - if (skip_isa_ioresource_align(dev))
> + if (skip_isa_ioresource_align(dev->bus))
>   return start;
>   if (start & 0x300)
>   start = (start + 0x3ff) & ~0x3ff;

LGTM.

Acked-by: Michael Ellerman  (powerpc)

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 4/6] powerpc: atomic: Implement atomic{, 64}_*_return_* variants

[Will Deacon]

On Mon, Oct 12, 2015 at 10:14:04PM +0800, Boqun Feng wrote:
> On powerpc, acquire and release semantics can be achieved with
> lightweight barriers("lwsync" and "ctrl+isync"), which can be used to
> implement __atomic_op_{acquire,release}.
> 
> For release semantics, since we only need to ensure all memory accesses
> that issue before must take effects before the -store- part of the
> atomics, "lwsync" is what we only need. On the platform without
> "lwsync", "sync" should be used. Therefore, smp_lwsync() is used here.
> 
> For acquire semantics, "lwsync" is what we only need for the similar
> reason.  However on the platform without "lwsync", we can use "isync"
> rather than "sync" as an acquire barrier. So a new kind of barrier
> smp_acquire_barrier__after_atomic() is introduced, which is barrier() on
> UP, "lwsync" if available and "isync" otherwise.
> 
> __atomic_op_fence is defined as smp_lwsync() + _relaxed +
> smp_mb__after_atomic() to guarantee a full barrier.
> 
> Implement atomic{,64}_{add,sub,inc,dec}_return_relaxed, and build other
> variants with these helpers.
> 
> Signed-off-by: Boqun Feng 
> ---
>  arch/powerpc/include/asm/atomic.h | 122 
> +-
>  1 file changed, 80 insertions(+), 42 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/atomic.h 
> b/arch/powerpc/include/asm/atomic.h
> index 55f106e..3143af9 100644
> --- a/arch/powerpc/include/asm/atomic.h
> +++ b/arch/powerpc/include/asm/atomic.h
> @@ -12,6 +12,39 @@
>  
>  #define ATOMIC_INIT(i)   { (i) }
>  
> +/*
> + * Since {add,sub}_return_relaxed and xchg_relaxed are implemented with
> + * a "bne-" instruction at the end, so an isync is enough as a acquire 
> barrier
> + * on the platform without lwsync.
> + */
> +#ifdef CONFIG_SMP
> +#define smp_acquire_barrier__after_atomic() \
> + __asm__ __volatile__(PPC_ACQUIRE_BARRIER : : : "memory")

I'm not keen on this barrier, as it sounds like it's part of the kernel
memory model, as opposed to an implementation detail on PowerPC (and
we've already got enough of that in the generic code ;).

Can you name it something different please (and maybe #undef it when
you're done)?

Will
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 4/6] powerpc: atomic: Implement atomic{, 64}_*_return_* variants

[Boqun Feng]

On Tue, Oct 13, 2015 at 02:21:32PM +0100, Will Deacon wrote:
> On Mon, Oct 12, 2015 at 10:14:04PM +0800, Boqun Feng wrote:
[snip]
> > +/*
> > + * Since {add,sub}_return_relaxed and xchg_relaxed are implemented with
> > + * a "bne-" instruction at the end, so an isync is enough as a acquire 
> > barrier
> > + * on the platform without lwsync.
> > + */
> > +#ifdef CONFIG_SMP
> > +#define smp_acquire_barrier__after_atomic() \
> > +   __asm__ __volatile__(PPC_ACQUIRE_BARRIER : : : "memory")
> 
> I'm not keen on this barrier, as it sounds like it's part of the kernel
> memory model, as opposed to an implementation detail on PowerPC (and
> we've already got enough of that in the generic code ;).
> 

Indeed, but we still have smp_lwsync() ;-)

> Can you name it something different please (and maybe #undef it when
> you're done)?
> 

I've considered #undef it after used, but now I think open code this
into __atomic_op_acquire() of PPC is a better idea?


#define __atomic_op_acquire(op, args...)\
({  \
typeof(op##_relaxed(args)) __ret  = op##_relaxed(args); \
__asm__ __volatile__(PPC_ACQUIRE_BARRIER : : : "memory");   \
__ret;  \
})

PPC_ACQUIRE_BARRIER will be empty if !SMP, so that will become a pure
compiler barrier and just what we need.

Regards,
Boqun


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants

[Will Deacon]

On Mon, Oct 12, 2015 at 10:14:06PM +0800, Boqun Feng wrote:
> Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on
> which _release variants can be built.
> 
> To avoid superfluous barriers in _acquire variants, we implement these
> operations with assembly code rather use __atomic_op_acquire() to build
> them automatically.

The "superfluous barriers" are for the case where the cmpxchg fails, right?
And you don't do the same thing for release, because you want to avoid a
barrier in the middle of the critical section?

(just checking I understand your reasoning).

Will
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] powerpc/85xx: Add PCIe controller support for bsc9132qds

[Zhiqiang Hou]

From: Harninder Rai 

1. Use machine_arch_initcall to hook mpc85xx_common_publish_devices
This can ensure before pcibios_init() is called, pci controllers have
been probed and added to the hose_list.
2. Add a workaround for errata A-005434
For the BSC9132, PEX_PEXIWARn[TRGT] for all windows defaults to 0xF,
which is mapped to CCSRBAR. However, for other products, 0xF is
mapped to the local memory. Therefore, for the BSC9132, any default
PCI Express access to the local memory (DDR) will now access the
CCSRBAR. This patch changes the mapping of targets of inbound windows
PEX_PEXIWARn[TRGT] to the Local address space – 0x0 (from 0xF).

Signed-off-by: Harninder Rai 
Signed-off-by: Minghuan Lian 
Change-Id: Iebb3d0e057d64d5b96263c130495e5d04caf7948
Reviewed-on: http://git.am.freescale.net:8181/2455
Reviewed-by: Zang Tiefei-R61911 
Reviewed-by: Kushwaha Prabhakar-B32579 
Reviewed-by: Fleming Andrew-AFLEMING 
Tested-by: Fleming Andrew-AFLEMING 
---
 arch/powerpc/platforms/85xx/bsc913x_qds.c |  8 +++-
 arch/powerpc/sysdev/fsl_pci.c | 13 +
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/85xx/bsc913x_qds.c 
b/arch/powerpc/platforms/85xx/bsc913x_qds.c
index f0927e5..dcfafd6 100644
--- a/arch/powerpc/platforms/85xx/bsc913x_qds.c
+++ b/arch/powerpc/platforms/85xx/bsc913x_qds.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "mpc85xx.h"
@@ -46,10 +47,12 @@ static void __init bsc913x_qds_setup_arch(void)
mpc85xx_smp_init();
 #endif
 
+   fsl_pci_assign_primary();
+
pr_info("bsc913x board from Freescale Semiconductor\n");
 }
 
-machine_device_initcall(bsc9132_qds, mpc85xx_common_publish_devices);
+machine_arch_initcall(bsc9132_qds, mpc85xx_common_publish_devices);
 
 /*
  * Called very early, device-tree isn't unflattened
@@ -67,6 +70,9 @@ define_machine(bsc9132_qds) {
.probe  = bsc9132_qds_probe,
.setup_arch = bsc913x_qds_setup_arch,
.init_IRQ   = bsc913x_qds_pic_init,
+#ifdef CONFIG_PCI
+   .pcibios_fixup_bus  = fsl_pcibios_fixup_bus,
+#endif
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index ebc1f412..b8607f6 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -193,6 +193,19 @@ static void setup_pci_atmu(struct pci_controller *hose)
const u64 *reg;
int len;
 
+   if (of_device_is_compatible(hose->dn, "fsl,bsc9132-pcie")) {
+   /*
+* BSC9132 Rev1.0 has an issue where all the PEX inbound
+* windows have implemented the default target value as 0xf
+* for CCSR space.In all Freescale legacy devices the target
+* of 0xf is reserved for local memory space. 9132 Rev1.0
+* now has local mempry space mapped to target 0x0 instead of
+* 0xf. Hence adding a workaround to remove the target 0xf
+* defined for memory space from Inbound window attributes.
+*/
+   piwar &= ~PIWAR_TGI_LOCAL;
+   }
+
if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
if (in_be32(>block_rev1) >= PCIE_IP_REV_2_2) {
win_idx = 2;
-- 
2.1.0.27.g96db324

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

Re: [PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

[Peter Zijlstra]

On Mon, Oct 12, 2015 at 10:14:00PM +0800, Boqun Feng wrote:
 
> The patchset consists of 6 parts:
> 
> 1.Make xchg, cmpxchg and their atomic_ versions a full barrier
> 
> 2.Add trivial tests for the new variants in lib/atomic64_test.c
> 
> 3.Allow architectures to define their own __atomic_op_*() helpers
>   to build other variants based on relaxed.
> 
> 4.Implement atomic{,64}_{add,sub,inc,dec}_return_* variants
> 
> 5.Implement xchg_* and atomic{,64}_xchg_* variants
> 
> 6.Implement cmpxchg_* atomic{,64}_cmpxchg_* variants
> 
> 
> This patchset is based on current locking/core branch of the tip tree
> and all patches are built and boot tested for little endian pseries, and
> also tested by 0day.
> 

I don't see any immediate problems with this series at this point. Will,
Paul?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v2,1/1] powerpc: Individual System V IPC system calls

[Arnd Bergmann]

On Tuesday 13 October 2015 20:38:42 Michael Ellerman wrote:
> On Tue, 2015-13-10 at 01:49:28 UTC, Sam bobroff wrote:
> > This patch provides individual system call numbers for the following
> > System V IPC system calls, on PowerPC, so that they do not need to be
> > multiplexed:
> > * semop, semget, semctl, semtimedop
> > * msgsnd, msgrcv, msgget, msgctl
> > * shmat, shmdt, shmget, shmctl
> 
> You tested this right?   Tell me about it.
> 
> Also we could make these available to SPU programs, but I don't think there's
> any point, no one's going to do a libc update for that.
> 

The existing sys_ipc is also in the list of exceptions that are
not exported to the SPU. I don't remember what the reason for this
is, but there probably was one.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/2] powerpc/fsl: Add PCI node in device tree of bsc9132qds

[Zhiqiang Hou]

From: Harninder Rai 

Signed-off-by: Harninder Rai 
Signed-off-by: Minghuan Lian 
Change-Id: I4355add4a92d1fcf514843aea5ecadd2e2517969
Reviewed-on: http://git.am.freescale.net:8181/2454
Reviewed-by: Zang Tiefei-R61911 
Reviewed-by: Kushwaha Prabhakar-B32579 
Reviewed-by: Fleming Andrew-AFLEMING 
Tested-by: Fleming Andrew-AFLEMING 
---
 arch/powerpc/boot/dts/bsc9132qds.dts  | 15 ++
 arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi | 29 +++
 arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi  |  1 +
 3 files changed, 45 insertions(+)

diff --git a/arch/powerpc/boot/dts/bsc9132qds.dts 
b/arch/powerpc/boot/dts/bsc9132qds.dts
index 6cab106..940d719 100644
--- a/arch/powerpc/boot/dts/bsc9132qds.dts
+++ b/arch/powerpc/boot/dts/bsc9132qds.dts
@@ -29,6 +29,21 @@
soc: soc@ff70 {
ranges = <0x0 0x0 0xff70 0x10>;
};
+
+   pci0: pcie@ff70a000 {
+   reg = <0 0xff70a000 0 0x1000>;
+   ranges = <0x200 0x0 0x9000 0 0x9000 0x0 0x2000
+ 0x100 0x0 0x 0 0xc001 0x0 0x1>;
+   pcie@0 {
+   ranges = <0x200 0x0 0x9000
+ 0x200 0x0 0x9000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+   };
+   };
 };
 
 /include/ "bsc9132qds.dtsi"
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
index c723071..78c8f1c 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
@@ -40,6 +40,35 @@
interrupts = <16 2 0 0 20 2 0 0>;
 };
 
+/* controller at 0xa000 */
+ {
+   compatible = "fsl,bsc9132-pcie", "fsl,qoriq-pcie-v2.2";
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   bus-range = <0 255>;
+   clock-frequency = <>;
+   interrupts = <16 2 0 0>;
+
+   pcie@0 {
+   reg = <0 0 0 0 0>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   device_type = "pci";
+   interrupts = <16 2 0 0>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+
+   interrupt-map = <
+   /* IDSEL 0x0 */
+    0x0 0x0 0x1  0x0 0x2 0x0 0x0
+    0x0 0x0 0x2  0x1 0x2 0x0 0x0
+    0x0 0x0 0x3  0x2 0x2 0x0 0x0
+    0x0 0x0 0x4  0x3 0x2 0x0 0x0
+   >;
+   };
+};
+
  {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
index 301a9db..90f7949 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
@@ -45,6 +45,7 @@
serial0 = 
ethernet0 = 
ethernet1 = 
+   pci0 = 
};
 
cpus {
-- 
2.1.0.27.g96db324

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

Re: [PATCH v2 2/2] net/fsl_pq_mdio: fix computed address for the TBI register

[David Miller]

From: Gerlando Falauto 
Date: Mon, 12 Oct 2015 09:18:41 +0200

> commit afae5ad78b342f401c28b0bb1adb3cd494cb125a
>   "net/fsl_pq_mdio: streamline probing of MDIO nodes"
> 
> added support for different types of MDIO devices:
> 1) Gianfar MDIO nodes that only map the MII registers
> 2) Gianfar MDIO nodes that map the full MDIO register set
> 3) eTSEC2 MDIO nodes (which map the full MDIO register set)
> 4) QE MDIO nodes (which map only the MII registers)
> 
> However, the implementation for types 1 and 4 would mistakenly assume
> a mapping of the full MDIO register set, thereby computing the address
> for the TBI register starting from the containing structure.
> The TBI register would therefore be accessed at a wrong (much bigger)
> address, not giving the expected result at all.
> This patch restores the correct behavior we had prior to the above one.
> 
> The consequences of this bug are apparent when trying to access a PHY
> with the same address as the value contained in the initial value of
> the TBI register (normally 0); in that case you'll get answers from the
> internal TBI device (even though MDIO/MDC pins are actually *also*
> toggling on the physical bus!).
> Beware that you also need to add a fake tbi node to your device tree
> with an unused address.
> 
> Notice how this fix is related to commit
> 220669495bf8b68130a8218607147c7b74c28d2b
>   "powerpc: Add TBI PHY node to first MDIO bus"
> 
> which fixed the behavior in kernel 3.3, which was later broken by the
> above commit on kernel 3.7.
> 
> Signed-off-by: Gerlando Falauto 

Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] scripts/tags.sh: Teach tags about some powerpc macros

[Michal Marek]

On 2015-10-13 07:18, Michael Ellerman wrote:
> On Tue, 2015-09-22 at 13:08 +1000, Michael Ellerman wrote:
>> The IO accessors on powerpc are generated using macro fu, ie. out_be32()
>> etc. Also there are some debugger related symbols that are macro
>> generated. Teach scripts/tags.sh about both.
>>
>> Signed-off-by: Michael Ellerman 
>> ---
>>  scripts/tags.sh | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/scripts/tags.sh b/scripts/tags.sh
>> index 8e5aee6d9da2..262889046703 100755
>> --- a/scripts/tags.sh
>> +++ b/scripts/tags.sh
>> @@ -198,6 +198,8 @@ exuberant()
>>  --regex-c++='/TASK_PFA_TEST\([^,]*,\s*([^)]*)\)/task_\1/'   \
>>  --regex-c++='/TASK_PFA_SET\([^,]*,\s*([^)]*)\)/task_set_\1/'\
>>  --regex-c++='/TASK_PFA_CLEAR\([^,]*,\s*([^)]*)\)/task_clear_\1/'\
>> +--regex-c++='/DEF_MMIO_(IN|OUT)_(X|D)\(([^,]*),\s*[^)]*\)/\3/'  \
>> +--regex-c++='/DEBUGGER_BOILERPLATE\(([^,]*)\)/\1/'  \
>>  --regex-c='/PCI_OP_READ\((\w*).*[1-4]\)/pci_bus_read_config_\1/' \
>>  --regex-c='/PCI_OP_WRITE\((\w*).*[1-4]\)/pci_bus_write_config_\1/' \
>>  --regex-c='/DEFINE_(MUTEX|SEMAPHORE|SPINLOCK)\((\w*)/\2/v/' \
> 
> 
> Michal, do you want to take this one or should I ?

I applied it to kbuild.git#misc.

Michal

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

Re: [PATCH 1/6] powerpc/kconfig: Move NR_IRQS into "Kernel Options"

[Arnd Bergmann]

On Tuesday 13 October 2015 11:28:06 Michael Ellerman wrote:
> On Mon, 2015-10-12 at 13:50 +0200, Arnd Bergmann wrote:
> > On Monday 12 October 2015 22:07:45 Michael Ellerman wrote:
> > > Yeah, this builds and boots at least on pseries KVM.
> > > 
> > > diff --git a/arch/powerpc/include/asm/irq.h 
> > > b/arch/powerpc/include/asm/irq.h
> > > index e8e3a0a04eb0..35fba282b7f9 100644
> > > --- a/arch/powerpc/include/asm/irq.h
> > > +++ b/arch/powerpc/include/asm/irq.h
> > > @@ -23,11 +23,8 @@ extern atomic_t ppc_n_lost_interrupts;
> > >  /* This number is used when no interrupt has been assigned */
> > >  #define NO_IRQ (0)
> > >  
> > > -/* Total number of virq in the platform */
> > > -#define NR_IRQSCONFIG_NR_IRQS
> > > -
> > > -/* Same thing, used by the generic IRQ code */
> > >  #define NR_IRQS_LEGACY NUM_ISA_INTERRUPTS
> > > +#define NR_IRQSNR_IRQS_LEGACY
> > >  
> > >  extern irq_hw_number_t virq_to_hw(unsigned int virq);
> > >  
> > 
> > This looks like the way it's intended.
> 
> Hmm, though IRQ_BITMAP_BITS is still a hard limit, and by default it's set to
> NR_IRQS + 8196.

Ah, I wasn't aware of this limit.

> So we'd be relying on the + 8196 to get us up to a reasonable number. That
> looks like it was added as a bit of a hack/bug-fix, so I'm not sure we want to
> rely on it. (c1ee6264280e ("genirq: Prevent access beyond allocated_irqs
> bitmap"))
> 
> All the distros seem to run with NR_IRQS=512, so it seems no one has needed
> more than that or we would have heard about it presumably.
> 
> At the same time if we're only spending a single bit for each interrupt number
> maybe we should just set it to min(512, NR_CPUS) or something like that to 
> make
> sure it's always reasonably big.

The NR_IRQS part is what consumes actual kernel memory, and it may hurt you
on some of the older embedded machines with small RAM. Reducing this is of
course the main idea behind CONFIG_SPARSE_IRQ, and I don't see any indication
that we ever need more than NR_IRQS_LEGACY here.

It's the +8196 part I'd be more worried about for large systems, as you say
it has been picked arbitrarily, and can easily be too small if you have
hundreds or thousands of CPU cores.

Maybe we could change the IRQ_BITMAP_BITS to have use

#define IRQ_BITMAP_BITS (NR_IRQS_LEGACY + MAX_NUMNODES * 8192)

which leaves it as it is on small machines, but gives large NUMA machines
(which should always have enough RAM anyway) some more room.

Arnd 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] net/fsl_pq_mdio: check TBI address for consistency with mapped range

[David Miller]

From: Gerlando Falauto 
Date: Mon, 12 Oct 2015 09:18:40 +0200

> When configuring the MDIO subsystem it is also necessary to configure
> the TBI register. Make sure the TBI is contained within the mapped
> register range in order to:
> a) make sure the address is computed correctly
> b) make users aware that we're actually accessing that register
> 
> In case of error, print a message but continue anyway.
> 
> Signed-off-by: Gerlando Falauto 
> Cc: Timur Tabi 
> Cc: David S. Miller 
> Cc: Kumar Gala 
> ---
> Changes from v1:
> - Added type cast & fixed range
> - removed freescale recipients

Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants

[Boqun Feng]

On Tue, Oct 13, 2015 at 02:24:04PM +0100, Will Deacon wrote:
> On Mon, Oct 12, 2015 at 10:14:06PM +0800, Boqun Feng wrote:
> > Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on
> > which _release variants can be built.
> > 
> > To avoid superfluous barriers in _acquire variants, we implement these
> > operations with assembly code rather use __atomic_op_acquire() to build
> > them automatically.
> 
> The "superfluous barriers" are for the case where the cmpxchg fails, right?

Yes.

> And you don't do the same thing for release, because you want to avoid a
> barrier in the middle of the critical section?
> 

Mostly because of the comments in include/linux/atomic.h:

 * For compound atomics performing both a load and a store, ACQUIRE
 * semantics apply only to the load and RELEASE semantics only to the
 * store portion of the operation. Note that a failed cmpxchg_acquire
 * does -not- imply any memory ordering constraints.

so I thought only the barrier in cmpxchg_acquire() is conditional, and
the barrier in cmpxchg_release() is not. Maybe we'd better call it out
that cmpxchg *family* doesn't have any order guarantee if cmp fails, as
a complement of

ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory ordering 
semantics")

Because it seems this commit only claims that the barriers in fully
ordered version are conditional.


If cmpxchg_release doesn't have order guarantee when failed, I guess I
can implement it with a barrier in the middle as you mentioned:

unsigned int prev;

__asm__ __volatile__ (
"1: lwarx   %0,0,%2 
cmpw0,%0,%3\n\
bne-2f\n"
PPC_RELEASE_BARRIER
"   stwcx.  %4,0,%2\n\
bne-1b"
"\n\
2:"
: "=" (prev), "+m" (*p)
: "r" (p), "r" (old), "r" (new)
: "cc", "memory");

return prev;


However, I need to check whether the architecture allows this and any
other problem exists.

Besides, I don't think it's a good idea to do the "put barrier in the
middle" thing in this patchset, because that seems a premature
optimization and if we go further, I guess we can also replace the
PPC_RELEASE_BARRIER above with a "sync" to implement a fully ordered
version cmpxchg(). Too much needs to investigate then..

> (just checking I understand your reasoning).
> 

That actually helps me find a probably better implementation if allowed,
thank you ;-)

Regards,
Boqun


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 12/13] powerpc: enable building of all dtbs

[Rob Herring]

On Mon, Oct 12, 2015 at 5:26 AM, Michael Ellerman  wrote:
> On Thu, 2015-10-08 at 12:53 -0500, Rob Herring wrote:
>> Enable building all dtb files when CONFIG_OF_ALL_DTBS is enabled. The dtbs
>> are not really dependent on a platform being enabled or any other kernel
>> config, so for testing coverage it is convenient to build all of the dtbs.
>> This builds all dts files in the tree, not just targets listed.
>>
>> Supporting this requires adding 'dtbs' make target which was not yet
>> supported on powerpc.
>
> I'm not entirely clear why we want this? It just means we can test build all
> the dts regardless of what kernel config we are building?

Yes. Given that I haven't found any that didn't build, that alone is
probably not so important. There's also an effort to move DT binding
docs to YAML, and I'm using dtc to dump out binding information to
automatically populate the binding docs hence I need to build all.
Eventually, we also plan to use the binding docs to validate dts
files.

> Have you tested the powerpc build with this applied or do you want me to?

Yes, I've tested powerpc.

>
>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>> index b9b4af2..0ec35ff 100644
>> --- a/arch/powerpc/Makefile
>> +++ b/arch/powerpc/Makefile
>> @@ -273,6 +273,11 @@ bootwrapper_install:
>>  %.dtb: scripts
>>   $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>>
>> +PHONY += dtbs
>> +
>> +dtbs: prepare scripts
>> + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot)/dts
>
> The ARCH should be powerpc, I guess you just copied the one above.

Okay, I'll drop it (it should already be set).

>
>> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
>> index 4eec430..381df1a 100644
>> --- a/arch/powerpc/boot/Makefile
>> +++ b/arch/powerpc/boot/Makefile
>> @@ -402,7 +402,7 @@ zInstall: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
>>  clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
>>   zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
>>   zImage.miboot zImage.pmac zImage.pseries \
>> - zImage.maple simpleImage.* otheros.bld *.dtb
>> + zImage.maple simpleImage.* otheros.bld
>
> This looks like we used to clean *.dtb in the current dir but now we don't? 
> But
> I'm probably just not understanding how clean-files works.

dtbs target is building in boot/dts. I just noticed that %.dtb targets
(or dtbImage.% targets) still build in boot/. I need to move them to
boot/dts/ as well to align with all other arches. This clean should
probably stay so dtbs get cleaned in either location.

>
>> @@ -410,6 +410,9 @@ clean-kernel += $(addsuffix .gz,$(clean-kernel))
>>  # If not absolute clean-files are relative to $(obj).
>>  clean-files += $(addprefix $(objtree)/, $(clean-kernel))
>>
>> +# Let clean descend into subdirs
>> +subdir- := dts
>> +
>>  WRAPPER_OBJDIR := /usr/lib/kernel-wrapper
>>  WRAPPER_DTSDIR := /usr/lib/kernel-wrapper/dts
>>  WRAPPER_BINDIR := /usr/sbin
>> diff --git a/arch/powerpc/boot/dts/Makefile b/arch/powerpc/boot/dts/Makefile
>> new file mode 100644
>> index 000..f121775
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/Makefile
>> @@ -0,0 +1,5 @@
>> +dtstree  := $(srctree)/$(src)
>> +dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
>> $(dtstree)/*.dts))
>> +
>> +always   := $(dtb-y)
>
> How/is that different from just doing the more normal:
>
> obj-$(CONFIG_OF_ALL_DTBS) := ...
>
> ?

obj-y will build the dtb into the kernel which some arches do and not
what we want here.

Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants

[Boqun Feng]

On Tue, Oct 13, 2015 at 10:32:59PM +0800, Boqun Feng wrote:
> On Tue, Oct 13, 2015 at 02:24:04PM +0100, Will Deacon wrote:
> > On Mon, Oct 12, 2015 at 10:14:06PM +0800, Boqun Feng wrote:
> > > Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on
> > > which _release variants can be built.
> > > 
> > > To avoid superfluous barriers in _acquire variants, we implement these
> > > operations with assembly code rather use __atomic_op_acquire() to build
> > > them automatically.
> > 
> > The "superfluous barriers" are for the case where the cmpxchg fails, right?
> 
> Yes.
> 
> > And you don't do the same thing for release, because you want to avoid a
> > barrier in the middle of the critical section?
> > 
> 
> Mostly because of the comments in include/linux/atomic.h:
> 
>  * For compound atomics performing both a load and a store, ACQUIRE
>  * semantics apply only to the load and RELEASE semantics only to the
>  * store portion of the operation. Note that a failed cmpxchg_acquire
>  * does -not- imply any memory ordering constraints.
> 
> so I thought only the barrier in cmpxchg_acquire() is conditional, and
> the barrier in cmpxchg_release() is not. Maybe we'd better call it out
> that cmpxchg *family* doesn't have any order guarantee if cmp fails, as
> a complement of
> 
> ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory 
> ordering semantics")
> 
> Because it seems this commit only claims that the barriers in fully
> ordered version are conditional.
> 
> 
> If cmpxchg_release doesn't have order guarantee when failed, I guess I
> can implement it with a barrier in the middle as you mentioned:
> 
>   unsigned int prev;
> 
>   __asm__ __volatile__ (
> "1:   lwarx   %0,0,%2 
>   cmpw0,%0,%3\n\
>   bne-2f\n"
>   PPC_RELEASE_BARRIER
> " stwcx.  %4,0,%2\n\
>   bne-1b"
>   "\n\
> 2:"
>   : "=" (prev), "+m" (*p)
>   : "r" (p), "r" (old), "r" (new)
>   : "cc", "memory");
> 
>   return prev;
> 
> 
> However, I need to check whether the architecture allows this and any
> other problem exists.
> 
> Besides, I don't think it's a good idea to do the "put barrier in the
> middle" thing in this patchset, because that seems a premature
> optimization and if we go further, I guess we can also replace the
> PPC_RELEASE_BARRIER above with a "sync" to implement a fully ordered

Correction: we can't just put the sync in the middle to implement a
fully ordered version. Sorry for that mistake..

Regards,
Boqun

> version cmpxchg(). Too much needs to investigate then..
> 
> > (just checking I understand your reasoning).
> > 
> 
> That actually helps me find a probably better implementation if allowed,
> thank you ;-)
> 
> Regards,
> Boqun


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants

[Boqun Feng]

On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote:
> On Tue, Oct 13, 2015 at 10:32:59PM +0800, Boqun Feng wrote:
[snip]
> > 
> > Mostly because of the comments in include/linux/atomic.h:
> > 
> >  * For compound atomics performing both a load and a store, ACQUIRE
> >  * semantics apply only to the load and RELEASE semantics only to the
> >  * store portion of the operation. Note that a failed cmpxchg_acquire
> >  * does -not- imply any memory ordering constraints.
> > 
> > so I thought only the barrier in cmpxchg_acquire() is conditional, and
> > the barrier in cmpxchg_release() is not. Maybe we'd better call it out
> > that cmpxchg *family* doesn't have any order guarantee if cmp fails, as
> > a complement of
> > 
> > ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory 
> > ordering semantics")
> > 
> > Because it seems this commit only claims that the barriers in fully
> > ordered version are conditional.
> 
> I didn't think this was ambiguous... A failed cmpxchg_release doesn't
> perform a store, so because the RELEASE semantics only apply to the
> store portion of the operation, it therefore doesn't have any ordering
> guarantees. Acquire is called out as a special case because it *does*
> actually perform a load on the failure case.
> 

Make sense.

> > If cmpxchg_release doesn't have order guarantee when failed, I guess I
> > can implement it with a barrier in the middle as you mentioned:
> > 
> > unsigned int prev;
> > 
> > __asm__ __volatile__ (
> > "1: lwarx   %0,0,%2 
> > cmpw0,%0,%3\n\
> > bne-2f\n"
> > PPC_RELEASE_BARRIER
> > "   stwcx.  %4,0,%2\n\
> > bne-1b"
> > "\n\
> > 2:"
> > : "=" (prev), "+m" (*p)
> > : "r" (p), "r" (old), "r" (new)
> > : "cc", "memory");
> > 
> > return prev;
> > 
> > 
> > However, I need to check whether the architecture allows this and any
> > other problem exists.
> > 
> > Besides, I don't think it's a good idea to do the "put barrier in the
> > middle" thing in this patchset, because that seems a premature
> > optimization and if we go further, I guess we can also replace the
> > PPC_RELEASE_BARRIER above with a "sync" to implement a fully ordered
> > version cmpxchg(). Too much needs to investigate then..
> 
> Putting a barrier in the middle of that critical section is probably a
> terrible idea, and that's why I thought you were avoiding it (hence my

The fact is that I haven't thought of that way to implement
cmpxchg_release before you ask that question ;-) And I'm not going to do
that for now and probably not in the future.

> original question). Perhaps just add a comment to that effect, since I

Are you suggesting if I put a barrier in the middle I'd better to add a
comment, right? So if I don't do that, it's OK to let this patch as it.

Regards,
Boqun

> fear adding more words to memory-barriers.txt is just likely to create
> further confusion.
> 
> Will


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants

[Will Deacon]

On Tue, Oct 13, 2015 at 10:58:30PM +0800, Boqun Feng wrote:
> On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote:
> > Putting a barrier in the middle of that critical section is probably a
> > terrible idea, and that's why I thought you were avoiding it (hence my
> 
> The fact is that I haven't thought of that way to implement
> cmpxchg_release before you ask that question ;-) And I'm not going to do
> that for now and probably not in the future.
> 
> > original question). Perhaps just add a comment to that effect, since I
> 
> Are you suggesting if I put a barrier in the middle I'd better to add a
> comment, right? So if I don't do that, it's OK to let this patch as it.

No, I mean put a comment in your file to explain the reason why you
override _relaxed and _acquire, but not _release (because overriding
_release would introduce this weird barrier in the middle of the critical
section, which would likely cause the conditional store to fail).

Will
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants

[Will Deacon]

On Tue, Oct 13, 2015 at 10:32:59PM +0800, Boqun Feng wrote:
> On Tue, Oct 13, 2015 at 02:24:04PM +0100, Will Deacon wrote:
> > On Mon, Oct 12, 2015 at 10:14:06PM +0800, Boqun Feng wrote:
> > > Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on
> > > which _release variants can be built.
> > > 
> > > To avoid superfluous barriers in _acquire variants, we implement these
> > > operations with assembly code rather use __atomic_op_acquire() to build
> > > them automatically.
> > 
> > The "superfluous barriers" are for the case where the cmpxchg fails, right?
> 
> Yes.
> 
> > And you don't do the same thing for release, because you want to avoid a
> > barrier in the middle of the critical section?
> > 
> 
> Mostly because of the comments in include/linux/atomic.h:
> 
>  * For compound atomics performing both a load and a store, ACQUIRE
>  * semantics apply only to the load and RELEASE semantics only to the
>  * store portion of the operation. Note that a failed cmpxchg_acquire
>  * does -not- imply any memory ordering constraints.
> 
> so I thought only the barrier in cmpxchg_acquire() is conditional, and
> the barrier in cmpxchg_release() is not. Maybe we'd better call it out
> that cmpxchg *family* doesn't have any order guarantee if cmp fails, as
> a complement of
> 
> ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory 
> ordering semantics")
> 
> Because it seems this commit only claims that the barriers in fully
> ordered version are conditional.

I didn't think this was ambiguous... A failed cmpxchg_release doesn't
perform a store, so because the RELEASE semantics only apply to the
store portion of the operation, it therefore doesn't have any ordering
guarantees. Acquire is called out as a special case because it *does*
actually perform a load on the failure case.

> If cmpxchg_release doesn't have order guarantee when failed, I guess I
> can implement it with a barrier in the middle as you mentioned:
> 
>   unsigned int prev;
> 
>   __asm__ __volatile__ (
> "1:   lwarx   %0,0,%2 
>   cmpw0,%0,%3\n\
>   bne-2f\n"
>   PPC_RELEASE_BARRIER
> " stwcx.  %4,0,%2\n\
>   bne-1b"
>   "\n\
> 2:"
>   : "=" (prev), "+m" (*p)
>   : "r" (p), "r" (old), "r" (new)
>   : "cc", "memory");
> 
>   return prev;
> 
> 
> However, I need to check whether the architecture allows this and any
> other problem exists.
> 
> Besides, I don't think it's a good idea to do the "put barrier in the
> middle" thing in this patchset, because that seems a premature
> optimization and if we go further, I guess we can also replace the
> PPC_RELEASE_BARRIER above with a "sync" to implement a fully ordered
> version cmpxchg(). Too much needs to investigate then..

Putting a barrier in the middle of that critical section is probably a
terrible idea, and that's why I thought you were avoiding it (hence my
original question). Perhaps just add a comment to that effect, since I
fear adding more words to memory-barriers.txt is just likely to create
further confusion.

Will
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants

[Boqun Feng]

On Tue, Oct 13, 2015 at 04:04:27PM +0100, Will Deacon wrote:
> On Tue, Oct 13, 2015 at 10:58:30PM +0800, Boqun Feng wrote:
> > On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote:
> > > Putting a barrier in the middle of that critical section is probably a
> > > terrible idea, and that's why I thought you were avoiding it (hence my
> > 
> > The fact is that I haven't thought of that way to implement
> > cmpxchg_release before you ask that question ;-) And I'm not going to do
> > that for now and probably not in the future.
> > 
> > > original question). Perhaps just add a comment to that effect, since I
> > 
> > Are you suggesting if I put a barrier in the middle I'd better to add a
> > comment, right? So if I don't do that, it's OK to let this patch as it.
> 
> No, I mean put a comment in your file to explain the reason why you
> override _relaxed and _acquire, but not _release (because overriding
> _release would introduce this weird barrier in the middle of the critical
> section, which would likely cause the conditional store to fail).
> 

Good idea, will do that. Thank you ;-)

Regards,
Boqun


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

[Paul E. McKenney]

On Tue, Oct 13, 2015 at 02:27:13PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 12, 2015 at 10:14:00PM +0800, Boqun Feng wrote:
> 
> > The patchset consists of 6 parts:
> > 
> > 1.  Make xchg, cmpxchg and their atomic_ versions a full barrier
> > 
> > 2.  Add trivial tests for the new variants in lib/atomic64_test.c
> > 
> > 3.  Allow architectures to define their own __atomic_op_*() helpers
> > to build other variants based on relaxed.
> > 
> > 4.  Implement atomic{,64}_{add,sub,inc,dec}_return_* variants
> > 
> > 5.  Implement xchg_* and atomic{,64}_xchg_* variants
> > 
> > 6.  Implement cmpxchg_* atomic{,64}_cmpxchg_* variants
> > 
> > 
> > This patchset is based on current locking/core branch of the tip tree
> > and all patches are built and boot tested for little endian pseries, and
> > also tested by 0day.
> 
> I don't see any immediate problems with this series at this point. Will,
> Paul?

Every time I have gotten ready to take a close look, someone has pointed
out a problem, and I have deferred until the next version.  Looks like
I should take a close look at Boqun's next version regardless.  ;-)

Thanx, Paul

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

Re: [PATCH] block-mq:Fix the null memory access while setting tags cpumask

[Raghavendra K T]

On 10/13/2015 10:17 PM, Jeff Moyer wrote:

Raghavendra K T  writes:


In nr_hw_queues >1 cases when certain number of cpus are onlined/or
offlined, that results change in request_queue map in block-mq layer,
we see the kernel dumping like:


What version is that patch against?  This problem should be fixed by the
patch set from Akinobu Mita.  I tested cpu hot-plugging on my system
with an nvme device, and it is fixed there on mainline.



Hi Jeff,

My patch was against (4.3.0-rc2) bcee19f424a.

I do see now that  commit 1356aae08338 (blk-mq: avoid setting
hctx->tags->cpumask before allocation) has equivalent fix.

Thanks for the information.


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

Re: [PATCH] block-mq:Fix the null memory access while setting tags cpumask

[Jeff Moyer]

Raghavendra K T  writes:

> In nr_hw_queues >1 cases when certain number of cpus are onlined/or
> offlined, that results change in request_queue map in block-mq layer,
> we see the kernel dumping like:

What version is that patch against?  This problem should be fixed by the
patch set from Akinobu Mita.  I tested cpu hot-plugging on my system
with an nvme device, and it is fixed there on mainline.

Cheers,
Jeff
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC, 1/2] scripts/kconfig/Makefile: Allow KBUILD_DEFCONFIG to be a target

[Olof Johansson]

On Fri, Oct 2, 2015 at 12:47 AM, Michael Ellerman  wrote:
> On Wed, 2015-23-09 at 05:40:34 UTC, Michael Ellerman wrote:
>> Arch Makefiles can set KBUILD_DEFCONFIG to tell kbuild the name of the
>> defconfig that should be built by default.
>>
>> However currently there is an assumption that KBUILD_DEFCONFIG points to
>> a file at arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG).
>>
>> We would like to use a target, using merge_config, as our defconfig, so
>> adapt the logic in scripts/kconfig/Makefile to allow that.
>>
>> To minimise the chance of breaking anything, we first check if
>> KBUILD_DEFCONFIG is a file, and if so we do the old logic. If it's not a
>> file, then we call the top-level Makefile with KBUILD_DEFCONFIG as the
>> target.
>>
>> Signed-off-by: Michael Ellerman 
>> Acked-by: Michal Marek 
>
> Applied to powerpc next.
>
> https://git.kernel.org/powerpc/c/d2036f30cfe1daa19e63ce75

This breaks arm64 defconfig for me:

mkdir obj-tmp
make -f Makefile O=obj-tmp ARCH=arm64 defconfig
... watch loop of:
*** Default configuration is based on target 'defconfig'
  GEN ./Makefile



-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC, 1/2] scripts/kconfig/Makefile: Allow KBUILD_DEFCONFIG to be a target

[Michael Ellerman]

On Tue, 2015-10-13 at 14:02 -0700, Olof Johansson wrote:
> On Fri, Oct 2, 2015 at 12:47 AM, Michael Ellerman  wrote:
> > On Wed, 2015-23-09 at 05:40:34 UTC, Michael Ellerman wrote:
> >> Arch Makefiles can set KBUILD_DEFCONFIG to tell kbuild the name of the
> >> defconfig that should be built by default.
> >>
> >> However currently there is an assumption that KBUILD_DEFCONFIG points to
> >> a file at arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG).
> >>
> >> We would like to use a target, using merge_config, as our defconfig, so
> >> adapt the logic in scripts/kconfig/Makefile to allow that.
> >>
> >> To minimise the chance of breaking anything, we first check if
> >> KBUILD_DEFCONFIG is a file, and if so we do the old logic. If it's not a
> >> file, then we call the top-level Makefile with KBUILD_DEFCONFIG as the
> >> target.
> >>
> >> Signed-off-by: Michael Ellerman 
> >> Acked-by: Michal Marek 
> >
> > Applied to powerpc next.
> >
> > https://git.kernel.org/powerpc/c/d2036f30cfe1daa19e63ce75
> 
> This breaks arm64 defconfig for me:
> 
> mkdir obj-tmp
> make -f Makefile O=obj-tmp ARCH=arm64 defconfig
> ... watch loop of:
> *** Default configuration is based on target 'defconfig'
>   GEN ./Makefile

Crap, sorry. I knew I shouldn't have touched that code!

Does this fix it for you?

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index b2b9c87..3043d6b 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -96,7 +96,7 @@ savedefconfig: $(obj)/conf
 defconfig: $(obj)/conf
 ifeq ($(KBUILD_DEFCONFIG),)
$< $(silent) --defconfig $(Kconfig)
-else ifneq ($(wildcard arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)),)
+else ifneq ($(wildcard 
$(srctree)/arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)),)
@$(kecho) "*** Default configuration is based on '$(KBUILD_DEFCONFIG)'"
$(Q)$< $(silent) 
--defconfig=arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig)
 else



$ make O=obj 
CROSS_COMPILE=/opt/cross/gcc-4.9.0-nolibc/aarch64-linux/bin/aarch64-linux- 
ARCH=arm64 defconfig
make[1]: Entering directory '/home/michael/kernels/linux-next/obj'
  HOSTCC  scripts/basic/fixdep
  GEN ./Makefile
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
*** Default configuration is based on 'defconfig'
#
# configuration written to .config
#
make[1]: Leaving directory '/home/michael/kernels/linux-next/obj'
$ head obj/.config
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm64 4.3.0-rc5 Kernel Configuration
#
CONFIG_ARM64=y
CONFIG_64BIT=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead


cheers


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

Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

[Michael Ellerman]

On Mon, 2015-10-12 at 22:30 +0800, Boqun Feng wrote:
> According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_
> versions all need to imply a full barrier, however they are now just
> RELEASE+ACQUIRE, which is not a full barrier.
> 
> So replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
> PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
> __{cmp,}xchg_{u32,u64} respectively to guarantee a full barrier
> semantics of atomic{,64}_{cmp,}xchg() and {cmp,}xchg().
> 
> This patch is a complement of commit b97021f85517 ("powerpc: Fix
> atomic_xxx_return barrier semantics").
> 
> Cc:  # 3.4.y-
> Signed-off-by: Boqun Feng 
> ---
>  arch/powerpc/include/asm/cmpxchg.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Hi Boqun,

Thanks for fixing this. In future you should send a patch like this as a
separate patch. I've not been paying attention to it because I assumed it was
part of your full series and was still under discussion like the other patches.

I don't think we've seen any crashes caused by this have we? So I guess I'll
put it in next to let it get some wider testing rather than sending it straight
to Linus.

To be clear you're doing:

> - PPC_RELEASE_BARRIER
> + PPC_ATOMIC_ENTRY_BARRIER

Which is correct but doesn't actually change anything at the moment, because
both macros turn into LWSYNC.

On the other hand:

> - PPC_ACQUIRE_BARRIER
> + PPC_ATOMIC_EXIT_BARRIER

Is changing an isync (which is then patched to lwsync on some cpus), with a 
sync.


Also I'm not clear what your stable line means:

> Cc:  # 3.4.y-

Do you mean 3.4 and anything after? I usually write that as 3.4+, but I'm not
sure if that's the correct syntax either.


cheers


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

Re: [PATCH] scripts/tags.sh: Teach tags about some powerpc macros

[Michael Ellerman]

On Tue, 2015-10-13 at 13:54 +0200, Michal Marek wrote:
> On 2015-10-13 07:18, Michael Ellerman wrote:
> > On Tue, 2015-09-22 at 13:08 +1000, Michael Ellerman wrote:
> >> The IO accessors on powerpc are generated using macro fu, ie. out_be32()
> >> etc. Also there are some debugger related symbols that are macro
> >> generated. Teach scripts/tags.sh about both.
> >>
> >> Signed-off-by: Michael Ellerman 
> >> ---
> >>  scripts/tags.sh | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/scripts/tags.sh b/scripts/tags.sh
> >> index 8e5aee6d9da2..262889046703 100755
> >> --- a/scripts/tags.sh
> >> +++ b/scripts/tags.sh
> >> @@ -198,6 +198,8 @@ exuberant()
> >>--regex-c++='/TASK_PFA_TEST\([^,]*,\s*([^)]*)\)/task_\1/'   \
> >>--regex-c++='/TASK_PFA_SET\([^,]*,\s*([^)]*)\)/task_set_\1/'\
> >>--regex-c++='/TASK_PFA_CLEAR\([^,]*,\s*([^)]*)\)/task_clear_\1/'\
> >> +  --regex-c++='/DEF_MMIO_(IN|OUT)_(X|D)\(([^,]*),\s*[^)]*\)/\3/'  \
> >> +  --regex-c++='/DEBUGGER_BOILERPLATE\(([^,]*)\)/\1/'  \
> >>--regex-c='/PCI_OP_READ\((\w*).*[1-4]\)/pci_bus_read_config_\1/' \
> >>--regex-c='/PCI_OP_WRITE\((\w*).*[1-4]\)/pci_bus_write_config_\1/' \
> >>--regex-c='/DEFINE_(MUTEX|SEMAPHORE|SPINLOCK)\((\w*)/\2/v/' \
> > 
> > 
> > Michal, do you want to take this one or should I ?
> 
> I applied it to kbuild.git#misc.

Thanks.

cheers


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

[PATCH] tty: disable unbind for old 74xx based serial/mpsc console port

[Paul Gortmaker]

We recently got rid of some modular code in this driver and also
got rid of the unused ".remove" function at the same time.  Thierry
noted that it was however possible to force the remove through the
bind/unbind interface.

Since this is a console device used on 2005 vintage 74xx based
powerpc embedded targets, and is essentially always used in
conjunction with SERIAL_MPSC_CONSOLE=y -- there is no sane reason
anyone would ever want to unbind the builtin driver and lose the
console.  So we just explicitly block bind/unbind operations and
prevent root from shooting themselves in the foot.

Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Thierry Reding 
Cc: linux-ser...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker 
---
 drivers/tty/serial/mpsc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/mpsc.c b/drivers/tty/serial/mpsc.c
index 2f43a58cb392..cadfd1cfae2b 100644
--- a/drivers/tty/serial/mpsc.c
+++ b/drivers/tty/serial/mpsc.c
@@ -2109,7 +2109,8 @@ static int mpsc_drv_probe(struct platform_device *dev)
 static struct platform_driver mpsc_driver = {
.probe  = mpsc_drv_probe,
.driver = {
-   .name   = MPSC_CTLR_NAME,
+   .name   = MPSC_CTLR_NAME,
+   .suppress_bind_attrs= true,
},
 };
 
-- 
2.6.1

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

[PATCH] powerpc: Delete old orphaned PrPMC 280/2800 DTS and boot file.

[Paul Gortmaker]

In commit 3c8464a9b12bf83807b6e2c896d7e7b633e1cae7 ("powerpc:
Delete old PrPMC 280/2800 support") we got rid of most of the C
code, and the Makefile/Kconfig hooks, but it seems I left the
platform's DTS file orphaned in the tree as well as the boot code.
Here we get rid of them both.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker 
---
 arch/powerpc/boot/dts/prpmc2800.dts | 297 ---
 arch/powerpc/boot/prpmc2800.c   | 571 
 2 files changed, 868 deletions(-)
 delete mode 100644 arch/powerpc/boot/dts/prpmc2800.dts
 delete mode 100644 arch/powerpc/boot/prpmc2800.c

diff --git a/arch/powerpc/boot/dts/prpmc2800.dts 
b/arch/powerpc/boot/dts/prpmc2800.dts
deleted file mode 100644
index 00afaacf8c8c..
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ /dev/null
@@ -1,297 +0,0 @@
-/* Device Tree Source for Motorola PrPMC2800
- *
- * Author: Mark A. Greer 
- *
- * 2007 (c) MontaVista, Software, Inc.  This file is licensed under
- * the terms of the GNU General Public License version 2.  This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- *
- * Property values that are labeled as "Default" will be updated by bootwrapper
- * if it can determine the exact PrPMC type.
- */
-
-/dts-v1/;
-
-/ {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   model = "PrPMC280/PrPMC2800"; /* Default */
-   compatible = "motorola,PrPMC2800";
-   coherency-off;
-
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   PowerPC,7447 {
-   device_type = "cpu";
-   reg = <0>;
-   clock-frequency = <7>;  /* Default */
-   bus-frequency = <1>;
-   timebase-frequency = <>;
-   i-cache-line-size = <32>;
-   d-cache-line-size = <32>;
-   i-cache-size = <32768>;
-   d-cache-size = <32768>;
-   };
-   };
-
-   memory {
-   device_type = "memory";
-   reg = <0x0 0x2000>; /* Default (512MB) */
-   };
-
-   system-controller@f100 { /* Marvell Discovery mv64360 */
-   #address-cells = <1>;
-   #size-cells = <1>;
-   model = "mv64360";  /* Default */
-   compatible = "marvell,mv64360";
-   clock-frequency = <1>;
-   reg = <0xf100 0x1>;
-   virtual-reg = <0xf100>;
-   ranges = <0x8800 0x8800 0x100 /* PCI 0 I/O Space */
- 0x8000 0x8000 0x800 /* PCI 0 MEM Space */
- 0xa000 0xa000 0x400 /* User FLASH */
- 0x 0xf100 0x001 /* Bridge's regs */
- 0xf200 0xf200 0x004>;/* Integrated SRAM */
-
-   flash@a000 {
-   device_type = "rom";
-   compatible = "direct-mapped";
-   reg = <0xa000 0x400>; /* Default (64MB) */
-   probe-type = "CFI";
-   bank-width = <4>;
-   partitions = <0x 0x0010 /* RO */
- 0x0010 0x00040001 /* RW */
- 0x0014 0x0040 /* RO */
- 0x0054 0x039c /* RO */
- 0x03f0 0x0010>; /* RO */
-   partition-names = "FW Image A", "FW Config Data", 
"Kernel Image", "Filesystem", "FW Image B";
-   };
-
-   mdio {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "marvell,mv64360-mdio";
-   PHY0: ethernet-phy@1 {
-   compatible = "broadcom,bcm5421";
-   interrupts = <76>;  /* GPP 12 */
-   interrupt-parent = <>;
-   reg = <1>;
-   };
-   PHY1: ethernet-phy@3 {
-   compatible = "broadcom,bcm5421";
-   interrupts = <76>;  /* GPP 12 */
-   interrupt-parent = <>;
-   reg = <3>;
-   };
-   };
-
-   ethernet-group@2000 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = 

Re: [PATCH v2 2/8] powerpc/eeh: More relexed hotplug criterion

[Daniel Axtens]

Gavin Shan  writes:


> I think you're talking about the situation reported from the bug. It's
> CAN_RECOVER instead of NONE returned from error_detected(). With the
> CAN_RECOVER, the driver hopes the EEH core to enable the IO path so that
> it can collect diag-data from IO space at late point.

Oh. That's an interesting decision from the driver's point of view.

I obviously need to re-read the patch and the surrounding code and try
again to make sense of it later. Thanks for your attempts to explain it!

Regards,
Daniel

>
>>Partial hotplug is pretty hacky to begin with, and a driver being able
>>to opt out of EEH selectively is a useful feature, so we probably want
>>to redesign the state machine to handle them both better. That would be
>>a long term project.
>>
>
> Thanks,
> Gavin
>
> Signed-off-by: Gavin Shan 
> ---
>  arch/powerpc/kernel/eeh_driver.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/eeh_driver.c 
> b/arch/powerpc/kernel/eeh_driver.c
> index 3a626ed..32178a4 100644
> --- a/arch/powerpc/kernel/eeh_driver.c
> +++ b/arch/powerpc/kernel/eeh_driver.c
> @@ -416,7 +416,10 @@ static void *eeh_rmv_device(void *data, void 
> *userdata)
>   driver = eeh_pcid_get(dev);
>   if (driver) {
>   eeh_pcid_put(dev);
> - if (driver->err_handler)
> + if (driver->err_handler &&
> + driver->err_handler->error_detected &&
> + driver->err_handler->slot_reset &&
> + driver->err_handler->resume)
>   return NULL;
>   }
>  
> -- 
> 2.1.0
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

[Boqun Feng]

On Wed, Oct 14, 2015 at 11:10:00AM +1100, Michael Ellerman wrote:
> On Mon, 2015-10-12 at 22:30 +0800, Boqun Feng wrote:
> > According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_
> > versions all need to imply a full barrier, however they are now just
> > RELEASE+ACQUIRE, which is not a full barrier.
> > 
> > So replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
> > PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
> > __{cmp,}xchg_{u32,u64} respectively to guarantee a full barrier
> > semantics of atomic{,64}_{cmp,}xchg() and {cmp,}xchg().
> > 
> > This patch is a complement of commit b97021f85517 ("powerpc: Fix
> > atomic_xxx_return barrier semantics").
> > 
> > Cc:  # 3.4.y-
> > Signed-off-by: Boqun Feng 
> > ---
> >  arch/powerpc/include/asm/cmpxchg.h | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> Hi Boqun,
> 

Hello, Michael

> Thanks for fixing this. In future you should send a patch like this as a
> separate patch. I've not been paying attention to it because I assumed it was

Got it. However, here is the thing, in previous version, this fix
depends on some of other patches in this patchset. So to make this fix
applied cleanly, I reorder my patchset to put this patch first, and the
result is that some of other patches in this patchset depends on
this(they need to remove code modified by this patch).

So I guess I'd better to stop Cc stable for this one, and wait until
this patchset merged and send a separate patch for -stable tree. Does
that work for you? I think this is what Peter want to suggests me to do
when he asked me about this, right, Peter?

> part of your full series and was still under discussion like the other 
> patches.
> 
> I don't think we've seen any crashes caused by this have we? So I guess I'll

No, we haven't seen any.

> put it in next to let it get some wider testing rather than sending it 
> straight
> to Linus.
> 

Good idea, thank you ;-)

> To be clear you're doing:
> 
> > -   PPC_RELEASE_BARRIER
> > +   PPC_ATOMIC_ENTRY_BARRIER
> 
> Which is correct but doesn't actually change anything at the moment, because
> both macros turn into LWSYNC.
> 
> On the other hand:
> 
> > -   PPC_ACQUIRE_BARRIER
> > +   PPC_ATOMIC_EXIT_BARRIER
> 
> Is changing an isync (which is then patched to lwsync on some cpus), with a 
> sync.
> 

These macros are introduced by commit b97021f85517 ("powerpc: Fix
atomic_xxx_return barrier semantics") to fix a similar problem, so I use
them to keep code similar.

> 
> Also I'm not clear what your stable line means:
> 
> > Cc:  # 3.4.y-
> 
> Do you mean 3.4 and anything after? I usually write that as 3.4+, but I'm not
> sure if that's the correct syntax either.
> 

Quote from Documentation/stable_kernel_rules.txt:

"""
Also, some patches may have kernel version prerequisites.  This can be
specified in the following format in the sign-off area:

 Cc:   # 3.3.x-

   The tag has the meaning of:
 git cherry-pick 

   For each "-stable" tree starting with the specified version.
"""

But yes, I have seen several people use like "3.4+", I'm not sure either

Regards,
Boqun


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 4/6] powerpc: atomic: Implement atomic{, 64}_*_return_* variants

[Boqun Feng]

On Tue, Oct 13, 2015 at 09:35:54PM +0800, Boqun Feng wrote:
> On Tue, Oct 13, 2015 at 02:21:32PM +0100, Will Deacon wrote:
> > On Mon, Oct 12, 2015 at 10:14:04PM +0800, Boqun Feng wrote:
> [snip]
> > > +/*
> > > + * Since {add,sub}_return_relaxed and xchg_relaxed are implemented with
> > > + * a "bne-" instruction at the end, so an isync is enough as a acquire 
> > > barrier
> > > + * on the platform without lwsync.
> > > + */
> > > +#ifdef CONFIG_SMP
> > > +#define smp_acquire_barrier__after_atomic() \
> > > + __asm__ __volatile__(PPC_ACQUIRE_BARRIER : : : "memory")
> > 
> > I'm not keen on this barrier, as it sounds like it's part of the kernel
> > memory model, as opposed to an implementation detail on PowerPC (and
> > we've already got enough of that in the generic code ;).
> > 
> 
> Indeed, but we still have smp_lwsync() ;-)
> 
> > Can you name it something different please (and maybe #undef it when
> > you're done)?
> > 
> 
> I've considered #undef it after used, but now I think open code this
> into __atomic_op_acquire() of PPC is a better idea?
> 
> 
> #define __atomic_op_acquire(op, args...)  \
> ({\
>   typeof(op##_relaxed(args)) __ret  = op##_relaxed(args); \
>   __asm__ __volatile__(PPC_ACQUIRE_BARRIER : : : "memory");   \

Should be:
__asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory");

>   __ret;  \
> })
> 
> PPC_ACQUIRE_BARRIER will be empty if !SMP, so that will become a pure
> compiler barrier and just what we need.
> 
> Regards,
> Boqun


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V5 3/6] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR

[Gavin Shan]

On Tue, Oct 13, 2015 at 01:29:44PM +0800, Wei Yang wrote:
>On Tue, Oct 13, 2015 at 02:32:49PM +1100, Gavin Shan wrote:
>>On Tue, Oct 13, 2015 at 10:50:42AM +0800, Wei Yang wrote:
>>>On Tue, Oct 13, 2015 at 10:55:27AM +1100, Gavin Shan wrote:
On Fri, Oct 09, 2015 at 10:46:53AM +0800, Wei Yang wrote:
>In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
>BARs in Single PE mode to cover the number of VFs required to be enabled.
>By doing so, several VFs would be in one VF Group and leads to interference
>between VFs in the same group.
>
>And in this patch, m64_wins is renamed to m64_map, which means index number
>of the M64 BAR used to map the VF BAR. Based on Gavin's comments.
>
>This patch changes the design by using one M64 BAR in Single PE mode for
>one VF BAR. This gives absolute isolation for VFs.
>
>Signed-off-by: Wei Yang 
>Reviewed-by: Gavin Shan 
>Acked-by: Alexey Kardashevskiy 
>---
> arch/powerpc/include/asm/pci-bridge.h |   5 +-
> arch/powerpc/platforms/powernv/pci-ioda.c | 169 
> --
> 2 files changed, 68 insertions(+), 106 deletions(-)
>
>diff --git a/arch/powerpc/include/asm/pci-bridge.h 
>b/arch/powerpc/include/asm/pci-bridge.h
>index 712add5..8aeba4c 100644
>--- a/arch/powerpc/include/asm/pci-bridge.h
>+++ b/arch/powerpc/include/asm/pci-bridge.h
>@@ -214,10 +214,9 @@ struct pci_dn {
>   u16 vfs_expanded;   /* number of VFs IOV BAR expanded */
>   u16 num_vfs;/* number of VFs enabled*/
>   int offset; /* PE# for the first VF PE */
>-#define M64_PER_IOV 4
>-  int m64_per_iov;
>+  boolm64_single_mode;/* Use M64 BAR in Single Mode */
> #define IODA_INVALID_M64(-1)
>-  int m64_wins[PCI_SRIOV_NUM_BARS][M64_PER_IOV];
>+  int (*m64_map)[PCI_SRIOV_NUM_BARS];
> #endif /* CONFIG_PCI_IOV */
> #endif
>   struct list_head child_list;
>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
>b/arch/powerpc/platforms/powernv/pci-ioda.c
>index 7da476b..2886f90 100644
>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>@@ -1148,29 +1148,36 @@ static void pnv_pci_ioda_setup_PEs(void)
> }
>
> #ifdef CONFIG_PCI_IOV
>-static int pnv_pci_vf_release_m64(struct pci_dev *pdev)
>+static int pnv_pci_vf_release_m64(struct pci_dev *pdev, u16 num_vfs)
> {
>   struct pci_bus*bus;
>   struct pci_controller *hose;
>   struct pnv_phb*phb;
>   struct pci_dn *pdn;
>   inti, j;
>+  intm64_bars;
>
>   bus = pdev->bus;
>   hose = pci_bus_to_host(bus);
>   phb = hose->private_data;
>   pdn = pci_get_pdn(pdev);
>
>+  if (pdn->m64_single_mode)
>+  m64_bars = num_vfs;
>+  else
>+  m64_bars = 1;
>+
>   for (i = 0; i < PCI_SRIOV_NUM_BARS; i++)
>-  for (j = 0; j < M64_PER_IOV; j++) {
>-  if (pdn->m64_wins[i][j] == IODA_INVALID_M64)
>+  for (j = 0; j < m64_bars; j++) {
>+  if (pdn->m64_map[j][i] == IODA_INVALID_M64)
>   continue;
>   opal_pci_phb_mmio_enable(phb->opal_id,
>-  OPAL_M64_WINDOW_TYPE, pdn->m64_wins[i][j], 0);
>-  clear_bit(pdn->m64_wins[i][j], 
>>ioda.m64_bar_alloc);
>-  pdn->m64_wins[i][j] = IODA_INVALID_M64;
>+  OPAL_M64_WINDOW_TYPE, pdn->m64_map[j][i], 0);
>+  clear_bit(pdn->m64_map[j][i], >ioda.m64_bar_alloc);
>+  pdn->m64_map[j][i] = IODA_INVALID_M64;
>   }
>
>+  kfree(pdn->m64_map);
>   return 0;
> }
>
>@@ -1187,8 +1194,7 @@ static int pnv_pci_vf_assign_m64(struct pci_dev 
>*pdev, u16 num_vfs)
>   inttotal_vfs;
>   resource_size_tsize, start;
>   intpe_num;
>-  intvf_groups;
>-  intvf_per_group;
>+  intm64_bars;
>
>   bus = pdev->bus;
>   hose = pci_bus_to_host(bus);
>@@ -1196,26 +1202,26 @@ static int pnv_pci_vf_assign_m64(struct pci_dev 
>*pdev, u16 num_vfs)
>   pdn = pci_get_pdn(pdev);
>   total_vfs = pci_sriov_get_totalvfs(pdev);
>
>-  /* Initialize the m64_wins to IODA_INVALID_M64 */
>-  for (i = 0; i < PCI_SRIOV_NUM_BARS; i++)
>-  for (j = 0; j < M64_PER_IOV; j++)
>-  pdn->m64_wins[i][j] = IODA_INVALID_M64;
>+  if (pdn->m64_single_mode)
>+  m64_bars = num_vfs;
>+  else
>+  m64_bars = 1;
>+

Re: [PATCH V5 2/6] powerpc/powernv: simplify the calculation of iov resource alignment

[Gavin Shan]

On Tue, Oct 13, 2015 at 11:56:43AM +0800, Wei Yang wrote:
>On Tue, Oct 13, 2015 at 02:27:52PM +1100, Gavin Shan wrote:
>>On Tue, Oct 13, 2015 at 10:45:45AM +0800, Wei Yang wrote:
>>>On Tue, Oct 13, 2015 at 11:13:50AM +1100, Gavin Shan wrote:
On Fri, Oct 09, 2015 at 10:46:52AM +0800, Wei Yang wrote:
>The alignment of IOV BAR on PowerNV platform is the total size of the IOV
>BAR. No matter whether the IOV BAR is extended with number of
>roundup_pow_of_two(total_vfs) or number of max PE number (256), the total
>size could be calculated by (vfs_expanded * VF_BAR_size).
>
>This patch simplifies the pnv_pci_iov_resource_alignment() by removing the
>first case.
>
>Signed-off-by: Wei Yang 
>Reviewed-by: Gavin Shan 
>Acked-by: Alexey Kardashevskiy 
>---
> arch/powerpc/platforms/powernv/pci-ioda.c | 20 
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
>b/arch/powerpc/platforms/powernv/pci-ioda.c
>index 8c031b5..7da476b 100644
>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>@@ -2988,17 +2988,21 @@ static resource_size_t 
>pnv_pci_iov_resource_alignment(struct pci_dev *pdev,
> int resno)
> {
>   struct pci_dn *pdn = pci_get_pdn(pdev);
>-  resource_size_t align, iov_align;
>-
>-  iov_align = resource_size(>resource[resno]);
>-  if (iov_align)
>-  return iov_align;
>+  resource_size_t align;
>
>+  /*
>+   * On PowerNV platform, IOV BAR is mapped by M64 BAR to enable the
>+   * SR-IOV. While from hardware perspective, the range mapped by M64
>+   * BAR should be size aligned.
>+   *
>+   * This function returns the total IOV BAR size if M64 BAR is in
>+   * Shared PE mode or just the individual size if not.
>+   */

s/the invidial size/VF BAR size

>   align = pci_iov_resource_size(pdev, resno);
>-  if (pdn->vfs_expanded)
>-  return pdn->vfs_expanded * align;
>+  if (!pdn->vfs_expanded)
>+  return align;
>
>-  return align;
>+  return pdn->vfs_expanded * align;

There is no difference before/after the changes. why this change is needed?

>>>
>>>After change the logic is more clear.
>>>
>>>Alignment equals to the total size when IOV BAR is expanded or equals to the
>>>VF BAR size. We don't need to check whether IOV BAR is truncated.
>>>
>>
>>I didn't get what you're talking about with "IOV BAR is truncated". I also
>>didn't get what has been really changed from last 3 lines changes.
>>
>>  if (pdn->vfs_expanded)  if (!pdn->vfs_expanded)
>>  return pdn->vfs_expanded * align;   return align;
>>  return align;   return 
>> pdn->vfs_expanded * align;
>>
>
>Truncated IOV BAR resource happens during sizing state, since IOV BAR is
>optional. While we still need to get the correct alignment during this
>process.
>

I don't see how your claim here is related. And, the IOV BAR can be
expanded as well depending on how much VFs the PF is going to support
virtually based on IOV BAR size.

>The code before and after change has the same meaning, while the later one is
>prepared for the single mode M64 BAR. You could look at the final version
>after single mode M64 is introduced.
>

I still don't see any strong reason to have this - nothing changed, but
it's not a big deal, I guess...

> }
> #endif /* CONFIG_PCI_IOV */
>
>-- 
>2.5.0
>
>>>
>>>-- 
>>>Richard Yang
>>>Help you, Help me
>
>-- 
>Richard Yang
>Help you, Help me

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

Re: [PATCH v2 2/8] powerpc/eeh: More relexed hotplug criterion

[Gavin Shan]

On Wed, Oct 14, 2015 at 10:48:15AM +1100, Daniel Axtens wrote:
>Gavin Shan  writes:
>> I think you're talking about the situation reported from the bug. It's
>> CAN_RECOVER instead of NONE returned from error_detected(). With the
>> CAN_RECOVER, the driver hopes the EEH core to enable the IO path so that
>> it can collect diag-data from IO space at late point.
>
>Oh. That's an interesting decision from the driver's point of view.
>
>I obviously need to re-read the patch and the surrounding code and try
>again to make sense of it later. Thanks for your attempts to explain it!
>

Yeah, that was the tricky solution we had after discussion. Obviously,
that's breaking EEH core's assumption that driver implements all error
handlers or none of them as you said. Unfortunately, I think there might
have more drivers to continue breaking but EEH core has to support. On
the other hand, the error handlers could be used for purposes other than
recovery, which is good.

Thanks,
Gavin

>>
>>>Partial hotplug is pretty hacky to begin with, and a driver being able
>>>to opt out of EEH selectively is a useful feature, so we probably want
>>>to redesign the state machine to handle them both better. That would be
>>>a long term project.
>>>

>> Signed-off-by: Gavin Shan 
>> ---
>>  arch/powerpc/kernel/eeh_driver.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/eeh_driver.c 
>> b/arch/powerpc/kernel/eeh_driver.c
>> index 3a626ed..32178a4 100644
>> --- a/arch/powerpc/kernel/eeh_driver.c
>> +++ b/arch/powerpc/kernel/eeh_driver.c
>> @@ -416,7 +416,10 @@ static void *eeh_rmv_device(void *data, void 
>> *userdata)
>>  driver = eeh_pcid_get(dev);
>>  if (driver) {
>>  eeh_pcid_put(dev);
>> -if (driver->err_handler)
>> +if (driver->err_handler &&
>> +driver->err_handler->error_detected &&
>> +driver->err_handler->slot_reset &&
>> +driver->err_handler->resume)
>>  return NULL;
>>  }
>>  
>> -- 
>> 2.1.0
>>
>> ___
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev


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

Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants

[Boqun Feng]

On Tue, Oct 13, 2015 at 04:04:27PM +0100, Will Deacon wrote:
> On Tue, Oct 13, 2015 at 10:58:30PM +0800, Boqun Feng wrote:
> > On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote:
> > > Putting a barrier in the middle of that critical section is probably a
> > > terrible idea, and that's why I thought you were avoiding it (hence my
> > 
> > The fact is that I haven't thought of that way to implement
> > cmpxchg_release before you ask that question ;-) And I'm not going to do
> > that for now and probably not in the future.
> > 
> > > original question). Perhaps just add a comment to that effect, since I
> > 
> > Are you suggesting if I put a barrier in the middle I'd better to add a
> > comment, right? So if I don't do that, it's OK to let this patch as it.
> 
> No, I mean put a comment in your file to explain the reason why you
> override _relaxed and _acquire, but not _release (because overriding

You mean overriding _acquire and fully order version, right?

> _release would introduce this weird barrier in the middle of the critical
> section, which would likely cause the conditional store to fail).
> 
> Will


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev