Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1605103 > unrolled thread
| Started by | Brian Norris <briannorris@chromium.org> |
|---|---|
| First post | 2017-03-20 21:10 +0100 |
| Last post | 2017-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.
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
| From | Brian Norris <briannorris@chromium.org> |
|---|---|
| Date | 2017-03-20 21:10 +0100 |
| Subject | Re: [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]
| From | Kalle Valo <kvalo@codeaurora.org> |
|---|---|
| Date | 2017-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]
| From | Brian Norris <briannorris@chromium.org> |
|---|---|
| Date | 2017-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