[linux-dvb] Re: Proposal for new frontend architecture

[Andrew de Quincey <adq_dvb@lidskialf.net>]

> > Hmmmm... could this be a way to restrict which devices are allowed on the
> > bus as well?
>
> Partly, the drivers have to play nice for that, you can't _force_ them
> not to probe.

Yeah, but I don't think thats a big problem - we can see the source, and moan 
at the authors if theres one that doesn't play ball.

[..]
> tuner_probe() can fetch informations.  If the bttv driver knows the card
> in question hasn't a analog tuner in the first place (tuner_type ==
> TUNER_ABSENT) it can just return and not call i2c_probe().  For the dvb
> frontends that would be even more useful as there are several ones
> instead of one single module for all tuners.  It's also possible to
> fetch config info in either tuner_probe (i2c bus addresses for example)
> or tuner_attach (any stuff needed to setup the device).  And probably
> more useful stuff.
>
> One quirk with this is that there is a chicken-and-egg issue with cards
> which have config info in a i2c-connected eeprom chip.  Current bttv
> solves that by doing the TUNER_SET_TYPE thingy in two different places,
> once in the callback mentioned above and once after reading the eeprom
> to make sure it works with any module load order.  One fix for that I
> can think of is to separate adapter registering and bus scan, i.e.
> have something like
>
>  i2c_add_adapter_noprobe();
>  /* bttv can read the eeprom here */
>  i2c_adapter_probe_drivers();
>
> Additional benefit is that i2c adapters can bypass autoprobe altogether
> by simply not calling i2c_adapter_probe_drivers() ;)

Sounds good! I think we've got now all the ideas floating about the list to 
sort kernel i2c out - we just need to decide which to choose and put them 
together.