[Intel-gfx] [PATCH 1/2] drm: Add a non-locking version of drm_kms_helper_poll_enable(), v2

[Jani Nikula]

On Fri, 25 Sep 2015, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> On Fri, 25 Sep 2015, Egbert Eich <eich at suse.com> wrote:
>> Jani Nikula writes:
>>  > 
>>  > Shouldn't this be _unlocked?
>>  > 
>>  > I thought the convention was that functions that do not acquire locks
>>  > are called _unlocked (although they may require a lock to be held when
>>  > called). And you might have foo() that grabs locks around a call to
>>  > foo_unlocked().
>>  > 
>>
>> Looking into this, functions that are to be called in a context where
>> the lock is already held should receive the suffix _locked while
>> those which do locking themselves and thus need to be called from
>> a context that doesn't hold this lock already receive the suffix 
>> _unlocked: the past tense refers to what has happened before.
>
> I'm afraid existing conventions trump what makes sense.

Egbert, I'm full of shit. Sorry. $BEVERAGE on me next time.

I'll queue these once I figure out through which tree.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center