Re: [PATCH] powerpc: thp: Use tlbiel wherever possible

2014-08-06 Thread Aneesh Kumar K.V
Benjamin Herrenschmidt  writes:

> On Wed, 2014-08-06 at 20:16 +0530, Aneesh Kumar K.V wrote:
>> "Aneesh Kumar K.V"  writes:
>> 
>> > If we know that user address space has never executed on other cpus
>> > we could use tlbiel.
>> >
>> > Signed-off-by: Aneesh Kumar K.V 
>> 
>> Now checking against flush_hash_page, I am wondering whether I need to handle
>> transcational memory in case of tlbiel ? Michael, can you let me know if
>> this is needed ?
>
> Also, beware that we have code that sets "tlbiel" in the page definition
> array to 0 on all but 4k and 64k pages...
>

Ok we use base page size to determine whether we can use tlbiel or not. 

static inline void tlbie(unsigned long vpn, int psize, int apsize,
 int ssize, int local)
{

if (use_local)
use_local = mmu_psize_defs[psize].tlbiel;

With that we should be ok, because we are using 4k and 64k base page
size and we have

/*
 * We don't know for sure what's up with tlbiel, so
 * for now we only set it for 4K and 64K pages
 */
if (base_idx == MMU_PAGE_4K || base_idx == MMU_PAGE_64K)
def->tlbiel = 1;
else
def->tlbiel = 0;


-aneesh

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

[PATCH 2/2] powerpc: Add smp_mb()s to arch_spin_unlock_wait()

2014-08-06 Thread Michael Ellerman
Similar to the previous commit which described why we need to add a
barrier to arch_spin_is_locked(), we have a similar problem with
spin_unlock_wait().

We need a barrier on entry to ensure any spinlock we have previously
taken is visibly locked prior to the load of lock->slock.

It's also not clear if spin_unlock_wait() is intended to have ACQUIRE
semantics. For now be conservative and add a barrier on exit to give it
ACQUIRE semantics.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/lib/locks.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index 0c9c8d7d0734..170a0346f756 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -70,12 +70,16 @@ void __rw_yield(arch_rwlock_t *rw)
 
 void arch_spin_unlock_wait(arch_spinlock_t *lock)
 {
+   smp_mb();
+
while (lock->slock) {
HMT_low();
if (SHARED_PROCESSOR)
__spin_yield(lock);
}
HMT_medium();
+
+   smp_mb();
 }
 
 EXPORT_SYMBOL(arch_spin_unlock_wait);
-- 
1.9.1

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

[PATCH 1/2] powerpc: Add smp_mb() to arch_spin_is_locked()

2014-08-06 Thread Michael Ellerman
The kernel defines the function spin_is_locked(), which can be used to
check if a spinlock is currently locked.

Using spin_is_locked() on a lock you don't hold is obviously racy. That
is, even though you may observe that the lock is unlocked, it may become
locked at any time.

There is (at least) one exception to that, which is if two locks are
used as a pair, and the holder of each checks the status of the other
before doing any update.

Assuming *A and *B are two locks, and *COUNTER is a shared non-atomic
value:

The first CPU does:

spin_lock(*A)

if spin_is_locked(*B)
# nothing
else
smp_mb()
LOAD r = *COUNTER
r++
STORE *COUNTER = r

spin_unlock(*A)

And the second CPU does:

spin_lock(*B)

if spin_is_locked(*A)
# nothing
else
smp_mb()
LOAD r = *COUNTER
r++
STORE *COUNTER = r

spin_unlock(*B)

Although this is a strange locking construct, it should work.

It seems to be understood, but not documented, that spin_is_locked() is
not a memory barrier, so in the examples above and below the caller
inserts its own memory barrier before acting on the result of
spin_is_locked().

For now we assume spin_is_locked() is implemented as below, and we break
it out in our examples:

bool spin_is_locked(*LOCK) {
LOAD l = *LOCK
return l.locked
}

Our intuition is that there should be no problem even if the two code
sequences run simultaneously such as:

CPU 0   CPU 1
==
spin_lock(*A)   spin_lock(*B)
LOAD b = *B LOAD a = *A
if b.locked # true  if a.locked # true
# nothing   # nothing
spin_unlock(*A) spin_unlock(*B)

If one CPU gets the lock before the other then it will do the update and
the other CPU will back off:

CPU 0   CPU 1
==
spin_lock(*A)
LOAD b = *B
spin_lock(*B)
if b.locked # false LOAD a = *A
elseif a.locked # true
smp_mb()# nothing
LOAD r1 = *COUNTER  spin_unlock(*B)
r1++
STORE *COUNTER = r1
spin_unlock(*A)

However in reality spin_lock() itself is not indivisible. On powerpc we
implement it as a load-and-reserve and store-conditional.

Ignoring the retry logic for the lost reservation case, it boils down to:
spin_lock(*LOCK) {
LOAD l = *LOCK
l.locked = true
STORE *LOCK = l
ACQUIRE_BARRIER
}

The ACQUIRE_BARRIER is required to give spin_lock() ACQUIRE semantics as
defined in memory-barriers.txt:

 This acts as a one-way permeable barrier.  It guarantees that all
 memory operations after the ACQUIRE operation will appear to happen
 after the ACQUIRE operation with respect to the other components of
 the system.

On modern powerpc systems we use lwsync for ACQUIRE_BARRIER. lwsync is
also know as "lightweight sync", or "sync 1".

As described in Power ISA v2.07 section B.2.1.1, in this scenario the
lwsync is not the barrier itself. It instead causes the LOAD of *LOCK to
act as the barrier, preventing any loads or stores in the locked region
from occurring prior to the load of *LOCK.

Whether this behaviour is in accordance with the definition of ACQUIRE
semantics in memory-barriers.txt is open to discussion, we may switch to
a different barrier in future.

What this means in practice is that the following can occur:

CPU 0   CPU 1
==
LOAD a = *A LOAD b = *B
a.locked = true b.locked = true
LOAD b = *B LOAD a = *A
STORE *A = aSTORE *B = b
if b.locked # false if a.locked # false
elseelse
smp_mb()smp_mb()
LOAD r1 = *COUNTER  LOAD r2 = *COUNTER
r1++r2++
STORE *COUNTER = r1
STORE *COUNTER = r2 # Lost update
spin_unlock(*A) spin_unlock(*B)

That is, the load of *B can occur prior to the store that makes *A
visibly locked. And similarly for CPU 1. The result is both CPUs hold
their lock and believe the other lock is unlocked.

The easiest fix for this is to add a full memory barrier to the start of
spin_is_locked(), so adding to our previous definition would give us:

bool spin_is_locked(*LOCK) {
smp_mb()
LOAD l = *LOCK
return l.locked
}

The new barrier orders the store to the lock we are lockin

[git pull] Please pull powerpc.git next branch

2014-08-06 Thread Benjamin Herrenschmidt
Hi Linus !

First an apology ... a lot of the stuff in there was only very recently
committed. This is not the normal process. I'm at fault here, my only
excuse is having been insanely swamped with other things. That's one of
the reasons for co-opting Michael as co-maintainer, to help with
avoiding that sort of trainwreck in the future.

The redeeming thing (if any) is that most of the patches were actually
reviewed on patchwork for a while, went through several iterations, and
in some cases fairly well tested in other places. Additionally the bulk
of the "new" stuff is fairly platform specific with little risk of
negatively impacting integration with other things.

There's the VFIO bit that doesn't fit in that category, but I gave Alex
the heads up already, he will probably send you some additional bits on
top of it before the end of this week.

Now for the content: This is the powerpc new goodies for 3.17. The short
story:

The biggest bit is Michael removing all of pre-POWER4 processor support
from the 64-bit kernel. POWER3 and rs64. This gets rid of a ton of old
cruft that has been bitrotting in a long while. It was broken for quite
a few versions already and nobody noticed. Nobody uses those machines
anymore. While at it, he cleaned up a bunch of old dusty cabinets,
getting rid of a skeletton or two.

Then, we have some base VFIO support for KVM, which allows assigning of
PCI devices to KVM guests, support for large 64-bit BARs on "powernv"
platforms, support for HMI (Hardware Management Interrupts) on those
same platforms, some sparse-vmemmap improvements (for memory hotplug),

There is the usual batch of Freescale embedded updates (summary in the
merge commit) and fixes here or there, I think that's it for the
highlights.

Cheers,
Ben.

The following changes since commit 6f5405bc2ee0102bb3856e2cdea64ff415db2e0c:

  powerpc: use _GLOBAL_TOC for memmove (2014-07-22 15:56:04 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next

for you to fetch changes up to 537e5400a0a05c4efe70e7b372c19cfcd0179362:

  powerpc/eeh: Export eeh_iommu_group_to_pe() (2014-08-07 13:00:02 +1000)


Alexey Kardashevskiy (4):
  powerpc/powernv: Use it_page_shift for TCE invalidation
  powerpc/powernv: Use it_page_shift in TCE build
  powerpc/powernv: Add a page size parameter to pnv_pci_setup_iommu_table()
  powerpc/iommu: Fix comments with it_page_shift

Andrey Utkin (1):
  powerpc/mm/numa: Fix break placement

Andy Fleming (1):
  powerpc/e6500: Add support for hardware threads

Anton Blanchard (3):
  powerpc/pseries: Use jump labels for hcall tracepoints
  powerpc/pseries: Optimise hcall tracepoints
  powernv: Add OPAL tracepoints

Benjamin Herrenschmidt (5):
  Merge branch 'merge' into next
  Merge branch 'merge' into next
  Add Michael Ellerman as powerpc co-maintainer
  Merge remote-tracking branch 'scott/next' into next
  powerpc/eeh: Add missing #ifdef CONFIG_IOMMU_API

Bharat Bhushan (1):
  booke/powerpc: define wimge shift mask to fix compilation error

Brian W Hart (1):
  powerpc/powernv: Update dev->dma_mask in pci_set_dma_mask() path

Chunhe Lan (2):
  t4240/dts: Enable third elo3 DMA engine support
  powerpc/85xx: Add T4240RDB board support

Gavin Shan (17):
  powerpc/eeh: Avoid event on passed PE
  powerpc/eeh: EEH support for VFIO PCI device
  drivers/vfio: EEH support for VFIO PCI device
  powerpc/powernv: Fix IOMMU table for VFIO dev
  powerpc/eeh: Fetch IOMMU table in reliable way
  powerpc/eeh: Refactor EEH flag accessors
  powerpc/eeh: Selectively enable IO for error log
  powerpc/eeh: Reduce lines of log dump
  powerpc/eeh: Replace pr_warning() with pr_warn()
  powerpc/eeh: Make diag-data not endian dependent
  powerpc/eeh: Aux PE data for error log
  powerpc/powernv: Allow to freeze PE
  powerpc/powernv: Split ioda_eeh_get_state()
  powerpc/powernv: Handle compound PE
  powerpc/powernv: Handle compound PE for EEH
  powerpc/powernv: Handle compound PE in config accessors
  powerpc/eeh: Export eeh_iommu_group_to_pe()

Guo Chao (1):
  powerpc/powernv: Enable M64 aperatus for PHB3

Himangi Saraogi (2):
  powerpc/mpic_msgr: Use kcalloc and correct the argument to sizeof
  powerpc/fsl-pci: Correct use of ! and &

Laurentiu TUDOR (1):
  powerpc/85xx: drop hypervisor specific board compatibles

Laurentiu Tudor (1):
  powerpc/booke64: wrap tlb lock and search in htw miss with FTR_SMT

Li Zhong (4):
  powerpc: implement vmemmap_list_free()
  powerpc: implement vmemmap_remove_mapping() for BOOK3S
  powerpc: implement vmemmap_free()
  powerpc: start loop at section start of start in vmemmap_populated()

Lucas Tanure (1):
  powerpc: Fix wrong defintion in boot/io.h

Madhusudanan Kandasamy (1):
  powerpc: Fail r

Re: [alsa-devel] [PATCH V1 1/2] ASoC: fsl: esai: refine esai for tdm support

2014-08-06 Thread Nicolin Chen
About the title, please follow the old pattern:

ASoC: fsl_esai: Refine

You can get the history from 'git log --oneline sound/soc/fsl/fsl_esai.c'

On Wed, Aug 06, 2014 at 06:23:03PM +0800, Shengjiu Wang wrote:
> Add parameter for slots, and caculate the number of TX/RX pins and bclk with
> slots. Then driver will be compatible with slots > 2 in TDM mode.

Hmm...although I totally understand what the patch's exactly improving,
I suggest to describe more so that other people can get a quick idea
even without looking at the code, like what the original driver lacks
or what's the problem of the original design, how this patch fulfills
this feature and why some change have to be done, those change in the
header file for example.

> Signed-off-by: Shengjiu Wang 
> ---
>  sound/soc/fsl/fsl_esai.c |   10 +++---
>  sound/soc/fsl/fsl_esai.h |8 
>  2 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
> index 72d154e..89aa531 100644
> --- a/sound/soc/fsl/fsl_esai.c
> +++ b/sound/soc/fsl/fsl_esai.c
> @@ -56,6 +56,7 @@ struct fsl_esai {
>   struct clk *fsysclk;
>   u32 fifo_depth;
>   u32 slot_width;
> + u32 slots;
>   u32 hck_rate[2];
>   u32 sck_rate[2];
>   bool hck_dir[2];

Please append a description for the new member to the existing comments
above the structure define.

> @@ -363,6 +364,7 @@ static int fsl_esai_set_dai_tdm_slot(struct snd_soc_dai 
> *dai, u32 tx_mask,
>  ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(rx_mask));
>  
>   esai_priv->slot_width = slot_width;
> + esai_priv->slots  = slots;

I prefer not to add indentation here, even thought this doesn't hurt.
Just...If there's going to be a subsequent patch adding a new member
assignment whose name's longer than slot_width, the style'll be broken
as well. For example:
esai_priv->slot_width = slot_width;
esai_priv->slots  = slots;
esai_priv->slot_samplebit = slots;

The indentation for the 'slots' will look abnormal.

>  
>   return 0;
>  }
> @@ -510,10 +512,11 @@ static int fsl_esai_hw_params(struct snd_pcm_substream 
> *substream,
>   bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
>   u32 width = snd_pcm_format_width(params_format(params));
>   u32 channels = params_channels(params);
> + u32 pin = DIV_ROUND_UP(channels, esai_priv->slots);

This may cause a 'Division by zero' here. The 'slots' is only assigned
in set_dai_tdm_slot(). As default, a machine driver who does not call
set_dai_tdm_slot() will get a zero slot. We must give 'slots' a default
value (2 for example) somewhere during initialization.

And another personal suggestion -- using name 'pins' might be better.

Thank you Shengjiu,
Nicolin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: Fix warnings about right shift count

2014-08-06 Thread Nick Krause
Fix warnings like the following using upper_32_bits(), discussed after mail with
someone on kernelnewbies

arch/powerpc/boot/addnote.c:183:3: warning: right shift count >= width of type
arch/powerpc/boot/addnote.c:188:3: warning: right shift count >= width of type
arch/powerpc/boot/addnote.c:206:3: warning: right shift count >= width of type
arch/powerpc/boot/addnote.c:211:3: warning: right shift count >= width of type

Signed-off-by: Nick Krause 
---
 arch/powerpc/boot/addnote.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/addnote.c b/arch/powerpc/boot/addnote.c
index 9d9f6f3..4611c12 100644
--- a/arch/powerpc/boot/addnote.c
+++ b/arch/powerpc/boot/addnote.c
@@ -72,7 +72,7 @@ static int e_class = ELFCLASS32;
 #define PUT_16BE(off, v)(buf[off] = ((v) >> 8) & 0xff, \
 buf[(off) + 1] = (v) & 0xff)
 #define PUT_32BE(off, v)(PUT_16BE((off), (v) >> 16L), PUT_16BE((off) + 2, (v)))
-#define PUT_64BE(off, v)((PUT_32BE((off), (v) >> 32L), \
+#define PUT_64BE(off, v)((PUT_32BE((off), upper_32_bits(v)), \
  PUT_32BE((off) + 4, (v
 
 #define GET_16LE(off)  ((buf[off]) + (buf[(off)+1] << 8))
@@ -82,7 +82,8 @@ static int e_class = ELFCLASS32;
 #define PUT_16LE(off, v) (buf[off] = (v) & 0xff, \
  buf[(off) + 1] = ((v) >> 8) & 0xff)
 #define PUT_32LE(off, v) (PUT_16LE((off), (v)), PUT_16LE((off) + 2, (v) >> 
16L))
-#define PUT_64LE(off, v) (PUT_32LE((off), (v)), PUT_32LE((off) + 4, (v) >> 
32L))
+#define PUT_64LE(off, v) (PUT_32LE((off), (v)), PUT_32LE((off) + 4, \
+   upper_32_bits(v)))
 
 #define GET_16(off)(e_data == ELFDATA2MSB ? GET_16BE(off) : GET_16LE(off))
 #define GET_32(off)(e_data == ELFDATA2MSB ? GET_32BE(off) : GET_32LE(off))
-- 
2.0.1

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

[PATCH v4 3/5] drivers/vfio: Fix EEH build error

2014-08-06 Thread Gavin Shan
The VFIO related components could be built as dynamic modules.
Unfortunately, CONFIG_EEH can't be configured to "m". The patch
fixes the build errors when configuring VFIO related components
as dynamic modules as follows:

  CC [M]  drivers/vfio/vfio_iommu_spapr_tce.o
In file included from drivers/vfio/vfio.c:33:0:
include/linux/vfio.h:101:43: warning: ‘struct pci_dev’ declared \
inside parameter list [enabled by default]
   :
  WRAParch/powerpc/boot/zImage.pseries
  WRAParch/powerpc/boot/zImage.maple
  WRAParch/powerpc/boot/zImage.pmac
  WRAParch/powerpc/boot/zImage.epapr
  MODPOST 1818 modules
ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko]\
undefined!
ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
Signed-off-by: Alexey Kardashevskiy 
---
v3: Introduce CONFIG_VFIO_SPAPR_EEH and add "struct pci_dev" in vfio.h
v2: remove #include  from vfio.c
---
 drivers/vfio/Kconfig  | 6 ++
 drivers/vfio/Makefile | 2 +-
 drivers/vfio/vfio_spapr_eeh.c | 3 +++
 include/linux/vfio.h  | 1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index af7b204..d8c5763 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -8,11 +8,17 @@ config VFIO_IOMMU_SPAPR_TCE
depends on VFIO && SPAPR_TCE_IOMMU
default n
 
+config VFIO_SPAPR_EEH
+   tristate
+   depends on EEH && VFIO_IOMMU_SPAPR_TCE
+   default n
+
 menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
select VFIO_IOMMU_TYPE1 if X86
select VFIO_IOMMU_SPAPR_TCE if (PPC_POWERNV || PPC_PSERIES)
+   select VFIO_SPAPR_EEH if (PPC_POWERNV || PPC_PSERIES)
select ANON_INODES
help
  VFIO provides a framework for secure userspace device drivers.
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 50e30bc..0b035b1 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_VFIO) += vfio.o
 obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
 obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
-obj-$(CONFIG_EEH) += vfio_spapr_eeh.o
+obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
 obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index f834b4c..949f98e 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -18,11 +18,13 @@ int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
return eeh_dev_open(pdev);
 }
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
 
 void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
 {
eeh_dev_release(pdev);
 }
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_release);
 
 long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
unsigned int cmd, unsigned long arg)
@@ -85,3 +87,4 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
 
return ret;
 }
+EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 25a0fbd..224128a 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -98,6 +98,7 @@ extern int vfio_external_user_iommu_id(struct vfio_group 
*group);
 extern long vfio_external_check_extension(struct vfio_group *group,
  unsigned long arg);
 
+struct pci_dev;
 #ifdef CONFIG_EEH
 extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
-- 
1.8.3.2

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

[PATCH v4 1/5] powerpc/eeh: Export eeh_iommu_group_to_pe()

2014-08-06 Thread Gavin Shan
The function is used by VFIO driver, which might be built as a
dynamic module. So it should be exported.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 6043879..59a64f8 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1254,6 +1254,7 @@ struct eeh_pe *eeh_iommu_group_to_pe(struct iommu_group 
*group)
 
return edev->pe;
 }
+EXPORT_SYMBOL_GPL(eeh_iommu_group_to_pe);
 
 #endif /* CONFIG_IOMMU_API */
 
-- 
1.8.3.2

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

[PATCH v4 5/5] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Gavin Shan
From: Alexey Kardashevskiy 

The existing vfio_pci_open() fails upon error returned from
vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
support which this patch brings back.

The patch fixes the issue by dropping the return value of
vfio_spapr_pci_eeh_open().

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
v3: Drop return value of vfio_spapr_pci_eeh_open()
v4: Add warning message in eeh_dev_open() in PATCH[2/5]
---
 drivers/vfio/pci/vfio_pci.c   | 6 +-
 drivers/vfio/vfio_spapr_eeh.c | 4 ++--
 include/linux/vfio.h  | 5 ++---
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index e2ee80f..32d69c8 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
if (ret)
goto error;
 
-   ret = vfio_spapr_pci_eeh_open(vdev->pdev);
-   if (ret) {
-   vfio_pci_disable(vdev);
-   goto error;
-   }
+   vfio_spapr_pci_eeh_open(vdev->pdev);
}
 
return 0;
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 4779cac..86dfceb 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -19,9 +19,9 @@
 #define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
 
 /* We might build address mapping here for "fast" path later */
-int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
+void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
-   return eeh_dev_open(pdev);
+   eeh_dev_open(pdev);
 }
 EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
 
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 224128a..d320411 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
vfio_group *group,
 
 struct pci_dev;
 #ifdef CONFIG_EEH
-extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
+extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
 extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
   unsigned int cmd,
   unsigned long arg);
 #else
-static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
+static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
-   return 0;
 }
 
 static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
-- 
1.8.3.2

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

[PATCH v4 0/5] drivers/vfio: EEH Compile and compatibility

2014-08-06 Thread Gavin Shan
The patchset is mainly for fixing errors from building VFIO compoments
as dynamic modules. PATCH[4/4] allows VFIO can be used though EEH fails
to initialize for VFIO PCI devices.


Alexey Kardashevskiy (2):
  drivers/vfio: Allow EEH to be built as module
  drivers/vfio: Enable VFIO if EEH is not supported

Gavin Shan (3):
  powerpc/eeh: Export eeh_iommu_group_to_pe()
  powerpc/eeh: Add warning message in eeh_dev_open()
  drivers/vfio: Fix EEH build error

 arch/powerpc/kernel/eeh.c |  6 +-
 drivers/vfio/Kconfig  |  6 ++
 drivers/vfio/Makefile |  2 +-
 drivers/vfio/pci/vfio_pci.c   |  6 +-
 drivers/vfio/vfio_spapr_eeh.c | 17 +++--
 include/linux/vfio.h  |  6 +++---
 6 files changed, 31 insertions(+), 12 deletions(-)

-- 
1.8.3.2

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

[PATCH v4 4/5] drivers/vfio: Allow EEH to be built as module

2014-08-06 Thread Gavin Shan
From: Alexey Kardashevskiy 

This adds necessary declarations to the SPAPR VFIO EEH module,
otherwise multiple dynamic linker errors reported:

vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
 drivers/vfio/vfio_spapr_eeh.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 949f98e..4779cac 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -9,10 +9,15 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
 
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR  "Gavin Shan, IBM Corporation"
+#define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
+
 /* We might build address mapping here for "fast" path later */
 int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
@@ -88,3 +93,8 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
return ret;
 }
 EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
-- 
1.8.3.2

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

[PATCH v4 2/5] powerpc/eeh: Add warning message in eeh_dev_open()

2014-08-06 Thread Gavin Shan
The patch adds one warning message in eeh_dev_open() in case the
PCI device can't be marked as passed through.

Suggested-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 59a64f8..5d73a49 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1162,8 +1162,11 @@ int eeh_dev_open(struct pci_dev *pdev)
 
/* No EEH device or PE ? */
edev = pci_dev_to_eeh_dev(pdev);
-   if (!edev || !edev->pe)
+   if (!edev || !edev->pe) {
+   pr_warn_once("%s: PCI device %s not supported\n",
+__func__, pci_name(pdev));
goto out;
+   }
 
/* Increase PE's pass through count */
atomic_inc(&edev->pe->pass_dev_cnt);
-- 
1.8.3.2

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

Re: [PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Gavin Shan
On Thu, Aug 07, 2014 at 12:10:07PM +1000, Gavin Shan wrote:
>On Wed, Aug 06, 2014 at 11:05:43PM +1000, Alexey Kardashevskiy wrote:
>>On 08/06/2014 10:50 PM, Alex Williamson wrote:
>>> On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
 From: Alexey Kardashevskiy 

 The existing vfio_pci_open() fails upon error returned from
 vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
 support which this patch brings back.

 The patch fixes the issue by dropping the return value of
 vfio_spapr_pci_eeh_open().

 Signed-off-by: Alexey Kardashevskiy 
 Signed-off-by: Gavin Shan 
 ---
 v3: Drop return value of vfio_spapr_pci_eeh_open()
 ---
  drivers/vfio/pci/vfio_pci.c   | 6 +-
  drivers/vfio/vfio_spapr_eeh.c | 4 ++--
  include/linux/vfio.h  | 5 ++---
  3 files changed, 5 insertions(+), 10 deletions(-)

 diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
 index e2ee80f..32d69c8 100644
 --- a/drivers/vfio/pci/vfio_pci.c
 +++ b/drivers/vfio/pci/vfio_pci.c
 @@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
if (ret)
goto error;
  
 -  ret = vfio_spapr_pci_eeh_open(vdev->pdev);
 -  if (ret) {
 -  vfio_pci_disable(vdev);
 -  goto error;
 -  }
 +  vfio_spapr_pci_eeh_open(vdev->pdev);
}
  
return 0;
 diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
 index 4779cac..86dfceb 100644
 --- a/drivers/vfio/vfio_spapr_eeh.c
 +++ b/drivers/vfio/vfio_spapr_eeh.c
 @@ -19,9 +19,9 @@
  #define DRIVER_DESC   "VFIO IOMMU SPAPR EEH"
  
  /* We might build address mapping here for "fast" path later */
 -int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 +void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
  {
 -  return eeh_dev_open(pdev);
 +  eeh_dev_open(pdev);
>>> 
>>> Wasn't there some intent to provide a warning message, that would now be
>>> done here?  Has that idea been dropped?
>>
>>
>>Comrade Gavin just forgot it :)
>>
>>Gavin, please add it. Thanks!
>>
>
>Sure, I'll add following warning message in eeh_dev_open() in
>separate patch in v4 in case nobody objects.
>
>int eeh_dev_open(struct pci_dev *pdev)
>{
>:
>/* No EEH device or PE ? */
>edev = pci_dev_to_eeh_dev(pdev);
>if (!edev || !edev->pe) {
>   pr_warn_once("%s: Device %s not supported\n",
>__func__, pci_name(pdev));
>goto out;
>}
>:
>}
>

Well, I added the warning message in eeh_dev_open() and sending "v4" out.

Thanks,
Gavin

>
>>
>>
>>> 
  }
  EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
  
 diff --git a/include/linux/vfio.h b/include/linux/vfio.h
 index 224128a..d320411 100644
 --- a/include/linux/vfio.h
 +++ b/include/linux/vfio.h
 @@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
 vfio_group *group,
  
  struct pci_dev;
  #ifdef CONFIG_EEH
 -extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 +extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
  extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
  extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
   unsigned int cmd,
   unsigned long arg);
  #else
 -static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 +static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
  {
 -  return 0;
  }
  
  static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
>>> 
>>> 
>>> 
>>
>>
>>-- 
>>Alexey
>>

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

Re: [PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Gavin Shan
On Wed, Aug 06, 2014 at 11:05:43PM +1000, Alexey Kardashevskiy wrote:
>On 08/06/2014 10:50 PM, Alex Williamson wrote:
>> On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
>>> From: Alexey Kardashevskiy 
>>>
>>> The existing vfio_pci_open() fails upon error returned from
>>> vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
>>> support which this patch brings back.
>>>
>>> The patch fixes the issue by dropping the return value of
>>> vfio_spapr_pci_eeh_open().
>>>
>>> Signed-off-by: Alexey Kardashevskiy 
>>> Signed-off-by: Gavin Shan 
>>> ---
>>> v3: Drop return value of vfio_spapr_pci_eeh_open()
>>> ---
>>>  drivers/vfio/pci/vfio_pci.c   | 6 +-
>>>  drivers/vfio/vfio_spapr_eeh.c | 4 ++--
>>>  include/linux/vfio.h  | 5 ++---
>>>  3 files changed, 5 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
>>> index e2ee80f..32d69c8 100644
>>> --- a/drivers/vfio/pci/vfio_pci.c
>>> +++ b/drivers/vfio/pci/vfio_pci.c
>>> @@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
>>> if (ret)
>>> goto error;
>>>  
>>> -   ret = vfio_spapr_pci_eeh_open(vdev->pdev);
>>> -   if (ret) {
>>> -   vfio_pci_disable(vdev);
>>> -   goto error;
>>> -   }
>>> +   vfio_spapr_pci_eeh_open(vdev->pdev);
>>> }
>>>  
>>> return 0;
>>> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
>>> index 4779cac..86dfceb 100644
>>> --- a/drivers/vfio/vfio_spapr_eeh.c
>>> +++ b/drivers/vfio/vfio_spapr_eeh.c
>>> @@ -19,9 +19,9 @@
>>>  #define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
>>>  
>>>  /* We might build address mapping here for "fast" path later */
>>> -int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>> +void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>>  {
>>> -   return eeh_dev_open(pdev);
>>> +   eeh_dev_open(pdev);
>> 
>> Wasn't there some intent to provide a warning message, that would now be
>> done here?  Has that idea been dropped?
>
>
>Comrade Gavin just forgot it :)
>
>Gavin, please add it. Thanks!
>

Sure, I'll add following warning message in eeh_dev_open() in
separate patch in v4 in case nobody objects.

int eeh_dev_open(struct pci_dev *pdev)
{
:
/* No EEH device or PE ? */
edev = pci_dev_to_eeh_dev(pdev);
if (!edev || !edev->pe) {
pr_warn_once("%s: Device %s not supported\n",
 __func__, pci_name(pdev));
goto out;
}
:
}

Thanks,
Gavin

>
>
>> 
>>>  }
>>>  EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>>>  
>>> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
>>> index 224128a..d320411 100644
>>> --- a/include/linux/vfio.h
>>> +++ b/include/linux/vfio.h
>>> @@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
>>> vfio_group *group,
>>>  
>>>  struct pci_dev;
>>>  #ifdef CONFIG_EEH
>>> -extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>>> +extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>>>  extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
>>>  extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>>>unsigned int cmd,
>>>unsigned long arg);
>>>  #else
>>> -static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>> +static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>>  {
>>> -   return 0;
>>>  }
>>>  
>>>  static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
>> 
>> 
>> 
>
>
>-- 
>Alexey
>

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

Re: [3.13.y.z extended stable] Patch "locking/mutex: Disable optimistic spinning on some architectures" has been added to staging queue

2014-08-06 Thread Andev
On Wed, Aug 6, 2014 at 9:55 PM, Kamal Mostafa  wrote:
>
> On Wed, 2014-08-06 at 14:30 -0700, Davidlohr Bueso wrote:
>> Well 3.13.y.z isn't an Ubuntu kernel, its upstream, and those archs
>> *are* supported.
>
> Davidlohr's answer is correct: This is not an "Ubuntu kernel".
>
> 3.13.y.z is an "extended stable" kernel which follows the same rules as
> the kernel.org official stable kernels.  It contains no Ubuntu-specific
> patches, and supports the same arch's as mainline.
>
> More details about this and the other Canonical-funded-and-hosted
> "extended stable" kernel versions is available here:
>
>> For more information about the 3.13.y.z tree, see
>> https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

OK, thank you for clarification. I was unsure as this is not hosted on
kernel.org, I thought it was a Ubuntu specific kernel.

So we have the following stable kernels as of now:

3.10, 3.12, 3.13, 3.14, 3.15(for a few days), 3.16!

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

Re: [PATCH] powerpc: Add POWER8 features to CPU_FTRS_POSSIBLE/ALWAYS

2014-08-06 Thread Joel Stanley
On Wed, Aug 6, 2014 at 3:12 PM, Michael Ellerman  wrote:
> We have been a bit slack about updating the CPU_FTRS_POSSIBLE and
> CPU_FTRS_ALWAYS masks. When we added POWER8, and also POWER8E we forgot
> to update the ALWAYS mask. And when we added POWER8_DD1 we forgot to
> update both the POSSIBLE and ALWAYS masks.
>
> Luckily this hasn't caused any actual bugs AFAICS. Failing to update the
> ALWAYS mask just forgoes a potential optimisation opportunity. Failing
> to update the POSSIBLE mask for POWER8_DD1 is also OK because it only
> removes a bit rather than adding any.
>
> Regardless they should all be in both masks so as to avoid any future
> bugs when the set of ALWAYS/POSSIBLE bits changes, or the masks
> themselves change.
>
> Signed-off-by: Michael Ellerman 

Thanks for catching that.

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

Re: [3.13.y.z extended stable] Patch "locking/mutex: Disable optimistic spinning on some architectures" has been added to staging queue

2014-08-06 Thread Kamal Mostafa

> On Wed, 2014-08-06 at 17:25 -0400, Andev wrote:
> > On Wed, Aug 6, 2014 at 4:54 PM, Kamal Mostafa  wrote:
> > > This is a note to let you know that I have just added a patch titled
> > >
> > > locking/mutex: Disable optimistic spinning on some architectures
> > >
> > > to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree
> > > which can be found at:
> > >
> > >  
> > > http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
> > >
> > > This patch is scheduled to be released in version 3.13.11.6.
> > >
> > 
> > This patch is specifically for parisc, sparc32, tile32, metag-lock1,
> > arc-!llsc and hexagon none of which Ubuntu supports.
> > 
> > Why are you backporting this patch?

On Wed, 2014-08-06 at 14:30 -0700, Davidlohr Bueso wrote:
> Well 3.13.y.z isn't an Ubuntu kernel, its upstream, and those archs
> *are* supported.

Davidlohr's answer is correct: This is not an "Ubuntu kernel".

3.13.y.z is an "extended stable" kernel which follows the same rules as
the kernel.org official stable kernels.  It contains no Ubuntu-specific
patches, and supports the same arch's as mainline.

More details about this and the other Canonical-funded-and-hosted
"extended stable" kernel versions is available here:

> For more information about the 3.13.y.z tree, see
> https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

 -Kamal


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

Re: [PATCH] powerpc: Add POWER8 features to CPU_FTRS_POSSIBLE/ALWAYS

2014-08-06 Thread Michael Neuling
On Wed, 2014-08-06 at 15:42 +1000, Michael Ellerman wrote:
> We have been a bit slack about updating the CPU_FTRS_POSSIBLE and
> CPU_FTRS_ALWAYS masks. When we added POWER8, and also POWER8E we forgot
> to update the ALWAYS mask. And when we added POWER8_DD1 we forgot to
> update both the POSSIBLE and ALWAYS masks.
> 
> Luckily this hasn't caused any actual bugs AFAICS. Failing to update the
> ALWAYS mask just forgoes a potential optimisation opportunity. Failing
> to update the POSSIBLE mask for POWER8_DD1 is also OK because it only
> removes a bit rather than adding any.
> 
> Regardless they should all be in both masks so as to avoid any future
> bugs when the set of ALWAYS/POSSIBLE bits changes, or the masks
> themselves change.
> 
> Signed-off-by: Michael Ellerman 

CCing Joel but FWIW

Acked-by: Michael Neuling 

> ---
>  arch/powerpc/include/asm/cputable.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/cputable.h 
> b/arch/powerpc/include/asm/cputable.h
> index af5598688daf..d696eeb2def0 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -458,7 +458,8 @@ extern const char *powerpc_base_platform;
>  #define CPU_FTRS_POSSIBLE\
>   (CPU_FTRS_POWER4 | CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
>CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
> -  CPU_FTRS_POWER8 | CPU_FTRS_CELL | CPU_FTRS_PA6T | CPU_FTR_VSX)
> +  CPU_FTRS_POWER8 | CPU_FTRS_POWER8_DD1 | CPU_FTRS_CELL | \
> +  CPU_FTRS_PA6T | CPU_FTR_VSX)
>  #endif
>  #else
>  enum {
> @@ -508,7 +509,8 @@ enum {
>  #define CPU_FTRS_ALWAYS  \
>   (CPU_FTRS_POWER4 & CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & \
>CPU_FTRS_POWER6 & CPU_FTRS_POWER7 & CPU_FTRS_CELL & \
> -  CPU_FTRS_PA6T & CPU_FTRS_POSSIBLE)
> +  CPU_FTRS_PA6T & CPU_FTRS_POWER8 & CPU_FTRS_POWER8E & \
> +  CPU_FTRS_POWER8_DD1 & CPU_FTRS_POSSIBLE)
>  #endif
>  #else
>  enum {

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

Re: [PATCH] powerpc: thp: Use tlbiel wherever possible

2014-08-06 Thread Michael Neuling
On Wed, 2014-08-06 at 20:16 +0530, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V"  writes:
> 
> > If we know that user address space has never executed on other cpus
> > we could use tlbiel.
> >
> > Signed-off-by: Aneesh Kumar K.V 
> 
> Now checking against flush_hash_page, I am wondering whether I need to handle
> transcational memory in case of tlbiel ? Michael, can you let me know if
> this is needed ?

Yeah, you do need to add something.  

local tlbie won't abort the transaction (broadcast will abort), so you
need to do a explicit tabort if there is an active transaction, to make
sure the transaction is doomed.

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

Re: [3.13.y.z extended stable] Patch "locking/mutex: Disable optimistic spinning on some architectures" has been added to staging queue

2014-08-06 Thread Mikulas Patocka


On Wed, 6 Aug 2014, Andev wrote:

> On Wed, Aug 6, 2014 at 4:54 PM, Kamal Mostafa  wrote:
> > This is a note to let you know that I have just added a patch titled
> >
> > locking/mutex: Disable optimistic spinning on some architectures
> >
> > to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree
> > which can be found at:
> >
> >  
> > http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
> >
> > This patch is scheduled to be released in version 3.13.11.6.
> >
> 
> This patch is specifically for parisc, sparc32, tile32, metag-lock1,
> arc-!llsc and hexagon none of which Ubuntu supports.
> 
> Why are you backporting this patch?
> 
> --
> Andev

I guess - it's less time consuming to backport all patches for stable than 
to ponder on each patch if it applies to Ubuntu or not...

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

Re: [3.13.y.z extended stable] Patch "locking/mutex: Disable optimistic spinning on some architectures" has been added to staging queue

2014-08-06 Thread Andev
On Wed, Aug 6, 2014 at 4:54 PM, Kamal Mostafa  wrote:
> This is a note to let you know that I have just added a patch titled
>
> locking/mutex: Disable optimistic spinning on some architectures
>
> to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree
> which can be found at:
>
>  
> http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
>
> This patch is scheduled to be released in version 3.13.11.6.
>

This patch is specifically for parisc, sparc32, tile32, metag-lock1,
arc-!llsc and hexagon none of which Ubuntu supports.

Why are you backporting this patch?

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

[3.13.y.z extended stable] Patch "locking/mutex: Disable optimistic spinning on some architectures" has been added to staging queue

2014-08-06 Thread Kamal Mostafa
This is a note to let you know that I have just added a patch titled

locking/mutex: Disable optimistic spinning on some architectures

to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree 
which can be found at:

 
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue

This patch is scheduled to be released in version 3.13.11.6.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.13.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Kamal

--

From 01698736c59ec0ef7db9aa25785868ebd5637e12 Mon Sep 17 00:00:00 2001
From: Peter Zijlstra 
Date: Fri, 6 Jun 2014 19:53:16 +0200
Subject: locking/mutex: Disable optimistic spinning on some architectures

commit 4badad352a6bb202ec68afa7a574c0bb961e5ebc upstream.

The optimistic spin code assumes regular stores and cmpxchg() play nice;
this is found to not be true for at least: parisc, sparc32, tile32,
metag-lock1, arc-!llsc and hexagon.

There is further wreckage, but this in particular seemed easy to
trigger, so blacklist this.

Opt in for known good archs.

Signed-off-by: Peter Zijlstra 
Reported-by: Mikulas Patocka 
Cc: David Miller 
Cc: Chris Metcalf 
Cc: James Bottomley 
Cc: Vineet Gupta 
Cc: Jason Low 
Cc: Waiman Long 
Cc: "James E.J. Bottomley" 
Cc: Paul McKenney 
Cc: John David Anglin 
Cc: James Hogan 
Cc: Linus Torvalds 
Cc: Davidlohr Bueso 
Cc: Benjamin Herrenschmidt 
Cc: Catalin Marinas 
Cc: Russell King 
Cc: Will Deacon 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/20140606175316.gv13...@laptop.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Kamal Mostafa 
---
 arch/arm/Kconfig | 1 +
 arch/arm64/Kconfig   | 1 +
 arch/powerpc/Kconfig | 1 +
 arch/sparc/Kconfig   | 1 +
 arch/x86/Kconfig | 1 +
 kernel/Kconfig.locks | 5 -
 6 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 31e1f44..b3d400d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -6,6 +6,7 @@ config ARM
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_MIGHT_HAVE_PC_PARPORT
+   select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT if MMU
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d4dd22..bf0ed5d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2,6 +2,7 @@ config ARM64
def_bool y
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_USE_CMPXCHG_LOCKREF
+   select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b44b52c..ab43fa3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -139,6 +139,7 @@ config PPC
select OLD_SIGACTION if PPC32
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_IRQ_EXIT_ON_IRQ_STACK
+   select ARCH_SUPPORTS_ATOMIC_RMW

 config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 6c95f4d..94cd9c1 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -76,6 +76,7 @@ config SPARC64
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select HAVE_C_RECORDMCOUNT
select NO_BOOTMEM
+   select ARCH_SUPPORTS_ATOMIC_RMW

 config ARCH_DEFCONFIG
string
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9e31880..9562fc3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -125,6 +125,7 @@ config X86
select RTC_LIB
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
+   select ARCH_SUPPORTS_ATOMIC_RMW

 config INSTRUCTION_DECODER
def_bool y
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
index d2b32ac..ecee67a 100644
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
@@ -220,6 +220,9 @@ config INLINE_WRITE_UNLOCK_IRQRESTORE

 endif

+config ARCH_SUPPORTS_ATOMIC_RMW
+   bool
+
 config MUTEX_SPIN_ON_OWNER
def_bool y
-   depends on SMP && !DEBUG_MUTEXES
+   depends on SMP && !DEBUG_MUTEXES && ARCH_SUPPORTS_ATOMIC_RMW
--
1.9.1

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

Re: [3.13.y.z extended stable] Patch "locking/mutex: Disable optimistic spinning on some architectures" has been added to staging queue

2014-08-06 Thread Davidlohr Bueso
On Wed, 2014-08-06 at 17:25 -0400, Andev wrote:
> On Wed, Aug 6, 2014 at 4:54 PM, Kamal Mostafa  wrote:
> > This is a note to let you know that I have just added a patch titled
> >
> > locking/mutex: Disable optimistic spinning on some architectures
> >
> > to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree
> > which can be found at:
> >
> >  
> > http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue
> >
> > This patch is scheduled to be released in version 3.13.11.6.
> >
> 
> This patch is specifically for parisc, sparc32, tile32, metag-lock1,
> arc-!llsc and hexagon none of which Ubuntu supports.
> 
> Why are you backporting this patch?

Well 3.13.y.z isn't an Ubuntu kernel, its upstream, and those archs
*are* supported.

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

Re: [PATCH 2/2] powerpc/nohash: Split __early_init_mmu() into boot and secondary

2014-08-06 Thread Benjamin Herrenschmidt
On Wed, 2014-08-06 at 15:09 -0500, Scott Wood wrote:
> BTW, is there a particular reason why we need to use
> memblock_enforce_memory_limit() on FSL_BOOK3E, rather than relying on
> memblock_set_current_limit()?  I see that when
> memblock_enforce_memory_limit() was added to __early_init_mmu(),
> memblock_set_current_limit() did not exist.  On 32-bit fsl booke uses
> memblock_set_current_limit() for this.

I don't remember. I don't even know what the difference is, I can
have a look later if you want but I'd rather you did :-)

Cheers,
Ben.


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

Re: [PATCH] powerpc: thp: Use tlbiel wherever possible

2014-08-06 Thread Benjamin Herrenschmidt
On Wed, 2014-08-06 at 20:16 +0530, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V"  writes:
> 
> > If we know that user address space has never executed on other cpus
> > we could use tlbiel.
> >
> > Signed-off-by: Aneesh Kumar K.V 
> 
> Now checking against flush_hash_page, I am wondering whether I need to handle
> transcational memory in case of tlbiel ? Michael, can you let me know if
> this is needed ?

Also, beware that we have code that sets "tlbiel" in the page definition
array to 0 on all but 4k and 64k pages...

Cheers,
Ben.


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

Re: qe: move qe from arch/powerpc to drivers

2014-08-06 Thread Scott Wood
On Wed, 2014-08-06 at 03:53 -0500, Zhao Qiang-B45475 wrote:
> On Wed, Jul 30, 2014 at 08:19 AM, Wood Scott wrote:
> 
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, July 30, 2014 8:19 AM
> > To: Zhao Qiang-B45475
> > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-R63061
> > Subject: Re: qe: move qe from arch/powerpc to drivers
> > 
> > On Tue, Jun 24, 2014 at 11:31:52AM +0800, Zhao Qiang wrote:
> > > ls1 has qe and ls1 has arm cpu.
> > > move qe from arch/powerpc to drivers.
> > >
> > > Signed-off-by: Zhao Qiang 
> > 
> > This is a very terse changelog.  Explain more about what QE is, and what
> > this patch accomplishes (it doesn't seem to get rid of the PPC dependency,
> > just moving code at this stage)
> > 
> > I don't see a MAINTAINERS update for the new path.  Who is going to
> > maintain it?
> > 
> > I don't think drivers/qe is the right place for it.  Directories directly
> > under drivers/ tend to be for classes of devices, not instances.  In any
> > case, LKML should be CCed when creating a new directory directly under
> > drivers/ or under a subdirectory of drivers/ that doesn't have its own
> > mailing list.
> 
> So which directory do you recommend?

drivers/soc/

> Actually qe is a kind of IP block, so in my opinion, it is proper to put it 
> under driver/(just in my opinion).

No, it isn't a type of device (e.g. "ethernet" or "tty").  It's an
abbreviation of a trademark for a specific multipurpose I/O
architecture.

-Scott


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

Re: [PATCH] ASoC: fsl_sai: Add asynchronous mode support

2014-08-06 Thread Mark Brown
On Wed, Aug 06, 2014 at 10:42:37AM +0800, Nicolin Chen wrote:
> On Tue, Aug 05, 2014 at 04:44:29PM +0530, Varka Bhadram wrote:

> > Reading comfortably is important for us...  :-)
> > see 
> > this:http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt#L46

> I know how to write a binding doc with indentations to make it clear.

> What I'm talking about is that the doc was created without indentations,
> so I don't feel comfortable to add indentations starting from this patch
> while leaving the old lines in totally a different style because It's not
> helpful to make people read comfortably at all but only forcing people to
> think why these two lines are so special to take some steps back here.

> So personally I agree with your idea to make doc more readable. But what
> I prefer to do is not having a conversation on the style within this patch
> but to create an extra style-refinement patch later after this one.

This is the right approach.


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

Re: [PATCH 2/2] powerpc/nohash: Split __early_init_mmu() into boot and secondary

2014-08-06 Thread Scott Wood
On Wed, 2014-08-06 at 14:58 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2014-08-05 at 19:48 -0500, Scott Wood wrote:
> > I'll do s/mmu_allcpus/this_mmu/ but early_init_mmu() needs to do things
> > both before and after early_init_mmu_common().  Do you want two new
> > functions (before and after) or is it OK to just rename
> > early_init_mmu_allcpus() and put a comment before early_init_mmu()
> > saying it's just for the boot cpu?
> 
> Do we really need that before/after ? The "after" code is the linear
> mapping setup but does it rely on the MAS4 setting done above ?

No, but it relies on the call to map_mem_in_cams() to determine how much
memory was able to be mapped.

> Otherwise you can do before/after using a separate function
> mmu_set_linear_map()

OK.

> Always nicer to break down too large functions anyway.

Usually yes, but it doesn't necessarily help when it's an arbitrary
division of a function that is a list of simple things (as opposed to
e.g. factoring out the #ifdef CONFIG_PPC_FSL_BOOK3E block into its own
function).

BTW, is there a particular reason why we need to use
memblock_enforce_memory_limit() on FSL_BOOK3E, rather than relying on
memblock_set_current_limit()?  I see that when
memblock_enforce_memory_limit() was added to __early_init_mmu(),
memblock_set_current_limit() did not exist.  On 32-bit fsl booke uses
memblock_set_current_limit() for this.

-Scott


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

[PATCH] KVM: PPC: e500mc: Add support for single threaded vcpus on e6500 core

2014-08-06 Thread Mihai Caraman
ePAPR represents hardware threads as cpu node properties in device tree.
So with existing QEMU, hardware threads are simply exposed as vcpus with
one hardware thread.

The e6500 core shares TLBs between hardware threads. Without tlb write
conditional instruction, the Linux kernel uses per core mechanisms to
protect against duplicate TLB entries.

The guest is unable to detect real siblings threads, so it can't use a
TLB protection mechanism. An alternative solution is to use the hypervisor
to allocate different lpids to guest's vcpus running simultaneous on real
siblings threads. This patch moves lpid to vcpu level and allocates a pool
of lpids (equal to the number of threads per core) per VM.

Signed-off-by: Mihai Caraman 
---
 Please rebase this patch before
[PATCH v3 5/5] KVM: PPC: Book3E: Enable e6500 core
 to proper handle SMP guests.

 arch/powerpc/include/asm/kvm_host.h |  5 
 arch/powerpc/kernel/asm-offsets.c   |  4 +++
 arch/powerpc/kvm/e500_mmu_host.c| 15 +-
 arch/powerpc/kvm/e500mc.c   | 55 +
 4 files changed, 55 insertions(+), 24 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 98d9dd5..1b0bb4a 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -227,7 +227,11 @@ struct kvm_arch_memory_slot {
 };
 
 struct kvm_arch {
+#ifdef CONFIG_KVM_BOOKE_HV
+   unsigned int lpid_pool[2];
+#else
unsigned int lpid;
+#endif
 #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
unsigned long hpt_virt;
struct revmap_entry *revmap;
@@ -435,6 +439,7 @@ struct kvm_vcpu_arch {
u32 eplc;
u32 epsc;
u32 oldpir;
+   u32 lpid;
 #endif
 
 #if defined(CONFIG_BOOKE)
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index ab9ae04..5a30b87 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -483,7 +483,11 @@ int main(void)
DEFINE(VCPU_SHARED_MAS6, offsetof(struct kvm_vcpu_arch_shared, mas6));
 
DEFINE(VCPU_KVM, offsetof(struct kvm_vcpu, kvm));
+#ifdef CONFIG_KVM_BOOKE_HV
+   DEFINE(KVM_LPID, offsetof(struct kvm_vcpu, arch.lpid));
+#else
DEFINE(KVM_LPID, offsetof(struct kvm, arch.lpid));
+#endif
 
/* book3s */
 #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 4150826..a233cc6 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -69,7 +69,7 @@ static inline u32 e500_shadow_mas3_attrib(u32 mas3, int 
usermode)
  * writing shadow tlb entry to host TLB
  */
 static inline void __write_host_tlbe(struct kvm_book3e_206_tlb_entry *stlbe,
-uint32_t mas0)
+uint32_t mas0, uint32_t *lpid)
 {
unsigned long flags;
 
@@ -80,6 +80,8 @@ static inline void __write_host_tlbe(struct 
kvm_book3e_206_tlb_entry *stlbe,
mtspr(SPRN_MAS3, (u32)stlbe->mas7_3);
mtspr(SPRN_MAS7, (u32)(stlbe->mas7_3 >> 32));
 #ifdef CONFIG_KVM_BOOKE_HV
+   /* populate mas8 with latest LPID */
+   stlbe->mas8 = MAS8_TGS | *lpid;
mtspr(SPRN_MAS8, stlbe->mas8);
 #endif
asm volatile("isync; tlbwe" : : : "memory");
@@ -129,11 +131,12 @@ static inline void write_host_tlbe(struct 
kvmppc_vcpu_e500 *vcpu_e500,
 
if (tlbsel == 0) {
mas0 = get_host_mas0(stlbe->mas2);
-   __write_host_tlbe(stlbe, mas0);
+   __write_host_tlbe(stlbe, mas0, &vcpu_e500->vcpu.arch.lpid);
} else {
__write_host_tlbe(stlbe,
  MAS0_TLBSEL(1) |
- MAS0_ESEL(to_htlb1_esel(sesel)));
+ MAS0_ESEL(to_htlb1_esel(sesel)),
+ &vcpu_e500->vcpu.arch.lpid);
}
 }
 
@@ -318,9 +321,7 @@ static void kvmppc_e500_setup_stlbe(
stlbe->mas7_3 = ((u64)pfn << PAGE_SHIFT) |
e500_shadow_mas3_attrib(gtlbe->mas7_3, pr);
 
-#ifdef CONFIG_KVM_BOOKE_HV
-   stlbe->mas8 = MAS8_TGS | vcpu->kvm->arch.lpid;
-#endif
+   /* Set mas8 when executing tlbwe since LPID can change dynamically */
 }
 
 static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
@@ -632,7 +633,7 @@ int kvmppc_load_last_inst(struct kvm_vcpu *vcpu, enum 
instruction_type type,
 
local_irq_save(flags);
mtspr(SPRN_MAS6, (vcpu->arch.pid << MAS6_SPID_SHIFT) | addr_space);
-   mtspr(SPRN_MAS5, MAS5_SGS | vcpu->kvm->arch.lpid);
+   mtspr(SPRN_MAS5, MAS5_SGS | vcpu->arch.lpid);
asm volatile("tlbsx 0, %[geaddr]\n" : :
 [geaddr] "r" (geaddr));
mtspr(SPRN_MAS5, 0);
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index aa48dc3..c0a0d9d 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -24,6 

Re: [PATCH] powerpc: thp: Use tlbiel wherever possible

2014-08-06 Thread Aneesh Kumar K.V
"Aneesh Kumar K.V"  writes:

> If we know that user address space has never executed on other cpus
> we could use tlbiel.
>
> Signed-off-by: Aneesh Kumar K.V 

Now checking against flush_hash_page, I am wondering whether I need to handle
transcational memory in case of tlbiel ? Michael, can you let me know if
this is needed ?


-aneesh

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

Re: [PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Alexey Kardashevskiy
On 08/06/2014 10:50 PM, Alex Williamson wrote:
> On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
>> From: Alexey Kardashevskiy 
>>
>> The existing vfio_pci_open() fails upon error returned from
>> vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
>> support which this patch brings back.
>>
>> The patch fixes the issue by dropping the return value of
>> vfio_spapr_pci_eeh_open().
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> Signed-off-by: Gavin Shan 
>> ---
>> v3: Drop return value of vfio_spapr_pci_eeh_open()
>> ---
>>  drivers/vfio/pci/vfio_pci.c   | 6 +-
>>  drivers/vfio/vfio_spapr_eeh.c | 4 ++--
>>  include/linux/vfio.h  | 5 ++---
>>  3 files changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
>> index e2ee80f..32d69c8 100644
>> --- a/drivers/vfio/pci/vfio_pci.c
>> +++ b/drivers/vfio/pci/vfio_pci.c
>> @@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
>>  if (ret)
>>  goto error;
>>  
>> -ret = vfio_spapr_pci_eeh_open(vdev->pdev);
>> -if (ret) {
>> -vfio_pci_disable(vdev);
>> -goto error;
>> -}
>> +vfio_spapr_pci_eeh_open(vdev->pdev);
>>  }
>>  
>>  return 0;
>> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
>> index 4779cac..86dfceb 100644
>> --- a/drivers/vfio/vfio_spapr_eeh.c
>> +++ b/drivers/vfio/vfio_spapr_eeh.c
>> @@ -19,9 +19,9 @@
>>  #define DRIVER_DESC "VFIO IOMMU SPAPR EEH"
>>  
>>  /* We might build address mapping here for "fast" path later */
>> -int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>> +void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>  {
>> -return eeh_dev_open(pdev);
>> +eeh_dev_open(pdev);
> 
> Wasn't there some intent to provide a warning message, that would now be
> done here?  Has that idea been dropped?


Comrade Gavin just forgot it :)

Gavin, please add it. Thanks!



> 
>>  }
>>  EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>>  
>> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
>> index 224128a..d320411 100644
>> --- a/include/linux/vfio.h
>> +++ b/include/linux/vfio.h
>> @@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
>> vfio_group *group,
>>  
>>  struct pci_dev;
>>  #ifdef CONFIG_EEH
>> -extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>> +extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>>  extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
>>  extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>> unsigned int cmd,
>> unsigned long arg);
>>  #else
>> -static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>> +static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>>  {
>> -return 0;
>>  }
>>  
>>  static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
> 
> 
> 


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

Re: [PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Alex Williamson
On Wed, 2014-08-06 at 19:49 +1000, Gavin Shan wrote:
> From: Alexey Kardashevskiy 
> 
> The existing vfio_pci_open() fails upon error returned from
> vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
> support which this patch brings back.
> 
> The patch fixes the issue by dropping the return value of
> vfio_spapr_pci_eeh_open().
> 
> Signed-off-by: Alexey Kardashevskiy 
> Signed-off-by: Gavin Shan 
> ---
> v3: Drop return value of vfio_spapr_pci_eeh_open()
> ---
>  drivers/vfio/pci/vfio_pci.c   | 6 +-
>  drivers/vfio/vfio_spapr_eeh.c | 4 ++--
>  include/linux/vfio.h  | 5 ++---
>  3 files changed, 5 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index e2ee80f..32d69c8 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
>   if (ret)
>   goto error;
>  
> - ret = vfio_spapr_pci_eeh_open(vdev->pdev);
> - if (ret) {
> - vfio_pci_disable(vdev);
> - goto error;
> - }
> + vfio_spapr_pci_eeh_open(vdev->pdev);
>   }
>  
>   return 0;
> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
> index 4779cac..86dfceb 100644
> --- a/drivers/vfio/vfio_spapr_eeh.c
> +++ b/drivers/vfio/vfio_spapr_eeh.c
> @@ -19,9 +19,9 @@
>  #define DRIVER_DESC  "VFIO IOMMU SPAPR EEH"
>  
>  /* We might build address mapping here for "fast" path later */
> -int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
> +void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>  {
> - return eeh_dev_open(pdev);
> + eeh_dev_open(pdev);

Wasn't there some intent to provide a warning message, that would now be
done here?  Has that idea been dropped?

>  }
>  EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>  
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 224128a..d320411 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
> vfio_group *group,
>  
>  struct pci_dev;
>  #ifdef CONFIG_EEH
> -extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
> +extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>  extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
>  extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>  unsigned int cmd,
>  unsigned long arg);
>  #else
> -static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
> +static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>  {
> - return 0;
>  }
>  
>  static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)



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

[PATCH V1 2/2] Revert "ASoC: fsl-esai: Add .xlate_tdm_slot_mask() support."

2014-08-06 Thread Shengjiu Wang
This reverts commit a603c8ee526f5ea9ad9b40710308766299ad8a69.

fsl_asoc_xlate_tdm_slot_mask() will invert the mask, which isn't fit for
esai. The default function snd_soc_xlate_tdm_slot_mask() is ok for esai.

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/Kconfig|1 -
 sound/soc/fsl/fsl_esai.c |2 --
 2 files changed, 3 deletions(-)

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index f54a8fc..f3012b6 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -49,7 +49,6 @@ config SND_SOC_FSL_ESAI
tristate "Enhanced Serial Audio Interface (ESAI) module support"
select REGMAP_MMIO
select SND_SOC_IMX_PCM_DMA if SND_IMX_SOC != n
-   select SND_SOC_FSL_UTILS
help
  Say Y if you want to add Enhanced Synchronous Audio Interface
  (ESAI) support for the Freescale CPUs.
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 89aa531..d05b920 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -18,7 +18,6 @@
 
 #include "fsl_esai.h"
 #include "imx-pcm.h"
-#include "fsl_utils.h"
 
 #define FSL_ESAI_RATES SNDRV_PCM_RATE_8000_192000
 #define FSL_ESAI_FORMATS   (SNDRV_PCM_FMTBIT_S8 | \
@@ -611,7 +610,6 @@ static struct snd_soc_dai_ops fsl_esai_dai_ops = {
.hw_params = fsl_esai_hw_params,
.set_sysclk = fsl_esai_set_dai_sysclk,
.set_fmt = fsl_esai_set_dai_fmt,
-   .xlate_tdm_slot_mask = fsl_asoc_xlate_tdm_slot_mask,
.set_tdm_slot = fsl_esai_set_dai_tdm_slot,
 };
 
-- 
1.7.9.5

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

[PATCH V1 0/2] refine esai for tdm support

2014-08-06 Thread Shengjiu Wang
refine esai for tdm support.

Shengjiu Wang (2):
  ASoC: fsl: esai: refine esai for tdm support
  Revert "ASoC: fsl-esai: Add .xlate_tdm_slot_mask() support."

 sound/soc/fsl/Kconfig|1 -
 sound/soc/fsl/fsl_esai.c |   12 +++-
 sound/soc/fsl/fsl_esai.h |8 
 3 files changed, 11 insertions(+), 10 deletions(-)

-- 
1.7.9.5

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

[PATCH V1 1/2] ASoC: fsl: esai: refine esai for tdm support

2014-08-06 Thread Shengjiu Wang
Add parameter for slots, and caculate the number of TX/RX pins and bclk with
slots. Then driver will be compatible with slots > 2 in TDM mode.

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/fsl_esai.c |   10 +++---
 sound/soc/fsl/fsl_esai.h |8 
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 72d154e..89aa531 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -56,6 +56,7 @@ struct fsl_esai {
struct clk *fsysclk;
u32 fifo_depth;
u32 slot_width;
+   u32 slots;
u32 hck_rate[2];
u32 sck_rate[2];
bool hck_dir[2];
@@ -363,6 +364,7 @@ static int fsl_esai_set_dai_tdm_slot(struct snd_soc_dai 
*dai, u32 tx_mask,
   ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(rx_mask));
 
esai_priv->slot_width = slot_width;
+   esai_priv->slots  = slots;
 
return 0;
 }
@@ -510,10 +512,11 @@ static int fsl_esai_hw_params(struct snd_pcm_substream 
*substream,
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
u32 width = snd_pcm_format_width(params_format(params));
u32 channels = params_channels(params);
+   u32 pin = DIV_ROUND_UP(channels, esai_priv->slots);
u32 bclk, mask, val;
int ret;
 
-   bclk = params_rate(params) * esai_priv->slot_width * 2;
+   bclk = params_rate(params) * esai_priv->slot_width * esai_priv->slots;
 
ret = fsl_esai_set_bclk(dai, tx, bclk);
if (ret)
@@ -530,7 +533,7 @@ static int fsl_esai_hw_params(struct snd_pcm_substream 
*substream,
mask = ESAI_xFCR_xFR_MASK | ESAI_xFCR_xWA_MASK | ESAI_xFCR_xFWM_MASK |
  (tx ? ESAI_xFCR_TE_MASK | ESAI_xFCR_TIEN : ESAI_xFCR_RE_MASK);
val = ESAI_xFCR_xWA(width) | ESAI_xFCR_xFWM(esai_priv->fifo_depth) |
-(tx ? ESAI_xFCR_TE(channels) | ESAI_xFCR_TIEN : 
ESAI_xFCR_RE(channels));
+(tx ? ESAI_xFCR_TE(pin) | ESAI_xFCR_TIEN : ESAI_xFCR_RE(pin));
 
regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx), mask, val);
 
@@ -565,6 +568,7 @@ static int fsl_esai_trigger(struct snd_pcm_substream 
*substream, int cmd,
struct fsl_esai *esai_priv = snd_soc_dai_get_drvdata(dai);
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
u8 i, channels = substream->runtime->channels;
+   u32 pin = DIV_ROUND_UP(channels, esai_priv->slots);
 
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -579,7 +583,7 @@ static int fsl_esai_trigger(struct snd_pcm_substream 
*substream, int cmd,
 
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
   tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK,
-  tx ? ESAI_xCR_TE(channels) : 
ESAI_xCR_RE(channels));
+  tx ? ESAI_xCR_TE(pin) : ESAI_xCR_RE(pin));
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_STOP:
diff --git a/sound/soc/fsl/fsl_esai.h b/sound/soc/fsl/fsl_esai.h
index 75e1403..91a550f 100644
--- a/sound/soc/fsl/fsl_esai.h
+++ b/sound/soc/fsl/fsl_esai.h
@@ -130,8 +130,8 @@
 #define ESAI_xFCR_RE_WIDTH 4
 #define ESAI_xFCR_TE_MASK  (((1 << ESAI_xFCR_TE_WIDTH) - 1) << 
ESAI_xFCR_xE_SHIFT)
 #define ESAI_xFCR_RE_MASK  (((1 << ESAI_xFCR_RE_WIDTH) - 1) << 
ESAI_xFCR_xE_SHIFT)
-#define ESAI_xFCR_TE(x)((ESAI_xFCR_TE_MASK >> (ESAI_xFCR_TE_WIDTH - 
((x + 1) >> 1))) & ESAI_xFCR_TE_MASK)
-#define ESAI_xFCR_RE(x)((ESAI_xFCR_RE_MASK >> (ESAI_xFCR_RE_WIDTH - 
((x + 1) >> 1))) & ESAI_xFCR_RE_MASK)
+#define ESAI_xFCR_TE(x)((ESAI_xFCR_TE_MASK >> (ESAI_xFCR_TE_WIDTH - 
x)) & ESAI_xFCR_TE_MASK)
+#define ESAI_xFCR_RE(x)((ESAI_xFCR_RE_MASK >> (ESAI_xFCR_RE_WIDTH - 
x)) & ESAI_xFCR_RE_MASK)
 #define ESAI_xFCR_xFR_SHIFT1
 #define ESAI_xFCR_xFR_MASK (1 << ESAI_xFCR_xFR_SHIFT)
 #define ESAI_xFCR_xFR  (1 << ESAI_xFCR_xFR_SHIFT)
@@ -272,8 +272,8 @@
 #define ESAI_xCR_RE_WIDTH  4
 #define ESAI_xCR_TE_MASK   (((1 << ESAI_xCR_TE_WIDTH) - 1) << 
ESAI_xCR_xE_SHIFT)
 #define ESAI_xCR_RE_MASK   (((1 << ESAI_xCR_RE_WIDTH) - 1) << 
ESAI_xCR_xE_SHIFT)
-#define ESAI_xCR_TE(x) ((ESAI_xCR_TE_MASK >> 
(ESAI_xCR_TE_WIDTH - ((x + 1) >> 1))) & ESAI_xCR_TE_MASK)
-#define ESAI_xCR_RE(x) ((ESAI_xCR_RE_MASK >> 
(ESAI_xCR_RE_WIDTH - ((x + 1) >> 1))) & ESAI_xCR_RE_MASK)
+#define ESAI_xCR_TE(x) ((ESAI_xCR_TE_MASK >> 
(ESAI_xCR_TE_WIDTH - x)) & ESAI_xCR_TE_MASK)
+#define ESAI_xCR_RE(x) ((ESAI_xCR_RE_MASK >> 
(ESAI_xCR_RE_WIDTH - x)) & ESAI_xCR_RE_MASK)
 
 /*
  * Transmit Clock Control Register -- REG_ESAI_TCCR 0xD8
-- 
1.7.9.5

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

Re: [PATCH] powerpc: subpage_protect: Increase the array size to take care of 64TB

2014-08-06 Thread Aneesh Kumar K.V
"Aneesh Kumar K.V"  writes:

> We now support TASK_SIZE of 16TB, hence the array should be 8.
>
> Fixes the below crash:
>
> Unable to handle kernel paging request for data at address 0x000100bd
> Faulting instruction address: 0xc004f914
> cpu 0x13: Vector: 300 (Data Access) at [c00fea75fa90]
> pc: c004f914: .sys_subpage_prot+0x2d4/0x5c0
> lr: c004fb5c: .sys_subpage_prot+0x51c/0x5c0
> sp: c00fea75fd10
>msr: 90009032
>dar: 100bd
>  dsisr: 4000
>   current = 0xc00fea6ae490
>   paca= 0xcfb8ab00   softe: 0irq_happened: 0x00
> pid   = 8237, comm = a.out
> enter ? for help
> [c00fea75fe30] c000a164 syscall_exit+0x0/0x98
> --- Exception: c00 (System Call) at 3fff89737004
>
> Signed-off-by: Aneesh Kumar K.V 

This should go to stable also. Merged upstream as
dad6f37c2602e4af6c3aecfdb41f2d8bd4668163. Let me know how it should be
handled.

-aneesh

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

Re: mm: BUG in unmap_page_range

2014-08-06 Thread Mel Gorman
On Wed, Aug 06, 2014 at 12:44:45PM +0530, Aneesh Kumar K.V wrote:
> > -#define pmd_mknonnuma pmd_mknonnuma
> > -static inline pmd_t pmd_mknonnuma(pmd_t pmd)
> > +/*
> > + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist
> > + * which was inherited from x86. For the purposes of powerpc pte_basic_t is
> > + * equivalent
> > + */
> > +#define pteval_t pte_basic_t
> > +#define pmdval_t pmd_t
> > +static inline pteval_t pte_flags(pte_t pte)
> >  {
> > -   return pte_pmd(pte_mknonnuma(pmd_pte(pmd)));
> > +   return pte_val(pte) & PAGE_PROT_BITS;
> 
> PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have
> to check further to find out why the mask doesn't include
> _PAGE_PRESENT. 
> 

Dumb of me, not sure how I managed that. For the purposes of what is required
it doesn't matter what PAGE_PROT_BITS does. It is clearer if there is a mask
that defines what bits are of interest to the generic helpers which is what
this version attempts to do. It's not tested on powerpc at all unfortunately.

---8<---
mm: Remove misleading ARCH_USES_NUMA_PROT_NONE

ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented
_PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and
relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting
fault scanner. This was found to be conceptually confusing with a lot of
implicit assumptions and it was asked that an alternative be found.

Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the
PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap
PTE bits and shrunk the maximum possible swap size but it did not go far
enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA
but the relics still exist.

This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary
duplication in powerpc vs the generic implementation by defining the types
the core NUMA helpers expected to exist from x86 with their ppc64 equivalent.
This necessitated that a PTE bit mask be created that identified the bits
that distinguish present from NUMA pte entries but it is expected this
will only differ between arches based on _PAGE_PROTNONE. The naming for
the generic helpers was taken from x86 originally but ppc64 has types that
are equivalent for the purposes of the helper so they are mapped instead
of duplicating code.

Signed-off-by: Mel Gorman 
---
 arch/powerpc/include/asm/pgtable.h| 57 ---
 arch/powerpc/include/asm/pte-common.h |  5 +++
 arch/x86/Kconfig  |  1 -
 arch/x86/include/asm/pgtable_types.h  |  7 +
 include/asm-generic/pgtable.h | 27 ++---
 init/Kconfig  | 11 ---
 6 files changed, 33 insertions(+), 75 deletions(-)

diff --git a/arch/powerpc/include/asm/pgtable.h 
b/arch/powerpc/include/asm/pgtable.h
index d98c1ec..beeb09e 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -38,10 +38,9 @@ static inline int pte_none(pte_t pte){ 
return (pte_val(pte) & ~_PTE_NONE_MASK)
 static inline pgprot_t pte_pgprot(pte_t pte)   { return __pgprot(pte_val(pte) 
& PAGE_PROT_BITS); }
 
 #ifdef CONFIG_NUMA_BALANCING
-
 static inline int pte_present(pte_t pte)
 {
-   return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA);
+   return pte_val(pte) & _PAGE_NUMA_MASK;
 }
 
 #define pte_present_nonuma pte_present_nonuma
@@ -50,37 +49,6 @@ static inline int pte_present_nonuma(pte_t pte)
return pte_val(pte) & (_PAGE_PRESENT);
 }
 
-#define pte_numa pte_numa
-static inline int pte_numa(pte_t pte)
-{
-   return (pte_val(pte) &
-   (_PAGE_NUMA|_PAGE_PRESENT)) == _PAGE_NUMA;
-}
-
-#define pte_mknonnuma pte_mknonnuma
-static inline pte_t pte_mknonnuma(pte_t pte)
-{
-   pte_val(pte) &= ~_PAGE_NUMA;
-   pte_val(pte) |=  _PAGE_PRESENT | _PAGE_ACCESSED;
-   return pte;
-}
-
-#define pte_mknuma pte_mknuma
-static inline pte_t pte_mknuma(pte_t pte)
-{
-   /*
-* We should not set _PAGE_NUMA on non present ptes. Also clear the
-* present bit so that hash_page will return 1 and we collect this
-* as numa fault.
-*/
-   if (pte_present(pte)) {
-   pte_val(pte) |= _PAGE_NUMA;
-   pte_val(pte) &= ~_PAGE_PRESENT;
-   } else
-   VM_BUG_ON(1);
-   return pte;
-}
-
 #define ptep_set_numa ptep_set_numa
 static inline void ptep_set_numa(struct mm_struct *mm, unsigned long addr,
 pte_t *ptep)
@@ -92,12 +60,6 @@ static inline void ptep_set_numa(struct mm_struct *mm, 
unsigned long addr,
return;
 }
 
-#define pmd_numa pmd_numa
-static inline int pmd_numa(pmd_t pmd)
-{
-   return pte_numa(pmd_pte(pmd));
-}
-
 #define pmdp_set_numa pmdp_set_numa
 static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr,
 pmd_t *pmdp)
@@ -109,16 +71,21 @@ static inline void 

[PATCH v3 1/4] powerpc/eeh: Export eeh_iommu_group_to_pe()

2014-08-06 Thread Gavin Shan
The function is used by VFIO driver, which might be built as a
dynamic module. So it should be exported.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 6043879..59a64f8 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1254,6 +1254,7 @@ struct eeh_pe *eeh_iommu_group_to_pe(struct iommu_group 
*group)
 
return edev->pe;
 }
+EXPORT_SYMBOL_GPL(eeh_iommu_group_to_pe);
 
 #endif /* CONFIG_IOMMU_API */
 
-- 
1.8.3.2

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

[PATCH v3 4/4] drivers/vfio: Enable VFIO if EEH is not supported

2014-08-06 Thread Gavin Shan
From: Alexey Kardashevskiy 

The existing vfio_pci_open() fails upon error returned from
vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
support which this patch brings back.

The patch fixes the issue by dropping the return value of
vfio_spapr_pci_eeh_open().

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
v3: Drop return value of vfio_spapr_pci_eeh_open()
---
 drivers/vfio/pci/vfio_pci.c   | 6 +-
 drivers/vfio/vfio_spapr_eeh.c | 4 ++--
 include/linux/vfio.h  | 5 ++---
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index e2ee80f..32d69c8 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -178,11 +178,7 @@ static int vfio_pci_open(void *device_data)
if (ret)
goto error;
 
-   ret = vfio_spapr_pci_eeh_open(vdev->pdev);
-   if (ret) {
-   vfio_pci_disable(vdev);
-   goto error;
-   }
+   vfio_spapr_pci_eeh_open(vdev->pdev);
}
 
return 0;
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 4779cac..86dfceb 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -19,9 +19,9 @@
 #define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
 
 /* We might build address mapping here for "fast" path later */
-int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
+void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
-   return eeh_dev_open(pdev);
+   eeh_dev_open(pdev);
 }
 EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
 
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 224128a..d320411 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -100,15 +100,14 @@ extern long vfio_external_check_extension(struct 
vfio_group *group,
 
 struct pci_dev;
 #ifdef CONFIG_EEH
-extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
+extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
 extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
   unsigned int cmd,
   unsigned long arg);
 #else
-static inline int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
+static inline void vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
-   return 0;
 }
 
 static inline void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
-- 
1.8.3.2

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

[PATCH v3 2/4] drivers/vfio: Fix EEH build error

2014-08-06 Thread Gavin Shan
The VFIO related components could be built as dynamic modules.
Unfortunately, CONFIG_EEH can't be configured to "m". The patch
fixes the build errors when configuring VFIO related components
as dynamic modules as follows:

  CC [M]  drivers/vfio/vfio_iommu_spapr_tce.o
In file included from drivers/vfio/vfio.c:33:0:
include/linux/vfio.h:101:43: warning: ‘struct pci_dev’ declared \
inside parameter list [enabled by default]
   :
  WRAParch/powerpc/boot/zImage.pseries
  WRAParch/powerpc/boot/zImage.maple
  WRAParch/powerpc/boot/zImage.pmac
  WRAParch/powerpc/boot/zImage.epapr
  MODPOST 1818 modules
ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko]\
undefined!
ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!

Reported-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
Signed-off-by: Alexey Kardashevskiy 
---
v3: Introduce CONFIG_VFIO_SPAPR_EEH and add "struct pci_dev" in vfio.h
v2: remove #include  from vfio.c
---
 drivers/vfio/Kconfig  | 6 ++
 drivers/vfio/Makefile | 2 +-
 drivers/vfio/vfio_spapr_eeh.c | 3 +++
 include/linux/vfio.h  | 1 +
 4 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index af7b204..d8c5763 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -8,11 +8,17 @@ config VFIO_IOMMU_SPAPR_TCE
depends on VFIO && SPAPR_TCE_IOMMU
default n
 
+config VFIO_SPAPR_EEH
+   tristate
+   depends on EEH && VFIO_IOMMU_SPAPR_TCE
+   default n
+
 menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
select VFIO_IOMMU_TYPE1 if X86
select VFIO_IOMMU_SPAPR_TCE if (PPC_POWERNV || PPC_PSERIES)
+   select VFIO_SPAPR_EEH if (PPC_POWERNV || PPC_PSERIES)
select ANON_INODES
help
  VFIO provides a framework for secure userspace device drivers.
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 50e30bc..0b035b1 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_VFIO) += vfio.o
 obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
 obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
-obj-$(CONFIG_EEH) += vfio_spapr_eeh.o
+obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
 obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index f834b4c..949f98e 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -18,11 +18,13 @@ int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
return eeh_dev_open(pdev);
 }
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
 
 void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
 {
eeh_dev_release(pdev);
 }
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_release);
 
 long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
unsigned int cmd, unsigned long arg)
@@ -85,3 +87,4 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
 
return ret;
 }
+EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 25a0fbd..224128a 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -98,6 +98,7 @@ extern int vfio_external_user_iommu_id(struct vfio_group 
*group);
 extern long vfio_external_check_extension(struct vfio_group *group,
  unsigned long arg);
 
+struct pci_dev;
 #ifdef CONFIG_EEH
 extern int vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
 extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
-- 
1.8.3.2

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

[PATCH v3 0/4] drivers/vfio: EEH Compile and compatibility

2014-08-06 Thread Gavin Shan
The patchset is mainly for fixing errors from building VFIO compoments
as dynamic modules. PATCH[4/4] allows VFIO can be used though EEH fails
to initialize for VFIO PCI devices.

Alexey Kardashevskiy (2):
  drivers/vfio: Allow EEH to be built as module
  drivers/vfio: Enable VFIO if EEH is not supported

Gavin Shan (2):
  powerpc/eeh: Export eeh_iommu_group_to_pe()
  drivers/vfio: Fix EEH build error

 arch/powerpc/kernel/eeh.c |  1 +
 drivers/vfio/Kconfig  |  6 ++
 drivers/vfio/Makefile |  2 +-
 drivers/vfio/pci/vfio_pci.c   |  6 +-
 drivers/vfio/vfio_spapr_eeh.c | 17 +++--
 include/linux/vfio.h  |  6 +++---
 6 files changed, 27 insertions(+), 11 deletions(-)

-- 
1.8.3.2

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

[PATCH v3 3/4] drivers/vfio: Allow EEH to be built as module

2014-08-06 Thread Gavin Shan
From: Alexey Kardashevskiy 

This adds necessary declarations to the SPAPR VFIO EEH module,
otherwise multiple dynamic linker errors reported:

vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
---
 drivers/vfio/vfio_spapr_eeh.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index 949f98e..4779cac 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -9,10 +9,15 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
 
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR  "Gavin Shan, IBM Corporation"
+#define DRIVER_DESC"VFIO IOMMU SPAPR EEH"
+
 /* We might build address mapping here for "fast" path later */
 int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
@@ -88,3 +93,8 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
return ret;
 }
 EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
-- 
1.8.3.2

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

[PATCH 2/2] powerpc/ppc64: Print CPU/MMU/FW features at boot

2014-08-06 Thread Michael Ellerman
"Helps debug funky firmware issues".

After:
  Starting Linux PPC64 #108 SMP Wed Aug 6 19:04:51 EST 2014
  -
  ppc64_pft_size= 0x1a
  phys_mem_size = 0x2
  cpu_features  = 0x17fc7a6c18500249
possible= 0x1fff18700649
always  = 0x0040
  cpu_user_features = 0xdc0065c2 0xee00
  mmu_features  = 0x5a01
  firmware_features = 0x0001405a440b
  htab_hash_mask= 0x7
  -

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Michael Ellerman 
---
v2: Add CPU_FTRS_ALWAYS & CPU_FTRS_POSSIBLE.
---
 arch/powerpc/kernel/setup_64.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index b364f7bd0a94..dce860181b5c 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -525,6 +525,14 @@ void __init setup_system(void)
if (ppc64_caches.iline_size != 0x80)
printk("icache_line_size  = 0x%x\n", ppc64_caches.iline_size);
 
+   printk("cpu_features  = 0x%016lx\n", cur_cpu_spec->cpu_features);
+   printk("  possible= 0x%016lx\n", CPU_FTRS_POSSIBLE);
+   printk("  always  = 0x%016lx\n", CPU_FTRS_ALWAYS);
+   printk("cpu_user_features = 0x%08x 0x%08x\n", 
cur_cpu_spec->cpu_user_features,
+   cur_cpu_spec->cpu_user_features2);
+   printk("mmu_features  = 0x%08x\n", cur_cpu_spec->mmu_features);
+   printk("firmware_features = 0x%016lx\n", powerpc_firmware_features);
+
 #ifdef CONFIG_PPC_STD_MMU_64
if (htab_address)
printk("htab_address  = 0x%p\n", htab_address);
-- 
1.9.1

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

[PATCH 1/2] powerpc/ppc64: Clean up the boot-time settings display

2014-08-06 Thread Michael Ellerman
At boot we display a bunch of low level settings which can be useful to
know, and can help to spot bugs when things are fundamentally
misconfigured.

At the moment they are very widely spaced, so that we can accommodate
the line:

  ppc64_caches.dcache_line_size = 0xYY

But we only print that line when the cache line size is not 128, ie.
almost never, so it just makes the display look odd usually.

The ppc64_caches prefix is redundant so remove it, which means we can
align things a bit closer for the common case. While we're there
replace the last use of camelCase (physicalMemorySize), and use
phys_mem_size.

