Re: [PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag

2013-08-26 Thread Paolo Bonzini
Il 26/08/2013 10:23, Yann Droneaud ha scritto:
 
 Sounds a lot like InfiniBand subsystem behavor: IB file descriptors
 are of no use accross exec() since memory mappings tied to those fds
 won't be available in the new process:
 
 https://lkml.org/lkml/2013/7/8/380
 http://mid.gmane.org/f58540dc64fec1ac0e496dfcd3cc1...@meuh.org

Yes, it is very similar.

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


Re: [PATCH 2/2] ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag

2013-08-26 Thread Yann Droneaud

Le 26.08.2013 09:39, Paolo Bonzini a écrit :

Il 25/08/2013 17:04, Alexander Graf ha scritto:

On 24.08.2013, at 21:14, Yann Droneaud wrote:



This patch set O_CLOEXEC flag on all file descriptors created
with anon_inode_getfd() to not leak file descriptors across exec().

Signed-off-by: Yann Droneaud ydrone...@opteya.com
Link: 
http://lkml.kernel.org/r/cover.1377372576.git.ydrone...@opteya.com


Reviewed-by: Alexander Graf ag...@suse.de

Would it make sense to simply inherit the O_CLOEXEC flag from the
parent kvm fd instead? That would give user space the power to keep
fds across exec() if it wants to.


Does it make sense to use non-O_CLOEXEC file descriptors with KVM at
all?  Besides fork() not being supported by KVM, as described in
Documentation/virtual/kvm/api.txt, the VMAs of the parent process go
away as soon as you exec().  I'm not sure how you can use the inherited
file descriptor in a sensible way after exec().



Sounds a lot like InfiniBand subsystem behavor: IB file descriptors
are of no use accross exec() since memory mappings tied to those fds
won't be available in the new process:

https://lkml.org/lkml/2013/7/8/380
http://mid.gmane.org/f58540dc64fec1ac0e496dfcd3cc1...@meuh.org

Regards.

--
Yann Droneaud
OPTEYA

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

Re: [PATCH 0/2] kvm: use anon_inode_getfd() with O_CLOEXEC flag

2013-08-26 Thread Gleb Natapov
On Sat, Aug 24, 2013 at 10:14:06PM +0200, Yann Droneaud wrote:
 Hi,
 
 Following a patchset asking to change calls to get_unused_flag() [1]
 to use O_CLOEXEC, Alex Williamson [2][3] decided to change VFIO
 to use the flag.
 
 Since it's a related subsystem to KVM, using O_CLOEXEC for
 file descriptors created by KVM might be applicable too.
 
 I'm suggesting to change calls to anon_inode_getfd() to use O_CLOEXEC
 as default flag.
 
 This patchset should be reviewed to not break existing userspace program.
 
 BTW, if it's not applicable, I would suggest that new ioctls be added to
 KVM subsystem, those ioctls would have a flag field added to their 
 arguments.
 Such flag would let userspace choose the open flag to use.
 See for example other APIs using anon_inode_getfd() such as fanotify,
 inotify, signalfd and timerfd.
 
 You might be interested to read:
 
 - Secure File Descriptor Handling (Ulrich Drepper, 2008)
   http://udrepper.livejournal.com/20407.html
 
 - Excuse me son, but your code is leaking !!! (Dan Walsh, March 2012) 
   http://danwalsh.livejournal.com/53603.html
 
Applied, thanks.

 Regards.
 
 [1] http://lkml.kernel.org/r/cover.1376327678.git.ydrone...@opteya.com
 [2] http://lkml.kernel.org/r/1377186804.25163.17.ca...@ul30vt.home
 [3] http://lkml.kernel.org/r/20130822171744.1297.13711.st...@bling.home
 
 Yann Droneaud (2):
   kvm: use anon_inode_getfd() with O_CLOEXEC flag
   ppc: kvm: use anon_inode_getfd() with O_CLOEXEC flag
 
  arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
  arch/powerpc/kvm/book3s_64_vio.c| 2 +-
  arch/powerpc/kvm/book3s_hv.c| 2 +-
  virt/kvm/kvm_main.c | 6 +++---
  4 files changed, 6 insertions(+), 6 deletions(-)
 
 -- 
 1.8.3.1

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


Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes

2013-08-26 Thread Hongbo Zhang

On 08/23/2013 11:17 AM, Hongbo Zhang wrote:

On 08/22/2013 07:16 AM, Stephen Warren wrote:

On 08/21/2013 05:00 PM, Scott Wood wrote:

On Wed, 2013-08-21 at 16:40 -0600, Stephen Warren wrote:

On 07/29/2013 04:49 AM, hongbo.zh...@freescale.com wrote:

+- reg   : registers mapping for channel
+- interrupts: interrupt mapping for DMA channel 
IRQ

s/interrupts/specifier/

Do you mean s/interrupt mapping/interrupt specifier/?

And probably s/registers mapping/register specifier/ as well.

Yup.


OK, I will update these descriptions.

Since Scott has clarified all the doubts, and no further comment till 
now, so my next iteration will include this s/mapping/specifier only.
I will sent it out this Tuesday, if there is still any comment/doubt, 
please let me know.



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


Re: Ethernet over PCIe driver for Inter-Processor Communication

2013-08-26 Thread Saravanan S
Hi All,
 First of all thank you  all for taking your time out to reply



On Fri, Aug 23, 2013 at 3:59 AM, Ira W. Snyder i...@ovro.caltech.edu wrote:

 On Thu, Aug 22, 2013 at 02:43:38PM -0700, David Hawkins wrote:
  Hi S.Saravanan,
 
   I have a custom board  with four MPC8640 nodes connected over
   a transparent PCI express switch . In this configuration one node is
   configured as host(Root Complex) and others as agents(End Point). Thus
   the legacy PCI software works fine . However the mainline kernel lacks
   any standard support for Inter-processor communication over PCI. I am
   in the process of developing an Ethernet over  PCI driver for the same
   on the lines of rionet . However I am facing the following problems.
  
   a)   I can generate MSI interrupts from End Point to Root Complex over
   PCI . But the vice-versa is not possible . However i need a method to
   interrupt the End Point from the Root Complex to complete my driver.
 
  Root complex's would normally interrupt a device via a PCIe write
  to a register in a BAR on the end-point (or in extended configuration
  space registers depending on the hardware implementation).

 MPC8640 End point implements only the Type 0 header (Page 1116) . The
header implements five BARs (Page 1165).


   Only previous references I can find are this post
  
 http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg25765.html
   However this uses doorbells and I think may not be possible in MPC8640.
 
  PCIe drivers need some way to interrupt the processor, so there must
  be an option somewhere ... for example, what are the message register
  interrupts intended for? See p479
 
  http://cache.freescale.com/files/32bit/doc/ref_manual/MPC8641DRM.pdf
 
  (Ira and myself have not used the MPC8640 so are not familiar with
  its user manual).


   Message registers  are for interrupting the processor . A write to them
sends an interrupt to the processor .  Actually message registers are used
by the RC to enable interrupts to the processor when an EP sends an MSI
transaction to RC.In RC driver  i register separately for the msi
interrupts from all three EPs.

 To access them in the EP from the RC  i will have to set an inbound window
mapping the PIC register space in the EP  to the PCI mem space  assigned to
it . An inbound window maps a PCI address on the bus received by the PCIe
controller to a platform address. I will try that and let u know .

 
   Any pointers on this issue and guidance on this driver development
 would
   be helpful .
 
  We use the Ethernet-over-PCI driver that Ira developed. Our next boards
  will use an MPC8308, but we don't currently have any in a PCIe device
  form-factor (just the MPC8038RDB), so he has not ported it to PCIe.
 
  Feel free to discuss your ideas for your PCIe driver (eg., why start
  with rionet rather than Ira's driver), either on-list, or email Ira
  and myself directly


To be frank with you there was no particular reason in starting with
rionet. Maybe because our board also had SRIO interface and we are using
rionet driver successfully. I had looked at Ira's driver later. I will
study that also and try   to come back with a skeleton for my driver.



 One further note. You might want to look at rproc/rpmsg and their virtio
 driver support. That seems to be where the Linux world is moving for
 inter-processor communications. See for example the ARM CPUs interfacing
 with DSPs.

 Ira


I will study that as i am not familiar with virtio .

Regards,

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

Re: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction

2013-08-26 Thread Zhang Haijun

On 08/23/2013 11:40 PM, Scott Wood wrote:

On Fri, 2013-08-23 at 14:39 +0800, Zhang Haijun wrote:

Hi, Anton and all

Is there any advice on these two patches ?

[PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system
transaction
[PATCH 3/4 V3] mmc: esdhc: Correct host version of T4240-R1.0-R2.0.


[PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
This patch is Act-by Scott.
Patch 4/4 is split to four patches and Act-by Anton.


Thanks all.




[snip]

+   if (!(((SVR_SOC_VER(svr) == SVR_T4240)  (SVR_REV(svr) == 0x10))
||
+   ((SVR_SOC_VER(svr) == SVR_B4860)  (SVR_REV(svr) == 0x10))
||
+   ((SVR_SOC_VER(svr) == SVR_P1010)  (SVR_REV(svr) == 0x10))
||
+   ((SVR_SOC_VER(svr) == SVR_P3041)  (SVR_REV(svr) = 0x20))
||
+   ((SVR_SOC_VER(svr) == SVR_P2041)  (SVR_REV(svr) = 0x20))
||
+   ((SVR_SOC_VER(svr) == SVR_P5040)  SVR_REV(svr) == 0x20)))
+   return;

You need to include variants here.  If P5040 is affected, then P5021 is
affected.  If P2041 is affected, then P2040 is affected, etc.

-Scott



Hi, Scott

This workaround is for CR:ENGR00229586: A-005055, Configs Affected 
onlylist these soc and its version.

I was also wonder why only these boards?

But Ican't add soc like P5021 as I think it should be. Maybe there are 
some difference between them.


--
Thanks  Regards

Haijun

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

Re: [PATCH V3] mmc:of_spi: Update the code of getting voltage-ranges

2013-08-26 Thread Zhang Haijun

On 08/25/2013 12:19 PM, Chris Ball wrote:

Hi Haijun,

On Sun, Aug 11 2013, Haijun Zhang wrote:

Using function mmc_of_parse_voltage() to get voltage-ranges.

Signed-off-by: Haijun Zhang haijun.zh...@freescale.com

The patchset contains patches 1-3 of 3, and also this unnumbered patch
v3.  Which order should I use to apply this patch?

Thanks,

- Chris.


Thanks Chris,

So, I'll numbered them an resend them to you.

Thanks a lot.

--
Thanks  Regards

Haijun

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

Re: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction

2013-08-26 Thread Zhang Haijun

On 08/26/2013 09:03 AM, Zhang Haijun wrote:

On 08/23/2013 11:40 PM, Scott Wood wrote:

On Fri, 2013-08-23 at 14:39 +0800, Zhang Haijun wrote:

Hi, Anton and all

Is there any advice on these two patches ?

[PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system
transaction
[PATCH 3/4 V3] mmc: esdhc: Correct host version of T4240-R1.0-R2.0.


[PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
This patch is Act-by Scott.
Patch 4/4 is split to four patches and Act-by Anton.


Thanks all.




[snip]

+   if (!(((SVR_SOC_VER(svr) == SVR_T4240)  (SVR_REV(svr) == 0x10))
||
+   ((SVR_SOC_VER(svr) == SVR_B4860)  (SVR_REV(svr) == 0x10))
||
+   ((SVR_SOC_VER(svr) == SVR_P1010)  (SVR_REV(svr) == 0x10))
||
+   ((SVR_SOC_VER(svr) == SVR_P3041)  (SVR_REV(svr) = 0x20))
||
+   ((SVR_SOC_VER(svr) == SVR_P2041)  (SVR_REV(svr) = 0x20))
||
+   ((SVR_SOC_VER(svr) == SVR_P5040)  SVR_REV(svr) == 0x20)))
+   return;

You need to include variants here.  If P5040 is affected, then P5021 is
affected.  If P2041 is affected, then P2040 is affected, etc.

-Scott



Hi, Scott

This workaround is for CR:ENGR00229586: A-005055, Configs Affected 
onlylist these soc and its version.

I was also wonder why only these boards?

But Ican't add soc like P5021 as I think it should be. Maybe there are 
some difference between them.


--
Thanks  Regards

Haijun

Hi, Scott

I found there are update about this errata.

I'll update thispatch.

Thanks.

--
Thanks  Regards

Haijun

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

Re: [PATCH] powerpc/kvm: Handle the boundary condition correctly

2013-08-26 Thread Alexander Graf

On 26.08.2013, at 05:28, Aneesh Kumar K.V wrote:

 Alexander Graf ag...@suse.de writes:
 
 On 23.08.2013, at 04:31, Aneesh Kumar K.V wrote:
 
 Alexander Graf ag...@suse.de writes:
 
 On 22.08.2013, at 12:37, Aneesh Kumar K.V wrote:
 
 From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
 
 Isn't this you?
 
 Yes. The patches are generated using git format-patch and sent by
 git send-email. That's how it always created patches for me. I am not sure 
 if
 there is a config I can change to avoid having From:
 
 
 
 We should be able to copy upto count bytes
 
 Why?
 
 
 Without this we end up doing
 
 +struct kvm_get_htab_buf {
 +struct kvm_get_htab_header header;
 +/*
 + * Older kernel required one extra byte.
 + */
 +unsigned long hpte[3];
 +} hpte_buf;
 
 
 even though we are only looking for one hpte entry.
 
 Ok, please give me an example with real numbers and why it breaks.
 
 
 http://mid.gmane.org/1376995766-16526-4-git-send-email-aneesh.ku...@linux.vnet.ibm.com
 
 
 Didn't quiet get what you are looking for. As explained before, we now
 need to pass an array with array size 3 even though we know we need to
 read only 2 entries because kernel doesn't loop correctly.

But we need to do that regardless, because newer QEMU needs to be able to run 
on older kernels, no?


Alex

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


Re: [PATCH] powerpc/kvm: Handle the boundary condition correctly

2013-08-26 Thread Aneesh Kumar K.V
Alexander Graf ag...@suse.de writes:

 On 26.08.2013, at 05:28, Aneesh Kumar K.V wrote:

 Alexander Graf ag...@suse.de writes:
 
 On 23.08.2013, at 04:31, Aneesh Kumar K.V wrote:
 
 Alexander Graf ag...@suse.de writes:
 
 On 22.08.2013, at 12:37, Aneesh Kumar K.V wrote:
 
 From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
 
 Isn't this you?
 
 Yes. The patches are generated using git format-patch and sent by
 git send-email. That's how it always created patches for me. I am not sure 
 if
 there is a config I can change to avoid having From:
 
 
 
 We should be able to copy upto count bytes
 
 Why?
 
 
 Without this we end up doing
 
 +struct kvm_get_htab_buf {
 +struct kvm_get_htab_header header;
 +/*
 + * Older kernel required one extra byte.
 + */
 +unsigned long hpte[3];
 +} hpte_buf;
 
 
 even though we are only looking for one hpte entry.
 
 Ok, please give me an example with real numbers and why it breaks.
 
 
 http://mid.gmane.org/1376995766-16526-4-git-send-email-aneesh.ku...@linux.vnet.ibm.com
 
 
 Didn't quiet get what you are looking for. As explained before, we now
 need to pass an array with array size 3 even though we know we need to
 read only 2 entries because kernel doesn't loop correctly.

 But we need to do that regardless, because newer QEMU needs to be able to run 
 on older kernels, no?


yes. So use space will have to pass an array of size 3. But that should
not prevent us from fixing this right ?

-aneesh

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


Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support

2013-08-26 Thread Gleb Natapov
On Wed, Aug 14, 2013 at 10:51:14AM +1000, Benjamin Herrenschmidt wrote:
 On Thu, 2013-08-01 at 14:44 +1000, Alexey Kardashevskiy wrote:
  This is to reserve a capablity number for upcoming support
  of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
  which support mulptiple DMA map/unmap operations per one call.
 
 Gleb, any chance you can put this (and the next one) into a tree to
 lock in the numbers ?
 
Applied it. Sorry for slow response, was on vocation and still go
through the email backlog.

 I've been wanting to apply the whole series to powerpc-next, that's
 stuff has been simmering for way too long and is in a good enough shape
 imho, but I need the capabilities and ioctl numbers locked in your tree
 first.
 
 Cheers,
 Ben.
 
  Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
  ---
  Changes:
  2013/07/16:
  * changed the number
  
  Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
  ---
   include/uapi/linux/kvm.h | 1 +
   1 file changed, 1 insertion(+)
  
  diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
  index acccd08..99c2533 100644
  --- a/include/uapi/linux/kvm.h
  +++ b/include/uapi/linux/kvm.h
  @@ -667,6 +667,7 @@ struct kvm_ppc_smmu_info {
   #define KVM_CAP_PPC_RTAS 91
   #define KVM_CAP_IRQ_XICS 92
   #define KVM_CAP_ARM_EL1_32BIT 93
  +#define KVM_CAP_SPAPR_MULTITCE 94
   
   #ifdef KVM_CAP_IRQ_ROUTING
   
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

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


Re: Pull request: scottwood/linux.git next

2013-08-26 Thread Scott Wood
On Fri, 2013-08-23 at 20:07 -0500, Scott Wood wrote:
 The following changes since commit afbcdd97bf117bc2d01b865a32f78f662437a4d8:
 
   powerpc/wsp: Fix early debug build (2013-08-16 10:59:27 +1000)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
 
 for you to fetch changes up to 622e03eb3498c32ee29de5c1d6d381f443e58fad:
 
   powerpc/85xx: Add C293PCIE board support (2013-08-23 19:43:24 -0500)
 
 
 Chunhe Lan (1):
   powerpc/85xx: Add P1023RDB board support
 
 Haijun.Zhang (1):
   powerpc/85xx: Add support for 85xx cpu type detection
 
 Mingkai Hu (3):
   powerpc/85xx: Add SEC6.0 device tree
   powerpc/85xx: Add silicon device tree for C293
   powerpc/85xx: Add C293PCIE board support
 
 Scott Wood (5):
   powerpc/fsl-booke: Work around erratum A-006958
   powerpc: Convert some mftb/mftbu into mfspr
   powerpc/85xx: Remove -Wa,-me500
   powerpc/booke64: Use appropriate -mcpu
   powerpc/e500: Set -mcpu flag for 32-bit e500
 
 Wang Dongsheng (1):
   powerpc: add Book E support to 64-bit hibernation

Oh, forgot again: Highlights include changes in compiler flag settings
on e500 family cores, booke64 hibernation support, support for two new
boards, and an erratum workaround.

-Scott



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


Re: [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system transaction

2013-08-26 Thread Scott Wood
On Mon, 2013-08-26 at 09:03 +0800, Zhang Haijun wrote:
 On 08/23/2013 11:40 PM, Scott Wood wrote:
 
  On Fri, 2013-08-23 at 14:39 +0800, Zhang Haijun wrote:
   Hi, Anton and all
   
   Is there any advice on these two patches ?
   
   [PATCH 2/4 V2] mmc: esdhc: workaround for dma err in the last system 
   transaction
   [PATCH 3/4 V3] mmc: esdhc: Correct host version of T4240-R1.0-R2.0.
   
   
   [PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
   This patch is Act-by Scott.
   Patch 4/4 is split to four patches and Act-by Anton.
   
   
   Thanks all.
   
   
   
  [snip]
 + if (!(((SVR_SOC_VER(svr) == SVR_T4240)  (SVR_REV(svr) == 
 0x10))
 ||
 + ((SVR_SOC_VER(svr) == SVR_B4860)  (SVR_REV(svr) == 
 0x10))
 ||
 + ((SVR_SOC_VER(svr) == SVR_P1010)  (SVR_REV(svr) == 
 0x10))
 ||
 + ((SVR_SOC_VER(svr) == SVR_P3041)  (SVR_REV(svr) = 
 0x20))
 ||
 + ((SVR_SOC_VER(svr) == SVR_P2041)  (SVR_REV(svr) = 
 0x20))
 ||
 + ((SVR_SOC_VER(svr) == SVR_P5040)  SVR_REV(svr) == 
 0x20)))
 + return;
  You need to include variants here.  If P5040 is affected, then P5021 is
  affected.  If P2041 is affected, then P2040 is affected, etc.
  
  -Scott
  
  
 Hi, Scott
 
 This workaround is for CR:ENGR00229586: A-005055, Configs Affected
 only list these soc and its version.
 I was also wonder why only these boards?
 
 But I can't add soc like P5021 as I think it should be. Maybe there
 are some difference between them.

The only difference between P5040 and P5021 is the number of cores
enabled.  It is physically the same silicon.  Likewise with a lot of
other variants.

-Scott



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


Re: [v3] powerpc/mpc85xx: Update the clock device tree nodes

2013-08-26 Thread Scott Wood
On Sun, 2013-08-25 at 21:42 -0500, Tang Yuantian-B29983 wrote:
  
 clockgen: global-utilities@e1000 {
   - compatible = fsl,b4420-clockgen, fsl,qoriq-clockgen-2.0;
   + compatible = fsl,b4420-clockgen, fsl,qoriq-clockgen-2.0,
   +fixed-clock;
   + clock-output-names = sysclk;
   + #clock-cells = 0;
  
  Does U-Boot fill in clock-frequency here?
  
 Yes, clock-frequency will be filled by uboot.
 You suggested we'd better not add it here.

Right -- I was just making sure.

   + #address-cells = 1;
   + #size-cells = 0;
   + pll0: pll0@800 {
   + #clock-cells = 1;
   + reg = 0x800;
   + compatible = fsl,core-pll-clock;
   + clocks = clockgen;
   + clock-output-names = pll0, pll0-div2, pll0-div4;
   + };
   + pll1: pll1@820 {
   + #clock-cells = 1;
   + reg = 0x820;
   + compatible = fsl,core-pll-clock;
   + clocks = clockgen;
   + clock-output-names = pll1, pll1-div2, pll1-div4;
   + };
  
  Please leave a blank line between properties and nodes, and between nodes.
  
 OK, will add.
 
  What does reg represent?  Where is the binding for this?
  
  The compatible is too vague.
 Reg is register offset.

With no size?

 I should have had a binding document.
 About the compatible, you should pointed it out earlier in SDK review.

Sorry, it doesn't work that way.  I don't know why I didn't notice this
stuff there -- the SDK review was probably rushed, with someone shouting
urgent.  The SDK does not dictate what goes upstream.  Device tree
bindings should go upstream first.

 It is too later to change since the clock driver is merged for months 
 although 
 I sent this patch first.

It should not have gone in without an approved binding.  It seems it
went in via Mike Turquette (why is a non-ARM-specific tree using
linux-arm-kernel as its list, BTW?).  No ack from Ben, Kumar, or me is
shown in the commit.

In any case, you can preserve compatibility with existing trees without
using this compatible in new trees.  The driver can check for both
compatibles, with a comment indicating that fsl,core-mux-clock is
deprecated and for compatibility only.

 Besides, it is not too bad because other arch use the similar name.

I don't follow.  This is a specific Freescale register interface, not a
general concept.

In any case, which similar names are you referring to?  A search in
arch/arm/boot/dts for mux with clk or clock turns up
allwinner,sun4i-apb1-mux-clk which is much more specific than
fsl,core-mux-clock.

-Scott



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


Re: Loading kernel on MPC86x

2013-08-26 Thread Scott Wood
On Sat, 2013-08-24 at 19:15 +0200, Martin Hinner wrote:
 Hello again,
 
   just a quick update: I have spent some more time on this and now I
 can boot into kernel (it works even with initramfs and simple assembly
 HelloWorld, so it's time to compile userland now). The problem was
 that kernel must be at location 0. Another problem was that interrupts
 got re-enabled during execution of my bootloader (I am doing some
 syscalls - goes  to Cisco rom),

Do you mean you're calling into the rom after Linux has already started
executing?  That's not normal for 8xx.

  otherwise it crashed randomly. And
 finally it seems that stack must be  8M. After this kernel boots.
 
 Anyway, I would still appreciate clarification on vmlinux:__start
 entry conditions:
 
 - must be loaded at 0 (but why arch/powerpc/boot/main.c has option to
 allocate space for kernel at nonzero addr ?)

arch/powerpc/boot/main.c is not just for 8xx.

 - stack? Does it really have to be  8M ?

The stack is allocated by the kernel.  It shouldn't matter what is in r1
when you initially enter the kernel.

 - interrupts disabled (really ;-) )
 - MSR.PR=0/LE=0/EE=0, but what other bits (RI? IP=0? ME?)
 - IMMR 0xff00
 - and of course correct entry arguments in registers
 
 anything else?
 
 I am also curious why CONFIG_PPC_EARLY_DEBUG_CPM uses
 CONFIG_PPC_EARLY_DEBUG_CPM_ADDR as pointer to transmit SMC buffer and
 not address of CPM/SCM parameter RAM ? TX buffer address can be read
 from SMC parameter RAM. Wouldn't this solution be more portable? At
 least this way I do it when I take over console from Cisco
 startup/rommon.

The point was to keep things as simple as possible (e.g. for use in
temporary handcoded asm as needed).  This is a hacky debugging feature
that assumes you know what you're doing and can set the address to match
what the loader does (and that the loader's choice of address is
static).  If you have an improvement that keeps it simple, feel free to
send a patch.

-Scott



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


Re: Loading kernel on MPC86x

2013-08-26 Thread Martin Hinner
On Mon, Aug 26, 2013 at 7:14 PM, Scott Wood scottw...@freescale.com wrote:
 that kernel must be at location 0. Another problem was that interrupts
 got re-enabled during execution of my bootloader (I am doing some
 syscalls - goes  to Cisco rom),
 Do you mean you're calling into the rom after Linux has already started
 executing?  That's not normal for 8xx.

No, in bootloader. I have disabled interrupts and then later did a
syscall which probably enabled them again. As I have overwritten some
of Cisco ROM data it crashed (at random place).

 I am also curious why CONFIG_PPC_EARLY_DEBUG_CPM uses
 CONFIG_PPC_EARLY_DEBUG_CPM_ADDR as pointer to transmit SMC buffer and
 not address of CPM/SCM parameter RAM ? TX buffer address can be read
 from SMC parameter RAM. Wouldn't this solution be more portable? At
 least this way I do it when I take over console from Cisco
 startup/rommon.

 The point was to keep things as simple as possible (e.g. for use in
 temporary handcoded asm as needed).  This is a hacky debugging feature
 that assumes you know what you're doing and can set the address to match
 what the loader does (and that the loader's choice of address is
 static).  If you have an improvement that keeps it simple, feel free to
 send a patch.

How about making CONFIG_PPC_EARLY_DEBUG_CPM_PARRAM that woud carry
address of SMCx parameter RAM (IMMR+0x04180 on MPC866) and this value
would be used in case CONFIG_PPC_EARLY_DEBUG_CPM_ADDR is zero ? This
would allow kernel hackers to still use
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR for assembly debugging (+legacy use)
and everyone else can use it as a more reliable option that does not
rely on particular bootloader behavior. Early debug is good even for
end-users so as they can send debug output if anything goes wrong at
early stage.

Anyway, difference between _PARRAM and _ADDR is only one lwz
instruction, so I guess it is possible to completely discard _ADDR if
there is no legacy use for it. I am also not sure if this works with
SCC UART ports or only CPM SMC UART.

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


[PATCH] powerpc/hvsi: increase handshake timeout from 200ms to 400ms.

2013-08-26 Thread Eugene Surovegin
This solves a problem observed in kexec'ed kernel where 200ms timeout is
too short and bootconsole fails to initialize. Console did eventually
become workable but much later into the boot process.

Observed timeout was around 260ms, but I decided to make it a little bigger
for more reliability.

This has been tested on Power7 machine with Petitboot as a primary
bootloader and PowerNV firmware.

Signed-off-by: Eugene Surovegin surove...@google.com
---
 drivers/tty/hvc/hvsi_lib.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/hvc/hvsi_lib.c b/drivers/tty/hvc/hvsi_lib.c
index 3396eb9..ac27671 100644
--- a/drivers/tty/hvc/hvsi_lib.c
+++ b/drivers/tty/hvc/hvsi_lib.c
@@ -341,8 +341,8 @@ void hvsilib_establish(struct hvsi_priv *pv)
 
pr_devel(HVSI@%x:   ... waiting handshake\n, pv-termno);
 
-   /* Try for up to 200s */
-   for (timeout = 0; timeout  20; timeout++) {
+   /* Try for up to 400ms */
+   for (timeout = 0; timeout  40; timeout++) {
if (pv-established)
goto established;
if (!hvsi_get_packet(pv))
-- 
1.7.10.2

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


[RFC PATCH v3 00/12] Machine check handling in linux host.

2013-08-26 Thread Mahesh J Salgaonkar
Hi,

Please find the patch set that performs the machine check handling inside linux
host. The design is to be able to handle re-entrancy so that we do not clobber
the machine check information during nested machine check interrupt.

The patch 2 introduces separate emergency stack in paca structure exclusively
for machine check exception handling.  Patch 3 implements the logic to save the
raw MCE info onto the emergency stack and prepares to take another exception.
Patch 4 implements the additional checks that helps to decide whether to
deliver machine check event to host kernel right away or queue it up and
return. Patch 5 and 6 adds CPU-side hooks for early machine check handler
and TLB flush. The patch 7 and 8 is responsible to detect SLB/TLB errors and
flush them off in the real mode. The patch 9 implements the logic to decode
and save high level MCE information to per cpu buffer without clobbering.
Patch 10 implements mechanism to queue up MCE event in cases where early
handler can not deliver the event to host kernel right away. The patch 12
adds the basic error handling to the high level C code with MMU on.

I have tested SLB multihit, MC coming from opal context on powernv.

Please review and let me know your comments.

Changes in v3:
- Rebased to v3.11-rc7
- Handle MCE coming from opal context, secondary thread nap and return
  from interrupt. Queue up the MCE event in this scenario and log it
  later during syscall exit path. (patch 4 and 10).

Changes in v2:
- Moved early machine check handling code under CPU_FTR_HVMODE section.
  This makes sure that the early machine check handler will get executed
  only in hypervisor kernel.
- Add dedicated emergency stack for machine check so that we don't end up
  disturbing others who use same emergency stack.
- Fixed the machine check early handle where it used to assume that r1 always
  contains the valid stack pointer.
- Fixed an issue where per-cpu mce_nest_count variable underflows when kvm
  fails to handle MC error and exit the guest.
- Fixed the code to restore r13 while before exiting early handler.

Thanks,
-Mahesh.
---

Mahesh Salgaonkar (12):
  powerpc/book3s: Split the common exception prolog logic into two section.
  powerpc/book3s: Introduce exclusive emergency stack for machine check 
exception.
  powerpc/book3s: handle machine check in Linux host.
  Validate r1 value before going to host kernel in virtual mode.
  powerpc/book3s: Introduce a early machine check hook in cpu_spec.
  powerpc/book3s: Add flush_tlb operation in cpu_spec.
  powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on 
power7.
  powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on 
power8.
  powerpc/book3s: Decode and save machine check event.
  Queue up and process delayed MCE events.
  powerpc/powernv: Remove machine check handling in OPAL.
  powerpc/powernv: Machine check exception handling.


 arch/powerpc/include/asm/bitops.h|5 
 arch/powerpc/include/asm/cputable.h  |   12 +
 arch/powerpc/include/asm/exception-64s.h |   67 +++---
 arch/powerpc/include/asm/mce.h   |  198 +
 arch/powerpc/include/asm/paca.h  |9 +
 arch/powerpc/kernel/Makefile |1 
 arch/powerpc/kernel/asm-offsets.c|4 
 arch/powerpc/kernel/cpu_setup_power.S|   38 ++-
 arch/powerpc/kernel/cputable.c   |   16 +
 arch/powerpc/kernel/entry_64.S   |5 
 arch/powerpc/kernel/exceptions-64s.S |  181 
 arch/powerpc/kernel/mce.c|  345 ++
 arch/powerpc/kernel/mce_power.c  |  287 +
 arch/powerpc/kernel/setup_64.c   |   10 +
 arch/powerpc/kernel/traps.c  |   15 +
 arch/powerpc/kvm/book3s_hv_ras.c |   50 ++--
 arch/powerpc/platforms/powernv/opal.c|  161 --
 arch/powerpc/xmon/xmon.c |4 
 18 files changed, 1228 insertions(+), 180 deletions(-)
 create mode 100644 arch/powerpc/include/asm/mce.h
 create mode 100644 arch/powerpc/kernel/mce.c
 create mode 100644 arch/powerpc/kernel/mce_power.c

-- 
-Mahesh

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


[RFC PATCH v3 01/12] powerpc/book3s: Split the common exception prolog logic into two section.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

This patch splits the common exception prolog logic into two parts to
facilitate reuse of existing code in the next patch. The second part will
be reused in the machine check exception routine in the next patch.

Please note that this patch does not introduce or change existing code
logic. Instead it is just a code movement.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/exception-64s.h |   67 --
 1 file changed, 35 insertions(+), 32 deletions(-)

diff --git a/arch/powerpc/include/asm/exception-64s.h 
b/arch/powerpc/include/asm/exception-64s.h
index 07ca627..2386d40 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -248,6 +248,40 @@ do_kvm_##n:
\
 
 #define NOTEST(n)
 
+#define EXCEPTION_PROLOG_COMMON_2(n, area)\
+   std r2,GPR2(r1);/* save r2 in stackframe*/ \
+   SAVE_4GPRS(3, r1);  /* save r3 - r6 in stackframe   */ \
+   SAVE_2GPRS(7, r1);  /* save r7, r8 in stackframe*/ \
+   ld  r9,area+EX_R9(r13); /* move r9, r10 to stackframe   */ \
+   ld  r10,area+EX_R10(r13);  \
+   std r9,GPR9(r1);   \
+   std r10,GPR10(r1); \
+   ld  r9,area+EX_R11(r13);/* move r11 - r13 to stackframe */ \
+   ld  r10,area+EX_R12(r13);  \
+   ld  r11,area+EX_R13(r13);  \
+   std r9,GPR11(r1);  \
+   std r10,GPR12(r1); \
+   std r11,GPR13(r1); \
+   BEGIN_FTR_SECTION_NESTED(66);  \
+   ld  r10,area+EX_CFAR(r13); \
+   std r10,ORIG_GPR3(r1); \
+   END_FTR_SECTION_NESTED(CPU_FTR_CFAR, CPU_FTR_CFAR, 66);\
+   GET_LR(r9,area);/* Get LR, later save to stack  */ \
+   ld  r2,PACATOC(r13);/* get kernel TOC into r2   */ \
+   std r9,_LINK(r1);  \
+   mfctr   r10;/* save CTR in stackframe   */ \
+   std r10,_CTR(r1);  \
+   lbz r10,PACASOFTIRQEN(r13);\
+   mfspr   r11,SPRN_XER;   /* save XER in stackframe   */ \
+   std r10,SOFTE(r1); \
+   std r11,_XER(r1);  \
+   li  r9,(n)+1;  \
+   std r9,_TRAP(r1);   /* set trap number  */ \
+   li  r10,0; \
+   ld  r11,exception_marker@toc(r2);  \
+   std r10,RESULT(r1); /* clear regs-result   */ \
+   std r11,STACK_FRAME_OVERHEAD-16(r1); /* mark the frame  */
+
 /*
  * The common exception prolog is used for all except a few exceptions
  * such as a segment miss on a kernel address.  We have to be prepared
@@ -281,38 +315,7 @@ do_kvm_##n:
\
beq 4f; /* if from kernel mode  */ \
ACCOUNT_CPU_USER_ENTRY(r9, r10);   \
SAVE_PPR(area, r9, r10);   \
-4: std r2,GPR2(r1);/* save r2 in stackframe*/ \
-   SAVE_4GPRS(3, r1);  /* save r3 - r6 in stackframe   */ \
-   SAVE_2GPRS(7, r1);  /* save r7, r8 in stackframe*/ \
-   ld  r9,area+EX_R9(r13); /* move r9, r10 to stackframe   */ \
-   ld  r10,area+EX_R10(r13);  \
-   std r9,GPR9(r1);   \
-   std r10,GPR10(r1); \
-   ld  r9,area+EX_R11(r13);/* move r11 - r13 to stackframe */ \
-   ld  r10,area+EX_R12(r13);  \
-   ld  r11,area+EX_R13(r13);  \
-   std r9,GPR11(r1);  \
-   std r10,GPR12(r1); \
-   std r11,GPR13(r1); \
-   BEGIN_FTR_SECTION_NESTED(66); 

[RFC PATCH v3 02/12] powerpc/book3s: Introduce exclusive emergency stack for machine check exception.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

This patch introduces exclusive emergency stack for machine check exception.
We use emergency stack to handle machine check exception so that we can save
MCE information (srr1, srr0, dar and dsisr) before turning on ME bit and be
ready for re-entrancy. This helps us to prevent clobbering of MCE information
in case of nested machine checks.

The reason for using emergency stack over normal kernel stack is that the
machine check might occur in the middle of setting up a stack frame which may
result into improper use of kernel stack.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/paca.h |9 +
 arch/powerpc/kernel/setup_64.c  |   10 +-
 arch/powerpc/xmon/xmon.c|4 
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 77c91e7..b4ca4e9 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -147,6 +147,15 @@ struct paca_struct {
 */
struct opal_machine_check_event *opal_mc_evt;
 #endif
+#ifdef CONFIG_PPC_BOOK3S_64
+   /* Exclusive emergency stack pointer for machine check exception. */
+   void *mc_emergency_sp;
+   /*
+* Flag to check whether we are in machine check early handler
+* and already using emergency stack.
+*/
+   u16 in_mce;
+#endif
 
/* Stuff for accurate time accounting */
u64 user_time;  /* accumulated usermode TB ticks */
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 389fb807..6f96af0 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -529,7 +529,8 @@ static void __init exc_lvl_early_init(void)
 
 /*
  * Stack space used when we detect a bad kernel stack pointer, and
- * early in SMP boots before relocation is enabled.
+ * early in SMP boots before relocation is enabled. Exclusive emergency
+ * stack for machine checks.
  */
 static void __init emergency_stack_init(void)
 {
@@ -552,6 +553,13 @@ static void __init emergency_stack_init(void)
sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
sp += THREAD_SIZE;
paca[i].emergency_sp = __va(sp);
+
+#ifdef CONFIG_PPC_BOOK3S_64
+   /* emergency stack for machine check exception handling. */
+   sp  = memblock_alloc_base(THREAD_SIZE, THREAD_SIZE, limit);
+   sp += THREAD_SIZE;
+   paca[i].mc_emergency_sp = __va(sp);
+#endif
}
 }
 
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 96bf5bd..5f17adb 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2044,6 +2044,10 @@ static void dump_one_paca(int cpu)
DUMP(p, stab_addr, lx);
 #endif
DUMP(p, emergency_sp, p);
+#ifdef CONFIG_PPC_BOOK3S_64
+   DUMP(p, mc_emergency_sp, p);
+   DUMP(p, in_mce, x);
+#endif
DUMP(p, data_offset, lx);
DUMP(p, hw_cpu_id, x);
DUMP(p, cpu_start, x);

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


[RFC PATCH v3 03/12] powerpc/book3s: handle machine check in Linux host.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

Move machine check entry point into Linux. So far we were dependent on
firmware to decode MCE error details and handover the high level info to OS.

This patch introduces early machine check routine that saves the MCE
information (srr1, srr0, dar and dsisr) to the emergency stack. We allocate
stack frame on emergency stack and set the r1 accordingly. This allows us to be
prepared to take another exception without loosing context. One thing to note
here that, if we get another machine check while ME bit is off then we risk a
checkstop. Hence we restrict ourselves to save only MCE information and turn
the ME bit on. We use paca-in_mce flag to differentiate between first entry
and nested machine check entry which helps proper use of emergency stack. We
increment paca-in_mce every time we enter in early machine check handler and
decrement it while leaving. When we enter machine check early handler first
time (paca-in_mce == 0), we are sure nobody is using MC emergency stack and
allocate a stack frame at the start of the emergency stack. During subsequent
entry (paca-in_mce  0), we know that r1 points inside emergency stack and we
allocate separate stack frame accordingly. This prevents us from clobbering MCE
information during nested machine checks.

The early machine check handler changes are placed under CPU_FTR_HVMODE
section. This makes sure that the early machine check handler will get executed
only in hypervisor kernel.

This is the code flow:

Machine Check Interrupt
|
V
   0x200 vector   ME=0, IR=0, DR=0
|
V
+---+
|machine_check_pSeries_early:   | ME=0, IR=0, DR=0
|   Alloc frame on emergency stack  |
|   Save srr1, srr0, dar and dsisr on stack |
+---+
|
(ME=1, IR=0, DR=0, RFID)
|
V
machine_check_handle_earlyME=1, IR=0, DR=0
|
V
+---+
|   machine_check_early (r3=pt_regs)| ME=1, IR=0, DR=0
|   Things to do: (in next patches) |
|   Flush SLB for SLB errors|
|   Flush TLB for TLB errors|
|   Decode and save MCE info|
+---+
|
(Fall through existing exception handler routine.)
|
V
machine_check_pSerie  ME=1, IR=0, DR=0
|
(ME=1, IR=1, DR=1, RFID)
|
V
machine_check_common  ME=1, IR=1, DR=1
.
.
.


Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/kernel/asm-offsets.c|4 +
 arch/powerpc/kernel/exceptions-64s.S |  109 ++
 arch/powerpc/kernel/traps.c  |   12 
 3 files changed, 125 insertions(+)

diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 8207459..e0e8ebb 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -238,6 +238,10 @@ int main(void)
DEFINE(PACA_DTL_RIDX, offsetof(struct paca_struct, dtl_ridx));
 #endif /* CONFIG_PPC_STD_MMU_64 */
DEFINE(PACAEMERGSP, offsetof(struct paca_struct, emergency_sp));
+#ifdef CONFIG_PPC_BOOK3S_64
+   DEFINE(PACAMCEMERGSP, offsetof(struct paca_struct, mc_emergency_sp));
+   DEFINE(PACA_IN_MCE, offsetof(struct paca_struct, in_mce));
+#endif
DEFINE(PACAHWCPUID, offsetof(struct paca_struct, hw_cpu_id));
DEFINE(PACAKEXECSTATE, offsetof(struct paca_struct, kexec_state));
DEFINE(PACA_STARTTIME, offsetof(struct paca_struct, starttime));
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 902ca3c..651a213 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -156,7 +156,11 @@ machine_check_pSeries_1:
HMT_MEDIUM_PPR_DISCARD
SET_SCRATCH0(r13)   /* save r13 */
EXCEPTION_PROLOG_0(PACA_EXMC)
+BEGIN_FTR_SECTION
+   b   machine_check_pSeries_early
+FTR_SECTION_ELSE
b   machine_check_pSeries_0
+ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
 
. = 0x300
.globl data_access_pSeries
@@ -404,6 +408,61 @@ denorm_exception_hv:
 
.align  7
/* moved from 0x200 */

[RFC PATCH v3 04/12] Validate r1 value before going to host kernel in virtual mode.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

We can get machine checks from any context. We need to make sure that
we handle all of them correctly. Once we decode MCE reason and generate
MCE event, we continue in host kernel in virtual mode so that we can
log/display it later. But before going to virtual mode we need to make
sure that r1 points to host kernel stack. But machine check can occur
in any context and r1 may not always point to host kernel stack. In cases
where we can not trust r1 value, we should queue up the MCE event and return
from interrupt. This patch implements the additional checks that helps to
decide whether to deleiver machine check event to host kernel right away
or queue it up and return.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/kernel/exceptions-64s.S |   72 ++
 1 file changed, 71 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 651a213..d82ebac 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -785,8 +785,78 @@ BEGIN_FTR_SECTION
bl  .save_nvgprs
addir3,r1,STACK_FRAME_OVERHEAD
bl  .machine_check_early
+
+   /*
+* We are now going to host kernel in V mode. We need to make sure
+* that r1 points to host kernel stack.
+*
+* If we are coming from userspace then we can continue in host kernel
+* in V mode.
+* But if we are coming from kernel and r1 does not point to kernel
+* stack then we can not continue, instead we return from here.
+*/
+
+   ld  r12,_MSR(r1)
+   andi.   r11,r12,MSR_PR  /* See if coming from user. */
+   bne 3f  /* continue if we are. */
+
+#ifdef CONFIG_KVM_BOOK3S_64_HV
+   /*
+* We are coming from kernel context. Check if we are coming from
+* guest. if yes, then we can continue. We will fall through
+* do_kvm_200-kvmppc_interrupt which will setup r1 correctly.
+*/
+   lbz r11,HSTATE_IN_GUEST(r13)
+   cmpwi   r11,0   /* Check if coming from guest */
+   bne 3f  /* continue if we are. */
+
+   /*
+* So, we did not come from guest. That leaves three possibilities:
+* a. We come from secondary thread which just came out of nap and
+*about to call kvm_start_guest.
+* b. We come from secondary thread which is about to go to nap
+*state (see kvm_no_guest()).
+* c. We come from opal context and r1 may be pointing to opal
+*kernel stack.
+*/
+
+   lbz r11,HSTATE_HWTHREAD_STATE(r13)
+   cmpwi   r11,KVM_HWTHREAD_IN_NAP /* Was it nap-ing? or about to */
+   beq 0f  /* Queue up event and return from interrupt */
+#endif
+
+   /*
+* So far we checked all possible situations where we can not
+* trust r1. Now we can trust r1.
+*  r1  0  r1 points to host kernel stack
+*  r1  0  r1 points to opal stack
+*/
+   ld  r11,GPR1(r1)
+   cmpdi   r11,0   /* check if r1 is in kernel. */
+   blt+3f  /* Continue if yes. */
+
+   /*
+* r1 points to opal stack. Queue up the MCE event and return
+* from the interrupt. But before that, check if this is an
+* un-recoverable exception. If yes, then stay on emergency
+* stack and panic.
+*/
+0: andi.   r11,r12,MSR_RI
+   bne 2f
+
+1: addir3,r1,STACK_FRAME_OVERHEAD
+   bl  .unrecoverable_exception
+   b   1b
+
+   /*
+* Return from MC interrupt.
+* TODO: Queue up the MCE event so that we can log it later.
+*/
+2: MACHINE_CHECK_HANDLER_WINDUP
+   rfid
+
/* Deliver the machine check to host kernel in V mode. */
-   MACHINE_CHECK_HANDLER_WINDUP
+3: MACHINE_CHECK_HANDLER_WINDUP
b   machine_check_pSeries
 END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
 

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


[RFC PATCH v3 05/12] powerpc/book3s: Introduce a early machine check hook in cpu_spec.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

This patch adds the early machine check function pointer in cputable for
CPU specific early machine check handling. The early machine handle routine
will be called in real mode to handle SLB and TLB errors. This patch just
sets up a mechanism invoke CPU specific handler. The subsequent patches
will populate the function pointer.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/cputable.h |7 +++
 arch/powerpc/kernel/traps.c |7 +--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 6f3887d..d8c098e 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -90,6 +90,13 @@ struct cpu_spec {
 * if the error is fatal, 1 if it was fully recovered and 0 to
 * pass up (not CPU originated) */
int (*machine_check)(struct pt_regs *regs);
+
+   /*
+* Processor specific early machine check handler which is
+* called in real mode to handle SLB and TLB errors.
+*/
+   long(*machine_check_early)(struct pt_regs *regs);
+
 };
 
 extern struct cpu_spec *cur_cpu_spec;
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index e8d6bf1..8b0a946 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -292,8 +292,11 @@ void system_reset_exception(struct pt_regs *regs)
  */
 long machine_check_early(struct pt_regs *regs)
 {
-   /* TODO: handle/decode machine check reason */
-   return 0;
+   long handled = 0;
+
+   if (cur_cpu_spec  cur_cpu_spec-machine_check_early)
+   handled = cur_cpu_spec-machine_check_early(regs);
+   return handled;
 }
 
 #endif

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


[RFC PATCH v3 06/12] powerpc/book3s: Add flush_tlb operation in cpu_spec.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

This patch introduces flush_tlb operation in cpu_spec structure. This will
help us to invoke appropriate CPU-side flush tlb routine. This patch
adds the foundation to invoke CPU specific flush routine for respective
architectures. Currently this patch introduce flush_tlb for p7 and p8.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/cputable.h   |5 
 arch/powerpc/kernel/cpu_setup_power.S |   38 +++--
 arch/powerpc/kernel/cputable.c|8 +++
 arch/powerpc/kvm/book3s_hv_ras.c  |   18 +++-
 4 files changed, 44 insertions(+), 25 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index d8c098e..d76e47b 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -97,6 +97,11 @@ struct cpu_spec {
 */
long(*machine_check_early)(struct pt_regs *regs);
 
+   /*
+* Processor specific routine to flush tlbs.
+*/
+   void(*flush_tlb)(unsigned long inval_selector);
+
 };
 
 extern struct cpu_spec *cur_cpu_spec;
diff --git a/arch/powerpc/kernel/cpu_setup_power.S 
b/arch/powerpc/kernel/cpu_setup_power.S
index 18b5b9c..37d1bb0 100644
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -29,7 +29,7 @@ _GLOBAL(__setup_cpu_power7)
mtspr   SPRN_LPID,r0
mfspr   r3,SPRN_LPCR
bl  __init_LPCR
-   bl  __init_TLB
+   bl  __init_tlb_power7
mtlrr11
blr
 
@@ -42,7 +42,7 @@ _GLOBAL(__restore_cpu_power7)
mtspr   SPRN_LPID,r0
mfspr   r3,SPRN_LPCR
bl  __init_LPCR
-   bl  __init_TLB
+   bl  __init_tlb_power7
mtlrr11
blr
 
@@ -59,7 +59,7 @@ _GLOBAL(__setup_cpu_power8)
orisr3, r3, LPCR_AIL_3@h
bl  __init_LPCR
bl  __init_HFSCR
-   bl  __init_TLB
+   bl  __init_tlb_power8
bl  __init_PMU_HV
mtlrr11
blr
@@ -78,7 +78,7 @@ _GLOBAL(__restore_cpu_power8)
orisr3, r3, LPCR_AIL_3@h
bl  __init_LPCR
bl  __init_HFSCR
-   bl  __init_TLB
+   bl  __init_tlb_power8
bl  __init_PMU_HV
mtlrr11
blr
@@ -134,15 +134,31 @@ __init_HFSCR:
mtspr   SPRN_HFSCR,r3
blr
 
-__init_TLB:
-   /*
-* Clear the TLB using the IS 3 form of tlbiel instruction
-* (invalidate by congruence class). P7 has 128 CCs, P8 has 512
-* so we just always do 512
-*/
+/*
+ * Clear the TLB using the specified IS form of tlbiel instruction
+ * (invalidate by congruence class). P7 has 128 CCs., P8 has 512.
+ *
+ * r3 = IS field
+ */
+__init_tlb_power7:
+   li  r3,0xc00/* IS field = 0b11 */
+_GLOBAL(__flush_tlb_power7)
+   li  r6,128
+   mtctr   r6
+   mr  r7,r3   /* IS field */
+   ptesync
+2: tlbiel  r7
+   addir7,r7,0x1000
+   bdnz2b
+   ptesync
+1: blr
+
+__init_tlb_power8:
+   li  r3,0xc00/* IS field = 0b11 */
+_GLOBAL(__flush_tlb_power8)
li  r6,512
mtctr   r6
-   li  r7,0xc00/* IS field = 0b11 */
+   mr  r7,r3   /* IS field */
ptesync
 2: tlbiel  r7
addir7,r7,0x1000
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 22973a7..cdbe115 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -71,6 +71,8 @@ extern void __restore_cpu_power7(void);
 extern void __setup_cpu_power8(unsigned long offset, struct cpu_spec* spec);
 extern void __restore_cpu_power8(void);
 extern void __restore_cpu_a2(void);
+extern void __flush_tlb_power7(unsigned long inval_selector);
+extern void __flush_tlb_power8(unsigned long inval_selector);
 #endif /* CONFIG_PPC64 */
 #if defined(CONFIG_E500)
 extern void __setup_cpu_e5500(unsigned long offset, struct cpu_spec* spec);
@@ -440,6 +442,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.oprofile_cpu_type  = ppc64/ibm-compat-v1,
.cpu_setup  = __setup_cpu_power7,
.cpu_restore= __restore_cpu_power7,
+   .flush_tlb  = __flush_tlb_power7,
.platform   = power7,
},
{   /* 2.07-compliant processor, i.e. Power8 architected mode */
@@ -456,6 +459,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.oprofile_cpu_type  = ppc64/ibm-compat-v1,
.cpu_setup  = __setup_cpu_power8,
.cpu_restore= __restore_cpu_power8,
+   .flush_tlb  = __flush_tlb_power8,
.platform   = power8,
},
{   

[RFC PATCH v3 08/12] powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on power8.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

This patch handles the memory errors on power8. If we get a machine check
exception due to SLB or TLB errors, then flush SLBs/TLBs and reload SLBs to
recover.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/mce.h  |3 +++
 arch/powerpc/kernel/cputable.c  |4 
 arch/powerpc/kernel/mce_power.c |   34 ++
 3 files changed, 41 insertions(+)

diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index ba19073..6866062 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -64,4 +64,7 @@
 P7_DSISR_MC_SLB_MULTIHIT | \
 P7_DSISR_MC_SLB_MULTIHIT_PARITY)
 
+#define P8_DSISR_MC_SLB_ERRORS (P7_DSISR_MC_SLB_ERRORS | \
+P8_DSISR_MC_ERAT_MULTIHIT_SEC)
+
 #endif /* __ASM_PPC64_MCE_H__ */
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index c28cc2c..0195358 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -74,6 +74,7 @@ extern void __restore_cpu_a2(void);
 extern void __flush_tlb_power7(unsigned long inval_selector);
 extern void __flush_tlb_power8(unsigned long inval_selector);
 extern long __machine_check_early_realmode_p7(struct pt_regs *regs);
+extern long __machine_check_early_realmode_p8(struct pt_regs *regs);
 #endif /* CONFIG_PPC64 */
 #if defined(CONFIG_E500)
 extern void __setup_cpu_e5500(unsigned long offset, struct cpu_spec* spec);
@@ -462,6 +463,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup  = __setup_cpu_power8,
.cpu_restore= __restore_cpu_power8,
.flush_tlb  = __flush_tlb_power8,
+   .machine_check_early= __machine_check_early_realmode_p8,
.platform   = power8,
},
{   /* Power7 */
@@ -521,6 +523,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup  = __setup_cpu_power8,
.cpu_restore= __restore_cpu_power8,
.flush_tlb  = __flush_tlb_power8,
+   .machine_check_early= __machine_check_early_realmode_p8,
.platform   = power8,
},
{   /* Power8 */
@@ -540,6 +543,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup  = __setup_cpu_power8,
.cpu_restore= __restore_cpu_power8,
.flush_tlb  = __flush_tlb_power8,
+   .machine_check_early= __machine_check_early_realmode_p8,
.platform   = power8,
},
{   /* Cell Broadband Engine */
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index 645d722..949d102 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -151,3 +151,37 @@ long __machine_check_early_realmode_p7(struct pt_regs 
*regs)
/* TODO: Decode machine check reason. */
return handled;
 }
+
+static long mce_handle_ierror_p8(uint64_t srr1)
+{
+   long handled = 0;
+
+   handled = mce_handle_common_ierror(srr1);
+
+   if (P7_SRR1_MC_IFETCH(srr1) == P8_SRR1_MC_IFETCH_ERAT_MULTIHIT) {
+   flush_and_reload_slb();
+   handled = 1;
+   }
+   return handled;
+}
+
+static long mce_handle_derror_p8(uint64_t dsisr)
+{
+   return mce_handle_derror(dsisr, P8_DSISR_MC_SLB_ERRORS);
+}
+
+long __machine_check_early_realmode_p8(struct pt_regs *regs)
+{
+   uint64_t srr1;
+   long handled = 1;
+
+   srr1 = regs-msr;
+
+   if (P7_SRR1_MC_LOADSTORE(srr1))
+   handled = mce_handle_derror_p8(regs-dsisr);
+   else
+   handled = mce_handle_ierror_p8(srr1);
+
+   /* TODO: Decode machine check reason. */
+   return handled;
+}

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


[RFC PATCH v3 07/12] powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on power7.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

If we get a machine check exception due to SLB or TLB errors, then flush
SLBs/TLBs and reload SLBs to recover. We do this in real mode before turning
on MMU. Otherwise we would run into nested machine checks.

If we get a machine check when we are in guest, then just flush the
SLBs and continue. This patch handles errors for power7. The next
patch will handle errors for power8

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/bitops.h |5 +
 arch/powerpc/include/asm/mce.h|   67 
 arch/powerpc/kernel/Makefile  |1 
 arch/powerpc/kernel/cputable.c|4 +
 arch/powerpc/kernel/mce_power.c   |  153 +
 5 files changed, 230 insertions(+)
 create mode 100644 arch/powerpc/include/asm/mce.h
 create mode 100644 arch/powerpc/kernel/mce_power.c

diff --git a/arch/powerpc/include/asm/bitops.h 
b/arch/powerpc/include/asm/bitops.h
index 910194e..a57f4bc 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -46,6 +46,11 @@
 #include asm/asm-compat.h
 #include asm/synch.h
 
+/* PPC bit number conversion */
+#define PPC_BIT(bit)   (0x8000UL  (bit))
+#define PPC_BITLSHIFT(be)  (63 - (be))
+#define PPC_BITMASK(bs, be)((PPC_BIT(bs) - PPC_BIT(be)) | PPC_BIT(bs))
+
 /*
  * clear_bit doesn't imply a memory barrier
  */
diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
new file mode 100644
index 000..ba19073
--- /dev/null
+++ b/arch/powerpc/include/asm/mce.h
@@ -0,0 +1,67 @@
+/*
+ * Machine check exception header file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2013 IBM Corporation
+ * Author: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
+ */
+
+#ifndef __ASM_PPC64_MCE_H__
+#define __ASM_PPC64_MCE_H__
+
+#include linux/bitops.h
+
+/*
+ * Machine Check bits on power7 and power8
+ */
+#define P7_SRR1_MC_LOADSTORE(srr1) ((srr1)  PPC_BIT(42)) /* P8 too */
+
+/* SRR1 bits for machine check (On Power7 and Power8) */
+#define P7_SRR1_MC_IFETCH(srr1)((srr1)  PPC_BITMASK(43, 45)) /* P8 
too */
+
+#define P7_SRR1_MC_IFETCH_UE   (0x1  PPC_BITLSHIFT(45)) /* P8 too */
+#define P7_SRR1_MC_IFETCH_SLB_PARITY   (0x2  PPC_BITLSHIFT(45)) /* P8 too */
+#define P7_SRR1_MC_IFETCH_SLB_MULTIHIT (0x3  PPC_BITLSHIFT(45)) /* P8 too */
+#define P7_SRR1_MC_IFETCH_SLB_BOTH (0x4  PPC_BITLSHIFT(45)) /* P8 too */
+#define P7_SRR1_MC_IFETCH_TLB_MULTIHIT (0x5  PPC_BITLSHIFT(45)) /* P8 too */
+#define P7_SRR1_MC_IFETCH_UE_TLB_RELOAD(0x6  PPC_BITLSHIFT(45)) /* 
P8 too */
+#define P7_SRR1_MC_IFETCH_UE_IFU_INTERNAL  (0x7  PPC_BITLSHIFT(45))
+
+/* SRR1 bits for machine check (On Power8) */
+#define P8_SRR1_MC_IFETCH_ERAT_MULTIHIT(0x4  PPC_BITLSHIFT(45))
+
+/* DSISR bits for machine check (On Power7 and Power8) */
+#define P7_DSISR_MC_UE (PPC_BIT(48))   /* P8 too */
+#define P7_DSISR_MC_UE_TABLEWALK   (PPC_BIT(49))   /* P8 too */
+#define P7_DSISR_MC_ERAT_MULTIHIT  (PPC_BIT(52))   /* P8 too */
+#define P7_DSISR_MC_TLB_MULTIHIT_MFTLB (PPC_BIT(53))   /* P8 too */
+#define P7_DSISR_MC_SLB_PARITY_MFSLB   (PPC_BIT(55))   /* P8 too */
+#define P7_DSISR_MC_SLB_MULTIHIT   (PPC_BIT(56))   /* P8 too */
+#define P7_DSISR_MC_SLB_MULTIHIT_PARITY(PPC_BIT(57))   /* P8 too */
+
+/*
+ * DSISR bits for machine check (Power8) in addition to above.
+ * Secondary DERAT Multihit
+ */
+#define P8_DSISR_MC_ERAT_MULTIHIT_SEC  (PPC_BIT(54))
+
+/* SLB error bits */
+#define P7_DSISR_MC_SLB_ERRORS (P7_DSISR_MC_ERAT_MULTIHIT | \
+P7_DSISR_MC_SLB_PARITY_MFSLB | \
+P7_DSISR_MC_SLB_MULTIHIT | \
+P7_DSISR_MC_SLB_MULTIHIT_PARITY)
+
+#endif /* __ASM_PPC64_MCE_H__ */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index a8619bf..a1aba53 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_PPC64)   += setup_64.o sys_ppc32.o \
 obj-$(CONFIG_HAVE_HW_BREAKPOINT)   += hw_breakpoint.o
 obj-$(CONFIG_PPC_BOOK3S_64)+= cpu_setup_ppc970.o cpu_setup_pa6t.o
 

[RFC PATCH v3 09/12] powerpc/book3s: Decode and save machine check event.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

Now that we handle machine check in linux, the MCE decoding should also
take place in linux host. This info is crucial to log before we go down
in case we can not handle the machine check errors. This patch decodes
and populates a machine check event which contain high level meaning full
MCE information.

We do this in real mode C code with ME bit on. The MCE information is still
available on emergency stack (in pt_regs structure format). Even if we take
another exception at this point the MCE early handler will allocate a new
stack frame on top of current one. So when we return back here we still have
our MCE information safe on current stack.

We use per cpu buffer to save high level MCE information. Each per cpu buffer
is an array of machine check event structure indexed by per cpu counter
mce_nest_count. The mce_nest_count is incremented every time we enter
machine check early handler in real mode to get the current free slot
(index = mce_nest_count - 1). The mce_nest_count is decremented once the
MCE info is consumed by virtual mode machine exception handler.

This patch provides save_mce_event(), get_mce_event() and release_mce_event()
generic routines that can be used by machine check handlers to populate and
retrieve the event. The routine release_mce_event() will free the event slot so
that it can be reused. Caller can invoke get_mce_event() with a release flag
either to release the event slot immediately OR keep it so that it can be
fetched again. The event slot can be also released anytime by invoking
release_mce_event().

This patch also updates kvm code to invoke get_mce_event to retrieve generic
mce event rather than paca-opal_mce_evt.

The KVM code always calls get_mce_event() with release flags set to false so
that event is available for linus host machine

If machine check occurs while we are in guest, KVM tries to handle the error.
If KVM is able to handle MC error successfully, it enters the guest and
delivers the machine check to guest. If KVM is not able to handle MC error, it
exists the guest and passes the control to linux host machine check handler
which then logs MC event and decides how to handle it in linux host. In failure
case, KVM needs to make sure that the MC event is available for linux host to
consume. Hence KVM always calls get_mce_event() with release flags set to false
and later it invokes release_mce_event() only if it succeeds to handle error.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/mce.h|  124 +
 arch/powerpc/kernel/Makefile  |2 
 arch/powerpc/kernel/mce.c |  164 +
 arch/powerpc/kernel/mce_power.c   |  116 ++-
 arch/powerpc/kvm/book3s_hv_ras.c  |   32 --
 arch/powerpc/platforms/powernv/opal.c |   35 +++
 6 files changed, 434 insertions(+), 39 deletions(-)
 create mode 100644 arch/powerpc/kernel/mce.c

diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index 6866062..d319161 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -66,5 +66,129 @@
 
 #define P8_DSISR_MC_SLB_ERRORS (P7_DSISR_MC_SLB_ERRORS | \
 P8_DSISR_MC_ERAT_MULTIHIT_SEC)
+enum MCE_Version {
+   MCE_V1 = 1,
+};
+
+enum MCE_Severity {
+   MCE_SEV_NO_ERROR = 0,
+   MCE_SEV_WARNING = 1,
+   MCE_SEV_ERROR_SYNC = 2,
+   MCE_SEV_FATAL = 3,
+};
+
+enum MCE_Disposition {
+   MCE_DISPOSITION_RECOVERED = 0,
+   MCE_DISPOSITION_NOT_RECOVERED = 1,
+};
+
+enum MCE_Initiator {
+   MCE_INITIATOR_UNKNOWN = 0,
+   MCE_INITIATOR_CPU = 1,
+};
+
+enum MCE_ErrorType {
+   MCE_ERROR_TYPE_UNKNOWN = 0,
+   MCE_ERROR_TYPE_UE = 1,
+   MCE_ERROR_TYPE_SLB = 2,
+   MCE_ERROR_TYPE_ERAT = 3,
+   MCE_ERROR_TYPE_TLB = 4,
+};
+
+enum MCE_UeErrorType {
+   MCE_UE_ERROR_INDETERMINATE = 0,
+   MCE_UE_ERROR_IFETCH = 1,
+   MCE_UE_ERROR_PAGE_TABLE_WALK_IFETCH = 2,
+   MCE_UE_ERROR_LOAD_STORE = 3,
+   MCE_UE_ERROR_PAGE_TABLE_WALK_LOAD_STORE = 4,
+};
+
+enum MCE_SlbErrorType {
+   MCE_SLB_ERROR_INDETERMINATE = 0,
+   MCE_SLB_ERROR_PARITY = 1,
+   MCE_SLB_ERROR_MULTIHIT = 2,
+};
+
+enum MCE_EratErrorType {
+   MCE_ERAT_ERROR_INDETERMINATE = 0,
+   MCE_ERAT_ERROR_PARITY = 1,
+   MCE_ERAT_ERROR_MULTIHIT = 2,
+};
+
+enum MCE_TlbErrorType {
+   MCE_TLB_ERROR_INDETERMINATE = 0,
+   MCE_TLB_ERROR_PARITY = 1,
+   MCE_TLB_ERROR_MULTIHIT = 2,
+};
+
+struct machine_check_event {
+   enum MCE_Versionversion:8;  /* 0x00 */
+   uint8_t in_use; /* 0x01 */
+   enum MCE_Severity   severity:8; /* 0x02 */
+   enum MCE_Initiator  initiator:8;/* 0x03 */
+   enum MCE_ErrorType  error_type:8;   /* 0x04 */
+   enum MCE_Dispositiondisposition:8;  /* 

[RFC PATCH v3 11/12] powerpc/powernv: Remove machine check handling in OPAL.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

Now that we are ready to handle machine check directly in linux, do not
register with firmware to handle machine check exception.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/powernv/opal.c |8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index f789514..0170d19 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -83,14 +83,10 @@ static int __init opal_register_exception_handlers(void)
if (!(powerpc_firmware_features  FW_FEATURE_OPAL))
return -ENODEV;
 
-   /* Hookup some exception handlers. We use the fwnmi area at 0x7000
-* to provide the glue space to OPAL
+   /* Hookup some exception handlers except machine check. We use the
+* fwnmi area at 0x7000 to provide the glue space to OPAL
 */
glue = 0x7000;
-   opal_register_exception_handler(OPAL_MACHINE_CHECK_HANDLER,
-   __pa(opal_mc_secondary_handler[0]),
-   glue);
-   glue += 128;
opal_register_exception_handler(OPAL_HYPERVISOR_MAINTENANCE_HANDLER,
0, glue);
glue += 128;

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


[RFC PATCH v3 10/12] Queue up and process delayed MCE events.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

When machine check real mode handler can not continue into host kernel
in V mode, it returns from the interrupt and we loose MCE event which
never gets logged. In such a situation queue up the MCE event so that
we can log it later when we get back into host kernel with r1 pointing to
kernel stack e.g. during syscall exit.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/mce.h|3 +
 arch/powerpc/kernel/entry_64.S|5 +
 arch/powerpc/kernel/exceptions-64s.S  |6 +
 arch/powerpc/kernel/mce.c |  154 +
 arch/powerpc/platforms/powernv/opal.c |   97 -
 5 files changed, 167 insertions(+), 98 deletions(-)

diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index d319161..1c20731 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -190,5 +190,8 @@ extern void save_mce_event(struct pt_regs *regs, long 
handled,
   struct mce_error_info *mce_err, uint64_t addr);
 extern int get_mce_event(struct machine_check_event *mce, bool release);
 extern void release_mce_event(void);
+extern void machine_check_queue_event(void);
+extern void machine_check_process_queued_event(void);
+extern void machine_check_print_event_info(struct machine_check_event *evt);
 
 #endif /* __ASM_PPC64_MCE_H__ */
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2bd0b88..71bcd41 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -183,6 +183,11 @@ syscall_exit:
bl  .do_show_syscall_exit
ld  r3,RESULT(r1)
 #endif
+#ifdef CONFIG_PPC_BOOK3S_64
+BEGIN_FTR_SECTION
+   bl  .machine_check_process_queued_event
+END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
+#endif
CURRENT_THREAD_INFO(r12, r1)
 
ld  r8,_MSR(r1)
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index d82ebac..d20a456 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -850,9 +850,11 @@ BEGIN_FTR_SECTION
 
/*
 * Return from MC interrupt.
-* TODO: Queue up the MCE event so that we can log it later.
+* Queue up the MCE event so that we can log it later, while
+* returning from kernel or opal call.
 */
-2: MACHINE_CHECK_HANDLER_WINDUP
+2: bl  .machine_check_queue_event
+   MACHINE_CHECK_HANDLER_WINDUP
rfid
 
/* Deliver the machine check to host kernel in V mode. */
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index aeecdf1..1cca4b6 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -31,6 +31,10 @@
 static DEFINE_PER_CPU(int, mce_nest_count);
 static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT], mce_event);
 
+/* Queue for delayed MCE events. */
+static DEFINE_PER_CPU(int, mce_queue_count);
+static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT], mce_event_queue);
+
 static void mce_set_error_info(struct machine_check_event *mce,
   struct mce_error_info *mce_err)
 {
@@ -162,3 +166,153 @@ void release_mce_event(void)
 {
get_mce_event(NULL, true);
 }
+
+/*
+ * Queue up the MCE event which then can be handled later.
+ */
+void machine_check_queue_event(void)
+{
+   int index;
+   struct machine_check_event evt;
+
+   if (!get_mce_event(evt, MCE_EVENT_RELEASE))
+   return;
+
+   index = __get_cpu_var(mce_queue_count)++;
+   /* If queue is full, just return for now. */
+   if (index = MAX_MC_EVT) {
+   __get_cpu_var(mce_queue_count)--;
+   return;
+   }
+   __get_cpu_var(mce_event_queue[index]) = evt;
+}
+
+/*
+ * process pending MCE event from the mce event queue. This function will be
+ * called during syscall exit.
+ */
+void machine_check_process_queued_event(void)
+{
+   int index;
+
+   preempt_disable();
+   /*
+* For now just print it to console.
+* TODO: log this error event to FSP or nvram.
+*/
+   while (__get_cpu_var(mce_queue_count)  0) {
+   index = __get_cpu_var(mce_queue_count) - 1;
+   machine_check_print_event_info(
+   __get_cpu_var(mce_event_queue[index]));
+   __get_cpu_var(mce_queue_count)--;
+   }
+   preempt_enable();
+}
+
+void machine_check_print_event_info(struct machine_check_event *evt)
+{
+   const char *level, *sevstr, *subtype;
+   static const char *mc_ue_types[] = {
+   Indeterminate,
+   Instruction fetch,
+   Page table walk ifetch,
+   Load/Store,
+   Page table walk Load/Store,
+   };
+   static const char *mc_slb_types[] = {
+   Indeterminate,
+   Parity,
+

[RFC PATCH v3 12/12] powerpc/powernv: Machine check exception handling.

2013-08-26 Thread Mahesh J Salgaonkar
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com

Add basic error handling in machine check exception handler.

- If MSR_RI isn't set, we can not recover.
- Check if disposition set to OpalMCE_DISPOSITION_RECOVERED.
- Check if address at fault is inside kernel address space, if not then send
  SIGBUS to process if we hit exception when in userspace.
- If address at fault is not provided then and if we get a synchronous machine
  check while in userspace then kill the task.

Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/mce.h|1 +
 arch/powerpc/kernel/mce.c |   27 +
 arch/powerpc/platforms/powernv/opal.c |   43 -
 3 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index 1c20731..f72ea4c 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -193,5 +193,6 @@ extern void release_mce_event(void);
 extern void machine_check_queue_event(void);
 extern void machine_check_process_queued_event(void);
 extern void machine_check_print_event_info(struct machine_check_event *evt);
+extern uint64_t get_mce_fault_addr(struct machine_check_event *evt);
 
 #endif /* __ASM_PPC64_MCE_H__ */
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index 1cca4b6..3100509 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -316,3 +316,30 @@ void machine_check_print_event_info(struct 
machine_check_event *evt)
break;
}
 }
+
+uint64_t get_mce_fault_addr(struct machine_check_event *evt)
+{
+   switch (evt-error_type) {
+   case MCE_ERROR_TYPE_UE:
+   if (evt-u.ue_error.effective_address_provided)
+   return evt-u.ue_error.effective_address;
+   break;
+   case MCE_ERROR_TYPE_SLB:
+   if (evt-u.slb_error.effective_address_provided)
+   return evt-u.slb_error.effective_address;
+   break;
+   case MCE_ERROR_TYPE_ERAT:
+   if (evt-u.erat_error.effective_address_provided)
+   return evt-u.erat_error.effective_address;
+   break;
+   case MCE_ERROR_TYPE_TLB:
+   if (evt-u.tlb_error.effective_address_provided)
+   return evt-u.tlb_error.effective_address;
+   break;
+   default:
+   case MCE_ERROR_TYPE_UNKNOWN:
+   break;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(get_mce_fault_addr);
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 0170d19..2070970 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -17,6 +17,7 @@
 #include linux/interrupt.h
 #include linux/notifier.h
 #include linux/slab.h
+#include linux/sched.h
 #include asm/opal.h
 #include asm/firmware.h
 #include asm/mce.h
@@ -240,6 +241,44 @@ int opal_put_chars(uint32_t vtermno, const char *data, int 
total_len)
return written;
 }
 
+static int opal_recover_mce(struct pt_regs *regs,
+   struct machine_check_event *evt)
+{
+   int recovered = 0;
+   uint64_t ea = get_mce_fault_addr(evt);
+
+   if (!(regs-msr  MSR_RI)) {
+   /* If MSR_RI isn't set, we cannot recover */
+   recovered = 0;
+   } else if (evt-disposition == MCE_DISPOSITION_RECOVERED) {
+   /* Platform corrected itself */
+   recovered = 1;
+   } else if (ea  !is_kernel_addr(ea)) {
+   /*
+* Faulting address is not in kernel text. We should be fine.
+* We need to find which process uses this address.
+* For now, kill the task if we have received exception when
+* in userspace.
+*
+* TODO: Queue up this address for hwpoisioning later.
+*/
+   if (user_mode(regs)  !is_global_init(current)) {
+   _exception(SIGBUS, regs, BUS_MCEERR_AR, regs-nip);
+   recovered = 1;
+   } else
+   recovered = 0;
+   } else if (user_mode(regs)  !is_global_init(current) 
+   evt-severity == MCE_SEV_ERROR_SYNC) {
+   /*
+* If we have received a synchronous error when in userspace
+* kill the task.
+*/
+   _exception(SIGBUS, regs, BUS_MCEERR_AR, regs-nip);
+   recovered = 1;
+   }
+   return recovered;
+}
+
 int opal_machine_check(struct pt_regs *regs)
 {
struct machine_check_event evt;
@@ -255,7 +294,9 @@ int opal_machine_check(struct pt_regs *regs)
}
machine_check_print_event_info(evt);
 
-   return evt.severity == MCE_SEV_FATAL ? 0 : 1;
+   if (opal_recover_mce(regs, evt))
+   return 1;
+  

Re: Loading kernel on MPC86x

2013-08-26 Thread Scott Wood
On Mon, 2013-08-26 at 20:29 +0200, Martin Hinner wrote:
 On Mon, Aug 26, 2013 at 7:14 PM, Scott Wood scottw...@freescale.com wrote:
  that kernel must be at location 0. Another problem was that interrupts
  got re-enabled during execution of my bootloader (I am doing some
  syscalls - goes  to Cisco rom),
  Do you mean you're calling into the rom after Linux has already started
  executing?  That's not normal for 8xx.
 
 No, in bootloader. I have disabled interrupts and then later did a
 syscall which probably enabled them again. As I have overwritten some
 of Cisco ROM data it crashed (at random place).
 
  I am also curious why CONFIG_PPC_EARLY_DEBUG_CPM uses
  CONFIG_PPC_EARLY_DEBUG_CPM_ADDR as pointer to transmit SMC buffer and
  not address of CPM/SCM parameter RAM ? TX buffer address can be read
  from SMC parameter RAM. Wouldn't this solution be more portable? At
  least this way I do it when I take over console from Cisco
  startup/rommon.
 
  The point was to keep things as simple as possible (e.g. for use in
  temporary handcoded asm as needed).  This is a hacky debugging feature
  that assumes you know what you're doing and can set the address to match
  what the loader does (and that the loader's choice of address is
  static).  If you have an improvement that keeps it simple, feel free to
  send a patch.
 
 How about making CONFIG_PPC_EARLY_DEBUG_CPM_PARRAM

PARAM

 that woud carry address of SMCx parameter RAM (IMMR+0x04180 on MPC866) and 
 this value
 would be used in case CONFIG_PPC_EARLY_DEBUG_CPM_ADDR is zero ? This
 would allow kernel hackers to still use
 CONFIG_PPC_EARLY_DEBUG_CPM_ADDR for assembly debugging (+legacy use)
 and everyone else can use it as a more reliable option that does not
 rely on particular bootloader behavior. Early debug is good even for
 end-users so as they can send debug output if anything goes wrong at
 early stage.

If it only works with CPM1 SMC, then that should be in the name of the
symbol.

 Anyway, difference between _PARRAM and _ADDR is only one lwz
 instruction, so I guess it is possible to completely discard _ADDR if
 there is no legacy use for it. I am also not sure if this works with
 SCC UART ports or only CPM SMC UART.

Given that testing can be a challenge on this old hardware (I don't have
easy access anymore, except maybe one 8xx board), I'd rather leave the
existing mechanism in place if you don't have the ability to test all
these cases.  The ability to not care about what type of CPM serial port
it is, is an important simplification.

-Scott



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


Re: [PATCH] powerpc/hvsi: increase handshake timeout from 200ms to 400ms.

2013-08-26 Thread Benjamin Herrenschmidt
On Mon, 2013-08-26 at 11:53 -0700, Eugene Surovegin wrote:
 This solves a problem observed in kexec'ed kernel where 200ms timeout is
 too short and bootconsole fails to initialize. Console did eventually
 become workable but much later into the boot process.
 
 Observed timeout was around 260ms, but I decided to make it a little bigger
 for more reliability.
 
 This has been tested on Power7 machine with Petitboot as a primary
 bootloader and PowerNV firmware.

Thanks !

I've been carrying a patch like that in my test stuff, the only reason I
hadn't merged it yet was that I though there might be a problem under
the hood, such as us maybe not actually polling the FSP fast enough or
something, but so far it looks like it's just slow to respond.

Cheers,
Ben.

 Signed-off-by: Eugene Surovegin surove...@google.com
 ---
  drivers/tty/hvc/hvsi_lib.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/tty/hvc/hvsi_lib.c b/drivers/tty/hvc/hvsi_lib.c
 index 3396eb9..ac27671 100644
 --- a/drivers/tty/hvc/hvsi_lib.c
 +++ b/drivers/tty/hvc/hvsi_lib.c
 @@ -341,8 +341,8 @@ void hvsilib_establish(struct hvsi_priv *pv)
  
   pr_devel(HVSI@%x:   ... waiting handshake\n, pv-termno);
  
 - /* Try for up to 200s */
 - for (timeout = 0; timeout  20; timeout++) {
 + /* Try for up to 400ms */
 + for (timeout = 0; timeout  40; timeout++) {
   if (pv-established)
   goto established;
   if (!hvsi_get_packet(pv))


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


Re: [alsa-devel] [PATCH v11] ASoC: fsl: Add S/PDIF machine driver

2013-08-26 Thread Nicolin Chen
On Fri, Aug 23, 2013 at 08:13:53PM +0100, Mark Brown wrote:
 On Fri, Aug 23, 2013 at 01:08:28PM -0600, Stephen Warren wrote:
  On 08/23/2013 02:04 AM, Nicolin Chen wrote:
   This patch implements a device-tree-only machine driver for Freescale
   i.MX series Soc. It works with spdif_transmitter/spdif_receiver and
   fsl_spdif.c drivers.
 
  The binding looks reasonable to me now. Thanks.
 
 Is that a Reviewed-by?

Sir,
I think this patch hasn't been applied yet, already been acked though.
Is there any problem in it?

Thank you.
Nicolin


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


RE: [v3] powerpc/mpc85xx: Update the clock device tree nodes

2013-08-26 Thread Tang Yuantian-B29983
+   };
+   pll1: pll1@820 {
+   #clock-cells = 1;
+   reg = 0x820;
+   compatible = fsl,core-pll-clock;
+   clocks = clockgen;
+   clock-output-names = pll1, pll1-div2, pll1-
 div4;
+   };
  
   Please leave a blank line between properties and nodes, and between
 nodes.
  
  OK, will add.
 
   What does reg represent?  Where is the binding for this?
  
   The compatible is too vague.
  Reg is register offset.
 
 With no size?

No size is needed.

 
  I should have had a binding document.
  About the compatible, you should pointed it out earlier in SDK review.
 
 Sorry, it doesn't work that way.  I don't know why I didn't notice this
 stuff there -- the SDK review was probably rushed, with someone shouting
 urgent.  The SDK does not dictate what goes upstream.  Device tree
 bindings should go upstream first.
 
When I sent the patch v1, there is a binding document with it. But I missed
It in the patch v3, so when patch v3 got merged, the binding document didn't 
get merged.
I will make the binding go upstream first next time.

  It is too later to change since the clock driver is merged for months
  although I sent this patch first.
 
 It should not have gone in without an approved binding.  It seems it went
 in via Mike Turquette (why is a non-ARM-specific tree using linux-arm-
 kernel as its list, BTW?).  No ack from Ben, Kumar, or me is shown in the
 commit.
The Linux common clock framework is not ARM specific. Any other arch can use it.
In fact, this clock driver is the first one that use common clk on PPC arch.
I will get the ack from you guys next time. I hope it doesn't make me wait too 
long.
 
 
 In any case, you can preserve compatibility with existing trees without
 using this compatible in new trees.  The driver can check for both
 compatibles, with a comment indicating that fsl,core-mux-clock is
 deprecated and for compatibility only.
It is sub-clock node, is it really necessary to think about compatibility?
I think that's the node clockgen's responsibility.

 
  Besides, it is not too bad because other arch use the similar name.
 
 I don't follow.  This is a specific Freescale register interface, not a
 general concept.
 
 In any case, which similar names are you referring to?  A search in
 arch/arm/boot/dts for mux with clk or clock turns up
 allwinner,sun4i-apb1-mux-clk which is much more specific than
 fsl,core-mux-clock.
Ok, I will change the compatible string.
Do you think fsl,ppc-core-* is ok?

Regards,
Yuantian
 
 -Scott
 

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


linux-next: manual merge of the pm tree with the powerpc tree

2013-08-26 Thread Stephen Rothwell
Hi Rafael,

Today's linux-next merge of the pm tree got a conflict in
arch/powerpc/kernel/prom.c between commit dc0e643afc50 (powerpc: Make
prom.c device tree accesses endian safe) from the powerpc tree and
commits 819d596568d8 (powerpc: refactor of_get_cpu_node to support other
architectures) and 183912d352a2 (of: move of_get_cpu_node
implementation to DT core library) from the pm tree.

I think that the latter superceded the conflicting fixes in the former,
so I just used the latter and can carry the fix as necessary (no action
is required).

P.S. Rafael, I used both your addresses because I have had a bounce from
the sisk.pl one in the past ...
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


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

Re: [PATCH v2 2/2] Register bootmem pages

2013-08-26 Thread Benjamin Herrenschmidt
On Mon, 2013-08-19 at 21:53 -0500, Nathan Fontenot wrote:
 Previous commit 46723bfa540... introduced a new config option
 HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for ppc
 when sparse vmemmap is not defined.
 
 This patch defines HAVE_BOOTMEM_INFO_NODE for ppc and adds the call to
 register_page_bootmem_info_node. Without this we get a BUG_ON for memory
 hot remove in put_page_bootmem().
 
 This also adds a stub for register_page_bootmem_memmap to allow ppc to build
 with sparse vmemmap defined.
 
 Signed-off-by: Nathan Fontenot nf...@linux.vnet.ibm.com
 ---

So I still feel very uncomfortable with that stuff 

For example, x86 calls register_page_bootmem_info_node() at boot time,
which does that strange get_page_bootmem on the NODE_DATA itself at
boot time, we don't. Should we ?

Since we don't, what do that mean ? We don't remove the node info pages
on unplug ? Is that ok ?

There's a whole pile of totally undocumented / uncommented generic code
with horrible function names in there whose sematic is very very
unclear.

Now, if we call that thing, are we expected to have
register_paqe_bootmem_memmap() to actually do something right? I assume
that means actually calling get_page_bootmem() on the various struct
page that comprise the vmemmap.

Well, we can probably implement that since we maintain a list of all the
vmemap pages... However, we don't implement vmemmap_free(). Should we ?

This all confuses me...

Cheers,
Ben.

 
 ---
  arch/powerpc/mm/init_64.c |4 
  arch/powerpc/mm/mem.c |9 +
  mm/Kconfig|2 +-
  3 files changed, 14 insertions(+), 1 deletion(-)
 
 Index: linux/arch/powerpc/mm/init_64.c
 ===
 --- linux.orig/arch/powerpc/mm/init_64.c
 +++ linux/arch/powerpc/mm/init_64.c
 @@ -300,5 +300,9 @@ void vmemmap_free(unsigned long start, u
  {
  }
 
 +void register_page_bootmem_memmap(unsigned long section_nr,
 +   struct page *start_page, unsigned long size)
 +{
 +}
  #endif /* CONFIG_SPARSEMEM_VMEMMAP */
 
 Index: linux/arch/powerpc/mm/mem.c
 ===
 --- linux.orig/arch/powerpc/mm/mem.c
 +++ linux/arch/powerpc/mm/mem.c
 @@ -297,12 +297,21 @@ void __init paging_init(void)
  }
  #endif /* ! CONFIG_NEED_MULTIPLE_NODES */
 
 +static void __init register_page_bootmem_info(void)
 +{
 + int i;
 +
 + for_each_online_node(i)
 + register_page_bootmem_info_node(NODE_DATA(i));
 +}
 +
  void __init mem_init(void)
  {
  #ifdef CONFIG_SWIOTLB
   swiotlb_init(0);
  #endif
 
 + register_page_bootmem_info();
   high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
   set_max_mapnr(max_pfn);
   free_all_bootmem();
 Index: linux/mm/Kconfig
 ===
 --- linux.orig/mm/Kconfig
 +++ linux/mm/Kconfig
 @@ -183,7 +183,7 @@ config MEMORY_HOTPLUG_SPARSE
  config MEMORY_HOTREMOVE
   bool Allow for memory hot remove
   select MEMORY_ISOLATION
 - select HAVE_BOOTMEM_INFO_NODE if X86_64
 + select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
   depends on MEMORY_HOTPLUG  ARCH_ENABLE_MEMORY_HOTREMOVE
   depends on MIGRATION
 
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev


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


Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support

2013-08-26 Thread Benjamin Herrenschmidt
On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote:
  Gleb, any chance you can put this (and the next one) into a tree to
  lock in the numbers ?
  
 Applied it. Sorry for slow response, was on vocation and still go
 through the email backlog.

Thanks. Since it's not in a topic branch that I can pull, I'm going to
just cherry-pick them. However, they are in your queue branch, not
next branch. Should I still assume this is a stable branch and that
the numbers aren't going to change ?

Cheers,
Ben.


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


Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support

2013-08-26 Thread Benjamin Herrenschmidt
On Tue, 2013-08-27 at 14:19 +1000, Benjamin Herrenschmidt wrote:
 On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote:
   Gleb, any chance you can put this (and the next one) into a tree to
   lock in the numbers ?
   
  Applied it. Sorry for slow response, was on vocation and still go
  through the email backlog.
 
 Thanks. Since it's not in a topic branch that I can pull, I'm going to
 just cherry-pick them. However, they are in your queue branch, not
 next branch. Should I still assume this is a stable branch and that
 the numbers aren't going to change ?

Oh and Alexey mentions that there are two capabilities and you only
applied one :-)

Cheers,
Ben.


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


Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore

2013-08-26 Thread Aruna Balakrishnaiah

On Friday 23 August 2013 04:47 AM, Luck, Tony wrote:

1[  383.209057] RIP  [813d3946] sysrq_handle_crash+0x16/0x20
4[  383.209057]  RSP 88006f551e80
4[  383.209057] CR2: 
4[  383.209057] ---[ end trace 04a1cddad37b4b33 ]---
3[  383.209057] pstore: compression failed for Part 2 returned -5
3[  383.209057] pstore: Capture uncompressed oops/panic report of Part 2
3[  383.209057] pstore: compression failed for Part 5 returned -5

Interesting.  With ERST backend I didn't see these messages.  Traces in
pstore recovered files go as far as the line before the ---[ end trace 
04a1cddad37b4b33 ]---

Why the difference depending on which back end is in use?

But I agree that we shouldn't have these messages.  They use up space
in the persistent store that could be better used saving some more lines
from earlier in the console log.


Yeah. We can remove these messages as it will add to the space consumed. But it 
would

be good to know why the compression failed with efivars case.

Seiji,

Could you let us know the efivars buffer size with which the pstore is 
registered when

the failure occurred.

Regards,
Aruna




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



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