Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-16 Thread Chanwoo Choi
Hi,

2018-06-14 20:33 GMT+09:00 H. Nikolaus Schaller :
>
>> Am 14.06.2018 um 12:39 schrieb H. Nikolaus Schaller :
>>
>> Hi Roger and Chanwoo,
>>
>>> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
>>>
>>> + H. Nikolaus Schaller 
>>>
>>> On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
 Previously, extcon used the spinlock before calling the notifier_call_chain
 to prevent the scheduled out of task and to prevent the notification delay.
 When spinlock is locked for sending the notification, deadlock issue
 occured on the side of extcon consumer device. To fix this issue,
 extcon consumer device should always use the work. it is always not
 reasonable to use work.

 To fix this issue on extcon consumer device, release locking when sending
 the notification of connector state.

 Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to 
 support the notification")
 Cc: sta...@vger.kernel.org
 Cc: Roger Quadros 
 Cc: Kishon Vijay Abraham I 
 Signed-off-by: Chanwoo Choi 
 ---
 drivers/extcon/extcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
 index 8bff5fd18185..f75b08a45d4e 100644
 --- a/drivers/extcon/extcon.c
 +++ b/drivers/extcon/extcon.c
 @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
 id)
 return index;

 spin_lock_irqsave(>lock, flags);
 -
 state = !!(edev->state & BIT(index));
 +   spin_unlock_irqrestore(>lock, flags);

 /*
  * Call functions in a raw notifier chain for the specific one
 @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
 id)
  */
 raw_notifier_call_chain(>nh_all, state, edev);

 +   spin_lock_irqsave(>lock, flags);
 /* This could be in interrupt handler */
 prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
 if (!prop_buf) {

>>
>> I have tested on the Pyra handheld prototype and now it works. Plugging in 
>> an OTG cable
>> enables/disables OTG power as expected and there are no kernel oops any more.
>
> I did take some minutes to check and it now also works again on the OMAP5EVM.
>
> BR,
> Nikolaus

Applied it.


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics


Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-16 Thread Chanwoo Choi
Hi,

2018-06-14 20:33 GMT+09:00 H. Nikolaus Schaller :
>
>> Am 14.06.2018 um 12:39 schrieb H. Nikolaus Schaller :
>>
>> Hi Roger and Chanwoo,
>>
>>> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
>>>
>>> + H. Nikolaus Schaller 
>>>
>>> On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
 Previously, extcon used the spinlock before calling the notifier_call_chain
 to prevent the scheduled out of task and to prevent the notification delay.
 When spinlock is locked for sending the notification, deadlock issue
 occured on the side of extcon consumer device. To fix this issue,
 extcon consumer device should always use the work. it is always not
 reasonable to use work.

 To fix this issue on extcon consumer device, release locking when sending
 the notification of connector state.

 Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to 
 support the notification")
 Cc: sta...@vger.kernel.org
 Cc: Roger Quadros 
 Cc: Kishon Vijay Abraham I 
 Signed-off-by: Chanwoo Choi 
 ---
 drivers/extcon/extcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
 index 8bff5fd18185..f75b08a45d4e 100644
 --- a/drivers/extcon/extcon.c
 +++ b/drivers/extcon/extcon.c
 @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
 id)
 return index;

 spin_lock_irqsave(>lock, flags);
 -
 state = !!(edev->state & BIT(index));
 +   spin_unlock_irqrestore(>lock, flags);

 /*
  * Call functions in a raw notifier chain for the specific one
 @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
 id)
  */
 raw_notifier_call_chain(>nh_all, state, edev);

 +   spin_lock_irqsave(>lock, flags);
 /* This could be in interrupt handler */
 prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
 if (!prop_buf) {

>>
>> I have tested on the Pyra handheld prototype and now it works. Plugging in 
>> an OTG cable
>> enables/disables OTG power as expected and there are no kernel oops any more.
>
> I did take some minutes to check and it now also works again on the OMAP5EVM.
>
> BR,
> Nikolaus

Applied it.


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics


Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-15 Thread Roger Quadros
On 14/06/18 07:14, Chanwoo Choi wrote:
> Previously, extcon used the spinlock before calling the notifier_call_chain
> to prevent the scheduled out of task and to prevent the notification delay.
> When spinlock is locked for sending the notification, deadlock issue
> occured on the side of extcon consumer device. To fix this issue,
> extcon consumer device should always use the work. it is always not
> reasonable to use work.
> 
> To fix this issue on extcon consumer device, release locking when sending
> the notification of connector state.
> 
> Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support 
> the notification")
> Cc: sta...@vger.kernel.org
> Cc: Roger Quadros 
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Chanwoo Choi 

Reviewed-by: Roger Quadros 

> ---
>  drivers/extcon/extcon.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 8bff5fd18185..f75b08a45d4e 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>   return index;
>  
>   spin_lock_irqsave(>lock, flags);
> -
>   state = !!(edev->state & BIT(index));
> + spin_unlock_irqrestore(>lock, flags);
>  
>   /*
>* Call functions in a raw notifier chain for the specific one
> @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>*/
>   raw_notifier_call_chain(>nh_all, state, edev);
>  
> + spin_lock_irqsave(>lock, flags);
>   /* This could be in interrupt handler */
>   prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
>   if (!prop_buf) {
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-15 Thread Roger Quadros
On 14/06/18 07:14, Chanwoo Choi wrote:
> Previously, extcon used the spinlock before calling the notifier_call_chain
> to prevent the scheduled out of task and to prevent the notification delay.
> When spinlock is locked for sending the notification, deadlock issue
> occured on the side of extcon consumer device. To fix this issue,
> extcon consumer device should always use the work. it is always not
> reasonable to use work.
> 
> To fix this issue on extcon consumer device, release locking when sending
> the notification of connector state.
> 
> Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support 
> the notification")
> Cc: sta...@vger.kernel.org
> Cc: Roger Quadros 
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Chanwoo Choi 

Reviewed-by: Roger Quadros 

> ---
>  drivers/extcon/extcon.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 8bff5fd18185..f75b08a45d4e 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>   return index;
>  
>   spin_lock_irqsave(>lock, flags);
> -
>   state = !!(edev->state & BIT(index));
> + spin_unlock_irqrestore(>lock, flags);
>  
>   /*
>* Call functions in a raw notifier chain for the specific one
> @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>*/
>   raw_notifier_call_chain(>nh_all, state, edev);
>  
> + spin_lock_irqsave(>lock, flags);
>   /* This could be in interrupt handler */
>   prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
>   if (!prop_buf) {
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-14 Thread Chanwoo Choi
Hi Roger,

If possible, Could you please review this patch? 

Regards,
Chanwoo Choi

On 2018년 06월 14일 20:33, H. Nikolaus Schaller wrote:
> 
>> Am 14.06.2018 um 12:39 schrieb H. Nikolaus Schaller :
>>
>> Hi Roger and Chanwoo,
>>
>>> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
>>>
>>> + H. Nikolaus Schaller 
>>>
>>> On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
 Previously, extcon used the spinlock before calling the notifier_call_chain
 to prevent the scheduled out of task and to prevent the notification delay.
 When spinlock is locked for sending the notification, deadlock issue
 occured on the side of extcon consumer device. To fix this issue,
 extcon consumer device should always use the work. it is always not
 reasonable to use work.

 To fix this issue on extcon consumer device, release locking when sending
 the notification of connector state.

 Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to 
 support the notification")
 Cc: sta...@vger.kernel.org
 Cc: Roger Quadros 
 Cc: Kishon Vijay Abraham I 
 Signed-off-by: Chanwoo Choi 
 ---
 drivers/extcon/extcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
 index 8bff5fd18185..f75b08a45d4e 100644
 --- a/drivers/extcon/extcon.c
 +++ b/drivers/extcon/extcon.c
 @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
 id)
return index;

spin_lock_irqsave(>lock, flags);
 -
state = !!(edev->state & BIT(index));
 +  spin_unlock_irqrestore(>lock, flags);

/*
 * Call functions in a raw notifier chain for the specific one
 @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
 id)
 */
raw_notifier_call_chain(>nh_all, state, edev);

 +  spin_lock_irqsave(>lock, flags);
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
if (!prop_buf) {

>>
>> I have tested on the Pyra handheld prototype and now it works. Plugging in 
>> an OTG cable
>> enables/disables OTG power as expected and there are no kernel oops any more.
> 
> I did take some minutes to check and it now also works again on the OMAP5EVM.
> 
> BR,
> Nikolaus
> 
> 



Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-14 Thread Chanwoo Choi
Hi Roger,

If possible, Could you please review this patch? 

Regards,
Chanwoo Choi

On 2018년 06월 14일 20:33, H. Nikolaus Schaller wrote:
> 
>> Am 14.06.2018 um 12:39 schrieb H. Nikolaus Schaller :
>>
>> Hi Roger and Chanwoo,
>>
>>> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
>>>
>>> + H. Nikolaus Schaller 
>>>
>>> On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
 Previously, extcon used the spinlock before calling the notifier_call_chain
 to prevent the scheduled out of task and to prevent the notification delay.
 When spinlock is locked for sending the notification, deadlock issue
 occured on the side of extcon consumer device. To fix this issue,
 extcon consumer device should always use the work. it is always not
 reasonable to use work.

 To fix this issue on extcon consumer device, release locking when sending
 the notification of connector state.

 Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to 
 support the notification")
 Cc: sta...@vger.kernel.org
 Cc: Roger Quadros 
 Cc: Kishon Vijay Abraham I 
 Signed-off-by: Chanwoo Choi 
 ---
 drivers/extcon/extcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
 index 8bff5fd18185..f75b08a45d4e 100644
 --- a/drivers/extcon/extcon.c
 +++ b/drivers/extcon/extcon.c
 @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
 id)
return index;

spin_lock_irqsave(>lock, flags);
 -
state = !!(edev->state & BIT(index));
 +  spin_unlock_irqrestore(>lock, flags);

/*
 * Call functions in a raw notifier chain for the specific one
 @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
 id)
 */
raw_notifier_call_chain(>nh_all, state, edev);

 +  spin_lock_irqsave(>lock, flags);
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
if (!prop_buf) {

>>
>> I have tested on the Pyra handheld prototype and now it works. Plugging in 
>> an OTG cable
>> enables/disables OTG power as expected and there are no kernel oops any more.
> 
> I did take some minutes to check and it now also works again on the OMAP5EVM.
> 
> BR,
> Nikolaus
> 
> 



Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-14 Thread H. Nikolaus Schaller


> Am 14.06.2018 um 12:39 schrieb H. Nikolaus Schaller :
> 
> Hi Roger and Chanwoo,
> 
>> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
>> 
>> + H. Nikolaus Schaller 
>> 
>> On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
>>> Previously, extcon used the spinlock before calling the notifier_call_chain
>>> to prevent the scheduled out of task and to prevent the notification delay.
>>> When spinlock is locked for sending the notification, deadlock issue
>>> occured on the side of extcon consumer device. To fix this issue,
>>> extcon consumer device should always use the work. it is always not
>>> reasonable to use work.
>>> 
>>> To fix this issue on extcon consumer device, release locking when sending
>>> the notification of connector state.
>>> 
>>> Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to 
>>> support the notification")
>>> Cc: sta...@vger.kernel.org
>>> Cc: Roger Quadros 
>>> Cc: Kishon Vijay Abraham I 
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>> drivers/extcon/extcon.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
>>> index 8bff5fd18185..f75b08a45d4e 100644
>>> --- a/drivers/extcon/extcon.c
>>> +++ b/drivers/extcon/extcon.c
>>> @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
>>> id)
>>> return index;
>>> 
>>> spin_lock_irqsave(>lock, flags);
>>> -
>>> state = !!(edev->state & BIT(index));
>>> +   spin_unlock_irqrestore(>lock, flags);
>>> 
>>> /*
>>>  * Call functions in a raw notifier chain for the specific one
>>> @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
>>> id)
>>>  */
>>> raw_notifier_call_chain(>nh_all, state, edev);
>>> 
>>> +   spin_lock_irqsave(>lock, flags);
>>> /* This could be in interrupt handler */
>>> prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
>>> if (!prop_buf) {
>>> 
> 
> I have tested on the Pyra handheld prototype and now it works. Plugging in an 
> OTG cable
> enables/disables OTG power as expected and there are no kernel oops any more.

I did take some minutes to check and it now also works again on the OMAP5EVM.

BR,
Nikolaus

Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-14 Thread H. Nikolaus Schaller


> Am 14.06.2018 um 12:39 schrieb H. Nikolaus Schaller :
> 
> Hi Roger and Chanwoo,
> 
>> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
>> 
>> + H. Nikolaus Schaller 
>> 
>> On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
>>> Previously, extcon used the spinlock before calling the notifier_call_chain
>>> to prevent the scheduled out of task and to prevent the notification delay.
>>> When spinlock is locked for sending the notification, deadlock issue
>>> occured on the side of extcon consumer device. To fix this issue,
>>> extcon consumer device should always use the work. it is always not
>>> reasonable to use work.
>>> 
>>> To fix this issue on extcon consumer device, release locking when sending
>>> the notification of connector state.
>>> 
>>> Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to 
>>> support the notification")
>>> Cc: sta...@vger.kernel.org
>>> Cc: Roger Quadros 
>>> Cc: Kishon Vijay Abraham I 
>>> Signed-off-by: Chanwoo Choi 
>>> ---
>>> drivers/extcon/extcon.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
>>> index 8bff5fd18185..f75b08a45d4e 100644
>>> --- a/drivers/extcon/extcon.c
>>> +++ b/drivers/extcon/extcon.c
>>> @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
>>> id)
>>> return index;
>>> 
>>> spin_lock_irqsave(>lock, flags);
>>> -
>>> state = !!(edev->state & BIT(index));
>>> +   spin_unlock_irqrestore(>lock, flags);
>>> 
>>> /*
>>>  * Call functions in a raw notifier chain for the specific one
>>> @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int 
>>> id)
>>>  */
>>> raw_notifier_call_chain(>nh_all, state, edev);
>>> 
>>> +   spin_lock_irqsave(>lock, flags);
>>> /* This could be in interrupt handler */
>>> prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
>>> if (!prop_buf) {
>>> 
> 
> I have tested on the Pyra handheld prototype and now it works. Plugging in an 
> OTG cable
> enables/disables OTG power as expected and there are no kernel oops any more.

I did take some minutes to check and it now also works again on the OMAP5EVM.

BR,
Nikolaus

Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-14 Thread H. Nikolaus Schaller
Hi Roger and Chanwoo,

> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
> 
> + H. Nikolaus Schaller 
> 
> On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
>> Previously, extcon used the spinlock before calling the notifier_call_chain
>> to prevent the scheduled out of task and to prevent the notification delay.
>> When spinlock is locked for sending the notification, deadlock issue
>> occured on the side of extcon consumer device. To fix this issue,
>> extcon consumer device should always use the work. it is always not
>> reasonable to use work.
>> 
>> To fix this issue on extcon consumer device, release locking when sending
>> the notification of connector state.
>> 
>> Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support 
>> the notification")
>> Cc: sta...@vger.kernel.org
>> Cc: Roger Quadros 
>> Cc: Kishon Vijay Abraham I 
>> Signed-off-by: Chanwoo Choi 
>> ---
>> drivers/extcon/extcon.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
>> index 8bff5fd18185..f75b08a45d4e 100644
>> --- a/drivers/extcon/extcon.c
>> +++ b/drivers/extcon/extcon.c
>> @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>>  return index;
>> 
>>  spin_lock_irqsave(>lock, flags);
>> -
>>  state = !!(edev->state & BIT(index));
>> +spin_unlock_irqrestore(>lock, flags);
>> 
>>  /*
>>   * Call functions in a raw notifier chain for the specific one
>> @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>>   */
>>  raw_notifier_call_chain(>nh_all, state, edev);
>> 
>> +spin_lock_irqsave(>lock, flags);
>>  /* This could be in interrupt handler */
>>  prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
>>  if (!prop_buf) {
>> 

I have tested on the Pyra handheld prototype and now it works. Plugging in an 
OTG cable
enables/disables OTG power as expected and there are no kernel oops any more.

So you can add my

Reported-by: H. Nikolaus Schaller 
Tested-by: H. Nikolaus Schaller 

BR and thank you for the quick fix,
Nikolaus

Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-14 Thread H. Nikolaus Schaller
Hi Roger and Chanwoo,

> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi :
> 
> + H. Nikolaus Schaller 
> 
> On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
>> Previously, extcon used the spinlock before calling the notifier_call_chain
>> to prevent the scheduled out of task and to prevent the notification delay.
>> When spinlock is locked for sending the notification, deadlock issue
>> occured on the side of extcon consumer device. To fix this issue,
>> extcon consumer device should always use the work. it is always not
>> reasonable to use work.
>> 
>> To fix this issue on extcon consumer device, release locking when sending
>> the notification of connector state.
>> 
>> Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support 
>> the notification")
>> Cc: sta...@vger.kernel.org
>> Cc: Roger Quadros 
>> Cc: Kishon Vijay Abraham I 
>> Signed-off-by: Chanwoo Choi 
>> ---
>> drivers/extcon/extcon.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
>> index 8bff5fd18185..f75b08a45d4e 100644
>> --- a/drivers/extcon/extcon.c
>> +++ b/drivers/extcon/extcon.c
>> @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>>  return index;
>> 
>>  spin_lock_irqsave(>lock, flags);
>> -
>>  state = !!(edev->state & BIT(index));
>> +spin_unlock_irqrestore(>lock, flags);
>> 
>>  /*
>>   * Call functions in a raw notifier chain for the specific one
>> @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>>   */
>>  raw_notifier_call_chain(>nh_all, state, edev);
>> 
>> +spin_lock_irqsave(>lock, flags);
>>  /* This could be in interrupt handler */
>>  prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
>>  if (!prop_buf) {
>> 

I have tested on the Pyra handheld prototype and now it works. Plugging in an 
OTG cable
enables/disables OTG power as expected and there are no kernel oops any more.

So you can add my

Reported-by: H. Nikolaus Schaller 
Tested-by: H. Nikolaus Schaller 

BR and thank you for the quick fix,
Nikolaus

Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-14 Thread Chanwoo Choi
+ H. Nikolaus Schaller 

On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
> Previously, extcon used the spinlock before calling the notifier_call_chain
> to prevent the scheduled out of task and to prevent the notification delay.
> When spinlock is locked for sending the notification, deadlock issue
> occured on the side of extcon consumer device. To fix this issue,
> extcon consumer device should always use the work. it is always not
> reasonable to use work.
> 
> To fix this issue on extcon consumer device, release locking when sending
> the notification of connector state.
> 
> Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support 
> the notification")
> Cc: sta...@vger.kernel.org
> Cc: Roger Quadros 
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/extcon/extcon.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 8bff5fd18185..f75b08a45d4e 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>   return index;
>  
>   spin_lock_irqsave(>lock, flags);
> -
>   state = !!(edev->state & BIT(index));
> + spin_unlock_irqrestore(>lock, flags);
>  
>   /*
>* Call functions in a raw notifier chain for the specific one
> @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>*/
>   raw_notifier_call_chain(>nh_all, state, edev);
>  
> + spin_lock_irqsave(>lock, flags);
>   /* This could be in interrupt handler */
>   prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
>   if (!prop_buf) {
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics


Re: [PATCH] extcon: Release locking when sending the notification of connector state

2018-06-14 Thread Chanwoo Choi
+ H. Nikolaus Schaller 

On 2018년 06월 14일 13:14, Chanwoo Choi wrote:
> Previously, extcon used the spinlock before calling the notifier_call_chain
> to prevent the scheduled out of task and to prevent the notification delay.
> When spinlock is locked for sending the notification, deadlock issue
> occured on the side of extcon consumer device. To fix this issue,
> extcon consumer device should always use the work. it is always not
> reasonable to use work.
> 
> To fix this issue on extcon consumer device, release locking when sending
> the notification of connector state.
> 
> Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support 
> the notification")
> Cc: sta...@vger.kernel.org
> Cc: Roger Quadros 
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/extcon/extcon.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 8bff5fd18185..f75b08a45d4e 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>   return index;
>  
>   spin_lock_irqsave(>lock, flags);
> -
>   state = !!(edev->state & BIT(index));
> + spin_unlock_irqrestore(>lock, flags);
>  
>   /*
>* Call functions in a raw notifier chain for the specific one
> @@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
>*/
>   raw_notifier_call_chain(>nh_all, state, edev);
>  
> + spin_lock_irqsave(>lock, flags);
>   /* This could be in interrupt handler */
>   prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
>   if (!prop_buf) {
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics


[PATCH] extcon: Release locking when sending the notification of connector state

2018-06-13 Thread Chanwoo Choi
Previously, extcon used the spinlock before calling the notifier_call_chain
to prevent the scheduled out of task and to prevent the notification delay.
When spinlock is locked for sending the notification, deadlock issue
occured on the side of extcon consumer device. To fix this issue,
extcon consumer device should always use the work. it is always not
reasonable to use work.

To fix this issue on extcon consumer device, release locking when sending
the notification of connector state.

Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support 
the notification")
Cc: sta...@vger.kernel.org
Cc: Roger Quadros 
Cc: Kishon Vijay Abraham I 
Signed-off-by: Chanwoo Choi 
---
 drivers/extcon/extcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 8bff5fd18185..f75b08a45d4e 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
return index;
 
spin_lock_irqsave(>lock, flags);
-
state = !!(edev->state & BIT(index));
+   spin_unlock_irqrestore(>lock, flags);
 
/*
 * Call functions in a raw notifier chain for the specific one
@@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
 */
raw_notifier_call_chain(>nh_all, state, edev);
 
+   spin_lock_irqsave(>lock, flags);
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
if (!prop_buf) {
-- 
1.9.1



[PATCH] extcon: Release locking when sending the notification of connector state

2018-06-13 Thread Chanwoo Choi
Previously, extcon used the spinlock before calling the notifier_call_chain
to prevent the scheduled out of task and to prevent the notification delay.
When spinlock is locked for sending the notification, deadlock issue
occured on the side of extcon consumer device. To fix this issue,
extcon consumer device should always use the work. it is always not
reasonable to use work.

To fix this issue on extcon consumer device, release locking when sending
the notification of connector state.

Fixes: ab11af049f88 ("extcon: Add the synchronization extcon APIs to support 
the notification")
Cc: sta...@vger.kernel.org
Cc: Roger Quadros 
Cc: Kishon Vijay Abraham I 
Signed-off-by: Chanwoo Choi 
---
 drivers/extcon/extcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index 8bff5fd18185..f75b08a45d4e 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -433,8 +433,8 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
return index;
 
spin_lock_irqsave(>lock, flags);
-
state = !!(edev->state & BIT(index));
+   spin_unlock_irqrestore(>lock, flags);
 
/*
 * Call functions in a raw notifier chain for the specific one
@@ -448,6 +448,7 @@ int extcon_sync(struct extcon_dev *edev, unsigned int id)
 */
raw_notifier_call_chain(>nh_all, state, edev);
 
+   spin_lock_irqsave(>lock, flags);
/* This could be in interrupt handler */
prop_buf = (char *)get_zeroed_page(GFP_ATOMIC);
if (!prop_buf) {
-- 
1.9.1