All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Qemu-devel] [PATCH] qxl: reset update_surface
From: Gerd Hoffmann @ 2011-10-24  7:08 UTC (permalink / raw)
  To: Alon Levy; +Cc: qemu-devel
In-Reply-To: <1319382232-23392-1-git-send-email-alevy@redhat.com>

On 10/23/11 17:03, Alon Levy wrote:
> update init_qxl_ram to reset update_surface to 0. This fixes one case
> of breakage when installing an old driver in a vm that had a new driver
> installed. The newer driver would know about surface creation and would
> change update_surface to !=0, then a reset would happen, all surfaces
> are destroyed, then the old driver is initialized and issues an
> UPDATE_AREA, and spice server aborts on invalid surface.

Patch added to spice patch queue.

thanks,
  Gerd

^ permalink raw reply

* Re: [PATCH] read-cache.c: fix index memory allocation
From: Junio C Hamano @ 2011-10-24  7:07 UTC (permalink / raw)
  To: René Scharfe; +Cc: Jeff King, John Hsing, Matthieu Moy, git
In-Reply-To: <4EA4B8E7.5070106@lsrfire.ath.cx>

Thanks.

This approach may be the most appropriate for the maintenance track, but
for the purpose of going forward, I wonder if we really want to keep the
"estimate and allocate a large pool, and carve out individual pieces".

This bulk-allocate dates back to the days when we didn't have ondisk vs
incore representation differences, IIRC, and as the result we deliberately
leak cache entries whenever an entry in the index is replaced with a new
one. Does the overhead to allocate individually really kill us that much
for say a tree with 30k files in it?

^ permalink raw reply

* Re: [PATCH net-next] ipv4: tcp: fix TOS value in ACK messages sent from TIME_WAIT
From: David Miller @ 2011-10-24  7:06 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, muralira, ak, hidden
In-Reply-To: <1319192965.2338.25.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 21 Oct 2011 12:29:25 +0200

> There is a long standing bug in linux tcp stack, about ACK messages sent
> on behalf of TIME_WAIT sockets.
> 
> In the IP header of the ACK message, we choose to reflect TOS field of
> incoming message, and this might break some setups.
> 
> Example of things that were broken :
>   - Routing using TOS as a selector
>   - Firewalls
>   - Trafic classification / shaping
> 
> We now remember in timewait structure the inet tos field and use it in
> ACK generation, and route lookup.
> 
> Notes :
>  - We still reflect incoming TOS in RST messages.
>  - We could extend MuraliRaja Muniraju patch to report TOS value in
> netlink messages for TIME_WAIT sockets.
>  - A patch is needed for IPv6
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied, thanks a lot Eric.

^ permalink raw reply

* Re: [PATCH] rtnetlink: Add missing manual netlink notification in dev_change_net_namespaces
From: David Miller @ 2011-10-24  7:03 UTC (permalink / raw)
  To: ebiederm; +Cc: netdev, kaber, equinox, renatowestphal
In-Reply-To: <m1ty72l3d7.fsf_-_@fess.ebiederm.org>

From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 21 Oct 2011 09:24:20 -0700

> Renato Westphal noticed that since commit a2835763e130c343ace5320c20d33c281e7097b7
> "rtnetlink: handle rtnl_link netlink notifications manually" was merged
> we no longer send a netlink message when a networking device is moved
> from one network namespace to another.
> 
> Fix this by adding the missing manual notification in dev_change_net_namespaces.
> 
> Since all network devices that are processed by dev_change_net_namspaces are
> in the initialized state the complicated tests that guard the manual
> rtmsg_ifinfo calls in rollback_registered and register_netdevice are
> unnecessary and we can just perform a plain notification.
> 
> Cc: stable@kernel.org
> Tested-by: Renato Westphal <renatowestphal@gmail.com>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

Applied, thanks Eric.

^ permalink raw reply

* Re: [RFC/PATCH 2/2] sparse: Use native sizes for data types
From: Pekka Enberg @ 2011-10-24  7:06 UTC (permalink / raw)
  To: Josh Triplett
  Cc: Jeff Garzik, linux-sparse, Christopher Li, Jeff Garzik,
	Linus Torvalds
In-Reply-To: <20111023171324.GA2940@leaf>

On Sun, Oct 23, 2011 at 8:13 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> On Sun, Oct 23, 2011 at 11:53:00AM -0400, Jeff Garzik wrote:
>> On 10/23/2011 08:37 AM, penberg@cs.helsinki.fi wrote:
>> >From: Pekka Enberg<penberg@kernel.org>
>> >
>> >This patch is needed to fix the sparsec LLVM backend data type sizes.
>> >
>> >Cc: Christopher Li<sparse@chrisli.org>
>> >Cc: Jeff Garzik<jgarzik@redhat.com>
>> >Cc: Linus Torvalds<torvalds@linux-foundation.org>
>> >Signed-off-by: Pekka Enberg<penberg@kernel.org>
>> >---
>> >  target.c |   10 +++++-----
>> >  1 files changed, 5 insertions(+), 5 deletions(-)
>> >
>> >diff --git a/target.c b/target.c
>> >index 6a535bc..009002f 100644
>> >--- a/target.c
>> >+++ b/target.c
>> >@@ -17,9 +17,9 @@ int max_alignment = 16;
>> >  int bits_in_bool = 8;
>> >  int bits_in_char = 8;
>> >  int bits_in_short = 16;
>> >-int bits_in_int = 32;
>> >-int bits_in_long = 32;
>> >-int bits_in_longlong = 64;
>> >+int bits_in_int = sizeof(int) * 8;
>> >+int bits_in_long = sizeof(long) * 8;
>> >+int bits_in_longlong = sizeof(long long) * 8;
>> >  int bits_in_longlonglong = 128;
>> >
>> >  int max_int_alignment = 4;
>> >@@ -36,8 +36,8 @@ int max_fp_alignment = 8;
>> >  /*
>> >   * Pointer data type
>> >   */
>> >-int bits_in_pointer = 32;
>> >-int pointer_alignment = 4;
>> >+int bits_in_pointer = sizeof(void *) * 8;
>> >+int pointer_alignment = sizeof(void *);
>>
>> No objection, but ideally we should select from a target template.
>>
>> We don't want to start down the road of making runtime target
>> switching (i386/x86-64) difficult.
>
> Agreed.  The platform that sparse checks code for should not necessarily
> correlate with what sparse observes at compile-time about the build
> platform.

Sure, I'm happy to implement this in some other way if you have an
idea how to do it cleanly. My patches don't make runtime switching
harder and I think using native data type sizes for plain sparse is a
better default.

                        Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3] powerpc: 85xx: separate e500 from e500mc
From: Baruch Siach @ 2011-10-24  6:00 UTC (permalink / raw)
  To: linuxppc-dev, Kumar Gala; +Cc: Scott Wood, Paul Gortmaker, Timur Tabi
In-Reply-To: <b965536bbd0457ab9614777dc00fc0dd22cf1d47.1312953203.git.baruch@tkos.co.il>

Hi Kumar,

On Wed, Aug 10, 2011 at 08:21:18AM +0300, Baruch Siach wrote:
> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
> breaking clear_pages(), probably others too.
> 
> This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems
> depend on PPC_E500_V1_V2.

Ping.
Any chance of merging this for 3.2?

baruch

> Cc: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> 
> Changes from v2:
> 
> 	* s/CONFIG_PPC_E500/CONFIG_PPC_E500_V1_V2/ to avoid confusion as
> 	  noted by Scott Wood
> 
> Changes from v1:
> 
> 	* Rebase on 3.1-rc1
> 
> 	* Remove the list of processor families from the PPC_E500 and 
> 	  PPC_E500MC options description. The P20xx can be either e500v2 or 
> 	  e500mc.
> 
>  arch/powerpc/platforms/85xx/Kconfig    |   13 +++++++++----
>  arch/powerpc/platforms/Kconfig.cputype |   27 +++++++++++++++------------
>  2 files changed, 24 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 498534c..00d4720 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -13,6 +13,8 @@ if FSL_SOC_BOOKE
>  
>  if PPC32
>  
> +if PPC_E500_V1_V2
> +
>  config MPC8540_ADS
>  	bool "Freescale MPC8540 ADS"
>  	select DEFAULT_UIMAGE
> @@ -171,10 +173,13 @@ config SBC8560
>  	help
>  	  This option enables support for the Wind River SBC8560 board
>  
> +endif # PPC_E500_V1_V2
> +
> +if PPC_E500MC
> +
>  config P2040_RDB
>  	bool "Freescale P2040 RDB"
>  	select DEFAULT_UIMAGE
> -	select PPC_E500MC
>  	select PHYS_64BIT
>  	select SWIOTLB
>  	select MPC8xxx_GPIO
> @@ -186,7 +191,6 @@ config P2040_RDB
>  config P3041_DS
>  	bool "Freescale P3041 DS"
>  	select DEFAULT_UIMAGE
> -	select PPC_E500MC
>  	select PHYS_64BIT
>  	select SWIOTLB
>  	select MPC8xxx_GPIO
> @@ -198,7 +202,6 @@ config P3041_DS
>  config P4080_DS
>  	bool "Freescale P4080 DS"
>  	select DEFAULT_UIMAGE
> -	select PPC_E500MC
>  	select PHYS_64BIT
>  	select SWIOTLB
>  	select MPC8xxx_GPIO
> @@ -207,13 +210,15 @@ config P4080_DS
>  	help
>  	  This option enables support for the P4080 DS board
>  
> +endif # PPC_E500MC
> +
>  endif # PPC32
>  
>  config P5020_DS
>  	bool "Freescale P5020 DS"
> +	depends on PPC_E500MC
>  	select DEFAULT_UIMAGE
>  	select E500
> -	select PPC_E500MC
>  	select PHYS_64BIT
>  	select SWIOTLB
>  	select MPC8xxx_GPIO
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index e06e395..e6cb00c 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -10,13 +10,13 @@ choice
>  	prompt "Processor Type"
>  	depends on PPC32
>  	help
> -	  There are five families of 32 bit PowerPC chips supported.
> +	  There are six families of 32 bit PowerPC chips supported.
>  	  The most common ones are the desktop and server CPUs (601, 603,
>  	  604, 740, 750, 74xx) CPUs from Freescale and IBM, with their
>  	  embedded 512x/52xx/82xx/83xx/86xx counterparts.
> -	  The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500
> -	  (85xx) each form a family of their own that is not compatible
> -	  with the others.
> +	  The other embeeded parts, namely 4xx, 8xx, e200 (55xx), e500
> +	  (85xx), and e500mc each form a family of their own that is not
> +	  compatible with the others.
>  
>  	  If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx.
>  
> @@ -24,10 +24,15 @@ config PPC_BOOK3S_32
>  	bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx"
>  	select PPC_FPU
>  
> -config PPC_85xx
> -	bool "Freescale 85xx"
> +config PPC_E500_V1_V2
> +	bool "Freescale e500v1/e500v2"
> +	select PPC_85xx
>  	select E500
>  
> +config PPC_E500MC
> +	bool "Freescale e500mc/e5500"
> +	select PPC_85xx
> +
>  config PPC_8xx
>  	bool "Freescale 8xx"
>  	select FSL_SOC
> @@ -128,15 +133,13 @@ config TUNE_CELL
>  config 8xx
>  	bool
>  
> -config E500
> +config PPC_85xx
> +	bool
>  	select FSL_EMB_PERFMON
>  	select PPC_FSL_BOOK3E
> -	bool
>  
> -config PPC_E500MC
> -	bool "e500mc Support"
> -	select PPC_FPU
> -	depends on E500
> +config E500
> +	bool
>  
>  config PPC_FPU
>  	bool
> -- 
> 1.7.5.4
> 

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

^ permalink raw reply

* Re: Vanilla-Kernel 3 - page allocation failure
From: Eric Dumazet @ 2011-10-24  7:03 UTC (permalink / raw)
  To: p.herz; +Cc: David Rientjes, Andi Kleen, linux-kernel
In-Reply-To: <4EA506B9.4030604@profihost.ag>

