[PATCH net-next-2.6 1/2] gianfar: Clean up implementation of RX network flow classification

2011-04-08 Thread Ben Hutchings 
This code was cribbed from niu, so gfar_set_hash_opts() begins by
converting the ethtool flow class code into a class code for Sun
Neptune hardware, then does the same thing again for the hardware it's
really dealing with.  It may also return -1 (-EPERM) for some
unhandled ethtool flow class codes.

Remove the useless code and definitions, and fix the error code.

Signed-off-by: Ben Hutchings 
---
This isn't even compile-tested, since it can only be built for some
PowerPC SoCs.  Could someone on ppc-dev check that this won't break the
driver?

Ben.

 drivers/net/gianfar.h |   17 -
 drivers/net/gianfar_ethtool.c |   52 +
 2 files changed, 1 insertions(+), 68 deletions(-)

diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index ec5d595..57ee3b0 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -382,23 +382,6 @@ extern const char gfar_driver_version[];
 #define BD_LFLAG(flags) ((flags) << 16)
 #define BD_LENGTH_MASK 0x
 
-#define CLASS_CODE_UNRECOG 0x00
-#define CLASS_CODE_DUMMY1  0x01
-#define CLASS_CODE_ETHERTYPE1  0x02
-#define CLASS_CODE_ETHERTYPE2  0x03
-#define CLASS_CODE_USER_PROG1  0x04
-#define CLASS_CODE_USER_PROG2  0x05
-#define CLASS_CODE_USER_PROG3  0x06
-#define CLASS_CODE_USER_PROG4  0x07
-#define CLASS_CODE_TCP_IPV40x08
-#define CLASS_CODE_UDP_IPV40x09
-#define CLASS_CODE_AH_ESP_IPV4 0x0a
-#define CLASS_CODE_SCTP_IPV4   0x0b
-#define CLASS_CODE_TCP_IPV60x0c
-#define CLASS_CODE_UDP_IPV60x0d
-#define CLASS_CODE_AH_ESP_IPV6 0x0e
-#define CLASS_CODE_SCTP_IPV6   0x0f
-
 #define FPR_FILER_MASK 0x
 #define MAX_FILER_IDX  0xFF
 
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 3bc8e27..0840590 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -645,42 +645,6 @@ static int gfar_set_wol(struct net_device *dev, struct 
ethtool_wolinfo *wol)
 }
 #endif
 
-static int gfar_ethflow_to_class(int flow_type, u64 *class)
-{
-   switch (flow_type) {
-   case TCP_V4_FLOW:
-   *class = CLASS_CODE_TCP_IPV4;
-   break;
-   case UDP_V4_FLOW:
-   *class = CLASS_CODE_UDP_IPV4;
-   break;
-   case AH_V4_FLOW:
-   case ESP_V4_FLOW:
-   *class = CLASS_CODE_AH_ESP_IPV4;
-   break;
-   case SCTP_V4_FLOW:
-   *class = CLASS_CODE_SCTP_IPV4;
-   break;
-   case TCP_V6_FLOW:
-   *class = CLASS_CODE_TCP_IPV6;
-   break;
-   case UDP_V6_FLOW:
-   *class = CLASS_CODE_UDP_IPV6;
-   break;
-   case AH_V6_FLOW:
-   case ESP_V6_FLOW:
-   *class = CLASS_CODE_AH_ESP_IPV6;
-   break;
-   case SCTP_V6_FLOW:
-   *class = CLASS_CODE_SCTP_IPV6;
-   break;
-   default:
-   return 0;
-   }
-
-   return 1;
-}
-
 static void ethflow_to_filer_rules (struct gfar_private *priv, u64 ethflow)
 {
u32 fcr = 0x0, fpr = FPR_FILER_MASK;
@@ -778,11 +742,6 @@ static int gfar_ethflow_to_filer_table(struct gfar_private 
*priv, u64 ethflow, u
case UDP_V6_FLOW:
cmp_rqfpr = RQFPR_IPV6 |RQFPR_UDP;
break;
-   case IPV4_FLOW:
-   cmp_rqfpr = RQFPR_IPV4;
-   case IPV6_FLOW:
-   cmp_rqfpr = RQFPR_IPV6;
-   break;
default:
printk(KERN_ERR "Right now this class is not supported\n");
return 0;
@@ -848,18 +807,9 @@ static int gfar_ethflow_to_filer_table(struct gfar_private 
*priv, u64 ethflow, u
 
 static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc 
*cmd)
 {
-   u64 class;
-
-   if (!gfar_ethflow_to_class(cmd->flow_type, &class))
-   return -EINVAL;
-
-   if (class < CLASS_CODE_USER_PROG1 ||
-   class > CLASS_CODE_SCTP_IPV6)
-   return -EINVAL;
-
/* write the filer rules here */
if (!gfar_ethflow_to_filer_table(priv, cmd->data, cmd->flow_type))
-   return -1;
+   return -EINVAL;
 
return 0;
 }
-- 
1.7.4



-- 
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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

Re: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX

2011-04-08 Thread Benjamin Herrenschmidt 
On Fri, 2011-04-08 at 13:22 -0500, Ayman El-Khashab wrote:
> From: Ayman El-Khashab 
> 
> This patch is to fix the PCIe on the 460SX CPU.  As far as I can tell,
> the 460SX must be using a different core than the previous 4xx SOCs.
> The registers aren't the same and it appears DCRs that existed on 
> previous parts don't exist on this one.  Perhaps somebody from AMCC 
> can chime in.  In any case, the main problem was that the TX and RX
> weren't enabled so nothing downstream from the RP was ever found.
> And the check to set "port->link" would never work (as far as I could
> tell).  I could not find any DCRs in this part to indicate when the
> link was up and there isn't an obvious loopback, so the following
> call would fail and result in no devices found.
> 
> ppc4xx_pciex_wait_on_sdr(port, PESDRn_LOOP, 1 << 28, 1 << 28, 100)
> 
> It would be better to detect the link status, but I don't see an
> obvious way to do that from the data sheet.  U-boot just skips the
> link check as well for this part.

Hi Tirumala !

You originally submitted the support for 460ex. Can you chime in (and
review Ayman patch) please ?

Cheers,
Ben.

> 
> Ayman El-Khashab (1):
>   ppc4xx: Fix PCIe scanning for the 460SX
> 
>  arch/powerpc/sysdev/ppc4xx_pci.c |   35 +++
>  1 files changed, 31 insertions(+), 4 deletions(-)
> 


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

[PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX

2011-04-08 Thread Ayman El-Khashab 
From: Ayman El-Khashab 

This patch is to fix the PCIe on the 460SX CPU.  As far as I can tell,
the 460SX must be using a different core than the previous 4xx SOCs.
The registers aren't the same and it appears DCRs that existed on 
previous parts don't exist on this one.  Perhaps somebody from AMCC 
can chime in.  In any case, the main problem was that the TX and RX
weren't enabled so nothing downstream from the RP was ever found.
And the check to set "port->link" would never work (as far as I could
tell).  I could not find any DCRs in this part to indicate when the
link was up and there isn't an obvious loopback, so the following
call would fail and result in no devices found.

ppc4xx_pciex_wait_on_sdr(port, PESDRn_LOOP, 1 << 28, 1 << 28, 100)

It would be better to detect the link status, but I don't see an
obvious way to do that from the data sheet.  U-boot just skips the
link check as well for this part.


Ayman El-Khashab (1):
  ppc4xx: Fix PCIe scanning for the 460SX

 arch/powerpc/sysdev/ppc4xx_pci.c |   35 +++
 1 files changed, 31 insertions(+), 4 deletions(-)

-- 
1.7.4.3

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

[PATCH 1/1] ppc4xx: Fix PCIe scanning for the 460SX

2011-04-08 Thread Ayman El-Khashab 
From: Ayman El-Khashab 

The 460SX uses a different register set than previous 44x PCIe CPUs,
so some of the checks were not valid.  Added an enable for the TX
and RX.  For the 460SX only: Bypassed VCO check and added PLL check.
Bypassed the link check.  Changed to advertise gen 2 speeds.

Signed-off-by: Ayman El-Khashab 
---
 arch/powerpc/sysdev/ppc4xx_pci.c |   35 +++
 1 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 156aa7d..1c854a7 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1058,6 +1058,8 @@ static int __init ppc460sx_pciex_core_init(struct 
device_node *np)
 
 static int ppc460sx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
 {
+   /* 500ms should be long enough */
+   int timeout = 5;
 
if (port->endpoint)
dcri_clrset(SDR0, port->sdr_base + PESDRn_UTLSET2,
@@ -1066,15 +1068,20 @@ static int ppc460sx_pciex_init_port_hw(struct 
ppc4xx_pciex_port *port)
dcri_clrset(SDR0, port->sdr_base + PESDRn_UTLSET2,
0, 0x0100);
 
-   /*Gen-1*/
-   mtdcri(SDR0, port->sdr_base + PESDRn_460SX_RCEI, 0x0800);
 
dcri_clrset(SDR0, port->sdr_base + PESDRn_RCSSET,
(PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTDL),
PESDRx_RCSSET_RSTPYN);
 
-   port->has_ibpre = 1;
 
+   /* Poll for the PHY reset */
+   while (timeout-- && !(mfdcr(port->sdr_base + PESDRn_RCSSTS) & 0x1))
+   udelay(10);
+
+   if (!timeout)
+   return -1;
+
+   port->has_ibpre = 1;
return 0;
 }
 
@@ -1082,6 +1089,8 @@ static int ppc460sx_pciex_init_utl(struct 
ppc4xx_pciex_port *port)
 {
/* Max 128 Bytes */
out_be32 (port->utl_base + PEUTL_PBBSZ,   0x);
+   out_be32 (port->utl_base + PEUTL_PCTL,0x8080);
+
return 0;
 }
 
@@ -1308,6 +1317,7 @@ static int __init ppc4xx_pciex_port_init(struct 
ppc4xx_pciex_port *port)
 * config space accesses. That way, it will be easier to implement
 * hotplug later on.
 */
+#ifndef CONFIG_460SX
if (!port->has_ibpre ||
!ppc4xx_pciex_wait_on_sdr(port, PESDRn_LOOP,
  1 << 28, 1 << 28, 100)) {
@@ -1325,6 +1335,10 @@ static int __init ppc4xx_pciex_port_init(struct 
ppc4xx_pciex_port *port)
}
} else
printk(KERN_INFO "PCIE%d: No device detected.\n", port->index);
+#else
+   /* XXX What DCR has the link status on the 460SX? */
+   port->link = 1;
+#endif
 
/*
 * Initialize mapping: disable all regions and configure
@@ -1344,8 +1358,9 @@ static int __init ppc4xx_pciex_port_init(struct 
ppc4xx_pciex_port *port)
if (ppc4xx_pciex_hwops->setup_utl)
ppc4xx_pciex_hwops->setup_utl(port);
 
+#ifndef CONFIG_460SX
/*
-* Check for VC0 active and assert RDY.
+* Check for VC0 active
 */
if (port->link &&
ppc4xx_pciex_wait_on_sdr(port, PESDRn_RCSSTS,
@@ -1353,7 +1368,19 @@ static int __init ppc4xx_pciex_port_init(struct 
ppc4xx_pciex_port *port)
printk(KERN_INFO "PCIE%d: VC0 not active\n", port->index);
port->link = 0;
}
+#else
+   /*
+* Check for PLL Locked
+*/
+   if (port->link &&
+   ppc4xx_pciex_wait_on_sdr(port, PESDRn_RCSSTS,
+1 << 12, 1 << 12, 5000)) {
+   printk(KERN_INFO "PCIE%d: PLL not locked\n", port->index);
+   port->link = 0;
+   }
+#endif
 
+   /* Assert RDY */
dcri_clrset(SDR0, port->sdr_base + PESDRn_RCSSET, 0, 1 << 20);
msleep(100);
 
-- 
1.7.4.3

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

Re: platform_driver/of_platform_driver compile warning in fsldma.c

2011-04-08 Thread Grant Likely 
On Fri, Apr 8, 2011 at 8:32 AM, Ira W. Snyder  wrote:
> On Fri, Apr 08, 2011 at 04:12:13AM -0500, Kumar Gala wrote:
>> Grant,
>>
>> I'm being lazy, can you give any quick insight on the following compile 
>> warning:
>>
>> drivers/dma/fsldma.c:1457:2: warning: initialization from incompatible 
>> pointer type
>> drivers/dma/fsldma.c: In function 'fsldma_init':
>> drivers/dma/fsldma.c:1468:2: warning: passing argument 1 of 
>> 'platform_driver_register' from incompatible pointer type
>> include/linux/platform_device.h:124:12: note: expected 'struct 
>> platform_driver *' but argument is of type 'struct of_platform_driver *'
>> drivers/dma/fsldma.c: In function 'fsldma_exit':
>> drivers/dma/fsldma.c:1473:2: warning: passing argument 1 of 
>> 'platform_driver_unregister' from incompatible pointer type
>> include/linux/platform_device.h:125:13: note: expected 'struct 
>> platform_driver *' but argument is of type 'struct of_platform_driver *'
>>
>
> The "struct of_platform_driver" needs to be changed to a
> "struct platform_driver". Just remove the "of_" prefix, the structure
> initialization is correct. I sent a patch for this yesterday to LKML. The
> title is: fsldma: fix build warning caused by of_platform_device changes

Yes, thanks Ira.  I'm picking up that patch today and I'll send it off to Linus.

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

Re: platform_driver/of_platform_driver compile warning in fsldma.c

2011-04-08 Thread Ira W. Snyder 
On Fri, Apr 08, 2011 at 04:12:13AM -0500, Kumar Gala wrote:
> Grant,
> 
> I'm being lazy, can you give any quick insight on the following compile 
> warning:
> 
> drivers/dma/fsldma.c:1457:2: warning: initialization from incompatible 
> pointer type
> drivers/dma/fsldma.c: In function 'fsldma_init':
> drivers/dma/fsldma.c:1468:2: warning: passing argument 1 of 
> 'platform_driver_register' from incompatible pointer type
> include/linux/platform_device.h:124:12: note: expected 'struct 
> platform_driver *' but argument is of type 'struct of_platform_driver *'
> drivers/dma/fsldma.c: In function 'fsldma_exit':
> drivers/dma/fsldma.c:1473:2: warning: passing argument 1 of 
> 'platform_driver_unregister' from incompatible pointer type
> include/linux/platform_device.h:125:13: note: expected 'struct 
> platform_driver *' but argument is of type 'struct of_platform_driver *'
> 

The "struct of_platform_driver" needs to be changed to a
"struct platform_driver". Just remove the "of_" prefix, the structure
initialization is correct. I sent a patch for this yesterday to LKML. The
title is: fsldma: fix build warning caused by of_platform_device changes

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

[PATCH] net: Remove invalid offloads

2011-04-08 Thread Michał Mirosław 
Remove offload changing ethtool ops which drivers don't really support:

 - fs_enet
 - ucc_geth

Signed-off-by: Michał Mirosław 
---
 drivers/net/fs_enet/fs_enet-main.c |2 --
 drivers/net/ucc_geth_ethtool.c |1 -
 2 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/net/fs_enet/fs_enet-main.c 
b/drivers/net/fs_enet/fs_enet-main.c
index 24cb953..a938894 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -956,8 +956,6 @@ static const struct ethtool_ops fs_ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_msglevel = fs_get_msglevel,
.set_msglevel = fs_set_msglevel,
-   .set_tx_csum = ethtool_op_set_tx_csum,  /* local! */
-   .set_sg = ethtool_op_set_sg,
.get_regs = fs_get_regs,
 };
 
diff --git a/drivers/net/ucc_geth_ethtool.c b/drivers/net/ucc_geth_ethtool.c
index 6f92e48..537fbc0 100644
--- a/drivers/net/ucc_geth_ethtool.c
+++ b/drivers/net/ucc_geth_ethtool.c
@@ -410,7 +410,6 @@ static const struct ethtool_ops uec_ethtool_ops = {
.set_ringparam  = uec_set_ringparam,
.get_pauseparam = uec_get_pauseparam,
.set_pauseparam = uec_set_pauseparam,
-   .set_sg = ethtool_op_set_sg,
.get_sset_count = uec_get_sset_count,
.get_strings= uec_get_strings,
.get_ethtool_stats  = uec_get_ethtool_stats,
-- 
1.7.2.5

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

Re: Using dmaengine on Freescale P2020 RDB

2011-04-08 Thread Timur Tabi 
On Wed, Apr 6, 2011 at 2:40 PM, Chuck Ketcham  wrote:

> Three of the channels were not used because they were already publicly 
> allocated.  One channel was
> not used because it didn't have DMA_MEMCPY capability.

That's strange, because all four DMA channels are identical.

> 2. If dmaengine is correct, what can I do to free up a channel for my own use?

There must be something else in your system using up the channels.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/1] powerpc/eeh: Add support for ibm,configure-pe RTAS call

2011-04-08 Thread Richard A Lary 

On 4/6/2011 8:35 PM, Benjamin Herrenschmidt wrote:

On Wed, 2011-04-06 at 15:50 -0700, Richard A Lary wrote:

From: Richard A. Lary

Added support for ibm,configure-pe RTAS call introduced with
PAPR 2.2.


Care to tell us a bit about the difference ? :-) There's nothing obvious
in the code Also you added calls to rtas_configure_bridge() and
eeh_restore_bars() to eeh_slot_error_Detail(), that might want some
explanation as well.


I was directed by Platform Firmware team to use the new configure-pe call
on platforms which support it.  Other than that, all I can tell you is
what PAPR+ 2.5 has to say:

---
Section 7.3.12.2 ibm,configure-pe
This call has about the same semantics as the ibm,configure-bridge RTAS
call, except that it:
1. Has the additional semantics of bypassing the configuration process
   if the PE has previously not been reset by the platform as a result
   of entering the EEH Stopped State.
2. Configures all the configurations spaces within the PE, including those
   of the endpoint devices within the PE (see Requirement R1–7.3.12.2–3).

Thus, this RTAS call can be made at the beginning of any EEH processing.

---

The addition of calls to rtas_configure_bridge() and eeh_restore_bars()
were also added as directed by Platform Firmware team.
Platform Firmware advised these calls were required to allow access to
all devices under the Partitionable Endpoint by gather_pci_data()
on PCIe adapters which contain PCIe Switches/Bridges.

I have verified in testing that the addition of rtas_configure_bridge()
and eeh_restore_bars() do indeed allow gather_pci_data() to read config
space on every device under the PE, which returned all FF's prior
to addition of those calls.


Cheers,
Ben.


Signed-off-by: Richard A. Lary
---
   arch/powerpc/platforms/pseries/eeh.c |   13  12 +1 - 0 !
   1 file changed, 12 insertions(+), 1 deletion(-)

Index: b/arch/powerpc/platforms/pseries/eeh.c
===
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -95,6 +95,7 @@ static int ibm_slot_error_detail;
   static int ibm_get_config_addr_info;
   static int ibm_get_config_addr_info2;
   static int ibm_configure_bridge;
+static int ibm_configure_pe;

   int eeh_subsystem_enabled;
   EXPORT_SYMBOL(eeh_subsystem_enabled);
@@ -263,6 +264,8 @@ void eeh_slot_error_detail(struct pci_dn
pci_regs_buf[0] = 0;

rtas_pci_enable(pdn, EEH_THAW_MMIO);
+   rtas_configure_bridge(pdn);
+   eeh_restore_bars(pdn);
loglen = gather_pci_data(pdn, pci_regs_buf, EEH_PCI_REGS_LOG_LEN);

rtas_slot_error_detail(pdn, severity, pci_regs_buf, loglen);
@@ -896,6 +899,7 @@ void
   rtas_configure_bridge(struct pci_dn *pdn)
   {
int config_addr;
+   int token;
int rc;

/* Use PE configuration address, if present */
@@ -903,7 +907,13 @@ rtas_configure_bridge(struct pci_dn *pdn
if (pdn->eeh_pe_config_addr)
config_addr = pdn->eeh_pe_config_addr;

-   rc = rtas_call(ibm_configure_bridge,3,1, NULL,
+   /* Use new configure-pe function, if supported */
+   if (ibm_configure_pe != RTAS_UNKNOWN_SERVICE)
+   token = ibm_configure_pe;
+   else
+   token = ibm_configure_bridge;
+
+   rc = rtas_call(token, 3, 1, NULL,
   config_addr,
   BUID_HI(pdn->phb->buid),
   BUID_LO(pdn->phb->buid));
@@ -1079,6 +1089,7 @@ void __init eeh_init(void)
ibm_get_config_addr_info = rtas_token("ibm,get-config-addr-info");
ibm_get_config_addr_info2 = rtas_token("ibm,get-config-addr-info2");
ibm_configure_bridge = rtas_token ("ibm,configure-bridge");
+   ibm_configure_pe = rtas_token("ibm,configure-pe");

if (ibm_set_eeh_option == RTAS_UNKNOWN_SERVICE)
return;

___
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: Where is CONFIG_BOOT_LOAD ?

2011-04-08 Thread Guillaume Dargaud 
> Isn't that blackfin specific?

So how do you change the loading address of the PowerPC kernel from its default 
0x40 address ?
-- 
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/85xx: P2020 DTS: re-organize dts files

2011-04-08 Thread Prabhakar Kushwaha 
Creates P2020si.dtsi, containing information for P2020 SoC. Modifies dts files
for P2020 based systems to use dtsi file.

Signed-off-by: Prabhakar Kushwaha 
---
 Based upon 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch 
master)

 Please see mpc5200b.dtsi for reference.
 
 Tested on P2020RDB and P2020DS

 arch/powerpc/boot/dts/p2020ds.dts |  374 ++--
 arch/powerpc/boot/dts/p2020rdb.dts|  362 ++-
 arch/powerpc/boot/dts/p2020rdb_camp_core0.dts |  237 +++-
 arch/powerpc/boot/dts/p2020rdb_camp_core1.dts |  142 ++
 arch/powerpc/boot/dts/p2020si.dtsi|  382 +
 5 files changed, 564 insertions(+), 933 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p2020si.dtsi

diff --git a/arch/powerpc/boot/dts/p2020ds.dts 
b/arch/powerpc/boot/dts/p2020ds.dts
index 1101914..2bcf368 100644
--- a/arch/powerpc/boot/dts/p2020ds.dts
+++ b/arch/powerpc/boot/dts/p2020ds.dts
@@ -1,7 +1,7 @@
 /*
  * P2020 DS Device Tree Source
  *
- * Copyright 2009 Freescale Semiconductor Inc.
+ * Copyright 2009-2011 Freescale Semiconductor Inc.
  *
  * 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
@@ -9,12 +9,11 @@
  * option) any later version.
  */
 
-/dts-v1/;
+/include/ "p2020si.dtsi"
+
 / {
-   model = "fsl,P2020";
+   model = "fsl,P2020DS";
compatible = "fsl,P2020DS";
-   #address-cells = <2>;
-   #size-cells = <2>;
 
aliases {
ethernet0 = &enet0;
@@ -27,35 +26,13 @@
pci2 = &pci2;
};
 
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   PowerPC,P2020@0 {
-   device_type = "cpu";
-   reg = <0x0>;
-   next-level-cache = <&L2>;
-   };
-
-   PowerPC,P2020@1 {
-   device_type = "cpu";
-   reg = <0x1>;
-   next-level-cache = <&L2>;
-   };
-   };
 
memory {
device_type = "memory";
};
 
localbus@ffe05000 {
-   #address-cells = <2>;
-   #size-cells = <1>;
compatible = "fsl,elbc", "simple-bus";
-   reg = <0 0xffe05000 0 0x1000>;
-   interrupts = <19 2>;
-   interrupt-parent = <&mpic>;
-
ranges = <0x0 0x0 0x0 0xe800 0x0800
  0x1 0x0 0x0 0xe000 0x0800
  0x2 0x0 0x0 0xffa0 0x0004
@@ -158,352 +135,77 @@
};
 
soc@ffe0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
-   device_type = "soc";
-   compatible = "fsl,p2020-immr", "simple-bus";
-   ranges = <0x0 0 0xffe0 0x10>;
-   bus-frequency = <0>;// Filled out by uboot.
-
-   ecm-law@0 {
-   compatible = "fsl,ecm-law";
-   reg = <0x0 0x1000>;
-   fsl,num-laws = <12>;
-   };
-
-   ecm@1000 {
-   compatible = "fsl,p2020-ecm", "fsl,ecm";
-   reg = <0x1000 0x1000>;
-   interrupts = <17 2>;
-   interrupt-parent = <&mpic>;
-   };
-
-   memory-controller@2000 {
-   compatible = "fsl,p2020-memory-controller";
-   reg = <0x2000 0x1000>;
-   interrupt-parent = <&mpic>;
-   interrupts = <18 2>;
-   };
-
-   i2c@3000 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   cell-index = <0>;
-   compatible = "fsl-i2c";
-   reg = <0x3000 0x100>;
-   interrupts = <43 2>;
-   interrupt-parent = <&mpic>;
-   dfsrr;
-   };
-
-   i2c@3100 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   cell-index = <1>;
-   compatible = "fsl-i2c";
-   reg = <0x3100 0x100>;
-   interrupts = <43 2>;
-   interrupt-parent = <&mpic>;
-   dfsrr;
-   };
 
-   serial0: serial@4500 {
-   cell-index = <0>;
-   device_type = "serial";
-   compatible = "ns16550";
-   reg = <0x4500 0x100>;
-   clock-frequency = <0>;
-   interrupts = <42 2>;
-   interrupt-parent = <&mpic>;
-   };
-
-   ser

[PATCH] powerpc: Fix xmon ml/mz commands to work with 64-bit values

2011-04-08 Thread Josh Boyer 
The ml and and mz commands in xmon currently only work on 32-bit values.
This leads to odd issues when trying to use them on a ppc64 machine.  If
one specified 64-bit addresses to mz, it would loop on the same output
indefinitely.  The ml command would fail to find any 64-bit values in a
memory range, even though one could clearly see them present with the d
command.

This adds a small function that mimics GETWORD, but works for 64-bit
values.  The data types involved in these commands are also changed to
'unsigned long' instead of just 'unsigned'.

Signed-off-by: Josh Boyer 

---
 arch/powerpc/xmon/xmon.c |   47 ++-
 1 file changed, 38 insertions(+), 9 deletions(-)

Index: linux-2.6/arch/powerpc/xmon/xmon.c
===
--- linux-2.6.orig/arch/powerpc/xmon/xmon.c
+++ linux-2.6/arch/powerpc/xmon/xmon.c
@@ -2257,14 +2257,40 @@ memdiffs(unsigned char *p1, unsigned cha
printf("Total of %d differences\n", prt);
 }
 
-static unsigned mend;
-static unsigned mask;
+static unsigned long mend;
+static unsigned long mask;
+
+/* This is mimics GETWORD but works for 64-bit values. */
+static inline unsigned long xmon_getval(unsigned char *val)
+{
+   unsigned long word1 = 0, word2 = 0;
+   unsigned long size = sizeof(unsigned long);
+   int i;
+   int bits = 24;
+
+   for (i = 0; i < 4; i++) {
+   word1 += val[i] << bits;
+   bits -= 8;
+   }
+   if (size > 4) {
+   bits = 24;
+   for (i = 4; i < 8; i++) {
+   word2 += val[i] << bits;
+   bits -= 8;
+   }
+   word1 = word1 << 32;
+   word2 = word2 & 0x;
+   word1 = word1 | word2;
+   }
+   return word1;
+}
 
 static void
 memlocate(void)
 {
-   unsigned a, n;
-   unsigned char val[4];
+   unsigned long a, n;
+   unsigned char val[sizeof(unsigned long)];
+   int size = sizeof(unsigned long);
 
last_cmd = "ml";
scanhex((void *)&mdest);
@@ -2280,10 +2306,10 @@ memlocate(void)
}
}
n = 0;
-   for (a = mdest; a < mend; a += 4) {
-   if (mread(a, val, 4) == 4
-   && ((GETWORD(val) ^ mval) & mask) == 0) {
-   printf("%.16x:  %.16x\n", a, GETWORD(val));
+   for (a = mdest; a < mend; a += size) {
+   if (mread(a, val, size) == size
+   && ((xmon_getval(val) ^ mval) & mask) == 0) {
+   printf("%.16lx:  %.16lx\n", a, xmon_getval(val));
if (++n >= 10)
break;
}
@@ -2297,7 +2323,7 @@ static void
 memzcan(void)
 {
unsigned char v;
-   unsigned a;
+   unsigned long a;
int ok, ook;
 
scanhex(&mdest);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Where is CONFIG_BOOT_LOAD ?

2011-04-08 Thread Florian Vögel 

On Fri, 2011-04-08 at 11:28 +0200, Guillaume Dargaud wrote:
> Hello all,
> I don't see this option in the .config and in the menuconfig / Advanced Setup 
> I don't see a [Set the boot link/load 
> address]:
> 
> [*] Prompt for advanced kernel configuration options
> [ ]   Set maximum low memory
> [ ]   Set custom page offset address
> [ ]   Set custom kernel base address
> [ ] Set custom user task size
> [ ] Set custom consistent memory pool size

Isn't that blackfin specific?

linux-next # find -name Kconfig -exec grep -H "BOOT_LOAD" \{\} \;
./arch/blackfin/Kconfig:config BOOT_LOAD

linux-next # find -exec grep -H "CONFIG_BOOT_LOAD" \{\} \;
./arch/blackfin/boot/Makefile:UIMAGE_OPTS-$(CONFIG_RAMKERNEL) += -a
$(CONFIG_BOOT_LOAD)
./arch/blackfin/kernel/vmlinux.lds.S:   . = CONFIG_BOOT_LOAD;
./arch/blackfin/kernel/vmlinux.lds.S:   . = CONFIG_BOOT_LOAD;
./arch/blackfin/kernel/trace.c: } else if (address < CONFIG_BOOT_LOAD) {
./arch/blackfin/kernel/setup.c: _rambase = CONFIG_BOOT_LOAD;
./arch/blackfin/configs/SRV1_defconfig:CONFIG_BOOT_LOAD=0x40
./arch/blackfin/configs/BF527-TLL6527M_defconfig:CONFIG_BOOT_LOAD=0x40
./arch/blackfin/mach-common/arch_checks.c:#if CONFIG_BOOT_LOAD <
FIXED_CODE_END
./arch/blackfin/mach-common/arch_checks.c:#if (CONFIG_BOOT_LOAD & 0x3)
./arch/blackfin/mach-common/arch_checks.c:#if ((0x -
L1_CODE_START + 1) + CONFIG_BOOT_LOAD) > 0x100

-Florian

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

Re: [PATCH] powerpc/book3e: Fix extlb size

2011-04-08 Thread Kumar Gala 

On Apr 8, 2011, at 2:22 AM, Michael Ellerman wrote:

> The calculation of the size for the exception save area of the TLB
> miss handler is wrong, luckily it's too big not too small.
> 
> Rework it to make it a bit clearer, and also correct. We want 3 save
> areas, each EX_TLB_SIZE _bytes_.
> 
> Signed-off-by: Michael Ellerman 
> ---
> arch/powerpc/include/asm/paca.h |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)

Acked-by: Kumar Gala 

- k


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

RE: known working sata_sil24.c setup on powerpc platforms?

2011-04-08 Thread Kushwaha Prabhakar-B32579 
Hi Leon, 
 
 interrupt-map-mask is missing for pcie@ffe0a000 node. Please see my comment 
there... 
pcie@ffe0a000 node deals with mini-PCIe. 

one more thing, can you please tell P1020Si version. It will be there on u-boot 
log.

--Prabhakar

> -Original Message-
> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
> Sent: Friday, April 08, 2011 2:43 PM
> To: Kushwaha Prabhakar-B32579
> Cc: Moffett, Kyle D; linux-...@vger.kernel.org; Tejun Heo; Jeff Garzik;
> Linux PPC; Gupta Maneesh-B18878
> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> 
> Hello Prabhakar,
> 
> On Fri, Apr 8, 2011 at 10:31 AM, Kushwaha Prabhakar-B32579
>  wrote:
> > Hi Leon,
> >
> >
> >> -Original Message-
> >> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
> >> Sent: Friday, April 08, 2011 1:55 PM
> >> To: Kushwaha Prabhakar-B32579
> >> Cc: Moffett, Kyle D; linux-...@vger.kernel.org; Tejun Heo; Jeff
> >> Garzik; Linux PPC; Gupta Maneesh-B18878
> >> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> >>
> >> Hello Prabhakar,
> >>
> >> On Fri, Apr 8, 2011 at 5:44 AM, Kushwaha Prabhakar-B32579
> >>  wrote:
> >> >> -Original Message-
> >> >> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
> >> >> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
> >> >> Sent: Thursday, April 07, 2011 10:23 PM
> >> >> To: Kushwaha Prabhakar-B32579
> >> >> Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun
> >> >> Heo; Jeff Garzik
> >> >> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> >> >>
> >> >> On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
> >> >>  wrote:
> >> >> > Can you please check p2020rdb.dts for IDSEL entries for pci0/1
> node?
> >> >> >
> >> >> > In order to work in legacy mode, IDSEL entries are required.
> >> >> >
> >> >> No, the p1020rdb and p2020rdb do not have the IDSEL entries:
> >> >> What would the correct IDSEL entries be?
> >> >
> >> > For legacy interrupt to work IDSEL values are required.. please
> >> > find
> >> the correct IDSEL values for pci0/1.
> >> >
> >> >        pci0: pcie@ffe09000 {
> >> > ...
> >> > Please try with this.. I am in process of pushing these IDSEL
> >> > values to
> >> upstream.
> >> >
> >>
> >> Do you have these for P1020RDB  as well? I found a P1020RDB board
> >> that has the CE10 errata fixed, so IRQ0 is properly pulled up.
> >>
> >
> >  Same IDSEL values are valid for P1020RDB also.
> >
> I compiled the new device tree binary, the dump is below(*) and booted
> the P1020RDB from that.
> 
> I verified using an oscilloscope that IRQ0 indeed remains high.
> 
> However, no interrupt seems to come in from the sata_sil24 driver, see
> boot log (**).
> 
> (*) dtb dump:
> $ dtc -I dtb -O dts /tftpboot/p1020rdb/uImage.dtb
> 
>   pcie@ffe09000 {
>   compatible = "fsl,mpc8548-pcie";
>   device_type = "pci";
>   #interrupt-cells = <0x1>;
>   #size-cells = <0x2>;
>   #address-cells = <0x3>;
>   reg = <0x0 0xffe09000 0x0 0x1000>;
>   bus-range = <0x0 0xff>;
>   ranges = <0x200 0x0 0xa000 0x0 0xa000 0x0
> 0x2000 0x100 0x0 0x0 0x0 0xffc3 0x0 0x1>;
>   clock-frequency = <0x1fca055>;
>   interrupt-parent = <0x2>;
>   interrupts = <0x10 0x2>;
>   interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
>   interrupt-map = <0x0 0x0 0x0 0x1 0x2 0x4 0x1 0x0 0x0 0x0 0x2
> 0x2 0x5
> 0x1 0x0 0x0 0x0 0x3 0x2 0x6 0x1 0x0 0x0 0x0 0x4 0x2 0x7 0x1>;
> 
>   pcie@0 {
>   reg = <0x0 0x0 0x0 0x0 0x0>;
>   #size-cells = <0x2>;
>   #address-cells = <0x3>;
>   device_type = "pci";
>   ranges = <0x200 0x0 0xa000 0x200 0x0
> 0xa000 0x0 0x2000 0x100 0x0 0x0 0x100 0x0 0x0 0x0
> 0x10>;
>   };
>   };
> 
>   pcie@ffe0a000 {
>   compatible = "fsl,mpc8548-pcie";
>   device_type = "pci";
>   #interrupt-cells = <0x1>;
>   #size-cells = <0x2>;
>   #address-cells = <0x3>;
>   reg = <0x0 0xffe0a000 0x0 0x1000>;
>   bus-range = <0x0 0xff>;
>   ranges = <0x200 0x0 0xc000 0x0 0xc000 0x0
> 0x2000 0x100 0x0 0x0 0x0 0xffc2 0x0 0x1>;
>   clock-frequency = <0x1fca055>;
>   interrupt-parent = <0x2>;
>   interrupts = <0x10 0x2>;

interrupt-map-mask is missing here.. can you please check dts again. 


>   interrupt-map = <0x0 0x0 0x0 0x1 0x2 0x0 0x1 0x0 0x0 0x0 0x2
> 0x2 0x1
> 0x1 0x0 0x0 0x0 0x3 0x2 0x2 0x1 0x0 0x0 0x0 0x4 0x2 0x3 0x1>;
> 
>   pcie@0 {
>   reg = <0x0 0x0 0x0 0x0 0x0>;
>   #size-cells = <0x2>;
>   #address-cells = <0x3>;
>

[PATCH] powerpc/e500mc: Remove CPU_FTR_MAYBE_CAN_NAP/CPU_FTR_MAYBE_CAN_DOZE

2011-04-08 Thread Kumar Gala 
From: Scott Wood 

e500mc does not support the HID0/MSR mechanism that is used by e500_idle
(and there are also issues with waking on certain types of interrupts).

Further, even if napping is never actually enabled, just having
CPU_FTR_CAN_NAP will cause machine_init() to overwrite the board's supplied
ppc_md.power_save().

We drop CPU_FTR_MAYBE_CAN_DOZE becuase we should use 'wait' instead on
e500mc.

Signed-off-by: Scott Wood 
Signed-off-by: Kumar Gala 
---
 arch/powerpc/include/asm/cputable.h |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 6a7c8d9..7e9b831 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -383,8 +383,7 @@ extern const char *powerpc_base_platform;
 #define CPU_FTRS_E500_2(CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | \
CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
-#define CPU_FTRS_E500MC(CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
-   CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
+#define CPU_FTRS_E500MC(CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL)
 #define CPU_FTRS_E5500 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \
-- 
1.7.3.4

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

[PATCH v3] powerpc/book3e: Fix CPU feature handling on 64-bit e5500

2011-04-08 Thread Kumar Gala 
The CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS defines did not encompass
e5500 CPU features when built for 64-bit.  This causes issues with
cpu_has_feature() as it utilizes the POSSIBLE & ALWAYS defines as part
of its check.

Create a unique CPU_FTRS_E5500 (as its different from CPU_FTRS_E500MC),
created a new group for 64-bit Book3e based CPUs and add CPU_FTRS_E5500
to that group.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/include/asm/cputable.h |   13 +
 arch/powerpc/kernel/cputable.c  |2 +-
 2 files changed, 14 insertions(+), 1 deletions(-)

v3 - drop NAP & DOZE support based on feedback from Scott

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index be3cdf9..f1fbf60 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -386,6 +386,9 @@ extern const char *powerpc_base_platform;
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL)
+#define CPU_FTRS_E5500 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \
+   CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
+   CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD)
 #define CPU_FTRS_GENERIC_32(CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
 
 /* 64-bit CPUs */
@@ -435,11 +438,15 @@ extern const char *powerpc_base_platform;
 #define CPU_FTRS_COMPATIBLE(CPU_FTR_USE_TB | CPU_FTR_PPCAS_ARCH_V2)
 
 #ifdef __powerpc64__
+#ifdef CONFIG_PPC_BOOK3E
+#define CPU_FTRS_POSSIBLE  (CPU_FTRS_E5500)
+#else
 #define CPU_FTRS_POSSIBLE  \
(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_FTR_1T_SEGMENT | CPU_FTR_VSX)
+#endif
 #else
 enum {
CPU_FTRS_POSSIBLE =
@@ -473,16 +480,21 @@ enum {
 #endif
 #ifdef CONFIG_E500
CPU_FTRS_E500 | CPU_FTRS_E500_2 | CPU_FTRS_E500MC |
+   CPU_FTRS_E5500 |
 #endif
0,
 };
 #endif /* __powerpc64__ */
 
 #ifdef __powerpc64__
+#ifdef CONFIG_PPC_BOOK3E
+#define CPU_FTRS_ALWAYS(CPU_FTRS_E5500)
+#else
 #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)
+#endif
 #else
 enum {
CPU_FTRS_ALWAYS =
@@ -513,6 +525,7 @@ enum {
 #endif
 #ifdef CONFIG_E500
CPU_FTRS_E500 & CPU_FTRS_E500_2 & CPU_FTRS_E500MC &
+   CPU_FTRS_E5500 &
 #endif
CPU_FTRS_POSSIBLE,
 };
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index c9b68d0..b9602ee 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1973,7 +1973,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_mask   = 0x,
.pvr_value  = 0x8024,
.cpu_name   = "e5500",
-   .cpu_features   = CPU_FTRS_E500MC,
+   .cpu_features   = CPU_FTRS_E5500,
.cpu_user_features  = COMMON_USER_BOOKE,
.mmu_features   = MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS 
|
MMU_FTR_USE_TLBILX,
-- 
1.7.3.4

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

Where is CONFIG_BOOT_LOAD ?

2011-04-08 Thread Guillaume Dargaud 
Hello all,
I don't see this option in the .config and in the menuconfig / Advanced Setup I 
don't see a [Set the boot link/load 
address]:

[*] Prompt for advanced kernel configuration options
[ ]   Set maximum low memory
[ ]   Set custom page offset address
[ ]   Set custom kernel base address
[ ] Set custom user task size
[ ] Set custom consistent memory pool size
 
-- 
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

hotplug support on 85xx smp ?

2011-04-08 Thread Kumar Gala 
Ben,

If looks like SUSPEND support requires CPU hotplug (forces CONFIG_HOTPLUG_CPU). 
 This is causing current 2.6.39-rc2 to break for 85xx-smp.  Are you willing to 
take patches that add cpu hotplug support for 85xx/e500 for 2.6.39 to fix this?

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

Re: [PATCH 2/3] powerpc: Use MSR_64BIT in places

2011-04-08 Thread Kumar Gala 

On Apr 8, 2011, at 2:56 AM, Michael Ellerman wrote:

> Use the new MSR_64BIT in a few places. Some of these are already ifdef'ed
> for BOOKE vs BOOKS, but it's still clearer, MSR_SF does not immediately
> parse as "MSR bit for 64bit".
> 
> Signed-off-by: Michael Ellerman 
> ---
> arch/powerpc/kernel/head_64.S   |2 +-
> arch/powerpc/kernel/signal_64.c |4 ++--
> arch/powerpc/kernel/traps.c |2 +-
> arch/powerpc/xmon/xmon.c|   14 +++---
> 4 files changed, 11 insertions(+), 11 deletions(-)

However MSR_ISF does ;)

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

Re: known working sata_sil24.c setup on powerpc platforms?

2011-04-08 Thread Leon Woestenberg 
Hello Prabhakar,

On Fri, Apr 8, 2011 at 10:31 AM, Kushwaha Prabhakar-B32579
 wrote:
> Hi Leon,
>
>
>> -Original Message-
>> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
>> Sent: Friday, April 08, 2011 1:55 PM
>> To: Kushwaha Prabhakar-B32579
>> Cc: Moffett, Kyle D; linux-...@vger.kernel.org; Tejun Heo; Jeff Garzik;
>> Linux PPC; Gupta Maneesh-B18878
>> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
>>
>> Hello Prabhakar,
>>
>> On Fri, Apr 8, 2011 at 5:44 AM, Kushwaha Prabhakar-B32579
>>  wrote:
>> >> -Original Message-
>> >> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
>> >> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
>> >> Sent: Thursday, April 07, 2011 10:23 PM
>> >> To: Kushwaha Prabhakar-B32579
>> >> Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo;
>> >> Jeff Garzik
>> >> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
>> >>
>> >> On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
>> >>  wrote:
>> >> > Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
>> >> >
>> >> > In order to work in legacy mode, IDSEL entries are required.
>> >> >
>> >> No, the p1020rdb and p2020rdb do not have the IDSEL entries:
>> >> What would the correct IDSEL entries be?
>> >
>> > For legacy interrupt to work IDSEL values are required.. please find
>> the correct IDSEL values for pci0/1.
>> >
>> >        pci0: pcie@ffe09000 {
>> > ...
>> > Please try with this.. I am in process of pushing these IDSEL values to
>> upstream.
>> >
>>
>> Do you have these for P1020RDB  as well? I found a P1020RDB board that
>> has the CE10 errata fixed, so IRQ0 is properly pulled up.
>>
>
>  Same IDSEL values are valid for P1020RDB also.
>
I compiled the new device tree binary, the dump is below(*) and booted
the P1020RDB from that.

I verified using an oscilloscope that IRQ0 indeed remains high.

However, no interrupt seems to come in from the sata_sil24 driver, see
boot log (**).

(*) dtb dump:
$ dtc -I dtb -O dts /tftpboot/p1020rdb/uImage.dtb

pcie@ffe09000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <0x1>;
#size-cells = <0x2>;
#address-cells = <0x3>;
reg = <0x0 0xffe09000 0x0 0x1000>;
bus-range = <0x0 0xff>;
ranges = <0x200 0x0 0xa000 0x0 0xa000 0x0 0x2000
0x100 0x0 0x0 0x0 0xffc3 0x0 0x1>;
clock-frequency = <0x1fca055>;
interrupt-parent = <0x2>;
interrupts = <0x10 0x2>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 0x2 0x4 0x1 0x0 0x0 0x0 0x2 
0x2 0x5
0x1 0x0 0x0 0x0 0x3 0x2 0x6 0x1 0x0 0x0 0x0 0x4 0x2 0x7 0x1>;

pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <0x2>;
#address-cells = <0x3>;
device_type = "pci";
ranges = <0x200 0x0 0xa000 0x200 0x0 
0xa000 0x0
0x2000 0x100 0x0 0x0 0x100 0x0 0x0 0x0 0x10>;
};
};

pcie@ffe0a000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <0x1>;
#size-cells = <0x2>;
#address-cells = <0x3>;
reg = <0x0 0xffe0a000 0x0 0x1000>;
bus-range = <0x0 0xff>;
ranges = <0x200 0x0 0xc000 0x0 0xc000 0x0 0x2000
0x100 0x0 0x0 0x0 0xffc2 0x0 0x1>;
clock-frequency = <0x1fca055>;
interrupt-parent = <0x2>;
interrupts = <0x10 0x2>;
interrupt-map = <0x0 0x0 0x0 0x1 0x2 0x0 0x1 0x0 0x0 0x0 0x2 
0x2 0x1
0x1 0x0 0x0 0x0 0x3 0x2 0x2 0x1 0x0 0x0 0x0 0x4 0x2 0x3 0x1>;

pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <0x2>;
#address-cells = <0x3>;
device_type = "pci";
ranges = <0x200 0x0 0xc000 0x200 0x0 
0xc000 0x0
0x2000 0x100 0x0 0x0 0x100 0x0 0x0 0x0 0x10>;
};
};
};

