Splitting trigger header in two and barriers.

Splitting trigger header in two and barriers.

[Jonathan Cameron]

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.

Thanks,

Jonathan

Re: Splitting trigger header in two and barriers.

[Jonathan Cameron]

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!

Re: Splitting trigger header in two and barriers.

[Jonathan Cameron]

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