From owner-cvs-src@FreeBSD.ORG Sat Sep 6 11:52:43 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F81316A4C0 for ; Sat, 6 Sep 2003 11:52:43 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 52C5143FB1 for ; Sat, 6 Sep 2003 11:52:39 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 20846 invoked by uid 65534); 6 Sep 2003 18:52:37 -0000 Received: from p508E5204.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.142.82.4) by mail.gmx.net (mp022) with SMTP; 06 Sep 2003 20:52:37 +0200 Received: by galatea (Postfix, from userid 1001) id 616E6CD; Sat, 6 Sep 2003 20:53:10 +0200 (CEST) Date: Sat, 6 Sep 2003 20:53:10 +0200 From: Thomas Moestl To: Bill Paul Message-ID: <20030906185309.GA1163@timesink.dyndns.org> Mail-Followup-To: Bill Paul , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org References: <200309041539.h84Fdj1k008672@repoman.freebsd.org> <20030906002321.F17CE16A4C0@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030906002321.F17CE16A4C0@hub.freebsd.org> User-Agent: Mutt/1.4.1i cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/pci if_rl.c if_rlreg.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2003 18:52:43 -0000 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 http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C