Le lundi 24 octobre 2011 à 08:33 +0200, Philipp Herz - Profihost AG a
écrit :
> Am 19.10.2011 03:58, schrieb David Rientjes:
> > On Tue, 18 Oct 2011, Andi Kleen wrote:
> >
> >> Philipp Herz - Profihost AG<p.herz@profihost.ag>  writes:
> >>
> >>> After updating kernel (x86_64) to stable version 3 there are a few
> >>> messages appearing in the kernel log such as
> >>>
> >>> kworker/0:1: page allocation failure: order:1, mode:0x20
> >>> mysql: page allocation failure: order:1, mode:0x20
> >>> php5: page allocation failure: order:1, mode:0x20
> >>
> >> You just ran out of memory.
> >>
> >
> > He ran out of order-1 physically contiguous memory and was unable to
> > compact or reclaim because of the atomic context.
> >
> > Philipp, based on your pastes from another post, it's evident you're using
> > CONFIG_SLAB and, unfortunately, it's not possible to change to single
> > page allocations (which would only result in a page allocation failure if
> > you were completely out of memory) without recompiling.
> >
> > You have a couple options:
> >
> >   - recompile with BREAK_GFP_ORDER_HI redefined to 0 in mm/slab.c, or
> >
> >   - recompile with CONFIG_SLUB instead of CONFIG_SLAB.
> >
> > It's very possible that neither of these will help, but it will tell you
> > whether you need to go out and buy more RAM or not.  If you try to
> > recompile with BREAK_GFP_ORDER_HI, these may turn into order-0
> > allocations.  If you can't reboot, send the output of
> > /proc/<pid>/net/protocols where<pid>  is the pid of one of the above tasks
> > (kworker, mysql, php5) when they are running and we'll know.
> >
> >   [ Changing slab_break_gfp_order should really be a CONFIG_SLAB command-
> >     line option.  It can't be runtime because slab depends on the order for
> >     caches remaining constant, but we can certainly change it on boot. ]
> >
> > If you try CONFIG_SLUB instead of CONFIG_SLAB, you can pass
> > slub_max_order=0 on the command line and see if it helps.
> 
> Hi David,
> 
> we have recompiled the kernel of one machine with CONFIG_SLUB instead of 
> CONFIG_SLAB, but it is showing similar message.
> 
> Now it's showing failure at "order:5, mode:0x4020".
> 
> Call trace can be found at:
> * http://pastebin.com/uGJiwvG1
> 
> Comparing kernel 2.6.32 (mm/page_alloc.c) there seams to be the same way 
> of dealing with page allocation.
> 
> Do you have an idea why these (warning) messages do never appear running 
> 2.6.32?

Your tg3 has a firmware limitation, and some skbs using fragments have
to be reallocated using a single and contiguous area of memory.

Initial skb delivered by tcp stack only uses order-0 pages, but the
reallocated one, being 64K, can be order-5

You can avoid this by following tuning :

ethtool -K eth0 sg off




^ permalink raw reply

* [U-Boot] [PATCH 7/7 v2] integrator: enable Vpp and disable flash protection
From: Linus Walleij @ 2011-10-24  7:02 UTC (permalink / raw)
  To: u-boot

This enables Vpp and disables the flash protection on the
Integrator when starting U-Boot. The integrator/AP has double
protection mechanisms: this one and the EBI protection bit
(patch earlier), the Integrator/CP has only one line of
protection in these registers.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Rebased to U-Boot ARM HEAD at Alberts request, see message
  4EA1C8E7.7090105 at aribaud.net
---
 board/armltd/integrator/integrator.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/board/armltd/integrator/integrator.c b/board/armltd/integrator/integrator.c
index dd83ca5..a507c09 100644
--- a/board/armltd/integrator/integrator.c
+++ b/board/armltd/integrator/integrator.c
@@ -37,6 +37,7 @@
 #include <netdev.h>
 #include <asm/io.h>
 #include "arm-ebi.h"
+#include "integrator-sc.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -76,7 +77,19 @@ extern void cm_remap(void);
 	cm_remap();	/* remaps writeable memory to 0x00000000 */
 #endif
 
+#ifdef CONFIG_ARCH_CINTEGRATOR
 	/*
+	 * Flash protection on the Integrator/CP is in a simple register
+	 */
+	val = readl(CP_FLASHPROG);
+	val |= (CP_FLASHPROG_FLVPPEN | CP_FLASHPROG_FLWREN);
+	writel(val, CP_FLASHPROG);
+#else
+	/*
+	 * The Integrator/AP has some special protection mechanisms
+	 * for the external memories, first the External Bus Interface (EBI)
+	 * then the system controller (SC).
+	 *
 	 * The system comes up with the flash memory non-writable and
 	 * configuration locked. If we want U-Boot to be used for flash
 	 * access we cannot have the flash memory locked.
@@ -88,6 +101,13 @@ extern void cm_remap(void);
 	writel(val, EBI_BASE + EBI_CSR1_REG);
 	writel(0, EBI_BASE + EBI_LOCK_REG);
 
+	/*
+	 * Set up the system controller to remove write protection from
+	 * the flash memory and enable Vpp
+	 */
+	writel(SC_CTRL_FLASHVPP | SC_CTRL_FLASHWP, SC_CTRLS);
+#endif
+
 	icache_enable ();
 
 	return 0;
-- 
1.7.6.4

^ permalink raw reply related

* [U-Boot] [PATCH 6/7 v2] integrator: add system controller header
From: Linus Walleij @ 2011-10-24  7:02 UTC (permalink / raw)
  To: u-boot

Break out the AP system controller and CP "CP controller"
registers into a header file, it gives better overview than
hardcoding its values and other disturbing practices.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Rebased to U-Boot ARM HEAD at Alberts request, see message
  4EA1C8E7.7090105 at aribaud.net
---
 board/armltd/integrator/integrator-sc.h |   91 +++++++++++++++++++++++++++++++
 1 files changed, 91 insertions(+), 0 deletions(-)
 create mode 100644 board/armltd/integrator/integrator-sc.h

