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
I think perhaps some kind of legacy wrapper is needed here, with the
moving of dvb-usb to its own core, so more development work can be done.
Wish like to thank you these comments Malcolm!
regards
Antti
--
http://palosaari.fi/
--
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
