by Trent Piepho

[permalink] [raw]

Subject: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

On Thu, 3 May 2007, Mauro Carvalho Chehab wrote:
> Em Qua, 2007-05-02 às 04:10 -0700, Trent Piepho escreveu:
> > I promise, this time it's right!
> > http://linuxtv.org/hg/~tap/dst-new
>
> Confirmed. Now the patch is properly working. My tests were done with a
> board with DST. Those are the results:
>
> 1) when DST is unselected, on a board with DST, it will print the errors
> indicating that the Kconfig items were not selected:
>
> DVB: registering new adapter (bttv0).
> DVB: Unable to find symbol dst_attach()
> frontend_init: Could not find a Twinhan DST.
> dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800
>
> The only issue is the wrong printk msg, stating that a "frontend driver"
> were not found. As this issue also happens with the current driver, due
> the usage of dvb_attach() macro, I don't see any regressions.
>
> It would be nice, however, to have a patch making dvb_attach more
> generic, by e.g. having a variant that allows passing another message.

Only this message is from dvb_attach():
> DVB: Unable to find symbol dst_attach()

Is it saying that it cannot load the module that dst_attach() is in (it
doesn't know what module that is, modprobe knows that). If you enabled dst
support and deleted the module, it would be the same.

If you turn off dvb_attach() and also disable dst, you should instead get
this message:
dst_attach: driver disabled by Kconfig

Maybe that would look nicer with a "DVB: " prefix? That would easier if it
wasn't necessary to update the printk in each boilerplate stub function. What
if one macro created these stubs....

> frontend_init: Could not find a Twinhan DST.
> dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800

These two messages are printed by the dvb-bt8xx driver, not by dvb_attach().
It would be trivial to change of course, but I'm not sure what would be
pedantically correct for both dst and non-dst based hardware.

> There's an argument against the prototype changes on dst_attach and
> dst_ca_attach since they aren't frontend.

The reason I changed that, is the dst_attach() already did return a
dvb_frontend pointer, it was just inside an enclosing structure. i.e. what
existed before:

{
struct dst_state *state;
state = dst_attach(...);
card->fe = &state->frontend;
} /* state goes out of scope */

The frontend is inside the state struct and the state pointer isn't saved
anywhere. dvb-bt8xx just saves a frontend pointer from inside the dst state
and tosses the state pointer away. So I changed that to:

card->fe = dst_attach(...);

2007-05-04 09:24:10

by Mauro Carvalho Chehab

[permalink] [raw]

Subject: Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)

> > It would be nice, however, to have a patch making dvb_attach more
> > generic, by e.g. having a variant that allows passing another message.
>
> Only this message is from dvb_attach():
> > DVB: Unable to find symbol dst_attach()
>
> Is it saying that it cannot load the module that dst_attach() is in (it
> doesn't know what module that is, modprobe knows that). If you enabled dst
> support and deleted the module, it would be the same.
>
> If you turn off dvb_attach() and also disable dst, you should instead get
> this message:
> dst_attach: driver disabled by Kconfig
>
> Maybe that would look nicer with a "DVB: " prefix? That would easier if it
> wasn't necessary to update the printk in each boilerplate stub function. What
> if one macro created these stubs....
>
> > frontend_init: Could not find a Twinhan DST.
> > dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800
>
> These two messages are printed by the dvb-bt8xx driver, not by dvb_attach().
> It would be trivial to change of course, but I'm not sure what would be
> pedantically correct for both dst and non-dst based hardware.

Sorry, this is what I meant: to fix the above message. The dvb_attach is
generic enough.

Maybe a more nice text would be something like:
"Couldn't initialize frontend helper modules for device ..."

since dvb_attach will also print what modules were not loaded.
>
> > There's an argument against the prototype changes on dst_attach and
> > dst_ca_attach since they aren't frontend.
>
> The reason I changed that, is the dst_attach() already did return a
> dvb_frontend pointer, it was just inside an enclosing structure. i.e. what
> existed before:
>
> {
> struct dst_state *state;
> state = dst_attach(...);
> card->fe = &state->frontend;
> } /* state goes out of scope */
>
> The frontend is inside the state struct and the state pointer isn't saved
> anywhere. dvb-bt8xx just saves a frontend pointer from inside the dst state
> and tosses the state pointer away. So I changed that to:
>
> card->fe = dst_attach(...);

IMO, this made the code cleaner.

--
Cheers,
Mauro