mac-2.3.14.diff: adb

David D. Kilzer ddkilzer at
Tue Aug 31 14:25:35 EST 1999

Paul Mackerras <Paul.Mackerras at> wrote:

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

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.

>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

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

>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.  :^)


[[ 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 ]]
[[ and for useful information before posting.   ]]

More information about the Linuxppc-dev mailing list