On Wed, 16 Oct 2013 20:45:39 +0300, Antti Palosaari wrote: > On 16.10.2013 20:33, Michael Krufky wrote: > > OK, I get it and it does seem OK. I'm just curious what kind of > > impact this refactoring would have over something like the > > b2c2-flexcop-fe driver, who does not know which ic's to attach based > > on device ids, but it does probe a few frontend combinations one after > > another, in an order that the driver authors knew was safe. I'd > > imaging that we'd write some helper abstraction function to switch out > > the info.type string as each driver gets probed? I think that can get > > quite ugly, but I know that the general population thinks dvb_attach() > > is even uglier, so maybe this could be the right path... > > > > Wanna take a crack at b2c2-flexcop-fe? > > heh, look the rtl28xxu driver in question, it does same. It probes maybe > total 10 tuners - checking their device ID too. Probing plain I2C device > address and making devision from that is simply dead idea. "Standard" > I2C address range for these silicon tuners are 0x60-0x64 => need to read > chip ID in order to detect => i2c_new_probed_device() is quite useless. Please remember you can pass a custom probe function to i2c_new_probed_device(). That probe function can read whatever chip ID register exists to decide if the probe should be successful or not. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
