Dear Joakim Tjernlund,
In message <1254960231-11441-1-git-send-email-joakim.tjernl...@transmode.se>
you wrote:
> NULL is an absolute value and should not be relocated.
> After this correction code like:
> void weak_fun(void) __attribute__((weak));
> printf("weak_fun:%p\n", weak_fun);
> will sti
Hi,
I'm trying to run NetConsole, listen for incoming messages for 1 sec, and
continue according to the message type.
On the other side (PC) i'm sending a broadcast message on port every
250 ms.
What i see is a very unstable behaviour
Sometimes i get nothing, sometime only part of the message
I was making my v2, and I found a problem wrt:
> while 64bit isnt in today, might as well avoid unclean code from the start
> when possible. in other words, used "unsigned int" rather than "u32" and cast
> to "unsigned long" rather than "int".
Since int is 32 also on 64bit systems, I used unsign
Dear alex889,
In message <25799667.p...@talk.nabble.com> you wrote:
>
> Hi,
> I'm trying to run NetConsole, listen for incoming messages for 1 sec, and
> continue according to the message type.
> On the other side (PC) i'm sending a broadcast message on port every
> 250 ms.
> What i see is a
NAND Boot support for P1 and P2 series RDB platforms.
This patch is derived from latest NAND Boot support on MPC8536DS by Mingkai Hu.
Signed-off-by: Dipen Dudhat
---
- Applies to http://git.denx.de/u-boot.git
- Changes from v1: Integrated kumar's comments
MAKEALL
On Chip BootROM support for P1 and P2 series RDB platforms.
This patch is derived from latest On Chip BootROM support on MPC8536DS by
Mingkai Hu.
Signed-off-by: Dipen Dudhat
---
- Applies to http://git.denx.de/u-boot.git
MAKEALL |8
Makefile
This patch adds support to boot from NAND/eSDHC/eSPI using DDR on P1 & P2 RDB
platforms.
Specifically this support needed when L2 Cache size is less than 512K.
For this one define "CONFIG_L2_RELOC" has added in platform config file.
Signed-off-by: Dipen Dudhat
---
- Applies to http://git.denx.d
Dear Alessandro Rubini,
In message <20091008074114.ga30...@mail.gnudd.com> you wrote:
>
> Since int is 32 also on 64bit systems, I used unsigned long.
Note that this is not guaranteed, though. It could be 64 bit as well.
> /* do it one word at a time (32 bits or 64 bits) if possible */
>
>
> Dear Joakim Tjernlund,
>
> In message <1254960231-11441-1-git-send-email-joakim.tjernl...@transmode.se>
> you wrote:
> > NULL is an absolute value and should not be relocated.
> > After this correction code like:
> > void weak_fun(void) __attribute__((weak));
> > printf("weak_fun:%p\n", wea
>
> Dear Alessandro Rubini,
>
> In message <20091008074114.ga30...@mail.gnudd.com> you wrote:
> >
> > Since int is 32 also on 64bit systems, I used unsigned long.
>
> Note that this is not guaranteed, though. It could be 64 bit as well.
>
>
> >/* do it one word at a time (32 bits or 64 bits
Hello, All!
My next question is about OneNAND U-Boot operations.
I use U-Boot 2009.08.rc2. There is "onenand" command:
onenand read[.oob] addr off size
read/write 'size' bytes starting at offset 'off'
to/from memory address 'addr', skipping bad blocks.
Can someone explain me how should I
Dear alex...@gmail.com,
Please keep the ML on Cc:.
In message <19418536.543781254988736020.javamail.nab...@isper.nabble.com> you
wrote:
>
> I'm running version 1.3.4 on TI's DM365 processor
Ah. Way too old. You most probably have performance issues in this old
implementation. Make sure to upda
I've added 32-bit lcd to the Nomadik (not submitted yet), and I found
the scroll to be very slow, as the screen is big.
Instead of activating the "if 0" stanza for 32-bit scroll in lcd.c,
I'd better have a faster memcpy/memset globally. So this patch set
adds ulong-wide memcpy and memset, then rem
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
lib_generic/string.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/lib_generic/string.c b/lib_generic/string.c
index 181eda6..9911941 100644
--- a/lib_generic/string.
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
lib_generic/string.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/lib_generic/string.c b/lib_generic/string.c
index 9911941..5f7aff9 100644
--- a/lib_generic/string.
From: Alessandro Rubini
Signed-off-by: Alessandro Rubini
Acked-by: Andrea Gallo
---
common/lcd.c | 21 -
1 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index dc8fea6..4e31618 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -99,
Out of curiosity, I wanted to see just how much of a size penalty I am
incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are
the results (fixed width font will help - its space, not tab, formatted):
Section non-reloc reloc
---
.
From: Alessandro Rubini
If "stdout" is not previously set, doing "setenv stdout lcd" had no
effect, since console redirection only worked if the environment
variable was already set; the second time you run setenv it worked.
Most default environments lack stdin/out/err definitions, so I'm sure
I'
This patch adds a new net api driver for AT91RM9200 EMAC
* adds NET_MULTI api EMAC (CONFIG_DRIVER_AT91EMAC)
* generic PHY initialization
Signed-off-by: Jens Scharsig
---
This patch was tested with full MII interface and LXT971 Phy on our
upcomming new board.
I have also tested the RMII interf
Dear Joakim Tjernlund,
In message
you
wrote:
>
> > Could you next time _please_ add this "v3" information to the
> > Subject:, say as "[PATCH v3] relocation: ..." ?
>
> You sure are hard to please :)
Not really. I consider this a basic requirement to patch submission.
In your case, I receive
Dear Joakim Tjernlund,
In message
you
wrote:
>
> > How about:
> >
> > cl = 0;
> > for (i=0; i > cl <<= 8;
> > cl |= c & 0xff;
> > }
> >
> > GCC optimization will do the rest...
>
> If you want gcc to optimise well, make it easy to do so.
> Changing the for l
Dear Sun Peng
2009/9/22 sun peng :
> When I'm playing with u-boot I found that the size of smdk6400 nand
> spl binary image can't pad to 4K. So I make some minor change to the
> config.mk file to achieve the correct padding size.
>
> Signed-off-by: Sunpeng
> ---
> nand_spl/board/samsung/smdk6400
Wolfgang Denk wrote on 08/10/2009 14:49:15:
>
> Dear Joakim Tjernlund,
>
> In message 0031e...@transmode.se> you wrote:
> >
> > > How about:
> > >
> > > cl = 0;
> > > for (i=0; i > > cl <<= 8;
> > > cl |= c & 0xff;
> > > }
> > >
> > > GCC optimization will do t
Wolfgang Denk wrote on 08/10/2009 14:44:07:
>
> Dear Joakim Tjernlund,
>
> In message 00311...@transmode.se> you wrote:
> >
> > > Could you next time _please_ add this "v3" information to the
> > > Subject:, say as "[PATCH v3] relocation: ..." ?
> >
> > You sure are hard to please :)
>
> Not re
> > Jocke, Peter: am I understanding correctly that we now have everything
> > in the "reloc" branch that we want to include with this upcoming
> > release, i. e. that we can do the "final" testing now before I merge
> > that branch into master?
>
> Yes, I have nothing more ready and I believe ev
Dear Joakim Tjernlund,
In message
you
wrote:
>
> So my question is: Did you check all gcc versions and
> arches?
Of course not :-)
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenze
On Oct 8, 2009, at 3:03 AM, Dipen Dudhat wrote:
> NAND Boot support for P1 and P2 series RDB platforms.
>
> This patch is derived from latest NAND Boot support on MPC8536DS by
> Mingkai Hu.
>
> Signed-off-by: Dipen Dudhat
> ---
> - Applies to http://git.denx.de/u-boot.git
> - Changes from v1:
On Oct 8, 2009, at 3:03 AM, Dipen Dudhat wrote:
> This patch adds support to boot from NAND/eSDHC/eSPI using DDR on P1
> & P2 RDB platforms.
> Specifically this support needed when L2 Cache size is less than 512K.
>
> For this one define "CONFIG_L2_RELOC" has added in platform config
> file.
>
> diff --git a/board/freescale/p1_p2_rdb/config.mk b/board/freescale/
> p1_p2_rdb/config.mk
> index 0f7a048..e76b59c 100644
> --- a/board/freescale/p1_p2_rdb/config.mk
> +++ b/board/freescale/p1_p2_rdb/config.mk
> @@ -33,12 +33,20 @@ endif
>
> ifeq ($(CONFIG_MK_SDCARD), y)
> TEXT_BASE = $(CONFIG
On Oct 8, 2009, at 3:03 AM, Dipen Dudhat wrote:
> On Chip BootROM support for P1 and P2 series RDB platforms.
>
> This patch is derived from latest On Chip BootROM support on
> MPC8536DS by Mingkai Hu.
>
> Signed-off-by: Dipen Dudhat
> ---
> - Applies to http://git.denx.de/u-boot.git
> MAKEALL
On Oct 2, 2009, at 5:48 PM, Paul Gortmaker wrote:
> This is an orphaned legacy leftover that is just polluting
> the config file namespace.
>
> Signed-off-by: Paul Gortmaker
> ---
> include/configs/MPC8610HPCD.h |2 --
> include/configs/MPC8641HPCN.h |2 --
> include/configs/sbc8641d.h
On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote:
> Out of curiosity, I wanted to see just how much of a size penalty I am
> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are
> the results (fixed width font will help - its space, not tab, formatted):
>
> Section
> > Most probably we need a Signed-off-by then ;)
>
> Take your pick. Either a:
>
> Acked-by: Olof Johansson
>
> Or apply the below revised patch instead.
>
>
> SMC911X: Add chip auto detection
>
> Refactor the smc911x driver to allow for detecting when the chip is
> missing.
> I.e. the dete
Hi Detlev,
Detlev Zundel wrote on Wednesday, October 07, 2009 4:38 PM:
> This fixes the code and the comment according to the original intent
> of doing an intensive memory test when PSC6_3 is pulled low on the
> STK52xx. Notably PORT_CONFIG will be overridden with this correct
> code now,
> so b
On Thu, 2009-10-08 at 13:30 +0200, Alessandro Rubini wrote:
> From: Alessandro Rubini
>
> Signed-off-by: Alessandro Rubini
> Acked-by: Andrea Gallo
> ---
> lib_generic/string.c | 17 +
> 1 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/lib_generic/string.c
On Sep 15, 2009, at 11:15 PM, Kumar Gala wrote:
>
> On Aug 19, 2009, at 1:37 PM, Anton Vorontsov wrote:
>
>> eSDHC is mutually exlusive with UART0* and I2C2. When eSDHC is
>> used, we should switch u-boot console to UART1, and make the
>> proper device-tree fixups.
>>
>> * Actually, according to
Peter Tyser wrote:
> On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote:
>
>> Out of curiosity, I wanted to see just how much of a size penalty I am
>> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are
>> the results (fixed width font will help - its space, not tab, forma
Graeme Russ wrote:
> Out of curiosity, I wanted to see just how much of a size penalty I am
> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are
> the results (fixed width font will help - its space, not tab, formatted):
>
> Section non-reloc reloc
> ---
> No interest in the suggestion to not require count to be an exact
> multiple of 4/8?
Actually, I wrote about that in my patch 0/3.
> I don't think it would be that hard to update the logic accordingly
> and this would let your code be utilized much more often, especially
> if/when we run on a 6
On Thu, 2009-10-08 at 08:53 -0700, J. William Campbell wrote:
> Peter Tyser wrote:
> > On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote:
> >
> >> Out of curiosity, I wanted to see just how much of a size penalty I am
> >> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here ar
On Thu, Oct 08, 2009 at 10:52:08AM -0500, Kumar Gala wrote:
>
> On Sep 15, 2009, at 11:15 PM, Kumar Gala wrote:
>
> >
> >On Aug 19, 2009, at 1:37 PM, Anton Vorontsov wrote:
> >
> >>eSDHC is mutually exlusive with UART0* and I2C2. When eSDHC is
> >>used, we should switch u-boot console to UART1, a
On Thu, 2009-10-08 at 18:00 +0200, Alessandro Rubini wrote:
> > No interest in the suggestion to not require count to be an exact
> > multiple of 4/8?
>
> Actually, I wrote about that in my patch 0/3.
Sorry, I should have read more thoroughly.
> > I don't think it would be that hard to update th
Peter Tyser wrote:
> On Thu, 2009-10-08 at 08:53 -0700, J. William Campbell wrote:
>
>> Peter Tyser wrote:
>>
>>> On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote:
>>>
>>>
Out of curiosity, I wanted to see just how much of a size penalty I am
incurring by using gcc -
Paulraj, Sandeep wrote:
>>> Most probably we need a Signed-off-by then ;)
>>>
>> Take your pick. Either a:
>>
>> Acked-by: Olof Johansson
>>
>> Or apply the below revised patch instead.
>>
>>
>> SMC911X: Add chip auto detection
>>
>> Refactor the smc911x driver to allow for detecting when t
> Paulraj, Sandeep wrote:
> >>> Most probably we need a Signed-off-by then ;)
> >>>
> >> Take your pick. Either a:
> >>
> >> Acked-by: Olof Johansson
> >>
> >> Or apply the below revised patch instead.
> >>
> >>
> >> SMC911X: Add chip auto detection
> >>
> >> Refactor the smc911x driver to allow
>> That's true, but I think the most important case is lcd scrolling,
>> where it's usually a big power of two -- that's where we had the #ifdef,
>> so the problem was known, I suppose.
>
> I think the most important case for *you* is lcd scrolling, but for 99%
> of everyone else, it isn't at all:
On Thu, Oct 08, 2009 at 10:08:08AM -0700, Ben Warren wrote:
> Paulraj, Sandeep wrote:
Most probably we need a Signed-off-by then ;)
>>> Take your pick. Either a:
>>>
>>> Acked-by: Olof Johansson
>>>
>>> Or apply the below revised patch instead.
>>>
>>>
>>> SMC911X: Add chip auto d
On Thu, 2009-10-08 at 20:23 +0200, Alessandro Rubini wrote:
> >> That's true, but I think the most important case is lcd scrolling,
> >> where it's usually a big power of two -- that's where we had the #ifdef,
> >> so the problem was known, I suppose.
> >
> > I think the most important case for *y
On Thursday 08 October 2009 07:30:02 Alessandro Rubini wrote:
> + if ( (((int)dest | (int)src | count) & (sizeof(long) - 1)) == 0) {
when i talked about changing the int cast, i was talking about the pointers.
pointers should always be cast to (unsigned long).
-mike
signature.asc
Descripti
> The statistics are going to be very different for different scenarios.
Yes, I know.
> For example, network operations seem to be the majority of your large
> memcpys, this isn't the case for everyone.
True. I noticed it after sending -- although I expected it.
> In any case, my only suggestio
Dear Alessandro Rubini,
In message you wrote:
>
> Similarly, I'm not interested in "4 bytes at a time, then 1 at a time"
> as it's quite a corner case. If such optimizations are really useful,
> then we'd better have hand-crafted assembly for each arch, possibly
> lifted from glibc.
I disagree
Dear Alessandro Rubini,
In message <20091008191734.ga13...@mail.gnudd.com> you wrote:
>
> > In any case, my only suggestion would be that if we're improving
> > memcpy()/memset(), do the extra 10% of effort required to make them a
> > little better. That 10% of effort will improve 15.2% of all m
Dear Alessandro Rubini,
In message <45d5e3a574bf4844f46f50b2c88054a5b28f973b.1255000877.git.rubini@
unipv.it> you wrote:
> From: Alessandro Rubini
>
> Signed-off-by: Alessandro Rubini
> Acked-by: Andrea Gallo
> ---
> lib_generic/string.c | 17 +
> 1 files changed, 13 insert
Dear Alessandro Rubini,
In message you wrote:
...
> void * memset(void * s,int c,size_t count)
> {
> char *xs = (char *) s;
> -
> + unsigned long *sl = (unsigned long *) s;
> + unsigned long cl = 0;
> + int i;
Same changes as suggested for the memcpy() patch go here:
> +
Dear Alessandro Rubini,
In message <20091008160026.ga9...@mail.gnudd.com> you wrote:
> > No interest in the suggestion to not require count to be an exact
> > multiple of 4/8?
>
> Actually, I wrote about that in my patch 0/3.
Hm. Your argument was not exctly convincing, though.
> Currently, I d
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell
wrote:
> Graeme Russ wrote:
>>
>> Out of curiosity, I wanted to see just how much of a size penalty I am
>> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are
>> the results (fixed width font will help - its space, not tab, f
Dear Graeme Russ,
In message you
wrote:
>
>
> Once the reloc branch has been merged, how many arches are left which do
> not support relocation?
All but PPC ?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kir
On Thursday 08 October 2009 07:29:51 Alessandro Rubini wrote:
> Similarly, I'm not interested in "4 bytes at a time, then 1 at a time"
> as it's quite a corner case. If such optimizations are really useful,
> then we'd better have hand-crafted assembly for each arch, possibly
> lifted from glibc.
On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you
> wrote:
>>
>>
>> Once the reloc branch has been merged, how many arches are left which do
>> not support relocation?
>
> All but PPC ?
Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all abou
Dear Peter Tyser,
In message <1255009252.9100.1019.ca...@localhost.localdomain> you wrote:
>
> > > Jocke, Peter: am I understanding correctly that we now have everything
> > > in the "reloc" branch that we want to include with this upcoming
> > > release, i. e. that we can do the "final" testing
On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote:
> On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wrote:
> > Dear Graeme Russ,
> >
> > In message
> > you wrote:
> >>
> >>
> >> Once the reloc branch has been merged, how many arches are left which do
> >> not support relocation?
> >
> > All bu
Graeme Russ wrote:
> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell
> wrote:
>
>> Graeme Russ wrote:
>>
>>> Out of curiosity, I wanted to see just how much of a size penalty I am
>>> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are
>>> the results (fixed width f
On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell
wrote:
> Graeme Russ wrote:
>>
>> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell
>> wrote:
>>
>>>
>>> Graeme Russ wrote:
>>>
Out of curiosity, I wanted to see just how much of a size penalty I am
incurring by using gcc -fpic
>
> On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell
> wrote:
> > Graeme Russ wrote:
> >>
> >> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell
> >> wrote:
> >>
> >>>
> >>> Graeme Russ wrote:
> >>>
>
> Out of curiosity, I wanted to see just how much of a size penalty I am
> i
Joakim Tjernlund wrote:
>> On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell
>> wrote:
>>
>>> Graeme Russ wrote:
>>>
On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell
wrote:
> Graeme Russ wrote:
>
>
>> Out of curiosity, I wan
On Thursday 08 October 2009 18:20:18 Peter Tyser wrote:
> On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote:
> > On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wrote:
> > > Graeme Russ wrote:
> > >> Once the reloc branch has been merged, how many arches are left which
> > >> do not support reloc
On Fri, Oct 9, 2009 at 9:20 AM, Peter Tyser wrote:
> On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote:
>> On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wrote:
>> > Dear Graeme Russ,
>> >
>> > In message
>> > you wrote:
>> >>
>> >>
>> >> Once the reloc branch has been merged, how many arches
Minkyu Kang wrote:
> This patch adds support for the Samsung s5pc100 and s5pc110
> SoCs. The s5pc1xx SoC is an ARM Cortex A8 processor.
>
> Signed-off-by: Minkyu Kang
> Signed-off-by: HeungJun, Kim
> ---
> Changes since v1:
> - make C struct instead of base+offset
> - use writel/readl function
>
Minkyu Kang wrote:
> This patch includes the onenand driver for s5pc100
>
> Signed-off-by: Minkyu Kang
> Signed-off-by: Kyungmin Park
> ---
> Changes since v1:
> - move samsung_onenand.h to include/linux/mtd/
> - make C struct instead of base+offset
> - Remove the "1 &&" in while loop
>
> Chang
Minkyu Kang wrote:
> This patch includes the serial driver for s5pc1xx.
> s5pc1xx uart driver needs own register setting and clock configuration.
> So, need to special driver.
>
> Signed-off-by: Minkyu Kang
> ---
> Changes since v1:
> - use serial multi API
> - use writel/readl function
> - remov
Minkyu Kang wrote:
> Adds new board SMDKC100 that uses s5pc100 SoC
>
> Signed-off-by: Minkyu Kang
> Signed-off-by: HeungJun, Kim
> ---
> Changes since v1:
> - arrange env values for more readable
> - make C struct instead of base+offset
> - use MACH_TYPE_SMDKC100 directly
> - fix the CONFIG_SYS_
Wolfgang Denk a écrit :
> I think we should change this if-else into a plain if, something like
> that:
>
> void * memcpy(void *dest, const void *src, size_t count)
> {
> char *tmp = (char *) dest, *s = (char *) src;
> char *d8 = (char *)dest, *s8 = (char *)src;
> unsigned long *d
Dear kevin.morfitt,
2009/9/8 kevin.morf...@fearnside-systems.co.uk
:
>
>
> On 07/09/2009 23:18, Wolfgang Denk wrote:
>> Dear "kevin.morf...@fearnside-systems.co.uk",
>>
>> In message <4aa583ac.3050...@fearnside-systems.co.uk> you wrote:
In message <4aa284b9.8030...@fearnside-systems.co.uk> yo
Dear kevin.morfitt
2009/10/6 kevin.morf...@fearnside-systems.co.uk
:
>
>
> Abdoulaye Walsimou Gaye wrote:
>> kevin.morf...@fearnside-systems.co.uk a écrit :
>>> Here are links to the patches and notes on their states:
>>> - [U-boot] [PATCH-ARM] CONFIG_SYS_HZ change for cpu/arm920t/s3c24x0 boards:
Blackfin pieces like commit 0630535e2d062dd73c1ceca5c6125c86d1127a49.
Signed-off-by: Mike Frysinger
---
include/asm-blackfin/config.h |3 +++
include/asm-blackfin/global_data.h |1 -
lib_blackfin/board.c |2 --
3 files changed, 3 insertions(+), 3 deletions(-)
diff
All arches apparently should reset the watchdog in their udelay loop as
noted on the mailing list recently:
> A comment in flash_status_check() suggests that udelay() is
> expected to reset the watchdog, but I can't find any architecture
> where it does.
If this is missing in other archit
All arches apparently should reset the watchdog in their udelay loop as
noted on the mailing list recently:
> A comment in flash_status_check() suggests that udelay() is
> expected to reset the watchdog, but I can't find any architecture
> where it does.
If this is missing in other archit
77 matches
Mail list logo