(**) boot log

[0.00] Using P1020 RDB machine description
[0.00] Memory CAM mapping: 256/256 Mb, residual: 0Mb
[0.00] Linux version 2.6.38 (leon@lunar) (gcc version 4.3.3
(GCC) ) #6 Fri Apr 8 11:00:10 CEST 2011
[0.00] Found legacy serial port 0 for /soc@ffe0/serial@4500
[0.00]   mem=ffe04500, taddr=ffe04500, irq=0, clk=39996, speed=0
[0.00] Found legacy serial port 1 for /soc@ffe0/serial@4600
[0.00]   mem=ffe04600, taddr=ffe04600, irq=0, clk=39996, speed=0
[0.00] bootconsole [udbg0] enabled
[0.00] Found FSL PCI hos

platform_driver/of_platform_driver compile warning in fsldma.c

2011-04-08 Thread Kumar Gala 
Grant,

I'm being lazy, can you give any quick insight on the following compile warning:

drivers/dma/fsldma.c:1457:2: warning: initialization from incompatible pointer 
type
drivers/dma/fsldma.c: In function 'fsldma_init':
drivers/dma/fsldma.c:1468:2: warning: passing argument 1 of 
'platform_driver_register' from incompatible pointer type
include/linux/platform_device.h:124:12: note: expected 'struct platform_driver 
*' but argument is of type 'struct of_platform_driver *'
drivers/dma/fsldma.c: In function 'fsldma_exit':
drivers/dma/fsldma.c:1473:2: warning: passing argument 1 of 
'platform_driver_unregister' from incompatible pointer type
include/linux/platform_device.h:125:13: note: expected 'struct platform_driver 
*' but argument is of type 'struct of_platform_driver *'

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

