linuxsh-dev

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Thu, 2001-12-06 at 20:41, NIIBE Yutaka wrote:

> Sorry, I don't share your view.  No, I don't say you're wrong.  I
> think that it's a sort of matter of taste or discipline (work style).

Sorry, but I can't see any rational reason for putting an if 0 in code
such that it disables perfectly working code under other arches.

If you have a superior solution, go for it.

Regardless, you are the maintainer and I respect that.  Your call.

> Ideal stuation would be like that (fully compatible and fully
> synchronized), but there are some parts which is not, _always_.
> Sometimes, we have to maintain the differences, say, a year or so to
> get merged.  It's unwise, well, quite impractical to ignore the
> existence of diversion.  If it's really being synched, there is no
> sence to have SH repository, in the first place.

I disagree.  I think in an ideal world, we would not diverge at all. 
But we can't honestly expect to develop in sync with Linus and the x86
arch so we have to work separately.  Having a CVS repository exists to
make the job easier; nothing else.

Maintaining a divergent tree makes things harder on everyone.  It makes
syncing on our end harder.  It causes changes to the kernel with no
regard to what we are doing (since no one knows). Etc etc ...

What sort of problem does someone sending a diff off to Linus and
Marcelo cause?  It makes our "drop in" tree smaller and our resyncing
easy.

> And it has been _me_ (and I think still _is_) who work for the
> synchronization.  And I ask you and others to leave it as #if 0,
> because it is good for me to do the synchronization work.

Well, I am here offering to help you -- but again, its you call.

> Having SH repository, people only commit to the repository, not try to
> send the patch to main line.  That's quite bad thing, because it may
> result more diversion and bad quality.  I had spent much time for the
> work of synchronization, and my experience says "don't hide the issue
> if there is work remained for merge".

What do you mean by this?

> If you really want (looks like) sane version, you can have your own
> version.

No, I don't intend to ever divert anything from your control.  A fork is
not going to get us anywhere here.  I just want to _help you_.

> Yes, it depends who does that.
> 
>  > Which brings me to the next point ... the trees are way out of sync. 
> 
> I agree I have things to be done.

Completely understandable.

>  > When was the last time someone pushed an SH merge off to the official
>  > kernel?
> 
> It is me, because I am a maintainer.  It was late 2.4.13.  Since that
> time, because of the priority of GCC synchronization, I have been
> spent most of time to have GCC patches to gather, send to upstream,
> evaluate, generate local patches, etc. 

Understandable; your gcc work is _very_ appreciated.

>  > I would be happy to put together a diff against the latest 2.4 and 2.5
>  > and send it off to Marcelo and Linus for merging into their tree.  I
>  > suspect it will take some work to make sure we keep the code correct
>  > (ie, nothing like the #if 0 stuff).  I would want the maintainer's
>  > permission before I do this.
> 
> Thanks for offering help, but no thank you for this work.  It
> complicate things in a bad way, if I can't see how things are going.
> 
> It is, say, "serialization".  In many cases, this style works well,
> although sometimes it's the bottle neck.  To avoid confusion of
> diversion, it is known to best to serialize merge of the work.

I made a patch of SH drop-in (and my pending patches) vs 2.4.17-pre5. 
The non-SH stuff is trivial.  In other words, not much syncing needs to
be done on our side.  It is their side that needs to catch up to us.  Of
course, what did need to be done would be posted to this list for all to
see.

>  > Second, with 2.5 starting, we need conversion to both CML2 and
>  > kbuild-2.5.
> 
> Yes.  I think that I notified people some time last year, and Greg
> also mentioned last month.
> 
>  > Both are non-trivial changes.  The SH port is the _only_
>  > piece of the kernel non-synced with CML2, supposedly at the maintainer's
>  > request that he do it?
> 
> No.  I don't request.  It's simple, I asked, but none does that.

Well, CML2 is going in 2.5 in a release or two.  Eric Raymond
specifically says SH is out of sync -- and is the only thing out of sync
-- at the maintainers request that he do it himself.  We won't work in
2.5 until this is fixed.

>  > Also, SH items in Configure.help are very lacking.  CML2 will _not_
>  > allow an item to be selected if in non-expert mode if it has no
>  > configure help!  And kbuild-2.5 will require a rewrite of our
>  > makefiles...
> 
> Why don't you contribute this part?  I think that there's no objection
> for 2.5 tree to do that job.  If you don't have write access to the
> repository, please ask.

	Robert Love

Re: [linuxsh-dev] Drop-In tree updates

[Tom R. <tr...@ke...>]

On Thu, Dec 06, 2001 at 09:44:34PM -0500, Robert Love wrote:
> On Thu, 2001-12-06 at 20:41, NIIBE Yutaka wrote:
> 
> > Ideal stuation would be like that (fully compatible and fully
> > synchronized), but there are some parts which is not, _always_.
> > Sometimes, we have to maintain the differences, say, a year or so to
> > get merged.  It's unwise, well, quite impractical to ignore the
> > existence of diversion.  If it's really being synched, there is no
> > sence to have SH repository, in the first place.
> 
> I disagree.  I think in an ideal world, we would not diverge at all. 
> But we can't honestly expect to develop in sync with Linus and the x86
> arch so we have to work separately.  Having a CVS repository exists to
> make the job easier; nothing else.

Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
useable tree.  It's always good to try and sync up with
Linus/Marcelo/Alan, but you don't want to be sending every diff to them
either.  In the ideal world, kernel.org works for the 95% case for
$(ARCH) and gets updated from the community tree.

> Maintaining a divergent tree makes things harder on everyone.  It makes
> syncing on our end harder.  It causes changes to the kernel with no
> regard to what we are doing (since no one knows). Etc etc ...

It depends on just how divergent.  The sparc tree has some very
different code from time to time than what Linus does, and it either
gets merged or tossed.  Same deal for the PPC _devel tree.  If you put a
comment (or a msg or two to a relevant list) people know or can figure
it out.

> What sort of problem does someone sending a diff off to Linus and
> Marcelo cause?  It makes our "drop in" tree smaller and our resyncing
> easy.

You can't just 'send off a diff', you need to create it, test it a bit,
and hope it doesn't cause any problems.  And then that
Linus/Marcelo/Alan doesn't loose it in a flood of other patches/emails.

> Well, CML2 is going in 2.5 in a release or two.  Eric Raymond
> specifically says SH is out of sync -- and is the only thing out of sync
> -- at the maintainers request that he do it himself.  We won't work in
> 2.5 until this is fixed.

Working in 2.5 is a non-issue for the moment.  2.5 won't work on x86 for 
a while. Hell, I imagine it'll take a while before Linus doesn't drop 
other arch patches on the floor.

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

Re: [linuxsh-dev] Drop-In tree updates

[M. R. B. <mr...@0x...>]

* Tom Rini <tr...@ke...> on Thu, Dec 06, 2001:

>=20
> Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
> useable tree.  It's always good to try and sync up with
> Linus/Marcelo/Alan, but you don't want to be sending every diff to them
> either.  In the ideal world, kernel.org works for the 95% case for
> $(ARCH) and gets updated from the community tree.
>=20

Call me unorthadox, but, why not?  You see hundreds of small patches on
lkml daily.  Why can't we be in that flurry as well?  Who says that arch
changes must come in one big lump?  According to Linus, they're less likely
to be accepted if they do come in large sizes.

>=20
> You can't just 'send off a diff', you need to create it, test it a bit,
> and hope it doesn't cause any problems.  And then that
> Linus/Marcelo/Alan doesn't loose it in a flood of other patches/emails.
>=20

Um, couldn't "sending a diff off" be interpreted as the 3 steps you just
listed? :)

>=20
> Working in 2.5 is a non-issue for the moment.  2.5 won't work on x86 for=
=20
> a while. Hell, I imagine it'll take a while before Linus doesn't drop=20
> other arch patches on the floor.
>=20

I think everyone can agree on that.  But we still need to get changes for
2.4.x out...

M. R.

Re: [linuxsh-dev] Drop-In tree updates

[Tom R. <tr...@ke...>]

On Thu, Dec 06, 2001 at 10:35:01PM -0600, M. R. Brown wrote:
> * Tom Rini <tr...@ke...> on Thu, Dec 06, 2001:
> 
> > 
> > Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
> > useable tree.  It's always good to try and sync up with
> > Linus/Marcelo/Alan, but you don't want to be sending every diff to them
> > either.  In the ideal world, kernel.org works for the 95% case for
> > $(ARCH) and gets updated from the community tree.
> 
> Call me unorthadox, but, why not?  You see hundreds of small patches on
> lkml daily.  Why can't we be in that flurry as well?

How many of those get picked up?  Alan was pretty good about it, and
hopefully Marcelo will be too.  But also how many of those are for the
same system?

> Who says that arch
> changes must come in one big lump?  According to Linus, they're less likely
> to be accepted if they do come in large sizes.

It all falls under 'Zen and the art of getting your patch to Linus' I
think.  There are no real rule.  I've seen Linus ignore 5 small
incremental patches and then pick them up when someone else resends 'em
as one large patch.  I've also gotten 5 small patches in.  And sometimes
you can't break changes down all that much (at least in unstable/dev
stuff).

> > You can't just 'send off a diff', you need to create it, test it a bit,
> > and hope it doesn't cause any problems.  And then that
> > Linus/Marcelo/Alan doesn't loose it in a flood of other patches/emails.
> 
> Um, couldn't "sending a diff off" be interpreted as the 3 steps you just
> listed? :)

Well yes, but they do entail a bit more than what robert implied anyhow.
It usually takes some twisting of clue-enabled users to test things too.

> > Working in 2.5 is a non-issue for the moment.  2.5 won't work on x86 for 
> > a while. Hell, I imagine it'll take a while before Linus doesn't drop 
> > other arch patches on the floor.
> 
> I think everyone can agree on that.  But we still need to get changes for
> 2.4.x out...

Most definatly.

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

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Thu, 2001-12-06 at 23:19, Tom Rini wrote:

> Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
> useable tree.  It's always good to try and sync up with
> Linus/Marcelo/Alan, but you don't want to be sending every diff to them
> either.  In the ideal world, kernel.org works for the 95% case for
> $(ARCH) and gets updated from the community tree.

I completely agree.

My point was that ideally there would be no syncing at all.  For
example, SH could be one of many modules in the official linux CVS.  We
take care of that.  If we touch non-SH code, we hand it to takes care of
that.

> > Maintaining a divergent tree makes things harder on everyone.  It makes
> > syncing on our end harder.  It causes changes to the kernel with no
> > regard to what we are doing (since no one knows). Etc etc ...
> 
> It depends on just how divergent.  The sparc tree has some very
> different code from time to time than what Linus does, and it either
> gets merged or tossed.  Same deal for the PPC _devel tree.  If you put a
> comment (or a msg or two to a relevant list) people know or can figure
> it out.

I think sparc is an exception because its in vger, which can be said to
be its own kernel tree.

But I really do think PPC is a good example of how to manage a non-x86
port.  PPC64 maybe not (IBM is heavily involved <grin>), but PPC seems
pretty well off.

> You can't just 'send off a diff', you need to create it, test it a bit,
> and hope it doesn't cause any problems.  And then that
> Linus/Marcelo/Alan doesn't loose it in a flood of other patches/emails.

Agreed.  We have a current CVS, and we know it works.  I rediffed it
against 2.4.17-pre5 and it seems fine.  So the SH part is trivial.  Now,
non-SH stuff is a minimum (I think we touch _one_ non-SH-specific item)
so that is trivial too.

> > Well, CML2 is going in 2.5 in a release or two.  Eric Raymond
> > specifically says SH is out of sync -- and is the only thing out of sync
> > -- at the maintainers request that he do it himself.  We won't work in
> > 2.5 until this is fixed.
> 
> Working in 2.5 is a non-issue for the moment.  2.5 won't work on x86 for 
> a while. Hell, I imagine it'll take a while before Linus doesn't drop 
> other arch patches on the floor.

	Robert Love

Re: [linuxsh-dev] Drop-In tree updates

[Tom R. <tr...@ke...>]

On Thu, Dec 06, 2001 at 11:41:19PM -0500, Robert Love wrote:
> On Thu, 2001-12-06 at 23:19, Tom Rini wrote:
> 
> > Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
> > useable tree.  It's always good to try and sync up with
> > Linus/Marcelo/Alan, but you don't want to be sending every diff to them
> > either.  In the ideal world, kernel.org works for the 95% case for
> > $(ARCH) and gets updated from the community tree.
> 
> I completely agree.
> 
> My point was that ideally there would be no syncing at all.  For
> example, SH could be one of many modules in the official linux CVS.  We
> take care of that.  If we touch non-SH code, we hand it to takes care of
> that.

That's sort-of how *BSD works.  We have The One True Tree which everyone
else has a backup of on their harddrive now :)

> > > Maintaining a divergent tree makes things harder on everyone.  It makes
> > > syncing on our end harder.  It causes changes to the kernel with no
> > > regard to what we are doing (since no one knows). Etc etc ...
> > 
> > It depends on just how divergent.  The sparc tree has some very
> > different code from time to time than what Linus does, and it either
> > gets merged or tossed.  Same deal for the PPC _devel tree.  If you put a
> > comment (or a msg or two to a relevant list) people know or can figure
> > it out.
> 
> I think sparc is an exception because its in vger, which can be said to
> be its own kernel tree.

vger is as much of it's own tree as the PPC one.  It's got sparc* and
network stuff (since DaveM is the maintainer of that too).  There's also
the ARM trees and I know m68k has a tree.  My point being that an
$(ARCH) tree is an important thing to have.

> But I really do think PPC is a good example of how to manage a non-x86
> port.  PPC64 maybe not (IBM is heavily involved <grin>), but PPC seems
> pretty well off.

Well, PPC64 isn't in kernel.org either, so lets ignore it for now.

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

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

Robert, thanks for your offering help.

My idea is like following for the cache handling.  I think that it
would be the things for 2.5 because it includes API change.

  (1) Think about API (set) of cache handling for 2.5.
  (2) Propose new API to lkml, ask review from another arch people, 
      possibly with example API changes to some archtectures including
      SH.
  (3) When it will be applied to mainline kernel, we can remove
      ugly #if-0-outed line from LinuxSH kernel of 2.5.
  (4) Backport the API change if it's really stable. 

If you want to do this, I don't stop you.  But could you please not
to send #ifdef CONFIG_SUPREH version to mainline.

			*	*	*

Changes in generic code requires time, occasionally _much_ time to
synchronize.  I'd say, be patient.  For me, in some cases, it takes a
year or so.

One good example is a cache flush at swaping code.  It has been wrong
for a long time for some architecture.  I did put some work around for
SuperH in 1999.  Some time later, I've found a proper fix, then I've
proposed the changes last year.  At that time Dave Miller agreed the
fix as some Sparc chip has same issues.  However, it does not get in
for a half of year.  Then, MIPS people foundd same issue, and I resent
a patch, which finally got in.  I needed to maintain it over a year
before it got merged.

 > Maintaining a divergent tree makes things harder on everyone.  It makes
 > syncing on our end harder.  It causes changes to the kernel with no
 > regard to what we are doing (since no one knows). Etc etc ...

I don't say divergence is good thing.  I say we need to maintain
divergence.  If we have changes in generic code, we need to maintain
the divergence, because it is very difficult to get merged.

Because it is hard to maintain divergence, we need to take care.
-- 

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Fri, 2001-12-07 at 08:40, NIIBE Yutaka wrote:
> Robert, thanks for your offering help.
> 
> My idea is like following for the cache handling.  I think that it
> would be the things for 2.5 because it includes API change.
> 
>   (1) Think about API (set) of cache handling for 2.5.
>   (2) Propose new API to lkml, ask review from another arch people, 
>       possibly with example API changes to some archtectures including
>       SH.
>   (3) When it will be applied to mainline kernel, we can remove
>       ugly #if-0-outed line from LinuxSH kernel of 2.5.
>   (4) Backport the API change if it's really stable. 

This is very good.  I would be happy to help you or otherwise work on
it.  What is needed, as dwmw2 pointed out, is an API like this to handle
all the arches needs.

> If you want to do this, I don't stop you.  But could you please not
> to send #ifdef CONFIG_SUPREH version to mainline.

I won't do anything without your blessing.

However, a couple ideas: we need to realize that the above is a
2.5-thing, and could take a _very_ long time to design, implement, test,
and finally have merged.  In the mean time, SH will grow further and
further out of sync.

I propose we work on the above API.  In the mean time, lets sync the
trees.  We do _not_ have to include the code you don't want. 
Possibilities:

(a) Don't send anything for mm/memory.c -- in our tree, keep it if'ed
out.  In the official tree, keep it as-is.  This means we keep the
reminder, we don't have the needless code, and the official tree doesn't
see anything yet.

(b) Implement the API for just that one file.  Something like:

#ifdef CONFIG_SH
#define flush_cache_page_xxx(a, b)
#elif /* arches that need it */
#define flush_cache_xxx(a, b) flush_cache_page(a, b)
#endif

where xxx is this specific use of the cache flush.

I think the ideal solution for the API is something like
include/asm/cache_policy.h

where the proper uses of the various cache flushings are defined as
needed.  Obviously we can't do that just yet...but the above is
essentially the same thing.

(c) just merge choice parts.  for instance, merge our changes to 8139too
to the maintainer (and have him merge the changes to Linus/marcelo). 
8139too is changing and its going to break our patches.

> Changes in generic code requires time, occasionally _much_ time to
> synchronize.  I'd say, be patient.  For me, in some cases, it takes a
> year or so.

I understand.  What we disagree about is that we can't work around the
issue for the time-being.  From above, I think (a) and (b) offer the
ability to synchronize our tree, but for our CVS repository to keep the
development changes.  We work on the new API there, and we can send a
solution to the official 2.5 tree when that time comes.

At least, do this for 2.4 ... but even with 2.5, things will get
progressively out of sync and we should send _some_ stuff out.

> One good example is a cache flush at swaping code.  It has been wrong
> for a long time for some architecture.  I did put some work around for
> SuperH in 1999.  Some time later, I've found a proper fix, then I've
> proposed the changes last year.  At that time Dave Miller agreed the
> fix as some Sparc chip has same issues.  However, it does not get in
> for a half of year.  Then, MIPS people foundd same issue, and I resent
> a patch, which finally got in.  I needed to maintain it over a year
> before it got merged.

Honestly, that is terrible :)

I hope we don't grow out of sync for two years ...

>  > Maintaining a divergent tree makes things harder on everyone.  It makes
>  > syncing on our end harder.  It causes changes to the kernel with no
>  > regard to what we are doing (since no one knows). Etc etc ...
> 
> I don't say divergence is good thing.  I say we need to maintain
> divergence.  If we have changes in generic code, we need to maintain
> the divergence, because it is very difficult to get merged.
> 
> Because it is hard to maintain divergence, we need to take care.

Agreed, you have a very good foresight and understanding of maintenance.

Please consider the suggestions above.  Let's synchronize things as much
as possible.  I agree we have a maintenance issue with the cache flush
stuff -- let's not touch that now, then.  We can leave it as-is and we
will fix it in due time.  The CVS tree will remain if 0 or whatever API
we begin to work on.

Remember, there is already SH work in the official kernel.  We are just
bringing it further up to date.  Cache issue is no better there, either
...

	Robert Love

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

Robert Love wrote:
 > However, a couple ideas: we need to realize that the above is a
 > 2.5-thing, and could take a _very_ long time to design, implement, test,
 > and finally have merged.  In the mean time, SH will grow further and
 > further out of sync.

Agreed.

 > (a) Don't send anything for mm/memory.c -- in our tree, keep it if'ed
 > out.  In the official tree, keep it as-is.  This means we keep the
 > reminder, we don't have the needless code, and the official tree doesn't
 > see anything yet.

For mm/memory.c, I think this is good.  Official tree works anyway, though
runs with bad performance.

 > (b) Implement the API for just that one file.  Something like:

Please look at Documentation/cachetlb.txt, we should add new routine here.

 > I understand.  What we disagree about is that we can't work around the
 > issue for the time-being.

No, I don't.  While I disagreed the handling of mm/memory.c, but I agree
that we should think and act for the synch to mainline.

 > Please consider the suggestions above.  Let's synchronize things as much
 > as possible.

Yes.

My plan for this week is like following:
	(1) Check the patches I hold, and check in to the repository:
		big-endian bug for users.h
		discontigous memory handling
		configuration issues (i.e., config.in and config.help)
	(2) Check the difference between 2.4 and repository
	    and send it to upstream.
	(3) Check the difference between 2.5 and repository
	    and send it to upstream.
	(4) Gather opinion and features for 2.5

For (2) or (3) I think that I will submit the difference to this list
before sending to upstream, so that people can see what's going on
more clearly.  Please note that I don't send all the difference, and
sometimes some parts may not be included by the upstream maintainer.

For (4), keeping up to kbuild is major one.

I have a question to M.R.  How do you think about the drivers for DC?
Is it ready for inclusion of mainline?  I don't know 2.4 opens for new
drivers or not, but at least it's worth sending those to 2.5. 
-- 

Re: [linuxsh-dev] Drop-In tree updates

[Paul M. <pm...@mv...>]

On Mon, Dec 10, 2001 at 09:35:16AM +0900, NIIBE Yutaka wrote:
> I have a question to M.R.  How do you think about the drivers for DC?
> Is it ready for inclusion of mainline?  I don't know 2.4 opens for new
> drivers or not, but at least it's worth sending those to 2.5.=20

Things like pvr2fb and the AICA RTC code are already in mainline. Maple is
currently undergoing a rewrite, and hopefully we'll be able to replace the
current implementation with that shortly. The current maple implementation
should never leave this tree.

As far as GD-ROM support goes.. that's pending a proper implementation as
well, since the current driver isn't anything other then a hack of a port o=
f a
hack of a driver from NetBSD..

Are there any other drivers you were referring to that I missed?

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

Paul Mundt wrote:
 > Things like pvr2fb and the AICA RTC code are already in mainline. Maple is
 > currently undergoing a rewrite, and hopefully we'll be able to replace the
 > current implementation with that shortly. The current maple implementation
 > should never leave this tree.
 > 
 > As far as GD-ROM support goes.. that's pending a proper implementation as
 > well, since the current driver isn't anything other then a hack of a port o=
 > f a
 > hack of a driver from NetBSD..
 > 
 > Are there any other drivers you were referring to that I missed?

Following files:
 drivers/cdrom/gdrom.c
 drivers/char/dc_keyb.c
 drivers/char/joystick/maplecontrol.c
 drivers/char/maple_keyb.c
 drivers/char/maplemouse.c
 drivers/maple/Config.in
 drivers/maple/Makefile
 drivers/maple/maple.c
 include/linux/maple.h

Without maple implementation, maplecontrol.c, maple_keyb.c and
maplemouse.c have nonsence.  So, we leave the files above in our tree, 
not sending to mainline, OK?
 
Here is diffstats output for the divergence between 2.4.16 and our
2.4 based tree (with no files above).

--------------------------
 arch/sh/kernel/sys_sh.c-1.7                    |  236 ++++++++++
 Documentation/sh/new-machine.txt               |   77 +++
 include/asm-sh/mmzone.h                        |   61 ++
 drivers/mtd/maps/solutionengine.c              |   47 +-
 include/asm-sh/stat.h                          |   25 -
 drivers/net/8139too.c                          |   25 +
 drivers/mtd/mtdpart.c                          |   11 
 drivers/mtd/maps/Config.in                     |   11 
 arch/sh/kernel/io_7751se.c                     |    8 
 include/linux/mtd/partitions.h                 |    7 
 drivers/pci/pci.ids                            |    7 
 drivers/char/shwdt.c                           |    7 
 arch/sh/kernel/traps.c                         |    7 
 include/asm-sh/segment.h                       |    6 
 Documentation/Configure.help                   |    6 
 include/asm-sh/pci.h                           |    5 
 drivers/char/joystick/Config.in                |    5 
 drivers/char/Makefile                          |    5 
 init/main.c                                    |    3 
 include/linux/input.h                          |    3 
 include/asm-sh/uaccess.h                       |    3 
 drivers/net/Config.in                          |    3 
 drivers/Makefile                               |    3 
 mm/memory.c                                    |    2 
 include/asm-sh/namei.h                         |    2 
 include/asm-sh/linux_logo.h                    |    2 
 include/asm-sh/keyboard.h                      |    2 
 include/asm-sh/ioctl.h                         |    2 
 include/asm-sh/io_dc.h                         |    2 
 include/asm-sh/hitachi_se.h                    |    2 
 include/asm-sh/hd64465_gpio.h                  |    2 
 include/asm-sh/hd64465.h                       |    2 
 include/asm-sh/hd64461.h                       |    2 
 include/asm-sh/cache.h                         |    2 
 drivers/video/hitfb.c                          |    2 
 drivers/pcmcia/hd64465_ss.c                    |    2 
 drivers/char/sh-sci.h                          |    2 
 drivers/char/sh-sci.c                          |    2 
 drivers/char/scan_keyb.c                       |    2 
 drivers/char/joystick/Makefile                 |    2 
 drivers/char/hp600_keyb.c                      |    2 
 arch/sh/vmlinux.lds.S                          |    2 
 arch/sh/mm/ioremap.c                           |    2 
 arch/sh/mm/init.c                              |    2 
 arch/sh/mm/fault.c                             |    2 
 arch/sh/mm/extable.c                           |    2 
 arch/sh/mm/copy_page.S                         |    2 
 arch/sh/mm/clear_page.S                        |    2 
 arch/sh/mm/cache-sh4.c                         |    2 
 arch/sh/mm/cache-sh3.c                         |    2 
 arch/sh/mm/__copy_user_page-sh4.S              |    2 
 arch/sh/mm/__clear_user_page-sh4.S             |    2 
 arch/sh/lib/strlen.S                           |    2 
 arch/sh/lib/memset.S                           |    2 
 arch/sh/lib/memmove.S                          |    2 
 arch/sh/lib/memcpy.S                           |    2 
 arch/sh/lib/memchr.S                           |    2 
 arch/sh/lib/checksum.S                         |    2 
 arch/sh/kernel/time.c                          |    2 
 arch/sh/kernel/signal.c                        |    2 
 arch/sh/kernel/sh_bios.c                       |    2 
 arch/sh/kernel/setup_se.c                      |    2 
 arch/sh/kernel/setup_hd64465.c                 |    2 
 arch/sh/kernel/setup_hd64461.c                 |    2 
 arch/sh/kernel/setup_cqreek.c                  |    2 
 arch/sh/kernel/setup.c                         |    2 
 arch/sh/kernel/ptrace.c                        |    2 
 arch/sh/kernel/process.c                       |    2 
 arch/sh/kernel/pcibios.c                       |    2 
 arch/sh/kernel/pci-sh7751.c                    |    2 
 arch/sh/kernel/pci-dc.c                        |    2 
 arch/sh/kernel/mach_dc.c                       |    2 
 arch/sh/kernel/irq_ipr.c                       |    2 
 arch/sh/kernel/irq_imask.c                     |    2 
 arch/sh/kernel/irq.c                           |    2 
 arch/sh/kernel/io_se.c                         |    2 
 arch/sh/kernel/io_hd64465.c                    |    2 
 arch/sh/kernel/io_hd64461.c                    |    2 
 arch/sh/kernel/io_generic.c                    |    2 
 arch/sh/kernel/io_dc.c                         |    2 
 arch/sh/kernel/head.S                          |    2 
 arch/sh/kernel/hd64465_gpio.c                  |    2 
 arch/sh/kernel/fpu.c                           |    2 
 arch/sh/kernel/entry.S                         |    2 
 arch/sh/kernel/cf-enabler.c                    |    2 
 arch/sh/config.in                              |    2 
 arch/sh/Makefile                               |    2 
 Documentation/cachetlb.txt                     |    2 
 kernel/ptrace.c                                |    1 
 include/linux/highmem.h                        |    1 
 drivers/cdrom/Makefile                         |    1 
 drivers/cdrom/Config.in                        |    1 
 drivers/block/rd.c                             |    1 
 arch/sh/kernel/pci-7751se.c                    |    1 
 Makefile                                       |    1 