Before:
  Starting Linux PPC64 #104 SMP Wed Aug 6 18:41:34 EST 2014
  -
  ppc64_pft_size= 0x1a
  physicalMemorySize= 0x2
  ppc64_caches.dcache_line_size = 0xf0
  ppc64_caches.icache_line_size = 0xf0
  htab_address  = 0xdeadbeef
  htab_hash_mask= 0x7
  physical_start= 0xf000bar
  -

After:
  Starting Linux PPC64 #103 SMP Wed Aug 6 18:38:04 EST 2014
  -
  ppc64_pft_size= 0x1a
  phys_mem_size = 0x2
  dcache_line_size  = 0xf0
  icache_line_size  = 0xf0
  htab_address  = 0xdeadbeef
  htab_hash_mask= 0x7
  physical_start= 0xf000bar
  -

This patch is final, no bike shedding ;)

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/setup_64.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index ee082d771178..b364f7bd0a94 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -517,21 +517,23 @@ void __init setup_system(void)
printk("Starting Linux PPC64 %s\n", init_utsname()->version);
 
printk("-\n");
-   printk("ppc64_pft_size= 0x%llx\n", ppc64_pft_size);
-   printk("physicalMemorySize= 0x%llx\n", 
memblock_phys_mem_size());
+   printk("ppc64_pft_size= 0x%llx\n", ppc64_pft_size);
+   printk("phys_mem_size = 0x%llx\n", memblock_phys_mem_size());
+
if (ppc64_caches.dline_size != 0x80)
-   printk("ppc64_caches.dcache_line_size = 0x%x\n",
-  ppc64_caches.dline_size);
+   printk("dcache_line_size  = 0x%x\n", ppc64_caches.dline_size);
if (ppc64_caches.iline_size != 0x80)
-   printk("ppc64_caches.icache_line_size = 0x%x\n",
-  ppc64_caches.iline_size);
+   printk("icache_line_size  = 0x%x\n", ppc64_caches.iline_size);
+
 #ifdef CONFIG_PPC_STD_MMU_64
if (htab_address)
-   printk("htab_address  = 0x%p\n", htab_address);
-   printk("htab_hash_mask= 0x%lx\n", htab_hash_mask);
-#endif /* CONFIG_PPC_STD_MMU_64 */
+   printk("htab_address  = 0x%p\n", htab_address);
+
+   printk("htab_hash_mask= 0x%lx\n", htab_hash_mask);
+#endif
+
if (PHYSICAL_START > 0)
-   printk("physical_start= 0x%llx\n",
+   printk("physical_start= 0x%llx\n",
   (unsigned long long)PHYSICAL_START);
printk("-\n");
 
-- 
1.9.1

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

RE: qe: move qe from arch/powerpc to drivers

2014-08-06 Thread qiang.z...@freescale.com
On Wed, Jul 30, 2014 at 08:19 AM, Wood Scott wrote:


> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 30, 2014 8:19 AM
> To: Zhao Qiang-B45475
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-R63061
> Subject: Re: qe: move qe from arch/powerpc to drivers
> 
> On Tue, Jun 24, 2014 at 11:31:52AM +0800, Zhao Qiang wrote:
> > ls1 has qe and ls1 has arm cpu.
> > move qe from arch/powerpc to drivers.
> >
> > Signed-off-by: Zhao Qiang 
> 
> This is a very terse changelog.  Explain more about what QE is, and what
> this patch accomplishes (it doesn't seem to get rid of the PPC dependency,
> just moving code at this stage)
> 
> I don't see a MAINTAINERS update for the new path.  Who is going to
> maintain it?
> 
> I don't think drivers/qe is the right place for it.  Directories directly
> under drivers/ tend to be for classes of devices, not instances.  In any
> case, LKML should be CCed when creating a new directory directly under
> drivers/ or under a subdirectory of drivers/ that doesn't have its own
> mailing list.

So which directory do you recommend?
Actually qe is a kind of IP block, so in my opinion, it is proper to put it 
under driver/(just in my opinion).


> 
> This came up before, without a resolution.  See:
> http://www.spinics.net/lists/kernel/msg1621335.html
> 
> > diff --git a/arch/powerpc/platforms/83xx/km83xx.c
> > b/arch/powerpc/platforms/83xx/km83xx.c
> > index bf4c447..22c0d6d 100644
> > --- a/arch/powerpc/platforms/83xx/km83xx.c
> > +++ b/arch/powerpc/platforms/83xx/km83xx.c
> > @@ -37,8 +37,8 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > -#include 
> > +#include 
> > +#include 
> 
> If you're moving it out of asm/ please give it an fsl prefix.
> 
> > diff --git a/drivers/qe/Kconfig b/drivers/qe/Kconfig new file mode
> > 100644 index 000..dc16e9a
> > --- /dev/null
> > +++ b/drivers/qe/Kconfig
> > @@ -0,0 +1,35 @@
> > +#
> > +# QE Communication options
> > +#
> > +menuconfig QUICC_ENGINE
> > +   bool "Freescale QUICC Engine (QE) Support"
> > +   depends on FSL_SOC && PPC32
> > +   select PPC_LIB_RHEAP
> > +   select CRC32
> > +   help
> > + The QUICC Engine (QE) is a new generation of communications
> > + coprocessors on Freescale embedded CPUs (akin to CPM in older
> chips).
> > + Selecting this option means that you wish to build a kernel
> > + for a machine with a QE coprocessor.
> > +
> > +if QUICC_ENGINE
> > +
> > +config UCC_SLOW
> > +   bool
> > +   default y if SERIAL_QE
> > +   help
> > + This option provides qe_lib support to UCC slow
> > + protocols: UART, BISYNC, QMC
> > +
> > +config UCC_FAST
> > +   bool
> > +   default y if UCC_GETH
> > +   help
> > + This option provides qe_lib support to UCC fast
> > + protocols: HDLC, Ethernet, ATM, transparent
> > +
> > +config UCC
> > +   bool
> > +   default y if UCC_FAST || UCC_SLOW
> > +
> > +endif
> 
> These config options could use better namespacing.
> 
> -Scott


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

[PATCH 2/2] powerpc/booke: Revert SPE/AltiVec common defines for interrupt numbers

2014-08-06 Thread Mihai Caraman
Though SPE/AltiVec shares interrupts numbers on BookE cores, use distinct
defines to identify these numbers. This improves code readability especially
in KVM.

Revert c58ce397 and 6b310fc5 patches that added common defines.

Signed-off-by: Mihai Caraman 
---
 arch/powerpc/kernel/exceptions-64e.S | 4 ++--
 arch/powerpc/kernel/head_fsl_booke.S | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/exceptions-64e.S 
b/arch/powerpc/kernel/exceptions-64e.S
index bb9cac6..3e68d1c 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -635,7 +635,7 @@ interrupt_end_book3e:
 
 /* Altivec Unavailable Interrupt */
START_EXCEPTION(altivec_unavailable);
-   NORMAL_EXCEPTION_PROLOG(0x200, BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL,
+   NORMAL_EXCEPTION_PROLOG(0x200, BOOKE_INTERRUPT_ALTIVEC_UNAVAIL,
PROLOG_ADDITION_NONE)
/* we can probably do a shorter exception entry for that one... */
EXCEPTION_COMMON(0x200)
@@ -658,7 +658,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
 /* AltiVec Assist */
START_EXCEPTION(altivec_assist);
NORMAL_EXCEPTION_PROLOG(0x220,
-   BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST,
+   BOOKE_INTERRUPT_ALTIVEC_ASSIST,
PROLOG_ADDITION_NONE)
EXCEPTION_COMMON(0x220)
INTS_DISABLE
diff --git a/arch/powerpc/kernel/head_fsl_booke.S 
b/arch/powerpc/kernel/head_fsl_booke.S
index 4f8930f..7ac2dbb 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -617,27 +617,27 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
 #ifdef CONFIG_SPE
/* SPE Unavailable */
START_EXCEPTION(SPEUnavailable)
-   NORMAL_EXCEPTION_PROLOG(SPE_ALTIVEC_UNAVAIL)
+   NORMAL_EXCEPTION_PROLOG(SPE_UNAVAIL)
beq 1f
bl  load_up_spe
b   fast_exception_return
 1: addir3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_EE_LITE(0x2010, KernelSPE)
 #elif CONFIG_SPE_POSSIBLE
-   EXCEPTION(0x2020, SPE_ALTIVEC_UNAVAIL, SPEUnavailable, \
+   EXCEPTION(0x2020, SPE_UNAVAIL, SPEUnavailable, \
  unknown_exception, EXC_XFER_EE)
 #endif /* CONFIG_SPE_POSSIBLE */
 
/* SPE Floating Point Data */
 #ifdef CONFIG_SPE
-   EXCEPTION(0x2030, SPE_FP_DATA_ALTIVEC_ASSIST, SPEFloatingPointData,
+   EXCEPTION(0x2030, SPE_FP_DATA, SPEFloatingPointData,
  SPEFloatingPointException, EXC_XFER_EE)
 
/* SPE Floating Point Round */
EXCEPTION(0x2050, SPE_FP_ROUND, SPEFloatingPointRound, \
  SPEFloatingPointRoundException, EXC_XFER_EE)
 #elif CONFIG_SPE_POSSIBLE
-   EXCEPTION(0x2040, SPE_FP_DATA_ALTIVEC_ASSIST, SPEFloatingPointData,
+   EXCEPTION(0x2040, SPE_FP_DATA, SPEFloatingPointData,
  unknown_exception, EXC_XFER_EE)
EXCEPTION(0x2050, SPE_FP_ROUND, SPEFloatingPointRound, \
  unknown_exception, EXC_XFER_EE)
-- 
1.7.11.7

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

[PATCH 1/2] powerpc/booke: Restrict SPE exception handlers to e200/e500 cores

2014-08-06 Thread Mihai Caraman
SPE exception handlers are now defined for 32-bit e500mc cores even though
SPE unit is not present and CONFIG_SPE is undefined.

Restrict SPE exception handlers to e200/e500 cores adding CONFIG_SPE_POSSIBLE
and consequently guard __stup_ivors and __setup_cpu functions.

Signed-off-by: Mihai Caraman 
---
 arch/powerpc/kernel/cpu_setup_fsl_booke.S | 12 +++-
 arch/powerpc/kernel/cputable.c|  5 +
 arch/powerpc/kernel/head_fsl_booke.S  | 18 +-
 arch/powerpc/platforms/Kconfig.cputype|  6 +-
 4 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 4f1393d..44bb2c9 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -91,6 +91,7 @@ _GLOBAL(setup_altivec_idle)
 
blr
 
+#if defined(CONFIG_E500) && defined(CONFIG_PPC_E500MC)
 _GLOBAL(__setup_cpu_e6500)
mflrr6
 #ifdef CONFIG_PPC64
@@ -107,14 +108,20 @@ _GLOBAL(__setup_cpu_e6500)
bl  __setup_cpu_e5500
mtlrr6
blr
+#endif /* CONFIG_E500 && CONFIG_PPC_E500MC */
 
 #ifdef CONFIG_PPC32
+#ifdef CONFIG_E200
 _GLOBAL(__setup_cpu_e200)
/* enable dedicated debug exception handling resources (Debug APU) */
mfspr   r3,SPRN_HID0
ori r3,r3,HID0_DAPUEN@l
mtspr   SPRN_HID0,r3
b   __setup_e200_ivors
+#endif /* CONFIG_E200 */
+
+#ifdef CONFIG_E500
+#ifndef CONFIG_PPC_E500MC
 _GLOBAL(__setup_cpu_e500v1)
 _GLOBAL(__setup_cpu_e500v2)
mflrr4
@@ -129,6 +136,7 @@ _GLOBAL(__setup_cpu_e500v2)
 #endif
mtlrr4
blr
+#else /* CONFIG_PPC_E500MC */
 _GLOBAL(__setup_cpu_e500mc)
 _GLOBAL(__setup_cpu_e5500)
mflrr5
@@ -159,7 +167,9 @@ _GLOBAL(__setup_cpu_e5500)
 2:
mtlrr5
blr
-#endif
+#endif /* CONFIG_PPC_E500MC */
+#endif /* CONFIG_E500 */
+#endif /* CONFIG_PPC32 */
 
 #ifdef CONFIG_PPC_BOOK3E_64
 _GLOBAL(__restore_cpu_e6500)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 965291b..c98719f 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -2031,6 +2031,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
 #endif /* CONFIG_PPC32 */
 #ifdef CONFIG_E500
 #ifdef CONFIG_PPC32
+#ifndef CONFIG_PPC_E500MC
{   /* e500 */
.pvr_mask   = 0x,
.pvr_value  = 0x8020,
@@ -2070,6 +2071,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check  = machine_check_e500,
.platform   = "ppc8548",
},
+#else
{   /* e500mc */
.pvr_mask   = 0x,
.pvr_value  = 0x8023,
@@ -2088,7 +2090,9 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check  = machine_check_e500mc,
.platform   = "ppce500mc",
},
+#endif /* CONFIG_PPC_E500MC */
 #endif /* CONFIG_PPC32 */
+#ifdef CONFIG_PPC_E500MC
{   /* e5500 */
.pvr_mask   = 0x,
.pvr_value  = 0x8024,
@@ -2132,6 +2136,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check  = machine_check_e500mc,
.platform   = "ppce6500",
},
+#endif /* CONFIG_PPC_E500MC */
 #ifdef CONFIG_PPC32
{   /* default match */
.pvr_mask   = 0x,
diff --git a/arch/powerpc/kernel/head_fsl_booke.S 
b/arch/powerpc/kernel/head_fsl_booke.S
index b497188..4f8930f 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -613,6 +613,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
mfspr   r10, SPRN_SPRG_RSCRATCH0
b   InstructionStorage
 
+/* Define SPE handlers for e200 and e500v2 */
 #ifdef CONFIG_SPE
/* SPE Unavailable */
START_EXCEPTION(SPEUnavailable)
@@ -622,10 +623,10 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
b   fast_exception_return
 1: addir3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_EE_LITE(0x2010, KernelSPE)
-#else
+#elif CONFIG_SPE_POSSIBLE
EXCEPTION(0x2020, SPE_ALTIVEC_UNAVAIL, SPEUnavailable, \
  unknown_exception, EXC_XFER_EE)
-#endif /* CONFIG_SPE */
+#endif /* CONFIG_SPE_POSSIBLE */
 
/* SPE Floating Point Data */
 #ifdef CONFIG_SPE
@@ -635,12 +636,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
/* SPE Floating Point Round */
EXCEPTION(0x2050, SPE_FP_ROUND, SPEFloatingPointRound, \
  SPEFloatingPointRoundException, EXC_XFER_EE)
-#else
+#elif CONFIG_SPE_POSSIBLE
EXCEPTION(0x2040, SPE_FP_DATA_ALTIVEC_ASSIST, SPEFloatingPointData,
  unknown_exception, EXC_XFER_EE)
EXCEPTION(0x2050, SPE_FP_ROUND, SPEFloatingPointRound, \

[PATCH] powerpc: Remove unused CPU_FTRS_A2

2014-08-06 Thread Michael Ellerman
In commit fb5a515704d7 "Remove platforms/wsp and associated pieces" we
removed the last user of CPU_FTRS_A2, so we should remove it too.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/cputable.h | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 0fdd7eece6d9..1de5ff3b7e42 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -458,13 +458,9 @@ extern const char *powerpc_base_platform;
CPU_FTR_PURR | CPU_FTR_REAL_LE | CPU_FTR_DABRX)
 #define CPU_FTRS_COMPATIBLE(CPU_FTR_USE_TB | CPU_FTR_PPCAS_ARCH_V2)
 
-#define CPU_FTRS_A2 (CPU_FTR_USE_TB | CPU_FTR_SMT | CPU_FTR_DBELL | \
-CPU_FTR_NOEXECUTE | CPU_FTR_NODSISRALIGN | \
-CPU_FTR_ICSWX | CPU_FTR_DABRX )
-
 #ifdef __powerpc64__
 #ifdef CONFIG_PPC_BOOK3E
-#define CPU_FTRS_POSSIBLE  (CPU_FTRS_E6500 | CPU_FTRS_E5500 | CPU_FTRS_A2)
+#define CPU_FTRS_POSSIBLE  (CPU_FTRS_E6500 | CPU_FTRS_E5500)
 #else
 #define CPU_FTRS_POSSIBLE  \
(CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 |\
@@ -515,7 +511,7 @@ enum {
 
 #ifdef __powerpc64__
 #ifdef CONFIG_PPC_BOOK3E
-#define CPU_FTRS_ALWAYS(CPU_FTRS_E6500 & CPU_FTRS_E5500 & 
CPU_FTRS_A2)
+#define CPU_FTRS_ALWAYS(CPU_FTRS_E6500 & CPU_FTRS_E5500)
 #else
 #define CPU_FTRS_ALWAYS\
(CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 &\
-- 
1.9.1

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

[PATCH] powerpc: Remove CPU_FTR_HVMODE from CPU_FTRS_ALWAYS

2014-08-06 Thread Michael Ellerman
We potentially clear CPU_FTR_HVMODE at runtime in __init_hvmode_206(),
so we must make sure it's not set in CPU_FTRS_ALWAYS.

This doesn't hurt us in practice at the moment, because we don't support
compiling only for CPUs that support CPU_FTR_HVMODE.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/cputable.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 0fdd7eece6d9..16d355e4a58b 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -520,7 +520,8 @@ enum {
 #define CPU_FTRS_ALWAYS\
(CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 &\
CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & CPU_FTRS_POWER6 &   \
-   CPU_FTRS_POWER7 & CPU_FTRS_CELL & CPU_FTRS_PA6T & CPU_FTRS_POSSIBLE)
+   CPU_FTRS_POWER7 & CPU_FTRS_CELL & CPU_FTRS_PA6T & \
+   ~CPU_FTR_HVMODE & CPU_FTRS_POSSIBLE)
 #endif
 #else
 enum {
-- 
1.9.1

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

Re: mm: BUG in unmap_page_range

2014-08-06 Thread Aneesh Kumar K.V
Mel Gorman  writes:

> From d0c77a2b497da46c52792ead066d461e5111a594 Mon Sep 17 00:00:00 2001
> From: Mel Gorman 
> Date: Tue, 5 Aug 2014 12:06:50 +0100
> Subject: [PATCH] mm: Remove misleading ARCH_USES_NUMA_PROT_NONE
>
> ARCH_USES_NUMA_PROT_NONE was defined for architectures that implemented
> _PAGE_NUMA using _PROT_NONE. This saved using an additional PTE bit and
> relied on the fact that PROT_NONE vmas were skipped by the NUMA hinting
> fault scanner. This was found to be conceptually confusing with a lot of
> implicit assumptions and it was asked that an alternative be found.
>
> Commit c46a7c81 "x86: define _PAGE_NUMA by reusing software bits on the
> PMD and PTE levels" redefined _PAGE_NUMA on x86 to be one of the swap
> PTE bits and shrunk the maximum possible swap size but it did not go far
> enough. There are no architectures that reuse _PROT_NONE as _PROT_NUMA
> but the relics still exist.
>
> This patch removes ARCH_USES_NUMA_PROT_NONE and removes some unnecessary
> duplication in powerpc vs the generic implementation by defining the types
> the core NUMA helpers expected to exist from x86 with their ppc64 equivalent.
> The unification for ppc64 is less than ideal because types do not exist
> that the "generic" code expects to. This patch works around the problem
> but it would be preferred if the powerpc people would look at this to see
> if they have opinions on what might suit them better.
>
> Signed-off-by: Mel Gorman 
> ---
>  arch/powerpc/include/asm/pgtable.h | 55 
> --
>  arch/x86/Kconfig   |  1 -
>  include/asm-generic/pgtable.h  | 35 
>  init/Kconfig   | 11 
>  4 files changed, 29 insertions(+), 73 deletions(-)
>



> -
>  #define pmdp_set_numa pmdp_set_numa
>  static inline void pmdp_set_numa(struct mm_struct *mm, unsigned long addr,
>pmd_t *pmdp)
> @@ -109,16 +71,21 @@ static inline void pmdp_set_numa(struct mm_struct *mm, 
> unsigned long addr,
>   return;
>  }
>  
> -#define pmd_mknonnuma pmd_mknonnuma
> -static inline pmd_t pmd_mknonnuma(pmd_t pmd)
> +/*
> + * Generic NUMA pte helpers expect pteval_t and pmdval_t types to exist
> + * which was inherited from x86. For the purposes of powerpc pte_basic_t is
> + * equivalent
> + */
> +#define pteval_t pte_basic_t
> +#define pmdval_t pmd_t
> +static inline pteval_t pte_flags(pte_t pte)
>  {
> - return pte_pmd(pte_mknonnuma(pmd_pte(pmd)));
> + return pte_val(pte) & PAGE_PROT_BITS;

PAGE_PROT_BITS don't get the _PAGE_NUMA and _PAGE_PRESENT. I will have
to check further to find out why the mask doesn't include
_PAGE_PRESENT. 


>  }
>  
> -#define pmd_mknuma pmd_mknuma
> -static inline pmd_t pmd_mknuma(pmd_t pmd)
> +static inline pteval_t pmd_flags(pte_t pte)
>  {


static inline pmdval_t ?

> - return pte_pmd(pte_mknuma(pmd_pte(pmd)));
> + return pmd_val(pte) & PAGE_PROT_BITS;
>  }
>  

-aneesh

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

[PATCH 2/2] powerpc/powernv: Remove duplicate check in tce_iommu_bus_notifier()

2014-08-06 Thread Gavin Shan
The called function iommu_del_device() checks if the device has
attached IOMMU group, we needn't check it again in the parent
function call tce_iommu_bus_notifier().

Signed-off-by: Gavin Shan 
---
 arch/powerpc/platforms/powernv/pci.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci.c 
b/arch/powerpc/platforms/powernv/pci.c
index f91a4e5..b562b0d 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -820,17 +820,18 @@ static int tce_iommu_bus_notifier(struct notifier_block 
*nb,
unsigned long action, void *data)
 {
struct device *dev = data;
+   int ret = 0;
 
switch (action) {
case BUS_NOTIFY_ADD_DEVICE:
-   return iommu_add_device(dev);
+   ret = iommu_add_device(dev);
+   break;
case BUS_NOTIFY_DEL_DEVICE:
-   if (dev->iommu_group)
-   iommu_del_device(dev);
-   return 0;
-   default:
-   return 0;
+   iommu_del_device(dev);
+   break;
}
+
+   return ret;
 }
 
 static struct notifier_block tce_iommu_bus_nb = {
-- 
1.8.3.2

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

[PATCH 1/2 v2] powerpc/powernv: Fix IOMMU group lost

2014-08-06 Thread Gavin Shan
When we take full hotplug to recover from EEH errors, PCI buses
could be involved. For the case, the child devices of involved
PCI buses can't be attached to IOMMU group properly, which is
caused by commit 3f28c5a ("powerpc/powernv: Reduce multi-hit of
iommu_add_device()").

When adding the PCI devices of the newly created PCI buses to
the system, the IOMMU group is expected to be added in (C).
(A) fails to bind the IOMMU group because bus->is_added is
false. (B) fails because the device doesn't have binding IOMMU
table yet. bus->is_added is set to true at end of (C) and
pdev->is_added is set to true at (D).

   pcibios_add_pci_devices()
  pci_scan_bridge()
 pci_scan_child_bus()
pci_scan_slot()
   pci_scan_single_device()
  pci_scan_device()
  pci_device_add()
 pcibios_add_device()   A: Ignore
 device_add()   B: Ignore
  pcibios_fixup_bus()
 pcibios_setup_bus_devices()
pcibios_setup_device()  C: Hit
  pcibios_finish_adding_to_bus()
 pci_bus_add_devices()
pci_bus_add_device()D: Add device

If the parent PCI bus isn't involved in hotplug, the IOMMU
group is expected to be bound in (B). (A) should fail as the
sysfs entries aren't populated.

The patch fixes the issue by reverting commit 3f28c5a and remove
WARN_ON() in iommu_add_device() to allow calling the function
even the specified device already has associated IOMMU group.

Cc:   # 3.16+
Reported-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Gavin Shan 
Acked-by: Wei Yang 
---
v2: Bail if sysfs entries aren't populated in iommu_add_device()
---
 arch/powerpc/kernel/iommu.c   | 38 +--
 arch/powerpc/platforms/powernv/pci-ioda.c |  2 +-
 2 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 88e3ec6..48fb2c1 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1120,37 +1120,41 @@ EXPORT_SYMBOL_GPL(iommu_release_ownership);
 int iommu_add_device(struct device *dev)
 {
struct iommu_table *tbl;
-   int ret = 0;
 
-   if (WARN_ON(dev->iommu_group)) {
-   pr_warn("iommu_tce: device %s is already in iommu group %d, 
skipping\n",
-   dev_name(dev),
-   iommu_group_id(dev->iommu_group));
+   /*
+* The sysfs entries should be populated before
+* binding IOMMU group. If sysfs entries isn't
+* ready, we simply bail.
+*/
+   if (!device_is_registered(dev))
+   return -ENOENT;
+
+   if (dev->iommu_group) {
+   pr_debug("%s: Skipping device %s with iommu group %d\n",
+__func__, dev_name(dev),
+iommu_group_id(dev->iommu_group));
return -EBUSY;
}
 
tbl = get_iommu_table_base(dev);
if (!tbl || !tbl->it_group) {
-   pr_debug("iommu_tce: skipping device %s with no tbl\n",
-   dev_name(dev));
+   pr_debug("%s: Skipping device %s with no tbl\n",
+__func__, dev_name(dev));
return 0;
}
 
-   pr_debug("iommu_tce: adding %s to iommu group %d\n",
-   dev_name(dev), iommu_group_id(tbl->it_group));
+   pr_debug("%s: Adding %s to iommu group %d\n",
+__func__, dev_name(dev),
+iommu_group_id(tbl->it_group));
 
if (PAGE_SIZE < IOMMU_PAGE_SIZE(tbl)) {
-   pr_err("iommu_tce: unsupported iommu page size.");
-   pr_err("%s has not been added\n", dev_name(dev));
+   pr_err("%s: Invalid IOMMU page size %lx (%lx) on %s\n",
+  __func__, IOMMU_PAGE_SIZE(tbl),
+  PAGE_SIZE, dev_name(dev));
return -EINVAL;
}
 
-   ret = iommu_group_add_device(tbl->it_group, dev);
-   if (ret < 0)
-   pr_err("iommu_tce: %s has not been added, ret=%d\n",
-   dev_name(dev), ret);
-
-   return ret;
+   return iommu_group_add_device(tbl->it_group, dev);
 }
 EXPORT_SYMBOL_GPL(iommu_add_device);
 
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index de19ede..86290eb 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -462,7 +462,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, 
struct pci_dev *pdev
 
pe = &phb->ioda.pe_array[pdn->pe_number];
WARN_ON(get_dma_ops(&pdev->dev) != &dma_iommu_ops);
-   set_iommu_table_base(&pdev->dev, &pe->tce32_table);
+   set_iommu_table_base_and_group(&pdev->dev, &pe->tce32_table);
 }
 
 static int pnv_pci_ioda_dma_set_

[PATCH] powerpc/ppc476: Disable BTAC

2014-08-06 Thread Alistair Popple
This patch disables the branch target address CAM which under specific
circumstances may cause the processor to skip execution of 1-4
instructions. This fixes IBM Erratum #47.

Signed-off-by: Alistair Popple 
---
 arch/powerpc/kernel/head_44x.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index c334f53..b5061ab 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -1210,10 +1210,12 @@ clear_utlb_entry:
 
/* We configure icbi to invalidate 128 bytes at a time since the
 * current 32-bit kernel code isn't too happy with icache != dcache
-* block size
+* block size. We also disable the BTAC as this can cause errors
+* in some circumstances (see IBM Erratum 47).
 */
mfspr   r3,SPRN_CCR0
orisr3,r3,0x0020
+   ori r3,r3,0x0040
mtspr   SPRN_CCR0,r3
isync
 
-- 
1.8.3.2

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