2020-05-15 02:23:08

by Jeffrey Hugo

[permalink] [raw]
Subject: [PATCH] bus: mhi: core: Use current ee in intvec handler

The intvec handler stores the caches ee in a local variable for use in
processing the intvec. It should instead use the current ee which is
read at the beginning of the intvec incase that the intvec is related to
an ee change. Otherwise, the handler might make the wrong decision
based on an incorrect ee.

Fixes: 3000f85b8f47 (bus: mhi: core: Add support for basic PM operations)
Signed-off-by: Jeffrey Hugo <[email protected]>
---
drivers/bus/mhi/core/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 7272a5a..0a41fe5 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -386,8 +386,8 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, void *dev)
write_lock_irq(&mhi_cntrl->pm_lock);
if (MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
state = mhi_get_mhi_state(mhi_cntrl);
- ee = mhi_cntrl->ee;
mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl);
+ ee = mhi_cntrl->ee;
}

if (state == MHI_STATE_SYS_ERR) {
--
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.


2020-05-16 03:04:22

by Bhaumik Bhatt

[permalink] [raw]
Subject: Re: [PATCH] bus: mhi: core: Use current ee in intvec handler

On 2020-05-14 19:17, Jeffrey Hugo wrote:
> The intvec handler stores the caches ee in a local variable for use in
> processing the intvec. It should instead use the current ee which is
> read at the beginning of the intvec incase that the intvec is related
> to
> an ee change. Otherwise, the handler might make the wrong decision
> based on an incorrect ee.
>
> Fixes: 3000f85b8f47 (bus: mhi: core: Add support for basic PM
> operations)
> Signed-off-by: Jeffrey Hugo <[email protected]>
> ---
> drivers/bus/mhi/core/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 7272a5a..0a41fe5 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -386,8 +386,8 @@ irqreturn_t mhi_intvec_threaded_handler(int
> irq_number, void *dev)
> write_lock_irq(&mhi_cntrl->pm_lock);
> if (MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
> state = mhi_get_mhi_state(mhi_cntrl);
> - ee = mhi_cntrl->ee;
> mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl);
> + ee = mhi_cntrl->ee;
> }
>
> if (state == MHI_STATE_SYS_ERR) {
Hi Jeff,

Let's hold off on this change for now please as we have some good set of
bug fixes and improvements coming in very soon. They're only pending
post
to LKML.

Thanks

2020-05-17 19:41:02

by Jeffrey Hugo

[permalink] [raw]
Subject: Re: [PATCH] bus: mhi: core: Use current ee in intvec handler

On 5/15/2020 8:58 PM, [email protected] wrote:
> On 2020-05-14 19:17, Jeffrey Hugo wrote:
>> The intvec handler stores the caches ee in a local variable for use in
>> processing the intvec.  It should instead use the current ee which is
>> read at the beginning of the intvec incase that the intvec is related to
>> an ee change.  Otherwise, the handler might make the wrong decision
>> based on an incorrect ee.
>>
>> Fixes: 3000f85b8f47 (bus: mhi: core: Add support for basic PM operations)
>> Signed-off-by: Jeffrey Hugo <[email protected]>
>> ---
>>  drivers/bus/mhi/core/main.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
>> index 7272a5a..0a41fe5 100644
>> --- a/drivers/bus/mhi/core/main.c
>> +++ b/drivers/bus/mhi/core/main.c
>> @@ -386,8 +386,8 @@ irqreturn_t mhi_intvec_threaded_handler(int
>> irq_number, void *dev)
>>      write_lock_irq(&mhi_cntrl->pm_lock);
>>      if (MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
>>          state = mhi_get_mhi_state(mhi_cntrl);
>> -        ee = mhi_cntrl->ee;
>>          mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl);
>> +        ee = mhi_cntrl->ee;
>>      }
>>
>>      if (state == MHI_STATE_SYS_ERR) {
> Hi Jeff,
>
> Let's hold off on this change for now please as we have some good set of
> bug fixes and improvements coming in very soon. They're only pending post
> to LKML.

Does that series of changes address the same issue this patch does, and
are they going to be posted soon (ie this week)?

--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

2020-05-18 17:33:46

by Bhaumik Bhatt

[permalink] [raw]
Subject: Re: [PATCH] bus: mhi: core: Use current ee in intvec handler

On 2020-05-17 12:38, Jeffrey Hugo wrote:
> On 5/15/2020 8:58 PM, [email protected] wrote:
>> On 2020-05-14 19:17, Jeffrey Hugo wrote:
>>> The intvec handler stores the caches ee in a local variable for use
>>> in
>>> processing the intvec.  It should instead use the current ee which is
>>> read at the beginning of the intvec incase that the intvec is related
>>> to
>>> an ee change.  Otherwise, the handler might make the wrong decision
>>> based on an incorrect ee.
>>>
>>> Fixes: 3000f85b8f47 (bus: mhi: core: Add support for basic PM
>>> operations)
>>> Signed-off-by: Jeffrey Hugo <[email protected]>
>>> ---
>>>  drivers/bus/mhi/core/main.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/bus/mhi/core/main.c
>>> b/drivers/bus/mhi/core/main.c
>>> index 7272a5a..0a41fe5 100644
>>> --- a/drivers/bus/mhi/core/main.c
>>> +++ b/drivers/bus/mhi/core/main.c
>>> @@ -386,8 +386,8 @@ irqreturn_t mhi_intvec_threaded_handler(int
>>> irq_number, void *dev)
>>>      write_lock_irq(&mhi_cntrl->pm_lock);
>>>      if (MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
>>>          state = mhi_get_mhi_state(mhi_cntrl);
>>> -        ee = mhi_cntrl->ee;
>>>          mhi_cntrl->ee = mhi_get_exec_env(mhi_cntrl);
>>> +        ee = mhi_cntrl->ee;
>>>      }
>>>
>>>      if (state == MHI_STATE_SYS_ERR) {
>> Hi Jeff,
>>
>> Let's hold off on this change for now please as we have some good set
>> of
>> bug fixes and improvements coming in very soon. They're only pending
>> post
>> to LKML.
>
> Does that series of changes address the same issue this patch does,
> and are they going to be posted soon (ie this week)?
Yes.