[linux-dvb] [patch/resend] dvb pll library

Gerd Knorr kraxel at bytesex.org
Thu Feb 17 13:53:53 CET 2005

Johannes Stezenbach <js at linuxtv.org> writes:

> > Whats the status on the cx22702 driver btw.?
> Well, you know my position. If you send me what I asked for
> it would be in CVS immediately. Now, I tried to get Michael
> and Andrew to back up either your or my position so we
> could reach a decision, but it seems they are not willing
> to say something.

Michael askd me to send him the files, I did, but never heared back
from him since.  Maybe he is just busy, I've also havn't seen anything
on the list from him recently.  But I through I'll ask for the status
while I'm submitting patches anyway ...

> Just in case you forgot: My problem is not that your code sucks, but
> simply that it is different from all other frontend drivers.

Well, the _interface_ to the other modules (drivers + dvb core) and is
exactly the same now.  The only minor difference are new entries in
the cx22702_config struct due to the switchover to dvb-pll.

The _internals_ are slightly different, yes.  I still think that it is
better register within the i2c core.  But whenever I do or not doesn't
change the module behavior at all.

IMHO it's just nicer for some things, for example for being visible in
sysfs.  Or -- just found that today -- not needing ugly hacks for
firmware loading like the one in tda1004x.c currently.  You could just
use i2c_client->dev and call request_firmware() directly.

> I see maintainability issues,

Just because I'm registering my i2c clients within the i2c core?
Thats the _only_ difference remaining.

> but also social problems with the people who were involved in the
> discussions that led to the current frontend design.

The discussion was about the frontend _interface_ design, i.e. how the
modules talk to each other, how they are configured and so on.  I
can't remember having discussed any strict coding guidelines for the
driver internals.

My cx22702 module has the same interface like all others, I think I've
explained that already.  At least I've tried ...

> An easy way out: You could get a CVS account and commit it
> yourself. That way you would take direct responsibility for
> your deeds.

I don't see how that makes a difference.  Either I care about that
baby or I don't, whenever I do by mailing patches or by commiting
myself doesn't really matter I think.  Well, committing directly would
bypass peer review, I don't think that is good (look at the mt352
discussion for example ...), you guys know the dvb internals much
better than I do.


#define printk(args...) fprintf(stderr, ## args)

More information about the linux-dvb mailing list