Hi
On Wed, Jun 14, 2017 at 1:58 PM, Arnd Bergmann wrote:
> Does that mean that we can have a concurrent hid_device_remove()
> and hid_device_probe() on the same device, using different
> drivers and actually still need the driver_lock for that? I would assume
> that the driver core handles that p
On Wed, Jun 14, 2017 at 9:45 AM, David Herrmann wrote:
> Hey
>
> On Wed, Jun 14, 2017 at 9:20 AM, Arnd Bergmann wrote:
>> On Wed, Jun 14, 2017 at 7:22 AM, Binoy Jayan wrote:
>>> Hi,
>>>
>>> On 14 June 2017 at 01:55, Arnd Bergmann wrote:
>>>
> The mutex code clearly states mutex_trylock() mu
Hey
On Wed, Jun 14, 2017 at 9:20 AM, Arnd Bergmann wrote:
> On Wed, Jun 14, 2017 at 7:22 AM, Binoy Jayan wrote:
>> Hi,
>>
>> On 14 June 2017 at 01:55, Arnd Bergmann wrote:
>>
The mutex code clearly states mutex_trylock() must not be used in
interrupt context (see kernel/locking/mutex.
On Wed, Jun 14, 2017 at 7:22 AM, Binoy Jayan wrote:
> Hi,
>
> On 14 June 2017 at 01:55, Arnd Bergmann wrote:
>
>>> The mutex code clearly states mutex_trylock() must not be used in
>>> interrupt context (see kernel/locking/mutex.c), hence we used a
>>> semaphore here. Unless the mutex code is cha
Hi,
On 14 June 2017 at 01:55, Arnd Bergmann wrote:
>> The mutex code clearly states mutex_trylock() must not be used in
>> interrupt context (see kernel/locking/mutex.c), hence we used a
>> semaphore here. Unless the mutex code is changed to allow this, we
>> cannot switch away from semaphores.
On Tue, Jun 13, 2017 at 5:43 PM, David Herrmann wrote:
> Hi
>
> On Tue, Jun 13, 2017 at 11:56 AM, Benjamin Tissoires
> wrote:
>>> > - struct semaphore driver_lock;
>>> > /* protects the current driver, except during input */
>>> > + struct mutex driv
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-inp
Hi
On Tue, Jun 13, 2017 at 11:56 AM, Benjamin Tissoires
wrote:
>> > - struct semaphore driver_lock; /*
>> > protects the current driver, except during input */
>> > + struct mutex driver_lock; /*
>> > protects t
Hi Arnd,
On 13 June 2017 at 15:15, Arnd Bergmann 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.
Will include them, thank you yet again for reminding me.
> You forgot to actually drop the defi
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 b
Hi,
On Jun 13 2017 or thereabouts, Arnd Bergmann wrote:
> On Tue, Jun 13, 2017 at 11:25 AM, Binoy Jayan wrote:
> > The semaphore 'driver_lock' is used as a simple mutex, and
> > also unnecessary as suggested by Arnd. Hence removing it, as
> > the concurrency between the probe and remove is alread
On Tue, Jun 13, 2017 at 11:25 AM, Binoy Jayan wrote:
> The semaphore 'driver_lock' is used as a simple mutex, and
> also unnecessary as suggested by Arnd. Hence removing it, as
> the concurrency between the probe and remove is already
> handled in the driver core.
>
> Signed-off-by: Binoy Jayan
>
The semaphore 'driver_lock' is used as a simple mutex, and
also unnecessary as suggested by Arnd. Hence removing it, as
the concurrency between the probe and remove is already
handled in the driver core.
Signed-off-by: Binoy Jayan
Suggested-by: Arnd Bergmann
---
v1 --> v2
Removed driver_lock
13 matches
Mail list logo
