how to use dvb_attach (was: Re: [linux-dvb] Re: Error unloading WinTV NOVA T USB2)

Trent Piepho xyzzy at speakeasy.org
Tue Aug 29 23:27:38 CEST 2006


On Tue, 29 Aug 2006, Patrick Boettcher wrote:
> On Mon, 28 Aug 2006, Trent Piepho wrote:
> > > On 8/22/06, Patrick Boettcher <patrick.boettcher at desy.de> wrote:
> > > > The wrong use_count for the dib3000mc is most likely because I'm not using
> > > > the dvb_attach-function for attaching the demod/frontend, because the
> > > > prototype of the dib3000mc_attach is not exactly the same as for other
> > > > demod-drivers.
> > > >
> > > > Why? Because with the dib3000mc_attach (and with the future coming
> > > > dib7000m_attach and dib7000p_attach) we can attach more than one demod at
> > > > the same time - will be used on devices arriving late fall/autumn).
> > > >
> > > > Can someone please advise me how to proceed?
> >
> > You should not use dvb_frontend_detach() unless you are using dvb_attach(),
> > which you are not using.
>
> Am I using dvb_frontend_detach?

Yes.

$ grep -n dvb_frontend_detach dvb-usb*.c
dvb-usb-dvb.c:189:                      dvb_frontend_detach(d->fe);
dvb-usb-dvb.c:207:              dvb_frontend_detach(d->fe);

> > I think it would make a lot more sense if you had dib3000mc_attach() just
> > attach one frontend, like all the other front-end attach functions.
>
> For whom would it make more sense? My understanding of the attach-function
> is not, that it only has to attach exactly one frontend. If I missed
> something in the dvb_attach-discussion I'm sorry.

This is how all the other attach functions work.  They return a pointer the
to the struct dvb_frontend that was attached or NULL on failure.  Except
dib3000mc_attach() which is totally different.  It makes it harder when you
one thing which doesn't work the way everything else does.  In fact, I see
from this patch http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=4468 that
even you got it wrong when using dib3000mc_attach()

I also think that attaching one frontend with the attach function and
calling it multiple times would make the code over all simpler.

> > If something has multiple front-ends, just call the attach function
> > multiple times.
>
> For the so-called I2C-enumeration of the DiBcom-demods (to get all the
> demod reachable by I2C) it is necessary to have some information which is
> present in the config-struct. I actually don't like to change all that,

That would be dib3000mc_i2c_enumeration(demod,no_of_demods,default_addr),
which is never actually called in the current code?

It does not look like it needs anything in the dib3000mc_config structure,
only all the frontend pointers and the default i2c address.

It looks like it remaps the demods to different I2C addresses?  Could you
just have a function that does this after all the demods have been
attached?  Or just re-map them one at a time as they are attached?  Have a
parameter to dib3000mc_attach that specifies the I2C address to re-map too
or 0 to not remap.

> > Why is dibusb_dib3000mb_frontend_attach() in dibusb-mb.c, and
> > dibusb_dib3000mc_frontend_attach in dibusb-common.c?
>
> Why why why? *sigh*. You can believe me, there is a reason:
>
> At first dibusb_dib3000mc_frontend_attach was only located in dibusb-mc.c,
> then a device appeared with the 3000mc inside but with USB firmware
> interface which normally only used with the 3000mb onboard. So, I put the
> dibusb_dib3000mc_frontend_attach in common, because it was used by two
> different modules.

This makes everything which uses dibusb-common depend on the 3000mc
demodulator module.  Why not just put dibusb_dib3000mc_frontend_attach(),
the dvb-usb wrapper for the frontend attach function, in dib3000mc.c?

>
> > BTW, the error path in dib3000mc_attach() is broken.
>
> Thanks, but where? I'm too blind to see it.

It de-references uninitialized front-end pointers.  I suppose that this
goes to show that the way the front-end attach function tries to do
multiple frontends at once makes it too complex.



More information about the linux-dvb mailing list