linux-kernel - Re: [PATCH v4 4/6] ath11k: set register access length for MHI driver

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Jun 2021 14:33:02 -0700
From:   Bhaumik Bhatt <bbhatt@...eaurora.org>
To:     Kalle Valo <kvalo@...eaurora.org>
Cc:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        linux-arm-msm@...r.kernel.org, hemantk@...eaurora.org,
        jhugo@...eaurora.org, linux-kernel@...r.kernel.org,
        loic.poulain@...aro.org, linux-wireless@...r.kernel.org,
        ath11k@...ts.infradead.org
Subject: Re: [PATCH v4 4/6] ath11k: set register access length for MHI driver

On 2021-06-23 10:34 AM, Kalle Valo wrote:
> Bhaumik Bhatt <bbhatt@...eaurora.org> writes:
> 
>> Hi Kalle,
>> 
>> On 2021-06-14 09:02 AM, Kalle Valo wrote:
>>> Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org> writes:
>>> 
>>>> On Thu, May 06, 2021 at 12:51:43PM -0700, Bhaumik Bhatt wrote:
>>>>> MHI driver requires register space length to add range checks and
>>>>> prevent memory region accesses outside of that for MMIO space.
>>>>> Set it before registering the MHI controller.
>>>>> 
>>>>> Signed-off-by: Bhaumik Bhatt <bbhatt@...eaurora.org>
>>>>> Reviewed-by: Hemant Kumar <hemantk@...eaurora.org>
>>>> 
>>>> Reviewed-by: Manivannan Sadhasivam 
>>>> <manivannan.sadhasivam@...aro.org>
>>>> 
>>>> Kalle, should we do immutable branch for this patch or I can pick
>>>> it up via MHI
>>>> tree (if there are no other patches expected from ath11k for this
>>>> controller)?
>>> 
>>> I'm not expecting any conflicts with this, and if there are, they
>>> should
>>> be easy for Stephen or Linus to fix. So it's easiest to route this 
>>> via
>>> your tree. But I'm not giving my ack yet, see below.
>>> 
>>> I'm worried that this patchset breaks bisect. Every patch in the
>>> patchset should not break existing functionality, what if only 
>>> patches
>>> 1-3 are included in the tree but not patch 4? Wouldn't ath11k be 
>>> broken
>>> then? I didn't review the whole patchset, but I suspect the fix is to
>>> include the ath11k change in the actual mhi patch which changes the
>>> functionality. So that way we would not have a separate ath11k patch 
>>> at
>>> all.
>>> 
>>> Also I'm not able to test this patchset at the moment. Can someone 
>>> else
>>> help and do a quick test with QCA6390 to verify these doesn't break
>>> ath11k?
>> 
>> I have requested someone to try and test this patch series with 
>> QCA6390.
>> 
>> I or the testers will get back to you with the test results when they
>> are available.
>> 
>> As far as your concerns go, you can choose to pick patches 1-3 and
>> that would be just fine.
>> 
>> Things will break if patchset 4 is _not_ in place with patchset 6
>> being part of the tree.
>> 
>> It would, however, be nice to pick the whole series instead and ensure
>> that the functionality MHI introduces for boot-up sanity is in place
>> for any controllers such as ath11k.
> 
> Just to be clear, this is not about me picking up any patches
> separately. I was instead making sure git-bisect works correctly, as it
> can randomly choose to test any commit in the tree. But based on your
> description everything seems to be in order in this patchset and bisect
> will work correctly.
> 
> git-bisect is an important tool for me when I'm searching the root 
> cause
> for ath11k regressions, that's why I'm so careful to make sure it 
> works.
OK. Understood.

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