Re: [PATCH] mm: Check we have the right vma in __access_remote_vm()

2011-04-08 Thread KOSAKI Motohiro 
> In __access_remote_vm() we need to check that we have found the right
> vma, not the following vma, before we try to access it. Otherwise we
> might call the vma's access routine with an address which does not
> fall inside the vma.
> 
> Signed-off-by: Michael Ellerman 
> ---
>  mm/memory.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index 9da8cab..ce999ca 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3678,7 +3678,7 @@ static int __access_remote_vm(struct task_struct *tsk, 
> struct mm_struct *mm,
>*/
>  #ifdef CONFIG_HAVE_IOREMAP_PROT
>   vma = find_vma(mm, addr);
> - if (!vma)
> + if (!vma || vma->vm_start > addr)
>   break;
>   if (vma->vm_ops && vma->vm_ops->access)
>   ret = vma->vm_ops->access(vma, addr, buf,

Looks good to me.
Reviewed-by: KOSAKI Motohiro 



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

RE: [PATCH V3] POWER: perf_event: Skip updating kernel counters ifregister value shrinks

2011-04-08 Thread David Laight 
 
> + u64 delta = 0;
...
> + if (((prev & 0x8000) && !(val & 0x8000)) || (val >
prev))
> + delta = (val - prev) & 0xul;
> +
> + return delta;

The above is incorrect modulo arithmetic.

It is probably intended to do:
s32 delta = val - prev;
return delta < 0 ? 0 : delta;
which will just ignore the fact that some counts are rolled back.

More accurate would be:
static u64 val64;
u32 val = read_perf_count();
s32 delta = val - val_64;
if (delta < 0)
return;
val64 += delta;
Which will not double count for rolled back events.
(The low bits of val64 should always match the actual counter.)

David


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

RE: known working sata_sil24.c setup on powerpc platforms?

2011-04-08 Thread Kushwaha Prabhakar-B32579 
Hi Leon,


> -Original Message-
> From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
> Sent: Friday, April 08, 2011 1:55 PM
> To: Kushwaha Prabhakar-B32579
> Cc: Moffett, Kyle D; linux-...@vger.kernel.org; Tejun Heo; Jeff Garzik;
> Linux PPC; Gupta Maneesh-B18878
> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> 
> Hello Prabhakar,
> 
> On Fri, Apr 8, 2011 at 5:44 AM, Kushwaha Prabhakar-B32579
>  wrote:
> >> -Original Message-
> >> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
> >> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
> >> Sent: Thursday, April 07, 2011 10:23 PM
> >> To: Kushwaha Prabhakar-B32579
> >> Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo;
> >> Jeff Garzik
> >> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> >>
> >> On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
> >>  wrote:
> >> > Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
> >> >
> >> > In order to work in legacy mode, IDSEL entries are required.
> >> >
> >> No, the p1020rdb and p2020rdb do not have the IDSEL entries:
> >> What would the correct IDSEL entries be?
> >
> > For legacy interrupt to work IDSEL values are required.. please find
> the correct IDSEL values for pci0/1.
> >
> >        pci0: pcie@ffe09000 {
> > ...
> > Please try with this.. I am in process of pushing these IDSEL values to
> upstream.
> >
> 
> Do you have these for P1020RDB  as well? I found a P1020RDB board that
> has the CE10 errata fixed, so IRQ0 is properly pulled up.
> 

  Same IDSEL values are valid for P1020RDB also.

--Prabhakar


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

Re: known working sata_sil24.c setup on powerpc platforms?

2011-04-08 Thread Leon Woestenberg 
Hello Prabhakar,

On Fri, Apr 8, 2011 at 5:44 AM, Kushwaha Prabhakar-B32579
 wrote:
>> -Original Message-
>> From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
>> ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
>> Sent: Thursday, April 07, 2011 10:23 PM
>> To: Kushwaha Prabhakar-B32579
>> Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo;
>> Jeff Garzik
>> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
>>
>> On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
>>  wrote:
>> > Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
>> >
>> > In order to work in legacy mode, IDSEL entries are required.
>> >
>> No, the p1020rdb and p2020rdb do not have the IDSEL entries:
>> What would the correct IDSEL entries be?
>
> For legacy interrupt to work IDSEL values are required.. please find the 
> correct IDSEL values for pci0/1.
>
>        pci0: pcie@ffe09000 {
> ...
> Please try with this.. I am in process of pushing these IDSEL values to 
> upstream.
>

Do you have these for P1020RDB  as well? I found a P1020RDB board that
has the CE10 errata fixed, so IRQ0 is properly pulled up.


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

[PATCH 3/3] powerpc: Use MSR_64BIT in sstep.c, fix kprobes on BOOK3E

2011-04-08 Thread Michael Ellerman 
We check MSR_SF a lot in sstep.c, to decide if we need to emulate the
truncation of values when running in 32-bit mode. Factor out that code
into a helper, and convert it and the other uses to use MSR_64BIT.

This fixes a bug on BOOK3E where kprobes would end up returning to a
32-bit address, because regs->nip was truncated, because (msr & MSR_SF)
was false.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/lib/sstep.c |   61 -
 1 files changed, 27 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index ae5189a..0e5e540 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -45,6 +45,18 @@ extern int do_stxvd2x(int rn, unsigned long ea);
 #endif
 
 /*
+ * Emulate the truncation of 64 bit values in 32-bit mode.
+ */
+static unsigned long truncate_if_32bit(unsigned long msr, unsigned long val)
+{
+#ifdef __powerpc64__
+   if ((msr & MSR_64BIT) == 0)
+   val &= 0xUL;
+#endif
+   return val;
+}
+
+/*
  * Determine whether a conditional branch instruction would branch.
  */
 static int __kprobes branch_taken(unsigned int instr, struct pt_regs *regs)
@@ -90,11 +102,8 @@ static unsigned long __kprobes dform_ea(unsigned int instr, 
struct pt_regs *regs
if (instr & 0x0400) /* update forms */
regs->gpr[ra] = ea;
}
-#ifdef __powerpc64__
-   if (!(regs->msr & MSR_SF))
-   ea &= 0xUL;
-#endif
-   return ea;
+
+   return truncate_if_32bit(regs->msr, ea);
 }
 
 #ifdef __powerpc64__
@@ -113,9 +122,8 @@ static unsigned long __kprobes dsform_ea(unsigned int 
instr, struct pt_regs *reg
if ((instr & 3) == 1)   /* update forms */
regs->gpr[ra] = ea;
}
-   if (!(regs->msr & MSR_SF))
-   ea &= 0xUL;
-   return ea;
+
+   return truncate_if_32bit(regs->msr, ea);
 }
 #endif /* __powerpc64 */
 
@@ -136,11 +144,8 @@ static unsigned long __kprobes xform_ea(unsigned int 
instr, struct pt_regs *regs
if (do_update)  /* update forms */
regs->gpr[ra] = ea;
}
-#ifdef __powerpc64__
-   if (!(regs->msr & MSR_SF))
-   ea &= 0xUL;
-#endif
-   return ea;
+
+   return truncate_if_32bit(regs->msr, ea);
 }
 
 /*
@@ -466,7 +471,7 @@ static void __kprobes set_cr0(struct pt_regs *regs, int rd)
 
regs->ccr = (regs->ccr & 0x0fff) | ((regs->xer >> 3) & 0x1000);
 #ifdef __powerpc64__
-   if (!(regs->msr & MSR_SF))
+   if (!(regs->msr & MSR_64BIT))
val = (int) val;
 #endif
if (val < 0)
@@ -487,7 +492,7 @@ static void __kprobes add_with_carry(struct pt_regs *regs, 
int rd,
++val;
regs->gpr[rd] = val;
 #ifdef __powerpc64__
-   if (!(regs->msr & MSR_SF)) {
+   if (!(regs->msr & MSR_64BIT)) {
val = (unsigned int) val;
val1 = (unsigned int) val1;
}
@@ -570,8 +575,7 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned 
int instr)
if ((instr & 2) == 0)
imm += regs->nip;
regs->nip += 4;
-   if ((regs->msr & MSR_SF) == 0)
-   regs->nip &= 0xUL;
+   regs->nip = truncate_if_32bit(regs->msr, regs->nip);
if (instr & 1)
regs->link = regs->nip;
if (branch_taken(instr, regs))
@@ -604,13 +608,9 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned 
int instr)
imm -= 0x0400;
if ((instr & 2) == 0)
imm += regs->nip;
-   if (instr & 1) {
-   regs->link = regs->nip + 4;
-   if ((regs->msr & MSR_SF) == 0)
-   regs->link &= 0xUL;
-   }
-   if ((regs->msr & MSR_SF) == 0)
-   imm &= 0xUL;
+   if (instr & 1)
+   regs->link = truncate_if_32bit(regs->msr, regs->nip + 
4);
+   imm = truncate_if_32bit(regs->msr, imm);
regs->nip = imm;
return 1;
case 19:
@@ -618,11 +618,8 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned 
int instr)
case 16:/* bclr */
case 528:   /* bcctr */
imm = (instr & 0x400)? regs->ctr: regs->link;
-   regs->nip += 4;
-   if ((regs->msr & MSR_SF) == 0) {
-   regs->nip &= 0xUL;
-   imm &= 0xUL;
-   }
+   regs->nip = truncate_if_32bit(regs->msr, regs->nip + 4);
+   imm = truncate_if_32bit(regs->msr, imm);
if (instr & 1)

[PATCH 2/3] powerpc: Use MSR_64BIT in places

2011-04-08 Thread Michael Ellerman 
Use the new MSR_64BIT in a few places. Some of these are already ifdef'ed
for BOOKE vs BOOKS, but it's still clearer, MSR_SF does not immediately
parse as "MSR bit for 64bit".

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/head_64.S   |2 +-
 arch/powerpc/kernel/signal_64.c |4 ++--
 arch/powerpc/kernel/traps.c |2 +-
 arch/powerpc/xmon/xmon.c|   14 +++---
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 271140b..e7e03f8 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -645,7 +645,7 @@ _GLOBAL(enable_64b_mode)
orisr11,r11,0x8000  /* CM bit set, we'll set ICM later */
mtmsr   r11
 #else /* CONFIG_PPC_BOOK3E */
-   li  r12,(MSR_SF | MSR_ISF)@highest
+   li  r12,(MSR_64BIT | MSR_ISF)@highest
sldir12,r12,48
or  r11,r11,r12
mtmsrd  r11
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index 27c4a45..da989ff 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -381,7 +381,7 @@ badframe:
   regs, uc, &uc->uc_mcontext);
 #endif
if (show_unhandled_signals && printk_ratelimit())
-   printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+   printk(regs->msr & MSR_64BIT ? fmt64 : fmt32,
current->comm, current->pid, "rt_sigreturn",
(long)uc, regs->nip, regs->link);
 
@@ -469,7 +469,7 @@ badframe:
   regs, frame, newsp);
 #endif
if (show_unhandled_signals && printk_ratelimit())
-   printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+   printk(regs->msr & MSR_64BIT ? fmt64 : fmt32,
current->comm, current->pid, "setup_rt_frame",
(long)frame, regs->nip, regs->link);
 
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index bd74fac..443353a 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -199,7 +199,7 @@ void _exception(int signr, struct pt_regs *regs, int code, 
unsigned long addr)
} else if (show_unhandled_signals &&
unhandled_signal(current, signr) &&
printk_ratelimit()) {
-   printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+   printk(regs->msr & MSR_64BIT ? fmt64 : fmt32,
current->comm, current->pid, signr,
addr, regs->nip, regs->link, code);
}
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 33794c1..ef9756e 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -399,7 +399,7 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
cpu_set(cpu, cpus_in_xmon);
 
bp = NULL;
-   if ((regs->msr & (MSR_IR|MSR_PR|MSR_SF)) == (MSR_IR|MSR_SF))
+   if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) == (MSR_IR|MSR_64BIT))
bp = at_breakpoint(regs->nip);
if (bp || unrecoverable_excp(regs))
fromipi = 0;
@@ -529,7 +529,7 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
}
}
 #else
