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