Date: Wed, 23 Jul 2003 15:32:57 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Matthew Emmerton <matt@compar.com> Cc: FreeBSD-CURRENT Mailing List <freebsd-current@freebsd.org> Subject: Re: We have ath, now what about Broadcom? Message-ID: <20030723223256.GB22166@Odin.AC.HMC.Edu> In-Reply-To: <009e01c35168$c0738270$1200a8c0@gsicomp.on.ca> References: <20030723220757.49A565D07@ptavv.es.net> <009e01c35168$c0738270$1200a8c0@gsicomp.on.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 23, 2003 at 06:21:23PM -0400, Matthew Emmerton wrote: > Why would Broadcom be scared? Obviously it's the _driver_ that controls = the > power/freq output of the chip, so the responsibility of staying within FCC > regs is that of the driver authors. Of course, the "no warranty" aspects= of > open source drivers turns a blind eye to liability, but would things real= ly > come back to Broadcom? It's not sufficent for a manufacture of RF equipment to say "don't do that". They have to take real, more or less working steps to keep you =66rom doing things you aren't supposed to do. This is why the Linksys link boosters were pulled. FWIW, there is a solution to this which Sam used to when implementing ath(4). That is to implement a binary-only hardware access layer, ath_hal(4), that keeps you from doing things you aren't supposed to with the highly programable chips. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/Hw0XXY6L6fI4GtQRAkqhAKDP0/ygbn5uEvOI8UGBM3qI+pwp2wCfX4VJ DV9Vpgjw7nk2LilnihzEZbE= =3c+S -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030723223256.GB22166>