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

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

On Wednesday 15 Sep 2004 22:52, Andrew de Quincey wrote:
> > 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() ;)
>
> I've been implementing this suggestion. One reason I prefer having a flag
> in the adapter (as opposed to i2c_add_adapter_noprobe()) is the following
> situation:
>
> i2c_add_adapter_noprobe()
> .... hardware communicates with EEPROM
> .... in the meantime, another module is loaded which registers an
> i2c_driver with the I2C_DF_NOTIFY flag set - this will attempt to register
> this new driver with the the partially initialised adapter.
> ....
>
> Also, if new i2c adapters are loaded post-initialisation, they will also
> try to register with the adapter in turn.
>
> Having a flag means this situation cannot occur.

On second thoughts, I suppose this isn't as bad - with the class filtering and 
the callback, you would be able to filter out everything.

However, I think I would prefer to be able to just say NOPROBE once and for 
all and only have to worry about things registering themselves when I 
specifically call i2c_adapter_probe_drivers().