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
[-- Attachment #1 --] 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 really > 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 from 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 -- 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/Hw0XXY6L6fI4GtQRAkqhAKDP0/ygbn5uEvOI8UGBM3qI+pwp2wCfX4VJ DV9Vpgjw7nk2LilnihzEZbE= =3c+S -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030723223256.GB22166>