* [PATCH] doc: linux-wpan: Fulfill the description of missed 802.15.4 APIs
From: Jian-Hong Pan @ 2017-11-18 15:55 UTC (permalink / raw)
To: Alexander Aring, Stefan Schmidt, Jonathan Corbet, linux-wpan,
linux-doc
Cc: Jian-Hong Pan
There are more functions and operations which must be used or implemented
in each IEEE 802.15.4 device driver, but are not mentioned in the Device
drivers API section of Documentation/networking/ieee802154.txt. Therefore,
I want to fulfill the missed part into the documentation with this patch.
Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
---
Documentation/networking/ieee802154.txt | 40 +++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 057e9fdbfac9..e74d8e1da0e2 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -97,6 +97,46 @@ The include/net/mac802154.h defines following functions:
- void ieee802154_unregister_hw(struct ieee802154_hw *hw):
freeing registered PHY
+ - void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb,
+ u8 lqi):
+ telling 802.15.4 module there is a new received frame in the skb with
+ the RF Link Quality Indicator (LQI) from the hardware device
+
+ - void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
+ bool ifs_handling):
+ telling 802.15.4 module the frame in the skb is or going to be
+ transmitted through the hardware device
+
+The device driver must implement the following callbacks in the IEEE 802.15.4
+operations structure at least:
+struct ieee802154_ops {
+ ...
+ int (*start)(struct ieee802154_hw *hw);
+ void (*stop)(struct ieee802154_hw *hw);
+ ...
+ int (*xmit_async)(struct ieee802154_hw *hw, struct sk_buff *skb);
+ int (*ed)(struct ieee802154_hw *hw, u8 *level);
+ int (*set_channel)(struct ieee802154_hw *hw, u8 page, u8 channel);
+ ...
+};
+
+ - int start(struct ieee802154_hw *hw):
+ handler that 802.15.4 module calls for the hardware device initialization.
+
+ - void stop(struct ieee802154_hw *hw):
+ handler that 802.15.4 module calls for the hardware device cleanup.
+
+ - int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
+ handler that 802.15.4 module calls for each frame in the skb going to be
+ transmitted through the hardware device.
+
+ - int ed(struct ieee802154_hw *hw, u8 *level):
+ handler that 802.15.4 module calls for Energy Detection from the hardware
+ device.
+
+ - int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
+ set radio for listening on specific channel of the hardware device.
+
Moreover IEEE 802.15.4 device operations structure should be filled.
Fake drivers
--
2.15.0
^ permalink raw reply related
* Re: [PATCH] doc: linux-wpan: Fulfill the description of missed 802.15.4 APIs
From: Alexander Aring @ 2017-11-19 16:19 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Alexander Aring, Stefan Schmidt, Jonathan Corbet, linux-wpan - ML,
linux-doc
In-Reply-To: <20171118155501.14148-1-starnight@g.ncu.edu.tw>
Hi,
On Sat, Nov 18, 2017 at 10:55 AM, Jian-Hong Pan <starnight@g.ncu.edu.tw> wrote:
> There are more functions and operations which must be used or implemented
> in each IEEE 802.15.4 device driver, but are not mentioned in the Device
> drivers API section of Documentation/networking/ieee802154.txt. Therefore,
> I want to fulfill the missed part into the documentation with this patch.
>
> Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
Acked-by: Alexander Aring <aring@mojatatu.com>
Thanks for doing this kind of job and blame for me that I didn't
update documentation...
xmit_complete is more a signal to say "frame transmission done", means
you can fill the hardware side frame buffer with new frames again.
It works together mit xmit_async, as xmit_sync (the old method) waits
until framebuffer fill is complete. It queues the work into workqueue
and people do "spi_sync" handling... but the ndo_xmit callback of
netdev works differently. It means "fill the frame into framebuffer
and start transmit" (in context of this callback) what "xmit_async" is
made for - not queue into workqueue (what xmit_sync) does.
Anyway I see problems when using subsystems e.g. traffic control which
assumes that at this time the frame is being to transmitted and not
queued somewhere else (in a software queue, e.g. workqueue).
People say to me, "spi_sync" "spi_async" - doesn't matter the spi
subsystem will do the same "things" afterwards, but then this is a bug
inside the spi subsystem to handle softirq context correctly.
- Alex
^ permalink raw reply
* Re: [PATCH] doc: linux-wpan: Fulfill the description of missed 802.15.4 APIs
From: Jian-Hong Pan @ 2017-11-20 15:27 UTC (permalink / raw)
To: Alexander Aring
Cc: Alexander Aring, Stefan Schmidt, Jonathan Corbet, linux-wpan - ML,
linux-doc
In-Reply-To: <CAOHTApiBh8VzMTm4FwjguPCQtNQMwefeDMptKDL1Vzh0TgewgA@mail.gmail.com>
Hi,
2017-11-20 0:19 GMT+08:00 Alexander Aring <aring@mojatatu.com>:
> Hi,
>
> On Sat, Nov 18, 2017 at 10:55 AM, Jian-Hong Pan <starnight@g.ncu.edu.tw> wrote:
>> There are more functions and operations which must be used or implemented
>> in each IEEE 802.15.4 device driver, but are not mentioned in the Device
>> drivers API section of Documentation/networking/ieee802154.txt. Therefore,
>> I want to fulfill the missed part into the documentation with this patch.
>>
>> Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
>
> Acked-by: Alexander Aring <aring@mojatatu.com>
>
> Thanks for doing this kind of job and blame for me that I didn't
> update documentation...
>
> xmit_complete is more a signal to say "frame transmission done", means
> you can fill the hardware side frame buffer with new frames again.
> It works together mit xmit_async, as xmit_sync (the old method) waits
> until framebuffer fill is complete. It queues the work into workqueue
> and people do "spi_sync" handling... but the ndo_xmit callback of
> netdev works differently. It means "fill the frame into framebuffer
> and start transmit" (in context of this callback) what "xmit_async" is
> made for - not queue into workqueue (what xmit_sync) does.
Thanks for Alex's sharing.
And, Yes! I was stuck here a while when I was developing the device driver.
I figured out what you mentioned after traced the code and the dumped error
message.
Jian-Hong, Pan
> Anyway I see problems when using subsystems e.g. traffic control which
> assumes that at this time the frame is being to transmitted and not
> queued somewhere else (in a software queue, e.g. workqueue).
> People say to me, "spi_sync" "spi_async" - doesn't matter the spi
> subsystem will do the same "things" afterwards, but then this is a bug
> inside the spi subsystem to handle softirq context correctly.
>
> - Alex
^ permalink raw reply
* [PATCH 1/5] net: ieee802154: adf7242: Add support for ADF7241 devices
From: michael.hennerich @ 2017-11-28 12:53 UTC (permalink / raw)
To: alex.aring, stefan; +Cc: linux-wpan, Michael Hennerich
From: Michael Hennerich <michael.hennerich@analog.com>
This adds support for ADF7241 Low Power IEEE 802.15.4
Zero-IF 2.4 GHz Transceivers
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
---
Documentation/devicetree/bindings/net/ieee802154/adf7242.txt | 2 +-
drivers/net/ieee802154/adf7242.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt b/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
index dea5124..d24172c 100644
--- a/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
+++ b/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
@@ -1,7 +1,7 @@
* ADF7242 IEEE 802.15.4 *
Required properties:
- - compatible: should be "adi,adf7242"
+ - compatible: should be "adi,adf7242", "adi,adf7241"
- spi-max-frequency: maximal bus speed (12.5 MHz)
- reg: the chipselect index
- interrupts: the interrupt generated by the device via pin IRQ1.
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index 400fdbd..56f4ca8 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -1,7 +1,7 @@
/*
* Analog Devices ADF7242 Low-Power IEEE 802.15.4 Transceiver
*
- * Copyright 2009-2015 Analog Devices Inc.
+ * Copyright 2009-2017 Analog Devices Inc.
*
* Licensed under the GPL-2 or later.
*
@@ -1257,12 +1257,14 @@ static int adf7242_remove(struct spi_device *spi)
static const struct of_device_id adf7242_of_match[] = {
{ .compatible = "adi,adf7242", },
+ { .compatible = "adi,adf7241", },
{ },
};
MODULE_DEVICE_TABLE(of, adf7242_of_match);
static const struct spi_device_id adf7242_device_id[] = {
{ .name = "adf7242", },
+ { .name = "adf7241", },
{ },
};
MODULE_DEVICE_TABLE(spi, adf7242_device_id);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] net: ieee802154: adf7242: Add additional DEBUG information
From: michael.hennerich @ 2017-11-28 12:53 UTC (permalink / raw)
To: alex.aring, stefan; +Cc: linux-wpan, Michael Hennerich
In-Reply-To: <1511873595-29238-1-git-send-email-michael.hennerich@analog.com>
From: Michael Hennerich <michael.hennerich@analog.com>
This adds missing status bits and improves the DEBUG prints.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
---
drivers/net/ieee802154/adf7242.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index a11948a..ce1a6d2 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -906,9 +906,12 @@ static void adf7242_debug(struct adf7242_local *lp, u8 irq1)
irq1 & IRQ_FRAME_VALID ? "IRQ_FRAME_VALID\n" : "",
irq1 & IRQ_ADDRESS_VALID ? "IRQ_ADDRESS_VALID\n" : "");
- dev_dbg(&lp->spi->dev, "%s STATUS = %X:\n%s\n%s%s%s%s%s\n",
+ dev_dbg(&lp->spi->dev, "%s STATUS = %X:\n%s\n%s\n%s\n%s\n%s%s%s%s%s\n",
__func__, stat,
+ stat & STAT_SPI_READY ? "SPI_READY" : "SPI_BUSY",
+ stat & STAT_IRQ_STATUS ? "IRQ_PENDING" : "IRQ_CLEAR",
stat & STAT_RC_READY ? "RC_READY" : "RC_BUSY",
+ stat & STAT_CCA_RESULT ? "CHAN_IDLE" : "CHAN_BUSY",
(stat & 0xf) == RC_STATUS_IDLE ? "RC_STATUS_IDLE" : "",
(stat & 0xf) == RC_STATUS_MEAS ? "RC_STATUS_MEAS" : "",
(stat & 0xf) == RC_STATUS_PHY_RDY ? "RC_STATUS_PHY_RDY" : "",
@@ -1086,8 +1089,11 @@ static int adf7242_stats_show(struct seq_file *file, void *offset)
irq1 & IRQ_FRAME_VALID ? "IRQ_FRAME_VALID\n" : "",
irq1 & IRQ_ADDRESS_VALID ? "IRQ_ADDRESS_VALID\n" : "");
- seq_printf(file, "STATUS = %X:\n%s\n%s%s%s%s%s\n", stat,
+ seq_printf(file, "STATUS = %X:\n%s\n%s\n%s\n%s\n%s%s%s%s%s\n", stat,
+ stat & STAT_SPI_READY ? "SPI_READY" : "SPI_BUSY",
+ stat & STAT_IRQ_STATUS ? "IRQ_PENDING" : "IRQ_CLEAR",
stat & STAT_RC_READY ? "RC_READY" : "RC_BUSY",
+ stat & STAT_CCA_RESULT ? "CHAN_IDLE" : "CHAN_BUSY",
(stat & 0xf) == RC_STATUS_IDLE ? "RC_STATUS_IDLE" : "",
(stat & 0xf) == RC_STATUS_MEAS ? "RC_STATUS_MEAS" : "",
(stat & 0xf) == RC_STATUS_PHY_RDY ? "RC_STATUS_PHY_RDY" : "",
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] net: ieee802154: adf7242: Avoid redundant RC_READY polling
From: michael.hennerich @ 2017-11-28 12:53 UTC (permalink / raw)
To: alex.aring, stefan; +Cc: linux-wpan, Michael Hennerich
In-Reply-To: <1511873595-29238-1-git-send-email-michael.hennerich@analog.com>
From: Michael Hennerich <michael.hennerich@analog.com>
READ/WRITE register and packet buffer can be done anytime as long
as SPI_READY. Only CMD transactions require RC_READY && SPI_READY.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
---
drivers/net/ieee802154/adf7242.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index ce1a6d2..548bec1 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -344,12 +344,18 @@ static int adf7242_wait_status(struct adf7242_local *lp, unsigned int status,
return ret;
}
-static int adf7242_wait_ready(struct adf7242_local *lp, int line)
+static int adf7242_wait_rc_ready(struct adf7242_local *lp, int line)
{
return adf7242_wait_status(lp, STAT_RC_READY | STAT_SPI_READY,
STAT_RC_READY | STAT_SPI_READY, line);
}
+static int adf7242_wait_spi_ready(struct adf7242_local *lp, int line)
+{
+ return adf7242_wait_status(lp, STAT_SPI_READY,
+ STAT_SPI_READY, line);
+}
+
static int adf7242_write_fbuf(struct adf7242_local *lp, u8 *data, u8 len)
{
u8 *buf = lp->buf;
@@ -369,7 +375,7 @@ static int adf7242_write_fbuf(struct adf7242_local *lp, u8 *data, u8 len)
spi_message_add_tail(&xfer_head, &msg);
spi_message_add_tail(&xfer_buf, &msg);
- adf7242_wait_ready(lp, __LINE__);
+ adf7242_wait_spi_ready(lp, __LINE__);
mutex_lock(&lp->bmux);
buf[0] = CMD_SPI_PKT_WR;
@@ -401,7 +407,7 @@ static int adf7242_read_fbuf(struct adf7242_local *lp,
spi_message_add_tail(&xfer_head, &msg);
spi_message_add_tail(&xfer_buf, &msg);
- adf7242_wait_ready(lp, __LINE__);
+ adf7242_wait_spi_ready(lp, __LINE__);
mutex_lock(&lp->bmux);
if (packet_read) {
@@ -432,7 +438,7 @@ static int adf7242_read_reg(struct adf7242_local *lp, u16 addr, u8 *data)
.rx_buf = lp->buf_read_rx,
};
- adf7242_wait_ready(lp, __LINE__);
+ adf7242_wait_spi_ready(lp, __LINE__);
mutex_lock(&lp->bmux);
lp->buf_read_tx[0] = CMD_SPI_MEM_RD(addr);
@@ -462,7 +468,7 @@ static int adf7242_write_reg(struct adf7242_local *lp, u16 addr, u8 data)
{
int status;
- adf7242_wait_ready(lp, __LINE__);
+ adf7242_wait_spi_ready(lp, __LINE__);
mutex_lock(&lp->bmux);
lp->buf_reg_tx[0] = CMD_SPI_MEM_WR(addr);
@@ -484,7 +490,7 @@ static int adf7242_cmd(struct adf7242_local *lp, unsigned int cmd)
dev_vdbg(&lp->spi->dev, "%s : CMD=0x%X\n", __func__, cmd);
if (cmd != CMD_RC_PC_RESET_NO_WAIT)
- adf7242_wait_ready(lp, __LINE__);
+ adf7242_wait_rc_ready(lp, __LINE__);
mutex_lock(&lp->bmux);
lp->buf_cmd = cmd;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] net: ieee802154: adf7242: Fix bug if defined DEBUG
From: michael.hennerich @ 2017-11-28 12:53 UTC (permalink / raw)
To: alex.aring, stefan; +Cc: linux-wpan, Michael Hennerich
In-Reply-To: <1511873595-29238-1-git-send-email-michael.hennerich@analog.com>
From: Michael Hennerich <michael.hennerich@analog.com>
This fixes undefined reference to struct adf7242_local *lp in
case DEBUG is defined.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
---
drivers/net/ieee802154/adf7242.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index 56f4ca8..a11948a 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -888,7 +888,7 @@ static const struct ieee802154_ops adf7242_ops = {
.set_cca_ed_level = adf7242_set_cca_ed_level,
};
-static void adf7242_debug(u8 irq1)
+static void adf7242_debug(struct adf7242_local *lp, u8 irq1)
{
#ifdef DEBUG
u8 stat;
@@ -932,7 +932,7 @@ static irqreturn_t adf7242_isr(int irq, void *data)
dev_err(&lp->spi->dev, "%s :ERROR IRQ1 = 0x%X\n",
__func__, irq1);
- adf7242_debug(irq1);
+ adf7242_debug(lp, irq1);
xmit = test_bit(FLAG_XMIT, &lp->flags);
--
2.7.4
^ permalink raw reply related
* [PATCH 5/5] net: ieee802154: adf7242: Rework IRQ and packet handling
From: michael.hennerich @ 2017-11-28 12:53 UTC (permalink / raw)
To: alex.aring, stefan; +Cc: linux-wpan, Michael Hennerich
In-Reply-To: <1511873595-29238-1-git-send-email-michael.hennerich@analog.com>
From: Michael Hennerich <michael.hennerich@analog.com>
* Stop unconditionally polling for RC_STATUS_PHY_RDY at the entry of
the threaded IRQ handler. Once IRQ_RX_PKT_RCVD is received we can
read immediately the packet from the buffer. However we still need
to wait afterwards for RC_STATUS_PHY_RDY, to make sure that the
ACK (in case requested) was processed and send out by the
Radio Controller, before we issue the next CMD_RC_RX.
This significantly reduces the overall time spend in the threaded
IRQ handler.
* Avoid raise condition between xmit and coincident packet reception,
by disabling the IRQ and clearing the IRQ status upon xmit entry.
* Introduce helper functions adf7242_clear_irqstat() and adf7242_cmd_rx()
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
---
drivers/net/ieee802154/adf7242.c | 54 +++++++++++++++++++++++++++++-----------
1 file changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index 548bec1..64f1b1e 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -563,6 +563,22 @@ static int adf7242_verify_firmware(struct adf7242_local *lp,
return 0;
}
+static void adf7242_clear_irqstat(struct adf7242_local *lp)
+{
+ adf7242_write_reg(lp, REG_IRQ1_SRC1, IRQ_CCA_COMPLETE | IRQ_SFD_RX |
+ IRQ_SFD_TX | IRQ_RX_PKT_RCVD | IRQ_TX_PKT_SENT |
+ IRQ_FRAME_VALID | IRQ_ADDRESS_VALID | IRQ_CSMA_CA);
+}
+
+static int adf7242_cmd_rx(struct adf7242_local *lp)
+{
+ /* Wait until the ACK is sent */
+ adf7242_wait_status(lp, RC_STATUS_PHY_RDY, RC_STATUS_MASK, __LINE__);
+ adf7242_clear_irqstat(lp);
+
+ return adf7242_cmd(lp, CMD_RC_RX);
+}
+
static int adf7242_set_txpower(struct ieee802154_hw *hw, int mbm)
{
struct adf7242_local *lp = hw->priv;
@@ -666,7 +682,7 @@ static int adf7242_start(struct ieee802154_hw *hw)
struct adf7242_local *lp = hw->priv;
adf7242_cmd(lp, CMD_RC_PHY_RDY);
- adf7242_write_reg(lp, REG_IRQ1_SRC1, 0xFF);
+ adf7242_clear_irqstat(lp);
enable_irq(lp->spi->irq);
set_bit(FLAG_START, &lp->flags);
@@ -677,10 +693,10 @@ static void adf7242_stop(struct ieee802154_hw *hw)
{
struct adf7242_local *lp = hw->priv;
+ disable_irq(lp->spi->irq);
adf7242_cmd(lp, CMD_RC_IDLE);
clear_bit(FLAG_START, &lp->flags);
- disable_irq(lp->spi->irq);
- adf7242_write_reg(lp, REG_IRQ1_SRC1, 0xFF);
+ adf7242_clear_irqstat(lp);
}
static int adf7242_channel(struct ieee802154_hw *hw, u8 page, u8 channel)
@@ -795,9 +811,12 @@ static int adf7242_xmit(struct ieee802154_hw *hw, struct sk_buff *skb)
struct adf7242_local *lp = hw->priv;
int ret;
+ /* ensure existing instances of the IRQ handler have completed */
+ disable_irq(lp->spi->irq);
set_bit(FLAG_XMIT, &lp->flags);
reinit_completion(&lp->tx_complete);
adf7242_cmd(lp, CMD_RC_PHY_RDY);
+ adf7242_clear_irqstat(lp);
ret = adf7242_write_fbuf(lp, skb->data, skb->len);
if (ret)
@@ -806,6 +825,7 @@ static int adf7242_xmit(struct ieee802154_hw *hw, struct sk_buff *skb)
ret = adf7242_cmd(lp, CMD_RC_CSMACA);
if (ret)
goto err;
+ enable_irq(lp->spi->irq);
ret = wait_for_completion_interruptible_timeout(&lp->tx_complete,
HZ / 10);
@@ -828,7 +848,7 @@ static int adf7242_xmit(struct ieee802154_hw *hw, struct sk_buff *skb)
err:
clear_bit(FLAG_XMIT, &lp->flags);
- adf7242_cmd(lp, CMD_RC_RX);
+ adf7242_cmd_rx(lp);
return ret;
}
@@ -852,7 +872,7 @@ static int adf7242_rx(struct adf7242_local *lp)
skb = dev_alloc_skb(len);
if (!skb) {
- adf7242_cmd(lp, CMD_RC_RX);
+ adf7242_cmd_rx(lp);
return -ENOMEM;
}
@@ -860,14 +880,14 @@ static int adf7242_rx(struct adf7242_local *lp)
ret = adf7242_read_fbuf(lp, data, len, true);
if (ret < 0) {
kfree_skb(skb);
- adf7242_cmd(lp, CMD_RC_RX);
+ adf7242_cmd_rx(lp);
return ret;
}
lqi = data[len - 2];
lp->rssi = data[len - 1];
- adf7242_cmd(lp, CMD_RC_RX);
+ ret = adf7242_cmd_rx(lp);
skb_trim(skb, len - 2); /* Don't put RSSI/LQI or CRC into the frame */
@@ -876,7 +896,7 @@ static int adf7242_rx(struct adf7242_local *lp)
dev_dbg(&lp->spi->dev, "%s: ret=%d len=%d lqi=%d rssi=%d\n",
__func__, ret, (int)len, (int)lqi, lp->rssi);
- return 0;
+ return ret;
}
static const struct ieee802154_ops adf7242_ops = {
@@ -932,10 +952,7 @@ static irqreturn_t adf7242_isr(int irq, void *data)
unsigned int xmit;
u8 irq1;
- adf7242_wait_status(lp, RC_STATUS_PHY_RDY, RC_STATUS_MASK, __LINE__);
-
adf7242_read_reg(lp, REG_IRQ1_SRC1, &irq1);
- adf7242_write_reg(lp, REG_IRQ1_SRC1, irq1);
if (!(irq1 & (IRQ_RX_PKT_RCVD | IRQ_CSMA_CA)))
dev_err(&lp->spi->dev, "%s :ERROR IRQ1 = 0x%X\n",
@@ -946,6 +963,9 @@ static irqreturn_t adf7242_isr(int irq, void *data)
xmit = test_bit(FLAG_XMIT, &lp->flags);
if (xmit && (irq1 & IRQ_CSMA_CA)) {
+ adf7242_wait_status(lp, RC_STATUS_PHY_RDY,
+ RC_STATUS_MASK, __LINE__);
+
if (ADF7242_REPORT_CSMA_CA_STAT) {
u8 astat;
@@ -966,6 +986,7 @@ static irqreturn_t adf7242_isr(int irq, void *data)
lp->tx_stat = SUCCESS;
}
complete(&lp->tx_complete);
+ adf7242_clear_irqstat(lp);
} else if (!xmit && (irq1 & IRQ_RX_PKT_RCVD) &&
(irq1 & IRQ_FRAME_VALID)) {
adf7242_rx(lp);
@@ -974,16 +995,19 @@ static irqreturn_t adf7242_isr(int irq, void *data)
dev_dbg(&lp->spi->dev, "%s:%d : ERROR IRQ1 = 0x%X\n",
__func__, __LINE__, irq1);
adf7242_cmd(lp, CMD_RC_PHY_RDY);
- adf7242_write_reg(lp, REG_IRQ1_SRC1, 0xFF);
- adf7242_cmd(lp, CMD_RC_RX);
+ adf7242_cmd_rx(lp);
} else {
/* This can only be xmit without IRQ, likely a RX packet.
* we get an TX IRQ shortly - do nothing or let the xmit
* timeout handle this
*/
+
dev_dbg(&lp->spi->dev, "%s:%d : ERROR IRQ1 = 0x%X, xmit %d\n",
__func__, __LINE__, irq1, xmit);
+ adf7242_wait_status(lp, RC_STATUS_PHY_RDY,
+ RC_STATUS_MASK, __LINE__);
complete(&lp->tx_complete);
+ adf7242_clear_irqstat(lp);
}
return IRQ_HANDLED;
@@ -1003,7 +1027,7 @@ static int adf7242_soft_reset(struct adf7242_local *lp, int line)
adf7242_set_promiscuous_mode(lp->hw, lp->promiscuous);
adf7242_set_csma_params(lp->hw, lp->min_be, lp->max_be,
lp->max_cca_retries);
- adf7242_write_reg(lp, REG_IRQ1_SRC1, 0xFF);
+ adf7242_clear_irqstat(lp);
if (test_bit(FLAG_START, &lp->flags)) {
enable_irq(lp->spi->irq);
@@ -1069,7 +1093,7 @@ static int adf7242_hw_init(struct adf7242_local *lp)
adf7242_write_reg(lp, REG_IRQ1_EN0, 0);
adf7242_write_reg(lp, REG_IRQ1_EN1, IRQ_RX_PKT_RCVD | IRQ_CSMA_CA);
- adf7242_write_reg(lp, REG_IRQ1_SRC1, 0xFF);
+ adf7242_clear_irqstat(lp);
adf7242_write_reg(lp, REG_IRQ1_SRC0, 0xFF);
adf7242_cmd(lp, CMD_RC_IDLE);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] doc: linux-wpan: Fulfill the description of missed 802.15.4 APIs
From: Stefan Schmidt @ 2017-11-29 16:04 UTC (permalink / raw)
To: Jian-Hong Pan, Alexander Aring, Jonathan Corbet, linux-wpan,
linux-doc
In-Reply-To: <20171118155501.14148-1-starnight@g.ncu.edu.tw>
Hello
On 11/18/2017 04:55 PM, Jian-Hong Pan wrote:
> There are more functions and operations which must be used or implemented
> in each IEEE 802.15.4 device driver, but are not mentioned in the Device
> drivers API section of Documentation/networking/ieee802154.txt. Therefore,
> I want to fulfill the missed part into the documentation with this patch.
>
> Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
> ---
> Documentation/networking/ieee802154.txt | 40 +++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
> diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
> index 057e9fdbfac9..e74d8e1da0e2 100644
> --- a/Documentation/networking/ieee802154.txt
> +++ b/Documentation/networking/ieee802154.txt
> @@ -97,6 +97,46 @@ The include/net/mac802154.h defines following functions:
> - void ieee802154_unregister_hw(struct ieee802154_hw *hw):
> freeing registered PHY
>
> + - void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb,
> + u8 lqi):
> + telling 802.15.4 module there is a new received frame in the skb with
> + the RF Link Quality Indicator (LQI) from the hardware device
> +
> + - void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb,
> + bool ifs_handling):
> + telling 802.15.4 module the frame in the skb is or going to be
> + transmitted through the hardware device
> +
> +The device driver must implement the following callbacks in the IEEE 802.15.4
> +operations structure at least:
> +struct ieee802154_ops {
> + ...
> + int (*start)(struct ieee802154_hw *hw);
> + void (*stop)(struct ieee802154_hw *hw);
> + ...
> + int (*xmit_async)(struct ieee802154_hw *hw, struct sk_buff *skb);
> + int (*ed)(struct ieee802154_hw *hw, u8 *level);
> + int (*set_channel)(struct ieee802154_hw *hw, u8 page, u8 channel);
> + ...
> +};
> +
> + - int start(struct ieee802154_hw *hw):
> + handler that 802.15.4 module calls for the hardware device initialization.
> +
> + - void stop(struct ieee802154_hw *hw):
> + handler that 802.15.4 module calls for the hardware device cleanup.
> +
> + - int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
> + handler that 802.15.4 module calls for each frame in the skb going to be
> + transmitted through the hardware device.
> +
> + - int ed(struct ieee802154_hw *hw, u8 *level):
> + handler that 802.15.4 module calls for Energy Detection from the hardware
> + device.
> +
> + - int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
> + set radio for listening on specific channel of the hardware device.
> +
> Moreover IEEE 802.15.4 device operations structure should be filled.
>
> Fake drivers
This patch has been applied to the wpan-next tree and will be
part of the next pull request to net-next. Thanks!
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH 1/5] net: ieee802154: adf7242: Add support for ADF7241 devices
From: Stefan Schmidt @ 2017-11-29 16:05 UTC (permalink / raw)
To: michael.hennerich, alex.aring; +Cc: linux-wpan
In-Reply-To: <1511873595-29238-1-git-send-email-michael.hennerich@analog.com>
Hello.
On 11/28/2017 01:53 PM, michael.hennerich@analog.com wrote:
> From: Michael Hennerich <michael.hennerich@analog.com>
>
> This adds support for ADF7241 Low Power IEEE 802.15.4
> Zero-IF 2.4 GHz Transceivers
>
> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
> ---
> Documentation/devicetree/bindings/net/ieee802154/adf7242.txt | 2 +-
> drivers/net/ieee802154/adf7242.c | 4 +++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt b/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
> index dea5124..d24172c 100644
> --- a/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
> +++ b/Documentation/devicetree/bindings/net/ieee802154/adf7242.txt
> @@ -1,7 +1,7 @@
> * ADF7242 IEEE 802.15.4 *
>
> Required properties:
> - - compatible: should be "adi,adf7242"
> + - compatible: should be "adi,adf7242", "adi,adf7241"
> - spi-max-frequency: maximal bus speed (12.5 MHz)
> - reg: the chipselect index
> - interrupts: the interrupt generated by the device via pin IRQ1.
> diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
> index 400fdbd..56f4ca8 100644
> --- a/drivers/net/ieee802154/adf7242.c
> +++ b/drivers/net/ieee802154/adf7242.c
> @@ -1,7 +1,7 @@
> /*
> * Analog Devices ADF7242 Low-Power IEEE 802.15.4 Transceiver
> *
> - * Copyright 2009-2015 Analog Devices Inc.
> + * Copyright 2009-2017 Analog Devices Inc.
> *
> * Licensed under the GPL-2 or later.
> *
> @@ -1257,12 +1257,14 @@ static int adf7242_remove(struct spi_device *spi)
>
> static const struct of_device_id adf7242_of_match[] = {
> { .compatible = "adi,adf7242", },
> + { .compatible = "adi,adf7241", },
> { },
> };
> MODULE_DEVICE_TABLE(of, adf7242_of_match);
>
> static const struct spi_device_id adf7242_device_id[] = {
> { .name = "adf7242", },
> + { .name = "adf7241", },
> { },
> };
> MODULE_DEVICE_TABLE(spi, adf7242_device_id);
All 5 patches have been applied to the wpan-next tree and will be
part of the next pull request to net-next. Thanks!
regards
Stefan Schmidt
^ permalink raw reply
* pull-request: ieee802154-next 2017-12-04
From: Stefan Schmidt @ 2017-12-04 16:51 UTC (permalink / raw)
To: davem; +Cc: linux-wpan, alex.aring, netdev
Hello Dave.
Some update from ieee802154 to *net-next*
Jian-Hong Pan updated our docs to match the APIs in code.
Michael Hennerichs enhanced the adf7242 driver to work with adf7241
devices and reworked the IRQ and packet handling in the driver.
The following changes since commit 1d3b78bbc6e983fabb3fbf91b76339bf66e4a12c:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-11-23 21:18:46 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git ieee802154-for-davem-2017-12-04
for you to fetch changes up to 8f1878a182dcc5a15a57c7fc7d8182bea0733dfa:
net: ieee802154: adf7242: Rework IRQ and packet handling (2017-11-29 16:49:41 +0100)
----------------------------------------------------------------
Jian-Hong Pan (1):
doc: linux-wpan: Fulfill the description of missed 802.15.4 APIs
Michael Hennerich (5):
net: ieee802154: adf7242: Add support for ADF7241 devices
net: ieee802154: adf7242: Fix bug if defined DEBUG
net: ieee802154: adf7242: Add additional DEBUG information
net: ieee802154: adf7242: Avoid redundant RC_READY polling
net: ieee802154: adf7242: Rework IRQ and packet handling
.../devicetree/bindings/net/ieee802154/adf7242.txt | 2 +-
Documentation/networking/ieee802154.txt | 40 ++++++++++
drivers/net/ieee802154/adf7242.c | 90 +++++++++++++++-------
3 files changed, 105 insertions(+), 27 deletions(-)
regards
Stefan Schmidt
^ permalink raw reply
* Re: pull-request: ieee802154-next 2017-12-04
From: David Miller @ 2017-12-05 19:45 UTC (permalink / raw)
To: stefan; +Cc: linux-wpan, alex.aring, netdev
In-Reply-To: <20171204165111.29240-1-stefan@osg.samsung.com>
From: Stefan Schmidt <stefan@osg.samsung.com>
Date: Mon, 4 Dec 2017 17:51:11 +0100
> Some update from ieee802154 to *net-next*
>
> Jian-Hong Pan updated our docs to match the APIs in code.
> Michael Hennerichs enhanced the adf7242 driver to work with adf7241
> devices and reworked the IRQ and packet handling in the driver.
Pulled, thanks.
^ permalink raw reply
* Business Possibility
From: Peter Deng @ 2018-01-04 16:14 UTC (permalink / raw)
To: linux-wpan
Hello there, My name is Peter Deng a South African citizen and a friend to Mrs Mugabe sister . I got your contact through Korean business online directory. I represent the interest of Mrs Mugabe who wishes to move a total amount of $19 million into a safe account owns by a trusted business man who is capable of accommodating such volume of funds with absolute trust & confidentiality.
We are willing to give 5-10 percent of the total money for this efforts . A non disclosure non circumvent agreement will be signed before the eventual transfer of funds. It is important for to know that the fund owner is going through a period of political turmoil and she is in a precarious position, so this transaction has to be highly secretive & very confidential.
Kindly respond back to me if this is what you can handle .
Regards,
Peter.
^ permalink raw reply
* reading RSSI value
From: anton @ 2018-01-21 12:24 UTC (permalink / raw)
To: linux-wpan
Hello
Is it possible to somehow read RSSI (Received Signal Strength indicator) value for each ieee802154 frame
received using raw socket? Quick grepping in kernel and wpan-tools sources says no, but just wanted to
confirm. Could energy detection level value used instead? Also, is it possible to set transmitter power
from userspace?
Thanks
Anton
^ permalink raw reply
* Re: reading RSSI value
From: Alexander Aring @ 2018-01-21 17:59 UTC (permalink / raw)
To: anton; +Cc: linux-wpan - ML
In-Reply-To: <20180121122454.GA24136@picapica.im>
Hi,
2018-01-21 7:24 GMT-05:00 <anton@picapica.im>:
> Hello
>
> Is it possible to somehow read RSSI (Received Signal Strength indicator) value for each ieee802154 frame
> received using raw socket? Quick grepping in kernel and wpan-tools sources says no, but just wanted to
One note about raw sockets: you should use AF_PACKET RAW as socket type.
The answer is no. A single RSSI value of a frame says nothing about
something... We want to collect them in kernelspace e.g. wireless
station dump and make some mapping from $NODE_ADDR (complicated
because short/extended mapping).
There exists some thesis branch on github which I did for my "thesis"
but not ready to bring upstream at all...
> confirm. Could energy detection level value used instead? Also, is it possible to set transmitter power
Also no energy detection and no LQI...
Transmit power is possible (depends on driver support), but not per frame...
- Alex
^ permalink raw reply
* Re: reading RSSI value
From: Alexander Aring @ 2018-01-22 19:02 UTC (permalink / raw)
To: anton; +Cc: linux-wpan - ML
In-Reply-To: <CAB_54W6mxa4f3Sy97psaYqYGf9Xp+7SY_imv91U=YK9y_-iMiQ@mail.gmail.com>
Hi,
2018-01-21 12:59 GMT-05:00 Alexander Aring <alex.aring@gmail.com>:
> Hi,
>
> 2018-01-21 7:24 GMT-05:00 <anton@picapica.im>:
>> Hello
>>
>> Is it possible to somehow read RSSI (Received Signal Strength indicator) value for each ieee802154 frame
>> received using raw socket? Quick grepping in kernel and wpan-tools sources says no, but just wanted to
>
> One note about raw sockets: you should use AF_PACKET RAW as socket type.
>
> The answer is no. A single RSSI value of a frame says nothing about
> something... We want to collect them in kernelspace e.g. wireless
> station dump and make some mapping from $NODE_ADDR (complicated
> because short/extended mapping).
> There exists some thesis branch on github which I did for my "thesis"
> but not ready to bring upstream at all...
>
>> confirm. Could energy detection level value used instead? Also, is it possible to set transmitter power
>
> Also no energy detection and no LQI...
>
> Transmit power is possible (depends on driver support), but not per frame...
>
got a new idea about to handle this per frame. Talked with one of the
TC maintainers today... I think it would be nice to have a TC action
where you can set a transmit power per classifier... not sure there
exists many way how to handle it. Also there was an idea according to
6lowpan to handle it per ndisc entry. :-/
If you really want to set it per frame. 802.11 people might be
interessted in the "wireless tx power TC action" as well...
- Alex
^ permalink raw reply
* Re: reading RSSI value
From: anton @ 2018-01-24 17:24 UTC (permalink / raw)
To: Alexander Aring; +Cc: linux-wpan
In-Reply-To: <CAB_54W5qcYR4oyqAUv0Bc2nCjEbKHSgzpRF4i2xtLsTHaNw=2Q@mail.gmail.com>
On Mon, Jan 22, 2018 at 02:02:09PM -0500, Alexander Aring wrote:
> Hi,
>
> 2018-01-21 12:59 GMT-05:00 Alexander Aring <alex.aring@gmail.com>:
> > Hi,
> >
> > 2018-01-21 7:24 GMT-05:00 <anton@picapica.im>:
> >> Hello
> >>
> >> Is it possible to somehow read RSSI (Received Signal Strength indicator) value for each ieee802154 frame
> >> received using raw socket? Quick grepping in kernel and wpan-tools sources says no, but just wanted to
> >
> > One note about raw sockets: you should use AF_PACKET RAW as socket type.
> >
> > The answer is no. A single RSSI value of a frame says nothing about
> > something... We want to collect them in kernelspace e.g. wireless
> > station dump and make some mapping from $NODE_ADDR (complicated
> > because short/extended mapping).
> > There exists some thesis branch on github which I did for my "thesis"
> > but not ready to bring upstream at all...
> >
> >> confirm. Could energy detection level value used instead? Also, is it possible to set transmitter power
> >
> > Also no energy detection and no LQI...
> >
> > Transmit power is possible (depends on driver support), but not per frame...
> >
>
> got a new idea about to handle this per frame. Talked with one of the
> TC maintainers today... I think it would be nice to have a TC action
> where you can set a transmit power per classifier... not sure there
> exists many way how to handle it. Also there was an idea according to
> 6lowpan to handle it per ndisc entry. :-/
>
> If you really want to set it per frame. 802.11 people might be
> interessted in the "wireless tx power TC action" as well...
>
> - Alex
But changing transmit power is possible in runtime, isn't it?
I mean, without bringing interface down/up. Or not?
Is it supported by at86rf230 driver for at86rf212 chip? It seems that yes
Anton
^ permalink raw reply
* Is at86rf230 a SoftMAC device driver?
From: anton @ 2018-01-24 17:29 UTC (permalink / raw)
To: linux-wpan
Or HardMac one?
Anton
^ permalink raw reply
* Re: reading RSSI value
From: Alexander Aring @ 2018-01-24 19:30 UTC (permalink / raw)
To: anton; +Cc: linux-wpan - ML
In-Reply-To: <20180124172434.GA5251@picapica.im>
Hi,
2018-01-24 12:24 GMT-05:00 <anton@picapica.im>:
> On Mon, Jan 22, 2018 at 02:02:09PM -0500, Alexander Aring wrote:
>> Hi,
>>
>> 2018-01-21 12:59 GMT-05:00 Alexander Aring <alex.aring@gmail.com>:
>> > Hi,
>> >
>> > 2018-01-21 7:24 GMT-05:00 <anton@picapica.im>:
>> >> Hello
>> >>
>> >> Is it possible to somehow read RSSI (Received Signal Strength indicator) value for each ieee802154 frame
>> >> received using raw socket? Quick grepping in kernel and wpan-tools sources says no, but just wanted to
>> >
>> > One note about raw sockets: you should use AF_PACKET RAW as socket type.
>> >
>> > The answer is no. A single RSSI value of a frame says nothing about
>> > something... We want to collect them in kernelspace e.g. wireless
>> > station dump and make some mapping from $NODE_ADDR (complicated
>> > because short/extended mapping).
>> > There exists some thesis branch on github which I did for my "thesis"
>> > but not ready to bring upstream at all...
>> >
>> >> confirm. Could energy detection level value used instead? Also, is it possible to set transmitter power
>> >
>> > Also no energy detection and no LQI...
>> >
>> > Transmit power is possible (depends on driver support), but not per frame...
>> >
>>
>> got a new idea about to handle this per frame. Talked with one of the
>> TC maintainers today... I think it would be nice to have a TC action
>> where you can set a transmit power per classifier... not sure there
>> exists many way how to handle it. Also there was an idea according to
>> 6lowpan to handle it per ndisc entry. :-/
>>
>> If you really want to set it per frame. 802.11 people might be
>> interessted in the "wireless tx power TC action" as well...
>>
>> - Alex
>
>
> But changing transmit power is possible in runtime, isn't it?
> I mean, without bringing interface down/up. Or not?
> Is it supported by at86rf230 driver for at86rf212 chip? It seems that yes
>
no, but this has only one reason currently why we allow this only on
ifdown... we need to set the txpower for next transmit. We don't do a
transmit power setting WHILE the transceiver is actually sending, this
ends mostly in some UNDEF behavior of transceivers (the vendors
doesn't say anything about that handling in datasheets and it sounds
fragile).
BUT this will not be solution to make in userspace something like:
set_power(x);
send_frame(....);
set_power(y);
send_frame(....);
Such use case can be done by some another ideas with sendmsg() CMSG OR
what I said before by a TC action.
- Alex
^ permalink raw reply
* Re: Is at86rf230 a SoftMAC device driver?
From: Alexander Aring @ 2018-01-24 19:32 UTC (permalink / raw)
To: anton; +Cc: linux-wpan - ML
In-Reply-To: <20180124172910.GA5472@picapica.im>
Hi,
2018-01-24 12:29 GMT-05:00 <anton@picapica.im>:
> Or HardMac one?
we don't support any HardMAC driver, the caFOO (don't remember) is
some HardMAC transceiver which use SoftMAC layer... I already
complained about that... anyway seems too much work for them to
program more HardMAC layer, we just accept it... but it's broken in
some cases (raw frame sendings) and we don't care when we add more
frametypes in SoftMAC handling.
- Alex
^ permalink raw reply
* wpan-tools 0.8 release
From: Stefan Schmidt @ 2018-02-01 10:29 UTC (permalink / raw)
To: linux-wpan@vger.kernel.org
Hello.
It is a pleasure to announce the 0.8 release of wpan-tools.
Thanks to everyone who contributed!
More of a maintenance release this time around. We did not have a release in a while and the build error with libnl >= 3.3 started to hit
more people. Having this fixed is worth a release alone. Thanks a lot to Thomas Petazzoni for the fix.
We also added some some examples on how to use the ieee802154 subsystem socket types from userspace.
Xue Wenqian added some more functionality to the wpan-ping utility. Mayn thanks here as well.
https://github.com/linux-wpan/wpan-tools/releases/download/wpan-tools-0.8/wpan-tools-0.8.tar.gz
sha256sum: 0e22cadbc40d4c12d0a66e8175bda12046f03237ce6da23d4fd26fd3ab557d8b
https://github.com/linux-wpan/wpan-tools/releases/download/wpan-tools-0.8/wpan-tools-0.8.tar.xz
sha256sum: daacd38fe2f216095664dbf2628151c8f632d3f122d526059a37ba3cc4d3d8af
Stefan Schmidt (9):
examples: add README with details to the various examples
examples: af_ieee802154_tx example
examples: af_ieee802154_rx example
examples: add af_packet_rx example
examples: af_inet6_rx example
examples: af_packet_tx example
examples: af_inet6_tx example
examples: add .gitignore file for examples directory
Release 0.8
Thomas Petazzoni (1):
src/nl_extras.h: fix compatibility with libnl 3.3.0
Xue Wenqian (2):
wpan-ping: add the support to set wpan-ping interval
wpan-ping: Add the filtering function for frame receiving
regards
Stefan Schmidt
^ permalink raw reply
* Re: wpan-tools 0.8 release
From: Alexander Aring @ 2018-02-01 16:15 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: linux-wpan@vger.kernel.org, Jamal Hadi Salim
In-Reply-To: <dea4d0e2-af43-1d46-2abe-ef947fa1298e@osg.samsung.com>
Hi,
On Thu, Feb 1, 2018 at 5:29 AM, Stefan Schmidt <stefan@osg.samsung.com> wrote:
> Hello.
>
>
> It is a pleasure to announce the 0.8 release of wpan-tools.
> Thanks to everyone who contributed!
>
> More of a maintenance release this time around. We did not have a release in a while and the build error with libnl >= 3.3 started to hit
> more people. Having this fixed is worth a release alone. Thanks a lot to Thomas Petazzoni for the fix.
>
> We also added some some examples on how to use the ieee802154 subsystem socket types from userspace.
> Xue Wenqian added some more functionality to the wpan-ping utility. Mayn thanks here as well.
>
> https://github.com/linux-wpan/wpan-tools/releases/download/wpan-tools-0.8/wpan-tools-0.8.tar.gz
>
> sha256sum: 0e22cadbc40d4c12d0a66e8175bda12046f03237ce6da23d4fd26fd3ab557d8b
>
> https://github.com/linux-wpan/wpan-tools/releases/download/wpan-tools-0.8/wpan-tools-0.8.tar.xz
>
> sha256sum: daacd38fe2f216095664dbf2628151c8f632d3f122d526059a37ba3cc4d3d8af
>
>
> Stefan Schmidt (9):
> examples: add README with details to the various examples
> examples: af_ieee802154_tx example
> examples: af_ieee802154_rx example
> examples: add af_packet_rx example
> examples: af_inet6_rx example
> examples: af_packet_tx example
> examples: af_inet6_tx example
> examples: add .gitignore file for examples directory
> Release 0.8
>
> Thomas Petazzoni (1):
> src/nl_extras.h: fix compatibility with libnl 3.3.0
>
> Xue Wenqian (2):
> wpan-ping: add the support to set wpan-ping interval
> wpan-ping: Add the filtering function for frame receiving
>
Thank you all. I know at the moment is some idle time... but I want to
make something this year again.
What I have laying around for container based mesh networking
simulation, I need that to tackle some issues with fragmentation
handling in 6LoWPAN...
Have some ideas for a special qdisc (and my current boss supports me
to develop it).
And another thing is the multiple pan handling with ack handling on
hardware (by slotted ackhandling on at86rf2xx transceivers).
I am recently moved into another country and my RPI/openthread
transceiver stuff is still in my old country... but I will have my
hardware this year.
Another thing would be too take a look into these IKEA lamps [0] and
check what's needed to talk with them? Somebody knows if they using
2.4 Ghz ISM? If so then it would be easy to sniff traffic...
So far I know they use 802.154. and some "ZigBee" e.g. Phillips Hue
(and phillips hue use 2.4 Ghz, I was able to see traffic once).
- Alex
[0] http://www.ikea.com/ca/en/catalog/categories/departments/lighting/36812/
^ permalink raw reply
* Re: wpan-tools 0.8 release
From: Stefan Schmidt @ 2018-02-02 8:36 UTC (permalink / raw)
To: Alexander Aring; +Cc: linux-wpan@vger.kernel.org, Jamal Hadi Salim
In-Reply-To: <CAOHTApicFHO=26DmaCnmux1KXqwfgR1DEZ7An2VFs5vRYp=aPw@mail.gmail.com>
Hello.
On 02/01/2018 05:15 PM, Alexander Aring wrote:
> Hi,
>
> On Thu, Feb 1, 2018 at 5:29 AM, Stefan Schmidt <stefan@osg.samsung.com> wrote:
>> Hello.
>>
>>
>> It is a pleasure to announce the 0.8 release of wpan-tools.
>> Thanks to everyone who contributed!
>>
>> More of a maintenance release this time around. We did not have a release in a while and the build error with libnl >= 3.3 started to hit
>> more people. Having this fixed is worth a release alone. Thanks a lot to Thomas Petazzoni for the fix.
>>
>> We also added some some examples on how to use the ieee802154 subsystem socket types from userspace.
>> Xue Wenqian added some more functionality to the wpan-ping utility. Mayn thanks here as well.
>>
>> https://github.com/linux-wpan/wpan-tools/releases/download/wpan-tools-0.8/wpan-tools-0.8.tar.gz
>>
>> sha256sum: 0e22cadbc40d4c12d0a66e8175bda12046f03237ce6da23d4fd26fd3ab557d8b
>>
>> https://github.com/linux-wpan/wpan-tools/releases/download/wpan-tools-0.8/wpan-tools-0.8.tar.xz
>>
>> sha256sum: daacd38fe2f216095664dbf2628151c8f632d3f122d526059a37ba3cc4d3d8af
>>
>>
>> Stefan Schmidt (9):
>> examples: add README with details to the various examples
>> examples: af_ieee802154_tx example
>> examples: af_ieee802154_rx example
>> examples: add af_packet_rx example
>> examples: af_inet6_rx example
>> examples: af_packet_tx example
>> examples: af_inet6_tx example
>> examples: add .gitignore file for examples directory
>> Release 0.8
>>
>> Thomas Petazzoni (1):
>> src/nl_extras.h: fix compatibility with libnl 3.3.0
>>
>> Xue Wenqian (2):
>> wpan-ping: add the support to set wpan-ping interval
>> wpan-ping: Add the filtering function for frame receiving
>>
> Thank you all. I know at the moment is some idle time... but I want to
> make something this year again.
> What I have laying around for container based mesh networking
> simulation, I need that to tackle some issues with fragmentation
> handling in 6LoWPAN...
> Have some ideas for a special qdisc (and my current boss supports me
> to develop it).
Looking forward to this.
> And another thing is the multiple pan handling with ack handling on
> hardware (by slotted ackhandling on at86rf2xx transceivers).
> I am recently moved into another country and my RPI/openthread
> transceiver stuff is still in my old country... but I will have my
> hardware this year.
>
> Another thing would be too take a look into these IKEA lamps [0] and
> check what's needed to talk with them? Somebody knows if they using
> 2.4 Ghz ISM? If so then it would be easy to sniff traffic...
> So far I know they use 802.154. and some "ZigBee" e.g. Phillips Hue
> (and phillips hue use 2.4 Ghz, I was able to see traffic once).
I got myself on IKEA set with lamp and motion detector. Its 2.4 GHz and one can easily sniff it.
Its using the Zigbee lighting protocol and has encrypted traffic (IIRC there was some chatter that the ZLL key was known).
This is where I stopped to to time constraints. Getting a way to talk to the IKEA devices would be nice.
regards
Stefan Schmidt
^ permalink raw reply
* [PATCH 0/3] ieee802154: Add support for NXP MCR20A
From: Xue Liu @ 2018-02-03 20:51 UTC (permalink / raw)
To: linux-wpan
This patchset adds a new device driver, documentation and build support for
NXP's MCR20A IEEE 802.15.4 radio transceiver:
https://www.nxp.com/products/wireless-connectivity/thread/2.4-ghz-802.15.4-wireless-transceiver:MCR20A
Xue Liu (3):
ieee802154: Add device tree documentation for MCR20A
ieee802154: Add entry in MAINTAINTERS for MCR20a driver
ieee802154: Add MCR20A IEEE 802.15.4 device driver
.../devicetree/bindings/net/ieee802154/mcr20a.txt | 23 +
MAINTAINERS | 8 +
drivers/net/ieee802154/Kconfig | 11 +
drivers/net/ieee802154/Makefile | 1 +
drivers/net/ieee802154/mcr20a.c | 1482 ++++++++++++++++++++
drivers/net/ieee802154/mcr20a.h | 498 +++++++
6 files changed, 2023 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/ieee802154/mcr20a.txt
create mode 100644 drivers/net/ieee802154/mcr20a.c
create mode 100644 drivers/net/ieee802154/mcr20a.h
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] ieee802154: Add device tree documentation for MCR20A
From: Xue Liu @ 2018-02-03 20:51 UTC (permalink / raw)
To: linux-wpan
In-Reply-To: <1517691074-20306-1-git-send-email-liuxuenetmail@gmail.com>
Signed-off-by: Xue Liu <liuxuenetmail@gmail.com>
---
.../devicetree/bindings/net/ieee802154/mcr20a.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/ieee802154/mcr20a.txt
diff --git a/Documentation/devicetree/bindings/net/ieee802154/mcr20a.txt b/Documentation/devicetree/bindings/net/ieee802154/mcr20a.txt
new file mode 100644
index 0000000..9a39769
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ieee802154/mcr20a.txt
@@ -0,0 +1,23 @@
+* MCR20A IEEE 802.15.4 *
+
+Required properties:
+ - compatible: should be "nxp,mcr20a"
+ - spi-max-frequency: maximal bus speed, should be set to a frequency
+ lower than 9000000 depends sync or async operation mode
+ - reg: the chipselect index
+ - interrupts: the interrupt generated by the device. Non high-level
+ can occur deadlocks while handling isr.
+
+Optional properties:
+ - rst_b-gpio: GPIO spec for the RST_B pin
+
+Example:
+
+ mcr20a@0 {
+ compatible = "nxp,mcr20a";
+ spi-max-frequency = <9000000>;
+ reg = <0>;
+ interrupts = <17 2>;
+ interrupt-parent = <&gpio>;
+ rst_b-gpio = <&gpio 27 1>
+ };
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox