On Wed, Jun 19, 2002 at 01:21:06PM +0200, Steven Scholz wrote:
Steven Scholz wrote:
quoted
I think we should move the board specific defines such as
etc. out of ./include/asm-ppc/commproc.h into the board specific header
files like ./arch/ppc/platforms/xxx.h
Ok,
I'll give it a try now.
Please find the attached patch. It moves the board specific definitions
for MPC8xx CPM Ethernet out of ./include/asm-ppc/commproc.h into the
board specific include files in ./arch/ppc/platforms/.
It applies cleanly against today's linuxppc_2_4_devel (2.4.19-pre10)
_and_ linuxppc_2_5 (2.5.4-pre2).
I only tested it with 2_4_devel for a TQM860L board.
The recent 2_5 does not even compile for neither TQM860L nor RPXLITE! So
I had no chance to test it. But it should work just fine.
Hope this helps cleaning up the mess! :o)
I'm sort-of supprised it works.
Isn't:
((uint)0x....)
in assembly bad?
I think we need to have all of these defines enclosed with the
__ASSEMBLY__ test, but I can go fix that.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Steven Scholz <hidden> Date: 2002-06-19 15:18:04
Tom Rini wrote:
I'm sort-of supprised it works.
I told you, it's not that much to do...
:-)
Isn't:
((uint)0x....)
in assembly bad?
Hmm. Don't know. Maybe. But these are just DEFINES! So what should that
be bad?
I think we need to have all of these defines enclosed with the
__ASSEMBLY__ test, but I can go fix that.
At least spd8xx.h and tqm8xx.h don't have any #ifndef __ASSEMBLY__ at
all!?
Cheers,
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
Tom Rini wrote:
quoted
I'm sort-of supprised it works.
I told you, it's not that much to do...
:-)
quoted
Isn't:
((uint)0x....)
in assembly bad?
Hmm. Don't know. Maybe. But these are just DEFINES! So what should that
be bad?
Oh yeah, right.. Hmm, it probably won't break anything then..
quoted
I think we need to have all of these defines enclosed with the
__ASSEMBLY__ test, but I can go fix that.
At least spd8xx.h and tqm8xx.h don't have any #ifndef __ASSEMBLY__ at
all!?
(... waking up ...) Because the only C bits they had are now in
<asm/ppcboot.h> which does the test right.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Steven Scholz <hidden> Date: 2002-06-19 15:33:41
Tom Rini wrote:
On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
quoted
Tom Rini wrote:
quoted
I'm sort-of supprised it works.
I told you, it's not that much to do...
:-)
quoted
Isn't:
((uint)0x....)
in assembly bad?
Hmm. Don't know. Maybe. But these are just DEFINES! So what should that
be bad?
Oh yeah, right.. Hmm, it probably won't break anything then..
quoted
quoted
I think we need to have all of these defines enclosed with the
__ASSEMBLY__ test, but I can go fix that.
At least spd8xx.h and tqm8xx.h don't have any #ifndef __ASSEMBLY__ at
all!?
(... waking up ...) Because the only C bits they had are now in
<asm/ppcboot.h> which does the test right.
All right then. I can't do more testing due to the lack of hardware.
Maybe Wolfgang could spend a little of his precious time since he claims
to have a zoo of boards... :o)
(Especially TQM8xxL, FPS850L, SM850)
So when can I "bk pull" these changes then, Tom?
Good luck,
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Wed, Jun 19, 2002 at 05:33:41PM +0200, Steven Scholz wrote:
Tom Rini wrote:
quoted
On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
quoted
Tom Rini wrote:
quoted
I'm sort-of supprised it works.
I told you, it's not that much to do...
:-)
quoted
Isn't:
((uint)0x....)
in assembly bad?
Hmm. Don't know. Maybe. But these are just DEFINES! So what should that
be bad?
Oh yeah, right.. Hmm, it probably won't break anything then..
quoted
quoted
I think we need to have all of these defines enclosed with the
__ASSEMBLY__ test, but I can go fix that.
At least spd8xx.h and tqm8xx.h don't have any #ifndef __ASSEMBLY__ at
all!?
(... waking up ...) Because the only C bits they had are now in
<asm/ppcboot.h> which does the test right.
All right then. I can't do more testing due to the lack of hardware.
Maybe Wolfgang could spend a little of his precious time since he claims
to have a zoo of boards... :o)
(Especially TQM8xxL, FPS850L, SM850)
So when can I "bk pull" these changes then, Tom?
On Wed, Jun 19, 2002 at 05:47:18PM +0200, Steven Scholz wrote:
Tom Rini wrote:
quoted
quoted
So when can I "bk pull" these changes then, Tom?
Shortly after I see if 2.5.23 boots/compiles for classic PPC :)
What do you mean? RPX Classic?
No, 6xx/7xx/74xx boards. Or more specifically the motorola lopec I've
got up on my desk here. :)
There's already a few things that need to be fixed, and then I'll push
that (And wait until we can start the _devel resync before pushing it to
2.4).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-06-19 21:11:36
Tom Rini wrote:
On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
quoted
Hmm. Don't know. Maybe. But these are just DEFINES! So what should that
be bad?
Oh yeah, right.. Hmm, it probably won't break anything then..
But, that's not the point.
The 2.4 source base is no longer supposed to be a development base.
The code works fine as it is, moving a bunch of #defines around because
some people like it that way isn't giving us any feature enhancement and
opens the door for making mistakes. I personally like the file the way
it is because it is the logical collection of all communication processor
related information regardless of the board. I'm sorry others don't
like it that way.
I don't know how many people have lived through previous transitions of
Linux kernel development to stable trees, but at some point you just have
to move to the development tree and let the "stable" tree become stable.
Instead of complaining about the development tree being unstable, you should
be investing some resources to make it better. Why are you waiting for
someone else to do that so you can reap the benefits later? The only
thing that should be happening in the 2.4 tree is bug fixing. The 2.4
kernel is what it is, like it or not. If you want something new and different,
it belongs in the 2.5 tree to show up at some point in the future.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Wed, Jun 19, 2002 at 05:11:36PM -0400, Dan Malek wrote:
Tom Rini wrote:
quoted
On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
quoted
quoted
Hmm. Don't know. Maybe. But these are just DEFINES! So what should that
be bad?
Oh yeah, right.. Hmm, it probably won't break anything then..
But, that's not the point.
Well, since I was referring to C-code in a #define in a file included by
asm files, it was the point. :) But I added __ASSEMBLY__ tests to the
files that neeed it 'n such since it does work but isn't really
correct..
The 2.4 source base is no longer supposed to be a development base.
The code works fine as it is, moving a bunch of #defines around because
some people like it that way isn't giving us any feature enhancement and
opens the door for making mistakes.
Maybe I won't move it into 2.4 right after the _devel merge. We'll
see..
I personally like the file the way
it is because it is the logical collection of all communication processor
related information regardless of the board. I'm sorry others don't
like it that way.
Yes, but it's putting board-specific information in a board-independant
file. That doesn't seem right.
[snip]
thing that should be happening in the 2.4 tree is bug fixing. The 2.4
kernel is what it is, like it or not. If you want something new and
different,
it belongs in the 2.5 tree to show up at some point in the future.
And in the (un)fortunate grand linux tradition, new features with some
demand from the users behind them get backported too. For example,
2.2.current (21? 22?) has all sorts of compat glue for 2.4 drivers and a
rather current USB stack and all sorts of things like that..
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-06-20 16:32:50
Tom Rini wrote:
And in the (un)fortunate grand linux tradition, new features with some
demand from the users behind them get backported too. For example,
2.2.current (21? 22?) has all sorts of compat glue for 2.4 drivers and a
rather current USB stack and all sorts of things like that..
It was probably done in 2.3.xx and backported, but yes, that does happen
and it is a good thing. However, it was first done in the newer, development
tree before it was ported into the current, stable kernel. I think
the first half dozen 2.4 releases were really 2.3.xxx, anyway :-)
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/