changes since v1:
- changes in commit messages and descriptions suggested by Alan Ott
Varka Bhadram (3):
mrf24j40: fix Missing a blank line after declarations
mrf24j40: remove unnecessary return statement
mrf24j40: use pr_* / dev_* instead of printk()
drivers/net/ieee802154/mrf24j40.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--
1.7.9.5
On 09/19/2014 03:18 PM, Alexander Aring wrote:
> On Fri, Sep 19, 2014 at 03:14:11PM +0530, Varka Bhadram wrote:
>> On 09/19/2014 03:11 PM, Alexander Aring wrote:
>>> On Fri, Sep 19, 2014 at 03:01:32PM +0530, Varka Bhadram wrote:
>>>> Hi Alex,
>>>>
>>>> On 09/19/2014 02:36 PM, Alexander Aring wrote:
>>>>> Hi Varka,
>>>>>
>>>>> nice to read you again. :-) I already thought that I was maybe a little
>>>>> bit too harsh to you for explaining changing dev->add_len during runtime
>>>>> will occur in unexcept behaviour. Sorry.
>>>> For dev->addr_len, i think David asked a question.. Isn't it..?
>>>>
>>> yes, I didn't answer. I decide now to put this issue at the last item of
>>> my todo queue. If you like you can try it. I will answer him that I do
>>> other things right now and this issue is more complex.
>>>
>>>
>>> Also you did the cc2520 driver, you can add you as maintainer for this
>>> driver. I have such devices here but on contiki nodes.
>>>
>> You mean to say that i need to add an entry in MAINTAINER file or ..?
>>
> not need, only if you like. I have no idea about the cc2520 driver.
>
> If there cames patches in, I can only look for syntax and according
> interaction with mac802154 stack.
Ya.. I can be maintainer for CC2520 driver.
I will look into the cc2520 driver patches.
Thanks
--
Regards,
Varka Bhadram.
On Fri, Sep 19, 2014 at 03:14:11PM +0530, Varka Bhadram wrote:
> On 09/19/2014 03:11 PM, Alexander Aring wrote:
> >On Fri, Sep 19, 2014 at 03:01:32PM +0530, Varka Bhadram wrote:
> >>Hi Alex,
> >>
> >>On 09/19/2014 02:36 PM, Alexander Aring wrote:
> >>>Hi Varka,
> >>>
> >>>nice to read you again. :-) I already thought that I was maybe a little
> >>>bit too harsh to you for explaining changing dev->add_len during runtime
> >>>will occur in unexcept behaviour. Sorry.
> >>For dev->addr_len, i think David asked a question.. Isn't it..?
> >>
> >yes, I didn't answer. I decide now to put this issue at the last item of
> >my todo queue. If you like you can try it. I will answer him that I do
> >other things right now and this issue is more complex.
> >
> >
> >Also you did the cc2520 driver, you can add you as maintainer for this
> >driver. I have such devices here but on contiki nodes.
> >
> You mean to say that i need to add an entry in MAINTAINER file or ..?
>
not need, only if you like. I have no idea about the cc2520 driver.
If there cames patches in, I can only look for syntax and according
interaction with mac802154 stack.
- Alex
On 09/19/2014 03:11 PM, Alexander Aring wrote:
> On Fri, Sep 19, 2014 at 03:01:32PM +0530, Varka Bhadram wrote:
>> Hi Alex,
>>
>> On 09/19/2014 02:36 PM, Alexander Aring wrote:
>>> Hi Varka,
>>>
>>> nice to read you again. :-) I already thought that I was maybe a little
>>> bit too harsh to you for explaining changing dev->add_len during runtime
>>> will occur in unexcept behaviour. Sorry.
>> For dev->addr_len, i think David asked a question.. Isn't it..?
>>
> yes, I didn't answer. I decide now to put this issue at the last item of
> my todo queue. If you like you can try it. I will answer him that I do
> other things right now and this issue is more complex.
>
>
> Also you did the cc2520 driver, you can add you as maintainer for this
> driver. I have such devices here but on contiki nodes.
>
You mean to say that i need to add an entry in MAINTAINER file or ..?
--
Regards,
Varka Bhadram.
On Fri, Sep 19, 2014 at 03:01:32PM +0530, Varka Bhadram wrote:
> Hi Alex,
>
> On 09/19/2014 02:36 PM, Alexander Aring wrote:
> >Hi Varka,
> >
> >nice to read you again. :-) I already thought that I was maybe a little
> >bit too harsh to you for explaining changing dev->add_len during runtime
> >will occur in unexcept behaviour. Sorry.
>
> For dev->addr_len, i think David asked a question.. Isn't it..?
>
yes, I didn't answer. I decide now to put this issue at the last item of
my todo queue. If you like you can try it. I will answer him that I do
other things right now and this issue is more complex.
Also you did the cc2520 driver, you can add you as maintainer for this
driver. I have such devices here but on contiki nodes.
> We need to find a way to add this. Based on this only RFC6775 is going to
> work.
>
> But i implemented RFC6775 it works for Extended addresses only. I used the
> system
> witch use extended address.
>
ok.
> >Nevertheless welcome back. I want to apply it when Alan finally sends a
> >"Acked-by: ...", but why is this tagged with bluetooth-next?
>
> I am also waiting for Alan "Acked-by:..." :-)
>
> >There are other mrf24j40 patches around and it's better to send this in
> >a whole patch series when all patches are on wpan-next/testing. Then I
> >will send these patches to bluetooth-next. When applied I will rebase
> >the wpan-next/master to bluetooth-next/master.
>
> Ok. I got your point. Thanks... I will respin this series with wpan-next
> tag...
>
> >Only 6LOWPAN GENERIC patches should be send to bluetooth-next.
>
> Ok.
>
> We are having multiple branches on wpan-next tree.
> I want to know which branch is for what,..?
>
master. Should easy to use git cherry-pick here, it should have the same
implementation for linux-wpan-next (802.15.4 branch only) like
linux-bluetooth-next (802.15.4 branch only).
You know, we already talked about how to decreasing workload of other
maintainers. This will decrease the workload of bluetooth maintainers.
- Alex
Hi Alex,
On 09/19/2014 02:36 PM, Alexander Aring wrote:
> Hi Varka,
>
> nice to read you again. :-) I already thought that I was maybe a little
> bit too harsh to you for explaining changing dev->add_len during runtime
> will occur in unexcept behaviour. Sorry.
For dev->addr_len, i think David asked a question.. Isn't it..?
We need to find a way to add this. Based on this only RFC6775 is going
to work.
But i implemented RFC6775 it works for Extended addresses only. I used
the system
witch use extended address.
> Nevertheless welcome back. I want to apply it when Alan finally sends a
> "Acked-by: ...", but why is this tagged with bluetooth-next?
I am also waiting for Alan "Acked-by:..." :-)
> There are other mrf24j40 patches around and it's better to send this in
> a whole patch series when all patches are on wpan-next/testing. Then I
> will send these patches to bluetooth-next. When applied I will rebase
> the wpan-next/master to bluetooth-next/master.
Ok. I got your point. Thanks... I will respin this series with wpan-next
tag...
> Only 6LOWPAN GENERIC patches should be send to bluetooth-next.
Ok.
We are having multiple branches on wpan-next tree.
I want to know which branch is for what,..?
wpan-next/alex/wip
wpan-next/for-martin
wpan-next/for-michael
wpan-next/master
wpan-next/nhc_layer
wpan-next/tcheneau
wpan-next/testing
wpan-next/wpan_rework_rfc
--
Thanks and Regards,
Varka Bhadram.
Hi Varka,
nice to read you again. :-) I already thought that I was maybe a little
bit too harsh to you for explaining changing dev->add_len during runtime
will occur in unexcept behaviour. Sorry.
Nevertheless welcome back. I want to apply it when Alan finally sends a
"Acked-by: ...", but why is this tagged with bluetooth-next?
There are other mrf24j40 patches around and it's better to send this in
a whole patch series when all patches are on wpan-next/testing. Then I
will send these patches to bluetooth-next. When applied I will rebase
the wpan-next/master to bluetooth-next/master.
Only 6LOWPAN GENERIC patches should be send to bluetooth-next.
- Alex
Replace printk() with dev_*() pr_*()
Signed-off-by: Varka Bhadram <[email protected]>
---
drivers/net/ieee802154/mrf24j40.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
index 2c617e3..c7f638c 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -323,8 +323,8 @@ static int mrf24j40_read_rx_buf(struct mrf24j40 *devrec,
#ifdef DEBUG
print_hex_dump(KERN_DEBUG, "mrf24j40 rx: ",
DUMP_PREFIX_OFFSET, 16, 1, data, *len, 0);
- printk(KERN_DEBUG "mrf24j40 rx: lqi: %02hhx rssi: %02hhx\n",
- lqi_rssi[0], lqi_rssi[1]);
+ pr_debug("mrf24j40 rx: lqi: %02hhx rssi: %02hhx\n",
+ lqi_rssi[0], lqi_rssi[1]);
#endif
out:
@@ -385,7 +385,7 @@ err:
static int mrf24j40_ed(struct ieee802154_dev *dev, u8 *level)
{
/* TODO: */
- printk(KERN_WARNING "mrf24j40: ed not implemented\n");
+ pr_warn("mrf24j40: ed not implemented\n");
*level = 0;
return 0;
}
@@ -481,12 +481,11 @@ static int mrf24j40_filter(struct ieee802154_dev *dev,
memcpy(addr, &filt->ieee_addr, 8);
for (i = 0; i < 8; i++)
write_short_reg(devrec, REG_EADR0 + i, addr[i]);
-
#ifdef DEBUG
- printk(KERN_DEBUG "Set long addr to: ");
+ pr_debug("Set long addr to: ");
for (i = 0; i < 8; i++)
- printk("%02hhx ", addr[7 - i]);
- printk(KERN_DEBUG "\n");
+ pr_debug("%02hhx ", addr[7 - i]);
+ pr_debug("\n");
#endif
}
@@ -702,7 +701,7 @@ static int mrf24j40_probe(struct spi_device *spi)
int ret = -ENOMEM;
struct mrf24j40 *devrec;
- printk(KERN_INFO "mrf24j40: probe(). IRQ: %d\n", spi->irq);
+ dev_info(&spi->dev, "probe(). IRQ: %d\n", spi->irq);
devrec = devm_kzalloc(&spi->dev, sizeof(struct mrf24j40), GFP_KERNEL);
if (!devrec)
--
1.7.9.5
Remove the return statement in the void function.
Signed-off-by: Varka Bhadram <[email protected]>
---
drivers/net/ieee802154/mrf24j40.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
index 466da57..2c617e3 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -420,8 +420,6 @@ static void mrf24j40_stop(struct ieee802154_dev *dev)
return;
val |= 0x1|0x8; /* Set TXNIE and RXIE. Disable Interrupts */
write_short_reg(devrec, REG_INTCON, val);
-
- return;
}
static int mrf24j40_set_channel(struct ieee802154_dev *dev,
--
1.7.9.5
Signed-off-by: Varka Bhadram <[email protected]>
---
drivers/net/ieee802154/mrf24j40.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
index 9e6a124..466da57 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -412,6 +412,7 @@ static void mrf24j40_stop(struct ieee802154_dev *dev)
struct mrf24j40 *devrec = dev->priv;
u8 val;
int ret;
+
dev_dbg(printdev(devrec), "stop\n");
ret = read_short_reg(devrec, REG_INTCON, &val);
@@ -465,6 +466,7 @@ static int mrf24j40_filter(struct ieee802154_dev *dev,
if (changed & IEEE802515_AFILT_SADDR_CHANGED) {
/* Short Addr */
u8 addrh, addrl;
+
addrh = le16_to_cpu(filt->short_addr) >> 8 & 0xff;
addrl = le16_to_cpu(filt->short_addr) & 0xff;
@@ -493,6 +495,7 @@ static int mrf24j40_filter(struct ieee802154_dev *dev,
if (changed & IEEE802515_AFILT_PANID_CHANGED) {
/* PAN ID */
u8 panidl, panidh;
+
panidh = le16_to_cpu(filt->pan_id) >> 8 & 0xff;
panidl = le16_to_cpu(filt->pan_id) & 0xff;
write_short_reg(devrec, REG_PANIDH, panidh);
--
1.7.9.5