[PATCH 1/2] p54spi: mask value read from SPI_ADRS_DMA_WRITE_CTRL in p54spi_wait_bit

[PATCH 1/2] p54spi: mask value read from SPI_ADRS_DMA_WRITE_CTRL in p54spi_wait_bit

[Max Filippov]

 Mask value read from SPI_ADRS_DMA_WRITE_CTRL in p54spi_wait_bit.
 Without this, 'fw_upload not allowed to DMA write' is observed at both N800 and N810.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
 drivers/net/wireless/p54/p54spi.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 2b222aa..d13268f 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -171,7 +171,7 @@ static int p54spi_wait_bit(struct p54s_priv *priv, u16 reg, __le32 bits)
 
 	for (i = 0; i < 2000; i++) {
 		p54spi_spi_read(priv, reg, &buffer, sizeof(buffer));
-		if (buffer == bits)
+		if ((buffer & bits) == bits)
 			return 1;
 
 		msleep(1);
-- 
1.5.4.3

[PATCH 2/2] p54spi: fix p54_upload_firmware

[Max Filippov]

 Instead of firmware itself p54_upload_firmware was sending to the device content of struct firmware
 and the following random garbage. Notice '&' before priv->firmware->data at p54spi_spi_write.
 But simple removing of '&' sign triggered BUG_ON at dma_cache_maint. Thus kmemdup - kfree workaround.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
 drivers/net/wireless/p54/p54spi.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index d13268f..4ef57c5 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -265,8 +265,15 @@ static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 		p54spi_write32(priv, SPI_ADRS_DMA_WRITE_BASE,
 			       cpu_to_le32(fw_addr));
 
-		p54spi_spi_write(priv, SPI_ADRS_DMA_DATA,
-				 &priv->firmware->data, _fw_len);
+		{
+			void *fw = kmemdup(priv->firmware->data, _fw_len, GFP_KERNEL);
+			if (fw)
+			{
+				p54spi_spi_write(priv, SPI_ADRS_DMA_DATA,
+						 fw, _fw_len);
+				kfree(fw);
+			}
+		}
 
 		fw_len -= _fw_len;
 		fw_addr += _fw_len;
-- 
1.5.4.3

Re: [PATCH 2/2] p54spi: fix p54_upload_firmware

[Christian Lamparter]

On Wednesday 25 March 2009 06:30:16 Max Filippov wrote:
>  Instead of firmware itself p54_upload_firmware was sending to the device content of struct firmware
>  and the following random garbage. Notice '&' before priv->firmware->data at p54spi_spi_write.
>  But simple removing of '&' sign triggered BUG_ON at dma_cache_maint. Thus kmemdup - kfree workaround.
> 
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
>  drivers/net/wireless/p54/p54spi.c |   11 +++++++++--
>  1 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
> index d13268f..4ef57c5 100644
> --- a/drivers/net/wireless/p54/p54spi.c
> +++ b/drivers/net/wireless/p54/p54spi.c
> @@ -265,8 +265,15 @@ static int p54spi_upload_firmware(struct ieee80211_hw *dev)
>  		p54spi_write32(priv, SPI_ADRS_DMA_WRITE_BASE,
>  			       cpu_to_le32(fw_addr));
>  
> -		p54spi_spi_write(priv, SPI_ADRS_DMA_DATA,
> -				 &priv->firmware->data, _fw_len);
> +		{
> +			void *fw = kmemdup(priv->firmware->data, _fw_len, GFP_KERNEL);
> +			if (fw)
> +			{
> +				p54spi_spi_write(priv, SPI_ADRS_DMA_DATA,
> +						 fw, _fw_len);
> +				kfree(fw);
> +			}
> +		}
>  
>  		fw_len -= _fw_len;
>  		fw_addr += _fw_len;
---
checkpatch.pl complains

WARNING: line over 80 characters
#94: FILE: drivers/net/wireless/p54/p54spi.c:269:
+                       void *fw = kmemdup(priv->firmware->data, _fw_len, GFP_KERNEL);

ERROR: that open brace { should be on the previous line
#95: FILE: drivers/net/wireless/p54/p54spi.c:270:
+                       if (fw)
+                       {

what do you think about the attached proposal?

Regards,
	Chr
---
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index d13268f..7d32a2f 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -228,8 +228,15 @@ static int p54spi_request_eeprom(struct ieee80211_hw *dev)
 static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 {
 	struct p54s_priv *priv = dev->priv;
-	unsigned long fw_len, fw_addr;
-	long _fw_len;
+	unsigned long fw_len, _fw_len;
+	unsigned int offset = 0;
+	int err = 0;
+	void *fw;
+
+	fw_len = priv->firmware->size;
+	fw = kmemdup(priv->firmware->data, fw_len, GFP_KERNEL);
+	if (!fw)
+		return -ENOMEM;
 
 	/* stop the device */
 	p54spi_write16(priv, SPI_ADRS_DEV_CTRL_STAT, cpu_to_le16(
@@ -244,9 +251,6 @@ static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 
 	msleep(TARGET_BOOT_SLEEP);
 
-	fw_addr = ISL38XX_DEV_FIRMWARE_ADDR;
-	fw_len = priv->firmware->size;
-
 	while (fw_len > 0) {
 		_fw_len = min_t(long, fw_len, SPI_MAX_PACKET_SIZE);
 
@@ -257,23 +261,20 @@ static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 				    cpu_to_le32(HOST_ALLOWED)) == 0) {
 			dev_err(&priv->spi->dev, "fw_upload not allowed "
 				"to DMA write.");
-			return -EAGAIN;
+			err = -EAGAIN;
+			goto out;
 		}
 
 		p54spi_write16(priv, SPI_ADRS_DMA_WRITE_LEN,
 			       cpu_to_le16(_fw_len));
-		p54spi_write32(priv, SPI_ADRS_DMA_WRITE_BASE,
-			       cpu_to_le32(fw_addr));
+		p54spi_write32(priv, SPI_ADRS_DMA_WRITE_BASE, cpu_to_le32(
+				ISL38XX_DEV_FIRMWARE_ADDR + offset));
 
 		p54spi_spi_write(priv, SPI_ADRS_DMA_DATA,
-				 &priv->firmware->data, _fw_len);
+				 (fw + offset), _fw_len);
 
 		fw_len -= _fw_len;
-		fw_addr += _fw_len;
-
-		/* FIXME: I think this doesn't work if firmware is large,
-		 * this loop goes to second round. fw->data is not
-		 * increased at all! */
+		offset += _fw_len;
 	}
 
 	BUG_ON(fw_len != 0);
@@ -292,7 +293,10 @@ static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 	p54spi_write16(priv, SPI_ADRS_DEV_CTRL_STAT, cpu_to_le16(
 		       SPI_CTRL_STAT_HOST_OVERRIDE | SPI_CTRL_STAT_RAM_BOOT));
 	msleep(TARGET_BOOT_SLEEP);
-	return 0;
+
+out:
+	kfree(fw);
+	return err;
 }
 
 static void p54spi_power_off(struct p54s_priv *priv)

Re: [PATCH 2/2] p54spi: fix p54_upload_firmware

[Max Filippov]

> checkpatch.pl complains
>
> WARNING: line over 80 characters
> #94: FILE: drivers/net/wireless/p54/p54spi.c:269:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 void *fw =3D kmemdup(pr=
iv->firmware->data, _fw_len, GFP_KERNEL);
>
> ERROR: that open brace { should be on the previous line
> #95: FILE: drivers/net/wireless/p54/p54spi.c:270:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (fw)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
>
Sorry, I haven't been used to checkpatch.

> what do you think about the attached proposal?

It looks generally better. But (fw + offset) wouldn't compile, because
fw is void*.

--=20
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware

[Christian Lamparter]

From: Max Filippov <jcmvbkbc@gmail.com>

Instead of firmware itself p54_upload_firmware was sending to the device
content of struct firmware and the following random garbage.

Notice '&' before priv->firmware->data at p54spi_spi_write.
But simple removing of '&' sign triggered BUG_ON at dma_cache_maint.
Thus kmemdup - kfree workaround.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
On Wednesday 25 March 2009 13:00:33 Max Filippov wrote:
> Sorry, I haven't been used to checkpatch.
But your PATCH 1/2 sailed through without any complains. ;-)
 
> > what do you think about the attached proposal?
> 
> It looks generally better. But (fw + offset) wouldn't compile, because
> fw is void*.
??? but it does compile?!
  CHECK   drivers/net/wireless/p54/p54spi.c
  CC [M]  drivers/net/wireless/p54/p54spi.o
 Building modules, stage 2.
  MODPOST 4 modules
  CC      drivers/net/wireless/p54/p54spi.mod.o
  LD [M]  drivers/net/wireless/p54/p54spi.ko

But yes, I agree we better change void *fw to u8 *fw.

BTW: does p54spi really work now?
---
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index d13268f..93c761e 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -228,8 +228,15 @@ static int p54spi_request_eeprom(struct ieee80211_hw *dev)
 static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 {
 	struct p54s_priv *priv = dev->priv;
-	unsigned long fw_len, fw_addr;
-	long _fw_len;
+	unsigned long fw_len, _fw_len;
+	unsigned int offset = 0;
+	int err = 0;
+	u8 *fw;
+
+	fw_len = priv->firmware->size;
+	fw = kmemdup(priv->firmware->data, fw_len, GFP_KERNEL);
+	if (!fw)
+		return -ENOMEM;
 
 	/* stop the device */
 	p54spi_write16(priv, SPI_ADRS_DEV_CTRL_STAT, cpu_to_le16(
@@ -244,9 +251,6 @@ static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 
 	msleep(TARGET_BOOT_SLEEP);
 
-	fw_addr = ISL38XX_DEV_FIRMWARE_ADDR;
-	fw_len = priv->firmware->size;
-
 	while (fw_len > 0) {
 		_fw_len = min_t(long, fw_len, SPI_MAX_PACKET_SIZE);
 
@@ -257,23 +261,20 @@ static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 				    cpu_to_le32(HOST_ALLOWED)) == 0) {
 			dev_err(&priv->spi->dev, "fw_upload not allowed "
 				"to DMA write.");
-			return -EAGAIN;
+			err = -EAGAIN;
+			goto out;
 		}
 
 		p54spi_write16(priv, SPI_ADRS_DMA_WRITE_LEN,
 			       cpu_to_le16(_fw_len));
-		p54spi_write32(priv, SPI_ADRS_DMA_WRITE_BASE,
-			       cpu_to_le32(fw_addr));
+		p54spi_write32(priv, SPI_ADRS_DMA_WRITE_BASE, cpu_to_le32(
+				ISL38XX_DEV_FIRMWARE_ADDR + offset));
 
 		p54spi_spi_write(priv, SPI_ADRS_DMA_DATA,
-				 &priv->firmware->data, _fw_len);
+				 (fw + offset), _fw_len);
 
 		fw_len -= _fw_len;
-		fw_addr += _fw_len;
-
-		/* FIXME: I think this doesn't work if firmware is large,
-		 * this loop goes to second round. fw->data is not
-		 * increased at all! */
+		offset += _fw_len;
 	}
 
 	BUG_ON(fw_len != 0);
@@ -292,7 +293,10 @@ static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 	p54spi_write16(priv, SPI_ADRS_DEV_CTRL_STAT, cpu_to_le16(
 		       SPI_CTRL_STAT_HOST_OVERRIDE | SPI_CTRL_STAT_RAM_BOOT));
 	msleep(TARGET_BOOT_SLEEP);
-	return 0;
+
+out:
+	kfree(fw);
+	return err;
 }
 
 static void p54spi_power_off(struct p54s_priv *priv)