-- 

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

NIIBE Yutaka wrote:
 >  arch/sh/kernel/sys_sh.c-1.7                    |  236 ++++++++++

This is a garbage, I put the other day.  I remove this file.

These 59 files are noly $Id$ difference, so leave them.

 >  arch/sh/Makefile                               |    2 
 >  arch/sh/kernel/cf-enabler.c                    |    2 
 >  arch/sh/kernel/entry.S                         |    2 
 >  arch/sh/kernel/fpu.c                           |    2 
 >  arch/sh/kernel/hd64465_gpio.c                  |    2 
 >  arch/sh/kernel/head.S                          |    2 
 >  arch/sh/kernel/io_dc.c                         |    2 
 >  arch/sh/kernel/io_generic.c                    |    2 
 >  arch/sh/kernel/io_hd64461.c                    |    2 
 >  arch/sh/kernel/io_hd64465.c                    |    2 
 >  arch/sh/kernel/io_se.c                         |    2 
 >  arch/sh/kernel/irq.c                           |    2 
 >  arch/sh/kernel/irq_imask.c                     |    2 
 >  arch/sh/kernel/irq_ipr.c                       |    2 
 >  arch/sh/kernel/mach_dc.c                       |    2 
 >  arch/sh/kernel/pci-dc.c                        |    2 
 >  arch/sh/kernel/pcibios.c                       |    2 
 >  arch/sh/kernel/process.c                       |    2 
 >  arch/sh/kernel/ptrace.c                        |    2 
 >  arch/sh/kernel/setup.c                         |    2 
 >  arch/sh/kernel/setup_cqreek.c                  |    2 
 >  arch/sh/kernel/setup_hd64461.c                 |    2 
 >  arch/sh/kernel/setup_hd64465.c                 |    2 
 >  arch/sh/kernel/setup_se.c                      |    2 
 >  arch/sh/kernel/sh_bios.c                       |    2 
 >  arch/sh/kernel/signal.c                        |    2 
 >  arch/sh/kernel/time.c                          |    2 
 >  arch/sh/lib/checksum.S                         |    2 
 >  arch/sh/lib/memchr.S                           |    2 
 >  arch/sh/lib/memcpy.S                           |    2 
 >  arch/sh/lib/memmove.S                          |    2 
 >  arch/sh/lib/memset.S                           |    2 
 >  arch/sh/lib/strlen.S                           |    2 
 >  arch/sh/mm/__clear_user_page-sh4.S             |    2 
 >  arch/sh/mm/__copy_user_page-sh4.S              |    2 
 >  arch/sh/mm/cache-sh3.c                         |    2 
 >  arch/sh/mm/cache-sh4.c                         |    2 
 >  arch/sh/mm/clear_page.S                        |    2 
 >  arch/sh/mm/copy_page.S                         |    2 
 >  arch/sh/mm/extable.c                           |    2 
 >  arch/sh/mm/fault.c                             |    2 
 >  arch/sh/mm/init.c                              |    2 
 >  arch/sh/mm/ioremap.c                           |    2 
 >  arch/sh/vmlinux.lds.S                          |    2 
 >  drivers/char/hp600_keyb.c                      |    2 
 >  drivers/char/sh-sci.c                          |    2 
 >  drivers/char/sh-sci.h                          |    2 
 >  drivers/pcmcia/hd64465_ss.c                    |    2 
 >  drivers/video/hitfb.c                          |    2 
 >  include/asm-sh/cache.h                         |    2 
 >  include/asm-sh/hd64461.h                       |    2 
 >  include/asm-sh/hd64465.h                       |    2 
 >  include/asm-sh/hd64465_gpio.h                  |    2 
 >  include/asm-sh/hitachi_se.h                    |    2 
 >  include/asm-sh/io_dc.h                         |    2 
 >  include/asm-sh/ioctl.h                         |    2 
 >  include/asm-sh/keyboard.h                      |    2 
 >  include/asm-sh/linux_logo.h                    |    2 
 >  include/asm-sh/namei.h                         |    2 
-- 

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

NIIBE Yutaka wrote:
 > Following files:
 >  drivers/cdrom/gdrom.c
 >  drivers/char/dc_keyb.c
 >  drivers/char/joystick/maplecontrol.c
 >  drivers/char/maple_keyb.c
 >  drivers/char/maplemouse.c
 >  drivers/maple/Config.in
 >  drivers/maple/Makefile
 >  drivers/maple/maple.c
 >  include/linux/maple.h

Besides, following files are meaningless without those files.
    Makefile
    driver/cdrom/Config.in
    driver/cdrom/Makefile
    driver/char/Makefile
    driver/char/joystic/Config.in
    driver/char/joystic/Makefile
    include/linux/input.h
-- 

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

* MTD driver

 >  drivers/mtd/maps/solutionengine.c              |   47 +-
 >  drivers/mtd/mtdpart.c                          |   11 
 >  drivers/mtd/maps/Config.in                     |   11 
 >  include/linux/mtd/partitions.h                 |    7 

Since these files are maintained by David Woodhouse, I don't send them to
mainline.


* 8139too driver

 >  Documentation/Configure.help                   |    6 
 >  drivers/net/8139too.c                          |   25 +

This is changes for 8139too, I and Takeshi sent them to 8139too
maintainer two or three times, but it has not yet included.
I don't know the status of this change.  Takeshi?


* MEMORY management, cache management

 >  Documentation/cachetlb.txt                     |    2 
 >  mm/memory.c                                    |    2 

I've changed the document slightly to follow current implementation.
I'm thinking new API for the chage of mm/memory.c.  Let's leave them.

 >  drivers/block/rd.c                             |    1 
 >  include/linux/highmem.h                        |    1 

These are paranoia thing which I put once.  I think that we should remove
them when we will find it's safe to remove.  Don't send them to mainline.

 >  kernel/ptrace.c                                |    1 

I think that this is needed.  Robert, could you please check this
and talk to Marcelo or DaveM.

 >  include/asm-sh/mmzone.h

This version is known not to work.  I think that Takeshi has newer
version.
-- 

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

We have change for drivers/pci/pci.ids.  Three lines are added, which
should not be an issue.  I don't know the chage of name

   SGS Thomson Microelectronics ===> STMicroelectronics

is right or not.

It would be good if we don't maintain this file in LinuxSH, if we
dont' have enough reason to do that.

Relevant person, could you please send your request to PCI.IDS
maintainer directly, so that we don't need to maintain it?


@@ -963,11 +963,12 @@
   1000  QuickStep 1000
   3000  QuickStep 3000
 1049  Fountain Technologies, Inc.
-104a  SGS Thomson Microelectronics
+104a  STMicroelectronics
       0008  STG 2000X
       0009  STG 1764X
       1746  STG 1764X
       3520  MPEG-II decoder card
+      2774  STE10/100A
 104b  BusLogic
       0140  BT-946C (old) [multimaster  01]
       1040  BT-946C (BA80C30) [MultiMaster 10]
@@ -2640,6 +2641,7 @@
 11aa  Actel
 11ab  Galileo Technology Ltd.
       0146  GT-64010
+      4146  GT-64111
       4801  GT-48001
       f003  GT-64010 Primary Image Piranha Image Generator
 11ac  Canon Information Systems Research Aust.
@@ -2794,6 +2796,7 @@
 11d9  TEC Corporation
 11da  Novell
 11db  Sega Enterprises Ltd
+      1234  Broadband Adapter
 11dc  Questra Corporation
 11dd  Crosfield Electronics Limited
 11de  Zoran Corporation
-- 

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Tue, 2001-12-11 at 01:32, NIIBE Yutaka wrote:
> We have change for drivers/pci/pci.ids.  Three lines are added, which
> should not be an issue.  I don't know the chage of name
> 
>    SGS Thomson Microelectronics ===> STMicroelectronics
> 
> is right or not.
> 
> It would be good if we don't maintain this file in LinuxSH, if we
> dont' have enough reason to do that.
> 
> Relevant person, could you please send your request to PCI.IDS
> maintainer directly, so that we don't need to maintain it?

I don't think there is a PCI ID maintainer, at least not anyone who does
anything important.  People just toss their changes to the kernel
maintainer.

I can't comment on the SGS Thomson -> STM change, but maybe it was down
because the full name is too long?  Unknown.  The rest look sane.

We should pass this on.

	Robert Love

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

STMicro people please confirm the pci.ids change is valid (or not).
At http://www.yourvote.com/pci/pciread.asp?sort=venid
The entry is:
	ST Microelectronics
(with space between ST and Microelectronics).

And for GT-64111, I've read a manual for GT-64111:
	http://cobalt22.cobalt.com/docs/gt64111_rev11.pdf

It says, the initial value is 0x4146 but ID number is 0x146.  I'm
confused.  Is that really valid entry?

I won't send the patch of pci.ids to maintainer, please do that by yourself.

For DC guys:

BTW, I've submit the information for Dreamcast BBA to
	http://www.yourvote.com/pci/pciread.asp
for inclusion.

I won't send the patch of pci.ids to maintainer, please do that by yourself.
-- 

Re: [linuxsh-dev] Drop-In tree updates

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Tue, Dec 11, 2001:

>=20
> For DC guys:
>=20
> BTW, I've submit the information for Dreamcast BBA to
> 	http://www.yourvote.com/pci/pciread.asp
> for inclusion.
>=20
> I won't send the patch of pci.ids to maintainer, please do that by yourse=
lf.

Cool.  No problem.

M. R.

Re: [linuxsh-dev] Drop-In tree updates

[Paul M. <pm...@mv...>]

On Tue, Dec 11, 2001 at 06:21:58PM +0900, NIIBE Yutaka wrote:
> And for GT-64111, I've read a manual for GT-64111:
> 	http://cobalt22.cobalt.com/docs/gt64111_rev11.pdf
>=20
> It says, the initial value is 0x4146 but ID number is 0x146.  I'm
> confused.  Is that really valid entry?
>=20
Looks like they got confused in their wording .. just for clarification,
device ID 0x146 refers to the GT64010A controller, which was one of their
earlist ones.

As far as what Cobalt shipped their configurations with, very early boards
(pre Cobalt-27 IIRC), shipped with the GT64011 (device ID 0x4146), which
Galileo later replaced with the GT64111. Since the GT64111 was intended as a
complete and total drop-in replacement for the GT64011, it retained the same
device ID. The only noticeable difference is that the GT64111 consumed a lot
less power, and supported voltages of both 3.3 and 5V.

Galileo also has a brief entry in their FAQ that compare the two and list
the changes in the GT64111, which can be obtained from here:

http://marvell.com/Products/Doc_Files/224/faq_gt64_641_960_961xxx.pdf)

The relevant section is found on pages 4 and 5.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

arch/sh/kernel/pci-sh7751.c

It seems Martin Mares' e-mail address has been changed, and it was applied
to mainline.  We should have change our file.
-- 

Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

Changes for drivers/net/Config.in

There're two changes.  One is Dreamcast change, another is CS89x0
support change.  Relevant persion, please send the change by yourself
to maintainer.
-- 

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Tue, 2001-12-11 at 01:20, NIIBE Yutaka wrote:

>  >  kernel/ptrace.c                                |    1 
> 
> I think that this is needed.  Robert, could you please check this
> and talk to Marcelo or DaveM.

At least with the changes in my tree, the kernel/ptrace.c works is
correct.  We should send it off.

	Robert Love

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Tue, 2001-12-11 at 01:20, NIIBE Yutaka wrote:
> * MTD driver
> 
>  >  drivers/mtd/maps/solutionengine.c              |   47 +-
>  >  drivers/mtd/mtdpart.c                          |   11 
>  >  drivers/mtd/maps/Config.in                     |   11 
>  >  include/linux/mtd/partitions.h                 |    7 
> 
> Since these files are maintained by David Woodhouse, I don't send them to
> mainline.

I've CC'ed David.  David, we are working on syncing the SH tree.  Note
maintainer is not sending your mtd work off -- I just wanted to make
sure you were aware.

If you get the chance it would be great to merge your changes upstream
with Marcelo and Linus :)

	Robert Love

Re: [linuxsh-dev] Drop-In tree updates

[David W. <dw...@in...>]

rm...@te... said:
>  I've CC'ed David.  David, we are working on syncing the SH tree.
> Note maintainer is not sending your mtd work off -- I just wanted to
> make sure you were aware.

> If you get the chance it would be great to merge your changes upstream
> with Marcelo and Linus :)

Feel free to send that part if you like. I'll then work from there when I
get round to syncing up again, which ought to be soon. Just let Linus and/or
Marcelo know I approved - not that Linus usually takes care to reject 
patches from non-maintainers anyway.

--
dwmw2

Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Tue, 2001-12-11 at 01:20, NIIBE Yutaka wrote:

> * 8139too driver
> 
>  >  Documentation/Configure.help                   |    6 
>  >  drivers/net/8139too.c                          |   25 +
> 
> This is changes for 8139too, I and Takeshi sent them to 8139too
> maintainer two or three times, but it has not yet included.
> I don't know the status of this change.  Takeshi?

Oh, I didn't notice this.  I don't know who you sent it to, but send it
to Jeff Garzick <jg...@ma...> and CC lkml and Marcelo.

I'll even do this if you like, I know Jeff.  Who did the 8139too work?

	Robert Love