From: "Arend van Spriel" <arend@broadcom.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: "Linux Wireless List" <linux-wireless@vger.kernel.org>,
"Greg KH" <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 0/9] brcm80211: minor bug fixes for broadcom driver
Date: Mon, 16 Apr 2012 10:51:05 +0200 [thread overview]
Message-ID: <4F8BDD79.6030008@broadcom.com> (raw)
In-Reply-To: <20120413175717.GD2616@tuxdriver.com>
On 04/13/2012 07:57 PM, John W. Linville wrote:
> On Wed, Apr 11, 2012 at 11:52:42AM +0200, Arend van Spriel wrote:
>
> In general, when mixing fixes and features/updates into a single
> series then the fixes should come at the beginning of the series.
> This helps to avoid dependencies on non-fix patches.
>
> I'll try to apply patch 9 to the wireless tree, and if that works I
> won't complain about it... :-)
>
> John
Like mentioned on collaboration summit, we may need a bit more education
on how to deal with stable fixes. I tagged the patch with cc to stable,
but not sure if that is the correct way to do it. The stable rules are
written in a generic way so I want know how the picture looks like when
moving patches upstream via a maintainer tree.
So here is my understanding:
1. submit patch without CC'ing stable against your wireless tree.
2. patch moves upstream to Dave's net tree.
3. patch moves further upstream to Linus' tree.
4. submit patch to stable with upstream commit id.
Is adding the CC to stable in step 1. a shortcut or is step 4. still
necessary in that case?
Gr. AvS
next prev parent reply other threads:[~2012-04-16 8:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-11 9:52 [PATCH 0/9] brcm80211: minor bug fixes for broadcom driver Arend van Spriel
2012-04-11 9:52 ` [PATCH 1/9] brcm80211: fmac: make brcmf_net_attach() static Arend van Spriel
2012-04-11 9:52 ` [PATCH 2/9] brcm80211: fmac: remove primary mac address handling from brcmf_net_attach Arend van Spriel
2012-04-11 9:52 ` [PATCH 3/9] brcm80211: fmac: register primary net device with device mac address Arend van Spriel
2012-04-11 9:52 ` [PATCH 4/9] brcm80211: fmac: add frame header extension support Arend van Spriel
2012-04-11 9:52 ` [PATCH 5/9] brcm80211: fmac: postpone dongle RF enabling Arend van Spriel
2012-04-11 9:52 ` [PATCH 6/9] brcm80211: fmac: clean up chip id table Arend van Spriel
2012-04-11 9:52 ` [PATCH 7/9] brcm80211: smac: do not use US as fallback regulatory hint Arend van Spriel
2012-04-13 14:48 ` Seth Forshee
2012-04-16 8:20 ` Arend van Spriel
2012-04-11 9:52 ` [PATCH 8/9] brcm80211: smac: only provide valid " Arend van Spriel
2012-04-11 9:52 ` [PATCH 9/9] brcm80211: smac: resume transmit fifo upon receiving frames Arend van Spriel
2012-04-13 17:57 ` [PATCH 0/9] brcm80211: minor bug fixes for broadcom driver John W. Linville
2012-04-16 8:51 ` Arend van Spriel [this message]
2012-04-16 17:18 ` John W. Linville
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F8BDD79.6030008@broadcom.com \
--to=arend@broadcom.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).