(BTW, typedefs are deprecated for kernel code (only allowed for explicitly opaque data types)).
Until now, I've been contested:
1) "&buf" instead of "buf" 2) "//" comments 3) use of typedef
the funny part is that
1) I copied&pasted existing code 2) "//" comments are everywhere 3) typedef are everywhere in frontend.h
:-) :-) :-)
In the days when we defined this header the common consensus was that atomic types can get typedef'd, somposite structs and unions should not. I did not followed the recent babbles of the fanatic codingstyle priests on the lkml, so I don't know the current policy. Removing the typedefs afterwards from pulic API headers would break userspace applications.
He proposed many ioctl (START_SCAN, CONTINUE_SCAN, STOP_SCAN), and they may be useful in the future even if they are not needed at the moment.
These are only useful if the hardware can indeed scan a frequency range automatically. If not, they are useless as userspace can only check (a small band around) one frequency, and retrieve the result (no signal, or a full parameter set). So please check the data sheets again (for mt352 and mt312) to see if this is true.
mt312: it is possible to specify a small band (+-15MHz max, +-6MHz default); so not a frequency scan, just autofinetuning.
The wide band makes sense for scanning/autoprobing, the small band is more useful for normal SET_PARAMETER calls because of faster lock times. For DVB-S demods it might make sense to make the used bandwidth also dependent of the symbolrate for optimal results.
Holger
