[PATCH 1/5] ieee802154/cc2420: Fix packet length value.

This is an addition to the last fix for adding the length byte. With hardware
FCS enabled we are obliged to set the length including the 2 bytes for the
FCS. Our skb does only have the len for the data it contains so we need to
adjust it for the length byte.

Signed-off-by: Stefan Schmidt <stefan@...>
---
 drivers/ieee802154/cc2420.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/ieee802154/cc2420.c b/drivers/ieee802154/cc2420.c
index fd072ce..3cc2724 100644
--- a/drivers/ieee802154/cc2420.c
+++ b/drivers/ieee802154/cc2420.c
 <at>  <at>  -213,6 +213,8  <at>  <at>  static int
 cc2420_write_txfifo(struct cc2420_local *lp, u8 *data, u8 len)
 {
 	int status;
+	/* Length byte must include FCS even if calculated in hardware */
+	int len_byte = len + 2;
 	struct spi_message msg;
 	struct spi_transfer xfer_head = {
 		.len		= 1,
 <at>  <at>  -221,7 +223,7  <at>  <at>  cc2420_write_txfifo(struct cc2420_local *lp, u8 *data, u8 len)
 	};
 	struct spi_transfer xfer_len = {
 		.len		= 1,
-		.tx_buf		= &len,
+		.tx_buf		= &len_byte,
 	};

[PATCH 2/5] ieee802154/cc2420: Send only the real packet into the stack.

With hardware FCS enabled the chip replaces the FCS bytes with a correlation
value, a FCS flag and the rssi value.

We need to make sure that both bytes are getting clipped before sending them
into the stack as functions checking for the length will fail otherwise.

Signed-off-by: Stefan Schmidt <stefan@...>
---
 drivers/ieee802154/cc2420.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/ieee802154/cc2420.c b/drivers/ieee802154/cc2420.c
index 3cc2724..f8fab59 100644
--- a/drivers/ieee802154/cc2420.c
+++ b/drivers/ieee802154/cc2420.c
 <at>  <at>  -367,8 +367,9  <at>  <at>  static int cc2420_rx(struct cc2420_local *lp)
 		return -EINVAL;
 	}

-	skb_trim(skb, len-1); /* We do not put CRC and Corr into
-							the frame, but remain rssi value */
+	/* Clip last two bytes. When using hardware FCS they get replaced with
+	 * correlation value, FCS flag and RSSI value */
+	skb_trim(skb, len-2);

 	ieee802154_rx_irqsafe(lp->dev, skb, lqi);

--

-- 
1.7.1

[PATCH 4/5] HACK: ieee802154/cc2420: Avoid gpio_request for fifop.

When gpio_request()'ing the fifop GPIO we get back an -EBUSY. It seems to be
related to fifop being 0 and the gpiolib may have some special handling for 0.
As this is "only" a resource allocation call which does not do anything with the
GPIO we are still able to use it correctly without it and it works as expected.

However this needs to be worked out completely and a real fix is needed.
---
 drivers/ieee802154/cc2420.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/ieee802154/cc2420.c b/drivers/ieee802154/cc2420.c
index 983800f..7839ddb 100644
--- a/drivers/ieee802154/cc2420.c
+++ b/drivers/ieee802154/cc2420.c
 <at>  <at>  -588,10 +588,12  <at>  <at>  static int __devinit cc2420_probe(struct spi_device *spi)
 	ret = gpio_request(lp->pdata->cca, "cca");
 	if (ret)
 		goto err_free_gpio_fifo;
+#if 0
 	/* This is causing problems as fifop is gpio 0 ? */
 	ret = gpio_request(lp->pdata->fifop, "fifop");
 	if (ret)
 		goto err_free_gpio_cca;
+#endif
 	ret = gpio_request(lp->pdata->sfd, "sfd");
 	if (ret)
 		goto err_free_gpio_fifop;
 <at>  <at>  -700,8 +702,8  <at>  <at>  err_free_gpio_sfd:
 	gpio_free(lp->pdata->sfd);
 err_free_gpio_fifop:

[PATCH 5/5] [ARM]: mach/pxa: Add platform data for cc2420 driver.

Now that the cc2420 driver has landed mainline we could supply the GPIO setup
via platform data and remove them from the MFP table.

