Re: mac-2.3.14.diff: adb

Re: mac-2.3.14.diff: adb

[David D. Kilzer]

>>>>>> "David" == David D Kilzer <ddkilzer@computer.org> writes:
>
>David> Hi Jes, Patch description:
>
>David> ADB merge with PowerPC.  These are the m68k patches that need to
>David> be updated.  Joshua Thompson has already sent the PPC patches to
>David> that group.
>
>David> NEW FILES: arch/m68k/mac/misc.c drivers/macintosh/adb-iop.c
>David> drivers/macintosh/via-macii.c include/asm-m68k/adb_iop.h

Jes Sorensen <Jes.Sorensen@cern.ch> wrote:

>Do not belong here, create a drivers/adb if you need it - stop putting
>things in drivers/macintosh.

Well, drivers/macintosh is PPC ADB code.  If drivers/macintosh shouldn't
exist, then shouldn't it be changed or moved at a higher level?

In reality, there is some ADB mouse code in drivers/char, too, so I wonder
if drivers/char/adb would make more/less sense than drivers/adb?

Dave


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Jes Sorensen]

>>>>> "David" == David D Kilzer <ddkilzer@computer.org> writes:

David> Jes Sorensen <Jes.Sorensen@cern.ch> wrote:

>> Do not belong here, create a drivers/adb if you need it - stop
>> putting things in drivers/macintosh.

David> Well, drivers/macintosh is PPC ADB code.  If drivers/macintosh
David> shouldn't exist, then shouldn't it be changed or moved at a
David> higher level?

IMHO yes, ADB code will be useful to the NeXT people if they ever get
the port going.

David> In reality, there is some ADB mouse code in drivers/char, too, so
David> I wonder if drivers/char/adb would make more/less sense than
David> drivers/adb?

No drivers/adb to handle the ADB bus, the char driver should go in
drivers/char.

I always disliked drivers/macintosh and drivers/sbus/char for that
matter as it seems to me like it was just an easy way to get things past
Linus.

Jes

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Michael Schmitz]

Jes Sorensen wrote:
> No drivers/adb to handle the ADB bus, the char driver should go in
> drivers/char.
> 
> I always disliked drivers/macintosh and drivers/sbus/char for that
> matter as it seems to me like it was just an easy way to get things past
> Linus.

I agree - IIRC Paul created drivers/macintosh as a quick fix to get the
Mac drivers integrated. I've suggested to move things to other places,
but Alan sait this would be 
'a 2.3 thing' at that time. Seems a bit late for that now.

	Michael

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Jes Sorensen]

>>>>> "Michael" == Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> writes:

Michael> Jes Sorensen wrote:
>> No drivers/adb to handle the ADB bus, the char driver should go in
>> drivers/char.
>> 
>> I always disliked drivers/macintosh and drivers/sbus/char for that
>> matter as it seems to me like it was just an easy way to get things
>> past Linus.

Michael> I agree - IIRC Paul created drivers/macintosh as a quick fix to
Michael> get the Mac drivers integrated. I've suggested to move things
Michael> to other places, but Alan sait this would be 'a 2.3 thing' at
Michael> that time. Seems a bit late for that now.

IMHO there is still time, I doubt Linus would object to patch for this
at the moment.

Wouldn't it be natural to move the Mac 8530 serial driver to
drivers/char and the rest to drivers/adb? or is the via stuff not adb
related?

Paul what do you think?

Jes

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Michael Schmitz]

> Michael> I agree - IIRC Paul created drivers/macintosh as a quick fix to
> Michael> get the Mac drivers integrated. I've suggested to move things
> Michael> to other places, but Alan sait this would be 'a 2.3 thing' at
> Michael> that time. Seems a bit late for that now.
> 
> IMHO there is still time, I doubt Linus would object to patch for this
> at the moment.
> 
> Wouldn't it be natural to move the Mac 8530 serial driver to
> drivers/char and the rest to drivers/adb? or is the via stuff not adb
> related?

The general VIA stuff isn't ADB related via-cuda and via-pmu are the low
level ADB drivers though.

	Michael

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Paul Mackerras]

Jes Sorensen <Jes.Sorensen@cern.ch> wrote:

> Wouldn't it be natural to move the Mac 8530 serial driver to
> drivers/char and the rest to drivers/adb? or is the via stuff not adb
> related?
> 
> Paul what do you think?

The stuff in drivers/macintosh is basically stuff that I thought would
only be useful on macs (powermacs initially but also potentially 68k
macs).

What's in there breaks down into:

ADB drivers: adb.c, macio-adb.c, via-cuda.c, via-pmu.c, mac_keyb.c

zilog serial driver: macserial.[ch]

powerbook media bay driver: mediabay.c

/dev/nvram driver: nvram.c

The CUDA and PMU drivers both have several functions, of which talking
to the ADB bus is only one.  The CUDA and PMU are both responsible for
talking to the real-time clock and NVRAM, and for reset and soft-power
control.  The PMU also has the functions of controlling and reporting
on the battery status and for putting the system to sleep.  The PMU
driver exports a /dev/pmu device.

If there was a compelling reason for getting rid of drivers/macintosh,
sure we could find other homes for the files in it.  I haven't seen
any compelling reason yet though.  If the 68k-mac folks feel that they
can't use drivers/macintosh, that is unfortunate and certainly not
what I intended.

I think the idea of having a drivers/adb directory is reasonable, and
adb.c, mac_keyb.c and maybe adbmouse.c can go in there.  I don't see
that via-cuda.c and via-pmu.c really fit well in there though.  Maybe
the thing to do is to split the adb-related functions out of those
files and put them in cuda-adb.c and pmu-adb.c in drivers/adb.

I don't really mind whether macserial.[ch] stay in drivers/macintosh
or go to drivers/char.  drivers/sbus/char/sunserial.[ch] is a
precedent for keeping it in drivers/char.  nvram.c could go into
drivers/char, I guess, but would have to have a name change.  I don't
see that these things have to go in drivers/char just because they
implement a character device.

Paul.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[David D. Kilzer]

Paul Mackerras <Paul.Mackerras@cs.anu.edu.au> wrote:

>The stuff in drivers/macintosh is basically stuff that I thought would
>only be useful on macs (powermacs initially but also potentially 68k
>macs).

If anyone continues the NeXT port of Linux (LiNeXT), these systems also use
ADB for mouse and keyboard.  It seems to be kind of dead right now, though.

  http://www.black.linux-m68k.org/

>What's in there breaks down into:
>
>ADB drivers: adb.c, macio-adb.c, via-cuda.c, via-pmu.c, mac_keyb.c

Add to that 68k-only stuff:  adb-iop.c, via-macii.c [and adb-iisi.c which
doesn't exist at the moment].

>zilog serial driver: macserial.[ch]

In drivers/char there exists mac_SCC.[ch] for m68k Macs, though it needs to
exist on its own outside of m68kserial.c (which is going away soon :^).

>powerbook media bay driver: mediabay.c
>
>/dev/nvram driver: nvram.c

Nothing equivalent (yet) on the m68k side, though we may soon have a PCMCIA
driver if Joshua Thompson gets it working on his PB 190cs.

>The CUDA and PMU drivers both have several functions, of which talking
>to the ADB bus is only one.  The CUDA and PMU are both responsible for
>talking to the real-time clock and NVRAM, and for reset and soft-power
>control.  The PMU also has the functions of controlling and reporting
>on the battery status and for putting the system to sleep.  The PMU
>driver exports a /dev/pmu device.

The adb-iop.c is an ADB driver for IOP-based Macs (IIfx, Quadra 900 and
950), the via-macii.c is a via driver for Mac II-based ADB systems (II,
SE/30), and adb-iisi.c will be a driver for the IIsi-style ADB.

>If there was a compelling reason for getting rid of drivers/macintosh,
>sure we could find other homes for the files in it.  I haven't seen
>any compelling reason yet though.  If the 68k-mac folks feel that they
>can't use drivers/macintosh, that is unfortunate and certainly not
>what I intended.

Actually, the m68k-mac folks don't care whether it goes in
drivers/macintosh or drivers/adb.  The m68k port maintainer, Jes Soresen,
won't accept any patches that put or modify files in drivers/macintosh.

To clear up any confusion, please note that Joshua Thompson submitted a
PPC-relevant patch to Paul Mackerras while I (David Kilzer) submitted an
m68k-relevant patch to Jes Sorensen.  Both were patches to files in
drivers/macintosh, and in some cases moved the files there from other
places.

The issue at hand is that Jes believes drivers/macintosh should not exist
while drivers/adb (for low-level adb stuff) and drivers/char/adb (for adb
devices) should exist instead.  Paul, it seems to me, would be happy either
way.

>I think the idea of having a drivers/adb directory is reasonable, and
>adb.c, mac_keyb.c and maybe adbmouse.c can go in there.  I don't see
>that via-cuda.c and via-pmu.c really fit well in there though.  Maybe
>the thing to do is to split the adb-related functions out of those
>files and put them in cuda-adb.c and pmu-adb.c in drivers/adb.
>
>I don't really mind whether macserial.[ch] stay in drivers/macintosh
>or go to drivers/char.  drivers/sbus/char/sunserial.[ch] is a
>precedent for keeping it in drivers/char.  nvram.c could go into
>drivers/char, I guess, but would have to have a name change.  I don't
>see that these things have to go in drivers/char just because they
>implement a character device.

I would appreciate it if Jes and Paul would come to an agreement on where
the code belongs so we can get on with the ADB merger.  :^)

Dave


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Paul Mackerras]

David D. Kilzer <ddkilzer@computer.org> wrote:

> The issue at hand is that Jes believes drivers/macintosh should not exist

I still haven't heard why.  I personally would like something more
compelling than "Jes doesn't like it" before changing an arrangement
that is working just fine AFAICS.

> I would appreciate it if Jes and Paul would come to an agreement on where
> the code belongs so we can get on with the ADB merger.  :^)

Jes is more of a "theoretician" than I am, I tend to be more
pragmatic, so this could be a problem. :-)  I will accept patches for
drivers/macintosh from the m68k mac folks.  I have some reservations
about the current adb merge patches, though, which I'll mention once
I've had a closer look at the patches.  In general I'm happy with a
drivers/adb directory but I don't think drivers/macintosh should go
away.

Paul.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Jes Sorensen]

>>>>> "Paul" == Paul Mackerras <paulus@cs.anu.edu.au> writes:

Paul> David D. Kilzer <ddkilzer@computer.org> wrote:
>> The issue at hand is that Jes believes drivers/macintosh should not
>> exist

Paul> I still haven't heard why.  I personally would like something more
Paul> compelling than "Jes doesn't like it" before changing an
Paul> arrangement that is working just fine AFAICS.

Heh, I have been wanting to clean up the driver hierachy for a very long
time, it is really silly that we keep copying old drivers and change 50
lines of code to make them run on a new machine. This is the case with
the 8530 driver, but even worse for the Lance Ethernet one.

>> I would appreciate it if Jes and Paul would come to an agreement on
>> where the code belongs so we can get on with the ADB merger.  :^)

Paul> Jes is more of a "theoretician" than I am, I tend to be more
Paul> pragmatic, so this could be a problem. :-) I will accept patches
Paul> for drivers/macintosh from the m68k mac folks.  I have some
Paul> reservations about the current adb merge patches, though, which
Paul> I'll mention once I've had a closer look at the patches.  In
Paul> general I'm happy with a drivers/adb directory but I don't think
Paul> drivers/macintosh should go away.

Hmmm, refusing is such a strong term, however I consider you to be the
owner of drivers/macintosh and prefer not to make changes to it since if
I have to keep them around for a while it's a nightmare to maintain
since I cannot test the code.

I always refused to create drivers/amiga and drivers/atari because I
knew it would mean I would get things past Linus quickly but they would
then stay isolated forever and we would never get things merged like we
did with the fbcon code after a long time. I always consider
drivers/sbus/char a result of Dave not being willing to spend any time
arguing with Linus over things - though I might be wrong, I don't want
to talk about Dave behind his back. Oh and don't get me started on
drivers/acorn ;-)

I don't know that much about the Mac hardware, however I know they do
have an ADB bus and that in principle it's not Mac specific. We now
created drivers/{pci,zorro,dio,sbus,...} for specific bus handling code
and it seems to me to be a good idea to do that for ADB as well (I might
be wrong, it's happend before). The Mac serial driver really should go
in drivers/char (or maybe even have a drivers/serial created at some
point to make it easier to deal with) - trying to merge the multiple
8530 drivers we have now would be a positive long term goal, though of
course it should not be holding back real development. If there are
things which are truly Mac specific I agree they should stay in
drivers/macintosh, I didn't notice all the things you listed when I did
an ls drivers/macintosh in my tree.

Jes

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Geert Uytterhoeven]

On Tue, 31 Aug 1999, Jes Sorensen wrote:
> Heh, I have been wanting to clean up the driver hierachy for a very long
> time, it is really silly that we keep copying old drivers and change 50
> lines of code to make them run on a new machine. This is the case with
> the 8530 driver, but even worse for the Lance Ethernet one.

Linux' advertisement should become: we have more Lance drivers than supported
architectures.

Last time I counted them, I needed more fingers.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[David A. Gatwood]

On Tue, 31 Aug 1999, Geert Uytterhoeven wrote:

> Linux' advertisement should become: we have more Lance drivers than supported
> architectures.
> 
> Last time I counted them, I needed more fingers.

Nah, you just have to count in binary.  Thumb is 2^0, first finger is 2^1,
etc.


David


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Benjamin Herrenschmidt]

On Fri, Aug 27, 1999, David D. Kilzer <ddkilzer@computer.org> wrote:

>Well, drivers/macintosh is PPC ADB code.  If drivers/macintosh shouldn't
>exist, then shouldn't it be changed or moved at a higher level?
>
>In reality, there is some ADB mouse code in drivers/char, too, so I wonder
>if drivers/char/adb would make more/less sense than drivers/adb?

I personally like drivers/macintosh, from my point of view, it makes
things clearer. except for macserial, which should be killed in favor of
a more generic zilog driver, most of those drivers are really mac-centric
stuffs with no "generic" userland interface. Also, drivers/char is
already enough of a mess like this.

I didn't look at the those new patches, but the adb code in
driver/macintosh was abstracted to use a generic "adb controller"
sub-driver interface some time ago and so adb.c should be platform
independant (useable as-is on PPC and 68k). mac_keyb.c too, with all it's
specific mouse support.

David, did you make a generic (m68k/ppc) cuda driver too ?

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[David D. Kilzer]

>On Fri, Aug 27, 1999, David D. Kilzer <ddkilzer@computer.org> wrote:
>>Well, drivers/macintosh is PPC ADB code.  If drivers/macintosh shouldn't
>>exist, then shouldn't it be changed or moved at a higher level?
>>
>>In reality, there is some ADB mouse code in drivers/char, too, so I wonder
>>if drivers/char/adb would make more/less sense than drivers/adb?

Benjamin Herrenschmidt <bh40@calva.net> wrote:
>I personally like drivers/macintosh, from my point of view, it makes
>things clearer. except for macserial, which should be killed in favor of
>a more generic zilog driver, most of those drivers are really mac-centric
>stuffs with no "generic" userland interface. Also, drivers/char is
>already enough of a mess like this.
>
>I didn't look at the those new patches, but the adb code in
>driver/macintosh was abstracted to use a generic "adb controller"
>sub-driver interface some time ago and so adb.c should be platform
>independant (useable as-is on PPC and 68k). mac_keyb.c too, with all it's
>specific mouse support.

Joshua Thompson did some rewriting of the adb.c code (and moved some header
files around) in order to fully integrate the m68k and PPC ADB code.

>David, did you make a generic (m68k/ppc) cuda driver too ?

Joshua Thompson made the patch, but I didn't include it in the patch I
submitted to Jes Sorensen (m68k maintainer) since I thought he only wanted
m68k stuff.  Joshua submitted the PPC side of the patch to Paul Mackerras.

Jes doesn't want to patch anything into drivers/macintosh.  He believes
that ADB code should be split into the bus code (drivers/adb) and into
device code (drivers/char/adb or drivers/char) and that drivers/macintosh
should go away.

I'm afraid that the m68k stuff is going to appear in drivers/[char/]adb
while the PPC stuff is going to remain in drivers/macintosh, and we'll be
worse off than we were before the merge!

Do we need to raise this issue on linux-kernel to get it resolved,
especially since the NeXT port (another m68k-based system) uses ADB as well?

Dave


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Geert Uytterhoeven]

On Fri, 27 Aug 1999, David D. Kilzer wrote:
> Jes doesn't want to patch anything into drivers/macintosh.  He believes
> that ADB code should be split into the bus code (drivers/adb) and into
> device code (drivers/char/adb or drivers/char) and that drivers/macintosh
> should go away.
> 
> I'm afraid that the m68k stuff is going to appear in drivers/[char/]adb
> while the PPC stuff is going to remain in drivers/macintosh, and we'll be
> worse off than we were before the merge!
> 
> Do we need to raise this issue on linux-kernel to get it resolved,
> especially since the NeXT port (another m68k-based system) uses ADB as well?

Hence ADB bus stuff must be moved to drivers/adb/.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: mac-2.3.14.diff: adb

[Geert Uytterhoeven]

I'd also like to see a global CONFIG_ADB option. At the moment the kernel
doesn't link if you don't set CONFIG_MAC_KEYBOARD due to numerous references to
ADB stuff. I fixed it `quick' by always linking in drivers/macintosh/adb.o.

Is it OK to protect all ADB references with #ifdef CONFIG_ADB/#endif?

Greetings,

						Geert

--
Geert Uytterhoeven ----------------- SONY Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Tel +32-2-7248608 Fax +32-2-7242686 ------------------ B-1130 Brussels, Belgium


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