diff --git a/board/armltd/integrator/integrator-sc.h b/board/armltd/integrator/integrator-sc.h
new file mode 100644
index 0000000..279dc55
--- /dev/null
+++ b/board/armltd/integrator/integrator-sc.h
@@ -0,0 +1,91 @@
+/*
+ * (C) Copyright 2011
+ * Linaro
+ * Linus Walleij <linus.walleij@linaro.org>
+ * Register definitions for the System Controller (SC) and
+ * the similar "CP Controller" found in the ARM Integrator/AP and
+ * Integrator/CP reference designs
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __ARM_SC_H
+#define __ARM_SC_H
+
+#define SC_BASE			0x11000000
+
+/*
+ * The system controller registers
+ */
+#define SC_ID_OFFSET		0x00
+#define SC_OSC_OFFSET		0x04
+/* Setting this bit switches to 25 MHz mode, clear means 33 MHz */
+#define SC_OSC_DIVXY		(1 << 8)
+#define SC_CTRLS_OFFSET		0x08
+#define SC_CTRLC_OFFSET		0x0C
+/* Set bits by writing CTRLS, clear bits by writing CTRLC */
+#define SC_CTRL_SOFTRESET	(1 << 0)
+#define SC_CTRL_FLASHVPP	(1 << 1)
+#define SC_CTRL_FLASHWP		(1 << 2)
+#define SC_CTRL_UART1DTR	(1 << 4)
+#define SC_CTRL_UART1RTS	(1 << 5)
+#define SC_CTRL_UART0DTR	(1 << 6)
+#define SC_CTRL_UART0RTS	(1 << 7)
+#define SC_DEC_OFFSET		0x10
+#define SC_ARB_OFFSET		0x14
+#define SC_PCI_OFFSET		0x18
+#define SC_PCI_PCIEN		(1 << 0)
+#define SC_PCI_PCIBINT_CLR	(1 << 1)
+#define SC_LOCK_OFFSET		0x1C
+#define SC_LBFADDR_OFFSET	0x20
+#define SC_LBFCODE_OFFSET	0x24
+
+#define SC_ID (SC_BASE + SC_ID_OFFSET)
+#define SC_OSC (SC_BASE + SC_OSC_OFFSET)
+#define SC_CTRLS (SC_BASE + SC_CTRLS_OFFSET)
+#define SC_CTRLC (SC_BASE + SC_CTRLC_OFFSET)
+#define SC_DEC (SC_BASE + SC_DEC_OFFSET)
+#define SC_ARB (SC_BASE + SC_ARB_OFFSET)
+#define SC_PCI (SC_BASE + SC_PCI_OFFSET)
+#define SC_LOCK (SC_BASE + SC_LOCK_OFFSET)
+#define SC_LBFADDR (SC_BASE + SC_LBFADDR_OFFSET)
+#define SC_LBFCODE (SC_BASE + SC_LBFCODE_OFFSET)
+
+/*
+ * The Integrator/CP as a smaller set of registers,@a different
+ * offset - probably not to disturb old software.
+ */
+
+#define CP_BASE			0xCB000000
+
+#define CP_IDFIELD_OFFSET	0x00
+#define CP_FLASHPROG_OFFSET	0x04
+#define CP_FLASHPROG_FLVPPEN	(1 << 0)
+#define CP_FLASHPROG_FLWREN	(1 << 1)
+#define CP_FLASHPROG_FLASHSIZE	(1 << 2)
+#define CP_FLASHPROG_EXTRABANK	(1 << 3)
+#define CP_INTREG_OFFSET	0x08
+#define CP_DECODE_OFFSET	0x0C
+
+#define CP_IDFIELD (CP_BASE + CP_ID_OFFSET)
+#define CP_FLASHPROG (CP_BASE + CP_FLASHPROG_OFFSET)
+#define CP_INTREG (CP_BASE + CP_INTREG_OFFSET)
+#define CP_DECODE (CP_BASE + CP_DECODE_OFFSET)
+
+#endif
-- 
1.7.6.4

^ permalink raw reply related

* [U-Boot] [PATCH 5/7 v3] integrator: make flash writeable on boot
From: Linus Walleij @ 2011-10-24  7:02 UTC (permalink / raw)
  To: u-boot

This reconfigures the EBI (External Bus Interface) on the
integrator so that chip select 1, handling the flash memory, is
set to writeable. Without this it is not possible for U-Boot to
access flash memory and it crashes on startup since CFI won't
work properly.

Since this is the first time we use the EBI, we create a header
file for its registers.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Moved the arm-ebi.h file from the global include/ dir to the
  board/armltd/integrator/ dir since it's only needed by
  the Integrator.
ChangeLog v2->v3:
- Rebased to U-Boot ARM HEAD at Alberts request, see message
  4EA1C8E7.7090105 at aribaud.net
---
 board/armltd/integrator/arm-ebi.h    |   62 ++++++++++++++++++++++++++++++++++
 board/armltd/integrator/integrator.c |   15 ++++++++
 2 files changed, 77 insertions(+), 0 deletions(-)
 create mode 100644 board/armltd/integrator/arm-ebi.h

diff --git a/board/armltd/integrator/arm-ebi.h b/board/armltd/integrator/arm-ebi.h
new file mode 100644
index 0000000..2d85e3f
--- /dev/null
+++ b/board/armltd/integrator/arm-ebi.h
@@ -0,0 +1,62 @@
+/*
+ * (C) Copyright 2011
+ * Linaro
+ * Linus Walleij <linus.walleij@linaro.org>
+ * Register definitions for the External Bus Interface (EBI)
+ * found in the ARM Integrator AP and CP reference designs
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __ARM_EBI_H
+#define __ARM_EBI_H
+
+#define EBI_BASE		0x12000000
+
+#define EBI_CSR0_REG		0x00 /* CS0 = Boot ROM */
+#define EBI_CSR1_REG		0x04 /* CS1 = Flash */
+#define EBI_CSR2_REG		0x08 /* CS2 = SSRAM */
+#define EBI_CSR3_REG		0x0C /* CS3 = Expansion memory */
+/*
+ * The four upper bits are the waitstates for each chip select
+ * 0x00 = 2 cycles, 0x10 = 3 cycles, ... 0xe0 = 16 cycles, 0xf0 = 16 cycles
+ */
+#define EBI_CSR_WAIT_MASK	0xF0
+/* Whether memory is synchronous or asynchronous */
+#define EBI_CSR_SYNC_MASK	0xF7
+#define EBI_CSR_ASYNC		0x00
+#define EBI_CSR_SYNC		0x08
+/* Whether memory is write enabled or not */
+#define EBI_CSR_WREN_MASK	0xFB
+#define EBI_CSR_WREN_DISABLE	0x00
+#define EBI_CSR_WREN_ENABLE	0x04
+/* Memory bit width for each chip select */
+#define EBI_CSR_MEMSIZE_MASK	0xFC
+#define EBI_CSR_MEMSIZE_8BIT	0x00
+#define EBI_CSR_MEMSIZE_16BIT	0x01
+#define EBI_CSR_MEMSIZE_32BIT	0x02
+
+/*
+ * The lock register need to be written with 0xa05f before anything in the
+ * EBI can be changed.
+ */
+#define EBI_LOCK_REG		0x20
+#define EBI_UNLOCK_MAGIC	0xA05F
+
+#endif
diff --git a/board/armltd/integrator/integrator.c b/board/armltd/integrator/integrator.c
index 780218c..dd83ca5 100644
--- a/board/armltd/integrator/integrator.c
+++ b/board/armltd/integrator/integrator.c
@@ -36,6 +36,7 @@
 #include <common.h>
 #include <netdev.h>
 #include <asm/io.h>
+#include "arm-ebi.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -56,6 +57,8 @@ void show_boot_progress(int progress)
 
 int board_init (void)
 {
+	u32 val;
+
 	/* arch number of Integrator Board */
 #ifdef CONFIG_ARCH_CINTEGRATOR
 	gd->bd->bi_arch_number = MACH_TYPE_CINTEGRATOR;
@@ -73,6 +76,18 @@ extern void cm_remap(void);
 	cm_remap();	/* remaps writeable memory to 0x00000000 */
 #endif
 
+	/*
+	 * The system comes up with the flash memory non-writable and
+	 * configuration locked. If we want U-Boot to be used for flash
+	 * access we cannot have the flash memory locked.
+	 */
+	writel(EBI_UNLOCK_MAGIC, EBI_BASE + EBI_LOCK_REG);
+	val = readl(EBI_BASE + EBI_CSR1_REG);
+	val &= EBI_CSR_WREN_MASK;
+	val |= EBI_CSR_WREN_ENABLE;
+	writel(val, EBI_BASE + EBI_CSR1_REG);
+	writel(0, EBI_BASE + EBI_LOCK_REG);
+
 	icache_enable ();
 
 	return 0;
-- 
1.7.6.4

^ permalink raw reply related

* [U-Boot] [PATCH 4/7 v2] integrator: use io-accessors for board init
From: Linus Walleij @ 2011-10-24  7:02 UTC (permalink / raw)
  To: u-boot

Casting around to *(volatile ulong *) doesn't look good, so include
the <asm/io.h> macros and use good old readl() instead.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Rebased to U-Boot ARM HEAD at Alberts request, see message
  4EA1C8E7.7090105 at aribaud.net
---
 board/armltd/integrator/integrator.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/board/armltd/integrator/integrator.c b/board/armltd/integrator/integrator.c
index 83f047c..780218c 100644
--- a/board/armltd/integrator/integrator.c
+++ b/board/armltd/integrator/integrator.c
@@ -35,6 +35,7 @@
 
 #include <common.h>
 #include <netdev.h>
+#include <asm/io.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -101,15 +102,15 @@ int dram_init (void)
 #ifdef CONFIG_CM_SPD_DETECT
 	{
 extern void dram_query(void);
-	unsigned long cm_reg_sdram;
-	unsigned long sdram_shift;
+	u32 cm_reg_sdram;
+	u32 sdram_shift;
 
 	dram_query();	/* Assembler accesses to CM registers */
 			/* Queries the SPD values	      */
 
 	/* Obtain the SDRAM size from the CM SDRAM register */
 
-	cm_reg_sdram = *(volatile ulong *)(CM_BASE + OS_SDRAM);
+	cm_reg_sdram = readl(CM_BASE + OS_SDRAM);
 	/*   Register	      SDRAM size
 	 *
 	 *   0xXXXXXXbbb000bb	 16 MB
@@ -119,7 +120,7 @@ extern void dram_query(void);
 	 *   0xXXXXXXbbb100bb	256 MB
 	 *
 	 */
-	sdram_shift		 = ((cm_reg_sdram & 0x0000001C)/4)%4;
+	sdram_shift = ((cm_reg_sdram & 0x0000001C)/4)%4;
 	gd->ram_size = get_ram_size((long *) CONFIG_SYS_SDRAM_BASE +
 				    REMAPPED_FLASH_SZ,
 				    0x01000000 << sdram_shift);
-- 
1.7.6.4

^ permalink raw reply related

* Re: [PATCH] ipv4: fix ipsec forward performance regression
From: David Miller @ 2011-10-24  7:02 UTC (permalink / raw)
  To: eric.dumazet; +Cc: zheng.z.yan, netdev, kim.phillips
In-Reply-To: <1319360590.6180.75.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 23 Oct 2011 11:03:10 +0200

> Le dimanche 23 octobre 2011 à 15:58 +0800, Yan, Zheng a écrit :
>> There is bug in commit 5e2b61f(ipv4: Remove flowi from struct rtable).
>> It makes xfrm4_fill_dst() modify wrong data structure.
>> 
>> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
 ...
> Reported-by: Kim Phillips <kim.phillips@freescale.com>
> 
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied, thanks everyone.

^ permalink raw reply

* [U-Boot] [PATCH 3/7 v2] integrator: do not test first part of the memory
From: Linus Walleij @ 2011-10-24  7:02 UTC (permalink / raw)
  To: u-boot

When booting from Flash, the Integrator remaps its flash memory
from 0x24000000 to 0x00000000, and starts executing it at
0x00000000. This ROM thus hides the RAM underneath and first
0x40000 bytes of the memory cannot be tested by get_ram_size().
So let's test from 0x40000 to the end of detected memory
instead.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Rebased to U-Boot ARM HEAD at Alberts request, see message
  4EA1C8E7.7090105 at aribaud.net
---
 board/armltd/integrator/integrator.c |   19 +++++++++++++++----
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/board/armltd/integrator/integrator.c b/board/armltd/integrator/integrator.c
index c8d2bc7..83f047c 100644
--- a/board/armltd/integrator/integrator.c
+++ b/board/armltd/integrator/integrator.c
@@ -86,6 +86,15 @@ int misc_init_r (void)
 	return (0);
 }
 
+/*
+ * The Integrator remaps the Flash memory to 0x00000000 and executes U-Boot
+ * from there, which means we cannot test the RAM underneath the ROM at this
+ * point. It will be unmapped later on, when we are executing from the
+ * relocated in RAM U-Boot. We simply assume that this RAM is usable if the
+ * RAM on higher addresses works fine.
+ */
+#define REMAPPED_FLASH_SZ 0x40000
+
 int dram_init (void)
 {
 	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
@@ -111,15 +120,17 @@ extern void dram_query(void);
 	 *
 	 */
 	sdram_shift		 = ((cm_reg_sdram & 0x0000001C)/4)%4;
-	gd->bd->bi_dram[0].size	 = 0x01000000 << sdram_shift;
-	gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
+	gd->ram_size = get_ram_size((long *) CONFIG_SYS_SDRAM_BASE +
+				    REMAPPED_FLASH_SZ,
 				    0x01000000 << sdram_shift);
 	}
 #else
-	gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
-	gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
+	gd->ram_size = get_ram_size((long *) CONFIG_SYS_SDRAM_BASE +
+				    REMAPPED_FLASH_SZ,
 				    PHYS_SDRAM_1_SIZE);
 #endif /* CM_SPD_DETECT */
+	/* We only have one bank of RAM, set it to whatever was detected */
+	gd->bd->bi_dram[0].size	 = gd->ram_size;
 
 	return 0;
 }
