* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code
From: Marek Vasut @ 2011-10-22 1:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA21152.60901@aribaud.net>
On Saturday, October 22, 2011 02:41:54 AM Albert ARIBAUD wrote:
> Le 22/10/2011 02:19, Marek Vasut a ?crit :
> > On Saturday, October 22, 2011 02:04:52 AM Tom Rini wrote:
> >> On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasut<marek.vasut@gmail.com> wrote:
> >>> On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
> >>>> Le 22/10/2011 00:46, Marek Vasut a ?crit :
> >>>>> On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
> >>>>>> Le 22/10/2011 00:00, Marek Vasut a ?crit :
> >>>>>>> On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
> >>>>>>>> Hi Marek,
> >>>>>>>>
> >>>>>>>> Le 21/10/2011 22:44, Marek Vasut a ?crit :
> >>>>>>>>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
> >>>>>>>>>> This allows the SPL to avoid compiling in the CPU support code.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Marek Vasut<marek.vasut@gmail.com>
> >>>>>>>>>> Cc: Stefano Babic<sbabic@denx.de>
> >>>>>>>>>> Cc: Wolfgang Denk<wd@denx.de>
> >>>>>>>>>> Cc: Detlev Zundel<dzu@denx.de>
> >>>>>>>>>> Cc: Scott Wood<scottwood@freescale.com>
> >>>>>>>>>> ---
> >>>>>>>>>>
> >>>>>>>>>> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++
> >>>>>>>>>> 1 files changed, 7 insertions(+), 0 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/arch/arm/cpu/arm926ejs/Makefile
> >>>>>>>>>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644
> >>>>>>>>>> --- a/arch/arm/cpu/arm926ejs/Makefile
> >>>>>>>>>> +++ b/arch/arm/cpu/arm926ejs/Makefile
> >>>>>>>>>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
> >>>>>>>>>>
> >>>>>>>>>> START = start.o
> >>>>>>>>>> COBJS = cpu.o
> >>>>>>>>>>
> >>>>>>>>>> +ifdef CONFIG_SPL_BUILD
> >>>>>>>>>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE
> >>>>>>>>>> +START :=
> >>>>>>>>>> +COBJS :=
> >>>>>>>>>> +endif
> >>>>>>>>>> +endif
> >>>>>>>>>> +
> >>>>>>>>>>
> >>>>>>>>>> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
> >>>>>>>>>> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
> >>>>>>>>>> START := $(addprefix $(obj),$(START))
> >>>>>>>>>
> >>>>>>>>> Hi Albert,
> >>>>>>>>>
> >>>>>>>>> can we get this applied please?
> >>>>>>>>
> >>>>>>>> I still don't understand what this is supposed to do -- why not
> >>>>>>>> linking this code is required.
> >>>>>>>>
> >>>>>>>> Amicalement,
> >>>>>>>
> >>>>>>> Hi Albert,
> >>>>>>>
> >>>>>>> I use very different start.S in SPL. And I don't need cpu.o at all.
> >>>>>>
> >>>>>> That I understand; but is there a /problem/ in linking cpu.o in?
> >>>>>
> >>>>> I suppose it'll be optimized out at link time ?
> >>>>
> >>>> That indirectly answers my question: what you want to achieve is
> >>>> removing dead code.
> >>>
> >>> The code IS USED in U-Boot, but IS NOT USED in SPL !
> >>
> >> Right, but linked and unused code in SPL is (or should be!) thrown
> >> away, is what's
> >> trying to be driven home right now. If the file is going to go away,
> >> and it's compiled
> >> thrown away at final link of SPL, lets just ignore that it exists for
> >> a little longer, and
> >> then it won't.
> >
> > My distrust towards compiler abilities to optimize such stuff out tells
> > me it's better to avoid it even to be compiled in at all.
>
> Optimizing unused functions is a rather simple and reliable ability in
> tolchains. The issue is not really whether the toolchain is able to do
> the removal (it is); rather, the issue is whether the linker command
> line will cause the removal (it will IMO as long as -gc-sections is
> specified).
>
> Amicalement,
So what you suggest is to leave cpu.o compiling and drop only start.S ?
Cheers
^ permalink raw reply
* [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
From: Marek Vasut @ 2011-10-22 1:18 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA20FC1.8060809@aribaud.net>
On Saturday, October 22, 2011 02:35:13 AM Albert ARIBAUD wrote:
> Hi Marek,
>
> Le 22/10/2011 02:16, Marek Vasut a ?crit :
> > This patch series reworks the debug() and debugX() macro in
> > include/common.h to be compatible with GCC 4.6.
> >
> > This series needs further discussion:
> > * Some files suffer size growth with gcc4.2, why ?
> >
> > - Possibility is that the GCC4.2 is incapable to optimize code out so
> > deep
> >
> > * Does this change break any platforms? Compile tested on PowerPC.
> >
> > - Please run MAKEALL on your platforms to test this.
>
> Any git branch we could pull and rebase on our trees rather than am'ing
> 39 patches one by one?
Please try:
git://git.denx.de/u-boot-marex.git , "debug" branch.
Cheers
^ permalink raw reply
* [PATCH 1/1] Squashfs: Add an option to set dev block size to 4K
From: Phillip Lougher @ 2011-10-22 1:09 UTC (permalink / raw)
To: linux-fsdevel; +Cc: linux-kernel
This patch adds an option to set the device block size used to 4K.
By default Squashfs sets the device block size (sb_min_blocksize) to 1K
or the smallest block size supported by the block device (if larger).
This, because blocks are packed together and unaligned in Squashfs,
should reduce latency.
This, however, gives poor performance on MTD NAND devices where
the optimal I/O size is 4K (even though the devices can support
smaller block sizes).
Using a 4K device block size may also improve overall I/O
performance for some file access patterns (e.g. sequential
accesses of files in filesystem order) on all media.
Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
---
fs/squashfs/Kconfig | 22 ++++++++++++++++++++++
fs/squashfs/squashfs_fs.h | 7 +++++++
fs/squashfs/super.c | 2 +-
3 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
index 7797218..d383dd2 100644
--- a/fs/squashfs/Kconfig
+++ b/fs/squashfs/Kconfig
@@ -66,6 +66,28 @@ config SQUASHFS_XZ
If unsure, say N.
+config SQUASHFS_4K_DEVBLK_SIZE
+ bool "Use 4K device block size?"
+ depends on SQUASHFS
+ help
+ By default Squashfs sets the dev block size (sb_min_blocksize)
+ to 1K or the smallest block size supported by the block device
+ (if larger). This, because blocks are packed together and
+ unaligned in Squashfs, should reduce latency.
+
+ This, however, gives poor performance on MTD NAND devices where
+ the optimal I/O size is 4K (even though the devices can support
+ smaller block sizes).
+
+ Using a 4K device block size may also improve overall I/O
+ performance for some file access patterns (e.g. sequential
+ accesses of files in filesystem order) on all media.
+
+ Setting this option will force Squashfs to use a 4K device block
+ size by default.
+
+ If unsure, say N.
+
config SQUASHFS_EMBEDDED
bool "Additional option for memory-constrained systems"
depends on SQUASHFS
diff --git a/fs/squashfs/squashfs_fs.h b/fs/squashfs/squashfs_fs.h
index b4a4e53..e8e1464 100644
--- a/fs/squashfs/squashfs_fs.h
+++ b/fs/squashfs/squashfs_fs.h
@@ -36,6 +36,13 @@
#define SQUASHFS_FILE_SIZE 131072
#define SQUASHFS_FILE_LOG 17
+/* default size of block device I/O */
+#ifdef CONFIG_SQUASHFS_4K_DEVBLK_SIZE
+#define SQUASHFS_DEVBLK_SIZE 4096
+#else
+#define SQUASHFS_DEVBLK_SIZE 1024
+#endif
+
#define SQUASHFS_FILE_MAX_SIZE 1048576
#define SQUASHFS_FILE_MAX_LOG 20
diff --git a/fs/squashfs/super.c b/fs/squashfs/super.c
index 7438850..2da1715 100644
--- a/fs/squashfs/super.c
+++ b/fs/squashfs/super.c
@@ -95,7 +95,7 @@ static int squashfs_fill_super(struct super_block *sb, void *data, int silent)
}
msblk = sb->s_fs_info;
- msblk->devblksize = sb_min_blocksize(sb, BLOCK_SIZE);
+ msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);
msblk->devblksize_log2 = ffz(~msblk->devblksize);
mutex_init(&msblk->read_data_mutex);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] intel-iommu:make identity_map default for crash dump
From: Simon Horman @ 2011-10-22 1:08 UTC (permalink / raw)
To: Dave Young; +Cc: iommu, luyu, kexec, linux-kernel, vgoyal
In-Reply-To: <20111021123154.GA5821@darkstar.nay.redhat.com>
On Fri, Oct 21, 2011 at 08:31:54PM +0800, Dave Young wrote:
> kdump kernel sometimes will get DMAR faults which
> is caused by random in-flight dma from 1st kernel
>
> Here make the identity_mapping as default for this case
This seems reasonable to me. Although I am curious to know
what the side effects of using IDENTMAP_ALL might be.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH] intel-iommu:make identity_map default for crash dump
From: Simon Horman @ 2011-10-22 1:08 UTC (permalink / raw)
To: Dave Young; +Cc: kexec, iommu, vgoyal, linux-kernel, luyu
In-Reply-To: <20111021123154.GA5821@darkstar.nay.redhat.com>
On Fri, Oct 21, 2011 at 08:31:54PM +0800, Dave Young wrote:
> kdump kernel sometimes will get DMAR faults which
> is caused by random in-flight dma from 1st kernel
>
> Here make the identity_mapping as default for this case
This seems reasonable to me. Although I am curious to know
what the side effects of using IDENTMAP_ALL might be.
^ permalink raw reply
* Re: [PATCH 1/3] MSVC: Compile fix by not including sys/resources.h
From: Junio C Hamano @ 2011-10-22 0:56 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git
In-Reply-To: <4EA1C9C9.9010904@lyx.org>
>> ...
>> Subject: [PATCH 1/3] MSVC: Compile fix by not including sys/resources.h
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
........................................................^^^^^^
Could you refrain from doing that? It breaks the patch text.
Vincent van Ravesteijn <vfr@lyx.org> writes:
> Fix compilation when compiling with MSVC because sys/resource.h
> is not available. This patch causes a number of other headerfiles
> that are not available to be excluded as well.
>
> Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Instead of current
#ifndef mingw32 is the only one that is strange
... everything for systems that is not strainge ...
#else
... include mingw specific tweaks ...
#endif
#ifdef msvc is also strange
... include msvc specific tweaks ...
#endif
it turns things around and says what it wants to achieve in a more direct
way, i.e.
#if mingw32
#include "compat/mingw.h"
#elif msvc
#include "compat/msvc.h"
#else
... all the others ...
#endif
which makes it look simpler.
^ permalink raw reply
* Re: [PATCH net -v2] [BUGFIX] bonding: use flush_delayed_work_sync in bond_close
From: Jay Vosburgh @ 2011-10-22 0:59 UTC (permalink / raw)
To: netdev
Cc: =?us-ascii?Q?=3D=3FUTF-8=3FQ=3FAm=3DC3=3DA9rico=5FWang=3F=3D?=,
Stephen Hemminger, Mitsuo Hayasaka, Andy Gospodarek, linux-kernel,
yrl.pp-manager.tt
In-Reply-To: <17144.1319178396@death>
Jay Vosburgh <fubar@us.ibm.com> wrote:
>Américo Wang <xiyou.wangcong@gmail.com> wrote:
>
>>On Thu, Oct 20, 2011 at 3:09 AM, Jay Vosburgh <fubar@us.ibm.com> wrote:
>>> Stephen Hemminger <shemminger@vyatta.com> wrote:
>>>
>>>>On Wed, 19 Oct 2011 11:01:02 -0700
>>>>Jay Vosburgh <fubar@us.ibm.com> wrote:
>>>>
>>>>> Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> wrote:
>>>>>
>>>>> >The bond_close() calls cancel_delayed_work() to cancel delayed works.
>>>>> >It, however, cannot cancel works that were already queued in workqueue.
>>>>> >The bond_open() initializes work->data, and proccess_one_work() refers
>>>>> >get_work_cwq(work)->wq->flags. The get_work_cwq() returns NULL when
>>>>> >work->data has been initialized. Thus, a panic occurs.
>>>>> >
>>>>> >This patch uses flush_delayed_work_sync() instead of cancel_delayed_work()
>>>>> >in bond_close(). It cancels delayed timer and waits for work to finish
>>>>> >execution. So, it can avoid the null pointer dereference due to the
>>>>> >parallel executions of proccess_one_work() and initializing proccess
>>>>> >of bond_open().
>>>>>
>>>>> I'm setting up to test this. I have a dim recollection that we
>>>>> tried this some years ago, and there was a different deadlock that
>>>>> manifested through the flush path. Perhaps changes since then have
>>>>> removed that problem.
>>>>>
>>>>> -J
>>>>
>>>>Won't this deadlock on RTNL. The problem is that:
>>>>
>>>> CPU0 CPU1
>>>> rtnl_lock
>>>> bond_close
>>>> delayed_work
>>>> mii_work
>>>> read_lock(bond->lock);
>>>> read_unlock(bond->lock);
>>>> rtnl_lock... waiting for CPU0
>>>> flush_delayed_work_sync
>>>> waiting for delayed_work to finish...
>>>
>>> Yah, that was it. We discussed this a couple of years ago in
>>> regards to a similar patch:
>>>
>>> http://lists.openwall.net/netdev/2009/12/17/3
>>>
>>> The short version is that we could rework the rtnl_lock inside
>>> the montiors to be conditional and retry on failure (where "retry" means
>>> "reschedule the work and try again later," not "spin retrying on rtnl").
>>> That should permit the use of flush or cancel to terminate the work
>>> items.
>>
>>Yes? Even if we use rtnl_trylock(), doesn't flush_delayed_work_sync()
>>still queue the pending delayed work and wait for it to be finished?
>
> Yes, it does. The original patch wants to use flush instead of
>cancel to wait for the work to finish, because there's evidently a
>possibility of getting back into bond_open before the work item
>executes, and bond_open would reinitialize the work queue and corrupt
>the queued work item.
>
> The original patch series, and recipe for destruction, is here:
>
> http://www.spinics.net/lists/netdev/msg176382.html
>
> I've been unable to reproduce the work queue panic locally,
>although it sounds plausible.
>
> Mitsuo: can you provide the precise bonding configuration you're
>using to induce the problem? Driver options, number and type of slaves,
>etc.
>
>>Maybe I am too blind, why do we need rtnl_lock for cancel_delayed_work()
>>inside bond_close()?
>
> We don't need RTNL for cancel/flush. However, bond_close is an
>ndo_stop operation, and is called in the dev_close path, which always
>occurs under RTNL. The mii / arp monitor work functions separately
>acquire RTNL if they need to perform various failover related
>operations.
>
> I'm working on a patch that should resolve the mii / arp monitor
>RTNL problem as I described above (if rtnl_trylock fails, punt and
>reschedule the work). I need to rearrange the netdev_bonding_change
>stuff a bit as well, since it acquires RTNL separately.
>
> Once these changes are made to mii / arp monitor, then
>bond_close can call flush instead of cancel, which should eliminate the
>original problem described at the top.
Just an update: there are three functions that may deadlock if
the cancel work calls are changed to flush_sync. There are two
rtnl_lock calls in each of the bond_mii_monitor and
bond_activebackup_arp_mon functions, and one more in the
bond_alb_monitor.
Still testing to make sure I haven't missed anything, and I
still haven't been able to reproduce Mitsuo's original failure.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* [GIT PULL] i.MX6Q support
From: Shawn Guo @ 2011-10-22 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111021180158.GI23421@pengutronix.de>
On Fri, Oct 21, 2011 at 08:01:58PM +0200, Sascha Hauer wrote:
> On Fri, Oct 21, 2011 at 12:23:33AM +0200, Arnd Bergmann wrote:
> > On Thursday 20 October 2011 22:18:34 Russell King - ARM Linux wrote:
> > > On Fri, Oct 21, 2011 at 01:11:59AM +0800, Shawn Guo wrote:
> > > > Please pull imx6q series. It's based on v3.1-rc10 with the following
> > > > branches merged plus a number of cache-l2x0 patches currently sitting
> > > > on rmk/for-next.
> > >
> > > Don't do that. If there's something you need, ask me. The L2x0
> > > patches got shuffled out into their own branch when the SMP and debug
> > > patches got split out of the 'misc' branch.
> >
> > Since I already had the branches at hand for the highbank tree, I
> > gave this a go and rebased the imx6q branch on top of the stable branches
> > that are there and confirmed that it actually builds.
> >
> > I have pulled the result into the next/soc branch along with highbank
> > and picoxcell.
> >
> > Shawn and Sascha, can you confirm that this is correct?
>
> Adding the following at least gives a compilable result. Works on i.MX3,
> I couldn't test on i.MX6 though.
It works for imx6q.
--
Regards,
Shawn
> BTW your patch exporting imx_ioremap is
> missing in your for-next branch.
^ permalink raw reply
* Re: [PATCH 0/2] Fixes metadata while migrating from Raid 0 to Raid 10
From: NeilBrown @ 2011-10-22 0:50 UTC (permalink / raw)
To: Lukasz Orlowski; +Cc: dan.j.williams, linux-raid
In-Reply-To: <20111021074643.14969.22068.stgit@gklab-128-192.igk.intel.com>
[-- Attachment #1: Type: text/plain, Size: 920 bytes --]
On Fri, 21 Oct 2011 09:47:29 +0200 Lukasz Orlowski
<lukasz.orlowski@intel.com> wrote:
> The following series fixes metadata updates handling code after migration from Raid 0 to Raid 10:
> Last disk is left as a spare instead of being activated and a missing disk is a
> member of an array instead of being removed. The array status is degraded
> instead of normal.
>
> ---
>
> Lukasz Orlowski (1):
> imsm: Moves metadata update code for spare activation to separate function
>
> Lukasz Orlowski (1):
> imsm: fix: Fixes metadata after migration from Raid 0 to Raid 10
>
>
> super-intel.c | 207 +++++++++++++++++++++++++++++++--------------------------
> 1 files changed, 114 insertions(+), 93 deletions(-)
>
Thanks.
I've applied this with some re-indenting (which suspect you only left that
way to it was easier to see exactly where the changes were).
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] Remove race for starting container devices.
From: NeilBrown @ 2011-10-22 0:49 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-raid, lukasz.dorau, adam.kwolek, dledford
In-Reply-To: <1319204000-6661-2-git-send-email-Jes.Sorensen@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]
On Fri, 21 Oct 2011 15:33:18 +0200 Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> This moves the lock handling out of Incremental_container() and relies
> on the caller holding the lock. This prevents conflict with a
> follow-on mdadm comment which may try and launch the device in
> parallel.
>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Hi Jes,
I have applied the 7 patches you sent.
However I have question mark over part of this one:
> @@ -451,9 +456,10 @@ int Incremental(char *devname, int verbose, int runstop,
> devnum = fd2devnum(mdfd);
> close(mdfd);
> sysfs_free(sra);
> - rv = Incremental(chosen_name, verbose, runstop,
> - NULL, homehost, require_homehost, autof,
> - freeze_reshape);
> + rv = Incremental_container(st, chosen_name, homehost,
> + verbose, runstop, autof,
> + freeze_reshape);
> + map_unlock(&map);
> if (rv == 1)
> /* Don't fail the whole -I if a subarray didn't
> * have enough devices to start yet
You have replaced a call to Incremental with a call to Incremental_container.
I feel that is significant enough that I would have liked to have seen it
discussed in the changelog comment.
You seem have have open-coded Incremental and then removed all the bits that
you don't need in this case - which is that vast majority of it.
But you didn't include the call to ->load_content().
So I have put it back in because I'm sure it must be harmless (Because it was
there already) but it may not be needed.
If you have thoughts on this, please let me know.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: ath9k: irq storm after suspend/resume
From: Adrian Chadd @ 2011-10-22 0:47 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Mohammed Shafi, linux-wireless, ath9k-devel
In-Reply-To: <20111021202038.GA1523@ecki.lan>
.. then I don't think it's specifically the NIC.
>From what I understand, unless there are bus errors happening (and
that'd occur with the NIC awake or having something being written to
it) the NIC shouldn't be generating interrupts if:
* sync/async cause are 0;
* ier is 0;
* imr is 0.
Now maybe some part of ath9k is still trying to write to the NIC when
it's asleep, but it would set some bits in sync_cause/async_cause.
At this point I'd really suggest whacking other devices into the slot
to see if they generate the same kind of behaviour.
Adrian
^ permalink raw reply
* [ath9k-devel] ath9k: irq storm after suspend/resume
From: Adrian Chadd @ 2011-10-22 0:47 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <20111021202038.GA1523@ecki.lan>
.. then I don't think it's specifically the NIC.
^ permalink raw reply
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code
From: Albert ARIBAUD @ 2011-10-22 0:41 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110220219.54608.marek.vasut@gmail.com>
Le 22/10/2011 02:19, Marek Vasut a ?crit :
> On Saturday, October 22, 2011 02:04:52 AM Tom Rini wrote:
>> On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasut<marek.vasut@gmail.com> wrote:
>>> On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
>>>> Le 22/10/2011 00:46, Marek Vasut a ?crit :
>>>>> On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
>>>>>> Le 22/10/2011 00:00, Marek Vasut a ?crit :
>>>>>>> On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
>>>>>>>> Hi Marek,
>>>>>>>>
>>>>>>>> Le 21/10/2011 22:44, Marek Vasut a ?crit :
>>>>>>>>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
>>>>>>>>>> This allows the SPL to avoid compiling in the CPU support code.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Marek Vasut<marek.vasut@gmail.com>
>>>>>>>>>> Cc: Stefano Babic<sbabic@denx.de>
>>>>>>>>>> Cc: Wolfgang Denk<wd@denx.de>
>>>>>>>>>> Cc: Detlev Zundel<dzu@denx.de>
>>>>>>>>>> Cc: Scott Wood<scottwood@freescale.com>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++
>>>>>>>>>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/cpu/arm926ejs/Makefile
>>>>>>>>>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644
>>>>>>>>>> --- a/arch/arm/cpu/arm926ejs/Makefile
>>>>>>>>>> +++ b/arch/arm/cpu/arm926ejs/Makefile
>>>>>>>>>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
>>>>>>>>>>
>>>>>>>>>> START = start.o
>>>>>>>>>> COBJS = cpu.o
>>>>>>>>>>
>>>>>>>>>> +ifdef CONFIG_SPL_BUILD
>>>>>>>>>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE
>>>>>>>>>> +START :=
>>>>>>>>>> +COBJS :=
>>>>>>>>>> +endif
>>>>>>>>>> +endif
>>>>>>>>>> +
>>>>>>>>>>
>>>>>>>>>> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
>>>>>>>>>> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
>>>>>>>>>> START := $(addprefix $(obj),$(START))
>>>>>>>>>
>>>>>>>>> Hi Albert,
>>>>>>>>>
>>>>>>>>> can we get this applied please?
>>>>>>>>
>>>>>>>> I still don't understand what this is supposed to do -- why not
>>>>>>>> linking this code is required.
>>>>>>>>
>>>>>>>> Amicalement,
>>>>>>>
>>>>>>> Hi Albert,
>>>>>>>
>>>>>>> I use very different start.S in SPL. And I don't need cpu.o at all.
>>>>>>
>>>>>> That I understand; but is there a /problem/ in linking cpu.o in?
>>>>>
>>>>> I suppose it'll be optimized out at link time ?
>>>>
>>>> That indirectly answers my question: what you want to achieve is
>>>> removing dead code.
>>>
>>> The code IS USED in U-Boot, but IS NOT USED in SPL !
>>
>> Right, but linked and unused code in SPL is (or should be!) thrown
>> away, is what's
>> trying to be driven home right now. If the file is going to go away,
>> and it's compiled
>> thrown away at final link of SPL, lets just ignore that it exists for
>> a little longer, and
>> then it won't.
>
> My distrust towards compiler abilities to optimize such stuff out tells me it's
> better to avoid it even to be compiled in at all.
Optimizing unused functions is a rather simple and reliable ability in
tolchains. The issue is not really whether the toolchain is able to do
the removal (it is); rather, the issue is whether the linker command
line will cause the removal (it will IMO as long as -gc-sections is
specified).
Amicalement,
--
Albert.
^ permalink raw reply
* [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
From: Albert ARIBAUD @ 2011-10-22 0:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
Hi Marek,
Le 22/10/2011 02:16, Marek Vasut a ?crit :
> This patch series reworks the debug() and debugX() macro in include/common.h to
> be compatible with GCC 4.6.
>
> This series needs further discussion:
> * Some files suffer size growth with gcc4.2, why ?
> - Possibility is that the GCC4.2 is incapable to optimize code out so deep
> * Does this change break any platforms? Compile tested on PowerPC.
> - Please run MAKEALL on your platforms to test this.
Any git branch we could pull and rebase on our trees rather than am'ing
39 patches one by one?
Amicalement,
--
Albert.
^ permalink raw reply
* [U-Boot] [WIKI] changes to "Custodian Git Trees"
From: Albert ARIBAUD @ 2011-10-22 0:33 UTC (permalink / raw)
To: u-boot
All,
I have modified http://www.denx.de/wiki/U-Boot/CustodianGitTrees to
reflect the layered repository ad also to simplify the custodian
operations description ; not having a local uboot branch anymore, and
fetching repos rather than pulling them, should avoid the accidental
merges that happen (ir)regularly.
Comment (or direct editing) welcome.
Amicalement,
--
Albert.
^ permalink raw reply
* "Benchmarks"
From: Brad Campbell @ 2011-10-22 0:29 UTC (permalink / raw)
To: linux-bcache-u79uwXL29TY76Z2rM5mHXA
I use the term loosely.
This is with the raw drive being a Maxtor MaxlineII 250GB 7200RPM SATA
unit. It's about a 2004 vintage with over 30,000 hours on it. Slow and
steady.
The Cache device is an OCZ Vertex Plus 120GB Unit. Not all that fast or
clever. The Cache has writeback enabled and is formatted with -w512 so
that direct IO worked as previously discussed.
The benchmark is conducted inside an XP VM running under KVM. The device
is a qcow2 backing file formatted NTFS. I ran the test multiple times
without the cache until the numbers stabilised (the backing file was
being expanded as required)
http://www.fnarfbargle.com/private/111022_bcache/Without_Cache.png
http://www.fnarfbargle.com/private/111022_bcache/With_Cache.png
As expected a significant improvement in random small I/O. The VM is far
more responsive with the cache.
^ permalink raw reply
* a bug when execute "git status" in git version 1.7.7.431.g89633
From: John Hsing @ 2011-10-22 0:20 UTC (permalink / raw)
To: git
the error:
git: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
(((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >=
(unsigned long)((((__builtin_offsetof (struct malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) -
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask)
== 0)' failed.
^ permalink raw reply
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code
From: Marek Vasut @ 2011-10-22 0:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CA+M6bXnmY1fiVJoLT+t50Lb-sq12Yb_Sz-w9qjhnW9iLbmYgqQ@mail.gmail.com>
On Saturday, October 22, 2011 02:04:52 AM Tom Rini wrote:
> On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
> >> Le 22/10/2011 00:46, Marek Vasut a ?crit :
> >> > On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
> >> >> Le 22/10/2011 00:00, Marek Vasut a ?crit :
> >> >>> On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
> >> >>>> Hi Marek,
> >> >>>>
> >> >>>> Le 21/10/2011 22:44, Marek Vasut a ?crit :
> >> >>>>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
> >> >>>>>> This allows the SPL to avoid compiling in the CPU support code.
> >> >>>>>>
> >> >>>>>> Signed-off-by: Marek Vasut<marek.vasut@gmail.com>
> >> >>>>>> Cc: Stefano Babic<sbabic@denx.de>
> >> >>>>>> Cc: Wolfgang Denk<wd@denx.de>
> >> >>>>>> Cc: Detlev Zundel<dzu@denx.de>
> >> >>>>>> Cc: Scott Wood<scottwood@freescale.com>
> >> >>>>>> ---
> >> >>>>>>
> >> >>>>>> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++
> >> >>>>>> 1 files changed, 7 insertions(+), 0 deletions(-)
> >> >>>>>>
> >> >>>>>> diff --git a/arch/arm/cpu/arm926ejs/Makefile
> >> >>>>>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644
> >> >>>>>> --- a/arch/arm/cpu/arm926ejs/Makefile
> >> >>>>>> +++ b/arch/arm/cpu/arm926ejs/Makefile
> >> >>>>>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
> >> >>>>>>
> >> >>>>>> START = start.o
> >> >>>>>> COBJS = cpu.o
> >> >>>>>>
> >> >>>>>> +ifdef CONFIG_SPL_BUILD
> >> >>>>>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE
> >> >>>>>> +START :=
> >> >>>>>> +COBJS :=
> >> >>>>>> +endif
> >> >>>>>> +endif
> >> >>>>>> +
> >> >>>>>>
> >> >>>>>> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
> >> >>>>>> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
> >> >>>>>> START := $(addprefix $(obj),$(START))
> >> >>>>>
> >> >>>>> Hi Albert,
> >> >>>>>
> >> >>>>> can we get this applied please?
> >> >>>>
> >> >>>> I still don't understand what this is supposed to do -- why not
> >> >>>> linking this code is required.
> >> >>>>
> >> >>>> Amicalement,
> >> >>>
> >> >>> Hi Albert,
> >> >>>
> >> >>> I use very different start.S in SPL. And I don't need cpu.o at all.
> >> >>
> >> >> That I understand; but is there a /problem/ in linking cpu.o in?
> >> >
> >> > I suppose it'll be optimized out at link time ?
> >>
> >> That indirectly answers my question: what you want to achieve is
> >> removing dead code.
> >
> > The code IS USED in U-Boot, but IS NOT USED in SPL !
>
> Right, but linked and unused code in SPL is (or should be!) thrown
> away, is what's
> trying to be driven home right now. If the file is going to go away,
> and it's compiled
> thrown away at final link of SPL, lets just ignore that it exists for
> a little longer, and
> then it won't.
My distrust towards compiler abilities to optimize such stuff out tells me it's
better to avoid it even to be compiled in at all.
^ permalink raw reply
* [U-Boot] [PATCH 39/39] GCC4.6: Add macros to mv_gen_reg.h
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
interrupts.c: In function 'interrupt_init_cpu':
interrupts.c:40: error: 'ETHERNET0_INTERRUPT_CAUSE_REGISTER' undeclared (first
use in this function)
interrupts.c:40: error: (Each undeclared identifier is reported only once
interrupts.c:40: error: for each function it appears in.)
interrupts.c:40: error: 'ETHERNET1_INTERRUPT_CAUSE_REGISTER' undeclared (first
use in this function)
interrupts.c:40: error: 'ETHERNET2_INTERRUPT_CAUSE_REGISTER' undeclared (first
use in this function)
interrupts.c:44: error: 'ETHERNET0_INTERRUPT_MASK_REGISTER' undeclared (first
use in this function)
interrupts.c:44: error: 'ETHERNET1_INTERRUPT_MASK_REGISTER' undeclared (first
use in this function)
interrupts.c:44: error: 'ETHERNET2_INTERRUPT_MASK_REGISTER' undeclared (first
use in this function)
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
board/Marvell/include/mv_gen_reg.h | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/board/Marvell/include/mv_gen_reg.h b/board/Marvell/include/mv_gen_reg.h
index 03fcd88..008185e 100644
--- a/board/Marvell/include/mv_gen_reg.h
+++ b/board/Marvell/include/mv_gen_reg.h
@@ -1864,6 +1864,14 @@
#define ETH_DA_FILTER_OTHER_MULTICAST_TABLE_BASE(port) (0x3500 + (port<<10))
#define ETH_DA_FILTER_UNICAST_TABLE_BASE(port) (0x3600 + (port<<10))
+/* Compat with interrupts.c */
+#define ETHERNET0_INTERRUPT_CAUSE_REGISTER ETH_INTERRUPT_CAUSE_REG(0)
+#define ETHERNET1_INTERRUPT_CAUSE_REGISTER ETH_INTERRUPT_CAUSE_REG(1)
+#define ETHERNET2_INTERRUPT_CAUSE_REGISTER ETH_INTERRUPT_CAUSE_REG(2)
+
+#define ETHERNET0_INTERRUPT_MASK_REGISTER ETH_INTERRUPT_MASK_REG(0)
+#define ETHERNET1_INTERRUPT_MASK_REGISTER ETH_INTERRUPT_MASK_REG(1)
+#define ETHERNET2_INTERRUPT_MASK_REGISTER ETH_INTERRUPT_MASK_REG(2)
/* Ethernet GT64260 */
/*
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 38/39] GCC4.6: Squash GTREADREG related errors
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
interrupts.c: In function 'interrupt_init_cpu':
interrupts.c:37: warning: implicit declaration of function 'GTREGREAD'
interrupts.c:37: error: 'LOW_INTERRUPT_CAUSE_REGISTER' undeclared (first use in
this function)
interrupts.c:37: error: (Each undeclared identifier is reported only once
interrupts.c:37: error: for each function it appears in.)
interrupts.c:37: error: 'HIGH_INTERRUPT_CAUSE_REGISTER' undeclared (first use in
this function)
interrupts.c:40: error: 'ETHERNET0_INTERRUPT_CAUSE_REGISTER' undeclared (first
use in this function)
interrupts.c:40: error: 'ETHERNET1_INTERRUPT_CAUSE_REGISTER' undeclared (first
use in this function)
interrupts.c:40: error: 'ETHERNET2_INTERRUPT_CAUSE_REGISTER' undeclared (first
use in this function)
interrupts.c:44: error: 'ETHERNET0_INTERRUPT_MASK_REGISTER' undeclared (first
use in this function)
interrupts.c:44: error: 'ETHERNET1_INTERRUPT_MASK_REGISTER' undeclared (first
use in this function)
interrupts.c:44: error: 'ETHERNET2_INTERRUPT_MASK_REGISTER' undeclared (first
use in this function)
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
include/configs/PCIPPC2.h | 4 ++++
include/configs/PCIPPC6.h | 4 ++++
include/configs/mpc7448hpc2.h | 4 ++++
include/configs/p3mx.h | 4 ++++
include/configs/ppmc7xx.h | 4 ++++
5 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/include/configs/PCIPPC2.h b/include/configs/PCIPPC2.h
index fb485b0..77cedc0 100644
--- a/include/configs/PCIPPC2.h
+++ b/include/configs/PCIPPC2.h
@@ -55,6 +55,10 @@
#define CONFIG_PREBOOT ""
#define CONFIG_BOOTDELAY 5
+#ifndef __ASSEMBLY__
+#include <galileo/core.h>
+#endif
+
/*
* BOOTP options
*/
diff --git a/include/configs/PCIPPC6.h b/include/configs/PCIPPC6.h
index 16d6450..a8d20ca 100644
--- a/include/configs/PCIPPC6.h
+++ b/include/configs/PCIPPC6.h
@@ -55,6 +55,10 @@
#define CONFIG_PREBOOT ""
#define CONFIG_BOOTDELAY 5
+#ifndef __ASSEMBLY__
+#include <galileo/core.h>
+#endif
+
/*
* BOOTP options
*/
diff --git a/include/configs/mpc7448hpc2.h b/include/configs/mpc7448hpc2.h
index 700dcda..8a91c91 100644
--- a/include/configs/mpc7448hpc2.h
+++ b/include/configs/mpc7448hpc2.h
@@ -54,6 +54,10 @@
#undef CONFIG_ECC /* disable ECC support */
+#ifndef __ASSEMBLY__
+#include <galileo/core.h>
+#endif
+
/* Board-specific Initialization Functions to be called */
#define CONFIG_SYS_BOARD_ASM_INIT
#define CONFIG_BOARD_EARLY_INIT_F
diff --git a/include/configs/p3mx.h b/include/configs/p3mx.h
index 94a6992..e44009e 100644
--- a/include/configs/p3mx.h
+++ b/include/configs/p3mx.h
@@ -447,4 +447,8 @@
#define L2_ENABLE (L2_INIT | L2CR_L2E)
+#ifndef __ASSEMBLY__
+#include <../board/Marvell/include/core.h>
+#endif
+
#endif /* __CONFIG_H */
diff --git a/include/configs/ppmc7xx.h b/include/configs/ppmc7xx.h
index d3c8990..4ceee17 100644
--- a/include/configs/ppmc7xx.h
+++ b/include/configs/ppmc7xx.h
@@ -51,6 +51,10 @@
#define CONFIG_SYS_TEXT_BASE 0xFFF00000
+#ifndef __ASSEMBLY__
+#include <galileo/core.h>
+#endif
+
/*
* Monitor configuration
*
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 37/39] RFT GCC4.6: Fix muas3001 and IDS8247
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
The boards suffer from the following error due to undefined configuration
variables:
Configuring for IDS8247 board...
ether_fcc.c:75: error: 'CONFIG_SYS_CMXFCR_MASK1' undeclared here (not in a
function)
ether_fcc.c:76: error: 'CONFIG_SYS_CMXFCR_VALUE1' undeclared here (not in a
function)
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
include/configs/IDS8247.h | 4 ++++
include/configs/muas3001.h | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/configs/IDS8247.h b/include/configs/IDS8247.h
index 8552250..bc26bd7 100644
--- a/include/configs/IDS8247.h
+++ b/include/configs/IDS8247.h
@@ -147,6 +147,10 @@
#define CONFIG_ETHER_INDEX 1 /* which SCC/FCC channel for ethernet */
#define CONFIG_ETHER_ON_FCC1
#define FCC_ENET
+#define CONFIG_SYS_CMXFCR_MASK1 \
+ (CMXFCR_FC1 | CMXFCR_RF1CS_MSK | CMXFCR_TF1CS_MSK)
+#define CONFIG_SYS_CMXFCR_VALUE1 \
+ (CMXFCR_RF1CS_CLK11 | CMXFCR_TF1CS_CLK12)
/*
* - Rx-CLK is CLK10
diff --git a/include/configs/muas3001.h b/include/configs/muas3001.h
index 8b3022b..e21dea3 100644
--- a/include/configs/muas3001.h
+++ b/include/configs/muas3001.h
@@ -78,6 +78,10 @@
#define CONFIG_ETHER_ON_FCC1
#define CONFIG_HAS_ETH0
#define FCC_ENET
+#define CONFIG_SYS_CMXFCR_MASK1 \
+ (CMXFCR_FC1 | CMXFCR_RF1CS_MSK | CMXFCR_TF1CS_MSK)
+#define CONFIG_SYS_CMXFCR_VALUE1 \
+ (CMXFCR_RF1CS_CLK11 | CMXFCR_TF1CS_CLK12)
/*
* - Rx-CLK is CLK11
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 36/39] GCC4.6: Squash error in cpc45/pd67290.c
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
pd67290.c: In function 'cirrus_set_opts':
pd67290.c:282: error: 'buf' undeclared (first use in this function)
pd67290.c:282: error: (Each undeclared identifier is reported only once
pd67290.c:282: error: for each function it appears in.)
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
board/cpc45/pd67290.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/board/cpc45/pd67290.c b/board/cpc45/pd67290.c
index 0d8ef23..815e4ba 100644
--- a/board/cpc45/pd67290.c
+++ b/board/cpc45/pd67290.c
@@ -225,11 +225,7 @@ static u_int cirrus_set_opts (socket_info_t * s)
{
cirrus_state_t *p = &s->c_state;
u_int mask = 0xffff;
-#if DEBUG
- char buf[200];
-
- memset (buf, 0, 200);
-#endif
+ char buf[200] = {0};
if (has_ring == -1)
has_ring = 1;
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 35/39] GCC4.6: Squash error in pcmcia/i82365.c
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
i82365.c: In function 'cirrus_set_opts':
i82365.c:329: error: 'buf' undeclared (first use in this function)
i82365.c:329: error: (Each undeclared identifier is reported only once
i82365.c:329: error: for each function it appears in.)
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
drivers/pcmcia/i82365.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/drivers/pcmcia/i82365.c b/drivers/pcmcia/i82365.c
index 1bcb3a5..1cde83a 100644
--- a/drivers/pcmcia/i82365.c
+++ b/drivers/pcmcia/i82365.c
@@ -272,11 +272,7 @@ static u_int cirrus_set_opts (socket_info_t * s)
{
cirrus_state_t *p = &s->c_state;
u_int mask = 0xffff;
-#if DEBUG
- char buf[200];
-
- memset (buf, 0, 200);
-#endif
+ char buf[200] = {0};
if (has_ring == -1)
has_ring = 1;
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 34/39] GCC4.6: Squash warnings in PPChameleonEVB/flash.c
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
flash.c: In function 'flash_init':
flash.c:54: warning: format '%08X' expects type 'unsigned int', but argument 4
has type 'struct flash_info_t *'
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
---
board/dave/PPChameleonEVB/flash.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/board/dave/PPChameleonEVB/flash.c b/board/dave/PPChameleonEVB/flash.c
index 2e1a9ab..3d5b20d 100644
--- a/board/dave/PPChameleonEVB/flash.c
+++ b/board/dave/PPChameleonEVB/flash.c
@@ -51,7 +51,8 @@ unsigned long flash_init (void)
int size_val = 0;
debug("[%s, %d] Entering ...\n", __FUNCTION__, __LINE__);
- debug("[%s, %d] flash_info = 0x%08X ...\n", __FUNCTION__, __LINE__, flash_info);
+ debug("[%s, %d] flash_info = 0x%p ...\n", __func__, __LINE__,
+ flash_info);
/* Init: no FLASHes known */
for (i=0; i<CONFIG_SYS_MAX_FLASH_BANKS; ++i) {
--
1.7.6.3
^ permalink raw reply related
* [U-Boot] [PATCH 33/39] GCC4.6: Squash warnings in r360mpi/flash.c
From: Marek Vasut @ 2011-10-22 0:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-1-git-send-email-marek.vasut@gmail.com>
flash.c: In function 'flash_get_size':
flash.c:222: warning: format '%08lx' expects type 'long unsigned int', but
argument 3 has type 'int'
flash.c:238: warning: format '%08lx' expects type 'long unsigned int', but
argument 3 has type 'int'
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mike Frysinger <vapier@gentoo.org>
---
board/r360mpi/flash.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/r360mpi/flash.c b/board/r360mpi/flash.c
index 45cccf7..26ec11d 100644
--- a/board/r360mpi/flash.c
+++ b/board/r360mpi/flash.c
@@ -219,7 +219,7 @@ static ulong flash_get_size (FPW * addr, flash_info_t * info)
value = addr[0];
- debug ("Manuf. ID @ 0x%08lx: 0x%08lx\n", (ulong)addr, value);
+ debug("Manuf. ID @ 0x%08lx: 0x%08x\n", (ulong)addr, value);
switch (value) {
case (FPW) INTEL_MANUFACT:
@@ -235,7 +235,7 @@ static ulong flash_get_size (FPW * addr, flash_info_t * info)
value = addr[1]; /* device ID */
- debug ("Device ID @ 0x%08lx: 0x%08lx\n", (ulong)(&addr[1]), value);
+ debug("Device ID @ 0x%08lx: 0x%08x\n", (ulong)(&addr[1]), value);
switch (value) {
case (FPW) INTEL_ID_28F320J3A:
--
1.7.6.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.