On 2014-12-02 11:02, Antti Palosaari wrote:
On 12/02/2014 11:47 AM, Akihiro TSUKADA wrote:
So at first it would be nice if someone could confirm my findings.
Applying the same kind of code like my patch and unplug something that
uses the affected frontend should be enough.
I tried that for tc90522, and I could remove earth-pt3
(which uses tc90522), tc90522 and tuner modules without any problem,
although earth-pt3 is a pci driver and does not use dvb-usb-v2.
From your log(?) output,
I guess that rtl28xxu_exit() removed the attached demod module
(mn88472) and thus free'ed fe BEFORE calling dvb_usbv2_exit(),
from where dvb_unregister_frontend(fe) is called.
I think that the demod i2c device is removed automatically by
dvb_usbv2_i2c_exit() in dvb_usbv2_exit(), if you registered
the demod i2c device, and your adapter/bridge driver
should not try to remove it.
Yes. You must unregister frontend before you remove driver. I have
already added new callbacks detach tuner and frontend to avoid that,
but there was yet again new issue as it removes rtl2832 demod driver
first and mn88472 slave demod was put to i2c bus / adapter which is
owned by rtl2832. So it will crash too. Solution is to convert rtl2832
to I2C binding (or convert mn88472 legacy DVB binding (which I don't
allow :)). When rtl2832 driver is converted to I2C model it is not
unloaded automatically and you could remove those in a correct order.
But hey, mn88472 is still on staging :D
regards
Antti
So the solution is to change rtl2832.c to the I2C model? And does this
issue only affect the mn8847x drivers ?
If this is the case would a patch that does not free the buffer but
leaks the memory be ok ? I can add a todo item and log it in syslog.
That would for sure be better then crashing the subsystem and the driver
is still in staging for a reason.
MvH
Benjamin Larsson
--
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