-- 
1.7.6.4

^ permalink raw reply related

* Re: [PATCH] ipv4: fix ipsec forward performance regression
From: David Miller @ 2011-10-24  7:01 UTC (permalink / raw)
  To: zheng.z.yan; +Cc: ja, netdev, eric.dumazet, kim.phillips
In-Reply-To: <4EA4B451.7010708@intel.com>

From: "Yan, Zheng" <zheng.z.yan@intel.com>
Date: Mon, 24 Oct 2011 08:41:53 +0800

> My understanding is that xfrm_dst(s) are managed by the flow cache
> (net/core/flow.c). We don't put them into the routing cache.

This is correct.

^ permalink raw reply

* [U-Boot] [PATCH 2/7 v2] integrator: move text offset to config
From: Linus Walleij @ 2011-10-24  7:01 UTC (permalink / raw)
  To: u-boot

Do away with the config.mk file and move the text offset to the
config files to make things easier.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Rebased to U-Boot ARM HEAD at Alberts request, see message
  4EA1C8E7.7090105 at aribaud.net
---
 board/armltd/integrator/config.mk |    5 -----
 include/configs/integratorap.h    |    1 +
 include/configs/integratorcp.h    |    1 +
 3 files changed, 2 insertions(+), 5 deletions(-)
 delete mode 100644 board/armltd/integrator/config.mk

diff --git a/board/armltd/integrator/config.mk b/board/armltd/integrator/config.mk
deleted file mode 100644
index 8b57af1..0000000
--- a/board/armltd/integrator/config.mk
+++ /dev/null
@@ -1,5 +0,0 @@
-#
-# image should be loaded at 0x01000000
-#
-
-CONFIG_SYS_TEXT_BASE = 0x01000000
diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h
index 61b8761..a1fdbb8 100644
--- a/include/configs/integratorap.h
+++ b/include/configs/integratorap.h
@@ -37,6 +37,7 @@
  * High Level Configuration Options
  * (easy to change)
  */
+#define CONFIG_SYS_TEXT_BASE		0x01000000
 #define CONFIG_SYS_MEMTEST_START	0x100000
 #define CONFIG_SYS_MEMTEST_END		0x10000000
 #define CONFIG_SYS_HZ			1000
diff --git a/include/configs/integratorcp.h b/include/configs/integratorcp.h
index 7ae34b7..ccbdf44 100644
--- a/include/configs/integratorcp.h
+++ b/include/configs/integratorcp.h
@@ -37,6 +37,7 @@
  * High Level Configuration Options
  * (easy to change)
  */
+#define CONFIG_SYS_TEXT_BASE		0x01000000
 #define CONFIG_SYS_MEMTEST_START	0x100000
 #define CONFIG_SYS_MEMTEST_END		0x10000000
 #define CONFIG_SYS_HZ			1000
-- 
1.7.6.4

^ permalink raw reply related

* Re: [meta-oe][PATCH 0/5] SystemD fixes and improvements
From: Koen Kooi @ 2011-10-24  6:55 UTC (permalink / raw)
  To: openembedded-devel
In-Reply-To: <cover.1319205291.git.otavio@ossystems.com.br>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 21-10-11 15:55, Otavio Salvador schreef:
> The following changes since commit
> 36423031ae2cc2157232f3bec8f5c9fa53ef215d:
> 
> Cloud9: incremental submodule and build fixes (2011-10-21 14:57:30
> +0200)
> 
> are available in the git repository at: 
> git://github.com/OSSystems/meta-oe master 
> https://github.com/OSSystems/meta-oe/tree/master
> 
> Otavio Salvador (5): systemd-serialgetty: don't require systemd_git.bb 
> systemd: add systemd-initramfs

These 2 have been merged

> systemd: add lock group using useradd.bbclass

This one is waiting for the matching useradd fix to go in to oe-core

> systemd: do not recommend systemd-serialgetty task-basic: add
> "serial-console" machine feature

I'd like some more feedback on this from the oe-core people, since we're
adding a new MACHINE/DISTRO/IMAGE_FEATURE.

I'll be at ELC-E in Prague this week with other OE developers, so the
patchflow will slow down.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFOpQvqMkyGM64RGpERAmCzAKCancsMz7U/YndZn2Gc2WLzJHnVxACfcbBk
tb1bywVIb3azG5MC90B9PX0=
=licP
-----END PGP SIGNATURE-----




^ permalink raw reply

* [U-Boot] [PATCH 1/7 v2] integrator: pass configs for core modules
From: Linus Walleij @ 2011-10-24  7:01 UTC (permalink / raw)
  To: u-boot

Alter the board.cfg to pass core module configuration flags
so we can make compile-time switches for different core
modules. These are already in use for some low-level code,
they just got lost in the conversion to the new build
system.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Rebased to U-Boot ARM HEAD at Alberts request, see message
  4EA1C8E7.7090105 at aribaud.net
---
 boards.cfg |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index 4162172..721e89c 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -35,7 +35,7 @@
 # Target                     ARCH        CPU         Board name          Vendor	        SoC         Options
 ###########################################################################################################
 
-integratorcp_cm1136          arm         arm1136     integrator          armltd         -           integratorcp
+integratorcp_cm1136          arm         arm1136     integrator          armltd         -           integratorcp:CM1136
 qong                         arm         arm1136     -                   davedenx       mx31
 mx31ads                      arm         arm1136     -                   freescale      mx31
 imx31_litekit                arm         arm1136     -                   logicpd        mx31
