Mailing List archive

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

[linux-dvb] Re: refactoring



> > Oh, no, not *this* again please.  What the heck is the reason to not
> > use the kernel i2c stuff?  I think we had discussed that ...
> 
> I have removed the kernel i2c_driver structures because we do not need it.

We do.  Well, we don't really have to, but it would make several things
easier when we'll use the existing infrastructure

> I have left it using the kernel i2c_adapter stuff, and i2c_transfer() 
> functions as before.

Which is a bad idea.  Have you actually looked at my cx22702 version?
There is much generic, reusable code in there.  And it is generic
*because* it makes heavy use of the kernl i2c infrastructure.  It
creates and registeres i2c_client structs for both demod + pll and then
passes around just a i2c_client ptr (instead of a fe-specific struct) to
many functions, like this one here:

   static int pll_dtt759x_set_tv_freq(struct i2c_client *c, u32 freq,
			              int bandwidth);

It's absolutely no problem to move that to some other -- say -- pll-lib
module and then have other frontend driver reuse it.

> > And free the drivers private data.  And any other cleanups the driver
> > migth have to do depending on the hardware.  We certainly need a
> > detach function.
> 
> There is no private data any longer.

Yes, I've seen the code now.  Thats is a serve design bug.  The drivers
private data should not be public.  And it should be allocated and freed
by the driver itself and not by someone else.

  Gerd

-- 
return -ENOSIG;





Home | Main Index | Thread Index