[PATCH wpan-next v5 00/11] ieee802154: Associations between devices

[PATCH wpan-next v5 00/11] ieee802154: Associations between devices

[Miquel Raynal]

Hello,

Now that we can discover our peer coordinators or make ourselves
dynamically discoverable, we may use the information about surrounding
devices to create PANs dynamically. This involves of course:
* Requesting an association to a coordinator, waiting for the response
* Sending a disassociation notification to a coordinator
* Receiving an association request when we are coordinator, answering
  the request (for now all devices are accepted up to a limit, to be
  refined)
* Sending a disassociation notification to a child
* Users may request the list of associated devices (the parent and the
  children).

Here are a few example of userspace calls that can be made:
iwpan dev <dev> associate pan_id 2 coord $COORD
iwpan dev <dev> list_associations
iwpan dev <dev> disassociate ext_addr $COORD

I used a small using hwsim to scan for a coordinator, associate with
it, look at the associations on both sides, disassociate from it and
check the associations again:
./assoc-demo
*** Scan ***
PAN 0x0002 (on wpan1)
	coordinator 0x060f3b35169a498f
	page 0
	channel 13
	preamble code 0
	mean prf 0
	superframe spec. 0xcf11
	LQI ff
*** End of scan ***
Associating wpan1 with coord0 0x060f3b35169a498f...
Dumping coord0 assoc:
child : 0x0b6f / 0xba7633ae47ccfb21
Dumping wpan1 assoc:
parent: 0xffff / 0x060f3b35169a498f
Disassociating from wpan1
Dumping coord0 assoc:
Dumping wpan1 assoc:

I could also successfully interact with a smaller device running Zephir,
using its command line interface to associate and then disassociate from
the Linux coordinator.

Thanks!
Miquèl

Changes in v5:
* Fixed (again) the helper supposed to check whether a device requesting
  association/disassociation is already (or not) in our PAN. We don't
  nee to check short addresses there.
* Changed the name of the helper a second time to make it more relevant
  and understandable:
  cfg802154_device_in_pan() -> cfg802154_pan_device_is_matching()
* Fixed a kernel test robot report where we would use an int instead of
  a __le16. Solved that by using cpu_to_le16 like in the other places
  where we use definitions as arguments.

Changes in v4:
* Ensured any disassociation would only be processed if the destination
  pan ID matches ours.
* Association requests should be made using extended addressing, it's
  the specification, so ensure this is true. Doing so helps reducing the
  checks down the road.
* Updated a copyright from 2021 to 2023.
* Improved the comment for cfg802154_device_in_pan() and only accept
  extended addressing when using this internal function because there is
  no point in checking short addresses here.
* Move nl802154_prepare_wpan_dev_dump() and
  nl802154_finish_wpan_dev_dump() outside of a
  CONFIG_IEEE802154_NL802154_EXPERIMENTAL #ifdef bloc as now used in
  regular code (not only experimental).
* Added a missing return value in the kernel doc of
  cfg802154_device_is_associated().

Changes in v3:
* Clarify a helper which compares if two devices seem to be identical by
  adding two comments. This is a static function that is only used by
  the PAN management core to operate or not an
  association/disassociation request. In this helper, a new check is
  introduced to be sure we compare fields which have been populated.
* Dropped the "association_generation" counter and all its uses along
  the code. I tried to mimic some other counter but I agree it is not
  super useful and could be dropped anyway.
* Dropped a faulty sequence number hardcoded to 10. This had no impact
  because a few lines later the same entry was set to a valid value.

Changes in v2:
* Drop the misleading IEEE802154_ADDR_LONG_BROADCAST definition and its
  only use which was useless anyway.
* Clarified how devices are defined when the user requests to associate
  with a coordinator: for now only the extended address of the
  coordinator is relevant so this is the only address we care about.
* Drop a useless NULL check before a kfree() call.
* Add a check when allocating a child short address: it must be
  different than ours.
* Rebased on top of v6.5.


Miquel Raynal (11):
  ieee802154: Let PAN IDs be reset
  ieee802154: Internal PAN management
  ieee802154: Add support for user association requests
  mac802154: Handle associating
  ieee802154: Add support for user disassociation requests
  mac802154: Handle disassociations
  mac802154: Handle association requests from peers
  ieee802154: Add support for limiting the number of associated devices
  mac802154: Follow the number of associated devices
  mac802154: Handle disassociation notifications from peers
  ieee802154: Give the user the association list

 include/net/cfg802154.h         |  70 ++++++
 include/net/ieee802154_netdev.h |  60 +++++
 include/net/nl802154.h          |  22 +-
 net/ieee802154/Makefile         |   2 +-
 net/ieee802154/core.c           |  24 ++
 net/ieee802154/nl802154.c       | 225 +++++++++++++++++-
 net/ieee802154/pan.c            | 103 +++++++++
 net/ieee802154/rdev-ops.h       |  30 +++
 net/ieee802154/trace.h          |  38 +++
 net/mac802154/cfg.c             | 170 ++++++++++++++
 net/mac802154/ieee802154_i.h    |  27 +++
 net/mac802154/main.c            |   2 +
 net/mac802154/rx.c              |  25 ++
 net/mac802154/scan.c            | 397 ++++++++++++++++++++++++++++++++
 14 files changed, 1180 insertions(+), 15 deletions(-)
 create mode 100644 net/ieee802154/pan.c

-- 
2.34.1

[PATCH wpan-next v5 01/11] ieee802154: Let PAN IDs be reset

[Miquel Raynal]

Soon association and disassociation will be implemented, which will
require to be able to either change the PAN ID from 0xFFFF to a real
value when association succeeded, or to reset the PAN ID to 0xFFFF upon
disassociation. Let's allow to do that manually for now.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 net/ieee802154/nl802154.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index d610c1886160..46ac6f599fe1 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1087,16 +1087,6 @@ static int nl802154_set_pan_id(struct sk_buff *skb, struct genl_info *info)
 
 	pan_id = nla_get_le16(info->attrs[NL802154_ATTR_PAN_ID]);
 
-	/* TODO
-	 * I am not sure about to check here on broadcast pan_id.
-	 * Broadcast is a valid setting, comment from 802.15.4:
-	 * If this value is 0xffff, the device is not associated.
-	 *
-	 * This could useful to simple deassociate an device.
-	 */
-	if (pan_id == cpu_to_le16(IEEE802154_PAN_ID_BROADCAST))
-		return -EINVAL;
-
 	return rdev_set_pan_id(rdev, wpan_dev, pan_id);
 }
 
-- 
2.34.1

[PATCH wpan-next v5 02/11] ieee802154: Internal PAN management

[Miquel Raynal]

Introduce structures to describe peer devices in a PAN as well as a few
related helpers. We basically care about:
- Our unique parent after associating with a coordinator.
- Peer devices, children, which successfully associated with us.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/net/cfg802154.h | 47 ++++++++++++++++++++++++++++++
 net/ieee802154/Makefile |  2 +-
 net/ieee802154/core.c   |  2 ++
 net/ieee802154/pan.c    | 63 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 113 insertions(+), 1 deletion(-)
 create mode 100644 net/ieee802154/pan.c

diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index f79ce133e51a..a89f1c9cea3f 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -303,6 +303,22 @@ struct ieee802154_coord_desc {
 	bool gts_permit;
 };
 
+/**
+ * struct ieee802154_pan_device - PAN device information
+ * @pan_id: the PAN ID of this device
+ * @mode: the preferred mode to reach the device
+ * @short_addr: the short address of this device
+ * @extended_addr: the extended address of this device
+ * @node: the list node
+ */
+struct ieee802154_pan_device {
+	__le16 pan_id;
+	u8 mode;
+	__le16 short_addr;
+	__le64 extended_addr;
+	struct list_head node;
+};
+
 /**
  * struct cfg802154_scan_request - Scan request
  *
@@ -478,6 +494,11 @@ struct wpan_dev {
 
 	/* fallback for acknowledgment bit setting */
 	bool ackreq;
+
+	/* Associations */
+	struct mutex association_lock;
+	struct ieee802154_pan_device *parent;
+	struct list_head children;
 };
 
 #define to_phy(_dev)	container_of(_dev, struct wpan_phy, dev)
@@ -529,4 +550,30 @@ static inline const char *wpan_phy_name(struct wpan_phy *phy)
 void ieee802154_configure_durations(struct wpan_phy *phy,
 				    unsigned int page, unsigned int channel);
 
+/**
+ * cfg802154_device_is_associated - Checks whether we are associated to any device
+ * @wpan_dev: the wpan device
+ * @return: true if we are associated
+ */
+bool cfg802154_device_is_associated(struct wpan_dev *wpan_dev);
+
+/**
+ * cfg802154_device_is_parent - Checks if a device is our coordinator
+ * @wpan_dev: the wpan device
+ * @target: the expected parent
+ * @return: true if @target is our coordinator
+ */
+bool cfg802154_device_is_parent(struct wpan_dev *wpan_dev,
+				struct ieee802154_addr *target);
+
+/**
+ * cfg802154_device_is_child - Checks whether a device is associated to us
+ * @wpan_dev: the wpan device
+ * @target: the expected child
+ * @return: the PAN device
+ */
+struct ieee802154_pan_device *
+cfg802154_device_is_child(struct wpan_dev *wpan_dev,
+			  struct ieee802154_addr *target);
+
 #endif /* __NET_CFG802154_H */
diff --git a/net/ieee802154/Makefile b/net/ieee802154/Makefile
index f05b7bdae2aa..7bce67673e83 100644
--- a/net/ieee802154/Makefile
+++ b/net/ieee802154/Makefile
@@ -4,7 +4,7 @@ obj-$(CONFIG_IEEE802154_SOCKET) += ieee802154_socket.o
 obj-y += 6lowpan/
 
 ieee802154-y := netlink.o nl-mac.o nl-phy.o nl_policy.o core.o \
-                header_ops.o sysfs.o nl802154.o trace.o
+                header_ops.o sysfs.o nl802154.o trace.o pan.o
 ieee802154_socket-y := socket.o
 
 CFLAGS_trace.o := -I$(src)
diff --git a/net/ieee802154/core.c b/net/ieee802154/core.c
index 57546e07e06a..cd69bdbfd59f 100644
--- a/net/ieee802154/core.c
+++ b/net/ieee802154/core.c
@@ -276,6 +276,8 @@ static int cfg802154_netdev_notifier_call(struct notifier_block *nb,
 		wpan_dev->identifier = ++rdev->wpan_dev_id;
 		list_add_rcu(&wpan_dev->list, &rdev->wpan_dev_list);
 		rdev->devlist_generation++;
+		mutex_init(&wpan_dev->association_lock);
+		INIT_LIST_HEAD(&wpan_dev->children);
 
 		wpan_dev->netdev = dev;
 		break;
diff --git a/net/ieee802154/pan.c b/net/ieee802154/pan.c
new file mode 100644
index 000000000000..2b30e7b19ac3
--- /dev/null
+++ b/net/ieee802154/pan.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * IEEE 802.15.4 PAN management
+ *
+ * Copyright (C) 2023 Qorvo US, Inc
+ * Authors:
+ *   - David Girault <david.girault@qorvo.com>
+ *   - Miquel Raynal <miquel.raynal@bootlin.com>
+ */
+
+#include <linux/kernel.h>
+#include <net/cfg802154.h>
+#include <net/af_ieee802154.h>
+
+/* Checks whether a device address matches one from the PAN list.
+ * This helper is meant to be used only during PAN management, when we expect
+ * extended addresses to be used.
+ */
+static bool cfg802154_pan_device_is_matching(struct ieee802154_pan_device *pan_dev,
+					     struct ieee802154_addr *ext_dev)
+{
+	if (!pan_dev || !ext_dev)
+		return false;
+
+	if (ext_dev->mode == IEEE802154_ADDR_SHORT)
+		return false;
+
+	return pan_dev->extended_addr == ext_dev->extended_addr;
+}
+
+bool cfg802154_device_is_associated(struct wpan_dev *wpan_dev)
+{
+	bool is_assoc;
+
+	mutex_lock(&wpan_dev->association_lock);
+	is_assoc = !list_empty(&wpan_dev->children) || wpan_dev->parent;
+	mutex_unlock(&wpan_dev->association_lock);
+
+	return is_assoc;
+}
+
+bool cfg802154_device_is_parent(struct wpan_dev *wpan_dev,
+				struct ieee802154_addr *target)
+{
+	lockdep_assert_held(&wpan_dev->association_lock);
+
+	return cfg802154_pan_device_is_matching(wpan_dev->parent, target);
+}
+
+struct ieee802154_pan_device *
+cfg802154_device_is_child(struct wpan_dev *wpan_dev,
+			  struct ieee802154_addr *target)
+{
+	struct ieee802154_pan_device *child;
+
+	lockdep_assert_held(&wpan_dev->association_lock);
+
+	list_for_each_entry(child, &wpan_dev->children, node)
+		if (cfg802154_pan_device_is_matching(child, target))
+			return child;
+
+	return NULL;
+}
-- 
2.34.1

Re: [PATCH wpan-next v5 00/11] ieee802154: Associations between devices

[Miquel Raynal]

Hello,

Send e-mail failed in the middle of the operation because of
connectivity issues, I'll resend the full thread later. Please ignore
this.

Sorry for the noise,
Miquèl

miquel.raynal@bootlin.com wrote on Wed, 27 Sep 2023
18:47:03 +0200:

> Hello,
> 
> Now that we can discover our peer coordinators or make ourselves
> dynamically discoverable, we may use the information about surrounding
> devices to create PANs dynamically. This involves of course:
> * Requesting an association to a coordinator, waiting for the response
> * Sending a disassociation notification to a coordinator
> * Receiving an association request when we are coordinator, answering
>   the request (for now all devices are accepted up to a limit, to be
>   refined)
> * Sending a disassociation notification to a child
> * Users may request the list of associated devices (the parent and the
>   children).
> 
> Here are a few example of userspace calls that can be made:
> iwpan dev <dev> associate pan_id 2 coord $COORD
> iwpan dev <dev> list_associations
> iwpan dev <dev> disassociate ext_addr $COORD
> 
> I used a small using hwsim to scan for a coordinator, associate with
> it, look at the associations on both sides, disassociate from it and
> check the associations again:
> ./assoc-demo
> *** Scan ***
> PAN 0x0002 (on wpan1)
> 	coordinator 0x060f3b35169a498f
> 	page 0
> 	channel 13
> 	preamble code 0
> 	mean prf 0
> 	superframe spec. 0xcf11
> 	LQI ff
> *** End of scan ***
> Associating wpan1 with coord0 0x060f3b35169a498f...
> Dumping coord0 assoc:
> child : 0x0b6f / 0xba7633ae47ccfb21
> Dumping wpan1 assoc:
> parent: 0xffff / 0x060f3b35169a498f
> Disassociating from wpan1
> Dumping coord0 assoc:
> Dumping wpan1 assoc:
> 
> I could also successfully interact with a smaller device running Zephir,
> using its command line interface to associate and then disassociate from
> the Linux coordinator.
> 
> Thanks!
> Miquèl
> 
> Changes in v5:
> * Fixed (again) the helper supposed to check whether a device requesting
>   association/disassociation is already (or not) in our PAN. We don't
>   nee to check short addresses there.
> * Changed the name of the helper a second time to make it more relevant
>   and understandable:
>   cfg802154_device_in_pan() -> cfg802154_pan_device_is_matching()
> * Fixed a kernel test robot report where we would use an int instead of
>   a __le16. Solved that by using cpu_to_le16 like in the other places
>   where we use definitions as arguments.
> 
> Changes in v4:
> * Ensured any disassociation would only be processed if the destination
>   pan ID matches ours.
> * Association requests should be made using extended addressing, it's
>   the specification, so ensure this is true. Doing so helps reducing the
>   checks down the road.
> * Updated a copyright from 2021 to 2023.
> * Improved the comment for cfg802154_device_in_pan() and only accept
>   extended addressing when using this internal function because there is
>   no point in checking short addresses here.
> * Move nl802154_prepare_wpan_dev_dump() and
>   nl802154_finish_wpan_dev_dump() outside of a
>   CONFIG_IEEE802154_NL802154_EXPERIMENTAL #ifdef bloc as now used in
>   regular code (not only experimental).
> * Added a missing return value in the kernel doc of
>   cfg802154_device_is_associated().
> 
> Changes in v3:
> * Clarify a helper which compares if two devices seem to be identical by
>   adding two comments. This is a static function that is only used by
>   the PAN management core to operate or not an
>   association/disassociation request. In this helper, a new check is
>   introduced to be sure we compare fields which have been populated.
> * Dropped the "association_generation" counter and all its uses along
>   the code. I tried to mimic some other counter but I agree it is not
>   super useful and could be dropped anyway.
> * Dropped a faulty sequence number hardcoded to 10. This had no impact
>   because a few lines later the same entry was set to a valid value.
> 
> Changes in v2:
> * Drop the misleading IEEE802154_ADDR_LONG_BROADCAST definition and its
>   only use which was useless anyway.
> * Clarified how devices are defined when the user requests to associate
>   with a coordinator: for now only the extended address of the
>   coordinator is relevant so this is the only address we care about.
> * Drop a useless NULL check before a kfree() call.
> * Add a check when allocating a child short address: it must be
>   different than ours.
> * Rebased on top of v6.5.
> 
> 
> Miquel Raynal (11):
>   ieee802154: Let PAN IDs be reset
>   ieee802154: Internal PAN management
>   ieee802154: Add support for user association requests
>   mac802154: Handle associating
>   ieee802154: Add support for user disassociation requests
>   mac802154: Handle disassociations
>   mac802154: Handle association requests from peers
>   ieee802154: Add support for limiting the number of associated devices
>   mac802154: Follow the number of associated devices
>   mac802154: Handle disassociation notifications from peers
>   ieee802154: Give the user the association list
> 
>  include/net/cfg802154.h         |  70 ++++++
>  include/net/ieee802154_netdev.h |  60 +++++
>  include/net/nl802154.h          |  22 +-
>  net/ieee802154/Makefile         |   2 +-
>  net/ieee802154/core.c           |  24 ++
>  net/ieee802154/nl802154.c       | 225 +++++++++++++++++-
>  net/ieee802154/pan.c            | 103 +++++++++
>  net/ieee802154/rdev-ops.h       |  30 +++
>  net/ieee802154/trace.h          |  38 +++
>  net/mac802154/cfg.c             | 170 ++++++++++++++
>  net/mac802154/ieee802154_i.h    |  27 +++
>  net/mac802154/main.c            |   2 +
>  net/mac802154/rx.c              |  25 ++
>  net/mac802154/scan.c            | 397 ++++++++++++++++++++++++++++++++
>  14 files changed, 1180 insertions(+), 15 deletions(-)
>  create mode 100644 net/ieee802154/pan.c
> 

Re: [PATCH wpan-next v5 01/11] ieee802154: Let PAN IDs be reset

[Miquel Raynal]

Hi Stefan,

stefan@datenfreihafen.org wrote on Thu, 7 Dec 2023 21:27:59 +0100:

> Hello Miquel,
> 
> 
> On 20.11.23 12:01, Miquel Raynal wrote:
> > On Wed, 2023-09-27 at 18:12:04 UTC, Miquel Raynal wrote:  
> >> Soon association and disassociation will be implemented, which will
> >> require to be able to either change the PAN ID from 0xFFFF to a real
> >> value when association succeeded, or to reset the PAN ID to 0xFFFF upon
> >> disassociation. Let's allow to do that manually for now.
> >>
> >> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>  
> > 
> > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next.git staging.  
> 
> I can't see this, or any other patch from the series, in the staging branch. Did you forget to push this out to kernel.org?

While preparing the PR for net maintainers I realized that in the above
message I actually pushed on the wpan repo instead of the wpan-next repo
by mistake. This explain why you didn't see it on the
wpan-next/[staging|master] branches. I've fixed my mess hopefully, and
will anyway send the PR today as the patches have been in -next for a
week or more already.

Thanks,
Miquèl

Re: [PATCH wpan-next v5 01/11] ieee802154: Let PAN IDs be reset

[Miquel Raynal]

Hi Stefan,

stefan@datenfreihafen.org wrote on Thu, 7 Dec 2023 21:27:59 +0100:

> Hello Miquel,
> 
> 
> On 20.11.23 12:01, Miquel Raynal wrote:
> > On Wed, 2023-09-27 at 18:12:04 UTC, Miquel Raynal wrote:  
> >> Soon association and disassociation will be implemented, which will
> >> require to be able to either change the PAN ID from 0xFFFF to a real
> >> value when association succeeded, or to reset the PAN ID to 0xFFFF upon
> >> disassociation. Let's allow to do that manually for now.
> >>
> >> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>  
> > 
> > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next.git staging.  
> 
> I can't see this, or any other patch from the series, in the staging branch. Did you forget to push this out to kernel.org?

Oh! Thanks for spotting this, I actually pushed the branch (otherwise
the hook would not have sent these messages) but the push operation
apparently failed at some point so the tip of the branch was not
updated. This is now fixed.

Thanks for the reviews by the way.

Miquèl

Re: [PATCH wpan-next v5 01/11] ieee802154: Let PAN IDs be reset

[Stefan Schmidt]

Hello Miquel,


On 20.11.23 12:01, Miquel Raynal wrote:
> On Wed, 2023-09-27 at 18:12:04 UTC, Miquel Raynal wrote:
>> Soon association and disassociation will be implemented, which will
>> require to be able to either change the PAN ID from 0xFFFF to a real
>> value when association succeeded, or to reset the PAN ID to 0xFFFF upon
>> disassociation. Let's allow to do that manually for now.
>>
>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> 
> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next.git staging.

I can't see this, or any other patch from the series, in the staging 
branch. Did you forget to push this out to kernel.org?

regards
Stefan Schmidt

Re: [PATCH wpan-next v5 01/11] ieee802154: Let PAN IDs be reset

[Miquel Raynal]

On Wed, 2023-09-27 at 18:12:04 UTC, Miquel Raynal wrote:
> Soon association and disassociation will be implemented, which will
> require to be able to either change the PAN ID from 0xFFFF to a real
> value when association succeeded, or to reset the PAN ID to 0xFFFF upon
> disassociation. Let's allow to do that manually for now.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next.git staging.

Miquel

[PATCH wpan-next v5 01/11] ieee802154: Let PAN IDs be reset

[Miquel Raynal]

Soon association and disassociation will be implemented, which will
require to be able to either change the PAN ID from 0xFFFF to a real
value when association succeeded, or to reset the PAN ID to 0xFFFF upon
disassociation. Let's allow to do that manually for now.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 net/ieee802154/nl802154.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index d610c1886160..46ac6f599fe1 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1087,16 +1087,6 @@ static int nl802154_set_pan_id(struct sk_buff *skb, struct genl_info *info)
 
 	pan_id = nla_get_le16(info->attrs[NL802154_ATTR_PAN_ID]);
 
-	/* TODO
-	 * I am not sure about to check here on broadcast pan_id.
-	 * Broadcast is a valid setting, comment from 802.15.4:
-	 * If this value is 0xffff, the device is not associated.
-	 *
-	 * This could useful to simple deassociate an device.
-	 */
-	if (pan_id == cpu_to_le16(IEEE802154_PAN_ID_BROADCAST))
-		return -EINVAL;
-
 	return rdev_set_pan_id(rdev, wpan_dev, pan_id);
 }
 
-- 
2.34.1