linux-kernel - Re: [PATCH 01/29] bus: mhi: Remove auto-start option

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]

Message-ID: <87eek8i1sk.fsf@codeaurora.org>
Date:   Wed, 02 Dec 2020 18:57:15 +0200
From:   Kalle Valo <kvalo@...eaurora.org>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc:     gregkh@...uxfoundation.org, hemantk@...eaurora.org,
        bbhatt@...eaurora.org, linux-arm-msm@...r.kernel.org,
        jhugo@...eaurora.org, linux-kernel@...r.kernel.org,
        loic.poulain@...aro.org
Subject: Re: [PATCH 01/29] bus: mhi: Remove auto-start option

Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org> writes:

> On Wed, Dec 02, 2020 at 06:00:05PM +0200, Kalle Valo wrote:
>> Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org> writes:
>> 
>> > From: Loic Poulain <loic.poulain@...aro.org>
>> >
>> > There is really no point having an auto-start for channels.
>> > This is confusing for the device drivers, some have to enable the
>> > channels, others don't have... and waste resources (e.g. pre allocated
>> > buffers) that may never be used.
>> >
>> > This is really up to the MHI device(channel) driver to manage the state
>> > of its channels.
>> >
>> > While at it, let's also remove the auto-start option from ath11k mhi
>> > controller.
>> >
>> > Signed-off-by: Loic Poulain <loic.poulain@...aro.org>
>> > Acked-by: Kalle Valo <kvalo@...eaurora.org>
>> > Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
>> > [mani: clubbed ath11k change]
>> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
>> 
>> Hmm, didn't we apply this already? At least I pulled the immutable
>> branch to my tree:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=526740b495059ebbc0c3c086dceca1263820fa4f
>> 
>> So if there's a new version of this patch (and a new commit id) the
>> immutable branch I pulled is not immutable anymore.
>
> This is not a new version of the patch. The commit SHA of this patch in
> immutable branch is ed5298c7d500abaf34ed7783969e953a1f028e5b and that is same
> in mhi-next as well.
>
> Now I'm funneling all patches in mhi-next to mainline through Greg, so this
> patch is part of the (MHI changes for v5.11) patch series. Perhaps you might be
> dealing with pull requests to Dave/Jakub but since the MHI patch flow is usually
> fairly low, Greg is happy with patch series.
>
> But since we are dealing with immutable branch I should send the pull request
> to Greg now.

Yes, I very much prefer you send a pull request so that we can avoid
conflicts between ath11k and mhi. If Greg would apply this patch as is,
we would have two versions of the same commit (with different commit
ids) and git would get confused.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches