if someone sets these cards out of range what happens? if it is mearly
poor or non-existant reception, then let the driver set it to whatever and
let the manufacturer worry about the specs, like everything else - if you
use it out of spec you are on your own. If actual damage can be done, then
we need to have the driver limit the freq.
David Lang
"If users are made to understand that the system administrator's job is to
make computers run, and not to make them happy, they can, in fact, be made
happy most of the time. If users are allowed to believe that the system
administrator's job is to make them happy, they can, in fact, never be made
happy."
- -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)
On Fri, 15 Jan 1999, Russell Kroll wrote:
> Date: Fri, 15 Jan 1999 16:11:31 -0700 (MST)
> From: Russell Kroll <rkroll@exploits.org>
> To: rhw@BigFoot.Com
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: AIMS Labs radio card: frequency limit
>
> > Probably a better choice would be for the kernel to assume that it
> > can, and report an error if the hardware says otherwise, at least as
> > far as that is possible...
>
> That assumes that the radio card is able to indicate that a frequency is
> unattainable. Unfortunately, when it comes to tuning, these things are
> pretty stupid and don't report much back. The aztech, aimslab, and cadet
> radio cards all suck down tuning bits but only the cadet will let you read
> them back.
>
> For most of these things, a human has to be in the loop doing experiments
> to figure out exactly what the limits are. There are also modifications
> possible to these cards that will alter the range, so a fixed value isn't
> always good either.
>
> I imagine that allowing "freqlow" and "freqhigh" as options for
> insmod/modprobe would allow users in various locations to try different
> frequencies to see what happens. This is obviously out of the question
> right now, so I will pursue it when 2.3 development starts. It keeps the
> idea of "let clued people change values" alive, which is always a good
> thing.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNp/bST7msCGEppcbAQFBWAgAx9fPSV+PX3lT+CfDTFVy0NLvRlhpK06z
kie6vtH7+2iZgrcWd0rgGjue0ZI00b4Du06JPSRcbvLG/noaK5R4phVrnOOJAmJp
k6uppeBi6JoiU7Bq9/5gGCPNUr399jwWUdgqYXwra6Ei4Z4y/YUJ7U4FljkSmlE5
bAPHPzmvqn9hWxJdRil4SiXo7rNKx392aB2GDu/1xXzOeuNIFqWPDu8ocCeHHfOD
KnHcAMZok7Qbk7shuUknHNdzZlU0GpgKBzq2RrqGsj5tsmYeoAr7DYqsKNVHDUYi
DePRANM6MRocZHG1AzR307ODmF1YbU6o5Wf9VTbX2oReHdp8D4LQlg==
=+uHV
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/