[linux-dvb] Re: [rfc/patch] pll handling and cx22702 update

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Tuesday 04 Jan 2005 07:04, Gerd Knorr wrote:
> > > > static int tuner_generic_init(struct dvb_tuner_desc* desc,
> > > > dvb_tuner_ops* ops) {
> > > >  u8* buf;
> > > >
> > > >  buf = alloca(desc->tuner_data_size);
> > > >  if (buf == NULL)
> > > >   return -ENOMEM;
> > > >
> > > >  memcpy(buf, desc->init_data, desc->tuner_data_size);
> > > >  return ops->write(desc, ops, 0, buf, desc->tuner_data_size);
> > > > }
> > >
> > > The ops->write() scares me, I think that isn't going to work with
> > > mt352-based frontends.
> >
> > Hmm, not really an issue - the implementation of write() will just copy
> > the appropriate data into the array supplied by pll_set() in struct
> > mt352_config.
>
> What is the point of using the ->write() callback then, instead of just
> passing a ptr to the buffer to fill?  That adds complexity for no reason
> and also is confusing as I'd expect a ->write() callback actually write
> the stuff.

It was to allow the maximum flexibility so that code for tuners with 
non-4-byte addressing or multiple i2c devices could be shared as well. 

> > I tried to keep it so the simple tuners could be represented simply, yet
> > it was flexible enough for the more complex ones too.
>
> I don't think it is that useful, there are some corner cases where
> you'll run into trouble with that approach.  The mt352 can only handle
> the simple 4-byte style tuners for example.  Whats wrong with handling
> the complex ones like they are handled today?

My take on this was that the idea was to pull out common tuner code into a 
shared module so that its not duplicated all over the codebase.. so when we 
have a non-4-byte tuner which is shared we'll be wanting to do this as well.