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

Date:   Wed, 2 Dec 2020 18:48:59 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Kalle Valo <kvalo@...eaurora.org>
Cc:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.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

On Wed, Dec 02, 2020 at 06:57:15PM +0200, Kalle Valo wrote:
> 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.

git wouldn't get confused, we do merges like this all the time.

It would confuse developers, I get confused by this type of thing all
the time :)

I'll just do the pull instead to keep my sanity, git is fine...

thanks,

greg k-h