@@ -45,9 +45,9 @@ mx31pdk                      arm         arm1136     -                   freesca
 mx35pdk                      arm         arm1136     -                   freescale      mx35
 omap2420h4                   arm         arm1136     -                   ti             omap24xx
 tnetv107x_evm                arm         arm1176     tnetv107xevm        ti             tnetv107x
-integratorap_cm720t          arm         arm720t     integrator          armltd         -           integratorap
-integratorap_cm920t          arm         arm920t     integrator          armltd         -           integratorap
-integratorcp_cm920t          arm         arm920t     integrator          armltd         -           integratorcp
+integratorap_cm720t          arm         arm720t     integrator          armltd         -           integratorap:CM720T
+integratorap_cm920t          arm         arm920t     integrator          armltd         -           integratorap:CM920T
+integratorcp_cm920t          arm         arm920t     integrator          armltd         -           integratorcp:CM920T
 a320evb                      arm         arm920t     -                   faraday        a320
 at91rm9200ek                 arm         arm920t     at91rm9200ek        atmel          at91        at91rm9200ek
 at91rm9200ek_ram             arm         arm920t     at91rm9200ek        atmel          at91        at91rm9200ek:RAMBOOT
@@ -61,8 +61,8 @@ cm41xx                       arm         arm920t     -                   -
 VCMA9                        arm         arm920t     vcma9               mpl            s3c24x0
 smdk2410                     arm         arm920t     -                   samsung        s3c24x0
 omap1510inn                  arm         arm925t     -                   ti
-integratorap_cm926ejs        arm         arm926ejs   integrator          armltd         -           integratorap
-integratorcp_cm926ejs        arm         arm926ejs   integrator          armltd         -           integratorcp
+integratorap_cm926ejs        arm         arm926ejs   integrator          armltd         -           integratorap:CM926EJ_S
+integratorcp_cm926ejs        arm         arm926ejs   integrator          armltd         -           integratorcp:CM924EJ_S
 versatileqemu                arm         arm926ejs   versatile           armltd         versatile   versatile:ARCH_VERSATILE_QEMU,ARCH_VERSATILE_PB
 versatilepb                  arm         arm926ejs   versatile           armltd         versatile   versatile:ARCH_VERSATILE_PB
 versatileab                  arm         arm926ejs   versatile           armltd         versatile   versatile:ARCH_VERSATILE_AB
@@ -158,8 +158,8 @@ nhk8815_onenand              arm         arm926ejs   nhk8815             st
 omap5912osk                  arm         arm926ejs   -                   ti             omap
 edminiv2                     arm         arm926ejs   -                   LaCie          orion5x
 dkb			     arm         arm926ejs   -                   Marvell        pantheon
-integratorap_cm946es         arm         arm946es    integrator          armltd         -               integratorap
-integratorcp_cm946es         arm         arm946es    integrator          armltd         -               integratorcp
+integratorap_cm946es         arm         arm946es    integrator          armltd         -               integratorap:CM946ES
+integratorcp_cm946es         arm         arm946es    integrator          armltd         -               integratorcp:CM946ES
 ca9x4_ct_vxp                 arm         armv7       vexpress            armltd
 am335x_evm                   arm         armv7       am335x              ti             am33xx
 efikamx                      arm         armv7       efikamx             -              mx5		efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKAMX,IMX_CONFIG=board/efikamx/imximage_mx.cfg
-- 
1.7.6.4

^ permalink raw reply related

* RE: UBIFS recovery fails
From: Ricard Wanderlof @ 2011-10-24  7:00 UTC (permalink / raw)
  To: Artem Bityutskiy
  Cc: Ivan Djelic, linux-mtd@lists.infradead.org,
	Jean-Sébastien Gagnon
In-Reply-To: <1319129028.20953.26.camel@sauron>


On Thu, 20 Oct 2011, Artem Bityutskiy wrote:

>> The real problem appears when those faulty bits are unstable: during 
>> the first few read attempts, the page may be successfully read 
>> (possibly with ecc corrections); and then, a bit later, the page 
>> becomes unreadable because of too many faulty bits.
>
> Right. If you first get a correctable bit-flip, UBI will schedule this
> PEB for scrubbing. When the background thread starts scrubbing, it will
> read the PEB _again_, and this time it can end up with an uncorrectable
> ECC error.
>
> This is probably also a good point: when UBIFS recovers, it should
> probably somehow ask UBI to _not_ do scrubbing, to avoid failures at UBI
> level if UBI decides to scrub a PEB before UBIFS erase-cycles it.
>
> IOW, the whole stack (not only UBIFS) should make sure the PEBs with
> unstable bits are read only once.

How would UBI+ubifs compare to jffs2 in this respect? I would naïvely 
assume that since jffs2 doesn't do any scrubbing, it would just return ok 
if the data happened to be read correctly that time, and something like an 
I/O error if the data was faulty, but without taking any special action in 
that case?

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

^ permalink raw reply

* Re: Use of _hint() functions and older machines
From: Raymond Yau @ 2011-10-24  7:00 UTC (permalink / raw)
  To: ALSA Development Mailing List
In-Reply-To: <4EA4F573.9060704@jesup.org>

2011/10/24 Randell Jesup <randell1@jesup.org>:
> On 10/23/2011 6:36 AM, Clemens Ladisch wrote:
>> On 10/21/2011 05:28 AM, Randell Jesup wrote:
>>> On older machines, _hint() aren't available, so even if I make them
>>> optional to dlsym-loading, I would need some other method to get the
>>> information I assume using older, now-deprecated-or-gone interfaces.
>>
>> On older machines, that information wasn't available at all.
>>
>> The recommendation was to use "default" or to let the user enter
>> a device name.
>
> Ah.  Ok.  Wow, was it really that painful?  I didn't do a lot of Linux
> media stuff back then, and generally had only built-in-audio (no USB
> headsets, etc) with simple speakers.

Those rack servers which are running 7x24 non-stop inside data center,
does not have any on-board audio,

^ permalink raw reply

* [U-Boot] [PATCH] arch/arm/lib/board.c: fix build error
From: Heiko Schocher @ 2011-10-24  7:00 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1319406671-6360-1-git-send-email-wd@denx.de>

Hello Wolfgang,

Wolfgang Denk wrote:
> Commit dc8bbea "arm: Use getenv_ulong() in place of getenv(), strtoul"
> introduced a build error for all ARM boards with network support:
> 
> board.c: In function 'board_init_r':
> board.c:569: error: 's' undeclared (first use in this function)
> board.c:569: error: (Each undeclared identifier is reported only once
> board.c:569: error: for each function it appears in.)
> 
> Fix it.
> 
> Signed-off-by: Wolfgang Denk <wd@denx.de>

posted a patch too, see your fix too late, sorry, so
forget my patch:

Acked-by: Heiko Schocher <hs@denx.de>

for this.

Thanks for fixing.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

^ permalink raw reply

* [RFC PATCH 08/15] ARM: uncompress: Rename misc.c to print.c
From: Uwe Kleine-König @ 2011-10-24  6:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319404245-12740-8-git-send-email-zoss@devai.org>

On Sun, Oct 23, 2011 at 11:10:38PM +0200, Zoltan Devai wrote:
> Now that misc.c only holds functions related to printout
> during decompression, rename it accordingly.
> 
> Signed-off-by: Zoltan Devai <zoss@devai.org>
> ---
>  arch/arm/boot/compressed/Makefile |    2 +-
>  arch/arm/boot/compressed/misc.c   |  122 -------------------------------------
>  arch/arm/boot/compressed/print.c  |  122 +++++++++++++++++++++++++++++++++++++
If you add -M to git-format-patch this gets much easier to review.

>  3 files changed, 123 insertions(+), 123 deletions(-)
>  delete mode 100644 arch/arm/boot/compressed/misc.c
>  create mode 100644 arch/arm/boot/compressed/print.c
> 
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index e4f32a8..d955d4f 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -23,7 +23,7 @@ endif
>  
>  AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
>  HEAD	= head.o
> -OBJS	+= misc.o decompress.o
> +OBJS	+= print.o decompress.o
>  FONTC	= $(srctree)/drivers/video/console/font_acorn_8x8.c
>  
>  # string library code (-Os is enforced to keep it much smaller)
> [...]
> diff --git a/arch/arm/boot/compressed/print.c b/arch/arm/boot/compressed/print.c
> new file mode 100644
> index 0000000..25f0fb2
> --- /dev/null
> +++ b/arch/arm/boot/compressed/print.c
> @@ -0,0 +1,122 @@
> +/*
> + * misc.c
This is wrong.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* Re: [PATCH] jme: fix irq storm after suspend/resume
From: David Miller @ 2011-10-24  6:58 UTC (permalink / raw)
  To: grawity; +Cc: linux-kernel, netdev
In-Reply-To: <j7uqst$kpc$1@dough.gmane.org>

From: "Mantas M." <grawity@gmail.com>
Date: Sat, 22 Oct 2011 19:27:09 +0300

> On 22/10/11 15:56, Clemens Buchacher wrote:
>> If the device is down during suspend/resume, interrupts are enabled
>> without a registered interrupt handler, causing a storm of
>> unhandled interrupts until the IRQ is disabled because "nobody
>> cared".
>>
>> Instead, check that the device is up before touching it in the
>> suspend/resume code.
>>
>> Fixes https://bugzilla.kernel.org/show_bug.cgi?id=39112
> 
> Just tested the patch, suspend/resume works well.

Applied, thanks.

^ permalink raw reply

* [PATCH Resend] arm: at91: fix NAND bus width decoding from system_rev
From: Christian Hitz @ 2011-10-24  6:57 UTC (permalink / raw)
  To: linux-arm-kernel

Make it safe to assign the return value of this function
to u8/u16 variables.

Signed-off-by: Christian Hitz <christian.hitz@aizo.com>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
---
  arch/arm/mach-at91/include/mach/system_rev.h |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-at91/include/mach/system_rev.h 
b/arch/arm/mach-at91/include/mach/system_rev.h
index 8f48660..ec164a4 100644
--- a/arch/arm/mach-at91/include/mach/system_rev.h
+++ b/arch/arm/mach-at91/include/mach/system_rev.h
@@ -19,7 +19,7 @@
  #define BOARD_HAVE_NAND_16BIT	(1 << 31)
  static inline int board_have_nand_16bit(void)
  {
-	return system_rev & BOARD_HAVE_NAND_16BIT;
+	return (system_rev & BOARD_HAVE_NAND_16BIT) ? 1 : 0;
  }
   #endif /* __ARCH_SYSTEM_REV_H__ */
-- 
1.7.4.1

^ permalink raw reply related

* Re: [PATCH v2 2/3] dp83640: use proper function to free transmit time stamping packets
From: David Miller @ 2011-10-24  6:55 UTC (permalink / raw)
  To: richardcochran; +Cc: netdev, eric.dumazet, johannes, stable
In-Reply-To: <966b346f5f73c0afc48f89686e9ed1f44457074b.1319193734.git.richard.cochran@omicron.at>

From: Richard Cochran <richardcochran@gmail.com>
Date: Fri, 21 Oct 2011 12:49:16 +0200

> The previous commit enforces a new rule for handling the cloned packets
> for transmit time stamping. These packets must not be freed using any other
> function than skb_complete_tx_timestamp. This commit fixes the one and only
> driver using this API.
> 
> The driver first appeared in v3.0.
> 
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: <stable@vger.kernel.org>

In the 'net' tree, which is where you should be targetting these dp83640
driver patches, the code looks nothing like what you're patching against.

Please respin patches #2 and #3 against current sources.

^ permalink raw reply

* Re: [PATCH net-next v3] route: fix ICMP redirect validation
From: David Miller @ 2011-10-24  6:56 UTC (permalink / raw)
  To: fbl; +Cc: netdev
In-Reply-To: <1319215448-6777-1-git-send-email-fbl@redhat.com>

From: Flavio Leitner <fbl@redhat.com>
Date: Fri, 21 Oct 2011 14:44:08 -0200

> The commit f39925dbde7788cfb96419c0f092b086aa325c0f
> (ipv4: Cache learned redirect information in inetpeer.)
> removed some ICMP packet validations which are required by
> RFC 1122, section 3.2.2.2:
> ...
>   A Redirect message SHOULD be silently discarded if the new
>   gateway address it specifies is not on the same connected
>   (sub-) net through which the Redirect arrived [INTRO:2,
>   Appendix A], or if the source of the Redirect is not the
>   current first-hop gateway for the specified destination (see
>   Section 3.3.1).
> 
> Signed-off-by: Flavio Leitner <fbl@redhat.com>

Applied, thanks.

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.