* [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
* [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
* 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
* 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
* [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: Timur Tabi @ 2013-02-12 12:36 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1360660088-27464-1-git-send-email-sr@denx.de>
On Tue, Feb 12, 2013 at 3:08 AM, Stefan Roese <sr@denx.de> wrote:
> + * First try to read MAC address from DT
> + */
> + p = of_get_property(np, "local-mac-address", NULL);
of_get_mac_address()
^ permalink raw reply
* Re: [PATCH] Centralise CONFIG_ARCH_NO_VIRT_TO_BUS
From: James Hogan @ 2013-02-12 12:04 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-arch, linux-sh, Vineet Gupta, linux-kernel, David S. Miller,
sparclinux, Paul Mundt, Paul Mackerras, Bjorn Helgaas,
Andrew Morton, linuxppc-dev, H Hartley Sweeten
In-Reply-To: <20130212224729.5e60d0303bda923bebcc1185@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
On 12/02/13 11:47, Stephen Rothwell wrote:
> Change it to CONFIG_HAVE_VIRT_TO_BUS and set it in all architecures
nit: typo in "architecures"
> that already provide virt_to_bus().
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cheers
James
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: Stefan Roese @ 2013-02-12 12:03 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: netdev@vger.kernel.org, Anatolij Gustschin, David S. Miller,
linuxppc-dev@ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D065A1614@039-SN2MPN1-023.039d.mgd.msft.net>
On 12.02.2013 12:23, Bhushan Bharat-R65777 wrote:
>>> Why we read from MAC registers if Linux should not rely on bootloader?
>>
>> It was suggested by David. Backwards compatibility. Here Davids comment to my
>> original patch which removed this register reading completely:
>>
>> "
>> I don't think this is a conservative enough change.
>>
>> You have to keep the MAC register reading code around, as a backup code path in
>> case the OF device node lacks a MAC address "
>
> Ok,
>
> But this is really a backward compatibility or hiding some bug? My
> thought is that if DT does not have a valid MAC address then it is
> a BUG and should be fixed. Is not it?
Yes. But it can only be fixed in the bootloader then. And some people
might not want to do this or might be unable to do this. So lets keep
this "feature" available for such cases.
BTW: U-Boot traditionally always wrote the MAC address into the FEC
registers. Even if FEC was not used in U-Boot at all. I only noticed
this problem with the new SPL fastbooting U-Boot version, which is
basically a very stripped down U-Boot version directly booting into
Linux (or U-Boot if selected). Here the FEC registers are not touched at
all. And the Linux FEC driver then woke up with an invalid MAC address.
Thanks,
Stefan
^ permalink raw reply
* [PATCH] Centralise CONFIG_ARCH_NO_VIRT_TO_BUS
From: Stephen Rothwell @ 2013-02-12 11:47 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, James Hogan, linux-sh, Vineet Gupta, linux-kernel,
sparclinux, Paul Mundt, Paul Mackerras, Bjorn Helgaas,
H Hartley Sweeten, linuxppc-dev, David S. Miller
In-Reply-To: <20130212154010.3f8b88da4756c7cf04e28a04@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 11133 bytes --]
Change it to CONFIG_HAVE_VIRT_TO_BUS and set it in all architecures
that already provide virt_to_bus().
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/Kconfig | 7 +++++++
arch/alpha/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/avr32/Kconfig | 1 +
arch/blackfin/Kconfig | 1 +
arch/cris/Kconfig | 1 +
arch/frv/Kconfig | 1 +
arch/h8300/Kconfig | 1 +
arch/ia64/Kconfig | 1 +
arch/m32r/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/mn10300/Kconfig | 1 +
arch/openrisc/Kconfig | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/Kconfig | 4 +---
arch/s390/Kconfig | 1 +
arch/score/Kconfig | 1 +
arch/sh/Kconfig | 3 ---
arch/sparc/Kconfig | 3 ---
arch/tile/Kconfig | 1 +
arch/unicore32/Kconfig | 1 +
arch/x86/Kconfig | 1 +
arch/xtensa/Kconfig | 1 +
mm/Kconfig | 2 +-
26 files changed, 30 insertions(+), 10 deletions(-)
This is based on v3.8-rc7. I think I got them all (apart from arc and metag).
diff --git a/arch/Kconfig b/arch/Kconfig
index 7f8f281..7721b40 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -291,6 +291,13 @@ config ARCH_WANT_OLD_COMPAT_IPC
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
bool
+config HAVE_VIRT_TO_BUS
+ bool
+ help
+ An architecture should select this if it implements the
+ deprecated interface virt_to_bus(). All new architectures
+ should probably not select this.
+
config HAVE_ARCH_SECCOMP_FILTER
bool
help
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 9d5904c..63f49b1 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -10,6 +10,7 @@ config ALPHA
select HAVE_PERF_EVENTS
select HAVE_DMA_ATTRS
select HAVE_GENERIC_HARDIRQS
+ select HAVE_VIRT_TO_BUS
select GENERIC_IRQ_PROBE
select AUTO_IRQ_AFFINITY if SMP
select GENERIC_IRQ_SHOW
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..23f99e1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -49,6 +49,7 @@ config ARM
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UID16
+ select HAVE_VIRT_TO_BUS
select KTIME_SCALAR
select PERF_USE_VMALLOC
select RTC_LIB
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 2ae6591..9b89257 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -7,6 +7,7 @@ config AVR32
select HAVE_OPROFILE
select HAVE_KPROBES
select HAVE_GENERIC_HARDIRQS
+ select HAVE_VIRT_TO_BUS
select GENERIC_IRQ_PROBE
select GENERIC_ATOMIC64
select HARDIRQS_SW_RESEND
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index b6f3ad5..834a6e3 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -34,6 +34,7 @@ config BLACKFIN
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_WANT_OPTIONAL_GPIOLIB
select HAVE_UID16
+ select HAVE_VIRT_TO_BUS
select ARCH_WANT_IPC_PARSE_VERSION
select HAVE_GENERIC_HARDIRQS
select GENERIC_ATOMIC64
diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig
index c59a01d..abe1fd2 100644
--- a/arch/cris/Kconfig
+++ b/arch/cris/Kconfig
@@ -43,6 +43,7 @@ config CRIS
select GENERIC_ATOMIC64
select HAVE_GENERIC_HARDIRQS
select HAVE_UID16
+ select HAVE_VIRT_TO_BUS
select ARCH_WANT_IPC_PARSE_VERSION
select GENERIC_IRQ_SHOW
select GENERIC_IOMAP
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index 9d26264..8ca9099 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -7,6 +7,7 @@ config FRV
select HAVE_PERF_EVENTS
select HAVE_UID16
select HAVE_GENERIC_HARDIRQS
+ select HAVE_VIRT_TO_BUS
select GENERIC_IRQ_SHOW
select HAVE_DEBUG_BUGVERBOSE
select ARCH_HAVE_NMI_SAFE_CMPXCHG
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 2d2efb6..ce7c55e 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -5,6 +5,7 @@ config H8300
select HAVE_GENERIC_HARDIRQS
select GENERIC_ATOMIC64
select HAVE_UID16
+ select HAVE_VIRT_TO_BUS
select ARCH_WANT_IPC_PARSE_VERSION
select GENERIC_IRQ_SHOW
select GENERIC_CPU_DEVICES
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 3279646..4c09006 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -26,6 +26,7 @@ config IA64
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP
select HAVE_VIRT_CPU_ACCOUNTING
+ select HAVE_VIRT_TO_BUS
select ARCH_DISCARD_MEMBLOCK
select GENERIC_IRQ_PROBE
select GENERIC_PENDING_IRQ if SMP
diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
index f807721..9262381 100644
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -10,6 +10,7 @@ config M32R
select ARCH_WANT_IPC_PARSE_VERSION
select HAVE_DEBUG_BUGVERBOSE
select HAVE_GENERIC_HARDIRQS
+ select HAVE_VIRT_TO_BUS
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select GENERIC_ATOMIC64
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 6710084..a12199b 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -8,6 +8,7 @@ config M68K
select GENERIC_IRQ_SHOW
select GENERIC_ATOMIC64
select HAVE_UID16
+ select HAVE_VIRT_TO_BUS
select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
select GENERIC_CPU_DEVICES
select GENERIC_STRNCPY_FROM_USER if MMU
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index ba3b7c8..7843d11 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -19,6 +19,7 @@ config MICROBLAZE
select HAVE_DEBUG_KMEMLEAK
select IRQ_DOMAIN
select HAVE_GENERIC_HARDIRQS
+ select HAVE_VIRT_TO_BUS
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select GENERIC_PCI_IOMAP
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2ac626a..7013aaa 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -39,6 +39,7 @@ config MIPS
select GENERIC_CLOCKEVENTS
select GENERIC_CMOS_UPDATE
select HAVE_MOD_ARCH_SPECIFIC
+ select HAVE_VIRT_TO_BUS
select MODULES_USE_ELF_REL if MODULES
select MODULES_USE_ELF_RELA if MODULES && 64BIT
diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig
index e70001c..0d1582d 100644
--- a/arch/mn10300/Kconfig
+++ b/arch/mn10300/Kconfig
@@ -8,6 +8,7 @@ config MN10300
select HAVE_ARCH_KGDB
select GENERIC_ATOMIC64
select HAVE_NMI_WATCHDOG if MN10300_WD_TIMER
+ select HAVE_VIRT_TO_BUS
select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 0ac66f6..b62ed01 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -12,6 +12,7 @@ config OPENRISC
select ARCH_WANT_OPTIONAL_GPIOLIB
select HAVE_ARCH_TRACEHOOK
select HAVE_GENERIC_HARDIRQS
+ select HAVE_VIRT_TO_BUS
select GENERIC_IRQ_CHIP
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index b77feff..598cf09 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -21,6 +21,7 @@ config PARISC
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
select HAVE_MOD_ARCH_SPECIFIC
+ select HAVE_VIRT_TO_BUS
select MODULES_USE_ELF_RELA
select CLONE_BACKWARDS
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 17903f1..f492ad9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -87,9 +87,6 @@ config GENERIC_GPIO
help
Generic GPIO API support
-config ARCH_NO_VIRT_TO_BUS
- def_bool PPC64
-
config PPC
bool
default y
@@ -101,6 +98,7 @@ config PPC
select HAVE_FUNCTION_GRAPH_TRACER
select SYSCTL_EXCEPTION_TRACE
select ARCH_WANT_OPTIONAL_GPIOLIB
+ select HAVE_VIRT_TO_BUS if !PPC64
select HAVE_IDE
select HAVE_IOREMAP_PROT
select HAVE_EFFICIENT_UNALIGNED_ACCESS
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index b5ea38c..5d23fa6 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -98,6 +98,7 @@ config S390
select HAVE_CMPXCHG_DOUBLE
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
select HAVE_VIRT_CPU_ACCOUNTING
+ select HAVE_VIRT_TO_BUS
select VIRT_CPU_ACCOUNTING
select ARCH_DISCARD_MEMBLOCK
select BUILDTIME_EXTABLE_SORT
diff --git a/arch/score/Kconfig b/arch/score/Kconfig
index 3b1482e..e569aa1 100644
--- a/arch/score/Kconfig
+++ b/arch/score/Kconfig
@@ -12,6 +12,7 @@ config SCORE
select GENERIC_CPU_DEVICES
select GENERIC_CLOCKEVENTS
select HAVE_MOD_ARCH_SPECIFIC
+ select HAVE_VIRT_TO_BUS
select MODULES_USE_ELF_REL
select CLONE_BACKWARDS
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index babc2b8..efa4c8c 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -150,9 +150,6 @@ config ARCH_HAS_ILOG2_U32
config ARCH_HAS_ILOG2_U64
def_bool n
-config ARCH_NO_VIRT_TO_BUS
- def_bool y
-
config ARCH_HAS_DEFAULT_IDLE
def_bool y
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 9f2edb5..aaa20de 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -143,9 +143,6 @@ config GENERIC_GPIO
help
Generic GPIO API support
-config ARCH_NO_VIRT_TO_BUS
- def_bool y
-
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y if SPARC64
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 875d008..61a6e59 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -17,6 +17,7 @@ config TILE
select GENERIC_IRQ_SHOW
select HAVE_DEBUG_BUGVERBOSE
select HAVE_SYSCALL_WRAPPERS if TILEGX
+ select HAVE_VIRT_TO_BUS
select SYS_HYPERVISOR
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_CLOCKEVENTS
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index 60651df..dc50b15 100644
--- a/arch/unicore32/Kconfig
+++ b/arch/unicore32/Kconfig
@@ -9,6 +9,7 @@ config UNICORE32
select GENERIC_ATOMIC64
select HAVE_KERNEL_LZO
select HAVE_KERNEL_LZMA
+ select HAVE_VIRT_TO_BUS
select ARCH_HAVE_CUSTOM_GPIO_H
select GENERIC_FIND_FIRST_BIT
select GENERIC_IRQ_PROBE
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 225543b..3d3304d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -110,6 +110,7 @@ config X86
select GENERIC_STRNLEN_USER
select HAVE_CONTEXT_TRACKING if X86_64
select HAVE_IRQ_TIME_ACCOUNTING
+ select HAVE_VIRT_TO_BUS
select MODULES_USE_ELF_REL if X86_32
select MODULES_USE_ELF_RELA if X86_64
select CLONE_BACKWARDS if X86_32
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 5aab1ac..e0c082b 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -9,6 +9,7 @@ config XTENSA
select HAVE_IDE
select GENERIC_ATOMIC64
select HAVE_GENERIC_HARDIRQS
+ select HAVE_VIRT_TO_BUS
select GENERIC_IRQ_SHOW
select GENERIC_CPU_DEVICES
select MODULES_USE_ELF_RELA
diff --git a/mm/Kconfig b/mm/Kconfig
index 278e3ab..6d5996f 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -266,7 +266,7 @@ config NR_QUICK
config VIRT_TO_BUS
def_bool y
- depends on !ARCH_NO_VIRT_TO_BUS
+ depends on HAVE_VIRT_TO_BUS
config MMU_NOTIFIER
bool
--
1.8.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* RE: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: Bhushan Bharat-R65777 @ 2013-02-12 11:23 UTC (permalink / raw)
To: Stefan Roese
Cc: netdev@vger.kernel.org, Anatolij Gustschin, David S. Miller,
linuxppc-dev@ozlabs.org
In-Reply-To: <511A219A.7080000@denx.de>
> -----Original Message-----
> From: Stefan Roese [mailto:sr@denx.de]
> Sent: Tuesday, February 12, 2013 4:34 PM
> To: Bhushan Bharat-R65777
> Cc: netdev@vger.kernel.org; linuxppc-dev@ozlabs.org; Anatolij Gustschin; =
David
> S. Miller
> Subject: Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tr=
ee
>=20
> On 12.02.2013 11:56, Bhushan Bharat-R65777 wrote:
> >> 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:
> >
> > Why we read from MAC registers if Linux should not rely on bootloader?
>=20
> It was suggested by David. Backwards compatibility. Here Davids comment t=
o my
> original patch which removed this register reading completely:
>=20
> "
> I don't think this is a conservative enough change.
>=20
> You have to keep the MAC register reading code around, as a backup code p=
ath in
> case the OF device node lacks a MAC address "
Ok,
But this is really a backward compatibility or hiding some bug? My thought =
is that if DT does not have a valid MAC address then it is a BUG and should=
be fixed. Is not it?
-Bharat
>=20
> Thanks,
> Stefan
^ permalink raw reply
* Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: Stefan Roese @ 2013-02-12 11:03 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: netdev@vger.kernel.org, Anatolij Gustschin, David S. Miller,
linuxppc-dev@ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D065A0271@039-SN2MPN1-023.039d.mgd.msft.net>
On 12.02.2013 11:56, Bhushan Bharat-R65777 wrote:
>> 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:
>
> Why we read from MAC registers if Linux should not rely on bootloader?
It was suggested by David. Backwards compatibility. Here Davids comment
to my original patch which removed this register reading completely:
"
I don't think this is a conservative enough change.
You have to keep the MAC register reading code around, as a backup
code path in case the OF device node lacks a MAC address
"
Thanks,
Stefan
^ permalink raw reply
* RE: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: Bhushan Bharat-R65777 @ 2013-02-12 10:56 UTC (permalink / raw)
To: Stefan Roese, netdev@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org, Anatolij Gustschin
In-Reply-To: <1360660088-27464-1-git-send-email-sr@denx.de>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Ste=
fan Roese
> Sent: Tuesday, February 12, 2013 2:38 PM
> To: netdev@vger.kernel.org
> Cc: linuxppc-dev@ozlabs.org; Anatolij Gustschin
> Subject: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
>=20
> 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 addres=
s from
> the DT as it should be done here.
>=20
> The following priority is now used to read the MAC address:
>=20
> 1) First, try OF node MAC address, if not present or invalid, then:
>=20
> 2) Read from MAC address registers, if invalid, then:
Why we read from MAC registers if Linux should not rely on bootloader?
-Bharat
>=20
> 3) Log a warning message, and choose a random MAC address.
>=20
> This fixes a problem with a MPC5200 board that uses the SPL U-Boot versio=
n
> without FEC initialization before Linux booting for boot speedup.
>=20
> Additionally a status line is now be printed upon successful driver probi=
ng,
> also displaying this MAC address.
>=20
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Anatolij Gustschin <agust@denx.de>
> ---
> 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
>=20
> drivers/net/ethernet/freescale/fec_mpc52xx.c | 61 +++++++++++++++++-----=
------
> 1 file changed, 37 insertions(+), 24 deletions(-)
>=20
> diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c
> b/drivers/net/ethernet/freescale/fec_mpc52xx.c
> index 817d081..8b725f4 100644
> --- a/drivers/net/ethernet/freescale/fec_mpc52xx.c
> +++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c
> @@ -76,10 +76,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);
>=20
> -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 =3D -1; /* the above default */
> @@ -110,15 +106,6 @@ static void mpc52xx_fec_set_paddr(struct net_device =
*dev,
> u8 *mac)
> out_be32(&fec->paddr2, (*(u16 *)(&mac[4]) << 16) | FEC_PADDR2_TYPE); }
>=20
> -static void mpc52xx_fec_get_paddr(struct net_device *dev, u8 *mac) -{
> - struct mpc52xx_fec_priv *priv =3D netdev_priv(dev);
> - struct mpc52xx_fec __iomem *fec =3D priv->fec;
> -
> - *(u32 *)(&mac[0]) =3D in_be32(&fec->paddr1);
> - *(u16 *)(&mac[4]) =3D in_be32(&fec->paddr2) >> 16;
> -}
> -
> static int mpc52xx_fec_set_mac_address(struct net_device *dev, void *add=
r) {
> struct sockaddr *sock =3D addr;
> @@ -853,6 +840,8 @@ static int mpc52xx_fec_probe(struct platform_device *=
op)
> struct resource mem;
> const u32 *prop;
> int prop_size;
> + struct device_node *np =3D op->dev.of_node;
> + const void *p;
>=20
> phys_addr_t rx_fifo;
> phys_addr_t tx_fifo;
> @@ -866,7 +855,7 @@ static int mpc52xx_fec_probe(struct platform_device *=
op)
> priv->ndev =3D ndev;
>=20
> /* Reserve FEC control zone */
> - rv =3D of_address_to_resource(op->dev.of_node, 0, &mem);
> + rv =3D of_address_to_resource(np, 0, &mem);
> if (rv) {
> printk(KERN_ERR DRIVER_NAME ": "
> "Error while parsing device node resource\n" ); @@ -
> 919,7 +908,7 @@ static int mpc52xx_fec_probe(struct platform_device *op)
>=20
> /* Get the IRQ we need one by one */
> /* Control */
> - ndev->irq =3D irq_of_parse_and_map(op->dev.of_node, 0);
> + ndev->irq =3D irq_of_parse_and_map(np, 0);
>=20
> /* RX */
> priv->r_irq =3D bcom_get_task_irq(priv->rx_dmatsk);
> @@ -927,11 +916,33 @@ static int mpc52xx_fec_probe(struct platform_device=
*op)
> /* TX */
> priv->t_irq =3D bcom_get_task_irq(priv->tx_dmatsk);
>=20
> - /* 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
> + */
> + p =3D of_get_property(np, "local-mac-address", NULL);
> + if (p !=3D NULL) {
> + memcpy(ndev->dev_addr, p, 6);
> + } else {
> + struct mpc52xx_fec __iomem *fec =3D priv->fec;
> +
> + /*
> + * If the MAC addresse is not provided via DT then read
> + * it back from the controller regs
> + */
> + *(u32 *)(&ndev->dev_addr[0]) =3D in_be32(&fec->paddr1);
> + *(u16 *)(&ndev->dev_addr[4]) =3D 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);
> + }
>=20
> priv->msg_enable =3D netif_msg_init(debug, MPC52xx_MESSAGES_DEFAULT);
>=20
> @@ -942,20 +953,20 @@ static int mpc52xx_fec_probe(struct platform_device=
*op)
> /* Start with safe defaults for link connection */
> priv->speed =3D 100;
> priv->duplex =3D DUPLEX_HALF;
> - priv->mdio_speed =3D ((mpc5xxx_get_bus_frequency(op->dev.of_node) >> 20=
) /
> 5) << 1;
> + priv->mdio_speed =3D ((mpc5xxx_get_bus_frequency(np) >> 20) / 5) << 1;
>=20
> /* The current speed preconfigures the speed of the MII link */
> - prop =3D of_get_property(op->dev.of_node, "current-speed", &prop_size);
> + prop =3D of_get_property(np, "current-speed", &prop_size);
> if (prop && (prop_size >=3D sizeof(u32) * 2)) {
> priv->speed =3D prop[0];
> priv->duplex =3D prop[1] ? DUPLEX_FULL : DUPLEX_HALF;
> }
>=20
> /* If there is a phy handle, then get the PHY node */
> - priv->phy_node =3D of_parse_phandle(op->dev.of_node, "phy-handle", 0);
> + priv->phy_node =3D of_parse_phandle(np, "phy-handle", 0);
>=20
> /* 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 =3D 1;
> dev_info(&ndev->dev, "using 7-wire PHY mode\n");
> }
> @@ -970,6 +981,8 @@ static int mpc52xx_fec_probe(struct platform_device *=
op)
>=20
> /* 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);
>=20
> return 0;
>=20
> --
> 1.8.1.3
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: Stefan Roese @ 2013-02-12 9:08 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>
---
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 | 61 +++++++++++++++++-----------
1 file changed, 37 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c b/drivers/net/ethernet/freescale/fec_mpc52xx.c
index 817d081..8b725f4 100644
--- a/drivers/net/ethernet/freescale/fec_mpc52xx.c
+++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c
@@ -76,10 +76,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 +106,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 +840,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 void *p;
phys_addr_t rx_fifo;
phys_addr_t tx_fifo;
@@ -866,7 +855,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 +908,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 +916,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
+ */
+ p = of_get_property(np, "local-mac-address", NULL);
+ if (p != NULL) {
+ memcpy(ndev->dev_addr, p, 6);
+ } 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 +953,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 +981,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: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-12 9:01 UTC (permalink / raw)
To: Michael Neuling; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <30014.1360642578@ale.ozlabs.ibm.com>
> -----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?
>=20
> Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
>=20
> >
> >
> > > -----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?
> > >
> > > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > > bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behal=
f
> > > > > bounces+Of Michael
> > > > > Neuling
> > > > > Sent: Tuesday, February 12, 2013 8:59 AM
> > > > > To: Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > Subject: BOOKE KVM calling load_up_fpu from C?
> > > > >
> > > > > Scott,
> > > > >
> > > > > I was looking at changing how load_up_fpu works and I found this
> > > > > in
> > > > > arch/powerpc/kvm/booke.h:
> > > > >
> > > > > static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu) {
> > > > > #ifdef CONFIG_PPC_FPU
> > > > > if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
> > > > > load_up_fpu();
> > > > > current->thread.regs->msr |=3D MSR_FP;
> > > > > }
> > > > > #endif
> > > > > }
> > > > >
> > > > > I'm wondering how this is suppose to work since load_up_fpu is
> > > > > suppose to have MSR in R12?
> > > >
> > > > Is not the load_up_fpu() does mfmsr:
> > > >
> > > > _GLOBAL(load_up_fpu)
> > > > mfmsr r5
> > > > ori r5,r5,MSR_FP
> > > > #ifdef CONFIG_VSX
> > > > BEGIN_FTR_SECTION
> > > > oris r5,r5,MSR_VSX@h
> > > > END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> > > > #endif
> > > > SYNC
> > > > MTMSRD(r5) /* enable use of fpu now */
> > > > isync
> > > > <snip>
> > >
> > > 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.
>=20
> Yes, SRR1 =3D=3D the MSR of the user process, not the current MSR.
>=20
> > Also on 32bit it looks like that R9 is assumed to have SRR1.
>=20
> Yep that too.
>=20
> 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->ms=
r is not actually used to write SRR1 (and eventually the thread MSR) when d=
oing rfi to enter guest. Infact Guest(shadow_msr) MSR is used as SRR1 and w=
hich will have proper MSR (including FP set).
But Yes, Scott is right person to comment, So let us wait for him comment.
Thanks
-Bharat
^ permalink raw reply
* Re: [BUG] irq_dispose_mapping after irq request failure
From: Benjamin Herrenschmidt @ 2013-02-12 8:53 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Baruch Siach, linuxppc-dev, linux-kernel
In-Reply-To: <20130212061822.GA8977@concordia>
On Tue, 2013-02-12 at 17:18 +1100, Michael Ellerman wrote:
>
> I don't think you can, "active" is not well defined. Other code may have
> done nothing other than create the mapping and remembered the virq,
> which will break if you destroy the mapping. Or?
Active as in "requested". Yes there's a potential problems with multiple
requests for mappings & shared interrupts. This is not a problem for PCI
on powerpc because we don't free those mappings afaik.
> I agree refcounting is not fun. It'll end up with the same mess as
> of_node_get/put() where practically every 2nd piece of code leaks
> references.
>
> I guess we can't go the other way, and say that mapping the same hwirq
> twice is an error.
Might be worth it, and force the sharing case to be handled at some kind
of upper level (bus or platform).
Ben.
^ permalink raw reply
* Re: [BUG] irq_dispose_mapping after irq request failure
From: Michael Ellerman @ 2013-02-12 6:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Baruch Siach, linuxppc-dev, linux-kernel
In-Reply-To: <1360630273.2035.2.camel@pasglop>
On Tue, Feb 12, 2013 at 11:51:13AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-02-11 at 20:52 +0000, Grant Likely wrote:
> > Really the irq mappings should be using reference counting. The existing
> > code is naive on this count and just releases the irq on the first call
> > to irq_dispose_mapping(). I've not gotten around to fixing that. Anyone
> > want to take that task on?
>
> Is this the best approach ?
>
> The original idea was that there was no point disposing of mappings in most
> cases and keeping the mapping around would provide a bit of stability of
> interrupt numbers which might come in handy for debugging etc...
>
> The few cases where disposing of a mapping might be useful is if the underlying
> physical interrupts completely disappear, as in a cascaded controller gets
> removed or that sort of thing, which is a very rare case... And even then...
That may have been the intent, but we forgot to tell driver writers, ourselves
included.
> Could you just make irq_dispose_mapping() check if the irq desc is
> active and fail/WARN/BUG if it is ? I don't see the point of adding a refcount,
> that feels overkill.
I don't think you can, "active" is not well defined. Other code may have
done nothing other than create the mapping and remembered the virq,
which will break if you destroy the mapping. Or?
I agree refcounting is not fun. It'll end up with the same mess as
of_node_get/put() where practically every 2nd piece of code leaks
references.
I guess we can't go the other way, and say that mapping the same hwirq
twice is an error.
cheers
^ permalink raw reply
* Re: [PATCH] Centralise CONFIG_ARCH_NO_VIRT_TO_BUS
From: Stephen Rothwell @ 2013-02-12 4:40 UTC (permalink / raw)
To: James Hogan
Cc: linux-arch, linux-sh, Vineet Gupta, linux-kernel, David S. Miller,
sparclinux, Paul Mundt, Paul Mackerras, Bjorn Helgaas,
Andrew Morton, linuxppc-dev, H Hartley Sweeten
In-Reply-To: <5118DCA8.1030905@imgtec.com>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
Hi James,
On Mon, 11 Feb 2013 11:57:28 +0000 James Hogan <james.hogan@imgtec.com> wrote:
>
> On 12/11/12 21:26, Stephen Rothwell wrote:
> > Make if easier for more architectures to select it and thus disable
> > drivers that use virt_to_bus().
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> I was just wondering what the status of this patch is? It was in -next
> for a while but seems to have disappeared.
Yeah, I think Andrew dropped it in favour of a more complete solution
which I haven't written yet. Let me dig out the emails and have a shot.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: BOOKE KVM calling load_up_fpu from C?
From: Michael Neuling @ 2013-02-12 4:16 UTC (permalink / raw)
To: Bhushan Bharat-R65777; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0659EC82@039-SN2MPN1-023.039d.mgd.msft.net>
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?
> >
> > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of
> > > > bounces+Michael
> > > > Neuling
> > > > Sent: Tuesday, February 12, 2013 8:59 AM
> > > > To: Wood Scott-B07421
> > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > Subject: BOOKE KVM calling load_up_fpu from C?
> > > >
> > > > Scott,
> > > >
> > > > I was looking at changing how load_up_fpu works and I found this in
> > > > arch/powerpc/kvm/booke.h:
> > > >
> > > > static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu) {
> > > > #ifdef CONFIG_PPC_FPU
> > > > if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
> > > > load_up_fpu();
> > > > current->thread.regs->msr |= MSR_FP;
> > > > }
> > > > #endif
> > > > }
> > > >
> > > > I'm wondering how this is suppose to work since load_up_fpu is
> > > > suppose to have MSR in R12?
> > >
> > > Is not the load_up_fpu() does mfmsr:
> > >
> > > _GLOBAL(load_up_fpu)
> > > mfmsr r5
> > > ori r5,r5,MSR_FP
> > > #ifdef CONFIG_VSX
> > > BEGIN_FTR_SECTION
> > > oris r5,r5,MSR_VSX@h
> > > END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> > > #endif
> > > SYNC
> > > MTMSRD(r5) /* enable use of fpu now */
> > > isync
> > > <snip>
> >
> > 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?
Mikey
^ permalink raw reply
* Re: [PATCH v5 00/45] CPU hotplug: stop_machine()-free CPU hotplug
From: Srivatsa S. Bhat @ 2013-02-12 3:58 UTC (permalink / raw)
To: paulmck
Cc: linux-doc, peterz, fweisbec, linux-kernel, walken, mingo,
linux-arch, Russell King - ARM Linux, xiaoguangrong, wangyun,
nikunj, linux-pm, Rusty Russell, rostedt, rjw, namhyung, tglx,
linux-arm-kernel, netdev, oleg, Vincent Guittot, sbw, tj, akpm,
linuxppc-dev
In-Reply-To: <20130211190852.GA5695@linux.vnet.ibm.com>
On 02/12/2013 12:38 AM, Paul E. McKenney wrote:
> On Mon, Feb 11, 2013 at 05:53:41PM +0530, Srivatsa S. Bhat wrote:
>> On 02/11/2013 05:28 PM, Vincent Guittot wrote:
>>> On 8 February 2013 19:09, Srivatsa S. Bhat
>>> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>
> [ . . . ]
>
>>>> Adding Vincent to CC, who had previously evaluated the performance and
>>>> latency implications of CPU hotplug on ARM platforms, IIRC.
>>>>
>>>
>>> Hi Srivatsa,
>>>
>>> I can try to run some of our stress tests on your patches.
>>
>> Great!
>>
>>> Have you
>>> got a git tree that i can pull ?
>>>
>>
>> Unfortunately, no, none at the moment.. :-(
>
> You do need to create an externally visible git tree.
Ok, I'll do that soon.
> In the meantime,
> I have added your series at rcu/bhat.2013.01.21a on -rcu:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>
> This should appear soon on a kernel.org mirror near you. ;-)
>
Thank you very much, Paul! :-)
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-12 3:58 UTC (permalink / raw)
To: Michael Neuling; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <16381.1360640767@ale.ozlabs.ibm.com>
> -----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?
>=20
> Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
>=20
> >
> >
> > > -----Original Message-----
> > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behalf Of
> > > bounces+Michael
> > > Neuling
> > > Sent: Tuesday, February 12, 2013 8:59 AM
> > > To: Wood Scott-B07421
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > Subject: BOOKE KVM calling load_up_fpu from C?
> > >
> > > Scott,
> > >
> > > I was looking at changing how load_up_fpu works and I found this in
> > > arch/powerpc/kvm/booke.h:
> > >
> > > static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu) {
> > > #ifdef CONFIG_PPC_FPU
> > > if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
> > > load_up_fpu();
> > > current->thread.regs->msr |=3D MSR_FP;
> > > }
> > > #endif
> > > }
> > >
> > > I'm wondering how this is suppose to work since load_up_fpu is
> > > suppose to have MSR in R12?
> >
> > Is not the load_up_fpu() does mfmsr:
> >
> > _GLOBAL(load_up_fpu)
> > mfmsr r5
> > ori r5,r5,MSR_FP
> > #ifdef CONFIG_VSX
> > BEGIN_FTR_SECTION
> > oris r5,r5,MSR_VSX@h
> > END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> > #endif
> > SYNC
> > MTMSRD(r5) /* enable use of fpu now */
> > isync
> > <snip>
>=20
> Look further down...
>=20
> #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
>=20
> R12 is loaded with SRR1 in the exception prolog before load_up_fpu is cal=
led.
Yes it is SRR1 not MSR.
Also on 32bit it looks like that R9 is assumed to have SRR1.
-Bharat
> It's the MSR of the user process, not the current MSR.
>=20
> Mikey
^ permalink raw reply
* Re: BOOKE KVM calling load_up_fpu from C?
From: Michael Neuling @ 2013-02-12 3:46 UTC (permalink / raw)
To: Bhushan Bharat-R65777; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0659EC4A@039-SN2MPN1-023.039d.mgd.msft.net>
Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
>
>
> > -----Original Message-----
> > From: Linuxppc-dev [mailto:linuxppc-dev-
> > bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of Michael
> > Neuling
> > Sent: Tuesday, February 12, 2013 8:59 AM
> > To: Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: BOOKE KVM calling load_up_fpu from C?
> >
> > Scott,
> >
> > I was looking at changing how load_up_fpu works and I found this in
> > arch/powerpc/kvm/booke.h:
> >
> > static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu) { #ifdef
> > CONFIG_PPC_FPU
> > if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
> > load_up_fpu();
> > current->thread.regs->msr |= MSR_FP;
> > }
> > #endif
> > }
> >
> > I'm wondering how this is suppose to work since load_up_fpu is suppose to have
> > MSR in R12?
>
> Is not the load_up_fpu() does mfmsr:
>
> _GLOBAL(load_up_fpu)
> mfmsr r5
> ori r5,r5,MSR_FP
> #ifdef CONFIG_VSX
> BEGIN_FTR_SECTION
> oris r5,r5,MSR_VSX@h
> END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> #endif
> SYNC
> MTMSRD(r5) /* enable use of fpu now */
> isync
> <snip>
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. It's the MSR of the user process, not the current MSR.
Mikey
^ permalink raw reply
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-12 3:37 UTC (permalink / raw)
To: Michael Neuling, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <14306.1360639760@ale.ozlabs.ibm.com>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Mic=
hael
> Neuling
> Sent: Tuesday, February 12, 2013 8:59 AM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: BOOKE KVM calling load_up_fpu from C?
>=20
> Scott,
>=20
> I was looking at changing how load_up_fpu works and I found this in
> arch/powerpc/kvm/booke.h:
>=20
> static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu) { #ifdef
> CONFIG_PPC_FPU
> if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
> load_up_fpu();
> current->thread.regs->msr |=3D MSR_FP;
> }
> #endif
> }
>=20
> I'm wondering how this is suppose to work since load_up_fpu is suppose to=
have
> MSR in R12?
Is not the load_up_fpu() does mfmsr:
_GLOBAL(load_up_fpu)
mfmsr r5
ori r5,r5,MSR_FP
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r5,r5,MSR_VSX@h
END_FTR_SECTION_IFSET(CPU_FTR_VSX)
#endif
SYNC
MTMSRD(r5) /* enable use of fpu now */
isync
<snip>
-Bharat
>=20
> Mikey
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* BOOKE KVM calling load_up_fpu from C?
From: Michael Neuling @ 2013-02-12 3:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
Scott,
I was looking at changing how load_up_fpu works and I found this in
arch/powerpc/kvm/booke.h:
static inline void kvmppc_load_guest_fp(struct kvm_vcpu *vcpu)
{
#ifdef CONFIG_PPC_FPU
if (vcpu->fpu_active && !(current->thread.regs->msr & MSR_FP)) {
load_up_fpu();
current->thread.regs->msr |= MSR_FP;
}
#endif
}
I'm wondering how this is suppose to work since load_up_fpu is suppose
to have MSR in R12?
Mikey
^ permalink raw reply
* Re: Re[3]: PS3 platform is broken on Linux 3.7.0
From: Geoff Levand @ 2013-02-12 1:11 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Phileas Fogg, linuxppc-dev
In-Reply-To: <87zjzb4051.fsf@linux.vnet.ibm.com>
Hi Aneesh,
On Mon, 2013-02-11 at 15:56 +0530, Aneesh Kumar K.V wrote:
> Can you try this patch ?
>
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
I tried your patch on PS3 with a ps3_defconfig build on both Linux-3.7
and Linux-3.8-rc7 and it seems to be working OK.
Please try to prepare a final fix for v3.8 and also send to linux-stable
for v3.7.
Thanks!
-Geoff
^ permalink raw reply
* Re: [BUG] irq_dispose_mapping after irq request failure
From: Benjamin Herrenschmidt @ 2013-02-12 0:51 UTC (permalink / raw)
To: Grant Likely; +Cc: Baruch Siach, linuxppc-dev, linux-kernel
In-Reply-To: <20130211205255.72B513E3530@localhost>
On Mon, 2013-02-11 at 20:52 +0000, Grant Likely wrote:
> Really the irq mappings should be using reference counting. The existing
> code is naive on this count and just releases the irq on the first call
> to irq_dispose_mapping(). I've not gotten around to fixing that. Anyone
> want to take that task on?
Is this the best approach ?
The original idea was that there was no point disposing of mappings in most
cases and keeping the mapping around would provide a bit of stability of
interrupt numbers which might come in handy for debugging etc...
The few cases where disposing of a mapping might be useful is if the underlying
physical interrupts completely disappear, as in a cascaded controller gets
removed or that sort of thing, which is a very rare case... And even then...
Could you just make irq_dispose_mapping() check if the irq desc is
active and fail/WARN/BUG if it is ? I don't see the point of adding a refcount,
that feels overkill.
Cheers,
Ben.
^ 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