board specific defines in commproc.h !?!?

board specific defines in commproc.h !?!?

[Steven Scholz]

Hi there,

I think we should move the board specific defines such as

/***  RPXCLASSIC  *****************************************************/

#ifdef CONFIG_RPXCLASSIC
/* Bits in parallel I/O port registers that have to be set/cleared
 * to configure the pins for SCC1 use.
 */
#define PA_ENET_RXD     ((ushort)0x0001)
#define PA_ENET_TXD     ((ushort)0x0002)
#define PA_ENET_TCLK    ((ushort)0x0200)

etc. out of ./include/asm-ppc/commproc.h into the board specific header
files like ./arch/ppc/platforms/xxx.h

The advantage is, that you don't have to change many files to port linux
to a new, custom platform. After all #define PA_ENET_RXD
((ushort)0x0001) is a board specific configuration define.

The same goes for the status_led.h from DENX (which unfortunatly has not
yet made it into linuxppc_2_4_devel!?!?)

At the same time we should changes this in the PPCBoot source - to make
porting Linux to a new platform easier.

I am prepared to do this - if you think it's worth it!

So?

Cheers,

Steven

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[John W. Linville]

Steven Scholz wrote:
>
> Hi there,
>
> I think we should move the board specific defines such as
>
> /***  RPXCLASSIC  *****************************************************/

I, for one, think that's a great idea.  It is always a PITA to track
down those nits when doing support for a new board or moving board
support from one kernel to the next...

John
--
John W. Linville
LVL7 Systems, Inc.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Tom Rini]

On Mon, Jun 17, 2002 at 11:20:02AM +0200, Steven Scholz wrote:

> Hi there,
>
> I think we should move the board specific defines such as
>
> /***  RPXCLASSIC  *****************************************************/
[snip]
> etc. out of ./include/asm-ppc/commproc.h into the board specific header
> files like ./arch/ppc/platforms/xxx.h

Yes, we should.  Patches vs linuxppc-2.5 (note, you won't be able to
boot 8xx unless you perform some other updates) happily accepted.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Steven Scholz]

Tom Rini wrote:
>
> On Mon, Jun 17, 2002 at 11:20:02AM +0200, Steven Scholz wrote:
>
> > Hi there,
> >
> > I think we should move the board specific defines such as
> >
> > /***  RPXCLASSIC  *****************************************************/
> [snip]
> > etc. out of ./include/asm-ppc/commproc.h into the board specific header
> > files like ./arch/ppc/platforms/xxx.h
>
> Yes, we should.  Patches vs linuxppc-2.5 (note, you won't be able to
> boot 8xx unless you perform some other updates) happily accepted.

Ehm... Does that mean you won't accept patches vs linuxppc-2.4 though
!?!?

Steven

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Tom Rini]

On Mon, Jun 17, 2002 at 05:37:55PM +0200, Steven Scholz wrote:
> Tom Rini wrote:
> >
> > On Mon, Jun 17, 2002 at 11:20:02AM +0200, Steven Scholz wrote:
> >
> > > Hi there,
> > >
> > > I think we should move the board specific defines such as
> > >
> > > /***  RPXCLASSIC  *****************************************************/
> > [snip]
> > > etc. out of ./include/asm-ppc/commproc.h into the board specific header
> > > files like ./arch/ppc/platforms/xxx.h
> >
> > Yes, we should.  Patches vs linuxppc-2.5 (note, you won't be able to
> > boot 8xx unless you perform some other updates) happily accepted.
>
> Ehm... Does that mean you won't accept patches vs linuxppc-2.4 though
> !?!?

That means I want this to be done in 2.5 first.  Where development is
supposed to happen.  I have this feeling that fixing commproc.h will be
more than 1 simple patch and we should do it in the development tree
first.  Then, once that's all done and people are happy with it, we can
move it to linuxppc_2_4.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Steven Scholz]

Tom Rini wrote:

> > Ehm... Does that mean you won't accept patches vs linuxppc-2.4 though
> > !?!?
>
> That means I want this to be done in 2.5 first.  Where development is
> supposed to happen.  I have this feeling that fixing commproc.h will be
> more than 1 simple patch and we should do it in the development tree
> first.  Then, once that's all done and people are happy with it, we can
> move it to linuxppc_2_4.

Hmm... Just moving the DEFINEs from commproc.h to the board specific
header files is indeed just ONE simple patch. I've done that already. I
am not sure what else you mean by "fixing commproc.h"!?

The thing is:

Since I am sure that many, many people are still using linux-2.4.4 I
would realy like to fix that in linuxppc_2_4_devel, linux-2.4.4 (DENX)
_and_ PPCBoot at the same time! Just to keep that consistent.

And I have to admit that I haven't had a look at linuxppc-2.5 at all so
far... :-(

Steven

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Tom Rini]

On Mon, Jun 17, 2002 at 06:01:30PM +0200, Steven Scholz wrote:
> Tom Rini wrote:
>
> > > Ehm... Does that mean you won't accept patches vs linuxppc-2.4 though
> > > !?!?
> >
> > That means I want this to be done in 2.5 first.  Where development is
> > supposed to happen.  I have this feeling that fixing commproc.h will be
> > more than 1 simple patch and we should do it in the development tree
> > first.  Then, once that's all done and people are happy with it, we can
> > move it to linuxppc_2_4.
>
> Hmm... Just moving the DEFINEs from commproc.h to the board specific
> header files is indeed just ONE simple patch. I've done that already. I
> am not sure what else you mean by "fixing commproc.h"!?

Well, commproc.h is a rather large dumping ground.

What bits does PPCBoot need to get at really?  What bits are needed for
i2c?  What can we legitimately move into another header (and add
__KERNEL__ too).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Wolfgang Denk]

In message <20020617153255.GS13541@opus.bloom.county> Tom Rini wrote:
>
> Yes, we should.  Patches vs linuxppc-2.5 (note, you won't be able to
> boot 8xx unless you perform some other updates) happily accepted.

Tom, I'm a bit frustrated.

You know that I've sent this very same patch to you a long, long time
ago. At a time, when there wasn't even a 2.5 around.


You shouldbe aware of all the problems with 2.5 for 8xx systems -  is
the  only  way  to  get  ANY  patches  into the _working_ tree really
through 2.5? Why must we  go  through  the  pain  to  fix  a  lot  of
unrelated problems in a tree we don't really care about (yet) just to
fix things?

This policy is just nonsense.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"I can call spirits from the vasty deep."
"Why so can I, or so can any man; but will they come when you do call
for them?"          - Shakespeare, 1 King Henry IV, Act III, Scene I.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Steven Scholz]

Tom Rini wrote:

> > -  is
> > the  only  way  to  get  ANY  patches  into the _working_ tree really
> > through 2.5?
>
> Well, for the moment I'd like to try that.  Considering there's really 4
> (kernel.org, linuxppc_2_4, linuxppc_2_4_devel, DENX) trees people use right
> now, I'd like to try and remove at least one of those.
>
> And since we're stuck between a rock and a hard place, wrt killing
> 2_4_devel right now, lets use linuxppc-2.5 (or linux-2.5) which has
> 98% of the changes in _devel (and I think 100%, wrt 8xx).
>
> > Why must we  go  through  the  pain  to  fix  a  lot  of
> > unrelated problems in a tree we don't really care about (yet) just to
> > fix things?
>
> Fixing 2 things.  And it will be a lot less painful now trying to fix 2,
> recently broken things, rather than waiting 6 months to fix 5 or 10
> broken things spanning 6-8 months.

Tom,

does that mean that you will _not_ accept small patches fixing small
problems!?

I can remember you (?) always telling the people the split their patches
into small pieces doing one thing at a time!

So why not fix first things first?

The DEFINES I am talking about are Ethernet related (SCC/FEC). I think
they should move into the board specific header files. And they have
nothing to with the I2C stuff! Or did I miss something?

Cheers,

Steven

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Wolfgang Denk]

Dear Tom,

in message <20020617173550.GV13541@opus.bloom.county> you wrote:
>
> > You shouldbe aware of all the problems with 2.5 for 8xx systems
>
> Yes.  There's 2 right now.  The tlb miss handlers need to be updated
> because the pmd is now a physical address rather than a virtual one, and
> the exception handling needs to be updated for some changes Paul made
> recently.   Everything else should be OK.

There is one central problem: this source  tree  is  an  experimental
tree, and it's far from being stable.

It makes no sense to me to use 2.5 as base for any of our daily work.

> Well, for the moment I'd like to try that.  Considering there's really 4
> (kernel.org, linuxppc_2_4, linuxppc_2_4_devel, DENX) trees people use right
> now, I'd like to try and remove at least one of those.

Agreed. I would be more than happy  to  get  rid  of  the  effort  to
maintain  our tree. But there are so many things I've submitted again
and again that never got acceepted that I gave  up.  [And  I  am  NOT
talking  about  obviouslu  controversial  stuff  like  our  old flash
drivers.]

> And since we're stuck between a rock and a hard place, wrt killing
> 2_4_devel right now, lets use linuxppc-2.5 (or linux-2.5) which has
> 98% of the changes in _devel (and I think 100%, wrt 8xx).

This does not work. When we port Linux to any new board,  we  need  a
stable  base  in  the  first place. Right now we're in the process of
switching to 2_4_devel, because this finally seems mature enough. 2.5
is nice for trying out new features and  stuff  like  that,  but  for
cleanup,  and  regular extensions (like new board support stuff etc.)
it's a wasto of time to get an instable tree like 2.5  running  on  a
new system just to get the patches into the "real" tree where we need
them  -  which  also  may take a LONG time (or forever), judging from
previous experience.

> Fixing 2 things.  And it will be a lot less painful now trying to fix 2,
> recently broken things, rather than waiting 6 months to fix 5 or 10
> broken things spanning 6-8 months.

For my purposes, 2.5 is not usable (yet). It's a playground.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Old programmers never die, they just branch to a new address.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Wolfgang Denk]

Dear Tom,

in message <20020617214339.GZ13541@opus.bloom.county> you wrote:
>
> likely) for 2.4 and 2.5.  And yes, an untested/lightly tested 2.5 patch
> is perfectly acceptible.  2.5 itself is only lightly tested (or not
> tested at all for some cases).

But don't you see  the  problem?  Exactly  this  is  what  makes  2.5
unusable: it's a collection of lightly or not tested patches.

> I'm asking you (and everyone else) to submit new work for the community
> vs 2.5 before you submit it for 2.4.  This has the bonus that the next
> stable release will have all of your fixes in it already and you won't

I don't see any bonus, but I do see  additional  (and  most  probably
wasted) efford.


Tom, let's stop here. I understand _what_ you say, and even parts  of
the _why_, but it's not practical to me.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
After a time, you may find that "having" is not so pleasing a thing,
after all, as "wanting."  It is not logical, but it is often true.
	-- Spock, "Amok Time", stardate 3372.7

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Tom Rini]

On Wed, Jun 19, 2002 at 01:21:06PM +0200, Steven Scholz wrote:

> Steven Scholz wrote:
>
> > 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/

Re: board specific defines in commproc.h !?!?

[Steven Scholz]

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/

Re: board specific defines in commproc.h !?!?

[Tom Rini]

On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
>
> 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?

Oh yeah, right..  Hmm, it probably won't break anything then..

> > 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/

Re: board specific defines in commproc.h !?!?

[Steven Scholz]

Tom Rini wrote:
>
> On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
> >
> > 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?
>
> Oh yeah, right..  Hmm, it probably won't break anything then..
>
> > > 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/

Re: board specific defines in commproc.h !?!?

[Tom Rini]

On Wed, Jun 19, 2002 at 05:33:41PM +0200, Steven Scholz wrote:
>
> Tom Rini wrote:
> >
> > On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
> > >
> > > 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?
> >
> > Oh yeah, right..  Hmm, it probably won't break anything then..
> >
> > > > 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?

Shortly after I see if 2.5.23 boots/compiles for classic PPC :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Steven Scholz]

Tom Rini wrote:
> > 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?

Steven

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Tom Rini]

On Wed, Jun 19, 2002 at 05:47:18PM +0200, Steven Scholz wrote:
> Tom Rini wrote:
> > > 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/

Re: board specific defines in commproc.h !?!?

[Dan Malek]

Tom Rini wrote:

> On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
>

>>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/

Re: board specific defines in commproc.h !?!?

[Tom Rini]

On Wed, Jun 19, 2002 at 05:11:36PM -0400, Dan Malek wrote:
> Tom Rini wrote:
>
> >On Wed, Jun 19, 2002 at 05:18:04PM +0200, Steven Scholz wrote:
> >
>
> >>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/

Re: board specific defines in commproc.h !?!?

[Wolfgang Denk]

Dan,

in message <3D10F388.5@embeddededge.com> you wrote:
>
> The 2.4 source base is no longer supposed to be a development base.
...
> 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.

So what is your suggestion if I want to provide a patch that supports
some new hardware?

Obviously I want to get it added to a stable tree, so we can  use  it
in  a real project. And often enough the hardware is instable enough,
so I don't need the additional thrill of an instable Linux kernel.


I understand that 2.4 should get stable, but  there  is  a  huge  gap
between  2.4  and 2.5, so neither fits - well, actually 2.4 fits _my_
requirements.

What do you recommend to do?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
All these theories, diverse as they are, have two things  in  common:
they explain the observed facts, and they are completeley and utterly
wrong.                       - Terry Pratchett, _The Light Fantastic_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Conn Clark]

I'm going to regret getting involved in this, but here it goes.

In my opinion...

New support/structural changes/etc... belong in the Development kernel.
At some point I do belive that "some" of these changes should be
eligable to be back ported and included in the stable kernel after
they are proven.


Anybody can write/maintain/distribute a patch to any kernel they want,
It just won't get included in a stable tree until the above is met and
agreed to by some form of concensus. Deadlocks should be settled by
Doom Deathmatches, Russian rollete, or whatever.


What ever our policy evolves into I think it needs to be Documented
and posted someplace. We may need to talk to other processor trees and
Linus so we can get this thing settled once and for all.


Conn


--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[Dan Malek]

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/

Re: board specific defines in commproc.h !?!?

[Dan Malek]

Wolfgang Denk wrote:


> So what is your suggestion if I want to provide a patch that supports
> some new hardware?

I personally always do it first in the new, development tree (2.5 in
this case), then move it into the current stable tree.  It isn't that
you don't ever put new things into the stable tree, you just can't treat
it as a development tree.  Any "cosmetic" changes shouldn't be done in
a stable tree.


> ..... And often enough the hardware is instable enough,
> so I don't need the additional thrill of an instable Linux kernel.

Well, that is a challenge but you are likely to have some similar hardware
that will provide a stability reference.  Anything new won't work better
than something that is proven.  The main reason I like doing the new hardware
in 2.5 is that way it is carried along as the software evolves.  I have seen
lots of updates lost in newer kernels because someone decided to "do it later",
then when it becomes the next stable kernel everyone is in a panic to get
their updates done :-)

Thanks.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: board specific defines in commproc.h !?!?

[John Traill]

Everyone/Anyone,

Does this mean linuxppc_2_4_devel will disappear leaving a 2.4 stable tree and a 2.5 devel ?


Paul Mackerras wrote:
> Steven Scholz writes:
>
>
>>I am not quite sure about the policies now. Could you please explain:
>>
>>linuxppc_2_4		is a stable tree
>>linuxppc_2_4_devel	is a devel tree
>>linuxppc_2_5		is a devel tree
>>
>>Is that right?
>
>
> 2_4_devel is stabilizing.  Once 2.4.19 comes out the plan is to
> restructure the linuxppc_2_4 tree along the lines of the 2_4_devel
> tree and start moving the stuff from 2_4_devel into 2_4 and submit it
> to Marcelo.
>
> With 2.5, I am hoping to be able to keep Linus' tree in closer sync
> with our linuxppc-2.5 tree than we managed in the past with the 2_4
> trees.
>
> Paul.
>


--

Regards, John


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/