Jacek Anaszewski <j.anaszewski@xxxxxxxxxxx> wrote: >On 08/19/2013 09:08 PM, Jonathan Cameron wrote: > >>>>> - I am still encountering "module in use" message when I am >trying >>>>> to execute rmmod on a driver module after generic_buffer >application >>>>> has been launched at least once. This is not specific only >to my >>>>> implementation but also for lps331ap driver (the only one of >the >>>>> remaining IIO drivers supporting triggers I am able to test >>>>> currently). >>>> Umm.. I'm unsure, but it 'might' be something to do with the >interrupt issues >>>> that are firing the above warning (though I doubt it as the >lps331ap isn't >>>> suffering from that bug - as it currently stands in tree). >>>> Check that all the sysfs entries are as one would expect (no >trigger attached >>>> or buffered enabled etc). Might be a bug in generic_buffer but I >haven't >>>> personally seen it do this. >>> >>> Fixing the warning didn't fix this problem. I've checked sysfs >entries >>> - the buffer is not enabled, no trigger is attached. I don't know if >>> this is correct, but when I build build my driver as a module I get >>> also the module industrialio-triggered-buffer.ko built, which has to >>> be loaded prior to the driver module. >> That provides the triggered_buffer utility functions. When those are >used >> it needs to be there. >> >> Unfortunately this isn't something I can chase down without the >hardware. >> It works fine in the iio_dummy driver. Could you perhaps just build >that >> and check that works fine with a sysfs-trigger? Would act to >indicate >> if there is something causing the issue in this driver that we >haven't spotted >> or something nasty is going on in the core. > >I've managed to discover what is going on. The bad symptom is in the >information returned by lsmod. Before launching generic_buffer >application the "Used by" column for the driver module is 0. >After the application finishes it is 0x7fffffff. >I figured out that the problem is in the function >iio_trigger_write_current (industrialio-trigger.c:371). > >If I comment lines: > >if (oldtrig && indio_dev->trig != oldtrig) > iio_trigger_put(oldtrig); > >the issue ceases to appear. It seems that module_put is called too many >times. Ah. I am clearly blind. This is caused by setting a default trigger in the driver. None of my test drivers do that and generally it is considered a bad idea. If there is a strong argument for doing that then we need a utility function that also does an additional iio_trigger_get. I would rather we just dropped the setting of indio_dev->trig and left that to user space. As with having default sets of Channels enabled which we killed off during transition out of staging, it is much cleaner to make no assumptions about what the user wants. Please drop that line from the driver and repost with that little bit of suggested extra text in the binding. Sorry I should have picked up on this review before now and from your earlier comment is would guess there are a few other cases out there to be fixed up. Thanks for chasing this down! Jonathan > >Thanks, >Jacek > > >-- >To unsubscribe from this list: send the line "unsubscribe linux-iio" in >the body of a message to majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
