From: Gary Jennejohn <garyj@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2 V2] IOMUX: Add console multiplexing support.
Date: Mon, 20 Oct 2008 18:26:35 +0200 [thread overview]
Message-ID: <20081020182635.4ed9ca48@ernst.jennejohn.org> (raw)
In-Reply-To: <20081020155732.2653f2d7@ernst.jennejohn.org>
On Mon, 20 Oct 2008 15:57:32 +0200
Gary Jennejohn <garyj@denx.de> wrote:
> On Mon, 20 Oct 2008 15:24:53 +0200
> Wolfgang Denk <wd@denx.de> wrote:
>
> > I have to admit that I don't like the idea of splitting the
> > GD_FLG_DEVINIT into several, unrelated parts of the code.
> >
>
> I don't like it too much myself, but it seemed like the logical approach
> to me at the time I made this modification.
>
> > Would it not make more sense to have the netconsole part wait with
> > output until it's been initialized? And/or move the netweork init to
> > an earlier point, when netconsole is enabled?
> >
>
> Not a bad idea. I think it would be most logical to do it in the
> netconsole code, rather than moving up the network initialization.
>
> I'll take a look at that.
>
I looked at this some more. eth_initialize() is called in every
architecture-specific library which means changing 8 files to move
it up to before the initialization of netconsole.
netconsole is intialized in devices_init() which is called even before
console_init_r() and long before eth_initialize().
What's the opinion of the ML? Is it worth all the repository churn to
move eth_initialize() up rather than changing just two files?
One alrernative which occurs to me would be to introduce a new flag
GD_FLG_ETHINIT, but this is even worse because it requires modifying
12 header files and 3 or more C files.
---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
*********************************************************************
next prev parent reply other threads:[~2008-10-20 16:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-14 14:45 [U-Boot] [PATCH 2/2] IOMUX: Add console multiplexing support Gary Jennejohn
2008-09-14 16:07 ` Wolfgang Denk
2008-09-14 17:19 ` Gary Jennejohn
2008-09-14 18:34 ` Wolfgang Denk
2008-09-15 8:46 ` Gary Jennejohn
2008-09-15 11:08 ` Wolfgang Denk
2008-10-20 11:58 ` [U-Boot] [PATCH 2/2 V2] " Gary Jennejohn
2008-10-20 13:24 ` Wolfgang Denk
2008-10-20 13:57 ` Gary Jennejohn
2008-10-20 16:26 ` Gary Jennejohn [this message]
2008-10-20 19:43 ` Wolfgang Denk
2008-10-20 20:13 ` Ben Warren
2008-10-21 9:45 ` Gary Jennejohn
2008-10-21 10:34 ` Wolfgang Denk
2008-10-21 11:32 ` Gary Jennejohn
2008-10-20 19:32 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081020182635.4ed9ca48@ernst.jennejohn.org \
--to=garyj@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox