[PATCH] less eventcause shifts

[PATCH] less eventcause shifts

[Holger Schurig]

* only shift eventcause once

* convert mac events to decimal, as this is what the firmware
  manual uses in section 6.1, too

Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>

Index: wireless-2.6/drivers/net/wireless/libertas/cmdresp.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/libertas/cmdresp.c	2007-11-28 10:07:27.000000000 +0100
+++ wireless-2.6/drivers/net/wireless/libertas/cmdresp.c	2007-11-28 10:15:07.000000000 +0100
@@ -899,12 +899,12 @@ int lbs_process_event(struct lbs_private
 	lbs_deb_enter(LBS_DEB_CMD);
 
 	spin_lock_irq(&adapter->driver_lock);
-	eventcause = adapter->eventcause;
+	eventcause = adapter->eventcause >> SBI_EVENT_CAUSE_SHIFT;
 	spin_unlock_irq(&adapter->driver_lock);
 
-	lbs_deb_cmd("event cause 0x%x\n", eventcause);
+	lbs_deb_cmd("event cause %d\n", eventcause);
 
-	switch (eventcause >> SBI_EVENT_CAUSE_SHIFT) {
+	switch (eventcause) {
 	case MACREG_INT_CODE_LINK_SENSED:
 		lbs_deb_cmd("EVENT: MACREG_INT_CODE_LINK_SENSED\n");
 		break;
@@ -919,7 +919,7 @@ int lbs_process_event(struct lbs_private
 		lbs_mac_event_disconnected(priv);
 		break;
 
-	case MACREG_INT_CODE_LINK_LOSE_NO_SCAN:
+	case MACREG_INT_CODE_LINK_LOST_NO_SCAN:
 		lbs_deb_cmd("EVENT: link lost\n");
 		lbs_mac_event_disconnected(priv);
 		break;
@@ -1013,8 +1013,7 @@ int lbs_process_event(struct lbs_private
 		break;
 
 	default:
-		lbs_pr_alert("EVENT: unknown event id 0x%04x\n",
-		       eventcause >> SBI_EVENT_CAUSE_SHIFT);
+		lbs_pr_alert("EVENT: unknown event id %d\n", eventcause);
 		break;
 	}
 
Index: wireless-2.6/drivers/net/wireless/libertas/host.h
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/libertas/host.h	2007-11-28 10:07:40.000000000 +0100
+++ wireless-2.6/drivers/net/wireless/libertas/host.h	2007-11-28 10:15:57.000000000 +0100
@@ -272,27 +272,35 @@ enum cmd_mesh_access_opts {
 };
 
 /** Card Event definition */
-#define MACREG_INT_CODE_TX_PPA_FREE             0x00000000
-#define MACREG_INT_CODE_TX_DMA_DONE             0x00000001
-#define MACREG_INT_CODE_LINK_LOSE_W_SCAN        0x00000002
-#define MACREG_INT_CODE_LINK_LOSE_NO_SCAN       0x00000003
-#define MACREG_INT_CODE_LINK_SENSED             0x00000004
-#define MACREG_INT_CODE_CMD_FINISHED            0x00000005
-#define MACREG_INT_CODE_MIB_CHANGED             0x00000006
-#define MACREG_INT_CODE_INIT_DONE               0x00000007
-#define MACREG_INT_CODE_DEAUTHENTICATED         0x00000008
-#define MACREG_INT_CODE_DISASSOCIATED           0x00000009
-#define MACREG_INT_CODE_PS_AWAKE                0x0000000a
-#define MACREG_INT_CODE_PS_SLEEP                0x0000000b
-#define MACREG_INT_CODE_MIC_ERR_MULTICAST       0x0000000d
-#define MACREG_INT_CODE_MIC_ERR_UNICAST         0x0000000e
-#define MACREG_INT_CODE_WM_AWAKE                0x0000000f
-#define MACREG_INT_CODE_ADHOC_BCN_LOST          0x00000011
-#define MACREG_INT_CODE_RSSI_LOW		0x00000019
-#define MACREG_INT_CODE_SNR_LOW			0x0000001a
-#define MACREG_INT_CODE_MAX_FAIL		0x0000001b
-#define MACREG_INT_CODE_RSSI_HIGH		0x0000001c
-#define MACREG_INT_CODE_SNR_HIGH		0x0000001d
-#define MACREG_INT_CODE_MESH_AUTO_STARTED	0x00000023
+#define MACREG_INT_CODE_TX_PPA_FREE             0
+#define MACREG_INT_CODE_TX_DMA_DONE             1
+#define MACREG_INT_CODE_LINK_LOST_W_SCAN        2
+#define MACREG_INT_CODE_LINK_LOST_NO_SCAN       3
+#define MACREG_INT_CODE_LINK_SENSED             4
+#define MACREG_INT_CODE_CMD_FINISHED            5
+#define MACREG_INT_CODE_MIB_CHANGED             6
+#define MACREG_INT_CODE_INIT_DONE               7
+#define MACREG_INT_CODE_DEAUTHENTICATED         8
+#define MACREG_INT_CODE_DISASSOCIATED           9
+#define MACREG_INT_CODE_PS_AWAKE                10
+#define MACREG_INT_CODE_PS_SLEEP                11
+#define MACREG_INT_CODE_MIC_ERR_MULTICAST       13
+#define MACREG_INT_CODE_MIC_ERR_UNICAST         14
+#define MACREG_INT_CODE_WM_AWAKE                15
+#define MACREG_INT_CODE_DEEP_SLEEP_AWAKE        16
+#define MACREG_INT_CODE_ADHOC_BCN_LOST          17
+#define MACREG_INT_CODE_HOST_AWAKE              18
+#define MACREG_INT_CODE_STOP_TX                 19
+#define MACREG_INT_CODE_START_TX                20
+#define MACREG_INT_CODE_CHANNEL_SWITCH          21
+#define MACREG_INT_CODE_MEASUREMENT_RDY         22
+#define MACREG_INT_CODE_WMM_CHANGE              23
+#define MACREG_INT_CODE_BG_SCAN_REPORT          24
+#define MACREG_INT_CODE_RSSI_LOW                25
+#define MACREG_INT_CODE_SNR_LOW                 26
+#define MACREG_INT_CODE_MAX_FAIL                27
+#define MACREG_INT_CODE_RSSI_HIGH               28
+#define MACREG_INT_CODE_SNR_HIGH                29
+#define MACREG_INT_CODE_MESH_AUTO_STARTED       35
 
 #endif

Re: [PATCH] less eventcause shifts

[Dan Williams]

On Wed, 2007-11-28 at 09:15 +0100, Holger Schurig wrote:
> * only shift eventcause once
> 
> * convert mac events to decimal, as this is what the firmware
>   manual uses in section 6.1, too
> 
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>

Acked-by: Dan Williams <dcbw@redhat.com>

> Index: wireless-2.6/drivers/net/wireless/libertas/cmdresp.c
> ===================================================================
> --- wireless-2.6.orig/drivers/net/wireless/libertas/cmdresp.c	2007-11-28 10:07:27.000000000 +0100
> +++ wireless-2.6/drivers/net/wireless/libertas/cmdresp.c	2007-11-28 10:15:07.000000000 +0100
> @@ -899,12 +899,12 @@ int lbs_process_event(struct lbs_private
>  	lbs_deb_enter(LBS_DEB_CMD);
>  
>  	spin_lock_irq(&adapter->driver_lock);
> -	eventcause = adapter->eventcause;
> +	eventcause = adapter->eventcause >> SBI_EVENT_CAUSE_SHIFT;
>  	spin_unlock_irq(&adapter->driver_lock);
>  
> -	lbs_deb_cmd("event cause 0x%x\n", eventcause);
> +	lbs_deb_cmd("event cause %d\n", eventcause);
>  
> -	switch (eventcause >> SBI_EVENT_CAUSE_SHIFT) {
> +	switch (eventcause) {
>  	case MACREG_INT_CODE_LINK_SENSED:
>  		lbs_deb_cmd("EVENT: MACREG_INT_CODE_LINK_SENSED\n");
>  		break;
> @@ -919,7 +919,7 @@ int lbs_process_event(struct lbs_private
>  		lbs_mac_event_disconnected(priv);
>  		break;
>  
> -	case MACREG_INT_CODE_LINK_LOSE_NO_SCAN:
> +	case MACREG_INT_CODE_LINK_LOST_NO_SCAN:
>  		lbs_deb_cmd("EVENT: link lost\n");
>  		lbs_mac_event_disconnected(priv);
>  		break;
> @@ -1013,8 +1013,7 @@ int lbs_process_event(struct lbs_private
>  		break;
>  
>  	default:
> -		lbs_pr_alert("EVENT: unknown event id 0x%04x\n",
> -		       eventcause >> SBI_EVENT_CAUSE_SHIFT);
> +		lbs_pr_alert("EVENT: unknown event id %d\n", eventcause);
>  		break;
>  	}
>  
> Index: wireless-2.6/drivers/net/wireless/libertas/host.h
> ===================================================================
> --- wireless-2.6.orig/drivers/net/wireless/libertas/host.h	2007-11-28 10:07:40.000000000 +0100
> +++ wireless-2.6/drivers/net/wireless/libertas/host.h	2007-11-28 10:15:57.000000000 +0100
> @@ -272,27 +272,35 @@ enum cmd_mesh_access_opts {
>  };
>  
>  /** Card Event definition */
> -#define MACREG_INT_CODE_TX_PPA_FREE             0x00000000
> -#define MACREG_INT_CODE_TX_DMA_DONE             0x00000001
> -#define MACREG_INT_CODE_LINK_LOSE_W_SCAN        0x00000002
> -#define MACREG_INT_CODE_LINK_LOSE_NO_SCAN       0x00000003
> -#define MACREG_INT_CODE_LINK_SENSED             0x00000004
> -#define MACREG_INT_CODE_CMD_FINISHED            0x00000005
> -#define MACREG_INT_CODE_MIB_CHANGED             0x00000006
> -#define MACREG_INT_CODE_INIT_DONE               0x00000007
> -#define MACREG_INT_CODE_DEAUTHENTICATED         0x00000008
> -#define MACREG_INT_CODE_DISASSOCIATED           0x00000009
> -#define MACREG_INT_CODE_PS_AWAKE                0x0000000a
> -#define MACREG_INT_CODE_PS_SLEEP                0x0000000b
> -#define MACREG_INT_CODE_MIC_ERR_MULTICAST       0x0000000d
> -#define MACREG_INT_CODE_MIC_ERR_UNICAST         0x0000000e
> -#define MACREG_INT_CODE_WM_AWAKE                0x0000000f
> -#define MACREG_INT_CODE_ADHOC_BCN_LOST          0x00000011
> -#define MACREG_INT_CODE_RSSI_LOW		0x00000019
> -#define MACREG_INT_CODE_SNR_LOW			0x0000001a
> -#define MACREG_INT_CODE_MAX_FAIL		0x0000001b
> -#define MACREG_INT_CODE_RSSI_HIGH		0x0000001c
> -#define MACREG_INT_CODE_SNR_HIGH		0x0000001d
> -#define MACREG_INT_CODE_MESH_AUTO_STARTED	0x00000023
> +#define MACREG_INT_CODE_TX_PPA_FREE             0
> +#define MACREG_INT_CODE_TX_DMA_DONE             1
> +#define MACREG_INT_CODE_LINK_LOST_W_SCAN        2
> +#define MACREG_INT_CODE_LINK_LOST_NO_SCAN       3
> +#define MACREG_INT_CODE_LINK_SENSED             4
> +#define MACREG_INT_CODE_CMD_FINISHED            5
> +#define MACREG_INT_CODE_MIB_CHANGED             6
> +#define MACREG_INT_CODE_INIT_DONE               7
> +#define MACREG_INT_CODE_DEAUTHENTICATED         8
> +#define MACREG_INT_CODE_DISASSOCIATED           9
> +#define MACREG_INT_CODE_PS_AWAKE                10
> +#define MACREG_INT_CODE_PS_SLEEP                11
> +#define MACREG_INT_CODE_MIC_ERR_MULTICAST       13
> +#define MACREG_INT_CODE_MIC_ERR_UNICAST         14
> +#define MACREG_INT_CODE_WM_AWAKE                15
> +#define MACREG_INT_CODE_DEEP_SLEEP_AWAKE        16
> +#define MACREG_INT_CODE_ADHOC_BCN_LOST          17
> +#define MACREG_INT_CODE_HOST_AWAKE              18
> +#define MACREG_INT_CODE_STOP_TX                 19
> +#define MACREG_INT_CODE_START_TX                20
> +#define MACREG_INT_CODE_CHANNEL_SWITCH          21
> +#define MACREG_INT_CODE_MEASUREMENT_RDY         22
> +#define MACREG_INT_CODE_WMM_CHANGE              23
> +#define MACREG_INT_CODE_BG_SCAN_REPORT          24
> +#define MACREG_INT_CODE_RSSI_LOW                25
> +#define MACREG_INT_CODE_SNR_LOW                 26
> +#define MACREG_INT_CODE_MAX_FAIL                27
> +#define MACREG_INT_CODE_RSSI_HIGH               28
> +#define MACREG_INT_CODE_SNR_HIGH                29
> +#define MACREG_INT_CODE_MESH_AUTO_STARTED       35
>  
>  #endif

Re: [PATCH] less eventcause shifts

[David Woodhouse]

On Wed, 2007-11-28 at 09:53 -0500, Dan Williams wrote:
> On Wed, 2007-11-28 at 09:15 +0100, Holger Schurig wrote:
> > * only shift eventcause once
> > 
> > * convert mac events to decimal, as this is what the firmware
> >   manual uses in section 6.1, too
> > 
> > Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
> 
> Acked-by: Dan Williams <dcbw@redhat.com>

s/less/fewer/ of course :)

Since I'm also going to be sending a flurry of libertas patches and the
turnaround through the wireless tree seems suboptimal, shall we put up a
git tree and work on it together, then ask John to pull when we're done?

-- 
dwmw2

Re: [PATCH] less eventcause shifts

[Holger Schurig]

> s/less/fewer/ of course :)

Thanks. Should I re-submit?


> Since I'm also going to be sending a flurry of libertas
> patches and the turnaround through the wireless tree seems
> suboptimal, shall we put up a git tree and work on it
> together, then ask John to pull when we're done?

That might be an option. Currently, I'm working with 
wireless-2.6/everything and quilt (because it's faster then 
stgit).

My goal with libertas is better roaming in an STA+MANY APs 
scenario. Right now libertas is almost unusable for my usage 
work type. The new-scan patch is just a stepstone in this 
direction (so that I understand scanning much better). Also my 
janitor-like patches are just by-products of getting used to the 
code-base.

In what parts of libertas are you working?

Re: [PATCH] less eventcause shifts

[Dan Williams]

On Wed, 2007-11-28 at 16:13 +0100, Holger Schurig wrote:
> > s/less/fewer/ of course :)
> 
> Thanks. Should I re-submit?
> 
> 
> > Since I'm also going to be sending a flurry of libertas
> > patches and the turnaround through the wireless tree seems
> > suboptimal, shall we put up a git tree and work on it
> > together, then ask John to pull when we're done?
> 
> That might be an option. Currently, I'm working with 
> wireless-2.6/everything and quilt (because it's faster then 
> stgit).
> 
> My goal with libertas is better roaming in an STA+MANY APs 
> scenario. Right now libertas is almost unusable for my usage 
> work type. The new-scan patch is just a stepstone in this 
> direction (so that I understand scanning much better). Also my 
> janitor-like patches are just by-products of getting used to the 
> code-base.
> 
> In what parts of libertas are you working?

He's reworking the firmware command handling to not be quite as sucky
and obfuscated.  It's gonna be a big patch.

Dan

Re: [PATCH] less eventcause shifts

[David Woodhouse]

On Wed, 2007-11-28 at 16:13 +0100, Holger Schurig wrote:
> > s/less/fewer/ of course :)
> 
> Thanks. Should I re-submit?

Well, if we're going to put up a git tree, you could just fix it when
you commit to that.

I've just pushed a couple of preliminary patches to
git://git.infradead.org/libertas-2.6.git, which is based on the
'everything' branch (I wish people wouldn't use branches) of
wireless-2.6.git

Let me have a SSH public key and I'll give you an account with access to
that tree.

> In what parts of libertas are you working?

Rewriting the command submission and queueing code.

I could do with getting hold of SD and CF devices -- any hints on where
to find them?

-- 
dwmw2

Re: [PATCH] less eventcause shifts

[Holger Schurig]

> Let me have a SSH public key and I'll give you an account with
> access to that tree.

You have it already. I actually once put my patches into a git 
tree, but no one pulled from it (neither Dan nor Linville), so I 
stopped the extra work.

My username at git.infradead.org (a.k.a. bombadil) is "schurig".

However, wireless-2.6/everything is now 8 days old. Shouldn't we 
prod Linville a bit more?



> > In what parts of libertas are you working?

> Rewriting the command submission and queueing code.

Cool.


> I could do with getting hold of SD and CF devices -- any hints
> on where to find them?

About the SD card: ask "ossmann" on #libertas on freenode.net.

For the CF card: Ambicom WL54CF. However, I've got mine from some 
company in Germany (which name I forgot ...).

Re: [PATCH] less eventcause shifts

[Dan Williams]

On Wed, 2007-11-28 at 15:02 +0000, David Woodhouse wrote:
> On Wed, 2007-11-28 at 09:53 -0500, Dan Williams wrote:
> > On Wed, 2007-11-28 at 09:15 +0100, Holger Schurig wrote:
> > > * only shift eventcause once
> > > 
> > > * convert mac events to decimal, as this is what the firmware
> > >   manual uses in section 6.1, too
> > > 
> > > Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
> > 
> > Acked-by: Dan Williams <dcbw@redhat.com>
> 
> s/less/fewer/ of course :)
> 
> Since I'm also going to be sending a flurry of libertas patches and the
> turnaround through the wireless tree seems suboptimal, shall we put up a
> git tree and work on it together, then ask John to pull when we're done?

Good idea, as long as it's topical and short-lived.  I don't want
another long-lived libertas-2.6.

Dan

Re: [PATCH] less eventcause shifts

[Dan Williams]

On Wed, 2007-11-28 at 09:15 +0100, Holger Schurig wrote:
> * only shift eventcause once
> 
> * convert mac events to decimal, as this is what the firmware
>   manual uses in section 6.1, too
> 
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>

I'm sort of sitting on these patches until you and Woodhouse start using
the same git tree until he's done with the command rework...  It's going
to be near impossible to handle both of your patches with any certainty.
Any progress on whether you've both been able to work in the same repo?

Dan

> Index: wireless-2.6/drivers/net/wireless/libertas/cmdresp.c
> ===================================================================
> --- wireless-2.6.orig/drivers/net/wireless/libertas/cmdresp.c	2007-11-28 10:07:27.000000000 +0100
> +++ wireless-2.6/drivers/net/wireless/libertas/cmdresp.c	2007-11-28 10:15:07.000000000 +0100
> @@ -899,12 +899,12 @@ int lbs_process_event(struct lbs_private
>  	lbs_deb_enter(LBS_DEB_CMD);
>  
>  	spin_lock_irq(&adapter->driver_lock);
> -	eventcause = adapter->eventcause;
> +	eventcause = adapter->eventcause >> SBI_EVENT_CAUSE_SHIFT;
>  	spin_unlock_irq(&adapter->driver_lock);
>  
> -	lbs_deb_cmd("event cause 0x%x\n", eventcause);
> +	lbs_deb_cmd("event cause %d\n", eventcause);
>  
> -	switch (eventcause >> SBI_EVENT_CAUSE_SHIFT) {
> +	switch (eventcause) {
>  	case MACREG_INT_CODE_LINK_SENSED:
>  		lbs_deb_cmd("EVENT: MACREG_INT_CODE_LINK_SENSED\n");
>  		break;
> @@ -919,7 +919,7 @@ int lbs_process_event(struct lbs_private
>  		lbs_mac_event_disconnected(priv);
>  		break;
>  
> -	case MACREG_INT_CODE_LINK_LOSE_NO_SCAN:
> +	case MACREG_INT_CODE_LINK_LOST_NO_SCAN:
>  		lbs_deb_cmd("EVENT: link lost\n");
>  		lbs_mac_event_disconnected(priv);
>  		break;
> @@ -1013,8 +1013,7 @@ int lbs_process_event(struct lbs_private
>  		break;
>  
>  	default:
> -		lbs_pr_alert("EVENT: unknown event id 0x%04x\n",
> -		       eventcause >> SBI_EVENT_CAUSE_SHIFT);
> +		lbs_pr_alert("EVENT: unknown event id %d\n", eventcause);
>  		break;
>  	}
>  
> Index: wireless-2.6/drivers/net/wireless/libertas/host.h
> ===================================================================
> --- wireless-2.6.orig/drivers/net/wireless/libertas/host.h	2007-11-28 10:07:40.000000000 +0100
> +++ wireless-2.6/drivers/net/wireless/libertas/host.h	2007-11-28 10:15:57.000000000 +0100
> @@ -272,27 +272,35 @@ enum cmd_mesh_access_opts {
>  };
>  
>  /** Card Event definition */
> -#define MACREG_INT_CODE_TX_PPA_FREE             0x00000000
> -#define MACREG_INT_CODE_TX_DMA_DONE             0x00000001
> -#define MACREG_INT_CODE_LINK_LOSE_W_SCAN        0x00000002
> -#define MACREG_INT_CODE_LINK_LOSE_NO_SCAN       0x00000003
> -#define MACREG_INT_CODE_LINK_SENSED             0x00000004
> -#define MACREG_INT_CODE_CMD_FINISHED            0x00000005
> -#define MACREG_INT_CODE_MIB_CHANGED             0x00000006
> -#define MACREG_INT_CODE_INIT_DONE               0x00000007
> -#define MACREG_INT_CODE_DEAUTHENTICATED         0x00000008
> -#define MACREG_INT_CODE_DISASSOCIATED           0x00000009
> -#define MACREG_INT_CODE_PS_AWAKE                0x0000000a
> -#define MACREG_INT_CODE_PS_SLEEP                0x0000000b
> -#define MACREG_INT_CODE_MIC_ERR_MULTICAST       0x0000000d
> -#define MACREG_INT_CODE_MIC_ERR_UNICAST         0x0000000e
> -#define MACREG_INT_CODE_WM_AWAKE                0x0000000f
> -#define MACREG_INT_CODE_ADHOC_BCN_LOST          0x00000011
> -#define MACREG_INT_CODE_RSSI_LOW		0x00000019
> -#define MACREG_INT_CODE_SNR_LOW			0x0000001a
> -#define MACREG_INT_CODE_MAX_FAIL		0x0000001b
> -#define MACREG_INT_CODE_RSSI_HIGH		0x0000001c
> -#define MACREG_INT_CODE_SNR_HIGH		0x0000001d
> -#define MACREG_INT_CODE_MESH_AUTO_STARTED	0x00000023
> +#define MACREG_INT_CODE_TX_PPA_FREE             0
> +#define MACREG_INT_CODE_TX_DMA_DONE             1
> +#define MACREG_INT_CODE_LINK_LOST_W_SCAN        2
> +#define MACREG_INT_CODE_LINK_LOST_NO_SCAN       3
> +#define MACREG_INT_CODE_LINK_SENSED             4
> +#define MACREG_INT_CODE_CMD_FINISHED            5
> +#define MACREG_INT_CODE_MIB_CHANGED             6
> +#define MACREG_INT_CODE_INIT_DONE               7
> +#define MACREG_INT_CODE_DEAUTHENTICATED         8
> +#define MACREG_INT_CODE_DISASSOCIATED           9
> +#define MACREG_INT_CODE_PS_AWAKE                10
> +#define MACREG_INT_CODE_PS_SLEEP                11
> +#define MACREG_INT_CODE_MIC_ERR_MULTICAST       13
> +#define MACREG_INT_CODE_MIC_ERR_UNICAST         14
> +#define MACREG_INT_CODE_WM_AWAKE                15
> +#define MACREG_INT_CODE_DEEP_SLEEP_AWAKE        16
> +#define MACREG_INT_CODE_ADHOC_BCN_LOST          17
> +#define MACREG_INT_CODE_HOST_AWAKE              18
> +#define MACREG_INT_CODE_STOP_TX                 19
> +#define MACREG_INT_CODE_START_TX                20
> +#define MACREG_INT_CODE_CHANNEL_SWITCH          21
> +#define MACREG_INT_CODE_MEASUREMENT_RDY         22
> +#define MACREG_INT_CODE_WMM_CHANGE              23
> +#define MACREG_INT_CODE_BG_SCAN_REPORT          24
> +#define MACREG_INT_CODE_RSSI_LOW                25
> +#define MACREG_INT_CODE_SNR_LOW                 26
> +#define MACREG_INT_CODE_MAX_FAIL                27
> +#define MACREG_INT_CODE_RSSI_HIGH               28
> +#define MACREG_INT_CODE_SNR_HIGH                29
> +#define MACREG_INT_CODE_MESH_AUTO_STARTED       35
>  
>  #endif

Re: [PATCH] less eventcause shifts

[David Woodhouse]

On Mon, 2007-12-03 at 12:58 -0500, Dan Williams wrote:
> I'm sort of sitting on these patches until you and Woodhouse start using
> the same git tree until he's done with the command rework...  It's going
> to be near impossible to handle both of your patches with any certainty.
> Any progress on whether you've both been able to work in the same repo?

http://git.infradead.org/?p=libertas-2.6.git

It's based on Linus' tree -- we've abandoned John's wireless-dev tree
altogether. He rebases it and uses branches -- it's just an exercise in
making git hard.

-- 
dwmw2

Re: [PATCH] less eventcause shifts

[Dan Williams]

On Mon, 2007-12-03 at 20:48 +0000, David Woodhouse wrote:
> On Mon, 2007-12-03 at 12:58 -0500, Dan Williams wrote:
> > I'm sort of sitting on these patches until you and Woodhouse start using
> > the same git tree until he's done with the command rework...  It's going
> > to be near impossible to handle both of your patches with any certainty.
> > Any progress on whether you've both been able to work in the same repo?
> 
> http://git.infradead.org/?p=libertas-2.6.git
> 
> It's based on Linus' tree -- we've abandoned John's wireless-dev tree
> altogether. He rebases it and uses branches -- it's just an exercise in
> making git hard.

Then you of course understand that you may have a bitch of a time
getting it back to John.  Because you can't just go to Linus, you need
to go through John when you want to upstream stuff.  That's how it
works.

However, since Libertas is fullmac-ish, the merge probably won't be
horrible.

Dan

Re: [PATCH] less eventcause shifts

[John W. Linville]

On Mon, Dec 03, 2007 at 08:48:59PM +0000, David Woodhouse wrote:
> 
> On Mon, 2007-12-03 at 12:58 -0500, Dan Williams wrote:
> > I'm sort of sitting on these patches until you and Woodhouse start using
> > the same git tree until he's done with the command rework...  It's going
> > to be near impossible to handle both of your patches with any certainty.
> > Any progress on whether you've both been able to work in the same repo?
> 
> http://git.infradead.org/?p=libertas-2.6.git
> 
> It's based on Linus' tree -- we've abandoned John's wireless-dev tree
> altogether. He rebases it and uses branches -- it's just an exercise in
> making git hard.

Re: branches -- I don't see why they bother you.  Mostly you can just
ignore them.

Without branches I would have to have at least two trees (one for
feeding Dave, the other for feeding Jeff) and maybe a third for
development/integration, and it would be more difficult to cherry-pick
commits between them.  How would that be any better?

Re: rebasing -- again it shouldn't matter to you when I rebase most
of the branches.  All the branches besides 'everything' are there
for my own organizational purposes.

I have been rebasing 'everything' when Linus releases an -rc.  If I
don't rebase then over time it becomes a mess.  It becomes difficult
to see what is "in" and what is "out", you get duplicate changelog
entries, you get merge conflicts where there shouldn't be any, etc.
I've been through that with the old wireless-dev tree (RIP) and I
would rather not repeat it.  That said, I _do_ try to avoid rebasing
'everything' when possible.  I don't think I've rebased within an
-rc period in quite some time.

As for "making git hard", git is what makes this easy.  If you are
doing development that relies on patches already merged [1], then
you might start development based on wireless-2.6 like this:

	git clone --reference linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
	git checkout -b work origin/everything
	git branch work-start

That way you have a record of where your patches start.  From there
you happily make you commits until you want to rebase your work on
the latest wireless-2.6 tree.  Then you start by saving a copy of
your work:

	git format-patch --stdout work-start..work > work.mbox

Then you need the updated wireless-2.6.  As you point-out, it may have
been rebased -- a straight pull won't always work.  So, just save your
tree, re-clone the current wireless-2.6, and make a new work branch:

	# rename your old tree
	mv wireless-2.6 wireless-2.6-old

	# This should look familiar!
	git clone --reference linux-2.6.git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
	git checkout -b work origin/everything
	git branch work-start

Then replay your work on top of it:

	git-am -s ../wireless-2.6-old/work.mbox

The result is a nice, rebased set of patches on top of the current
upstream work.	If you simply did a "commit, pull, commit, pull,
etc" cycle then you would end-up with a set of patches that might
no longer apply on top of a clean upstream branch -- been there,
wireless-dev RIP.

I really think this is the best methodology for processing patches
so that they are ready for merging when posted.

Hth!

John

[1] If your work does _not_ rely on patches already merged in my tree
then by all means just use Linus' tree.
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH] less eventcause shifts

[David Woodhouse]

On Tue, 2007-12-04 at 09:54 -0500, John W. Linville wrote:
> The result is a nice, rebased set of patches on top of the current
> upstream work.	If you simply did a "commit, pull, commit, pull,
> etc" cycle then you would end-up with a set of patches that might
> no longer apply on top of a clean upstream branch -- been there,
> wireless-dev RIP.

Ah, I understand your confusion. It reflects akpm's confusion when he
first started trying to use git-bisect.

This thing is, there is no actual need for a 'set of patches'. Git isn't
about patches. It's about commits and pulls. It doesn't _matter_ if you
had to fix up something when you merged from Linus, because when Linus
pulls from your tree, he pulls your manual merge effort too.

That's how git is designed. You're trying to use it as a kind of staging
post before you send a set of patches to Linus, which is why it looks
strange to me. That's the kind of thing that quilt does best, I think.

Perhaps you should investigate stgit, which {ab,}uses git for this kind
of thing and lets you deal with patches that way quite nicely too.

> I really think this is the best methodology for processing patches
> so that they are ready for merging when posted.

You're probably right.

On the other hand, I think the best methodology for processing code
changes to the Linux kernel so that they are ready for merging into
Linus' git tree is probably in a normal git tree :)

Yes, it's useful not to do daily pulls and end up with a ton of 'empty'
merge commits in the graph -- that gets message. For that reason, I tend
to pull from upstream only when there's something there which I depend
on, or when I'll have to do a manual merge. But a reasonable number of
merges is perfectly normal. That's what git was designed to do, after
all.

> [1] If your work does _not_ rely on patches already merged in my tree
> then by all means just use Linus' tree.

That was my intention, right up to the point at which a bunch of
libertas patches appeared in your tree :)

-- 
dwmw2

Re: [PATCH] less eventcause shifts

[Dan Williams]

On Tue, 2007-12-04 at 15:07 +0000, David Woodhouse wrote:
> On Tue, 2007-12-04 at 09:54 -0500, John W. Linville wrote:
> > The result is a nice, rebased set of patches on top of the current
> > upstream work.	If you simply did a "commit, pull, commit, pull,
> > etc" cycle then you would end-up with a set of patches that might
> > no longer apply on top of a clean upstream branch -- been there,
> > wireless-dev RIP.
> 
> Ah, I understand your confusion. It reflects akpm's confusion when he
> first started trying to use git-bisect.
> 
> This thing is, there is no actual need for a 'set of patches'. Git isn't
> about patches. It's about commits and pulls. It doesn't _matter_ if you
> had to fix up something when you merged from Linus, because when Linus
> pulls from your tree, he pulls your manual merge effort too.
> 
> That's how git is designed. You're trying to use it as a kind of staging
> post before you send a set of patches to Linus, which is why it looks
> strange to me. That's the kind of thing that quilt does best, I think.
> 
> Perhaps you should investigate stgit, which {ab,}uses git for this kind
> of thing and lets you deal with patches that way quite nicely too.
> 
> > I really think this is the best methodology for processing patches
> > so that they are ready for merging when posted.
> 
> You're probably right.
> 
> On the other hand, I think the best methodology for processing code
> changes to the Linux kernel so that they are ready for merging into
> Linus' git tree is probably in a normal git tree :)
> 
> Yes, it's useful not to do daily pulls and end up with a ton of 'empty'
> merge commits in the graph -- that gets message. For that reason, I tend
> to pull from upstream only when there's something there which I depend
> on, or when I'll have to do a manual merge. But a reasonable number of
> merges is perfectly normal. That's what git was designed to do, after
> all.
> 
> > [1] If your work does _not_ rely on patches already merged in my tree
> > then by all means just use Linus' tree.
> 
> That was my intention, right up to the point at which a bunch of
> libertas patches appeared in your tree :)

Those patches should get into 2.6.25; I don't want them held up if you
don't think you can get the command rework done by 2.6.25...  As long as
the stuff that's queued up in John's tree gets up to Linus for 2.6.25,
then you can develop however you want in libertas-2.6 based of Linus or
whatever.

Dan

Re: [PATCH] less eventcause shifts

[David Woodhouse]

On Tue, 2007-12-04 at 10:06 -0500, Dan Williams wrote:
> Those patches should get into 2.6.25; I don't want them held up if you
> don't think you can get the command rework done by 2.6.25...  As long as
> the stuff that's queued up in John's tree gets up to Linus for 2.6.25,
> then you can develop however you want in libertas-2.6 based of Linus or
> whatever.

I intend to have the command rework done by the end of the week. And if
there's anything in libertas-2.6 which isn't ready to go by the time the
merge window opens, I promise I'll cherry-pick the bits which _are_
ready to go, so that they're not held up.

-- 
dwmw2

Re: [PATCH] less eventcause shifts

[David Woodhouse]

On Tue, 2007-12-04 at 15:07 +0000, David Woodhouse wrote:
> Yes, it's useful not to do daily pulls and end up with a ton of
> 'empty' merge commits in the graph -- that gets message.

s/message/messy/

More tea required.

-- 
dwmw2

Re: [PATCH] less eventcause shifts

[John W. Linville]

On Tue, Dec 04, 2007 at 03:07:46PM +0000, David Woodhouse wrote:
> On Tue, 2007-12-04 at 09:54 -0500, John W. Linville wrote:
> > The result is a nice, rebased set of patches on top of the current
> > upstream work.	If you simply did a "commit, pull, commit, pull,
> > etc" cycle then you would end-up with a set of patches that might
> > no longer apply on top of a clean upstream branch -- been there,
> > wireless-dev RIP.
> 
> Ah, I understand your confusion. It reflects akpm's confusion when he
> first started trying to use git-bisect.
> 
> This thing is, there is no actual need for a 'set of patches'. Git isn't
> about patches. It's about commits and pulls. It doesn't _matter_ if you
> had to fix up something when you merged from Linus, because when Linus
> pulls from your tree, he pulls your manual merge effort too.

Well I'm a bit hemmed-in -- Linus pull's from Dave and Jeff, they
pull from me.  Both of them are a bit prone to rebasing as well.
Even if I just "let it ride" (i.e. didn't rebase), I would still be
prone to some of the merge difficulties I described when I pulled
duplicate patches back in from Linus later.

FWIW, I've seen Linus complain about dirty git history on several
occassions.  So even if he were pulling directly from me I imagine
that there would still be a need for some of this quilt-like use of
git to clean-up things from time to time.

Still, it is true that I might be able to maintain a more consistent
'everything' branch if I weren't "serving two masters"...alas.

> > [1] If your work does _not_ rely on patches already merged in my tree
> > then by all means just use Linus' tree.
> 
> That was my intention, right up to the point at which a bunch of
> libertas patches appeared in your tree :)

It was my understanding that you were working on top of these patches
anyway (i.e. not rewriting or replacing them).  Anyway they are all
destined for 2.6.25 so your "Linus + libertas patches" just still be
just as valid...?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH] less eventcause shifts

[David Woodhouse]

On Tue, 2007-12-04 at 10:21 -0500, John W. Linville wrote:
> On Tue, Dec 04, 2007 at 03:07:46PM +0000, David Woodhouse wrote:
> > On Tue, 2007-12-04 at 09:54 -0500, John W. Linville wrote:
> > > The result is a nice, rebased set of patches on top of the current
> > > upstream work.	If you simply did a "commit, pull, commit, pull,
> > > etc" cycle then you would end-up with a set of patches that might
> > > no longer apply on top of a clean upstream branch -- been there,
> > > wireless-dev RIP.
> > 
> > Ah, I understand your confusion. It reflects akpm's confusion when he
> > first started trying to use git-bisect.
> > 
> > This thing is, there is no actual need for a 'set of patches'. Git isn't
> > about patches. It's about commits and pulls. It doesn't _matter_ if you
> > had to fix up something when you merged from Linus, because when Linus
> > pulls from your tree, he pulls your manual merge effort too.
> 
> Well I'm a bit hemmed-in -- Linus pull's from Dave and Jeff, they
> pull from me.  Both of them are a bit prone to rebasing as well.
> Even if I just "let it ride" (i.e. didn't rebase), I would still be
> prone to some of the merge difficulties I described when I pulled
> duplicate patches back in from Linus later.
> 
> FWIW, I've seen Linus complain about dirty git history on several
> occassions.  So even if he were pulling directly from me I imagine
> that there would still be a need for some of this quilt-like use of
> git to clean-up things from time to time.

Very occasionally. Never, in my experience, when I'm careful about when
I actually merge. As I said, daily merges are probably a bad idea. :)

> Still, it is true that I might be able to maintain a more consistent
> 'everything' branch if I weren't "serving two masters"...alas.

Yeah, I don't really mean to tell you how to handle it -- I'm just
trying to find a way to work that actually allows me to use git
properly, rather than forcing me in to the old method of stacks of
patches.

Basically, trees which get rebased aren't suitable for git users to base
their work on. It just doesn't work.

> > > [1] If your work does _not_ rely on patches already merged in my tree
> > > then by all means just use Linus' tree.
> > 
> > That was my intention, right up to the point at which a bunch of
> > libertas patches appeared in your tree :)
> 
> It was my understanding that you were working on top of these patches
> anyway (i.e. not rewriting or replacing them).  Anyway they are all
> destined for 2.6.25 so your "Linus + libertas patches" just still be
> just as valid...?

The important question is: is the commit sha1sum the same?

And the answer is no -- the commit corresponding to a given patch may
have a different sha1sum from day to day, in your tree, and when it
finally gets to Linus. That's fair enough -- you deal with patches, not
git. But it sucks for anyone who wants to use git and to base their work
on stuff you have in those patches.

Which is why I thought we'd agreed that I'll commit libertas-related
stuff to libertas-2.6.git for now, where Holger and I can play to our
hearts' content, then ask you to pull when we're done.

I'm open to better suggestions, as long as they're not "you are not
allowed to use git, except as a primitive way of storing patches". :)

-- 
dwmw2

Re: [PATCH] less eventcause shifts

[Dan Williams]

On Tue, 2007-12-04 at 15:29 +0000, David Woodhouse wrote:
> On Tue, 2007-12-04 at 10:21 -0500, John W. Linville wrote:
> > On Tue, Dec 04, 2007 at 03:07:46PM +0000, David Woodhouse wrote:
> > > On Tue, 2007-12-04 at 09:54 -0500, John W. Linville wrote:
> > > > The result is a nice, rebased set of patches on top of the current
> > > > upstream work.	If you simply did a "commit, pull, commit, pull,
> > > > etc" cycle then you would end-up with a set of patches that might
> > > > no longer apply on top of a clean upstream branch -- been there,
> > > > wireless-dev RIP.
> > > 
> > > Ah, I understand your confusion. It reflects akpm's confusion when he
> > > first started trying to use git-bisect.
> > > 
> > > This thing is, there is no actual need for a 'set of patches'. Git isn't
> > > about patches. It's about commits and pulls. It doesn't _matter_ if you
> > > had to fix up something when you merged from Linus, because when Linus
> > > pulls from your tree, he pulls your manual merge effort too.
> > 
> > Well I'm a bit hemmed-in -- Linus pull's from Dave and Jeff, they
> > pull from me.  Both of them are a bit prone to rebasing as well.
> > Even if I just "let it ride" (i.e. didn't rebase), I would still be
> > prone to some of the merge difficulties I described when I pulled
> > duplicate patches back in from Linus later.
> > 
> > FWIW, I've seen Linus complain about dirty git history on several
> > occassions.  So even if he were pulling directly from me I imagine
> > that there would still be a need for some of this quilt-like use of
> > git to clean-up things from time to time.
> 
> Very occasionally. Never, in my experience, when I'm careful about when
> I actually merge. As I said, daily merges are probably a bad idea. :)
> 
> > Still, it is true that I might be able to maintain a more consistent
> > 'everything' branch if I weren't "serving two masters"...alas.
> 
> Yeah, I don't really mean to tell you how to handle it -- I'm just
> trying to find a way to work that actually allows me to use git
> properly, rather than forcing me in to the old method of stacks of
> patches.
> 
> Basically, trees which get rebased aren't suitable for git users to base
> their work on. It just doesn't work.
> 
> > > > [1] If your work does _not_ rely on patches already merged in my tree
> > > > then by all means just use Linus' tree.
> > > 
> > > That was my intention, right up to the point at which a bunch of
> > > libertas patches appeared in your tree :)
> > 
> > It was my understanding that you were working on top of these patches
> > anyway (i.e. not rewriting or replacing them).  Anyway they are all
> > destined for 2.6.25 so your "Linus + libertas patches" just still be
> > just as valid...?
> 
> The important question is: is the commit sha1sum the same?
> 
> And the answer is no -- the commit corresponding to a given patch may
> have a different sha1sum from day to day, in your tree, and when it
> finally gets to Linus. That's fair enough -- you deal with patches, not
> git. But it sucks for anyone who wants to use git and to base their work
> on stuff you have in those patches.
> 
> Which is why I thought we'd agreed that I'll commit libertas-related
> stuff to libertas-2.6.git for now, where Holger and I can play to our
> hearts' content, then ask you to pull when we're done.

However it works out, as long as the work in libertas-2.6 doesn't drag
out too long.  Slow and steady does not win the race here :)  Not sure
what's involved if Jeff has already pulled from John; but if not, John
could drop the current libertas set and you (david) can _ensure_ that
they get into libertas-2.6 so nothing gets dropped on the floor.

Dan

Re: [PATCH] less eventcause shifts

[John W. Linville]

On Tue, Dec 04, 2007 at 11:00:02AM -0500, Dan Williams wrote:

> However it works out, as long as the work in libertas-2.6 doesn't drag
> out too long.  Slow and steady does not win the race here :)  Not sure
> what's involved if Jeff has already pulled from John; but if not, John
> could drop the current libertas set and you (david) can _ensure_ that
> they get into libertas-2.6 so nothing gets dropped on the floor.

If the new patches come fast enough to guarantee that then I have to
believe that we can work-out how to merge the new patches on top of
what I've already sent.  So, I would prefer to let the pull request
I sent today stand.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH] less eventcause shifts

[Dan Williams]

On Tue, 2007-12-04 at 11:14 -0500, John W. Linville wrote:
> On Tue, Dec 04, 2007 at 11:00:02AM -0500, Dan Williams wrote:
> 
> > However it works out, as long as the work in libertas-2.6 doesn't drag
> > out too long.  Slow and steady does not win the race here :)  Not sure
> > what's involved if Jeff has already pulled from John; but if not, John
> > could drop the current libertas set and you (david) can _ensure_ that
> > they get into libertas-2.6 so nothing gets dropped on the floor.
> 
> If the new patches come fast enough to guarantee that then I have to
> believe that we can work-out how to merge the new patches on top of
> what I've already sent.  So, I would prefer to let the pull request
> I sent today stand.

That would be my preference too; since it's already all said and done...

Dan

Re: [PATCH] less eventcause shifts

[John W. Linville]

On Tue, Dec 04, 2007 at 03:29:30PM +0000, David Woodhouse wrote:

> Basically, trees which get rebased aren't suitable for git users to base
> their work on. It just doesn't work.

Well I think that is an overstatement, but you are entitled to it... :-)

I don't know what else I can offer.  There may be some ways to
rebase 'everything' less often, but I don't think I can eliminate it
completely without having a big mess.

> Which is why I thought we'd agreed that I'll commit libertas-related
> stuff to libertas-2.6.git for now, where Holger and I can play to our
> hearts' content, then ask you to pull when we're done.

I just don't see where I have upset that apple cart.  Polish-up your
tree and I'll pull it.  I (or maybe we) will work it out from there.

Again, I don't have any more libertas patches in queue.  So don't
send any more until you are ready to merge and I don't think there
will be a serious problem.

> I'm open to better suggestions, as long as they're not "you are not
> allowed to use git, except as a primitive way of storing patches". :)

Keeping a clean patch stack at the top is the only way I know to
come close to guaranteeing you have mergeable patches.  Beyond that,
I'll work with you the best that I can.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH] fewer eventcause shifts

[David Woodhouse]

(the subject line was annoying me; I fixed it)

On Tue, 2007-12-04 at 11:12 -0500, John W. Linville wrote:
> On Tue, Dec 04, 2007 at 03:29:30PM +0000, David Woodhouse wrote:
> 
> > Basically, trees which get rebased aren't suitable for git users to base
> > their work on. It just doesn't work.
> 
> Well I think that is an overstatement, but you are entitled to it... :-)

Well, I am making the distinction between 'git as git' and 'git as quilt
storage'. If you interpret 'git users' to mean those who want the
former, it really isn't much of an overstatement at all.

> Again, I don't have any more libertas patches in queue.  So don't
> send any more until you are ready to merge and I don't think there
> will be a serious problem.

OK. 

> > I'm open to better suggestions, as long as they're not "you are not
> > allowed to use git, except as a primitive way of storing patches". :)
> 
> Keeping a clean patch stack at the top is the only way I know to
> come close to guaranteeing you have mergeable patches.  Beyond that,
> I'll work with you the best that I can.

Again you're talking of 'patches'. But if we're using "git as git", then
it isn't about guaranteeing you have mergeable _patches_. It's about
guaranteeing you have a mergeable _tree_.

On Tue, 2007-12-04 at 11:14 -0500, John W. Linville wrote:
> If the new patches come fast enough to guarantee that then I have to
> believe that we can work-out how to merge the new patches on top of
> what I've already sent.  So, I would prefer to let the pull request
> I sent today stand.

OK, that's fine, I think. Because if you've actually sent the pull
request, then I can use those _commits_ and those will be the ones which
turn up upstream. Those patches won't get recommitted, cherry-picked,
rebased or otherwise mangled so that they're no longer the same commits
that I'm basing my tree on.

Which branch of yours contains the commits (not patches) which are
actually going upstream? I'll throw away my tree and rebase it on that.

-- 
dwmw2

Re: [PATCH] fewer eventcause shifts

[John W. Linville]

On Tue, Dec 04, 2007 at 04:27:35PM +0000, David Woodhouse wrote:
> On Tue, 2007-12-04 at 11:12 -0500, John W. Linville wrote:

> > Keeping a clean patch stack at the top is the only way I know to
> > come close to guaranteeing you have mergeable patches.  Beyond that,
> > I'll work with you the best that I can.
> 
> Again you're talking of 'patches'. But if we're using "git as git", then
> it isn't about guaranteeing you have mergeable _patches_. It's about
> guaranteeing you have a mergeable _tree_.

This might be true if there were a guarantee that no one would rebase
from you to me to Jeff/Dave to Linus.  Experience tells me that I can't
guarantee the "Jeff/Dave" part of that chain.  Given that, experience
also tells me that when your patches pop-up in their rebase operation
that they will look like your original commit and not have any fixups
included as part of any 'git merge' along the way.  So by not rebasing
your patches (or insisting that you do so) before sending them along,
I'm making life harder for Jeff/Dave.  Since they handle even more
patches than I do, that seems to fall under the "not cool" category.

> On Tue, 2007-12-04 at 11:14 -0500, John W. Linville wrote:
> > If the new patches come fast enough to guarantee that then I have to
> > believe that we can work-out how to merge the new patches on top of
> > what I've already sent.  So, I would prefer to let the pull request
> > I sent today stand.
> 
> OK, that's fine, I think. Because if you've actually sent the pull
> request, then I can use those _commits_ and those will be the ones which
> turn up upstream. Those patches won't get recommitted, cherry-picked,
> rebased or otherwise mangled so that they're no longer the same commits
> that I'm basing my tree on.

You might presume so, and you might even be right this time around.
But, I think you presume too much in this case.

> Which branch of yours contains the commits (not patches) which are
> actually going upstream? I'll throw away my tree and rebase it on that.

I have asked Jeff to pull the 'upstream-jgarzik' branch, which contains
the libertas patches.

John
-- 
John W. Linville
linville@tuxdriver.com