[GIT PULL 0/3] IEEE 802.15.4 last-minute fixes v2

[GIT PULL 0/3] IEEE 802.15.4 last-minute fixes v2

[Dmitry Eremin-Solenikov]

Please pull several minor fixes for the IEEE 802.15.4 stack.

The following changes since commit db71789c01ae7b641f83c5aa64e7df25122f4b28:
  David S. Miller (1):
        xfrm6: Fix xfrm6_policy.c build when SYSCTL disabled.

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git for-linus

Dmitry Eremin-Solenikov (3):
      af_ieee802154: fix ioctl processing
      af_ieee802154: provide dummy get/setsockopt
      documentation: fix wrt. headers rename

 Documentation/networking/ieee802154.txt |    9 ++++-----
 net/ieee802154/af_ieee802154.c          |    8 +++++---
 net/ieee802154/dgram.c                  |   14 ++++++++++++++
 net/ieee802154/raw.c                    |   14 ++++++++++++++
 4 files changed, 37 insertions(+), 8 deletions(-)

-- 
With best wishes
Dmitry Eremin-Solenikov

[PATCH 1/3] af_ieee802154: fix ioctl processing

[Dmitry Eremin-Solenikov]

fix two errors in ioctl processing:
1) if the ioctl isn't supported one should return -ENOIOCTLCMD
2) don't call ndo_do_ioctl if the device doesn't provide it

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
 net/ieee802154/af_ieee802154.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/ieee802154/af_ieee802154.c b/net/ieee802154/af_ieee802154.c