-   if ((regs->msr & (MSR_IR|MSR_PR|MSR_SF)) == (MSR_IR|MSR_SF)) {
+   if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) == (MSR_IR|MSR_64BIT)) {
bp = at_breakpoint(regs->nip);
if (bp != NULL) {
int stepped = emulate_step(regs, bp->instr[0]);
@@ -578,7 +578,7 @@ static int xmon_bpt(struct pt_regs *regs)
struct bpt *bp;
unsigned long offset;
 
-   if ((regs->msr & (MSR_IR|MSR_PR|MSR_SF)) != (MSR_IR|MSR_SF))
+   if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
return 0;
 
/* Are we at the trap at bp->instr[1] for some bp? */
@@ -609,7 +609,7 @@ static int xmon_sstep(struct pt_regs *regs)
 
 static int xmon_dabr_match(struct pt_regs *regs)
 {
-   if ((regs->msr & (MSR_IR|MSR_PR|MSR_SF)) != (MSR_IR|MSR_SF))
+   if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
return 0;
if (dabr.enabled == 0)
return 0;
@@ -619,7 +619,7 @@ static int xmon_dabr_match(struct pt_regs *regs)
 
 static int xmon_iabr_match(struct pt_regs *regs)
 {
-   if ((regs->msr & (MSR_IR|MSR_PR|MSR_SF)) != (MSR_IR|MSR_SF))
+   if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
return 0;
if (iabr == NULL)
return 0;
@@ -644,7 +644,7 @@ static int xmon_fault_handler(struct pt_regs *regs)
if (in_xmon && catch_memory_errors)
handle_fault(regs); /* doesn't return */
 
-   if ((regs->msr & (MSR_IR|MSR_PR|MSR_SF)) == (MSR_IR|MSR_SF)) {
+   if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) == (MSR_IR|MSR_64BIT)) {
bp =

[PATCH 1/3] powerpc: Add MSR_64BIT

2011-04-08 Thread Michael Ellerman 
The MSR bit which indicates 64-bit-ness is different between server and
booke, so add a #define which gives you the right mask regardless.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/reg.h   |   10 --
 arch/powerpc/include/asm/reg_booke.h |6 --
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 7e4abeb..fdaafd0 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -99,17 +99,23 @@
 #define MSR_LE __MASK(MSR_LE_LG)   /* Little Endian */
 
 #if defined(CONFIG_PPC_BOOK3S_64)
+#define MSR_64BIT  MSR_SF
+
 /* Server variant */
 #define MSR_   MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_ISF |MSR_HV
-#define MSR_KERNEL  MSR_ | MSR_SF
+#define MSR_KERNEL MSR_ | MSR_64BIT
 #define MSR_USER32 MSR_ | MSR_PR | MSR_EE
-#define MSR_USER64 MSR_USER32 | MSR_SF
+#define MSR_USER64 MSR_USER32 | MSR_64BIT
 #elif defined(CONFIG_PPC_BOOK3S_32) || defined(CONFIG_8xx)
 /* Default MSR for kernel mode. */
 #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR)
 #define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE)
 #endif
 
+#ifndef MSR_64BIT
+#define MSR_64BIT  0
+#endif
+
 /* Floating Point Status and Control Register (FPSCR) Fields */
 #define FPSCR_FX   0x8000  /* FPU exception summary */
 #define FPSCR_FEX  0x4000  /* FPU enabled exception summary */
diff --git a/arch/powerpc/include/asm/reg_booke.h 
b/arch/powerpc/include/asm/reg_booke.h
index 3b1a9b7..36d7dbd 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -27,10 +27,12 @@
 #define MSR_CM (1<<31) /* Computation Mode (0=32-bit, 1=64-bit) */
 
 #if defined(CONFIG_PPC_BOOK3E_64)
+#define MSR_64BIT  MSR_CM
+
 #define MSR_   MSR_ME | MSR_CE
-#define MSR_KERNEL  MSR_ | MSR_CM
+#define MSR_KERNEL MSR_ | MSR_64BIT
 #define MSR_USER32 MSR_ | MSR_PR | MSR_EE | MSR_DE
-#define MSR_USER64 MSR_USER32 | MSR_CM | MSR_DE
+#define MSR_USER64 MSR_USER32 | MSR_64BIT
 #elif defined (CONFIG_40x)
 #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_CE)
 #define MSR_USER   (MSR_KERNEL|MSR_PR|MSR_EE)
-- 
1.7.1

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

[PATCH] powerpc: Fix oops if scan_dispatch_log is called too early

2011-04-08 Thread Anton Blanchard 

We currently enable interrupts before the dispatch log for the boot
cpu is setup. If a timer interrupt comes in early enough we oops in
scan_dispatch_log:

Unable to handle kernel paging request for data at address 0x0010

...

.scan_dispatch_log+0xb0/0x170
.account_system_vtime+0xa0/0x220
.irq_enter+0x88/0xc0
.do_IRQ+0x48/0x230

The patch below adds a check to scan_dispatch_log to ensure the
dispatch log has been allocated.

Signed-off-by: Anton Blanchard 
Cc: 
---

Index: powerpc.git/arch/powerpc/kernel/time.c
===
--- powerpc.git.orig/arch/powerpc/kernel/time.c 2011-04-05 18:38:40.814489516 
+1000
+++ powerpc.git/arch/powerpc/kernel/time.c  2011-04-08 12:16:41.864748155 
+1000
@@ -229,6 +229,9 @@ static u64 scan_dispatch_log(u64 stop_tb
u64 stolen = 0;
u64 dtb;
 
+   if (!dtl)
+   return 0;
+
if (i == vpa->dtl_idx)
return 0;
while (i < vpa->dtl_idx) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] mm: Check we have the right vma in __access_remote_vm()

2011-04-08 Thread Michael Ellerman 
In __access_remote_vm() we need to check that we have found the right
vma, not the following vma, before we try to access it. Otherwise we
might call the vma's access routine with an address which does not
fall inside the vma.

Signed-off-by: Michael Ellerman 
---
 mm/memory.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 9da8cab..ce999ca 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3678,7 +3678,7 @@ static int __access_remote_vm(struct task_struct *tsk, 
struct mm_struct *mm,
 */
 #ifdef CONFIG_HAVE_IOREMAP_PROT
vma = find_vma(mm, addr);
-   if (!vma)
+   if (!vma || vma->vm_start > addr)
break;
if (vma->vm_ops && vma->vm_ops->access)
ret = vma->vm_ops->access(vma, addr, buf,
-- 
1.7.1

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

[PATCH] powerpc/book3e: Fix extlb size

2011-04-08 Thread Michael Ellerman 
The calculation of the size for the exception save area of the TLB
miss handler is wrong, luckily it's too big not too small.

Rework it to make it a bit clearer, and also correct. We want 3 save
areas, each EX_TLB_SIZE _bytes_.

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

diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index ec57540..c3416ca 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -106,7 +106,8 @@ struct paca_struct {
pgd_t *pgd; /* Current PGD */
pgd_t *kernel_pgd;  /* Kernel PGD */
u64 exgen[8] __attribute__((aligned(0x80)));
-   u64 extlb[EX_TLB_SIZE*3] __attribute__((aligned(0x80)));
+   /* We can have up to 3 levels of reentrancy in the TLB miss handler */
+   u64 extlb[3][EX_TLB_SIZE / sizeof(u64)] __attribute__((aligned(0x80)));
u64 exmc[8];/* used for machine checks */
u64 excrit[8];  /* used for crit interrupts */
u64 exdbg[8];   /* used for debug interrupts */
-- 
1.7.1

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

Re: [PATCH] mm: Check we have the right vma in access_process_vm()

2011-04-08 Thread Michael Ellerman 
On Mon, 2011-04-04 at 23:42 -0700, Michel Lespinasse wrote:
> On Mon, Apr 4, 2011 at 11:24 PM, Michael Ellerman
>  wrote:
> > In access_process_vm() we need to check that we have found the right
> > vma, not the following vma, before we try to access it. Otherwise
> > we might call the vma's access routine with an address which does
> > not fall inside the vma.
> >
> > Signed-off-by: Michael Ellerman 
> 
> Please note that the code has moved into __access_remote_vm() in
> current linus tree.

Ah good point, if git hadn't done such a good job of merging it I would
have noticed :)

I'll send a new version with a corrected changelog.

> Also, should len be truncated before calling vma->vm_ops->access() so
> that we can guarantee it won't overflow past the end of the vma ?

The access implementations I've looked at check len, but I guess it
could be truncated on the way in. But maybe that's being paranoid, I
dunno.

cheers



signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev