[PATCH bluetooth-next v2 0/3] cleanup for mrf24j40 driver

[PATCH bluetooth-next v2 0/3] cleanup for mrf24j40 driver

[Varka Bhadram]

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

[PATCH bluetooth-next v2 1/3] mrf24j40: fix Missing a blank line after declarations

[Varka Bhadram]

Signed-off-by: Varka Bhadram <varkab@cdac.in>
---
 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

[PATCH bluetooth-next v2 2/3] mrf24j40: remove unnecessary return statement

[Varka Bhadram]

Remove the return statement in the void function.

Signed-off-by: Varka Bhadram <varkab@cdac.in>
---
 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

[PATCH bluetooth-next v2 3/3] mrf24j40: use pr_* / dev_* instead of printk()

[Varka Bhadram]

Replace printk() with dev_*() pr_*()

Signed-off-by: Varka Bhadram <varkab@cdac.in>
---
 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

Re: [PATCH bluetooth-next v2 0/3] cleanup for mrf24j40 driver

[Alexander Aring]

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

Re: [PATCH bluetooth-next v2 0/3] cleanup for mrf24j40 driver

[Varka Bhadram]

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.

Re: [PATCH bluetooth-next v2 0/3] cleanup for mrf24j40 driver

[Alexander Aring]

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

Re: [PATCH bluetooth-next v2 0/3] cleanup for mrf24j40 driver

[Varka Bhadram]

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.

Re: [PATCH bluetooth-next v2 0/3] cleanup for mrf24j40 driver

[Alexander Aring]

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

Re: [PATCH bluetooth-next v2 0/3] cleanup for mrf24j40 driver

[Varka Bhadram]

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.