This patch also does some minor coding style cleanups.
Signed-off-by: Andreas Bießmann
---
arch/arm/lib/board.c|3 ++-
arch/avr32/lib/board.c |3 ++-
arch/blackfin/lib/board.c |3 ++-
arch/m68k/lib/board.c |3 ++-
arch/microblaze/lib/board.c
Hi Andreas,
On 16.04.2013 12:14, Andreas Bießmann wrote:
> This patch also does some minor coding style cleanups.
>
> Signed-off-by: Andreas Bießmann
>
> ---
> arch/arm/lib/board.c|3 ++-
> arch/avr32/lib/board.c |3 ++-
> arch/blackfin/lib/board.c |3 ++-
Hi Andreas,
On Tue, Apr 16, 2013 at 8:14 PM, Andreas Bießmann <
andreas.de...@googlemail.com> wrote:
> This patch also does some minor coding style cleanups.
>
>
Coding style cleanups belong in a separate patch - Rules are rules ;)
Regards,
Graeme
__
Hi Andreas,
On Tue, 16 Apr 2013 12:14:09 +0200, Andreas Bießmann
wrote:
> This patch also does some minor coding style cleanups.
>
> Signed-off-by: Andreas Bießmann
>
> ---
> arch/arm/lib/board.c|3 ++-
> arch/avr32/lib/board.c |3 ++-
> arch/blackfin/lib/board.c
Hi Albert,
On 04/16/2013 01:36 PM, Albert ARIBAUD wrote:
> Hi Andreas,
>
> On Tue, 16 Apr 2013 12:14:09 +0200, Andreas Bießmann
> wrote:
>
>> This patch also does some minor coding style cleanups.
>>
>> Signed-off-by: Andreas Bießmann
>>
>> ---
>> arch/arm/lib/board.c|3 ++-
>>
Dear "Andreas Bießmann",
In message <516d39cf.9020...@gmail.com> you wrote:
>
> > Apart from Stefan's comments: considered standalone, doesn't this patch
> > have zero effect? I suspect you intend to use this in a later patch,
> > and if so, I would suggest grouping these in a series so that the
Dear Wolfgang Denk,
On 04/16/2013 02:22 PM, Wolfgang Denk wrote:
> Dear "Andreas Bießmann",
>
> In message <516d39cf.9020...@gmail.com> you wrote:
>>
>>> Apart from Stefan's comments: considered standalone, doesn't this patch
>>> have zero effect? I suspect you intend to use this in a later patch
Dear Andreas,
In message <516d4b00.9030...@gmail.com> you wrote:
>
> > So it is dead code in mainline, and we will not add it.
>
> Well, I don't think it is dead code cause the hang() is called in some ways.
> This patch opens just the possibility to specialize the hang() by for
> example a speci
Dear Wolfgang,
On 04/16/2013 03:05 PM, Wolfgang Denk wrote:
> Dear Andreas,
>
> In message <516d4b00.9030...@gmail.com> you wrote:
>>
>>> So it is dead code in mainline, and we will not add it.
>>
>> Well, I don't think it is dead code cause the hang() is called in some ways.
>> This patch opens
Hi Andreas,
On Tue, Apr 16, 2013 at 11:32 PM, Andreas Bießmann <
andreas.de...@googlemail.com> wrote:
>
> Dear Wolfgang,
>
> On 04/16/2013 03:05 PM, Wolfgang Denk wrote:
> > Dear Andreas,
> >
> > In message <516d4b00.9030...@gmail.com> you wrote:
> >>
> >>> So it is dead code in mainline, and we
Hi Graeme,
On 04/16/2013 03:35 PM, Graeme Russ wrote:
> Hi Andreas,
>
> On Tue, Apr 16, 2013 at 11:32 PM, Andreas Bießmann
> mailto:andreas.de...@googlemail.com>> wrote:
>>
>> Dear Wolfgang,
>>
>> On 04/16/2013 03:05 PM, Wolfgang Denk wrote:
>> > Dear Andreas,
>> >
>> > In message <516d4b00.9030.
Dear Andreas,
In message <516d52ee.1040...@gmail.com> you wrote:
>
> Yes it is independent (or should at least). But there are still slightly
> different versions:
Yes, I know :-(
> ---8<---
> arch/powerpc/lib/board.c:void __hang(void)
> arch/powerpc/lib/board.c-{
> arch/powerpc/lib/board.c-
Hi Andreas,
On Wed, Apr 17, 2013 at 12:15 AM, Andreas Bießmann <
andreas.de...@googlemail.com> wrote:
>
> Hi Graeme,
>
> On 04/16/2013 03:35 PM, Graeme Russ wrote:
> > Hi Andreas,
> >
> > On Tue, Apr 16, 2013 at 11:32 PM, Andreas Bießmann
> > mailto:andreas.de...@googlemail.com>>
wrote:
> >>
> >>
Dear Andreas,
In message <516d5d0a.20...@gmail.com> you wrote:
>
> In my opinion it makes sense to panic(). In my special case I also need
> to hang() when panic(). The next question is then how to visualize the
> (end-)user of that device that we hang().
The intention behind hang() is to stop d
Dear Wolfgang,
On 04/16/2013 04:23 PM, Wolfgang Denk wrote:
> Dear Andreas,
>
> In message <516d5d0a.20...@gmail.com> you wrote:
>>
>> In my opinion it makes sense to panic(). In my special case I also need
>> to hang() when panic(). The next question is then how to visualize the
>> (end-)user of
Dear Andreas,
In message <516d62e1.7090...@gmail.com> you wrote:
>
> But how about other places in u-boot hang()ing the device? How can we
> tell the user that state without a terminal? If one plugs a uart cable
> he might see some cause of the hang() but this is not acceptable for
> some groups o
Dear Wolfgang,
On 04/16/2013 05:14 PM, Wolfgang Denk wrote:
> Dear Andreas,
>
> In message <516d62e1.7090...@gmail.com> you wrote:
>>
>> But how about other places in u-boot hang()ing the device? How can we
>> tell the user that state without a terminal? If one plugs a uart cable
>> he might see
Dear Andreas,
In message <516d6f71.8090...@gmail.com> you wrote:
>
> You say (or at least I understand you so), that I have to hack all these
> places with some application specific stuff to inform the user of the
> device that we will stop processing now. Why don't we add an interface
> to easil
Dear Wolfgang,
On 16.04.13 18:00, Wolfgang Denk wrote:
> Dear Andreas,
>
> In message <516d6f71.8090...@gmail.com> you wrote:
>>> Also, as done in arch/powerpc/lib/board.c we usually print an error
>>> message on the console device, and we can call bootstage_error(),
>>> which could initialte su
19 matches
Mail list logo