Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753968AbdFMUAs (ORCPT ); Tue, 13 Jun 2017 16:00:48 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:32833 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753875AbdFMUAq (ORCPT ); Tue, 13 Jun 2017 16:00:46 -0400 MIME-Version: 1.0 In-Reply-To: References: <1497345926-3262-1-git-send-email-binoy.jayan@linaro.org> <20170613095618.GB29589@mail.corp.redhat.com> From: Arnd Bergmann Date: Tue, 13 Jun 2017 22:00:44 +0200 X-Google-Sender-Auth: quEMHmRrvW-TSAZKoVhBZAm2aYM Message-ID: Subject: Re: [PATCH v2] HID: Replace semaphore driver_lock with mutex To: Binoy Jayan Cc: Benjamin Tissoires , linux-input@vger.kernel.org, Linux Kernel Mailing List , Rajendra , Mark Brown , Jiri Kosina , David Herrmann , Andrew de los Reyes Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1230 Lines: 34 On Tue, Jun 13, 2017 at 12:09 PM, Binoy Jayan wrote: > Hi, > > On 13 June 2017 at 15:26, Benjamin Tissoires > wrote: > >>> Looks good to me, but I see you didn't include David and Andrew on >>> Cc, it would be good for at least one of them to provide an Ack as well. >> >> Please also CC linux-input@ > > Will do that. >> (one more nitpick below too) >> A little bit below, there is: >> bool io_started; /* Protected by driver_lock. If IO has started */ >> >> You should probably remove the mention to driver_lock here. > > Will remove the reference too. > > Thank you for noticing that, initially I missed it as I thought > 'io_started' somehow > influences the increment of the semaphore, but its anyway used only in > hid-core.c It is also used in hid_device_io_start() and hid_device_io_stop(), but what's important here is that these are only ever called from inside of hid_device_probe() and other functions called by that, so no synchronization across CPUs is required here. I think in theory, it could be accessed from below hid_device_remove as well, but I did not find any instance of that. Arnd