index 69c8d92..d504c34 100644
--- a/net/ieee802154/af_ieee802154.c
+++ b/net/ieee802154/af_ieee802154.c
@@ -136,7 +136,7 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
 		unsigned int cmd)
 {
 	struct ifreq ifr;
-	int ret = -EINVAL;
+	int ret = -ENOIOCTLCMD;
 	struct net_device *dev;
 
 	if (copy_from_user(&ifr, arg, sizeof(struct ifreq)))
@@ -146,8 +146,10 @@ static int ieee802154_dev_ioctl(struct sock *sk, struct ifreq __user *arg,
 
 	dev_load(sock_net(sk), ifr.ifr_name);
 	dev = dev_get_by_name(sock_net(sk), ifr.ifr_name);
-	if (dev->type == ARPHRD_IEEE802154 ||
-	    dev->type == ARPHRD_IEEE802154_PHY)
+
+	if ((dev->type == ARPHRD_IEEE802154 ||
+	     dev->type == ARPHRD_IEEE802154_PHY) &&
+	    dev->netdev_ops->ndo_do_ioctl)
 		ret = dev->netdev_ops->ndo_do_ioctl(dev, &ifr, cmd);
 
 	if (!ret && copy_to_user(arg, &ifr, sizeof(struct ifreq)))
-- 
1.6.3.3

[PATCH 2/3] af_ieee802154: provide dummy get/setsockopt

[Dmitry Eremin-Solenikov]

Provide dummt get/setsockopt implementations to stop these
syscalls from oopsing on our sockets.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
 net/ieee802154/dgram.c |   14 ++++++++++++++
 net/ieee802154/raw.c   |   14 ++++++++++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 53dd912..d1da6c6 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -377,6 +377,18 @@ int ieee802154_dgram_deliver(struct net_device *dev, struct sk_buff *skb)
 	return ret;
 }
 
+static int dgram_getsockopt(struct sock *sk, int level, int optname,
+		    char __user *optval, int __user *optlen)
+{
+	return -EOPNOTSUPP;
+}
+
+static int dgram_setsockopt(struct sock *sk, int level, int optname,
+		    char __user *optval, int __user optlen)
+{
+	return -EOPNOTSUPP;
+}
+
 struct proto ieee802154_dgram_prot = {
 	.name		= "IEEE-802.15.4-MAC",
 	.owner		= THIS_MODULE,
@@ -391,5 +403,7 @@ struct proto ieee802154_dgram_prot = {
 	.connect	= dgram_connect,
 	.disconnect	= dgram_disconnect,
 	.ioctl		= dgram_ioctl,
+	.getsockopt	= dgram_getsockopt,
+	.setsockopt	= dgram_setsockopt,
 };
 
diff --git a/net/ieee802154/raw.c b/net/ieee802154/raw.c
index ea8d1f1..60dee69 100644
--- a/net/ieee802154/raw.c
+++ b/net/ieee802154/raw.c
@@ -238,6 +238,18 @@ void ieee802154_raw_deliver(struct net_device *dev, struct sk_buff *skb)
 	read_unlock(&raw_lock);
 }
 
+static int raw_getsockopt(struct sock *sk, int level, int optname,
+		    char __user *optval, int __user *optlen)
+{
+	return -EOPNOTSUPP;
+}
+
+static int raw_setsockopt(struct sock *sk, int level, int optname,
+		    char __user *optval, int __user optlen)
+{
+	return -EOPNOTSUPP;
+}
+
 struct proto ieee802154_raw_prot = {
 	.name		= "IEEE-802.15.4-RAW",
 	.owner		= THIS_MODULE,
@@ -250,5 +262,7 @@ struct proto ieee802154_raw_prot = {
 	.unhash		= raw_unhash,
 	.connect	= raw_connect,
 	.disconnect	= raw_disconnect,
+	.getsockopt	= raw_getsockopt,
+	.setsockopt	= raw_setsockopt,
 };
 
-- 
1.6.3.3

[PATCH 3/3] documentation: fix wrt. headers rename

[Dmitry Eremin-Solenikov]

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
 Documentation/networking/ieee802154.txt |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 1d4ed66..1c0c82c 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -22,7 +22,7 @@ int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
 .....
 
 The address family, socket addresses etc. are defined in the
-include/net/ieee802154/af_ieee802154.h header or in the special header
+include/net/af_ieee802154.h header or in the special header
 in our userspace package (see either linux-zigbee sourceforge download page
 or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee).
 
@@ -33,7 +33,7 @@ MLME - MAC Level Management
 ============================
 
 Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.
-See the include/net/ieee802154/nl802154.h header. Our userspace tools package
+See the include/net/nl802154.h header. Our userspace tools package
 (see above) provides CLI configuration utility for radio interfaces and simple
 coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.
 
@@ -54,7 +54,7 @@ Those types of devices require different approach to be hooked into Linux kernel
 HardMAC
 =======
 
-See the header include/net/ieee802154/netdevice.h. You have to implement Linux
+See the header include/net/ieee802154_netdev.h. You have to implement Linux
 net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
 code via plain sk_buffs. The control block of sk_buffs will contain additional
 info as described in the struct ieee802154_mac_cb.
@@ -72,5 +72,4 @@ SoftMAC
 We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
 in software. This is currently WIP.
 
-See header include/net/ieee802154/mac802154.h and several drivers in
-drivers/ieee802154/
+See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
-- 
1.6.3.3

Re: [PATCH 3/3] documentation: fix wrt. headers rename

[David Miller]

From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Wed,  5 Aug 2009 11:28:17 +0400

> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>

What are you generating these patches against?

> @@ -72,5 +72,4 @@ SoftMAC
>  We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
>  in software. This is currently WIP.
>  
> -See header include/net/ieee802154/mac802154.h and several drivers in
> -drivers/ieee802154/
> +See header include/net/mac802154.h and several drivers in drivers/ieee802154/.

In net-2.6, and in Linus's tree as well, that first sentence quoted has
a typo, "implementing" is misspelled, but in whatever you're patching
against the misspelling is fixed.

Looking at your pull request:

--------------------
The following changes since commit db71789c01ae7b641f83c5aa64e7df25122f4b28:
  David S. Miller (1):
        xfrm6: Fix xfrm6_policy.c build when SYSCTL disabled.
--------------------

You're submitting these for net-next-2.6?  Didn't we just go back and
forth about trimming this patch series down to only pure bug fixes so
that they could go into net-2.6?  Given that, why are you generating
this stuff against net-next-2.6?

I'm tossing this entire series again, this is beyond frustrating.

Re: [PATCH 3/3] documentation: fix wrt. headers rename

[Dmitry Eremin-Solenikov]

On Wed, Aug 05, 2009 at 08:22:26PM -0700, David Miller wrote:
> From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Date: Wed,  5 Aug 2009 11:28:17 +0400
> 
> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> 
> What are you generating these patches against?
> 
> > @@ -72,5 +72,4 @@ SoftMAC
> >  We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
> >  in software. This is currently WIP.
> >  
> > -See header include/net/ieee802154/mac802154.h and several drivers in
> > -drivers/ieee802154/
> > +See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
> 
> In net-2.6, and in Linus's tree as well, that first sentence quoted has
> a typo, "implementing" is misspelled, but in whatever you're patching
> against the misspelling is fixed.
> 
> Looking at your pull request:
> 
> --------------------
> The following changes since commit db71789c01ae7b641f83c5aa64e7df25122f4b28:
>   David S. Miller (1):
>         xfrm6: Fix xfrm6_policy.c build when SYSCTL disabled.
> --------------------
> 
> You're submitting these for net-next-2.6?  Didn't we just go back and
> forth about trimming this patch series down to only pure bug fixes so
> that they could go into net-2.6?  Given that, why are you generating
> this stuff against net-next-2.6?

Damn. It seems I missed the difference between net-next-2.6 and net-2.6.

BTW: how should I differentiate my poll requests for net-next-2.6 and
for net-2.6 ?

-- 
With best wishes
Dmitry

Re: [PATCH 3/3] documentation: fix wrt. headers rename

[David Miller]

From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Thu, 6 Aug 2009 13:26:17 +0400

> BTW: how should I differentiate my poll requests for net-next-2.6 and
> for net-2.6 ?

Like the rest of the world by indicating the target tree in your
subject lines.  As long as it's in those initial [] brackets,
the automated GIT tools strip it all out when applying patches.

Don't you see other patch posters putting things like "[NEXT ...]" and
"[net-2.6 ...]" and "[net-next-2.6 ...]" in their subjects?

Re: [PATCH 2/3] af_ieee802154: provide dummy get/setsockopt

[David Miller]

From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Wed,  5 Aug 2009 11:28:16 +0400

> Provide dummt get/setsockopt implementations to stop these
> syscalls from oopsing on our sockets.
> 
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>

See "sock_no_getsockopt()" and "sock_no_setsockopt()" which are
provided specifically for this situation.

Re: [PATCH 2/3] af_ieee802154: provide dummy get/setsockopt

[Dmitry Eremin-Solenikov]

On Wed, Aug 05, 2009 at 12:17:14PM -0700, David Miller wrote:
> From: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Wed,  5 Aug 2009 11:28:16 +0400
> 
> > Provide dummt get/setsockopt implementations to stop these
> > syscalls from oopsing on our sockets.
> > 
> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> See "sock_no_getsockopt()" and "sock_no_setsockopt()" which are
> provided specifically for this situation.

There functions are to be used in struct proto_ops and not in the
struct proto. I'd like to use sock_common_get/setsockopt() from the
beginning, as there will be sockopts at least for dgram protocols.

If you say so, I can, of course, replace this patch with the one you
suggested. However I really don't see a point in doing this.

-- 
With best wishes
Dmitry


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Re: [PATCH 2/3] af_ieee802154: provide dummy get/setsockopt

[David Miller]

From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Thu, 6 Aug 2009 01:41:39 +0400

> On Wed, Aug 05, 2009 at 12:17:14PM -0700, David Miller wrote:
>> From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> Date: Wed,  5 Aug 2009 11:28:16 +0400
>> 
>> > Provide dummt get/setsockopt implementations to stop these
>> > syscalls from oopsing on our sockets.
>> > 
>> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> 
>> See "sock_no_getsockopt()" and "sock_no_setsockopt()" which are
>> provided specifically for this situation.
> 
> There functions are to be used in struct proto_ops and not in the
> struct proto. I'd like to use sock_common_get/setsockopt() from the
> beginning, as there will be sockopts at least for dgram protocols.

Ok, my bad.  The patch is fine.