Mailing List archive

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

[linux-dvb] Changes to FE_REGISTER/FE_UNREGISTER calling convention



I can't find this message in the archives, so I'm resending...

--

The "new" frontend code assumes that a FE_REGISTER/FE_UNREGISTER will be
issued during the attach_adapter routine's operation (as a result of an
i2c_attach_client), and triggers a BUG() in the instance where a board
driver doesn't call the FE_REGISTER routine synchronously.  It also
assumes that a FE_UNREGISTER will be issued synchronously when an
i2c_detach_client() is called.

This causes problems with some multi-function cards, such as the cx88,
which have a "core" module providing the i2c functionality, and a "dvb"
module providing the DVB functionality.  Specifically, if one loads the
frontend module and then the "core"/i2c module, we get an oops because the
DVB module is not loaded.

At first I was looking at removing FE_UNREGISTER completely, and
triggering all the actions from the but this still has problems in the
case of multi-function cards with separate modules - unloading the DVB
module can result in a similar behaviour, with an oops as the dvb_adapter
handle that we kept is no longer valid.

I propose the following changes to address these problems:

1. Frontend's .attach_adapter is modified to probe the i2c bus and check
to see if it will be possible to attach a DVB tuner on this device.  If
so, performs an i2c_attach_client and returns.  Remove the
BUG_ON(!state->dvb) and the call to dvb_register_frontend, leaving us
attached to receive a FE_REGISTER later on.

2. Frontend's .command routine is modified to call dvb_register_frontend
as a result of a FE_REGISTER call iff (state->dvb == NULL).

3. Card's driver is modified to performs an i2c_clients_command(..,
FE_REGISTER, dvb_adapter) in its core attach_inform routine (should it be
already ready to handle DVB (i.e. in the multi-module case, when the DVB
module is loaded)) and in its probe routine (immediately after it
registers its frontends, etc, to the DVB core).

4. Card's driver is modified to perform i2c_clients_command(..,
FE_UNREGISTER, dvb_adapter) from its core detach_inform routine, and its
DVB module to call i2c_clients_command(.., FE_UNREGISTER, dvb_adapter)
from its .remove routine before unregistering itself from the DVB core.

5. Frontend's .command routine modified to perform a
dvb_unregister_frontend() if state->dvb == the state->dvb we were passed
and sets state->dvb to NULL.

6. Frontend's .detach_client routine calls dvb_unregister_frontend() if
state->dvb is set, and then calls i2c_detach_client().  This
unregister_frontend is needed as i2c_clients_command won't send a
FE_UNREGISTER message to a driver that in the process of being unloaded.

I think that this permits all orderings of frontend/core/dvb module
load/unloads without oopsing.  I have made such changes to the cx88 and
mt352 modules and tested various combinations of module loads/unloads with
no ill effect.

Does anyone have any comments on this?  If this looks good, I will put
together a patch for all the frontends/cx88/bt8xx cards to make them
behave in this way.

Regards,
Chris




Home | Main Index | Thread Index