Re: [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware

[Max Filippov]

>> Sorry, I haven't been used to checkpatch.
> But your PATCH 1/2 sailed through without any complains. ;-)
Mere coincidence (:

> BTW: does p54spi really work now?
I haven't tested your patch yet, but with the one that I sent it does
work in IBSS mode.
My aim is to wind it up in mesh mode. This doesn't work, it cannot
establish peer link.
I'm going to investigate it. Does mesh mode work on conventional pci/usb p54?

--
Max

Re: [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On Wed, 2009-03-25 at 15:50 +0300, Max Filippov wrote:

> > BTW: does p54spi really work now?
> I haven't tested your patch yet, but with the one that I sent it does
> work in IBSS mode.

Nice.

> My aim is to wind it up in mesh mode. This doesn't work, it cannot
> establish peer link.
> I'm going to investigate it. Does mesh mode work on conventional pci/usb p54?

There may or may not be beaconing problems -- try scanning at least on
the mesh interface.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware

[Max Filippov]

> > > BTW: does p54spi really work now?
> >
> > I haven't tested your patch yet, but with the one that I sent it does
> > work in IBSS mode.
>
> Nice.
Not that nice, actually. It works till first beacon resubmission. After beacon resubmission beaconing continues,
but timestamp in outgoing frames constantly gets reset:

<7>[  280.959311] RX beacon SA=00:1d:6e:9b:ee:6d BSSID=7e:2e:03:09:31:25 TSF=0x23ac519 BCN=0x1c521e2 diff=7709495 @4294959513
<7>[  281.061780] RX beacon SA=00:1d:6e:9b:ee:6d BSSID=7e:2e:03:09:31:25 TSF=0x23c552d BCN=0x1c6b1f6 diff=7709495 @4294959526
<7>[  283.992749] phy0: Removed STA 00:1d:6e:9b:ee:6d
<7>[  284.008374] phy0: Destroyed STA 00:1d:6e:9b:ee:6d
<7>[  284.008435] wlan0: deauthenticating by local choice (reason=3)
<7>[  288.948834] RX beacon SA=00:1d:6e:9b:ee:6d BSSID=7e:2e:03:09:31:25 TSF=0x1c3e1 BCN=0x23f034a diff=-37568361 @4294960536
<7>[  288.948895] wlan0: beacon TSF higher than local TSF - IBSS merge with BSSID 7e:2e:03:09:31:25
<7>[  288.949139] phy0: Adding new IBSS station 00:1d:6e:9b:ee:6d (dev=wlan0)
<7>[  288.949230] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<7>[  288.949322] phy0: Inserted STA 00:1d:6e:9b:ee:6d
<7>[  289.050906] wlan0: updated supp_rates set for 00:1d:6e:9b:ee:6d based on beacon info (0x1 | 0xfff -> 0xfff)
<7>[  289.050997] RX beacon SA=00:1d:6e:9b:ee:6d BSSID=7e:2e:03:09:31:25 TSF=0x3528d BCN=0x24091f6 diff=-37568361 @4294960549
<7>[  289.051058] wlan0: beacon TSF higher than local TSF - IBSS merge with BSSID 7e:2e:03:09:31:25
<7>[  289.051150] phy0: Removed STA 00:1d:6e:9b:ee:6d
<7>[  289.063052] phy0: Destroyed STA 00:1d:6e:9b:ee:6d
<7>[  289.071679] phy0: Adding new IBSS station 00:1d:6e:9b:ee:6d (dev=wlan0)
<7>[  289.071770] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<7>[  289.074486] phy0: Inserted STA 00:1d:6e:9b:ee:6d
<7>[  289.153774] RX beacon SA=00:1d:6e:9b:ee:6d BSSID=7e:2e:03:09:31:25 TSF=0x4e459 BCN=0x24223c2 diff=-37568361 @4294960562
<7>[  289.153835] wlan0: beacon TSF higher than local TSF - IBSS merge with BSSID 7e:2e:03:09:31:25
<7>[  289.153896] phy0: Removed STA 00:1d:6e:9b:ee:6d
<7>[  289.154140] phy0: Adding new IBSS station 00:1d:6e:9b:ee:6d (dev=wlan0)
<7>[  289.154232] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<7>[  289.157107] phy0: Inserted STA 00:1d:6e:9b:ee:6d
<7>[  289.172445] phy0: Destroyed STA 00:1d:6e:9b:ee:6d

Here's what's on the air (tshark -T fields -e wlan.sa -e wlan.seq -e wlan_mgt.fixed.timestamp):

00:1d:6e:9b:ee:6d       179     0x00000000023BE296
00:1d:6e:9b:ee:6d       180     0x00000000023D720A
00:1d:6e:9b:ee:6d       181     0x00000000023F034A
00:1d:6e:9b:ee:6d       182     0x00000000024091F6
00:1d:6e:9b:ee:6c       0       0x00000000000002D5
00:1d:6e:9b:ee:6c       1       0x00000000000003FB
00:1d:6e:9b:ee:6d       183     0x00000000024223C2
00:1d:6e:9b:ee:6c       2       0x0000000000000332
00:1d:6e:9b:ee:6d       184     0x000000000243B296
00:1d:6e:9b:ee:6c       3       0x000000000000054D
00:1d:6e:9b:ee:6c       4       0x0000000000000798

It gets back in sync only after beacon resubmission stops:

<7>[  353.579189] RX beacon SA=00:1d:6e:9b:ee:6d BSSID=7e:2e:03:09:31:25 TSF=0x4aaa81 BCN=0x618f1f6 diff=-97404789 @1513
<7>[  353.579250] wlan0: beacon TSF higher than local TSF - IBSS merge with BSSID 7e:2e:03:09:31:25
<7>[  353.579311] phy0: Removed STA 00:1d:6e:9b:ee:6d
<7>[  353.579555] phy0: Adding new IBSS station 00:1d:6e:9b:ee:6d (dev=wlan0)
<7>[  353.579616] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<7>[  353.582332] phy0: Inserted STA 00:1d:6e:9b:ee:6d
<7>[  353.594254] phy0: Destroyed STA 00:1d:6e:9b:ee:6d
<7>[  353.682026] RX beacon SA=00:1d:6e:9b:ee:6d BSSID=7e:2e:03:09:31:25 TSF=0x4c3c89 BCN=0x61a83fe diff=-97404789 @1526
<7>[  353.682087] wlan0: beacon TSF higher than local TSF - IBSS merge with BSSID 7e:2e:03:09:31:25
<7>[  353.682148] phy0: Removed STA 00:1d:6e:9b:ee:6d
<7>[  353.682392] phy0: Adding new IBSS station 00:1d:6e:9b:ee:6d (dev=wlan0)
<7>[  353.682453] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<7>[  353.685169] phy0: Inserted STA 00:1d:6e:9b:ee:6d
<7>[  353.695728] phy0: Destroyed STA 00:1d:6e:9b:ee:6d

At this point my n810 freezes. Here's what's on the air at the same time:

00:1d:6e:9b:ee:6d       809     0x0000000006176282
00:1d:6e:9b:ee:6c       59      0x000000000000051F
00:1d:6e:9b:ee:6c       60      0x00000000000006F7
00:1d:6e:9b:ee:6d       810     0x000000000618F1F6
00:1d:6e:9b:ee:6c       61      0x000000000000041D
00:1d:6e:9b:ee:6c       62      0x000000000000037B
00:1d:6e:9b:ee:6d       811     0x00000000061A83FE
00:1d:6e:9b:ee:6c       63      0x0000000000000585
00:1d:6e:9b:ee:6c       64      0x00000000000006BF
00:1d:6e:9b:ee:6d       812     0x00000000061C1372
00:1d:6e:9b:ee:6c       65      0x00000000061DA1E3
00:1d:6e:9b:ee:6d       813     0x00000000061F321E
00:1d:6e:9b:ee:6c       66      0x000000000620C2E6
00:1d:6e:9b:ee:6c       67      0x00000000062252BE
00:1d:6e:9b:ee:6c       68      0x000000000623E2E6
00:1d:6e:9b:ee:6d       814     0x000000000625739A

I can conduct additional tests or provide additional logs/pcaps.
Any suggestions?

-- 
Thanks.
-- Max

Re: [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware

[Christian Lamparter]

On Wednesday 25 March 2009 13:50:44 Max Filippov wrote:
> >> Sorry, I haven't been used to checkpatch.
> > But your PATCH 1/2 sailed through without any complains. ;-)
> Mere coincidence (:
> 
> > BTW: does p54spi really work now?
> I haven't tested your patch yet, but with the one that I sent it does
> work in IBSS mode.
> My aim is to wind it up in mesh mode. This doesn't work, it cannot
> establish peer link.
> I'm going to investigate it. Does mesh mode work on conventional pci/usb p54?

hmm, yes... at least with wireless-testing from yesterday. (beaconing works too)

[ 9862.704138] mesh: running mesh housekeeping
[ 9906.580204] phy3: Allocated STA 00:14:a5:45:33:ff
[ 9906.581566] phy3: Inserted STA 00:14:a5:45:33:ff
[ 9906.581581] Mesh plink: starting establishment with 00:14:a5:45:33:ff
[ 9906.634055] Mesh plink (peer, state, llid, plid, event): 00:14:a5:45:33:ff 1 28312 0 1
[ 9906.636888] Mesh plink (peer, state, llid, plid, event): 00:14:a5:45:33:ff 2 28312 55519 4
[ 9906.636895] Mesh plink with 00:14:a5:45:33:ff ESTABLISHED

64 bytes from 10.0.0.2: icmp_seq=449 ttl=64 time=1.81 ms
64 bytes from 10.0.0.2: icmp_seq=450 ttl=64 time=1.41 ms
64 bytes from 10.0.0.2: icmp_seq=451 ttl=64 time=3.52 ms
...

both peers have a p54 (one is pci, the other one usb)... I'll see if I can
get my old ath5k back to verify that it works with other devices as well.

Regards,
	Chr

Re: [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware

[Christian Lamparter]

On Wednesday 25 March 2009 14:42:58 Christian Lamparter wrote:
> On Wednesday 25 March 2009 13:50:44 Max Filippov wrote:
> > >> Sorry, I haven't been used to checkpatch.
> > > But your PATCH 1/2 sailed through without any complains. ;-)
> > Mere coincidence (:
> > 
> > > BTW: does p54spi really work now?
> > I haven't tested your patch yet, but with the one that I sent it does
> > work in IBSS mode.
> > My aim is to wind it up in mesh mode. This doesn't work, it cannot
> > establish peer link.
> > I'm going to investigate it. Does mesh mode work on conventional pci/usb p54?
> 
> hmm, yes... at least with wireless-testing from yesterday. (beaconing works too)
> 
> [ 9862.704138] mesh: running mesh housekeeping
> [ 9906.580204] phy3: Allocated STA 00:14:a5:45:33:ff
> [ 9906.581566] phy3: Inserted STA 00:14:a5:45:33:ff
> [ 9906.581581] Mesh plink: starting establishment with 00:14:a5:45:33:ff
> [ 9906.634055] Mesh plink (peer, state, llid, plid, event): 00:14:a5:45:33:ff 1 28312 0 1
> [ 9906.636888] Mesh plink (peer, state, llid, plid, event): 00:14:a5:45:33:ff 2 28312 55519 4
> [ 9906.636895] Mesh plink with 00:14:a5:45:33:ff ESTABLISHED
> 
> 64 bytes from 10.0.0.2: icmp_seq=449 ttl=64 time=1.81 ms
> 64 bytes from 10.0.0.2: icmp_seq=450 ttl=64 time=1.41 ms
> 64 bytes from 10.0.0.2: icmp_seq=451 ttl=64 time=3.52 ms
> ...
> 
> both peers have a p54 (one is pci, the other one usb)... I'll see if I can
> get my old ath5k back to verify that it works with other devices as well.

FYI, I just finished testing with a 5 node mesh network with various drivers
(ath5k, ar9170usb and p54 mesh network) and it looks like everything works
the way it should... ( testing was done with the current wireless-testing.git )

Is there anything else I can do, or something you want to know?

Regards,
	Chr

p54spi - mesh mode summary

[Max Filippov]

> FYI, I just finished testing with a 5 node mesh network with various
> drivers (ath5k, ar9170usb and p54 mesh network) and it looks like
> everything works the way it should... ( testing was done with the current
> wireless-testing.git )
Good news.

And here's what's happening in p54spi environment:
1) yesterday's logs, with plink establishment failure:

<7>[ 1438.922118] p54spi_probe
<6>[ 1438.922271] cx3110x spi2.0: firmware: requesting 3826.arm
<6>[ 1439.032744] phy0: p54 detected a LM20 firmware
<6>[ 1439.038267] p54: rx_mtu reduced from 3240 to 2376
<6>[ 1439.043883] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
<6>[ 1439.049864] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
<6>[ 1439.055754] cx3110x spi2.0: firmware: requesting 3826.eeprom
<6>[ 1439.159376] cx3110x spi2.0: loading default eeprom...
<6>[ 1439.165723] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
<7>[ 1439.222347] phy0: Selected rate control algorithm 'minstrel'
<6>[ 1439.272353] cx3110x spi2.0: device is bound to phy0
<4>[ 1439.618513] Empty flash at 0x01ef1588 ends at 0x01ef1800
<4>[ 1439.768935] Empty flash at 0x02eb9474 ends at 0x02eb9800
<7>[ 1444.630185] usb0: eth_open
<7>[ 1444.630215] usb0: eth_start
<7>[ 1444.630368] g_ether gadget: ecm_open
<7>[ 1466.055751] m0: running mesh housekeeping
<7>[ 1515.025311] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<4>[ 1515.028027] ------------[ cut here ]------------
<4>[ 1515.035626] WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
<4>[ 1515.043316] Modules linked in: p54spi
<4>[ 1515.050976] [<c0034ff8>] (dump_stack+0x0/0x14) from [<c005b1f0>] (warn_on_slowpath+0x4c/0x68)
<4>[ 1515.059308] [<c005b1a4>] (warn_on_slowpath+0x0/0x68) from [<c006051c>] (local_bh_enable+0x54/0xbc)
<4>[ 1515.075696]  r6:c7adae00 r5:c70100a0 r4:c04594a0
<4>[ 1515.084118] [<c00604c8>] (local_bh_enable+0x0/0xbc) from [<bf000038>] (p54spi_op_tx+0x38/0x4c [p54spi])
<4>[ 1515.101422]  r4:c7adae00
<4>[ 1515.109814] [<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi]) from [<c01a4dbc>] (p54_sta_unlock+0x64/0x78)
<4>[ 1515.127698]  r5:c7ada1a0 r4:c70100a0
<4>[ 1515.136548] [<c01a4d58>] (p54_sta_unlock+0x0/0x78) from [<c01a4df8>] (p54_sta_notify+0x28/0x2c)
<4>[ 1515.146008]  r7:c7f33b80 r6:c7ada1a0 r5:60000013 r4:c7dbf400
<4>[ 1515.155621] [<c01a4dd0>] (p54_sta_notify+0x0/0x2c) from [<c02e0a40>] (sta_info_insert+0x128/0x19c)
<4>[ 1515.175122] [<c02e0918>] (sta_info_insert+0x0/0x19c) from [<c02fdb44>] (mesh_neighbour_update+0x58/0xbc)
<4>[ 1515.196240]  r8:c7f33b80 r7:00000000 r6:00000fff r5:c7ada1a0 r4:c7dbf400
<4>[ 1515.207165] [<c02fdaec>] (mesh_neighbour_update+0x0/0xbc) from [<c02fc398>] (ieee80211_mesh_work+0x188/0x2c4)
<4>[ 1515.229382] [<c02fc210>] (ieee80211_mesh_work+0x0/0x2c4) from [<c006b2bc>] (run_workqueue+0xa8/0x124)
<4>[ 1515.251843] [<c006b214>] (run_workqueue+0x0/0x124) from [<c006be20>] (worker_thread+0xec/0x100)
<4>[ 1515.263653]  r6:c7ace8a0 r5:c79d2000 r4:c7ace8a8
<4>[ 1515.275311] [<c006bd34>] (worker_thread+0x0/0x100) from [<c006ee28>] (kthread+0x5c/0x94)
<4>[ 1515.287274]  r6:c006bd34 r5:c7ace8a0 r4:c79d2000
<4>[ 1515.298962] [<c006edcc>] (kthread+0x0/0x94) from [<c005dd48>] (do_exit+0x0/0x6cc)
<4>[ 1515.310834]  r6:00000000 r5:00000000 r4:00000000
<4>[ 1515.322369] ---[ end trace 6577f51800004055 ]---
<7>[ 1515.333813] phy0: Inserted STA 00:1d:6e:9b:ee:6d
<7>[ 1515.334075] Mesh plink: starting establishment with 00:1d:6e:9b:ee:6d
<7>[ 1515.366638] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 1 55435 0 1
<7>[ 1515.375244] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 55435 52255 5
<7>[ 1515.383087] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 55435 52255 7
<7>[ 1515.448926] Mesh plink: starting establishment with 00:1d:6e:9b:ee:6d
<7>[ 1515.565271] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 1 45266 0 1
<7>[ 1515.652472] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 45266 42191 1
<7>[ 1515.816619] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 45266 42191 1
<7>[ 1515.988764] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 45266 42191 1
<7>[ 1516.222413] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 45266 42191 7
<7>[ 1516.384869] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1516.474268] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1516.660834] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1517.035595] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1517.620691] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1517.716322] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1517.808898] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1517.996655] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1518.309186] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1518.925549] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1519.047711] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1519.137689] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1519.332318] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1519.567132] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1519.886792] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1520.072015] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1520.162238] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1520.309277] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1520.566906] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1521.027050] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1521.197986] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1521.285534] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1521.449658] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1521.683874] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1522.120782] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1522.222321] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1522.308697] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1522.449658] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1522.722290] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.182879] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1523.349408] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.441265] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.542901] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.653998] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1523.808606] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1523.964532] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.051355] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.238568] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.457379] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.746228] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1524.885754] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1524.973095] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1525.136694] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1525.395458] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1525.809765] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8
<7>[ 1525.829907] m0: running mesh housekeeping
<7>[ 1525.910473] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1525.996636] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1526.105718] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1526.317089] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 3
<7>[ 1526.573998] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 5 45266 42191 8

2) Today it doesn't reproduce. Plink establishment passes, altough, warning remains:

<6>[    8.237792] cx3110x spi2.0: firmware: requesting 3826.arm
<6>[    8.343169] phy0: p54 detected a LM20 firmware
<6>[    8.348693] p54: rx_mtu reduced from 3240 to 2376
<6>[    8.354369] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6
<6>[    8.360319] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
<6>[    8.366423] cx3110x spi2.0: firmware: requesting 3826.eeprom
<6>[    8.474607] cx3110x spi2.0: loading default eeprom...
<6>[    8.480833] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow
<7>[    8.538937] phy0: Selected rate control algorithm 'minstrel'
<6>[    8.588103] cx3110x spi2.0: device is bound to phy0
<4>[    8.946653] Empty flash at 0x01ef1588 ends at 0x01ef1800
<4>[    9.091216] Empty flash at 0x02eb9474 ends at 0x02eb9800
<7>[   13.979885] usb0: eth_open
<7>[   13.979916] usb0: eth_start
<7>[   13.980068] g_ether gadget: ecm_open
<7>[   14.827604] g_ether gadget: notify connect true
<7>[   14.859617] g_ether gadget: notify speed 425984000
<7>[  122.496226] m0: running mesh housekeeping
<7>[  124.771694] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<4>[  124.774440] ------------[ cut here ]------------
<4>[  124.782008] WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
<4>[  124.789729] Modules linked in: p54spi
<4>[  124.797389] [<c0034ff8>] (dump_stack+0x0/0x14) from [<c005b1f0>] (warn_on_slowpath+0x4c/0x68)
<4>[  124.805721] [<c005b1a4>] (warn_on_slowpath+0x0/0x68) from [<c006051c>] (local_bh_enable+0x54/0xbc)
<4>[  124.822139]  r6:c79bbe00 r5:c7ed6e20 r4:c04594a0
<4>[  124.830562] [<c00604c8>] (local_bh_enable+0x0/0xbc) from [<bf000038>] (p54spi_op_tx+0x38/0x4c [p54spi])
<4>[  124.847926]  r4:c79bbe00
<4>[  124.856319] [<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi]) from [<c01a4dbc>] (p54_sta_unlock+0x64/0x78)
<4>[  124.874233]  r5:c79bb1a0 r4:c7ed6e20
<4>[  124.883083] [<c01a4d58>] (p54_sta_unlock+0x0/0x78) from [<c01a4df8>] (p54_sta_notify+0x28/0x2c)
<4>[  124.892574]  r7:c79a5380 r6:c79bb1a0 r5:60000013 r4:c7fec800
<4>[  124.902187] [<c01a4dd0>] (p54_sta_notify+0x0/0x2c) from [<c02e0a40>] (sta_info_insert+0x128/0x19c)
<4>[  124.921748] [<c02e0918>] (sta_info_insert+0x0/0x19c) from [<c02fdb44>] (mesh_neighbour_update+0x58/0xbc)
<4>[  124.942867]  r8:c79a5380 r7:00000000 r6:00000fff r5:c79bb1a0 r4:c7fec800
<4>[  124.953822] [<c02fdaec>] (mesh_neighbour_update+0x0/0xbc) from [<c02fc398>] (ieee80211_mesh_work+0x188/0x2c4)
<4>[  124.976039] [<c02fc210>] (ieee80211_mesh_work+0x0/0x2c4) from [<c006b2bc>] (run_workqueue+0xa8/0x124)
<4>[  124.998500] [<c006b214>] (run_workqueue+0x0/0x124) from [<c006be20>] (worker_thread+0xec/0x100)
<4>[  125.010341]  r6:c7aca920 r5:c79e8000 r4:c7aca928
<4>[  125.021968] [<c006bd34>] (worker_thread+0x0/0x100) from [<c006ee28>] (kthread+0x5c/0x94)
<4>[  125.033992]  r6:c006bd34 r5:c7aca920 r4:c79e8000
<4>[  125.045711] [<c006edcc>] (kthread+0x0/0x94) from [<c005dd48>] (do_exit+0x0/0x6cc)
<4>[  125.057613]  r6:00000000 r5:00000000 r4:00000000
<4>[  125.069148] ---[ end trace 6577f51800004055 ]---
<7>[  125.080592] phy0: Inserted STA 00:1d:6e:9b:ee:6d
<7>[  125.081085] Mesh plink: starting establishment with 00:1d:6e:9b:ee:6d
<7>[  125.103576] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 1 55435 0 1
<7>[  125.110412] Mesh plink (peer, state, llid, plid, event): 00:1d:6e:9b:ee:6d 2 55435 3385 4
<7>[  125.110473] Mesh plink with 00:1d:6e:9b:ee:6d ESTABLISHED
<7>[  183.146203] m0: running mesh housekeeping
<7>[  243.146171] m0: running mesh housekeeping
<7>[  265.520801] phy0: Removed STA 00:1d:6e:9b:ee:6d
<7>[  265.536378] phy0: Destroyed STA 00:1d:6e:9b:ee:6d

3) Beaconing works, but not the way it should: like MPs don't hear each other. Timestamps never get in sync
and both MPs issue beacon during 0.1s beacon interval.
I've seen it before, with stlc45xx. It shows when LMAC is set up with LMAC_SETUP_IBSS | LMAC_SETUP_TRANSPARENT flags.
If there's no LMAC_SETUP_TRANSPARENT flag in LMAC setup then timestamps get in sync.

(Traced with tshark -T fields -e frame.time -e wlan.sa -e wlan.seq -e wlan.fc.type_subtype -e wlan_mgt.fixed.timestamp)

08:27:47.423880000	00:1d:6e:9b:ee:6c	0	0x08	0x0000000000000580
08:27:47.433851000	00:1d:6e:9b:ee:6c	1	0x08	0x00000000000004ED
08:27:47.437849000	00:1d:6e:9b:ee:6c	2	0x08	0x0000000000000266
08:27:47.443847000	00:1d:6e:9b:ee:6c	3	0x08	0x0000000000000220
08:27:47.546857000	00:1d:6e:9b:ee:6c	4	0x08	0x0000000000019370
08:27:47.649819000	00:1d:6e:9b:ee:6c	5	0x08	0x00000000000326A4
08:27:47.751787000	00:1d:6e:9b:ee:6c	6	0x08	0x000000000004B690
08:27:47.853764000	00:1d:6e:9b:ee:6c	7	0x08	0x0000000000064474
08:27:47.955744000	00:1d:6e:9b:ee:6c	8	0x08	0x000000000007D1F4
08:27:48.058762000	00:1d:6e:9b:ee:6c	9	0x08	0x00000000000965B4
08:27:48.160737000	00:1d:6e:9b:ee:6c	10	0x08	0x00000000000AF398
08:27:48.263704000	00:1d:6e:9b:ee:6c	11	0x08	0x00000000000C830C
08:27:48.366677000	00:1d:6e:9b:ee:6c	12	0x08	0x00000000000E1537
08:27:48.467636000	00:1d:6e:9b:ee:6c	13	0x08	0x00000000000FA26C
08:27:48.571610000	00:1d:6e:9b:ee:6c	14	0x08	0x0000000000113528
08:27:48.673588000	00:1d:6e:9b:ee:6c	15	0x08	0x000000000012C690
08:27:48.775578000	00:1d:6e:9b:ee:6c	16	0x08	0x0000000000145528
08:27:48.877544000	00:1d:6e:9b:ee:6c	17	0x08	0x000000000015E35C
08:27:48.980549000	00:1d:6e:9b:ee:6c	18	0x08	0x0000000000177348
08:27:49.083530000	00:1d:6e:9b:ee:6c	19	0x08	0x0000000000190474
08:27:49.186511000	00:1d:6e:9b:ee:6c	20	0x08	0x00000000001A9690
08:27:49.287465000	00:1d:6e:9b:ee:6c	21	0x08	0x00000000001C2384
08:27:49.390436000	00:1d:6e:9b:ee:6c	22	0x08	0x00000000001DB671
08:27:49.492412000	00:1d:6e:9b:ee:6c	23	0x08	0x00000000001F44C4
08:27:49.595410000	00:1d:6e:9b:ee:6c	24	0x08	0x000000000020D3E9
08:27:49.696370000	00:1d:6e:9b:ee:6d	0	0x08	0x0000000000000569
08:27:49.698362000	00:1d:6e:9b:ee:6c	25	0x08	0x0000000000226656
08:27:49.712360000	00:1d:6e:9b:ee:6d	1	0x08	0x000000000000023D
08:27:49.713360000	00:1d:6e:9b:ee:6d	2	0x08	0x0000000000000438
08:27:49.719359000	00:1d:6e:9b:ee:6d	3	0x08	0x0000000000000296
08:27:49.720358000	00:1d:6e:9b:ee:6d	4	0x08	0x0000000000000613
08:27:49.799379000	00:1d:6e:9b:ee:6c	26	0x08	0x000000000023F2D2
08:27:49.823342000	00:1d:6e:9b:ee:6d	5	0x08	0x00000000000196A5
08:27:49.902330000	00:1d:6e:9b:ee:6c	27	0x08	0x00000000002583EA
08:27:49.925317000	00:1d:6e:9b:ee:6d	6	0x08	0x00000000000326D7
08:27:50.004346000	00:1d:6e:9b:ee:6c	28	0x08	0x00000000002712FA
08:27:50.010336000	00:1d:6e:9b:ee:6c	0	0x0d	
08:27:50.011399000			0x1d	
08:27:50.027297000	00:1d:6e:9b:ee:6d	7	0x08	0x000000000004B26D
08:27:50.028290000	00:1d:6e:9b:ee:6d	0	0x0d	
08:27:50.029305000			0x1d	
08:27:50.030287000	00:1d:6e:9b:ee:6c	1	0x0d	
08:27:50.031295000			0x1d	
08:27:50.032286000	00:1d:6e:9b:ee:6d	1	0x0d	
08:27:50.033295000			0x1d	
08:27:50.108304000	00:1d:6e:9b:ee:6c	29	0x08	0x000000000028A6CD
08:27:50.129274000	00:1d:6e:9b:ee:6d	8	0x08	0x0000000000064399
08:27:50.210268000	00:1d:6e:9b:ee:6c	30	0x08	0x00000000002A357A
08:27:50.232249000	00:1d:6e:9b:ee:6d	9	0x08	0x000000000007D30D
08:27:50.312234000	00:1d:6e:9b:ee:6c	31	0x08	0x00000000002BC642
08:27:50.334228000	00:1d:6e:9b:ee:6d	10	0x08	0x00000000000964ED
08:27:50.414218000	00:1d:6e:9b:ee:6c	32	0x08	0x00000000002D52E6
08:27:50.436206000	00:1d:6e:9b:ee:6d	11	0x08	0x00000000000AF26D
08:27:50.517218000	00:1d:6e:9b:ee:6c	33	0x08	0x00000000002EE6B9
08:27:50.539201000	00:1d:6e:9b:ee:6d	12	0x08	0x00000000000C8529
08:27:50.619169000	00:1d:6e:9b:ee:6c	34	0x08	0x00000000003073EA
08:27:50.642167000	00:1d:6e:9b:ee:6d	13	0x08	0x00000000000E1691

