> Am 14.06.2018 um 12:39 schrieb H. Nikolaus Schaller <h...@goldelico.com>:
> 
> Hi Roger and Chanwoo,
> 
>> Am 14.06.2018 um 12:18 schrieb Chanwoo Choi <cw00.c...@samsung.com>:
>> 
>> + H. Nikolaus Schaller <h...@goldelico.com>
>> 
>> 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 <rog...@ti.com>
>>> Cc: Kishon Vijay Abraham I <kis...@ti.com>
>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com>
>>> ---
>>> 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(&edev->lock, flags);
>>> -
>>>     state = !!(edev->state & BIT(index));
>>> +   spin_unlock_irqrestore(&edev->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(&edev->nh_all, state, edev);
>>> 
>>> +   spin_lock_irqsave(&edev->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

Reply via email to