* 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 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
* [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: 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
* 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: 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
* [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
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