4) Pings don't go, because MPs don't answer ARP requests sent to it. Haven't tested for the root cause yet.
But again, I have seen this with stlc45xx with two different causes:
- when LMAC was set up without LMAC_SETUP_TRANSPARENT flag, ARP requests didn't pass LMAC packet filter
  and weren't reported to the driver;
- when LMAC was set up with LMAC_SETUP_TRANSPARENT flag firmware seem to truncate last 2 bytes of the packet
  that it reports.

> Is there anything else I can do, or something you want to know?
Are there other p54 species that use 3826.arm firmware?

Are there other sources of information regarding LMAC interaction except
http://wireless.kernel.org/en/developers/Documentation/specs?action=AttachFile&do=get&target=STSW45x0C_LMAC_API_ED1P4.pdf ?

Who should be contacted with questions about firmware behavior?

-- 
Thanks.
-- Max

Re: p54spi - mesh mode summary

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Thu, 2009-03-26 at 09:22 +0300, Max Filippov wrote:

> 3) Beaconing works, but not the way it should: like MPs don't hear each other. Timestamps never get in sync
> and both MPs issue beacon during 0.1s beacon interval.

That's perfectly fine for mesh. You're thinking of IBSS.

> 4) Pings don't go, because MPs don't answer ARP requests sent to it. Haven't tested for the root cause yet.

Maybe some multicast issue?

> Are there other sources of information regarding LMAC interaction except
> http://wireless.kernel.org/en/developers/Documentation/specs?action=AttachFile&do=get&target=STSW45x0C_LMAC_API_ED1P4.pdf ?

No; well, the header file.

> Who should be contacted with questions about firmware behavior?

I don't think we have any contact.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: p54spi - mesh mode summary

[Max Filippov]

> > 4) Pings don't go, because MPs don't answer ARP requests sent to it.
> > Haven't tested for the root cause yet.
>
> Maybe some multicast issue?

ARP requests get filtered out by LMAC.
Can anyone explain why? My 802.11s comprehension is quite weak.
Here's the packet:

IEEE 802.11 Data, Flags: ......FT
    Type/Subtype: Data (0x20)
    Frame Control: 0x0308 (Normal)
        Version: 0
        Type: Data frame (2)
        Subtype: 0
        Flags: 0x3
            DS status: WDS (AP to AP) or Mesh (MP to MP) Frame (To DS: 1 From DS: 1) (0x03)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    Duration: 0
    Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
    Transmitter address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
    Destination address: Broadcast (ff:ff:ff:ff:ff:ff)
    Fragment number: 0
    Sequence number: 2
    Source address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
    Mesh Header
        Address Extension 0
        Mesh TTL: 5
        Mesh Seq: 0
Logical-Link Control
    DSAP: SNAP (0xaa)
    IG Bit: Individual
    SSAP: SNAP (0xaa)
    CR Bit: Command
    Control field: U, func=UI (0x03)
        000. 00.. = Command: Unnumbered Information (0x00)
        .... ..11 = Frame type: Unnumbered frame (0x03)
    Organization Code: Encapsulated Ethernet (0x000000)
    Type: ARP (0x0806)
Address Resolution Protocol (request)
    Hardware type: Ethernet (0x0001)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (0x0001)
    Sender MAC address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
    Sender IP address: 192.168.4.13 (192.168.4.13)
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: 192.168.4.14 (192.168.4.14)


I'm tempted to do something like this in p54_setup_mac:

-               case NL80211_IFTYPE_MESH_POINT:
                        mode = P54_FILTER_TYPE_IBSS;
                        break;
+               case NL80211_IFTYPE_MESH_POINT:
+                       mode = P54_FILTER_TYPE_IBSS | P54_FILTER_TYPE_TRANSPARENT;
+                       break;

But I guess that's bad solution, at least for pci/usb drivers.
Christian, Johannes, what would you suggest?

-- 
Thanks.
-- Max

Re: p54spi - mesh mode summary

[Christian Lamparter]

On Friday 27 March 2009 06:03:54 Max Filippov wrote:
> > > 4) Pings don't go, because MPs don't answer ARP requests sent to it.
> > > Haven't tested for the root cause yet.
> >
> > Maybe some multicast issue?
> 
> ARP requests get filtered out by LMAC.
> Can anyone explain why? My 802.11s comprehension is quite weak.
> Here's the packet:
> 
> IEEE 802.11 Data, Flags: ......FT
>     Type/Subtype: Data (0x20)
>     Frame Control: 0x0308 (Normal)
>         Version: 0
>         Type: Data frame (2)
>         Subtype: 0
>         Flags: 0x3
>             DS status: WDS (AP to AP) or Mesh (MP to MP) Frame (To DS: 1 From DS: 1) (0x03)
>             .... .0.. = More Fragments: This is the last fragment
>             .... 0... = Retry: Frame is not being retransmitted
>             ...0 .... = PWR MGT: STA will stay up
>             ..0. .... = More Data: No data buffered
>             .0.. .... = Protected flag: Data is not protected
>             0... .... = Order flag: Not strictly ordered
>     Duration: 0
>     Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
>     Transmitter address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
>     Destination address: Broadcast (ff:ff:ff:ff:ff:ff)
>     Fragment number: 0
>     Sequence number: 2
>     Source address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
>     Mesh Header
>         Address Extension 0
>         Mesh TTL: 5
>         Mesh Seq: 0
> Logical-Link Control
>     DSAP: SNAP (0xaa)
>     IG Bit: Individual
>     SSAP: SNAP (0xaa)
>     CR Bit: Command
>     Control field: U, func=UI (0x03)
>         000. 00.. = Command: Unnumbered Information (0x00)
>         .... ..11 = Frame type: Unnumbered frame (0x03)
>     Organization Code: Encapsulated Ethernet (0x000000)
>     Type: ARP (0x0806)
> Address Resolution Protocol (request)
>     Hardware type: Ethernet (0x0001)
>     Protocol type: IP (0x0800)
>     Hardware size: 6
>     Protocol size: 4
>     Opcode: request (0x0001)
>     Sender MAC address: NokiaDan_9b:ee:6c (00:1d:6e:9b:ee:6c)
>     Sender IP address: 192.168.4.13 (192.168.4.13)
>     Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
>     Target IP address: 192.168.4.14 (192.168.4.14)
> 
> 
> I'm tempted to do something like this in p54_setup_mac:
> 
> -               case NL80211_IFTYPE_MESH_POINT:
>                         mode = P54_FILTER_TYPE_IBSS;
>                         break;
> +               case NL80211_IFTYPE_MESH_POINT:
> +                       mode = P54_FILTER_TYPE_IBSS | P54_FILTER_TYPE_TRANSPARENT;
> +                       break;
> 
> But I guess that's bad solution, at least for pci/usb drivers.
> Christian, Johannes, what would you suggest?
That's odd.

P54_FILTER_TYPE_TRANSPARENT should be already set for mesh mode.

The reason is that mesh mode will automatically set the FIF_OTHER_BSS flag,
(file:net/mac80211/iface.c func:ieee80211_open lines:251 f) 

which in turn ORs the P54_FILTER_TYPE_TRANSPARENT flag to the mode...
(file:drivers/net/wireless/p54/p54common.c func: p54_setup_mac lines: 1691 f)

So, there's no need to OR a flag that gets ORed anyway?

Regards,
	Chr

Re: p54spi - mesh mode summary

[Max Filippov]

> That's odd.
>
> P54_FILTER_TYPE_TRANSPARENT should be already set for mesh mode.
>
> The reason is that mesh mode will automatically set the FIF_OTHER_BSS=
 flag,
> (file:net/mac80211/iface.c func:ieee80211_open lines:251 f)
>
> which in turn ORs the P54_FILTER_TYPE_TRANSPARENT flag to the mode...
> (file:drivers/net/wireless/p54/p54common.c func: p54_setup_mac lines:=
 1691
> f)
>
> So, there's no need to OR a flag that gets ORed anyway?

=46ound the problem, that's my fault at merge of omap and wireless-test=
ing=20
trees:
p54_configure_filter that I tested with has the following code:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *total_flags &=3D FIF_PROMISC_IN_BSS |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 FIF_OTHER_BSS |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 (*total_flags & FIF_PROMISC_IN_BSS) ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 FIF_FCSFAIL : 0;

which does not what it is intended to. '|' operator has higher preceden=
ce=20
than '? :'
thus it is equivalent to *total_flags &=3D FIF_FCSFAIL; which never yie=
lds=20
neither
=46IF_PROMISC_IN_BSS nor FIF_OTHER_BSS.

Current wireless-testing head has=20

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *total_flags &=3D FIF_PROMISC_IN_BSS |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 FIF_OTHER_BSS;

at this place, which work fine.

--=20
Thanks.
-- Max
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: p54spi - mesh mode summary

[Christian Lamparter]

On Saturday 28 March 2009 04:21:02 Max Filippov wrote:
> > That's odd.
> >
> > P54_FILTER_TYPE_TRANSPARENT should be already set for mesh mode.
> >
> > The reason is that mesh mode will automatically set the FIF_OTHER_B=
SS flag,
> > (file:net/mac80211/iface.c func:ieee80211_open lines:251 f)
> >
> > which in turn ORs the P54_FILTER_TYPE_TRANSPARENT flag to the mode.=
=2E.
> > (file:drivers/net/wireless/p54/p54common.c func: p54_setup_mac line=
s: 1691
> > f)
> >
> > So, there's no need to OR a flag that gets ORed anyway?
>=20
> Found the problem, that's my fault at merge of omap and wireless-test=
ing=20
> trees:
> p54_configure_filter that I tested with has the following code:
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 *total_flags &=3D FIF_PROMISC_IN_BSS |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 FIF_OTHER_BSS |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 (*total_flags & FIF_PROMISC_IN_BSS) ?
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 FIF_FCSFAIL : 0;
>=20
> which does not what it is intended to. '|' operator has higher preced=
ence=20
> than '? :'
> thus it is equivalent to *total_flags &=3D FIF_FCSFAIL; which never y=
ields=20
> neither
> FIF_PROMISC_IN_BSS nor FIF_OTHER_BSS.
>=20
> Current wireless-testing head has=20
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 *total_flags &=3D FIF_PROMISC_IN_BSS |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 FIF_OTHER_BSS;
>=20
> at this place, which work fine.
Yup that was fixed by "p54: misplaced parentheses"
( c1359ddff01dc63b2770f876a94b6dd97e0473f6 )
and FCS_FAIL was removed by "p54: completely ignore rx'd frames with ba=
d FCS"
( adda7e08403adf0980efb69ffe339567df8eb8d1 )=20

your last patches had some offset, do you have more code fixes or
does everything work (properly)?

Regards,
	Chr
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: p54spi - mesh mode summary

[Max Filippov]

> your last patches had some offset, do you have more code fixes or
> does everything work (properly)?
The offset is caused by the fact that I haven't merged in changes that has been done since 2009.01.09.
Now I've cherry-picked all recent patches related to p54, and IBSS and mesh are working good.

There are 3 issues that I'm focused on now:

- 'cx3110x spi2.0: WR_READY timeout' which sometimes occurs on ifdown-ifup cycle. Communication
  with firmware breaks and sometimes the box hangs altogether. It looks like some locking-concurrency
  issue, but I still haven't found it for sure;

- this, which happens every time when IBSS or mesh starts:
<7>[  211.754448] wlan0: Creating new IBSS network, BSSID 56:75:0c:c5:65:0d
<7>[  213.681352] phy0: Adding new IBSS station 00:1d:6e:9b:ee:6d (dev=wlan0)
<7>[  213.681443] phy0: Allocated STA 00:1d:6e:9b:ee:6d
<4>[  213.684251] ------------[ cut here ]------------
<4>[  213.691850] WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
<4>[  213.699571] Modules linked in: p54spi
<4>[  213.707231] [<c0034ff8>] (dump_stack+0x0/0x14) from [<c005b1f0>] (warn_on_slowpath+0x4c/0x68)
<4>[  213.715623] [<c005b1a4>] (warn_on_slowpath+0x0/0x68) from [<c006051c>] (local_bh_enable+0x54/0xbc)
<4>[  213.732041]  r6:c7cc4e00 r5:c7840380 r4:c04594a0
<4>[  213.740464] [<c00604c8>] (local_bh_enable+0x0/0xbc) from [<bf000038>] (p54spi_op_tx+0x38/0x4c [p54spi])
<4>[  213.757829]  r4:c7cc4e00
<4>[  213.766221] [<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi]) from [<c01a4d98>] (p54_sta_unlock+0x64/0x78)
<4>[  213.784135]  r5:c7cc41a0 r4:c7840380
<4>[  213.793016] [<c01a4d34>] (p54_sta_unlock+0x0/0x78) from [<c01a4dd4>] (p54_sta_notify+0x28/0x2c)
<4>[  213.802507]  r7:c7971380 r6:c7cc41a0 r5:60000013 r4:c79cd400
<4>[  213.812120] [<c01a4dac>] (p54_sta_notify+0x0/0x2c) from [<c02e0a60>] (sta_info_insert+0x128/0x19c)
<4>[  213.831681] [<c02e0938>] (sta_info_insert+0x0/0x19c) from [<c02e7b90>] (ieee80211_ibss_add_sta+0x150/0x170)
<4>[  213.852830]  r8:00000000 r7:c79cd400 r6:c7971380 r5:00000000 r4:c0416500
<4>[  213.863786] [<c02e7a40>] (ieee80211_ibss_add_sta+0x0/0x170) from [<c02e7e3c>] (ieee80211_rx_bss_info+0x188/0x48c)
<4>[  213.886033]  r8:c701ee24 r7:00000000 r6:00000fff r5:c701ee24 r4:c701ee2e
<4>[  213.897386] [<c02e7cb4>] (ieee80211_rx_bss_info+0x0/0x48c) from [<c02e8fac>] (ieee80211_sta_work+0x388/0xfe8)
<4>[  213.919816] [<c02e8c24>] (ieee80211_sta_work+0x0/0xfe8) from [<c006b2bc>] (run_workqueue+0xa8/0x124)
<4>[  213.942948] [<c006b214>] (run_workqueue+0x0/0x124) from [<c006be20>] (worker_thread+0xec/0x100)
<4>[  213.955003]  r6:c79764e0 r5:c79dc000 r4:c79764e8
<4>[  213.966783] [<c006bd34>] (worker_thread+0x0/0x100) from [<c006ee28>] (kthread+0x5c/0x94)
<4>[  213.978746]  r6:c006bd34 r5:c79764e0 r4:c79dc000
<4>[  213.990586] [<c006edcc>] (kthread+0x0/0x94) from [<c005dd48>] (do_exit+0x0/0x6cc)
<4>[  214.002580]  r6:00000000 r5:00000000 r4:00000000
<4>[  214.014238] ---[ end trace 3652d538aa1ad903 ]---

- infinite beacon resubmission loop in IBSS which causes severe performance degradation, not to mention radio noise.

Before TSF sync loss:
(none):~# ping -s 50000 192.168.4.14
PING 192.168.4.14 (192.168.4.14): 50000 data bytes
50008 bytes from 192.168.4.14: seq=0 ttl=64 time=130.4 ms
50008 bytes from 192.168.4.14: seq=1 ttl=64 time=129.9 ms
50008 bytes from 192.168.4.14: seq=2 ttl=64 time=130.4 ms
50008 bytes from 192.168.4.14: seq=3 ttl=64 time=132.9 ms
50008 bytes from 192.168.4.14: seq=4 ttl=64 time=133.6 ms