Signed-off-by: Stefan Schmidt <stefan@...>
---
 arch/arm/mach-pxa/imote2.c |   27 ++++++++++++++++++---------
 1 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-pxa/imote2.c b/arch/arm/mach-pxa/imote2.c
index 5b0862d..c99f04e 100644
--- a/arch/arm/mach-pxa/imote2.c
+++ b/arch/arm/mach-pxa/imote2.c
 <at>  <at>  -23,6 +23,7  <at>  <at> 
 #include <linux/i2c.h>
 #include <linux/mfd/da903x.h>
 #include <linux/sht15.h>
+#include <linux/spi/cc2420.h>

 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 <at>  <at>  -39,6 +40,13  <at>  <at> 
 #include "devices.h"
 #include "generic.h"

+#define GPIO_FIFOP	0
+#define GPIO_SFD	16
+#define GPIO_RESET	22
+#define GPIO_FIFO	114
+#define GPIO_VREG	115
+#define GPIO_CCA	116

[PATCH 3/5] ieee802154/cc2420: Fix some typos and wording

Most of it is trivial but should help to understand the debugging output
better.

Signed-off-by: Stefan Schmidt <stefan@...>
---
 drivers/ieee802154/cc2420.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/ieee802154/cc2420.c b/drivers/ieee802154/cc2420.c
index f8fab59..983800f 100644
--- a/drivers/ieee802154/cc2420.c
+++ b/drivers/ieee802154/cc2420.c
 <at>  <at>  -496,7 +496,7  <at>  <at>  static void cc2420_sfd_irqwork(struct work_struct *work)
 		= container_of(work, struct cc2420_local, sfd_irqwork);
 	unsigned long flags;

-	dev_dbg(&lp->spi->dev, "fifop interrupt received\n");
+	dev_dbg(&lp->spi->dev, "sfd interrupt received\n");

 	spin_lock_irqsave(&lp->lock, flags);
 	if (lp->is_tx) {
 <at>  <at>  -544,7 +544,7  <at>  <at>  static int cc2420_hw_init(struct cc2420_local *lp)
 		udelay(1);
 	} while (!(status & CC2420_STATUS_XOSC16M_STABLE));

-	dev_info(&lp->spi->dev, "oscillator succesfully brought up \n");
+	dev_info(&lp->spi->dev, "oscillator succesfully brought up\n");

 	return 0;
 error_ret:

Latest fixes for CC2420

Hello.

With these patches I'm finally able to  have a working 802.15.4 setup with two
imotes. One as coordinator and one as client. The packets sniffed on the air are
also looking good now in wireshark.

I would like to get the first three patches applied. The fourth is a hack to
work around the gpio_request problem and should not get applied. We need a real
fix for this. Still it is needed to get the driver through probing.

The last patch is only appended as reference. It will go to the arm list once
the mac802154 stack and the cc2420 driver hits mainline.

regards
Stefan Schmidt

------------------------------------------------------------------------------

cc2420 linux driver status?

Hello everyone,
I asked a questiona month ago, but nobody answered me, so I'm asking again:
Does anyone have a linux driver for TI/Chipcon cc2420 radio?
Or may be somebody knows where to get the compilable source?

It looks like people are using it, but yet I couldn't figure out where to
download it.
--

-- 
Respectfully yours, Alexander E. Gogolev

------------------------------------------------------------------------------

Re: cc2420 linux driver status?

On 05/05/10 14:35, agogolev wrote:
> Hello everyone,
> I asked a questiona month ago, but nobody answered me, so I'm asking again:
> Does anyone have a linux driver for TI/Chipcon cc2420 radio?
> Or may be somebody knows where to get the compilable source?
> 
> It looks like people are using it, but yet I couldn't figure out where to
> download it.

As per Stefan Schmidt's email to this list yesterday, he has it working.

Apply his latest patch set to a clone of the linux-zigbee kernel git tree,

browse it at:

http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=summary

or

git clone  git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee/kernel

Then take a look at the devel branch.

------------------------------------------------------------------------------

Re: [PATCH 1/5] ieee802154/cc2420: Fix packet length value.

------------------------------------------------------------------------------

_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@...
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

Re: Latest fixes for CC2420

------------------------------------------------------------------------------

_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@...
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel