On Thursday 28 July 2011 00:23:06 Antti Palosaari wrote: > On 07/28/2011 01:07 AM, Malcolm Priestley wrote: > > On Wed, 2011-07-27 at 16:06 -0300, Mauro Carvalho Chehab wrote: > >> Em 25-07-2011 21:17, Antti Palosaari escreveu: > >>> Signed-off-by: Antti Palosaari<crope@xxxxxx> > >>> > >>> + adap->fe[i] = NULL; > >>> + /* In error case, do not try register more FEs, > >>> + * still leaving already registered FEs alive. */ > >> > >> I think that the proper thing to do is to detach everything, if one of > >> the attach fails. There isn't much sense on keeping the device > >> partially initialized. > >> > >> From memory, I recall the existing code doesn't detach the frontend > >> even > > > > if the device driver forces an error. So, the device driver must detach > > the frontend first. > > Yes, if you return for example error (or fe == NULL) for .tuner_attach() > it does not detach or deregister it - just silently discard all. I > thought very many times those when implementing this and keep very > careful not to change old functionality. > > > The trouble is that dvb-usb is becoming dated as new drivers tend to > > work around it. No one likes to touch it, out of fear of breaking > > existing drivers. > > Yes, so true. I have thought that too. There is a lot of things I want > to change but those are very hard without massive work. > > * We should have priv at the very first. No priv for FW DL example. > * Remote keytable should be property of certain device model not adapter > * There should be way to set count of adapter (and fe) in runtime (this > is why I allowed to fail 2nd FE attach silently) > * no probe (read eeprom etc) callback (I think read MAC could be renamed > for probe) > * no FE power control (GPIOs etc) that MFE patch adds this too > * maybe probe1 and probe2 callbacks needed. sequence something like plug > device => probe1 => download FW => probe2 => attach demod If I had more time I'd add * handle suspend/resume calls properly for buggy USB firmwares (iow: all devices I saw) -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- 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
