cvs commit: src/sys/pci if_rl.c if_rlreg.h

[Thomas Moestl]

On Fri, 2003/09/05 at 17:23:21 -0700, Bill Paul wrote:
> > tmm         2003/09/04 08:39:45 PDT
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     sys/pci              if_rl.c if_rlreg.h 
> >   Log:
> >   Use stream bus space accesses to program the ID (station address)
> >   registers; otherwise, the byte order of the address is changed on
> >   big-endian machines.
> >   
> >   Revision  Changes    Path
> >   1.115     +4 -2      src/sys/pci/if_rl.c
> >   1.34      +2 -0      src/sys/pci/if_rlreg.h
> > 
> 
> Do you by any chance know if this affects the multicast filter
> hash table registers as well? Also, is it possible to achieve
> the same effect using htole32()?

The non-streaming bus space functions guarantee that integers accessed
through them (by a single access of the appropriate size) have the
same value in both the device's and the host system's
interpretation. This means that conversions are necessary if bus and
host byte orders differ, as is the case with sparc64 and PCI.

This behavior is what is desired in most of the cases; however, when
loading the same byte sequence from memory on architectures with
different endianness, the value it is interpreted as will differ, so
this type of access is not appropriate to literally transmit byte
sequences to the device, e.g. for sending data by PIO. Because of
this, the stream functions where introduced to transfer data at
more than one byte at a time, while preserving the byte order.

Since rl_calcash() accesses the addresses byte by byte and the address
is an array of bytes, the hash calculation is endian neutral. The
calculated hashes[] should have the same value for the device and the
host, so a non-streaming write is appropriate.

Because of the conversions mentioned, the non-streaming bus space
functions can be viewed as having an implicit htole*() call in the
PCI case, so calling letoh32() on the station address data before
writing it would work too (and using htole32() would happen to also
work since both are the same for non-pathological byte orders).
However, this would IMHO be slight API abuse since it treats the
address chunk as an int32_t, and tends to be confusing, so I prefer to
use the streaming functions. For drivers which support buses with
different byte orders, using them can be necessary, so this also
increases consistency (they are faster on architectures which require
byte order conversions as well, but of course this does not matter in
this case).

Sorry for being long winded and stating many things which must be
obvious to you, but I though this might interest other people too,
although my explanation is probably lacking.

	- Thomas

-- 
Thomas Moestl <t.moestl at tu-bs.de>	http://www.tu-bs.de/~y0015675/
              <tmm at FreeBSD.org>		http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0  9C0F 1FE6 4F1D 419C 776C