Re: Splitting trigger header in two and barriers.

[Jonathan Cameron <jic23@cam.ac.uk>]

On 07/11/11 17:08, Jonathan Cameron wrote:
> On 07/11/11 16:51, Jonathan Cameron wrote:
>> Hi All,
>>
>> The trigger.h file merges elements I'd really rather were separate.
>> There are some parts that belong to drivers acting as consumers
>> and others to those acting as producers of triggers.
>> In a few cases  (e.g. lis3l02dq_ring.c) the consumer and trigger
>> are in the same file, but in many others the driver only supports
>> one or the other or has them in separate source files.
>>
>> The main block to this bit of reorganization ist that some drivers
>> explicitly put the trigger and detach from it in their 'ring cleanup'
>> functions (see ad7298_ring.c ad7298_ring_cleanup.)
>>
>> My original intent was that if a trigger had not been detached from
>> in userspace, it would not be possible to remmove the driver, so
>> no cleanup would occur. (basically it counts as being 'in use').
>>
>> Is there a usecase that demands this explicity disconnect, or
>> is it simply a case that the reference counting is going wrong
>> somewhere and hence this was needed in the drivers?
>>
>> Failing a good description of why this is there in these drivers,
>> I'd like to clean it out.  Will give us a much easier to follow
>> interface for the triggers.
> oops, just noticed I did this first in max1363. Will hammer that hard
> and see whether everything works as I think it should!
Ah, definitely doesn't work as I thought it did. Will fix and repost
when I have a simple solution to that.  Guess when one sees unexpected
code, one should expect it to have a reason for being there!

Sorry for the noise, though the basic question still stands, even if
a little more work is needed to fix the core first.

Jonathan