Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: refactoring



> > I think it isn't wise to create a all-in-one function for that as you
> > loose flexibility.  And I've already found one bug: It doesn't care
> > about the PLL issue.  To fix that you need even more arguments, that
> > isn't going to be pretty ...
> 
> Yeah  - this is exactly why I left the i2c_adapter in the config structs - 
> otherwise you end up with six arguments to the XXX_attach() functions.
> 
> I don't really see the problem with having it in there - it is an external 
> piece of information supplied to the demodulator by the adapter - which 
> pretty much fits with the sort of thing that should be in config to me.

There is a important difference which I've already tried to outline:
It isn't static.  config info is something which will be identical for
two identical cards.  That isn't true for i2c_adapter.  i2c_adapter
belongs to a particular _instance_ of the card (i.e. with two cards in
one machine have two different i2c_adapter structs), not to some card
_type_.

If you put i2c_adapter into the config struct you _must_ allocate it
dynamically and put in the i2c_adapter there to pass it down to the fe.
If it is not in there you can just pass the pointer to the config data
directly to the fe driver (and it can even be declared const as pointed
out by Johannes).

  Gerd

-- 
return -ENOSIG;




Home | Main Index | Thread Index