Hi Tejun,
On 04/16/2014 03:58 PM, Tejun Heo wrote:
Hello,
Thanks for the review. A brief description of the use-case first.
Token is intended to be used as a large grain lock and once locked,
it can be held in the locked state for long periods of time.
For instance, application will request
On Thu, Apr 17, 2014 at 02:01:32PM -0600, Shuah Khan wrote:
Operating on the lock should be atomic, which is what devres_update()
is doing. It can be simplified as follows by holding devres_lock
in devm_token_lock().
spin_lock_irqsave(dev-devres_lock, flags);
if (tkn_ptr-status ==
On Thu, Apr 17, 2014 at 04:10:34PM -0400, Tejun Heo wrote:
On Thu, Apr 17, 2014 at 02:01:32PM -0600, Shuah Khan wrote:
Operating on the lock should be atomic, which is what devres_update()
is doing. It can be simplified as follows by holding devres_lock
in devm_token_lock().
On 04/17/2014 02:10 PM, Tejun Heo wrote:
On Thu, Apr 17, 2014 at 02:01:32PM -0600, Shuah Khan wrote:
Operating on the lock should be atomic, which is what devres_update()
is doing. It can be simplified as follows by holding devres_lock
in devm_token_lock().
spin_lock_irqsave(dev-devres_lock,
On 04/17/2014 02:22 PM, Tejun Heo wrote:
On Thu, Apr 17, 2014 at 04:10:34PM -0400, Tejun Heo wrote:
Please do not implement locking
primitive directly if at all avoidable. Why can't it use a mutex
embedded in the data area of a devres entry? And if you for some
reason have to implement it
Hello,
On Wed, Apr 09, 2014 at 09:21:08AM -0600, Shuah Khan wrote:
+#define TOKEN_DEVRES_FREE0
+#define TOKEN_DEVRES_BUSY1
+
+struct token_devres {
+ int status;
+ charid[];
+};
Please just do bool busy and drop the constants.
+struct tkn_match {
+ int
