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

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

[Jeffrey Hugo]

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 <jhugo@codeaurora.org>
---
 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.

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

[bbhatt]

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 <jhugo@codeaurora.org>
> ---
>  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

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

[Jeffrey Hugo]

On 5/15/2020 8:58 PM, bbhatt@codeaurora.org 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 <jhugo@codeaurora.org>
>> ---
>>  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.

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

[bbhatt]

On 2020-05-17 12:38, Jeffrey Hugo wrote:
> On 5/15/2020 8:58 PM, bbhatt@codeaurora.org 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 <jhugo@codeaurora.org>
>>> ---
>>>  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.