* [PATCH v3] net: fec_mpc52xx: Read MAC address from device-tree
From: Stefan Roese @ 2013-02-12 13:05 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Anatolij Gustschin
Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
(U-Boot) to write the MAC address into the ethernet controller
registers. The Linux driver should not rely on such a thing. So
lets read the MAC address from the DT as it should be done here.
The following priority is now used to read the MAC address:
1) First, try OF node MAC address, if not present or invalid, then:
2) Read from MAC address registers, if invalid, then:
3) Log a warning message, and choose a random MAC address.
This fixes a problem with a MPC5200 board that uses the SPL U-Boot
version without FEC initialization before Linux booting for
boot speedup.
Additionally a status line is now be printed upon successful
driver probing, also displaying this MAC address.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Anatolij Gustschin <agust@denx.de>
---
v3:
- Use of_get_mac_address() instead of of_get_property()
v2:
- Remove module parameter mpc52xx_fec_mac_addr
- Priority for MAC address probing now is DT, controller regs
If the resulting MAC address is invalid, a random address will
be generated and used with a warning message
- Use "np" variable to simplify the code
drivers/net/ethernet/freescale/fec_mpc52xx.c | 62 +++++++++++++++++-----------
1 file changed, 38 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c b/drivers/net/ethernet/freescale/fec_mpc52xx.c
index 817d081..7f91b0c 100644
--- a/drivers/net/ethernet/freescale/fec_mpc52xx.c
+++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c
@@ -29,6 +29,7 @@
#include <linux/delay.h>
#include <linux/of_device.h>
#include <linux/of_mdio.h>
+#include <linux/of_net.h>
#include <linux/of_platform.h>
#include <linux/netdevice.h>
@@ -76,10 +77,6 @@ static void mpc52xx_fec_stop(struct net_device *dev);
static void mpc52xx_fec_start(struct net_device *dev);
static void mpc52xx_fec_reset(struct net_device *dev);
-static u8 mpc52xx_fec_mac_addr[6];
-module_param_array_named(mac, mpc52xx_fec_mac_addr, byte, NULL, 0);
-MODULE_PARM_DESC(mac, "six hex digits, ie. 0x1,0x2,0xc0,0x01,0xba,0xbe");
-
#define MPC52xx_MESSAGES_DEFAULT ( NETIF_MSG_DRV | NETIF_MSG_PROBE | \
NETIF_MSG_LINK | NETIF_MSG_IFDOWN | NETIF_MSG_IFUP)
static int debug = -1; /* the above default */
@@ -110,15 +107,6 @@ static void mpc52xx_fec_set_paddr(struct net_device *dev, u8 *mac)
out_be32(&fec->paddr2, (*(u16 *)(&mac[4]) << 16) | FEC_PADDR2_TYPE);
}
-static void mpc52xx_fec_get_paddr(struct net_device *dev, u8 *mac)
-{
- struct mpc52xx_fec_priv *priv = netdev_priv(dev);
- struct mpc52xx_fec __iomem *fec = priv->fec;
-
- *(u32 *)(&mac[0]) = in_be32(&fec->paddr1);
- *(u16 *)(&mac[4]) = in_be32(&fec->paddr2) >> 16;
-}
-
static int mpc52xx_fec_set_mac_address(struct net_device *dev, void *addr)
{
struct sockaddr *sock = addr;
@@ -853,6 +841,8 @@ static int mpc52xx_fec_probe(struct platform_device *op)
struct resource mem;
const u32 *prop;
int prop_size;
+ struct device_node *np = op->dev.of_node;
+ const char *mac_addr;
phys_addr_t rx_fifo;
phys_addr_t tx_fifo;
@@ -866,7 +856,7 @@ static int mpc52xx_fec_probe(struct platform_device *op)
priv->ndev = ndev;
/* Reserve FEC control zone */
- rv = of_address_to_resource(op->dev.of_node, 0, &mem);
+ rv = of_address_to_resource(np, 0, &mem);
if (rv) {
printk(KERN_ERR DRIVER_NAME ": "
"Error while parsing device node resource\n" );
@@ -919,7 +909,7 @@ static int mpc52xx_fec_probe(struct platform_device *op)
/* Get the IRQ we need one by one */
/* Control */
- ndev->irq = irq_of_parse_and_map(op->dev.of_node, 0);
+ ndev->irq = irq_of_parse_and_map(np, 0);
/* RX */
priv->r_irq = bcom_get_task_irq(priv->rx_dmatsk);
@@ -927,11 +917,33 @@ static int mpc52xx_fec_probe(struct platform_device *op)
/* TX */
priv->t_irq = bcom_get_task_irq(priv->tx_dmatsk);
- /* MAC address init */
- if (!is_zero_ether_addr(mpc52xx_fec_mac_addr))
- memcpy(ndev->dev_addr, mpc52xx_fec_mac_addr, 6);
- else
- mpc52xx_fec_get_paddr(ndev, ndev->dev_addr);
+ /*
+ * MAC address init:
+ *
+ * First try to read MAC address from DT
+ */
+ mac_addr = of_get_mac_address(np);
+ if (mac_addr) {
+ memcpy(ndev->dev_addr, mac_addr, ETH_ALEN);
+ } else {
+ struct mpc52xx_fec __iomem *fec = priv->fec;
+
+ /*
+ * If the MAC addresse is not provided via DT then read
+ * it back from the controller regs
+ */
+ *(u32 *)(&ndev->dev_addr[0]) = in_be32(&fec->paddr1);
+ *(u16 *)(&ndev->dev_addr[4]) = in_be32(&fec->paddr2) >> 16;
+ }
+
+ /*
+ * Check if the MAC address is valid, if not get a random one
+ */
+ if (!is_valid_ether_addr(ndev->dev_addr)) {
+ eth_hw_addr_random(ndev);
+ dev_warn(&ndev->dev, "using random MAC address %pM\n",
+ ndev->dev_addr);
+ }
priv->msg_enable = netif_msg_init(debug, MPC52xx_MESSAGES_DEFAULT);
@@ -942,20 +954,20 @@ static int mpc52xx_fec_probe(struct platform_device *op)
/* Start with safe defaults for link connection */
priv->speed = 100;
priv->duplex = DUPLEX_HALF;
- priv->mdio_speed = ((mpc5xxx_get_bus_frequency(op->dev.of_node) >> 20) / 5) << 1;
+ priv->mdio_speed = ((mpc5xxx_get_bus_frequency(np) >> 20) / 5) << 1;
/* The current speed preconfigures the speed of the MII link */
- prop = of_get_property(op->dev.of_node, "current-speed", &prop_size);
+ prop = of_get_property(np, "current-speed", &prop_size);
if (prop && (prop_size >= sizeof(u32) * 2)) {
priv->speed = prop[0];
priv->duplex = prop[1] ? DUPLEX_FULL : DUPLEX_HALF;
}
/* If there is a phy handle, then get the PHY node */
- priv->phy_node = of_parse_phandle(op->dev.of_node, "phy-handle", 0);
+ priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
/* the 7-wire property means don't use MII mode */
- if (of_find_property(op->dev.of_node, "fsl,7-wire-mode", NULL)) {
+ if (of_find_property(np, "fsl,7-wire-mode", NULL)) {
priv->seven_wire_mode = 1;
dev_info(&ndev->dev, "using 7-wire PHY mode\n");
}
@@ -970,6 +982,8 @@ static int mpc52xx_fec_probe(struct platform_device *op)
/* We're done ! */
dev_set_drvdata(&op->dev, ndev);
+ printk(KERN_INFO "%s: %s MAC %pM\n",
+ ndev->name, op->dev.of_node->full_name, ndev->dev_addr);
return 0;
--
1.8.1.3
^ permalink raw reply related
* Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: David Miller @ 2013-02-12 17:05 UTC (permalink / raw)
To: R65777; +Cc: netdev, sr, agust, linuxppc-dev
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D065A0271@039-SN2MPN1-023.039d.mgd.msft.net>
From: Bhushan Bharat-R65777 <R65777@freescale.com>
Date: Tue, 12 Feb 2013 10:56:05 +0000
> Why we read from MAC registers if Linux should not rely on bootloader?
Because it used to and if you just remove that code then you break
existing setups, and I explicitly told him to code things this way.
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: dts - add ranges property for SEC
From: Kumar Gala @ 2013-02-12 17:26 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, Po Liu
In-Reply-To: <20130118144047.616d315258f4d23834363b33@freescale.com>
On Jan 18, 2013, at 2:40 PM, Kim Phillips wrote:
> On Fri, 18 Jan 2013 17:16:13 +0800
> Po Liu <po.liu@freescale.com> wrote:
>
>> This facilitates getting the physical address of the SEC node.
>>
>> Signed-off-by: Liu po <po.liu@freescale.com>
>> ---
> Reviewed-by: Kim Phillips <kim.phillips@freescale.com>
>
> Kim
This was missing a trailing ';', so wondering if it was ever tested?
I fixed when I applied.
applied.
- k
^ permalink raw reply
* [PATCH 1/2] powerpc: Make VSID_BITS* dependency explicit
From: Aneesh Kumar K.V @ 2013-02-12 18:31 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
VSID_BITS and VSID_BITS_1T depends on the context bits and user esid
bits. Make the dependency explicit
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/mmu-hash64.h | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
index 2fdb47a..5f8c2bd 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -381,21 +381,22 @@ extern void slb_set_size(u16 size);
* hash collisions.
*/
+#define CONTEXT_BITS 19
+#define USER_ESID_BITS 18
+#define USER_ESID_BITS_1T 6
+
/*
* This should be computed such that protovosid * vsid_mulitplier
* doesn't overflow 64 bits. It should also be co-prime to vsid_modulus
*/
#define VSID_MULTIPLIER_256M ASM_CONST(12538073) /* 24-bit prime */
-#define VSID_BITS_256M 38
+#define VSID_BITS_256M (CONTEXT_BITS + USER_ESID_BITS + 1)
#define VSID_MODULUS_256M ((1UL<<VSID_BITS_256M)-1)
#define VSID_MULTIPLIER_1T ASM_CONST(12538073) /* 24-bit prime */
-#define VSID_BITS_1T 26
+#define VSID_BITS_1T (CONTEXT_BITS + USER_ESID_BITS_1T + 1)
#define VSID_MODULUS_1T ((1UL<<VSID_BITS_1T)-1)
-#define CONTEXT_BITS 19
-#define USER_ESID_BITS 18
-#define USER_ESID_BITS_1T 6
#define USER_VSID_RANGE (1UL << (USER_ESID_BITS + SID_SHIFT))
--
1.7.10
^ permalink raw reply related
* [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Aneesh Kumar K.V @ 2013-02-12 18:31 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <1360693905-23503-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Different platforms supports different virtual addr size(n bits). We need to mak sure
0:77-n bits of the VA generated is forced to zero.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/mmu-hash64.h | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
index 5f8c2bd..839efae 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -381,7 +381,27 @@ extern void slb_set_size(u16 size);
* hash collisions.
*/
-#define CONTEXT_BITS 19
+/*
+ * Be careful with this value. This determines the VSID_MODULUS_* and that
+ * need to be co-prime with VSID_MULTIPLIER*
+ */
+#if defined(CONFIG_POWER6_CPU) || defined(CONFIG_POWER7_CPU)
+/*
+ * Even if cpu support 68 bits, we limit this to 66 because
+ * we support only 2^19 context.
+ */
+#define MAX_VIRTUAL_ADDR_BITS 66
+#else
+/* power4,power 5 and cell is 65 */
+#define MAX_VIRTUAL_ADDR_BITS 65
+#endif
+
+/*
+ * One bit is taken by the kernel, only the rest of space is available for the
+ * user space.
+ */
+#define CONTEXT_BITS (MAX_VIRTUAL_ADDR_BITS - \
+ (USER_ESID_BITS + SID_SHIFT + 1))
#define USER_ESID_BITS 18
#define USER_ESID_BITS_1T 6
--
1.7.10
^ permalink raw reply related
* Re: [PATCH v5 04/45] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Paul E. McKenney @ 2013-02-12 16:15 UTC (permalink / raw)
To: Oleg Nesterov
Cc: linux-doc, peterz, fweisbec, mingo, linux-arch, linux,
xiaoguangrong, wangyun, nikunj, linux-pm, rusty, rostedt, rjw,
namhyung, tglx, linux-arm-kernel, netdev, linux-kernel, sbw,
Srivatsa S. Bhat, tj, akpm, linuxppc-dev
In-Reply-To: <20130210195417.GK2666@linux.vnet.ibm.com>
On Sun, Feb 10, 2013 at 11:54:17AM -0800, Paul E. McKenney wrote:
> On Sun, Feb 10, 2013 at 07:06:07PM +0100, Oleg Nesterov wrote:
> > On 02/08, Paul E. McKenney wrote:
>
> [ . . . ]
>
> > > > +static inline void sync_reader(struct percpu_rwlock *pcpu_rwlock,
> > > > + unsigned int cpu)
> > > > +{
> > > > + smp_rmb(); /* Paired with smp_[w]mb() in percpu_read_[un]lock() */
> > >
> > > As I understand it, the purpose of this memory barrier is to ensure
> > > that the stores in drop_writer_signal() happen before the reads from
> > > ->reader_refcnt in reader_uses_percpu_refcnt(), thus preventing the
> > > race between a new reader attempting to use the fastpath and this writer
> > > acquiring the lock. Unless I am confused, this must be smp_mb() rather
> > > than smp_rmb().
> >
> > And note that before sync_reader() we call announce_writer_active() which
> > already adds mb() before sync_all_readers/sync_reader, so this rmb() looks
> > unneeded.
> >
> > But, at the same time, could you confirm that we do not need another mb()
> > after sync_all_readers() in percpu_write_lock() ? I mean, without mb(),
> > can't this reader_uses_percpu_refcnt() LOAD leak into the critical section
> > protected by ->global_rwlock? Then this LOAD can be re-ordered with other
> > memory operations done by the writer.
>
> As soon as I get the rest of the way through Thomas's patchset. ;-)
There is a memory barrier associated with write_lock(), but it is
only required to keep the critical section inside the lock -- and is
permitted to allow stuff outside of the lock to be reordered into the
critical section. So I believe we do indeed need an smp_mb() between
sync_all_readers() and write_lock() in percpu_write_lock().
Good eyes, Oleg!
Thanx, Paul
^ permalink raw reply
* Re: BOOKE KVM calling load_up_fpu from C?
From: Scott Wood @ 2013-02-12 18:33 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0659EF89@039-SN2MPN1-023.039d.mgd.msft.net>
On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Michael Neuling [mailto:mikey@neuling.org]
> > Sent: Tuesday, February 12, 2013 9:46 AM
> > To: Bhushan Bharat-R65777
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> >
> > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > > Sent: Tuesday, February 12, 2013 9:16 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > > >
> > > > Look further down...
> > > >
> > > > #ifdef CONFIG_PPC32
> > > > mfspr r5,SPRN_SPRG_THREAD /* current =20
> task's THREAD (phys) */
> > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > ori r9,r9,MSR_FP /* enable FP for =20
> current */
> > > > or r9,r9,r4
> > > > #else
> > > > ld r4,PACACURRENT(r13)
> > > > addi r5,r4,THREAD /* Get THREAD */
> > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > ori r12,r12,MSR_FP
> > > > or r12,r12,r4
> > > > std r12,_MSR(r1)
> > > > #endif
> > > >
> > > > R12 is loaded with SRR1 in the exception prolog before =20
> load_up_fpu is
> > called.
> > >
> > > Yes it is SRR1 not MSR.
> >
> > Yes, SRR1 =3D=3D the MSR of the user process, not the current MSR.
> >
> > > Also on 32bit it looks like that R9 is assumed to have SRR1.
> >
> > Yep that too.
> >
> > So any idea how it's suppose to work or is it broken?
>=20
> To me this looks wrong. And this seems to works because the =20
> thread->reg->msr is not actually used to write SRR1 (and eventually =20
> the thread MSR) when doing rfi to enter guest. Infact =20
> Guest(shadow_msr) MSR is used as SRR1 and which will have proper MSR =20
> (including FP set).
>=20
> But Yes, Scott is right person to comment, So let us wait for him =20
> comment.
I don't think it's actually a problem on 32-bit, since r9 is modified =20
but never actually used for anything. On 64-bit, though, there's a =20
store to the caller's stack frame (yuck) which the kvm/booke.h caller =20
is not prepared for. Indeed, book3s's kvmppc_load_up_fpu creates an =20
interrupt-like stack frame, but does not load r9 or r12.
It would be really nice if assumptions like these were put in a code =20
comment above load_up_fpu... and if we didn't have so many random =20
differences between 32-bit and 64-bit. :-P
-Scott=
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/82xx: fix checkpatch warnings for km82xx.c
From: Kumar Gala @ 2013-02-12 20:00 UTC (permalink / raw)
To: Holger Brunck; +Cc: linuxppc-dev
In-Reply-To: <1354892956-14623-1-git-send-email-holger.brunck@keymile.com>
On Dec 7, 2012, at 9:09 AM, Holger Brunck wrote:
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> cc: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/platforms/82xx/km82xx.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
applied 1-5 to next
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix various PCI node compatible strings
From: Gala Kumar-B11780 @ 2013-02-12 20:01 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev@ozlabs.org, Wood Scott-B07421, Yoder Stuart-B08248
In-Reply-To: <1358462073-2558-1-git-send-email-timur@tabi.org>
On Jan 17, 2013, at 4:34 PM, Timur Tabi wrote:
> From: Timur Tabi <timur@freescale.com>
>=20
> Fix and/or improve the compatible strings of the PCI device tree nodes fo=
r
> some Freescale SOCs. This fixes some issues and improves consistency amo=
ng
> the SOCs.
>=20
> Specifically:
>=20
> 1) The P1022 has a v1 PCIe controller, so the compatible property should =
just
> say "fsl,mpc8548-pcie". U-Boot does not look for "fsl,p1022-pcie", so it
> wasn't fixing up the node.
>=20
> 2) The P4080 has a v2.1 PCIe controller, so add that version-specific str=
ing
> to the device tree. Update the kernel to also look for that string.
> Currently, the kernel looks for "fsl,p4080-pcie" specifically, but
> eventually that check should be deleted.
>=20
> 3) The P1010 device tree claims compatibility with v2.2 and v2.3, but tha=
t's
> redundant. No other device tree does this. Remove the v2.2 string.
>=20
> 4) The kernel looks for both "fsl,p1023-pcie" and "fsl,qoriq-pcie-v2.2",
> even though the P1023 device trees has always included both strings. Rem=
ove
> the search for "fsl,p1023-pcie".
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 4 ++--
> arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 6 +++---
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 6 +++---
> arch/powerpc/sysdev/fsl_pci.c | 15 ++++++++++-----
> 4 files changed, 18 insertions(+), 13 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: describe the PAMU topology in the device tree
From: Gala Kumar-B11780 @ 2013-02-12 20:01 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev@ozlabs.org, Wood Scott-B07421, Yoder Stuart-B08248
In-Reply-To: <1358462073-2558-2-git-send-email-timur@tabi.org>
On Jan 17, 2013, at 4:34 PM, Timur Tabi wrote:
> From: Timur Tabi <timur@freescale.com>
>=20
> The PAMU caches use the LIODNs to determine which cache lines hold the
> entries for the corresponding LIODs. The LIODNs must therefore be
> carefully assigned to avoid cache thrashing -- two active LIODs with
> LIODNs that put them in the same cache line.
>=20
> Currently, LIODNs are statically assigned by U-Boot, but this has
> limitations. LIODNs are assigned even for devices that may be disabled
> or unused by the kernel. Static assignments also do not allow for device
> drivers which may know which LIODs can be used simultaneously. In
> other words, we really should assign LIODNs dynamically in Linux.
>=20
> To do that, we need to describe the PAMU device and cache topologies in
> the device trees.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/guts.txt | 14 ++-
> .../devicetree/bindings/powerpc/fsl/pamu.txt | 142 +++++++++++++++=
+++++
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 87 +++++++++++--
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 87 +++++++++++--
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 68 +++++++++-
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 92 +++++++++++--
> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 92 +++++++++++--
> 7 files changed, 533 insertions(+), 49 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: split sbc8548 dts file into pre and post chunks
From: Kumar Gala @ 2013-02-12 20:01 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1358972013-5271-2-git-send-email-paul.gortmaker@windriver.com>
On Jan 23, 2013, at 2:13 PM, Paul Gortmaker wrote:
> Updates to u-boot allow this board to boot off of either
> the 8MB soldered on flash, or the 64MB SODIMM flash.
>=20
> This is achieved by changing JP12 and SW2.8 which in turn
> swaps which flash device appears on /CS0 and /CS6 respectively.
>=20
> Since the flash devices are not the same size, this also
> changes the MTD memory map layout on the local bus.
>=20
> Here we split the common chunks out into a pre and post
> include, so they can be reused by an upcoming "alternative
> boot" dts file; leaving only the local bus chunk behind.
>=20
> No content changes are made at this point - it is just purely
> the move to using include files.
>=20
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/boot/dts/sbc8548-post.dtsi | 295 =
+++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/sbc8548-pre.dtsi | 52 ++++++
> arch/powerpc/boot/dts/sbc8548.dts | 322 =
+-------------------------------
> 3 files changed, 351 insertions(+), 318 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/sbc8548-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/sbc8548-pre.dtsi
applied 1-4 to next
- k=
^ permalink raw reply
* Re: [PATCH -next] powerpc/85xx: use for_each_compatible_node() macro
From: Kumar Gala @ 2013-02-12 20:02 UTC (permalink / raw)
To: Wei Yongjun
Cc: devicetree-discuss, linux-kernel, rob.herring, yongjun_wei,
paulus, linuxppc-dev
In-Reply-To: <CAPgLHd_esknTwVv4EeehwSJz6ee5eFJ+zf6xntH-vaNwdxkrvg@mail.gmail.com>
On Dec 3, 2012, at 7:36 AM, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Use for_each_compatible_node() macro instead of open coding it.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/fsl: msi: sparse fixes
From: Kumar Gala @ 2013-02-12 20:02 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <1354318502-367-1-git-send-email-kim.phillips@freescale.com>
On Nov 30, 2012, at 5:34 PM, Kim Phillips wrote:
> arch/powerpc/sysdev/fsl_msi.c:31:1: warning: symbol 'msi_head' was not =
declared. Should it be static?
> arch/powerpc/sysdev/fsl_msi.c:138:40: warning: incorrect type in =
argument 1 (different base types)
> arch/powerpc/sysdev/fsl_msi.c:138:40: expected restricted __be64 =
const [usertype] *p
> arch/powerpc/sysdev/fsl_msi.c:138:40: got unsigned long long const =
[usertype] *[assigned] reg
>=20
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied 1-4 to next
- k=
^ permalink raw reply
* Re: [PATCHv1] crypto: caam - Added property fsl, sec-era in SEC4.0 device tree binding.
From: Kumar Gala @ 2013-02-12 20:04 UTC (permalink / raw)
To: Vakul Garg; +Cc: devicetree-discuss, linuxppc-dev, linux-crypto
In-Reply-To: <1358925668-10330-1-git-send-email-vakul@freescale.com>
On Jan 23, 2013, at 1:21 AM, Vakul Garg wrote:
> This new property defines the era of the particular SEC version.
> The compatible property in device tree "crypto" node has been updated
> not to contain SEC era numbers.
>
> Signed-off-by: Vakul Garg <vakul@freescale.com>
> ---
> Changelog:
> 1. Marked fsl,sec-era as 'optional'.
>
> .../devicetree/bindings/crypto/fsl-sec4.txt | 12 +++++++++---
> 1 files changed, 9 insertions(+), 3 deletions(-)
applied to next.
I assume this supersedes http://patchwork.ozlabs.org/patch/204431/
- k
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/fsl: msi: sparse fixes
From: Kumar Gala @ 2013-02-12 20:07 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <1354318502-367-1-git-send-email-kim.phillips@freescale.com>
On Nov 30, 2012, at 5:34 PM, Kim Phillips wrote:
> arch/powerpc/sysdev/fsl_msi.c:31:1: warning: symbol 'msi_head' was not =
declared. Should it be static?
> arch/powerpc/sysdev/fsl_msi.c:138:40: warning: incorrect type in =
argument 1 (different base types)
> arch/powerpc/sysdev/fsl_msi.c:138:40: expected restricted __be64 =
const [usertype] *p
> arch/powerpc/sysdev/fsl_msi.c:138:40: got unsigned long long const =
[usertype] *[assigned] reg
>=20
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied 1-4 to next
- k=
^ permalink raw reply
* Re: [PATCH v2 1/1] powerpc/85xx: Board support for ppa8548
From: Kumar Gala @ 2013-02-12 20:09 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, Stef van Os, linuxppc-dev@lists.ozlabs.org,
Paul Mackerras
In-Reply-To: <510FD412.4000505@calxeda.com>
On Feb 4, 2013, at 9:30 AM, Timur Tabi wrote:
> On 02/03/2013 01:39 PM, Stef van Os wrote:
>=20
>> + pci0: pci@fe0008000 {
>> + status =3D "disabled";
>> + };
>> +
>> + pci1: pci@fe0009000 {
>> + status =3D "disabled";
>> + };
>> +
>> + pci2: pcie@fe000a000 {
>> + status =3D "disabled";
>> + };
>=20
> I was hoping you'd follow my example and include a comment indicating =
why the PCI devices are all disabled.
>=20
>> +static void ppa8548_show_cpuinfo(struct seq_file *m)
>> +{
>> + uint svid, phid1;
>=20
> Please don't used unsized integers for hardware registers.
>=20
> uint32_t svid, phid1;
Stef,
If you'd like this included for 3.9, please make the minor updates.
thanks
- k=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Benjamin Herrenschmidt @ 2013-02-12 20:33 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, paulus
In-Reply-To: <1360693905-23503-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Wed, 2013-02-13 at 00:01 +0530, Aneesh Kumar K.V wrote:
> + * Be careful with this value. This determines the VSID_MODULUS_* and that
> + * need to be co-prime with VSID_MULTIPLIER*
> + */
> +#if defined(CONFIG_POWER6_CPU) || defined(CONFIG_POWER7_CPU)
> +/*
> + * Even if cpu support 68 bits, we limit this to 66 because
> + * we support only 2^19 context.
> + */
> +#define MAX_VIRTUAL_ADDR_BITS 66
> +#else
> +/* power4,power 5 and cell is 65 */
> +#define MAX_VIRTUAL_ADDR_BITS 65
> +#endif
> +
A compile option ? Really ? Ugh...
Ben.
^ permalink raw reply
* Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: David Miller @ 2013-02-12 21:15 UTC (permalink / raw)
To: sr; +Cc: netdev, agust, linuxppc-dev
In-Reply-To: <1360660088-27464-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Tue, 12 Feb 2013 10:08:08 +0100
> Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
> (U-Boot) to write the MAC address into the ethernet controller
> registers. The Linux driver should not rely on such a thing. So
> lets read the MAC address from the DT as it should be done here.
>
> The following priority is now used to read the MAC address:
>
> 1) First, try OF node MAC address, if not present or invalid, then:
>
> 2) Read from MAC address registers, if invalid, then:
>
> 3) Log a warning message, and choose a random MAC address.
>
> This fixes a problem with a MPC5200 board that uses the SPL U-Boot
> version without FEC initialization before Linux booting for
> boot speedup.
>
> Additionally a status line is now be printed upon successful
> driver probing, also displaying this MAC address.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Applied.
^ permalink raw reply
* Re: [PATCH v3] net: fec_mpc52xx: Read MAC address from device-tree
From: David Miller @ 2013-02-12 21:16 UTC (permalink / raw)
To: sr; +Cc: netdev, agust, linuxppc-dev
In-Reply-To: <1360674338-12776-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Tue, 12 Feb 2013 14:05:38 +0100
> v3:
> - Use of_get_mac_address() instead of of_get_property()
Just to clarify, I applied this version (v3), not v2 (which I
just replied to with "applied").
^ permalink raw reply
* Re: BOOKE KVM calling load_up_fpu from C?
From: Michael Neuling @ 2013-02-12 22:51 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <1360693988.24612.4@snotra>
Scott Wood <scottwood@freescale.com> wrote:
> On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > Sent: Tuesday, February 12, 2013 9:46 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > > > Sent: Tuesday, February 12, 2013 9:16 AM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > > > >
> > > > > Look further down...
> > > > >
> > > > > #ifdef CONFIG_PPC32
> > > > > mfspr r5,SPRN_SPRG_THREAD /* current
> > task's THREAD (phys) */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r9,r9,MSR_FP /* enable FP for
> > current */
> > > > > or r9,r9,r4
> > > > > #else
> > > > > ld r4,PACACURRENT(r13)
> > > > > addi r5,r4,THREAD /* Get THREAD */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r12,r12,MSR_FP
> > > > > or r12,r12,r4
> > > > > std r12,_MSR(r1)
> > > > > #endif
> > > > >
> > > > > R12 is loaded with SRR1 in the exception prolog before
> > load_up_fpu is
> > > called.
> > > >
> > > > Yes it is SRR1 not MSR.
> > >
> > > Yes, SRR1 == the MSR of the user process, not the current MSR.
> > >
> > > > Also on 32bit it looks like that R9 is assumed to have SRR1.
> > >
> > > Yep that too.
> > >
> > > So any idea how it's suppose to work or is it broken?
> >
> > To me this looks wrong. And this seems to works because the
> > thread->reg->msr is not actually used to write SRR1 (and eventually
> > the thread MSR) when doing rfi to enter guest. Infact
> > Guest(shadow_msr) MSR is used as SRR1 and which will have proper MSR
> > (including FP set).
> >
> > But Yes, Scott is right person to comment, So let us wait for him
> > comment.
>
> I don't think it's actually a problem on 32-bit, since r9 is modified
> but never actually used for anything. On 64-bit, though, there's a
> store to the caller's stack frame (yuck) which the kvm/booke.h caller
> is not prepared for. Indeed, book3s's kvmppc_load_up_fpu creates an
> interrupt-like stack frame, but does not load r9 or r12.
Yep.
> It would be really nice if assumptions like these were put in a code
> comment above load_up_fpu... and if we didn't have so many random
> differences between 32-bit and 64-bit. :-P
Yep.. I won't NACK that patch when you send it :-)
It was pretty much assumed that load_up_fpu was going to be called right
after the exception prolog. Calling it any other way was going to be
tricky.
Mikey
^ permalink raw reply
* [PATCH] powerpc: Apply early paca fixups to boot_paca and the boot cpu's paca
From: Michael Ellerman @ 2013-02-13 0:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: phileas-fogg
In commit 466921c we added a hack to set the paca data_offset to zero so
that per-cpu accesses would work on the boot cpu prior to per-cpu areas
being setup. This fixed a problem with lockdep touching per-cpu areas
very early in boot.
However if we combine CONFIG_LOCK_STAT=y with any of the PPC_EARLY_DEBUG
options, we can hit the same problem in udbg_early_init(). To avoid that
we need to set the data_offset of the boot_paca also. So factor out the
fixup logic and call it for both the boot_paca, and "the paca of the
boot cpu".
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 6da881b..8d97eb4 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -156,6 +156,15 @@ early_param("smt-enabled", early_smt_enabled);
#define check_smt_enabled()
#endif /* CONFIG_SMP */
+/** Fix up paca fields required for the boot cpu */
+static void fixup_boot_paca(void)
+{
+ /* The boot cpu is started */
+ get_paca()->cpu_start = 1;
+ /* Allow percpu accesses to work until we setup percpu data */
+ get_paca()->data_offset = 0;
+}
+
/*
* Early initialization entry point. This is called by head.S
* with MMU translation disabled. We rely on the "feature" of
@@ -185,6 +194,7 @@ void __init early_setup(unsigned long dt_ptr)
/* Assume we're on cpu 0 for now. Don't write to the paca yet! */
initialise_paca(&boot_paca, 0);
setup_paca(&boot_paca);
+ fixup_boot_paca();
/* Initialize lockdep early or else spinlocks will blow */
lockdep_init();
@@ -205,11 +215,7 @@ void __init early_setup(unsigned long dt_ptr)
/* Now we know the logical id of our boot cpu, setup the paca. */
setup_paca(&paca[boot_cpuid]);
-
- /* Fix up paca fields required for the boot cpu */
- get_paca()->cpu_start = 1;
- /* Allow percpu accesses to "work" until we setup percpu data */
- get_paca()->data_offset = 0;
+ fixup_boot_paca();
/* Probe the machine type */
probe_machine();
--
1.7.10.4
^ permalink raw reply related
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-13 1:18 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1360693988.24612.4@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, February 13, 2013 12:03 AM
> To: Bhushan Bharat-R65777
> Cc: Michael Neuling; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: BOOKE KVM calling load_up_fpu from C?
>=20
> On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > Sent: Tuesday, February 12, 2013 9:46 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > > > Sent: Tuesday, February 12, 2013 9:16 AM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > > > >
> > > > > Look further down...
> > > > >
> > > > > #ifdef CONFIG_PPC32
> > > > > mfspr r5,SPRN_SPRG_THREAD /* current
> > task's THREAD (phys) */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r9,r9,MSR_FP /* enable FP for
> > current */
> > > > > or r9,r9,r4
> > > > > #else
> > > > > ld r4,PACACURRENT(r13)
> > > > > addi r5,r4,THREAD /* Get THREAD */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r12,r12,MSR_FP
> > > > > or r12,r12,r4
> > > > > std r12,_MSR(r1)
> > > > > #endif
> > > > >
> > > > > R12 is loaded with SRR1 in the exception prolog before
> > load_up_fpu is
> > > called.
> > > >
> > > > Yes it is SRR1 not MSR.
> > >
> > > Yes, SRR1 =3D=3D the MSR of the user process, not the current MSR.
> > >
> > > > Also on 32bit it looks like that R9 is assumed to have SRR1.
> > >
> > > Yep that too.
> > >
> > > So any idea how it's suppose to work or is it broken?
> >
> > To me this looks wrong. And this seems to works because the
> > thread->reg->msr is not actually used to write SRR1 (and eventually
> > the thread MSR) when doing rfi to enter guest. Infact
> > Guest(shadow_msr) MSR is used as SRR1 and which will have proper MSR
> > (including FP set).
> >
> > But Yes, Scott is right person to comment, So let us wait for him
> > comment.
>=20
> I don't think it's actually a problem on 32-bit, since r9 is modified but=
never
> actually used for anything.
Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and then r9=
is written back in srr1 ?
> On 64-bit, though, there's a store to the caller's
> stack frame (yuck) which the kvm/booke.h caller is not prepared for.
So if caller is using r12 then it can lead to come corruption, right ?
> Indeed,
> book3s's kvmppc_load_up_fpu creates an interrupt-like stack frame, but do=
es not
> load r9 or r12.
>=20
> It would be really nice if assumptions like these were put in a code comm=
ent
> above load_up_fpu... and if we didn't have so many random differences be=
tween
> 32-bit and 64-bit. :-P
:)
Thanks
-Bharat
>=20
> -Scott
^ permalink raw reply
* Re: BOOKE KVM calling load_up_fpu from C?
From: Scott Wood @ 2013-02-13 1:23 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D065A3456@039-SN2MPN1-023.039d.mgd.msft.net>
On 02/12/2013 07:18:14 PM, Bhushan Bharat-R65777 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, February 13, 2013 12:03 AM
> > To: Bhushan Bharat-R65777
> > Cc: Michael Neuling; Wood Scott-B07421; =20
> linuxppc-dev@lists.ozlabs.org
> > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> >
> > On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> > > To me this looks wrong. And this seems to works because the
> > > thread->reg->msr is not actually used to write SRR1 (and =20
> eventually
> > > the thread MSR) when doing rfi to enter guest. Infact
> > > Guest(shadow_msr) MSR is used as SRR1 and which will have proper =20
> MSR
> > > (including FP set).
> > >
> > > But Yes, Scott is right person to comment, So let us wait for him
> > > comment.
> >
> > I don't think it's actually a problem on 32-bit, since r9 is =20
> modified but never
> > actually used for anything.
>=20
> Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and =20
> then r9 is written back in srr1 ?
What epilog? We're talking about the case where it's called from C =20
code.
When it's called from an exception handler, then r9 is used, but in =20
that case it's also initialized before calling load_up_fpu, by the =20
prolog.
> > On 64-bit, though, there's a store to the caller's
> > stack frame (yuck) which the kvm/booke.h caller is not prepared for.
>=20
> So if caller is using r12 then it can lead to come corruption, right ?
No, r12 is a volatile register in the ABI, as is r9. The issue is that =20
the stack can be corrupted.
-Scott=
^ permalink raw reply
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-13 1:26 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1360718594.24612.21@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, February 13, 2013 6:53 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Michael Neuling; linuxppc-dev@lists.ozlabs.org
> Subject: Re: BOOKE KVM calling load_up_fpu from C?
>=20
> On 02/12/2013 07:18:14 PM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, February 13, 2013 12:03 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Michael Neuling; Wood Scott-B07421;
> > linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> > > > To me this looks wrong. And this seems to works because the
> > > > thread->reg->msr is not actually used to write SRR1 (and
> > eventually
> > > > the thread MSR) when doing rfi to enter guest. Infact
> > > > Guest(shadow_msr) MSR is used as SRR1 and which will have proper
> > MSR
> > > > (including FP set).
> > > >
> > > > But Yes, Scott is right person to comment, So let us wait for him
> > > > comment.
> > >
> > > I don't think it's actually a problem on 32-bit, since r9 is
> > modified but never
> > > actually used for anything.
> >
> > Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and
> > then r9 is written back in srr1 ?
>=20
> What epilog? We're talking about the case where it's called from C code
>=20
> When it's called from an exception handler, then r9 is used, but in that =
case
> it's also initialized before calling load_up_fpu, by the prolog.
Agree. Was just confirming the exception handler case.
>=20
> > > On 64-bit, though, there's a store to the caller's stack frame
> > > (yuck) which the kvm/booke.h caller is not prepared for.
> >
> > So if caller is using r12 then it can lead to come corruption, right ?
>=20
> No, r12 is a volatile register in the ABI, as is r9. The issue is that t=
he
> stack can be corrupted.
Ok, Thanks
-Bharat
>=20
> -Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Aneesh Kumar K.V @ 2013-02-13 3:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1360701185.2035.10.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Wed, 2013-02-13 at 00:01 +0530, Aneesh Kumar K.V wrote:
>> + * Be careful with this value. This determines the VSID_MODULUS_* and that
>> + * need to be co-prime with VSID_MULTIPLIER*
>> + */
>> +#if defined(CONFIG_POWER6_CPU) || defined(CONFIG_POWER7_CPU)
>> +/*
>> + * Even if cpu support 68 bits, we limit this to 66 because
>> + * we support only 2^19 context.
>> + */
>> +#define MAX_VIRTUAL_ADDR_BITS 66
>> +#else
>> +/* power4,power 5 and cell is 65 */
>> +#define MAX_VIRTUAL_ADDR_BITS 65
>> +#endif
>> +
>
> A compile option ? Really ? Ugh...
I actually wanted that to be done in Kconfig.cputype, but haven't found
a nice way to do it. Considering we are switching between only two
values, I was thinking an #ifdef would work.
-aneesh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox