lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <690515d16d21eec14b527982630968e3@codeaurora.org>
Date:   Tue, 13 Oct 2020 18:37:09 -0700
From:   Bhaumik Bhatt <bbhatt@...eaurora.org>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc:     linux-arm-msm@...r.kernel.org, hemantk@...eaurora.org,
        jhugo@...eaurora.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 08/10] bus: mhi: core: Move to an error state on any
 firmware load failure

On 2020-10-09 09:42, Manivannan Sadhasivam wrote:
> On Fri, Sep 18, 2020 at 07:02:33PM -0700, Bhaumik Bhatt wrote:
>> Move MHI to a firmware download error state for a failure to find
>> the firmware files or to load SBL or EBL image using BHI/BHIe. This
>> helps detect an error state sooner and shortens the wait for a
>> synchronous power up timeout.
>> 
>> Signed-off-by: Bhaumik Bhatt <bbhatt@...eaurora.org>
>> ---
>>  drivers/bus/mhi/core/boot.c | 43 
>> +++++++++++++++++++++++++------------------
>>  1 file changed, 25 insertions(+), 18 deletions(-)
>> 
>> diff --git a/drivers/bus/mhi/core/boot.c b/drivers/bus/mhi/core/boot.c
>> index 92b8dd3..fcc71f2 100644
>> --- a/drivers/bus/mhi/core/boot.c
>> +++ b/drivers/bus/mhi/core/boot.c
> 
> [...]
> 
>> -error_read:
>> +error_ready_state:
>>  	mhi_free_bhie_table(mhi_cntrl, mhi_cntrl->fbc_image);
>>  	mhi_cntrl->fbc_image = NULL;
>> 
>> -error_alloc_fw_table:
>> -	release_firmware(firmware);
>> +error_fw_load:
>> +	write_lock_irq(&mhi_cntrl->pm_lock);
>> +	mhi_cntrl->pm_state = MHI_PM_FW_DL_ERR;
>> +	wake_up_all(&mhi_cntrl->state_event);
> 
> Do you really need pm_lock for this?
> 
> Thanks,
> Mani
> 
Not really, the underlying usage does not matter if this lock is used or
not. We just want to error out so removing it.
>> +	write_unlock_irq(&mhi_cntrl->pm_lock);
>>  }
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project
>> 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,
a Linux Foundation Collaborative Project

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