SMC91cxx h/w info and bus space queries
Allen Briggs
(10/100 ethernet). These are based on the SMC 91C100
chip. This is almost recognized by the smc91cxx driver,
but not quite. Does anyone have any softcopy docs for
this chip? I found smsc.com on-line, but the 91C100 is
discontinued and they don't have archived information
on-line.
FWIW, I currently have:
sm0 at nubus0 slot d: AsanteFAST 10/100 NB^A
sm0: invalid BSR 0x0035
sm0: unknown chip id 3, revision 5
sm0: MAC address 00:00:94:77:e8:08, default media UTP
The chip id and revision are almost certainly wrong because...
The smc91cxx driver seems to assume that bus_space_read_2 will
return data LSB-first. The nubus machines that I'm aware of are
both m68k and therefore will be using memory-mapped I/O and reading
16-bit data MSB-first. So, how should this be handled?
* Should the driver do a le16toh() or htole16() in
conjunction with its current code? That wouldn't
seem right for systems that automatically byte-swap
for the bus accesses.
* Should the mac68k bus_space implementation be
expanded to carry flag(s) (in the bus_handle_t)
that drivers can set? One of these flags would
be for byte swapping (there is some need also
for a way to specify that byte registers are on
longword boundaries, etc.).
I'm thinking that the second is the way to go, but since
it's more work and will have some negative impact on performance
(on a machine with little performance to spare ;-), I'd like
to hear what others think about this.
-allen
Izumi Tsutsui
bri...@ninthwonder.com wrote:
> * Should the driver do a le16toh() or htole16() in
> conjunction with its current code? That wouldn't
> seem right for systems that automatically byte-swap
> for the bus accesses.
>
> * Should the mac68k bus_space implementation be
> expanded to carry flag(s) (in the bus_handle_t)
> that drivers can set? One of these flags would
> be for byte swapping (there is some need also
> for a way to specify that byte registers are on
> longword boundaries, etc.).
>
> I'm thinking that the second is the way to go, but since
> it's more work and will have some negative impact on performance
> (on a machine with little performance to spare ;-), I'd like
> to hear what others think about this.
All byte-swap operations should be done inside bus_space functions,
so I believe the latter is proper. mac68k bus_space functions
should be implemented like amiga or atari to handle both endian.
I guess this is requred to support mac68k nubus wdc.
(MI wdc also requires "stride" (sparse space access) method, though.)
---
Izumi Tsutsui
tsu...@ceres.dti.ne.jp
Allen Briggs
> so I believe the latter is proper. mac68k bus_space functions
> should be implemented like amiga or atari to handle both endian.
This case is a little different from the amiga / atari cases because I
don't want to swap for the entire bus--only for specific address ranges
on a bus--only if certain hardware is detected. I think the only way
to do this is to change bus_space_handle_t to be a structure containing
the address and the access requirements.
> I guess this is requred to support mac68k nubus wdc.
> (MI wdc also requires "stride" (sparse space access) method, though.)
The onboard mac68k wdc, yes. I'm not aware of a nubus wdc.
-allen