In article <031102080824.M0128014@mirage.ceres.dti.ne.jp>
I wrote:

> If you have any problem (especially on untested machines),
> please report via send-pr(1).

Ok, to fix port-sparc64/23342, I've made a quick diff which splits
current sparc64/sparc64/clock.c into each device/bus attachment:
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/sparc64-clock-20031102.diff

GENERIC kernel works on my Ultra5:
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/netbsd-GENERIC-sparc64clock-20031102.gz
but it's appreciate to test it on other machines
(especially sbus based models and mcclock based models).


Anyway, clock/eeprom code on sparc64 still should be cleaned up more:

(1)"eeprom" device attachment
sparc64 port really needs "eeprom" definition in files.sparc64?
I think only sun4/100 and sun4/200 machines (which have intersil7170
todclock) have "eeprom" device, and "eeprom" attachment (sparc/eeprom.c)
on sparc port for these machines only sets eeprom_va. But it is refered
only in sparc/mem.c for /dev/mem access, and sparc64 doesn't have such
code in sparc64/mem.c, so I removed eeprom from fines.sparc64 and
eeprom_uio() function from sparc64/clock.c.

(2)timer device attachments
Timer device attachments should be split from sparc64/clock.c
like sparc port, but I have no idea how the "no counter-timer" case
should be handled.

(3)myetheraddr()
Maybe myetheraddr() should be moved into machdep.c,
but I'm not sure.
(on sparc, it's in sparc/promlib.c with __strong_alias().)

(4)code sharing with sparc port
Currently all attachments are in sparc64/dev, but
maybe they should be in MI place and shared with sparc port.
(How should eeprom device be handled?)

(5)device names
I wonder if "mcclock" and "mkclock" is appropriate.
sparc port still has "rtc" for ds1287 (which is also mc146818
compatible, but a bit different from sparc64) on JavaStation.

etc. etc.
Comments? Is it OK to commit the above diff for intermediate fix?
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp