Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1605103 > unrolled thread

Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code

Started byBrian Norris <briannorris@chromium.org>
First post2017-03-20 21:10 +0100
Last post2017-03-21 17:00 +0100
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code Brian Norris <briannorris@chromium.org> - 2017-03-20 21:10 +0100
    Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code Kalle Valo <kvalo@codeaurora.org> - 2017-03-21 13:20 +0100
      Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code Brian Norris <briannorris@chromium.org> - 2017-03-21 17:00 +0100

#1605103 — Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code

FromBrian Norris <briannorris@chromium.org>
Date2017-03-20 21:10 +0100
SubjectRe: [4/4] mwifiex: pcie: de-duplicate buffer allocation code
Message-ID<tnbMS-1ns-19@gated-at.bofh.it>
Hi Kalle,

On Mon, Mar 20, 2017 at 05:08:35PM +0000, Kalle Valo wrote:
> Brian Norris <briannorris@chromium.org> wrote:
> > This code was duplicated as part of the PCIe FLR code added to this
> > driver. Let's de-duplicate it to:
> > 
> >  * make things easier to read (mwifiex_pcie_free_buffers() now has a
> >    corresponding mwifiex_pcie_alloc_buffers())
> >  * reduce likelihood of bugs
> >  * make error logging equally verbose
> >  * save lines of code!
> > 
> > Also drop some of the commentary that isn't really needed.
> > 
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> 
> Failed to apply:
> 
> fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/pcie.c).
> error: could not build fake ancestor
> Applying: mwifiex: pcie: de-duplicate buffer allocation code
> Patch failed at 0001 mwifiex: pcie: de-duplicate buffer allocation code
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> 
> Patch set to Changes Requested.

This applies fine to your wireless-drivers/master branch for me, where
patches 1-3 were applied. Are you applying this to
wireless-drivers-next? It's quite understandable that patch 4 wouldn't
apply there, as you've stripped out the previous patches...

Brian

[toc] | [next] | [standalone]


#1605556

FromKalle Valo <kvalo@codeaurora.org>
Date2017-03-21 13:20 +0100
Message-ID<tnqVB-3d4-29@gated-at.bofh.it>
In reply to#1605103
Brian Norris <briannorris@chromium.org> writes:

> On Mon, Mar 20, 2017 at 05:08:35PM +0000, Kalle Valo wrote:
>> Brian Norris <briannorris@chromium.org> wrote:
>> > This code was duplicated as part of the PCIe FLR code added to this
>> > driver. Let's de-duplicate it to:
>> > 
>> >  * make things easier to read (mwifiex_pcie_free_buffers() now has a
>> >    corresponding mwifiex_pcie_alloc_buffers())
>> >  * reduce likelihood of bugs
>> >  * make error logging equally verbose
>> >  * save lines of code!
>> > 
>> > Also drop some of the commentary that isn't really needed.
>> > 
>> > Signed-off-by: Brian Norris <briannorris@chromium.org>
>> 
>> Failed to apply:
>> 
>> fatal: sha1 information is lacking or useless
>> (drivers/net/wireless/marvell/mwifiex/pcie.c).
>> error: could not build fake ancestor
>> Applying: mwifiex: pcie: de-duplicate buffer allocation code
>> Patch failed at 0001 mwifiex: pcie: de-duplicate buffer allocation code
>> The copy of the patch that failed is found in: .git/rebase-apply/patch
>> 
>> Patch set to Changes Requested.
>
> This applies fine to your wireless-drivers/master branch for me, where
> patches 1-3 were applied. Are you applying this to
> wireless-drivers-next? It's quite understandable that patch 4 wouldn't
> apply there, as you've stripped out the previous patches...

I (wrongly) understood that patches 1-3 are for 4.11 and patch 4 is for
4.12, don't remember anymore how I got that impression. But I don't
think a cleanup patch like this is justified for 4.11 so I'm not
comfortable applying this to wireless-drivers (which should only contain
fixes to important bugs or regressions).

What I could do is to wait for the patches 1-3 trickle down to w-d-next
and then apply this patch. It usually takes few weeks, but with bad luck
it might happen only after the merge window. Would that work?

-- 
Kalle Valo

[toc] | [prev] | [next] | [standalone]


#1605751

FromBrian Norris <briannorris@chromium.org>
Date2017-03-21 17:00 +0100
Message-ID<tnumt-5mU-5@gated-at.bofh.it>
In reply to#1605556
On Tue, Mar 21, 2017 at 02:14:05PM +0200, Kalle Valo wrote:
> Brian Norris <briannorris@chromium.org> writes:
> > On Mon, Mar 20, 2017 at 05:08:35PM +0000, Kalle Valo wrote:
> >> Failed to apply:
> >> 
> >> fatal: sha1 information is lacking or useless
> >> (drivers/net/wireless/marvell/mwifiex/pcie.c).
> >> error: could not build fake ancestor
> >> Applying: mwifiex: pcie: de-duplicate buffer allocation code
> >> Patch failed at 0001 mwifiex: pcie: de-duplicate buffer allocation code
> >> The copy of the patch that failed is found in: .git/rebase-apply/patch
> >> 
> >> Patch set to Changes Requested.
> >
> > This applies fine to your wireless-drivers/master branch for me, where
> > patches 1-3 were applied. Are you applying this to
> > wireless-drivers-next? It's quite understandable that patch 4 wouldn't
> > apply there, as you've stripped out the previous patches...
> 
> I (wrongly) understood that patches 1-3 are for 4.11 and patch 4 is for
> 4.12, don't remember anymore how I got that impression. But I don't

Well, you're not exactly wrong. I mentioned in the cover letter that the
first 3 are bugfixes (probably for 4.11) and the 4th is not.

> think a cleanup patch like this is justified for 4.11 so I'm not
> comfortable applying this to wireless-drivers (which should only contain
> fixes to important bugs or regressions).

Right.

> What I could do is to wait for the patches 1-3 trickle down to w-d-next
> and then apply this patch. It usually takes few weeks, but with bad luck
> it might happen only after the merge window. Would that work?

Yeah, I figured something like that would happen. Seems fine to me.

Brian

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web