After:
(none):~# ifconfig wlan0 down
(none):~# ifconfig wlan0 up
(none):~# ping -s 50000 192.168.4.14
PING 192.168.4.14 (192.168.4.14): 50000 data bytes
50008 bytes from 192.168.4.14: seq=1 ttl=64 time=629.1 ms
50008 bytes from 192.168.4.14: seq=2 ttl=64 time=825.8 ms
50008 bytes from 192.168.4.14: seq=3 ttl=64 time=421.2 ms
50008 bytes from 192.168.4.14: seq=4 ttl=64 time=745.5 ms
50008 bytes from 192.168.4.14: seq=5 ttl=64 time=548.0 ms
50008 bytes from 192.168.4.14: seq=6 ttl=64 time=296.1 ms
50008 bytes from 192.168.4.14: seq=7 ttl=64 time=501.2 ms

Hope that I make patches for at least first two issues during the next few days.

-- 
Thanks a lot (:
-- Max

Re: p54spi - mesh mode summary

[Christian Lamparter]

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

On Sunday 29 March 2009 06:41:59 Max Filippov wrote:
> > your last patches had some offset, do you have more code fixes or
> > does everything work (properly)?
> The offset is caused by the fact that I haven't merged in changes that has been done since 2009.01.09.
> Now I've cherry-picked all recent patches related to p54, and IBSS and mesh are working good.
> 
> There are 3 issues that I'm focused on now:
> 
> - 'cx3110x spi2.0: WR_READY timeout' which sometimes occurs on ifdown-ifup cycle. Communication
>   with firmware breaks and sometimes the box hangs altogether. It looks like some locking-concurrency
>   issue, but I still haven't found it for sure;
> 
> - this, which happens every time when IBSS or mesh starts:
> <7>[  211.754448] wlan0: Creating new IBSS network, BSSID 56:75:0c:c5:65:0d
> <7>[  213.681352] phy0: Adding new IBSS station 00:1d:6e:9b:ee:6d (dev=wlan0)
> <7>[  213.681443] phy0: Allocated STA 00:1d:6e:9b:ee:6d
> <4>[  213.684251] ------------[ cut here ]------------
> <4>[  213.691850] WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
> <4>[  213.699571] Modules linked in: p54spi
> <4>[  213.707231] [<c0034ff8>] (dump_stack+0x0/0x14) from [<c005b1f0>] (warn_on_slowpath+0x4c/0x68)
> <4>[  213.715623] [<c005b1a4>] (warn_on_slowpath+0x0/0x68)
> <4>[  213.740464] [<c00604c8>] (local_bh_enable+0x0/0xbc)
> <4>[  213.766221] [<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi])
> <4>[  213.793016] [<c01a4d34>] (p54_sta_unlock+0x0/0x78) 
hmm, sta_unlock is called from a tasklet, so we must use the irqsave functions
does this warning go away with the attached patch?

Regards,
	Chr

[-- Attachment #2: p54spi-irqsave-locks.diff --]
[-- Type: text/x-diff, Size: 2488 bytes --]

diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 155f453..5202312 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -469,9 +469,10 @@ static int p54spi_wq_tx(struct p54s_priv *priv)
 	struct ieee80211_tx_info *info;
 	struct p54_tx_info *minfo;
 	struct p54s_tx_info *dinfo;
+	unsigned long flags;
 	int ret = 0;
 
-	spin_lock_bh(&priv->tx_lock);
+	spin_lock_irqsave(&priv->tx_lock, flags);
 
 	while (!list_empty(&priv->tx_pending)) {
 		entry = list_entry(priv->tx_pending.next,
@@ -479,7 +480,7 @@ static int p54spi_wq_tx(struct p54s_priv *priv)
 
 		list_del_init(&entry->tx_list);
 
-		spin_unlock_bh(&priv->tx_lock);
+		spin_unlock_irqrestore(&priv->tx_lock, flags);
 
 		dinfo = container_of((void *) entry, struct p54s_tx_info,
 				     tx_list);
@@ -491,16 +492,14 @@ static int p54spi_wq_tx(struct p54s_priv *priv)
 
 		ret = p54spi_tx_frame(priv, skb);
 
-		spin_lock_bh(&priv->tx_lock);
-
 		if (ret < 0) {
 			p54_free_skb(priv->hw, skb);
-			goto out;
+			return ret;
 		}
-	}
 
-out:
-	spin_unlock_bh(&priv->tx_lock);
+		spin_lock_irqsave(&priv->tx_lock, flags);
+	}
+	spin_unlock_irqrestore(&priv->tx_lock, flags);
 	return ret;
 }
 
@@ -510,12 +509,13 @@ static void p54spi_op_tx(struct ieee80211_hw *dev, struct sk_buff *skb)
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	struct p54_tx_info *mi = (struct p54_tx_info *) info->rate_driver_data;
 	struct p54s_tx_info *di = (struct p54s_tx_info *) mi->data;
+	unsigned long flags;
 
 	BUILD_BUG_ON(sizeof(*di) > sizeof((mi->data)));
 
-	spin_lock_bh(&priv->tx_lock);
+	spin_lock_irqsave(&priv->tx_lock, flags);
 	list_add_tail(&di->tx_list, &priv->tx_pending);
-	spin_unlock_bh(&priv->tx_lock);
+	spin_unlock_irqrestore(&priv->tx_lock, flags);
 
 	queue_work(priv->hw->workqueue, &priv->work);
 }
@@ -616,6 +616,7 @@ out:
 static void p54spi_op_stop(struct ieee80211_hw *dev)
 {
 	struct p54s_priv *priv = dev->priv;
+	unsigned long flags;
 
 	if (mutex_lock_interruptible(&priv->mutex)) {
 		/* FIXME: how to handle this error? */
@@ -627,9 +628,9 @@ static void p54spi_op_stop(struct ieee80211_hw *dev)
 	cancel_work_sync(&priv->work);
 
 	p54spi_power_off(priv);
-	spin_lock_bh(&priv->tx_lock);
+	spin_lock_irqsave(&priv->tx_lock, flags);
 	INIT_LIST_HEAD(&priv->tx_pending);
-	spin_unlock_bh(&priv->tx_lock);
+	spin_unlock_irqrestore(&priv->tx_lock, flags);
 
 	priv->fw_state = FW_STATE_OFF;
 	mutex_unlock(&priv->mutex);

Re: p54spi - mesh mode summary

[Max Filippov]

> hmm, sta_unlock is called from a tasklet, so we must use the irqsave
> functions does this warning go away with the attached patch?
Yes, it does.

-- 
Thanks.
-- Max

Re: [PATCH 2/2 v2] p54spi: fix p54spi_upload_firmware

[Max Filippov]

> > > what do you think about the attached proposal?
> >
> > It looks generally better. But (fw + offset) wouldn't compile, because
> > fw is void*.
>
> ??? but it does compile?!
>   CHECK   drivers/net/wireless/p54/p54spi.c
>   CC [M]  drivers/net/wireless/p54/p54spi.o
>  Building modules, stage 2.
>   MODPOST 4 modules
>   CC      drivers/net/wireless/p54/p54spi.mod.o
>   LD [M]  drivers/net/wireless/p54/p54spi.ko
>
> But yes, I agree we better change void *fw to u8 *fw.
>
> BTW: does p54spi really work now?
Now firmware uploading code works fine. It even successfully uploads firmware 
in small chunks.

-- 
Thanks.
-- Max

Re: [PATCH 1/2] p54spi: mask value read from SPI_ADRS_DMA_WRITE_CTRL in p54spi_wait_bit

[Christian Lamparter]

On Wednesday 25 March 2009 06:30:15 Max Filippov wrote:
>  Mask value read from SPI_ADRS_DMA_WRITE_CTRL in p54spi_wait_bit.
>  Without this, 'fw_upload not allowed to DMA write' is observed at both N800 and N810.
> 
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>

Acked-by: Christian Lamparter <chunkeey@web.de>
> ---
>  drivers/net/wireless/p54/p54spi.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
> index 2b222aa..d13268f 100644
> --- a/drivers/net/wireless/p54/p54spi.c
> +++ b/drivers/net/wireless/p54/p54spi.c
> @@ -171,7 +171,7 @@ static int p54spi_wait_bit(struct p54s_priv *priv, u16 reg, __le32 bits)
>  
>  	for (i = 0; i < 2000; i++) {
>  		p54spi_spi_read(priv, reg, &buffer, sizeof(buffer));
> -		if (buffer == bits)
> +		if ((buffer & bits) == bits)
>  			return 1;
>  
>  		msleep(1);