Michael Krufky <mkrufky <at> linuxtv.org> writes: > ...snip... > That's fine with me... except I just don't see why we shouldn't just have the > demod drivers that have the integrated tuning functionality just fill > tuner_ops.info.frequency_max|min anyway. The point is, the structures will be > present regardless of whether any tuner_ops are actually filled. This is an > opportunity to remove the frequency_min|max from the demod ops.info structure, > as we all agree that it is inappropriate there anyhow. If we do this, then we > will have a standard across the board. > > Regards, > Mike > Having looked around for such information myself, it would possibly help consistency of tuner/demod/demux drivers if there was a standard/'best practice' for implementing such software, giving the decision points based on the actual device(s) features, reflecting into implemented code. e.g. if the device is a tuner: - create this file (from a template ?) - fill in these structure fields based on xxx values - write these functions - add these Kconfig settings ... This would ensure in the current case that there is no misunderstanding about the roles of different, possibly duplicated, fields, and which has precedence. Also when to specifically use a "tuner" or "frontend" structure. Regards, MikeW _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
