Re: pull-request: ieee802154 for net 2024-09-27
Hello Jakub, On 10/3/24 02:08, Jakub Kicinski wrote: On Fri, 27 Sep 2024 11:43:50 +0200 Stefan Schmidt wrote: Jinjie Ruan added the use of IRQF_NO_AUTOEN in the mcr20a driver and fixed and addiotinal build dependency problem while doing so. Jiawei Ye, ensured a correct RCU handling in mac802154_scan_worker. Sorry for the delay, conferences and travel.. No worries, just wanted to make sure it did not got lost. regards Stefan Schmidt
Re: pull-request: ieee802154 for net 2024-09-27
Hello, On 9/27/24 11:43, Stefan Schmidt wrote: Hello Dave, Jakub, Paolo. An update from ieee802154 for your *net* tree: Jinjie Ruan added the use of IRQF_NO_AUTOEN in the mcr20a driver and fixed and addiotinal build dependency problem while doing so. Jiawei Ye, ensured a correct RCU handling in mac802154_scan_worker. regards Stefan Schmidt The following changes since commit b8ec0dc3845f6c9089573cb5c2c4b05f7fc10728: net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD() (2024-06-03 11:20:56 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan.git tags/ieee802154-for-net-2024-09-27 for you to fetch changes up to 09573b1cc76e7ff8f056ab29ea1cdc152ec8c653: net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq() (2024-09-27 10:47:53 +0200) Jiawei Ye (1): mac802154: Fix potential RCU dereference issue in mac802154_scan_worker Jinjie Ruan (2): ieee802154: Fix build error net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq() drivers/net/ieee802154/Kconfig | 1 + drivers/net/ieee802154/mcr20a.c | 5 + net/mac802154/scan.c| 4 +++- 3 files changed, 5 insertions(+), 5 deletions(-) A friendly ping on this. :-) regards Stefan Schmidt
pull-request: ieee802154 for net 2024-09-27
Hello Dave, Jakub, Paolo. An update from ieee802154 for your *net* tree: Jinjie Ruan added the use of IRQF_NO_AUTOEN in the mcr20a driver and fixed and addiotinal build dependency problem while doing so. Jiawei Ye, ensured a correct RCU handling in mac802154_scan_worker. regards Stefan Schmidt The following changes since commit b8ec0dc3845f6c9089573cb5c2c4b05f7fc10728: net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD() (2024-06-03 11:20:56 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan.git tags/ieee802154-for-net-2024-09-27 for you to fetch changes up to 09573b1cc76e7ff8f056ab29ea1cdc152ec8c653: net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq() (2024-09-27 10:47:53 +0200) Jiawei Ye (1): mac802154: Fix potential RCU dereference issue in mac802154_scan_worker Jinjie Ruan (2): ieee802154: Fix build error net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq() drivers/net/ieee802154/Kconfig | 1 + drivers/net/ieee802154/mcr20a.c | 5 + net/mac802154/scan.c| 4 +++- 3 files changed, 5 insertions(+), 5 deletions(-)
Re: [PATCH v3] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker
Hello Jiawei Ye. On Tue, 24 Sep 2024 06:58:05 +, Jiawei Ye wrote: > In the `mac802154_scan_worker` function, the `scan_req->type` field was > accessed after the RCU read-side critical section was unlocked. According > to RCU usage rules, this is illegal and can lead to unpredictable > behavior, such as accessing memory that has been updated or causing > use-after-free issues. > > This possible bug was identified using a static analysis tool developed > by myself, specifically designed to detect RCU-related issues. > > [...] Applied to wpan/wpan.git, thanks! [1/1] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker https://git.kernel.org/wpan/wpan/c/bff1709b3980 regards, Stefan Schmidt
Re: [PATCH v2] mac802154: Fix potential RCU dereference issue in mac802154_scan_worker
Hello.
On 9/21/24 07:22, Jiawei Ye wrote:
Hi Miquèl,
I'm sorry for the accidental email sent while testing my email setup. Please
disregard the previous message.
On 9/20/24 19:21, Miquel Raynal wrote:
Hi Jiawei,
jiawei...@foxmail.com wrote on Fri, 20 Sep 2024 04:03:32 +:
In the `mac802154_scan_worker` function, the `scan_req->type` field was
accessed after the RCU read-side critical section was unlocked. According
to RCU usage rules, this is illegal and can lead to unpredictable
behavior, such as accessing memory that has been updated or causing
use-after-free issues.
This possible bug was identified using a static analysis tool developed
by myself, specifically designed to detect RCU-related issues.
To address this, the `scan_req->type` value is now stored in a local
variable `scan_req_type` while still within the RCU read-side critical
section. The `scan_req_type` is then used after the RCU lock is released,
ensuring that the type value is safely accessed without violating RCU
rules.
Fixes: e2c3e6f53a7a ("mac802154: Handle active scanning")
Signed-off-by: Jiawei Ye
I think net maintainers now expect the Cc: stable tag to be put here
when there is a reason to backport, which I believe is the case here.
So please add this line here.
Does this mean I should use Cc: sta...@vger.kernel.org? I am not familiar with
this procedure.
Yes.
Please delete this blank line as well.
And with that you can add my:
Acked-by: Miquel Raynal
---
Thanks,
Miquèl
Do I need to resend patch v2 with the "Resend" label?
Please make it a v3 right away, the resend with changes is to confusing
for maintainers to keep up what to apply.
In your case remove the blank line, add the stable cc and I am happy to
apply this.
regards
Stefan Schmidt
Re: [PATCH] Fix the RCU usage in mac802154_scan_worker
Hello Jiawei,
On 9/19/24 14:26, Jiawei Ye wrote:
On 9/19/24 17:01, Przemek Kitszel wrote:
In the `mac802154_scan_worker` function, the `scan_req->type` field was
accessed after the RCU read-side critical section was unlocked. According
to RCU usage rules, this is illegal and can lead to unpredictable
behavior, such as accessing memory that has been updated or causing
use-after-free issues.
This possible bug was identified using a static analysis tool developed
by myself, specifically designed to detect RCU-related issues.
To address this, the `scan_req->type` value is now stored in a local
variable `scan_req_type` while still within the RCU read-side critical
section. The `scan_req_type` is then used after the RCU lock is released,
ensuring that the type value is safely accessed without violating RCU
rules.
Fixes: e2c3e6f53a7a ("mac802154: Handle active scanning")
Signed-off-by: Jiawei Ye
---
net/mac802154/scan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mac802154/scan.c b/net/mac802154/scan.c
index 1c0eeaa76560..29cd84c9f69c 100644
--- a/net/mac802154/scan.c
+++ b/net/mac802154/scan.c
@@ -180,6 +180,7 @@ void mac802154_scan_worker(struct work_struct *work)
unsigned int scan_duration = 0;
struct wpan_phy *wpan_phy;
u8 scan_req_duration;
+ enum nl802154_scan_types scan_req_type;
this line violates the reverse X-mass tree rule of code formatting
Thank you for pointing out the concern regarding the violation of the
reverse Christmas tree rule. I will adjust the placement of
`enum nl802154_scan_types scan_req_type` to be between
`struct cfg802154_scan_request *scan_req` and
`struct ieee802154_sub_if_data *sdata`. If this change is suitable,
should I resend the patch as a v2 patch?
Yes, please always increase the version whenever you change something
and re-send. Also a ChangeLog of the changes makes it a lot easier for
the reviewer.
regards
Stefan Schmidt
Re: 802.15.4-2020 PHR field changes
Hello, On 9/13/24 12:59 AM, Alexander Aring wrote: Hi, On Mon, Sep 9, 2024 at 8:19 PM James Hanley wrote: Has there been any effort to understand the changes needed to include/net/ieee802154.h and associated files within drivers/net/ieee802154 to support the ratification of 15.4-2020? One prime example is the "Extended PHR" bit which was previously reserved to now allow extend the PHR of 2 more octets giving bits 8-11 to be used for "Frame Length MSB" and bits 12-15 marked as "Reserved" - this in combination of the legacy PHR bits 0-6 labeled as "Frame Length LSB" now allows for a frame MTU of 2048 octets. The 802.15.4-2020 is available individually free of charge through the IEEE website through the IEEE Get Program. https://ieeexplore.ieee.org/document/9144691 Is there a way to prototype these new changes to the spec with the mac802154_hwsim driver? mac802154_hwsim driver uses mac802154 the SoftMAC implementation. There are quite more changes necessary as the whole mac802154 stack deals with static 127 bytes MTU defines, etc. Unfortunately, it isn't just a driver change. I understand it the way that James actually wanted to try prototyping stack changes and verify with hwsim. James, could you clarify? To answer your question, we currently have no support for any of the newer 802154 specs. :/ Bigger MTU was brought up before (IIRC in the subGHz context) but nobody started to actually work on it. We are happy to take changes in, but currently we have no plans on our side to get this going. regards Stefan Schmidt
Re: [PATCH wpan RESEND] net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()
Hello Jinjie Ruan. On Wed, 11 Sep 2024 17:42:34 +0800, Jinjie Ruan wrote: > disable_irq() after request_irq() still has a time gap in which > interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will > disable IRQ auto-enable when request IRQ. > > Applied to wpan/wpan-next.git, thanks! [1/1] net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq() https://git.kernel.org/wpan/wpan-next/c/ace2b53313556 regards, Stefan Schmidt
Re: [PATCH 4/7] net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()
Hello Jinjie Ruan.
On 9/9/24 3:30 PM, Jinjie Ruan wrote:
disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable when request IRQ.
Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver
driver")
Signed-off-by: Jinjie Ruan
---
drivers/net/ieee802154/mcr20a.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
index 433fb5839203..020d392a98b6 100644
--- a/drivers/net/ieee802154/mcr20a.c
+++ b/drivers/net/ieee802154/mcr20a.c
@@ -1302,16 +1302,13 @@ mcr20a_probe(struct spi_device *spi)
irq_type = IRQF_TRIGGER_FALLING;
ret = devm_request_irq(&spi->dev, spi->irq, mcr20a_irq_isr,
- irq_type, dev_name(&spi->dev), lp);
+ irq_type | IRQF_NO_AUTOEN, dev_name(&spi->dev),
lp);
if (ret) {
dev_err(&spi->dev, "could not request_irq for mcr20a\n");
ret = -ENODEV;
goto free_dev;
}
- /* disable_irq by default and wait for starting hardware */
- disable_irq(spi->irq);
-
ret = ieee802154_register_hw(hw);
if (ret) {
dev_crit(&spi->dev, "ieee802154_register_hw failed\n");
Dave, Eric, Jakub, if you are taking them into net/net-next directly
here is my ack (and Miquel's review as well).
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH] ieee802154: Fix build error
Hello Jinjie. On Mon, 09 Sep 2024 21:17:40 +0800, Jinjie Ruan wrote: > If REGMAP_SPI is m and IEEE802154_MCR20A is y, > > mcr20a.c:(.text+0x3ed6c5b): undefined reference to > `__devm_regmap_init_spi' > ld: mcr20a.c:(.text+0x3ed6cb5): undefined reference to > `__devm_regmap_init_spi' > > Select REGMAP_SPI for IEEE802154_MCR20A to fix it. > > [...] Applied, thanks! [1/1] ieee802154: Fix build error commit: addf89774e48c992316449ffab4f29c2309ebefb Best regards, Stefan Schmidt
Re: pull-request: ieee802154 for net 2024-09-01
Hello. On 9/3/24 8:42 PM, Jakub Kicinski wrote: On Sun, 1 Sep 2024 20:42:13 +0200 Stefan Schmidt wrote: Simon Horman catched two typos in our headers. No functional change. Is it okay if we merge these into net-next ? On one hand they are unlikely^w guaranteed not to introduce regressions, but on the other such trivial spelling fixes are not at all urgent. Sure, no problem. They just landed in my fixes queue and thus wpan. They can easily go through net-next. Can you merge the pull directly or do need a new one against net-next? regards Stefan Schmidt
pull-request: ieee802154 for net 2024-09-01
Hello Dave, Jakub, Paolo. An update from ieee802154 for your *net* tree: Simon Horman catched two typos in our headers. No functional change. regards Stefan Schmidt The following changes since commit b8ec0dc3845f6c9089573cb5c2c4b05f7fc10728: net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD() (2024-06-03 11:20:56 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan.git tags/ieee802154-for-net-2024-09-01 for you to fetch changes up to 3682c302e72d71abeb17a81a6d29f281b22928e2: ieee802154: Correct spelling in nl802154.h (2024-08-30 22:30:55 +0200) Simon Horman (2): mac802154: Correct spelling in mac802154.h ieee802154: Correct spelling in nl802154.h include/net/mac802154.h | 4 ++-- include/net/nl802154.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
Re: [PATCH wpan-next 1/2] mac802154: Correct spelling in mac802154.h
Hello Simon,
On 8/29/24 6:10 PM, Simon Horman wrote:
Correct spelling in mac802154.h.
As reported by codespell.
Signed-off-by: Simon Horman
---
include/net/mac802154.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/mac802154.h b/include/net/mac802154.h
index 4a3a9de9da73..1b5488fa2ff0 100644
--- a/include/net/mac802154.h
+++ b/include/net/mac802154.h
@@ -140,7 +140,7 @@ enum ieee802154_hw_flags {
*
* xmit_sync:
* Handler that 802.15.4 module calls for each transmitted frame.
- * skb cntains the buffer starting from the IEEE 802.15.4 header.
+ * skb contains the buffer starting from the IEEE 802.15.4 header.
* The low-level driver should send the frame based on available
* configuration. This is called by a workqueue and useful for
* synchronous 802.15.4 drivers.
@@ -152,7 +152,7 @@ enum ieee802154_hw_flags {
*
* xmit_async:
* Handler that 802.15.4 module calls for each transmitted frame.
- * skb cntains the buffer starting from the IEEE 802.15.4 header.
+ * skb contains the buffer starting from the IEEE 802.15.4 header.
* The low-level driver should send the frame based on available
* configuration.
* This function should return zero or negative errno.
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
regards
Stefan Schmidt
Re: [PATCH v1] ieee802154: at86rf230: Simplify with dev_err_probe()
Hello Shen,
On 8/30/24 10:14 AM, Shen Lichuan wrote:
Use dev_err_probe() to simplify the error path and unify a message
template.
Using this helper is totally fine even if err is known to never
be -EPROBE_DEFER.
The benefit compared to a normal dev_err() is the standardized format
of the error code, it being emitted symbolically and the fact that
the error code is returned which allows more compact error paths.
Signed-off-by: Shen Lichuan
---
drivers/net/ieee802154/at86rf230.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ieee802154/at86rf230.c
b/drivers/net/ieee802154/at86rf230.c
index f632b0cfd5ae..3fb536734034 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -1532,11 +1532,9 @@ static int at86rf230_probe(struct spi_device *spi)
rc = device_property_read_u8(&spi->dev, "xtal-trim", &xtal_trim);
if (rc < 0) {
- if (rc != -EINVAL) {
- dev_err(&spi->dev,
- "failed to parse xtal-trim: %d\n", rc);
- return rc;
- }
+ if (rc != -EINVAL)
+ return dev_err_probe(&spi->dev, rc,
+"failed to parse xtal-trim\n");
xtal_trim = 0;
}
@@ -1576,9 +1574,8 @@ static int at86rf230_probe(struct spi_device *spi)
lp->regmap = devm_regmap_init_spi(spi, &at86rf230_regmap_spi_config);
if (IS_ERR(lp->regmap)) {
- rc = PTR_ERR(lp->regmap);
- dev_err(&spi->dev, "Failed to allocate register map: %d\n",
- rc);
+ dev_err_probe(&spi->dev, PTR_ERR(lp->regmap),
+ "Failed to allocate register map\n");
goto free_dev;
}
Please take the review from Simon into account here. Dropped this
version of the patch from the wpan patchwork queue.
regards
Stefan Schmidt
Re: [PATCH wpan-next 2/2] ieee802154: Correct spelling in nl802154.h
Hello Simon,
On 8/29/24 6:10 PM, Simon Horman wrote:
Correct spelling in nl802154.h.
As reported by codespell.
Signed-off-by: Simon Horman
---
include/net/nl802154.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index 4c752f799957..a994dea74596 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -192,7 +192,7 @@ enum nl802154_iftype {
* @NL802154_CAP_ATTR_TX_POWERS: a nested attribute for
*nl802154_wpan_phy_tx_power
* @NL802154_CAP_ATTR_MIN_CCA_ED_LEVEL: minimum value for cca_ed_level
- * @NL802154_CAP_ATTR_MAX_CCA_ED_LEVEL: maxmimum value for cca_ed_level
+ * @NL802154_CAP_ATTR_MAX_CCA_ED_LEVEL: maximum value for cca_ed_level
* @NL802154_CAP_ATTR_CCA_MODES: nl802154_cca_modes flags
* @NL802154_CAP_ATTR_CCA_OPTS: nl802154_cca_opts flags
* @NL802154_CAP_ATTR_MIN_MINBE: minimum of minbe value
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
regards
Stefan Schmidt
Re: pull-request: ieee802154 for net 2024-06-27
Hello Jakub, On 29.06.24 03:39, Jakub Kicinski wrote: On Thu, 27 Jun 2024 20:19:12 +0200 Stefan Schmidt wrote: Dmitry Antipov corrected the time calculations for the lifs and sifs periods in mac802154. Yunshui Jiang introduced the safer use of DEV_STATS_* macros for atomic updates. A good addition, even if not strictly necessary in our code. FTR looks like this got merged by DaveM, thank you! Thanks for letting me know. regards Stefan Schmidt
pull-request: ieee802154 for net 2024-06-27
Hello Dave, Jakub, Paolo. An update from ieee802154 for your *net* tree: Two small fixes this time around. Dmitry Antipov corrected the time calculations for the lifs and sifs periods in mac802154. Yunshui Jiang introduced the safer use of DEV_STATS_* macros for atomic updates. A good addition, even if not strictly necessary in our code. regards Stefan Schmidt The following changes since commit 4b377b4868ef17b040065bd468668c707d2477a5: kprobe/ftrace: fix build error due to bad function definition (2024-05-17 19:17:55 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan.git tags/ieee802154-for-net-2024-06-27 for you to fetch changes up to b8ec0dc3845f6c9089573cb5c2c4b05f7fc10728: net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD() (2024-06-03 11:20:56 +0200) Dmitry Antipov (1): mac802154: fix time calculation in ieee802154_configure_durations() Yunshui Jiang (1): net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD() net/mac802154/main.c | 14 -- net/mac802154/tx.c | 8 2 files changed, 12 insertions(+), 10 deletions(-)
Re: [PATCH] net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD()
Hello Jakub, Alex,
On 04.06.24 15:52, Alexander Aring wrote:
Hi,
On Mon, Jun 3, 2024 at 7:56 PM Jakub Kicinski wrote:
On Mon, 3 Jun 2024 11:33:28 +0200 Stefan Schmidt wrote:
Hello.
On 31.05.24 10:07, Yunshui Jiang wrote:
mac802154 devices update their dev->stats fields locklessly. Therefore
these counters should be updated atomically. Adopt SMP safe DEV_STATS_INC()
and DEV_STATS_ADD() to achieve this.
Signed-off-by: Yunshui Jiang
---
net/mac802154/tx.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index 2a6f1ed763c9..6fbed5bb5c3e 100644
--- a/net/mac802154/tx.c
+++ b/net/mac802154/tx.c
@@ -34,8 +34,8 @@ void ieee802154_xmit_sync_worker(struct work_struct *work)
if (res)
goto err_tx;
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += skb->len;
+ DEV_STATS_INC(dev, tx_packets);
+ DEV_STATS_ADD(dev, tx_bytes, skb->len);
ieee802154_xmit_complete(&local->hw, skb, false);
@@ -90,8 +90,8 @@ ieee802154_tx(struct ieee802154_local *local, struct sk_buff
*skb)
if (ret)
goto err_wake_netif_queue;
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += len;
+ DEV_STATS_INC(dev, tx_packets);
+ DEV_STATS_ADD(dev, tx_bytes, len);
} else {
local->tx_skb = skb;
queue_work(local->workqueue, &local->sync_tx_work);
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
Hi! I haven't looked in detail, but FWIW
$ git grep LLTX net/mac802154/
$
and similar patch from this author has been rejected:
https://lore.kernel.org/all/cann89ilpyoojmxnjbvhy7gwpfbguxwrom9gzz-fwuuyfyjm...@mail.gmail.com/
In the case of ieee802154_tx() yes the tx lock is held so it's like
what the mentioned link says. The workqueue is an ordered workqueue
and you either have the driver async xmit option (the preferred
option) or the driver sync xmit callback on a per driver (implies per
interface) basis.
When I reviewed and applied this I did indeed not realize the ordered
workqueue making this unnecessary.
I also don't see why there is currently a problem with the current
non-atomic way.
For me this looks more like a wrapper that could avoid future problems
for no cost. I would not mind if the patch stays. But you are right, its
not strictly needed. Want me to back it out again?
regards
Stefan Schmidt
Re: [PATCH] net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD()
Hello.
On 31.05.24 10:07, Yunshui Jiang wrote:
mac802154 devices update their dev->stats fields locklessly. Therefore
these counters should be updated atomically. Adopt SMP safe DEV_STATS_INC()
and DEV_STATS_ADD() to achieve this.
Signed-off-by: Yunshui Jiang
---
net/mac802154/tx.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index 2a6f1ed763c9..6fbed5bb5c3e 100644
--- a/net/mac802154/tx.c
+++ b/net/mac802154/tx.c
@@ -34,8 +34,8 @@ void ieee802154_xmit_sync_worker(struct work_struct *work)
if (res)
goto err_tx;
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += skb->len;
+ DEV_STATS_INC(dev, tx_packets);
+ DEV_STATS_ADD(dev, tx_bytes, skb->len);
ieee802154_xmit_complete(&local->hw, skb, false);
@@ -90,8 +90,8 @@ ieee802154_tx(struct ieee802154_local *local, struct sk_buff *skb)
if (ret)
goto err_wake_netif_queue;
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += len;
+ DEV_STATS_INC(dev, tx_packets);
+ DEV_STATS_ADD(dev, tx_bytes, len);
} else {
local->tx_skb = skb;
queue_work(local->workqueue, &local->sync_tx_work);
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
regards
Stefan Schmidt
Re: [PATCH] mac802154: fix time calculation in ieee802154_configure_durations()
Hello Dmitry, On 08.05.24 13:40, Dmitry Antipov wrote: Since 'symbol_duration' of 'struct wpan_phy' is in nanoseconds but 'lifs_period' and 'sifs_period' are both in microseconds, fix time calculation in 'ieee802154_configure_durations()' and use convenient 'NSEC_PER_USEC' in 'ieee802154_setup_wpan_phy_pib()' as well. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov --- net/mac802154/main.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/net/mac802154/main.c b/net/mac802154/main.c index 9ab7396668d2..21b7c3b280b4 100644 --- a/net/mac802154/main.c +++ b/net/mac802154/main.c @@ -161,8 +161,10 @@ void ieee802154_configure_durations(struct wpan_phy *phy, } phy->symbol_duration = duration; - phy->lifs_period = (IEEE802154_LIFS_PERIOD * phy->symbol_duration) / NSEC_PER_SEC; - phy->sifs_period = (IEEE802154_SIFS_PERIOD * phy->symbol_duration) / NSEC_PER_SEC; + phy->lifs_period = + (IEEE802154_LIFS_PERIOD * phy->symbol_duration) / NSEC_PER_USEC; + phy->sifs_period = + (IEEE802154_SIFS_PERIOD * phy->symbol_duration) / NSEC_PER_USEC; } EXPORT_SYMBOL(ieee802154_configure_durations); @@ -184,10 +186,10 @@ static void ieee802154_setup_wpan_phy_pib(struct wpan_phy *wpan_phy) * Should be done when all drivers sets this value. */ - wpan_phy->lifs_period = - (IEEE802154_LIFS_PERIOD * wpan_phy->symbol_duration) / 1000; - wpan_phy->sifs_period = - (IEEE802154_SIFS_PERIOD * wpan_phy->symbol_duration) / 1000; + wpan_phy->lifs_period = (IEEE802154_LIFS_PERIOD * +wpan_phy->symbol_duration) / NSEC_PER_USEC; + wpan_phy->sifs_period = (IEEE802154_SIFS_PERIOD * +wpan_phy->symbol_duration) / NSEC_PER_USEC; } int ieee802154_register_hw(struct ieee802154_hw *hw) I added a Fixes tag for you here before pushing so stable can decide if they want to pick this. This patch has been applied to the wpan tree and will be part of the next pull request to net. Thanks! regards Stefan Schmidt
Re: [PATCH] mac802154: fix time calculation in ieee802154_configure_durations()
Hello Miquel, On 13.05.24 09:09, Miquel Raynal wrote: Hi Dmitry, + Stefan dmanti...@yandex.ru wrote on Wed, 8 May 2024 14:40:10 +0300: Since 'symbol_duration' of 'struct wpan_phy' is in nanoseconds but 'lifs_period' and 'sifs_period' are both in microseconds, fix time calculation in 'ieee802154_configure_durations()' and use convenient 'NSEC_PER_USEC' in 'ieee802154_setup_wpan_phy_pib()' as well. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Requires Fixes and Cc: stable I guess. Fixes should be enough to get picked up. Added before pushing. regards Stefan Schmidt
[Observium] Re: Capture gaps when retrieving interface traffic data …
Thx James Tandy, Solution! We selected the dedicated device, choosed "Properties" and "SNMP" Tap, then "Basic Configuration" and adjusted under "Max Repetitions" with the Value "80". Working better now, Poller Times went down to 50 Seconds ... Grüße Stefan ___ observium mailing list -- observium@lists.observium.org To unsubscribe send an email to observium-le...@lists.observium.org
[Observium] Re: Capture gaps when retrieving interface traffic data …
Hello Admin, thank you for the 3 points, to which we would like to respond in order to further assess the problem: 1. The poller hardware currently only queries this one Mikrotik router beside 19 other devices behind. There is a load, this one router is displayed with “Last Polled” 100% and 204.19s. So is the server overloaded? 2. We have total 20 devices, 16 threads and 1 wrapper. How can we expand the processes? Minimum allowed warpper process is set to “4”. We only see one at a time. 3. In parallel to the router in question, other routers, switches, APs are queried (19) in the same network, where these problems do not occur. Why? On one router we have traffic of 10-100 Mbit/s on each 4 ports (interfaces) that we can see. Is it possible that the Mikrotik hardware processes the SNMP query too slowly? Our SNMP Access goes via a 5th unused line, not effected with internet traffic. Has anyone had similar experiences with Mikrotik and the CCR2004-16G-2S+ model? If this problem stays: Is there a way to individually change the polling time to 10 or 20 minutes for certain devices? Could be ok for uns ... Grüße Stefan ___ observium mailing list -- observium@lists.observium.org To unsubscribe send an email to observium-le...@lists.observium.org
[Observium] Capture gaps when retrieving interface traffic data …
Hello! We query with snmp Observium the port data from a Mikrotik router (CCR2004-16G-2S+) with RouterOS 7.14.1 (Level 6) via SNMP from 4 WAN interfaces with polling and alerts. However, we always have gaps in the data. Every now and then 5-10 minutes of data are missing, so that vertical lines without data appear in the rrd - of course this only becomes clear in the 6h overview. We are surprised because we have the impression that it only started on this device (and others) almost a year ago. We therefore renewed the hardware, reinstalled the system (debian12) and only queried this router alone (also deleted the query from the old Observium to avoid parallel double queries). We look at https://.../pollerlog/ and see our patient there: Device Last Polled 10.X.X.1 100% 108.67s (...) and others of the location with 1-19%... Why 100%... where are the key data relevant here? We would be happy if someone could help us adjust the Observium "Poller Wrapper" parameters if necessary. Is there potential for adaptation there? Greetings Frankfurt/Main Stefan ___ observium mailing list -- observium@lists.observium.org To unsubscribe send an email to observium-le...@lists.observium.org
pull-request: ieee802154-next 2024-03-07
Hello Dave, Jakub, Paolo. A little late, but hopefully still in time. An update from ieee802154 for your *net-next* tree: Various cross tree patches for ieee802154v drivers and a resource leak fix for ieee802154 llsec. Andy Shevchenko changed GPIO header usage for at86rf230 and mcr20a to only include needed headers. Bo Liu converted the at86rf230, mcr20a and mrf24j40 driver regmap support to use the maple tree register cache. Fedor Pchelkin fixed a resource leak in the llsec key deletion path. Ricardo B. Marliere made wpan_phy_class const. Tejun Heo removed WQ_UNBOUND from a workqueue call in ca8210. regards Stefan Schmidt The following changes since commit 2373699560a754079579b7722b50d1d38de1960e: mac802154: Avoid new associations while disassociating (2023-12-15 11:14:57 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan-next.git tags/ieee802154-for-net-next-2024-03-07 for you to fetch changes up to b2d23256615c8f8b3215f0155b0234f0e310dfde: ieee802154: cfg802154: make wpan_phy_class constant (2024-03-06 21:23:10 +0100) Andy Shevchenko (2): ieee802154: at86rf230: Replace of_gpio.h by proper one ieee802154: mcr20a: Remove unused of_gpio.h Bo Liu (3): net: ieee802154: at86rf230: convert to use maple tree register cache net: ieee802154: mcr20a: convert to use maple tree register cache net: ieee802154: mrf24j40: convert to use maple tree register cache Fedor Pchelkin (1): mac802154: fix llsec key resources release in mac802154_llsec_key_del Ricardo B. Marliere (1): ieee802154: cfg802154: make wpan_phy_class constant Tejun Heo (1): ieee802154: ca8210: Drop spurious WQ_UNBOUND from alloc_ordered_workqueue() call drivers/net/ieee802154/at86rf230.c | 5 ++--- drivers/net/ieee802154/ca8210.c| 10 ++ drivers/net/ieee802154/mcr20a.c| 5 ++--- drivers/net/ieee802154/mrf24j40.c | 4 ++-- include/net/cfg802154.h| 1 + net/ieee802154/sysfs.c | 2 +- net/ieee802154/sysfs.h | 2 +- net/mac802154/llsec.c | 18 +- 8 files changed, 24 insertions(+), 23 deletions(-)
Re: [PATCH wpan-next] wifi: cfg802154: make wpan_phy_class constant
Hello.
On 05.03.24 20:55, Ricardo B. Marliere wrote:
Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the wpan_phy_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.
Cc: Greg Kroah-Hartman
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Ricardo B. Marliere
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
Re: [PATCH net-next v1 1/1] ieee802154: mcr20a: Remove unused of_gpio.h
Hello. On 04.03.24 18:53, Andy Shevchenko wrote: of_gpio.h is deprecated and subject to remove. The driver doesn't use it, simply remove the unused header. Signed-off-by: Andy Shevchenko --- drivers/net/ieee802154/mcr20a.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c index efb1be3c644e..433fb5839203 100644 --- a/drivers/net/ieee802154/mcr20a.c +++ b/drivers/net/ieee802154/mcr20a.c @@ -12,7 +12,6 @@ #include #include #include -#include #include #include #include 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
Re: [PATCH net-next v1 1/1] ieee802154: at86rf230: Replace of_gpio.h by proper one
Hello. On 04.03.24 18:42, Andy Shevchenko wrote: of_gpio.h is deprecated and subject to remove. The driver doesn't use it directly, replace it with what is really being used. Signed-off-by: Andy Shevchenko --- drivers/net/ieee802154/at86rf230.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c index 6212164ffb36..f632b0cfd5ae 100644 --- a/drivers/net/ieee802154/at86rf230.c +++ b/drivers/net/ieee802154/at86rf230.c @@ -11,17 +11,16 @@ */ #include #include +#include #include #include #include #include -#include #include #include #include #include #include -#include #include #include 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
Re: [PATCH wpan] mac802154: fix llsec key resources release in mac802154_llsec_key_del
Hello.
On 28.02.24 17:38, Fedor Pchelkin wrote:
mac802154_llsec_key_del() can free resources of a key directly without
following the RCU rules for waiting before the end of a grace period. This
may lead to use-after-free in case llsec_lookup_key() is traversing the
list of keys in parallel with a key deletion:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25
refcount_warn_saturate+0x162/0x2a0
Modules linked in:
CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:refcount_warn_saturate+0x162/0x2a0
Call Trace:
llsec_lookup_key.isra.0+0x890/0x9e0
mac802154_llsec_encrypt+0x30c/0x9c0
ieee802154_subif_start_xmit+0x24/0x1e0
dev_hard_start_xmit+0x13e/0x690
sch_direct_xmit+0x2ae/0xbc0
__dev_queue_xmit+0x11dd/0x3c20
dgram_sendmsg+0x90b/0xd60
__sys_sendto+0x466/0x4c0
__x64_sys_sendto+0xe0/0x1c0
do_syscall_64+0x45/0xf0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
Also, ieee802154_llsec_key_entry structures are not freed by
mac802154_llsec_key_del():
unreferenced object 0x8880613b6980 (size 64):
comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s)
hex dump (first 32 bytes):
78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x..."...
00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00
backtrace:
[] __kmem_cache_alloc_node+0x1e2/0x2d0
[] kmalloc_trace+0x25/0xc0
[] mac802154_llsec_key_add+0xac9/0xcf0
[] ieee802154_add_llsec_key+0x5a/0x80
[] nl802154_add_llsec_key+0x426/0x5b0
[] genl_family_rcv_msg_doit+0x1fe/0x2f0
[] genl_rcv_msg+0x531/0x7d0
[] netlink_rcv_skb+0x169/0x440
[] genl_rcv+0x28/0x40
[] netlink_unicast+0x53c/0x820
[] netlink_sendmsg+0x93b/0xe60
[] sys_sendmsg+0xac5/0xca0
[] ___sys_sendmsg+0x11d/0x1c0
[] __sys_sendmsg+0xfa/0x1d0
[] do_syscall_64+0x45/0xf0
[] entry_SYSCALL_64_after_hwframe+0x6e/0x76
Handle the proper resource release in the RCU callback function
mac802154_llsec_key_del_rcu().
Note that if llsec_lookup_key() finds a key, it gets a refcount via
llsec_key_get() and locally copies key id from key_entry (which is a
list element). So it's safe to call llsec_key_put() and free the list
entry after the RCU grace period elapses.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 5d637d5aabd8 ("mac802154: add llsec structures and mutators")
Cc: sta...@vger.kernel.org
Signed-off-by: Fedor Pchelkin
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
Re: [PATCH] ieee802154: ca8210: Drop spurious WQ_UNBOUND from alloc_ordered_workqueue() call
Hello,
On 06.02.24 00:53, Tejun Heo wrote:
Workqueue is in the process of cleaning up the distinction between unbound
workqueues w/ @nr_active==1 and ordered workqueues. Explicit WQ_UNBOUND
isn't needed for alloc_ordered_workqueue() and will trigger a warning in the
future. Let's remove it. This doesn't cause any functional changes.
Signed-off-by: Tejun Heo
---
drivers/net/ieee802154/ca8210.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -2857,19 +2857,13 @@ static int ca8210_interrupt_init(struct
*/
static int ca8210_dev_com_init(struct ca8210_priv *priv)
{
- priv->mlme_workqueue = alloc_ordered_workqueue(
- "MLME work queue",
- WQ_UNBOUND
- );
+ priv->mlme_workqueue = alloc_ordered_workqueue("MLME work queue", 0);
if (!priv->mlme_workqueue) {
dev_crit(&priv->spi->dev, "alloc of mlme_workqueue failed!\n");
return -ENOMEM;
}
- priv->irq_workqueue = alloc_ordered_workqueue(
- "ca8210 irq worker",
- WQ_UNBOUND
- );
+ priv->irq_workqueue = alloc_ordered_workqueue("ca8210 irq worker", 0);
if (!priv->irq_workqueue) {
dev_crit(&priv->spi->dev, "alloc of irq_workqueue failed!\n");
destroy_workqueue(priv->mlme_workqueue);
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
Re: [PATCH] net: ieee802154: at86rf230: convert to use maple tree register cache
Hello,
On 02.02.24 07:45, Bo Liu wrote:
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu
---
drivers/net/ieee802154/at86rf230.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/at86rf230.c
b/drivers/net/ieee802154/at86rf230.c
index 164c7f605af5..6212164ffb36 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -316,7 +316,7 @@ static const struct regmap_config
at86rf230_regmap_spi_config = {
.val_bits = 8,
.write_flag_mask = CMD_REG | CMD_WRITE,
.read_flag_mask = CMD_REG,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.max_register = AT86RF2XX_NUMREGS,
.writeable_reg = at86rf230_reg_writeable,
.readable_reg = at86rf230_reg_readable,
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
Re: [PATCH] net: ieee802154: mrf24j40: convert to use maple tree register cache
Hello,
On 02.02.24 07:46, Bo Liu wrote:
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu
---
drivers/net/ieee802154/mrf24j40.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index ee4cfbf2c5cc..d3f42efc5d1a 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -388,7 +388,7 @@ static const struct regmap_config mrf24j40_short_regmap = {
.pad_bits = 1,
.write_flag_mask = MRF24J40_SHORT_WRITE,
.read_flag_mask = MRF24J40_SHORT_READ,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.max_register = MRF24J40_SHORT_NUMREGS,
.writeable_reg = mrf24j40_short_reg_writeable,
.readable_reg = mrf24j40_short_reg_readable,
@@ -495,7 +495,7 @@ static const struct regmap_config mrf24j40_long_regmap = {
.pad_bits = 5,
.write_flag_mask = MRF24J40_LONG_ACCESS,
.read_flag_mask = MRF24J40_LONG_ACCESS,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.max_register = MRF24J40_LONG_NUMREGS,
.writeable_reg = mrf24j40_long_reg_writeable,
.readable_reg = mrf24j40_long_reg_readable,
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
Re: [PATCH] net: ieee802154: mcr20a: convert to use maple tree register cache
Hello,
On 02.02.24 07:46, Bo Liu wrote:
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu
---
drivers/net/ieee802154/mcr20a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
index 87abe3b46316..efb1be3c644e 100644
--- a/drivers/net/ieee802154/mcr20a.c
+++ b/drivers/net/ieee802154/mcr20a.c
@@ -251,7 +251,7 @@ static const struct regmap_config mcr20a_dar_regmap = {
.val_bits = 8,
.write_flag_mask= REGISTER_ACCESS | REGISTER_WRITE,
.read_flag_mask = REGISTER_ACCESS | REGISTER_READ,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.writeable_reg = mcr20a_dar_writeable,
.readable_reg = mcr20a_dar_readable,
.volatile_reg = mcr20a_dar_volatile,
@@ -387,7 +387,7 @@ static const struct regmap_config mcr20a_iar_regmap = {
.val_bits = 8,
.write_flag_mask= REGISTER_ACCESS | REGISTER_WRITE | IAR_INDEX,
.read_flag_mask = REGISTER_ACCESS | REGISTER_READ | IAR_INDEX,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.writeable_reg = mcr20a_iar_writeable,
.readable_reg = mcr20a_iar_readable,
.volatile_reg = mcr20a_iar_volatile,
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
Re: [PATCH 02/33] ieee802154: ca8210: Follow renaming of SPI "master" to "controller"
Hello
On 15.01.24 21:12, Uwe Kleine-König wrote:
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. To not break all drivers
compatibility macros were provided.
To be able to remove these compatibility macros push the renaming into
this driver.
Signed-off-by: Uwe Kleine-König
---
drivers/net/ieee802154/ca8210.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 4ec0dab38872..f732c150462b 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -2956,7 +2956,7 @@ static int ca8210_test_interface_init(struct ca8210_priv
*priv)
node_name,
sizeof(node_name),
"ca8210@%d_%d",
- priv->spi->master->bus_num,
+ priv->spi->controller->bus_num,
spi_get_chipselect(priv->spi, 0)
);
Feel free to take this one together with the rest through one tree.
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: Linux WPAN and Contiki NG
Hello Marek, [I added the list back into cc as I think is could be of interest to more people. Also your blog post for people interested in trying out Contiki NG with Linux] On 09.01.24 19:32, Marek Küthe wrote: On Tue, 9 Jan 2024 08:34:47 +0100 Stefan Schmidt wrote: Would be happy to hear findings when you tried it. :-) I have written a small blog entry about my configuration. It may not be particularly beautiful (written) - but I think you can understand it. TLDR: Linux and Contriki NG only work together when Contriki NG is in CSMA mode. English: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-en/ German: https://mk16.de/blog/contiki-ng-linux-wpan-6lowpan-de/ Thanks, it was a good read. To address some of your implicit questions in the post. Yes, the first missing pings could be due to ND. To be sure you would need to check out the packets with wireshark or similar. As for the MAC access mode needed to be CSMA, yes this is the only one supported. The biggest problem, for Linux, with other modes like 6Tisch is the hard timing requirements. If it is possible to work in these real-time requirements would have to be tested. Nobody stepped up to do the implementation yet to try it out. One could start with simple implementation, if that fails, make use of preempt-rt features, if that fails see what hardware timers or other capabilities of the transceivers could be used. On the ATUSB, time critical pathes could also be offloaded into the firmware. It all depends on interest, motivation and time :-) regards Stefan Schmidt
Re: Linux WPAN and Contiki NG
Hello Marek, On 08.01.24 18:09, Marek Küthe wrote: Hello dear Mailling list, I would like to try Linux WPAN with Contriki NG and have some questions (I am new to the topic, so the questions may be quite stupid): Contiki NG, as I understand it, implements various 6lowpan standards - including 6TiSCH, TSCH and 6TOP. Which of these are also implemented in Linux WPAN and how can they be used? As I understand it, TSCH is implemented. Is that correct? I fear none of these advanced mechanisms (mostly for packet scheduling) are implemented. Linux wpan offers the basics in 802.15.4 and 6lowpan. PHY and MAC access and encapsulations and compression with 6lowpan. The use of it is explained on https://linux-wpan.org/documentation.html. Is there anything special I need to consider when connecting Linux and Contiki NG? I have not looked at Contiki in years to be fair. In general the main 1.4 and 6lowpan communication should work. If you enable advanced techniques for packet scheduling and timing you will surely run into problems. Would be happy to hear findings when you tried it. :-) I hope it's okay if I post my questions here on the Mailling list. Its the perfect place for them. :-) regards Stefan Schmidt
Re: [PATCH net-next 06/10] net: fill in MODULE_DESCRIPTION()s for ieee802154
Hello.
On 08.01.24 19:16, Breno Leitao wrote:
W=1 builds now warn if module is built without a MODULE_DESCRIPTION().
Add descriptions to ieee802154 modules.
Signed-off-by: Breno Leitao
---
net/ieee802154/6lowpan/core.c | 1 +
net/ieee802154/socket.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
index 2c087b7f17c5..b88f6a96d961 100644
--- a/net/ieee802154/6lowpan/core.c
+++ b/net/ieee802154/6lowpan/core.c
@@ -280,5 +280,6 @@ static void __exit lowpan_cleanup_module(void)
module_init(lowpan_init_module);
module_exit(lowpan_cleanup_module);
+MODULE_DESCRIPTION("IPv6 over Low power Wireless Personal Area Network IEEE802154.4
core");
If we want to nitpick you could write it as IEEE 802.15.4.
MODULE_LICENSE("GPL");
MODULE_ALIAS_RTNL_LINK("lowpan");
diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
index 00302e8b9615..db8df6e26159 100644
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -1137,4 +1137,5 @@ module_init(af_ieee802154_init);
module_exit(af_ieee802154_remove);
MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("IEEE802154.4 socket interface");
MODULE_ALIAS_NETPROTO(PF_IEEE802154);
Same here.
Besides this:
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH wpan-tools 0/2] Associations support
Hello. On 28.11.23 12:29, Miquel Raynal wrote: Hello, Associations will be part of the next kernel merge window, so here is the userspace part to interact with it. Thanks, Miquèl Miquel Raynal (2): iwpan: Synchronize nl802154.h with the latest association changes iwpan: Add associations support src/info.c | 4 ++ src/mac.c | 187 + src/nl802154.h | 22 +- 3 files changed, 211 insertions(+), 2 deletions(-) I pushed both of thee now into the associations-support topic branch of wpan-tools. Once A kernel is released with the support we can merge it into the main branch. regards Stefan Schmidt
Re: [PATCH wpan-tools] iwpan: Allow the phy shortcut for scanning commands
Hello. On 28.11.23 12:27, Miquel Raynal wrote: Hi Stefan, miquel.ray...@bootlin.com wrote on Mon, 13 Feb 2023 18:47:03 +0100: Allow running: iwpan phy scan trigger ... iwpan phy scan abort ... Aside with the existing: iwpan dev scan trigger ... iwpan dev scan abort ... This change does not apply easily to the TOPLEVEL(scan) command, so we keep this one more constrained for simplicity. I believe this patch felt into the cracks, I think I remember it came from a request from Alex, maybe you will want to consider it for merge despite its "age"? Or maybe I missed some feedback in the SPAMS /o\ Nope, just fallen through the cracks. Applied now: https://github.com/linux-wpan/wpan-tools/commit/3036dc0533abd6a89d5d0df0f3d9013aa294cbb3 regards Stefan Schmidt
Re: [PATCH wpan-next 5/5] mac802154: Avoid new associations while disassociating
Hello.
On 28.11.23 12:16, Miquel Raynal wrote:
While disassociating from a PAN ourselves, let's set the maximum number
of associations temporarily to zero to be sure no new device tries to
associate with us.
Signed-off-by: Miquel Raynal
---
include/net/cfg802154.h | 4 +++-
net/ieee802154/pan.c| 8 +++-
net/mac802154/cfg.c | 11 ---
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index a64bbcd71f10..cd95711b12b8 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -589,8 +589,10 @@ cfg802154_device_is_child(struct wpan_dev *wpan_dev,
* cfg802154_set_max_associations - Limit the number of future associations
* @wpan_dev: the wpan device
* @max: the maximum number of devices we accept to associate
+ * @return: the old maximum value
*/
-void cfg802154_set_max_associations(struct wpan_dev *wpan_dev, unsigned int
max);
+unsigned int cfg802154_set_max_associations(struct wpan_dev *wpan_dev,
+ unsigned int max);
/**
* cfg802154_get_free_short_addr - Get a free address among the known devices
diff --git a/net/ieee802154/pan.c b/net/ieee802154/pan.c
index fb5b0af2ef68..249df7364b3e 100644
--- a/net/ieee802154/pan.c
+++ b/net/ieee802154/pan.c
@@ -94,10 +94,16 @@ __le16 cfg802154_get_free_short_addr(struct wpan_dev
*wpan_dev)
}
EXPORT_SYMBOL_GPL(cfg802154_get_free_short_addr);
-void cfg802154_set_max_associations(struct wpan_dev *wpan_dev, unsigned int max)
+unsigned int cfg802154_set_max_associations(struct wpan_dev *wpan_dev,
+ unsigned int max)
{
+ unsigned int old_max;
+
lockdep_assert_held(&wpan_dev->association_lock);
+ old_max = wpan_dev->max_associations;
wpan_dev->max_associations = max;
+
+ return old_max;
}
EXPORT_SYMBOL_GPL(cfg802154_set_max_associations);
diff --git a/net/mac802154/cfg.c b/net/mac802154/cfg.c
index 17e2032fac24..ef7f23af043f 100644
--- a/net/mac802154/cfg.c
+++ b/net/mac802154/cfg.c
@@ -389,6 +389,7 @@ static int mac802154_disassociate_from_parent(struct
wpan_phy *wpan_phy,
struct ieee802154_local *local = wpan_phy_priv(wpan_phy);
struct ieee802154_pan_device *child, *tmp;
struct ieee802154_sub_if_data *sdata;
+ unsigned int max_assoc;
u64 eaddr;
int ret;
@@ -397,6 +398,7 @@ static int mac802154_disassociate_from_parent(struct wpan_phy *wpan_phy,
/* Start by disassociating all the children and preventing new ones to
* attempt associations.
*/
+ max_assoc = cfg802154_set_max_associations(wpan_dev, 0);
list_for_each_entry_safe(child, tmp, &wpan_dev->children, node) {
ret = mac802154_send_disassociation_notif(sdata, child,
IEEE802154_COORD_WISHES_DEVICE_TO_LEAVE);
@@ -429,14 +431,17 @@ static int mac802154_disassociate_from_parent(struct
wpan_phy *wpan_phy,
if (local->hw.flags & IEEE802154_HW_AFILT) {
ret = drv_set_pan_id(local, wpan_dev->pan_id);
if (ret < 0)
- return ret;
+ goto reset_mac_assoc;
ret = drv_set_short_addr(local, wpan_dev->short_addr);
if (ret < 0)
- return ret;
+ goto reset_mac_assoc;
}
- return 0;
+reset_mac_assoc:
+ cfg802154_set_max_associations(wpan_dev, max_assoc);
+
+ return ret;
}
static int mac802154_disassociate_child(struct wpan_phy *wpan_phy,
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH wpan-next 4/5] ieee802154: Avoid confusing changes after associating
Hello.
On 28.11.23 12:16, Miquel Raynal wrote:
Once associated with any device, we are part of a PAN (with a specific
PAN ID), and we are expected to be present on a particular
channel. Let's avoid confusing other devices by preventing any PAN
ID/channel change once associated.
Signed-off-by: Miquel Raynal
---
net/ieee802154/nl802154.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index e4d290d0e0a0..5c73b5fcadc0 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1087,6 +1087,15 @@ 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]);
+ /* Only allow changing the PAN ID when the device has no more
+* associations ongoing to avoid confusing peers.
+*/
+ if (cfg802154_device_is_associated(wpan_dev)) {
+ NL_SET_ERR_MSG(info->extack,
+ "Existing associations, changing PAN ID
forbidden");
+ return -EINVAL;
+ }
+
return rdev_set_pan_id(rdev, wpan_dev, pan_id);
}
@@ -1113,20 +1122,17 @@ static int nl802154_set_short_addr(struct sk_buff *skb, struct genl_info *info)
short_addr = nla_get_le16(info->attrs[NL802154_ATTR_SHORT_ADDR]);
- /* TODO
-* I am not sure about to check here on broadcast short_addr.
-* Broadcast is a valid setting, comment from 802.15.4:
-* A value of 0xfffe indicates that the device has
-* associated but has not been allocated an address. A
-* value of 0x indicates that the device does not
-* have a short address.
-*
-* I think we should allow to set these settings but
-* don't allow to allow socket communication with it.
+ /* The short address only has a meaning when part of a PAN, after a
+* proper association procedure. However, we want to still offer the
+* possibility to create static networks so changing the short address
+* is only allowed when not already associated to other devices with
+* the official handshake.
*/
- if (short_addr == cpu_to_le16(IEEE802154_ADDR_SHORT_UNSPEC) ||
- short_addr == cpu_to_le16(IEEE802154_ADDR_SHORT_BROADCAST))
+ if (cfg802154_device_is_associated(wpan_dev)) {
+ NL_SET_ERR_MSG(info->extack,
+ "Existing associations, changing short address
forbidden");
return -EINVAL;
+ }
return rdev_set_short_addr(rdev, wpan_dev, short_addr);
}
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH wpan-next 3/5] mac802154: Only allow PAN controllers to process association requests
Hello.
On 28.11.23 12:16, Miquel Raynal wrote:
It is not very clear in the specification whether simple coordinators
are allowed or not to answer to association requests themselves. As
there is no synchronization mechanism, it is probably best to rely on
the relay feature of these coordinators and avoid processing them in
this case.
Signed-off-by: Miquel Raynal
---
net/mac802154/scan.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/mac802154/scan.c b/net/mac802154/scan.c
index 5873da634fb4..1c0eeaa76560 100644
--- a/net/mac802154/scan.c
+++ b/net/mac802154/scan.c
@@ -781,6 +781,12 @@ int mac802154_process_association_req(struct
ieee802154_sub_if_data *sdata,
unlikely(dest->short_addr != wpan_dev->short_addr))
return -ENODEV;
+ if (wpan_dev->parent) {
+ dev_dbg(&sdata->dev->dev,
+ "Ignoring ASSOC REQ, not the PAN coordinator\n");
+ return -ENODEV;
+ }
+
mutex_lock(&wpan_dev->association_lock);
memcpy(&assoc_req_pl, skb->data, sizeof(assoc_req_pl));
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH wpan-next 2/5] mac802154: Use the PAN coordinator parameter when stamping packets
Hello.
On 28.11.23 12:16, Miquel Raynal wrote:
ACKs come with the source and destination address empty, this has been
clarified already. But there is something else: if the destination
address is empty but the source address is valid, it may be a way to
reach the PAN coordinator. Either the device receiving this frame is the
PAN coordinator itself and should process what it just received
(PACKET_HOST) or it is not and may, if supported, relay the packet as it
is targeted to another device in the network.
Right now we do not support relaying so the packet should be dropped in
the first place, but the stamping looks more accurate this way.
Signed-off-by: Miquel Raynal
---
net/mac802154/rx.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/mac802154/rx.c b/net/mac802154/rx.c
index 0024341ef9c5..e40a988d6c80 100644
--- a/net/mac802154/rx.c
+++ b/net/mac802154/rx.c
@@ -156,12 +156,15 @@ ieee802154_subif_frame(struct ieee802154_sub_if_data
*sdata,
switch (mac_cb(skb)->dest.mode) {
case IEEE802154_ADDR_NONE:
- if (hdr->source.mode != IEEE802154_ADDR_NONE)
- /* FIXME: check if we are PAN coordinator */
- skb->pkt_type = PACKET_OTHERHOST;
- else
+ if (hdr->source.mode == IEEE802154_ADDR_NONE)
/* ACK comes with both addresses empty */
skb->pkt_type = PACKET_HOST;
+ else if (!wpan_dev->parent)
+ /* No dest means PAN coordinator is the recipient */
+ skb->pkt_type = PACKET_HOST;
+ else
+ /* We are not the PAN coordinator, just relaying */
+ skb->pkt_type = PACKET_OTHERHOST;
break;
case IEEE802154_ADDR_LONG:
if (mac_cb(skb)->dest.pan_id != span &&
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH wpan-next 1/5] mac80254: Provide real PAN coordinator info in beacons
Hello.
On 28.11.23 12:16, Miquel Raynal wrote:
Sending a beacon is a way to advertise a PAN, but also ourselves as
coordinator in the PAN. There is only one PAN coordinator in a PAN, this
is the device without parent (not associated itself to an "upper"
coordinator). Instead of blindly saying that we are the PAN coordinator,
let's actually use our internal information to fill this field.
Signed-off-by: Miquel Raynal
---
net/mac802154/scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac802154/scan.c b/net/mac802154/scan.c
index 7597072aed57..5873da634fb4 100644
--- a/net/mac802154/scan.c
+++ b/net/mac802154/scan.c
@@ -466,6 +466,7 @@ int mac802154_send_beacons_locked(struct
ieee802154_sub_if_data *sdata,
struct cfg802154_beacon_request *request)
{
struct ieee802154_local *local = sdata->local;
+ struct wpan_dev *wpan_dev = &sdata->wpan_dev;
ASSERT_RTNL();
@@ -495,8 +496,7 @@ int mac802154_send_beacons_locked(struct ieee802154_sub_if_data *sdata,
local->beacon.mac_pl.superframe_order = request->interval;
local->beacon.mac_pl.final_cap_slot = 0xf;
local->beacon.mac_pl.battery_life_ext = 0;
- /* TODO: Fill this field with the coordinator situation in the network
*/
- local->beacon.mac_pl.pan_coordinator = 1;
+ local->beacon.mac_pl.pan_coordinator = !wpan_dev->parent;
local->beacon.mac_pl.assoc_permit = 1;
if (request->interval == IEEE802154_ACTIVE_SCAN_DURATION)
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH wpan-next v5 01/11] ieee802154: Let PAN IDs be reset
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 0x to a real value when association succeeded, or to reset the PAN ID to 0x upon disassociation. Let's allow to do that manually for now. Signed-off-by: Miquel Raynal 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 net-next 10/10] ieee802154: hwsim: Convert to platform remove callback returning void
Hello.
On 17.11.23 10:59, Uwe Kleine-König wrote:
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/net/ieee802154/mac802154_hwsim.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ieee802154/mac802154_hwsim.c
b/drivers/net/ieee802154/mac802154_hwsim.c
index 31cba9aa7636..2c2483bbe780 100644
--- a/drivers/net/ieee802154/mac802154_hwsim.c
+++ b/drivers/net/ieee802154/mac802154_hwsim.c
@@ -1035,7 +1035,7 @@ static int hwsim_probe(struct platform_device *pdev)
return err;
}
-static int hwsim_remove(struct platform_device *pdev)
+static void hwsim_remove(struct platform_device *pdev)
{
struct hwsim_phy *phy, *tmp;
@@ -1043,13 +1043,11 @@ static int hwsim_remove(struct platform_device *pdev)
list_for_each_entry_safe(phy, tmp, &hwsim_phys, list)
hwsim_del(phy);
mutex_unlock(&hwsim_phys_lock);
-
- return 0;
}
static struct platform_driver mac802154hwsim_driver = {
.probe = hwsim_probe,
- .remove = hwsim_remove,
+ .remove_new = hwsim_remove,
.driver = {
.name = "mac802154_hwsim",
},
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH net-next 09/10] ieee802154: fakelb: Convert to platform remove callback returning void
Hello.
On 17.11.23 10:59, Uwe Kleine-König wrote:
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/net/ieee802154/fakelb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/fakelb.c b/drivers/net/ieee802154/fakelb.c
index 523d13ee02bf..35e55f198e05 100644
--- a/drivers/net/ieee802154/fakelb.c
+++ b/drivers/net/ieee802154/fakelb.c
@@ -221,7 +221,7 @@ static int fakelb_probe(struct platform_device *pdev)
return err;
}
-static int fakelb_remove(struct platform_device *pdev)
+static void fakelb_remove(struct platform_device *pdev)
{
struct fakelb_phy *phy, *tmp;
@@ -229,14 +229,13 @@ static int fakelb_remove(struct platform_device *pdev)
list_for_each_entry_safe(phy, tmp, &fakelb_phys, list)
fakelb_del(phy);
mutex_unlock(&fakelb_phys_lock);
- return 0;
}
static struct platform_device *ieee802154fake_dev;
static struct platform_driver ieee802154fake_driver = {
.probe = fakelb_probe,
- .remove = fakelb_remove,
+ .remove_new = fakelb_remove,
.driver = {
.name = "ieee802154fakelb",
},
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
pull-request: ieee802154 for net 2023-10-10
Hello Dave, Jakub, Paolo. An update from ieee802154 for your *net* tree: Just one small fix this time around. Dinghao Liu fixed a potential use-after-free in the ca8210 driver probe function. regards Stefan Schmidt The following changes since commit a2e52554c710b388df2d9d95b51cc1059af2aa22: Merge branch 'ravb-fix-use-after-free-issues' (2023-10-06 16:19:15 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan.git tags/ieee802154-for-net-2023-10-10 for you to fetch changes up to f990874b1c98fe8e57ee9385669f501822979258: ieee802154: ca8210: Fix a potential UAF in ca8210_probe (2023-10-07 20:37:38 +0200) Dinghao Liu (1): ieee802154: ca8210: Fix a potential UAF in ca8210_probe drivers/net/ieee802154/ca8210.c | 17 +++-- 1 file changed, 3 insertions(+), 14 deletions(-)
Re: [PATCH] [v4] ieee802154: ca8210: Fix a potential UAF in ca8210_probe
Hello.
On 07.10.23 05:30, Dinghao Liu wrote:
If of_clk_add_provider() fails in ca8210_register_ext_clock(),
it calls clk_unregister() to release priv->clk and returns an
error. However, the caller ca8210_probe() then calls ca8210_remove(),
where priv->clk is freed again in ca8210_unregister_ext_clock(). In
this case, a use-after-free may happen in the second time we call
clk_unregister().
Fix this by removing the first clk_unregister(). Also, priv->clk could
be an error code on failure of clk_register_fixed_rate(). Use
IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().
Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Signed-off-by: Dinghao Liu
---
Changelog:
v2: -Remove the first clk_unregister() instead of nulling priv->clk.
v3: -Simplify ca8210_register_ext_clock().
-Add a ';' after return in ca8210_unregister_ext_clock().
v4: -Remove an unused variable 'ret'.
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
regards
Stefan Schmidt
Re: [PATCH] [v3] ieee802154: ca8210: Fix a potential UAF in ca8210_probe
Hello Dinghao, On 01.10.23 09:19, kernel test robot wrote: Hi Dinghao, kernel test robot noticed the following build warnings: [auto build test WARNING on linus/master] [also build test WARNING on v6.6-rc3 next-20230929] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Dinghao-Liu/ieee802154-ca8210-Fix-a-potential-UAF-in-ca8210_probe/20231001-135130 base: linus/master patch link: https://lore.kernel.org/r/20231001054949.14624-1-dinghao.liu%40zju.edu.cn patch subject: [PATCH] [v3] ieee802154: ca8210: Fix a potential UAF in ca8210_probe config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20231001/202310011548.qyqmuodi-...@intel.com/config) compiler: m68k-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231001/202310011548.qyqmuodi-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202310011548.qyqmuodi-...@intel.com/ All warnings (new ones prefixed by >>): drivers/net/ieee802154/ca8210.c: In function 'ca8210_register_ext_clock': drivers/net/ieee802154/ca8210.c:2743:13: warning: unused variable 'ret' [-Wunused-variable] 2743 | int ret = 0; | ^~~ Please take care of this now unused variable after your re-factor. With this fixed and send out as v4 I am happy to get this applied to the wpan tree. regards Stefan Schmidt
Re: [PATCH 0/9] wpan-tools: switch to SPDX header for license and copyright
Hello. On 02.10.23 01:37, Alexander Aring wrote: Hi, On Tue, Sep 26, 2023 at 4:00 AM Stefan Schmidt wrote: Hello Miquel, Alex. On 25.09.23 09:22, Miquel Raynal wrote: Hi Stefan, ste...@datenfreihafen.org wrote on Sun, 24 Sep 2023 14:22:22 +0200: Hello. I took some time to convert wpan-tools over to using the SPDX header format to express copyright and license information. In this process we make the actual license (ISC) more clear and allow downstream users of wpan-tools to have a machine readable format for license compliance. We are also using the reuse tool in our CI to check for this now and generate a SBOM file as an example. Nice addition! Reviewed-by: Miquel Raynal Thanks Miquel. Alex, any remarks from your side or are you happy for me to land this in wpan-tools? looks okay to me. Thanks you two. Pushed to master now. regards Stefan Schmidt
Re: [PATCH 5/9] src/nl802154.h: switch file to SPDX header for license and copyright
Hello. On 02.10.23 01:33, Alexander Aring wrote: Hi, On Sun, Sep 24, 2023 at 8:24 AM Stefan Schmidt wrote: This file has its own commit as we are syncing it between the Linux kernel and this project when new netlink functionality is added. The same change needs to be done on the iLinux kernel side as well to avoid conflicts. the iLinux kernel? :) The Linux fork running on an iPhone? It's okay... you don't need to fix it. I had to add the reviewed by tag from Miquel anyway so I fixed the typo up before pushing. regards Stefan Schmidt
Re: [PATCH] [v2] ieee802154: ca8210: Fix a potential UAF in ca8210_probe
Hello.
On 26.09.23 10:02, Miquel Raynal wrote:
Hi Dinghao,
dinghao@zju.edu.cn wrote on Tue, 26 Sep 2023 11:22:44 +0800:
If of_clk_add_provider() fails in ca8210_register_ext_clock(),
it calls clk_unregister() to release priv->clk and returns an
error. However, the caller ca8210_probe() then calls ca8210_remove(),
where priv->clk is freed again in ca8210_unregister_ext_clock(). In
this case, a use-after-free may happen in the second time we call
clk_unregister().
Fix this by removing the first clk_unregister(). Also, priv->clk could
be an error code on failure of clk_register_fixed_rate(). Use
IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().
Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Missing Cc stable, this needs to be backported.
Signed-off-by: Dinghao Liu
---
Changelog:
v2: -Remove the first clk_unregister() instead of nulling priv->clk.
---
drivers/net/ieee802154/ca8210.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index aebb19f1b3a4..b35c6f59bd1a 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -2759,7 +2759,6 @@ static int ca8210_register_ext_clock(struct spi_device
*spi)
}
ret = of_clk_add_provider(np, of_clk_src_simple_get, priv->clk);
if (ret) {
- clk_unregister(priv->clk);
dev_crit(
&spi->dev,
"Failed to register external clock as clock provider\n"
I was hoping you would simplify this function a bit more.
@@ -2780,7 +2779,7 @@ static void ca8210_unregister_ext_clock(struct spi_device
*spi)
{
struct ca8210_priv *priv = spi_get_drvdata(spi);
- if (!priv->clk)
+ if (IS_ERR_OR_NULL(priv->clk))
return
of_clk_del_provider(spi->dev.of_node);
Alex, Stefan, who handles wpan and wpan/next this release?
IIRC it would be me for wpan and Alex for wpan-next.
regards
Stefan Schmidt
Re: [PATCH 0/9] wpan-tools: switch to SPDX header for license and copyright
Hello Miquel, Alex. On 25.09.23 09:22, Miquel Raynal wrote: Hi Stefan, ste...@datenfreihafen.org wrote on Sun, 24 Sep 2023 14:22:22 +0200: Hello. I took some time to convert wpan-tools over to using the SPDX header format to express copyright and license information. In this process we make the actual license (ISC) more clear and allow downstream users of wpan-tools to have a machine readable format for license compliance. We are also using the reuse tool in our CI to check for this now and generate a SBOM file as an example. Nice addition! Reviewed-by: Miquel Raynal Thanks Miquel. Alex, any remarks from your side or are you happy for me to land this in wpan-tools? regards Stefan Schmidt
[PATCH 9/9] workflow: add reuse job to check for REUSE compliance
The linter ensures we can catch problems early on and keeps the codebase reuse compliant. A big step for ard for all downstream users who care about license compliance and SBOM generation. As extra step we generate a SBOM file as artifact. Signed-off-by: Stefan Schmidt --- .github/workflows/reuse.yml | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 .github/workflows/reuse.yml diff --git a/.github/workflows/reuse.yml b/.github/workflows/reuse.yml new file mode 100644 index 000..194a7d7 --- /dev/null +++ b/.github/workflows/reuse.yml @@ -0,0 +1,19 @@ +# SPDX-FileCopyrightText: 2023 Stefan Schmidt +# +# SPDX-License-Identifier: ISC + +name: Check for REUSE compliance of wpan-tools +on: push + +jobs: + reuse: +runs-on: ubuntu-latest +steps: +- name: Check out repository + uses: actions/checkout@v4 +- name: Install reuse tool + run: pip3 install reuse +- name: Run reuse lint + run: reuse lint +- name: Create SBOM + run: reuse spdx > sbom.txt -- 2.41.0
[PATCH 6/9] examples: switch files to SPDX header for license and copyright
Signed-off-by: Stefan Schmidt --- examples/.gitignore | 4 examples/Makefile.am| 4 examples/README.examples| 4 examples/af_ieee802154_rx.c | 23 --- examples/af_ieee802154_tx.c | 23 --- examples/af_inet6_rx.c | 23 --- examples/af_inet6_tx.c | 23 --- examples/af_packet_rx.c | 23 --- examples/af_packet_tx.c | 23 --- 9 files changed, 36 insertions(+), 114 deletions(-) diff --git a/examples/.gitignore b/examples/.gitignore index 845e803..3dad378 100644 --- a/examples/.gitignore +++ b/examples/.gitignore @@ -1,3 +1,7 @@ +# SPDX-FileCopyrightText: 2016 Samsung Electronics Co., Ltd. +# +# SPDX-License-Identifier: ISC + /.deps /af_ieee802154_rx /af_ieee802154_tx diff --git a/examples/Makefile.am b/examples/Makefile.am index b475c1f..00bd991 100644 --- a/examples/Makefile.am +++ b/examples/Makefile.am @@ -1,3 +1,7 @@ +# SPDX-FileCopyrightText: 2016 Samsung Electronics Co., Ltd. +# +# SPDX-License-Identifier: ISC + noinst_PROGRAMS = af_ieee802154_tx \ af_ieee802154_rx \ af_packet_tx \ diff --git a/examples/README.examples b/examples/README.examples index 11e9424..bf69c90 100644 --- a/examples/README.examples +++ b/examples/README.examples @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2016 Samsung Electronics Co., Ltd. +// +// SPDX-License-Identifier: ISC + This folder contains various examples on how the Linux-wpan stack can be used from userspace, using the Linux socket interface. diff --git a/examples/af_ieee802154_rx.c b/examples/af_ieee802154_rx.c index 86ba707..4bfd7b6 100644 --- a/examples/af_ieee802154_rx.c +++ b/examples/af_ieee802154_rx.c @@ -1,23 +1,8 @@ -/* - * IEEE 802.15.4 socket example - * - * Copyright (C) 2016 Samsung Electronics Co., Ltd. - * - * Author: Stefan Schmidt - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - */ +// SPDX-FileCopyrightText: 2016 Samsung Electronics Co., Ltd. +// +// SPDX-License-Identifier: ISC +/* IEEE 802.15.4 socket example */ /* gcc af_ieee802154_rx.c -o af_ieee802154_rx */ #include diff --git a/examples/af_ieee802154_tx.c b/examples/af_ieee802154_tx.c index faad17e..7cbc8a1 100644 --- a/examples/af_ieee802154_tx.c +++ b/examples/af_ieee802154_tx.c @@ -1,23 +1,8 @@ -/* - * IEEE 802.15.4 socket example - * - * Copyright (C) 2016 Samsung Electronics Co., Ltd. - * - * Author: Stefan Schmidt - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - */ +// SPDX-FileCopyrightText: 2016 Samsung Electronics Co., Ltd. +// +// SPDX-License-Identifier: ISC +/* IEEE 802.15.4 socket example */ /* gcc af_ieee802154_tx.c -o af_ieee802154_tx */ #include diff --git a/examples/af_inet6_rx.c b/examples/af_inet6_rx.c index d512471..525e68d 100644 --- a/examples/af_inet6_rx.c +++ b/examples/af_inet6_rx.c @@ -1,23 +1,8 @@ -/* - * IEEE 802.15.4 socket example - * - * Copyright (C) 2016 Samsung Electronics Co., Ltd. - * - * Author: Stefan Schmidt - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
[PATCH 3/9] wpan-ping: switch files to SPDX header for license and copyright
Signed-off-by: Stefan Schmidt --- wpan-ping/.gitignore | 4 wpan-ping/Makefile.am | 4 wpan-ping/README.wpan-ping | 4 wpan-ping/wpan-ping.c | 22 +- 4 files changed, 17 insertions(+), 17 deletions(-) diff --git a/wpan-ping/.gitignore b/wpan-ping/.gitignore index 0e2e07a..4d78615 100644 --- a/wpan-ping/.gitignore +++ b/wpan-ping/.gitignore @@ -1,2 +1,6 @@ +# SPDX-FileCopyrightText: 2015 Stefan Schmidt +# +# SPDX-License-Identifier: ISC + .deps/ wpan-ping diff --git a/wpan-ping/Makefile.am b/wpan-ping/Makefile.am index 6021c95..5003205 100644 --- a/wpan-ping/Makefile.am +++ b/wpan-ping/Makefile.am @@ -1,3 +1,7 @@ +# SPDX-FileCopyrightText: 2015 Stefan Schmidt +# +# SPDX-License-Identifier: ISC + bin_PROGRAMS = wpan-ping wpan_ping_SOURCES = wpan-ping.c diff --git a/wpan-ping/README.wpan-ping b/wpan-ping/README.wpan-ping index 4827e21..5d18661 100644 --- a/wpan-ping/README.wpan-ping +++ b/wpan-ping/README.wpan-ping @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2015 Stefan Schmidt +// +// SPDX-License-Identifier: ISC + wpan-ping aims to offer ping/ping6 like functionality on a IEEE 802.15.4 level. No control message protocol is defined so we will simply use DGRAM's over a diff --git a/wpan-ping/wpan-ping.c b/wpan-ping/wpan-ping.c index 791346c..d82b1f0 100644 --- a/wpan-ping/wpan-ping.c +++ b/wpan-ping/wpan-ping.c @@ -1,20 +1,8 @@ -/* - * Linux IEEE 802.15.4 ping tool - * - * Copyright (C) 2015 Stefan Schmidt - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - */ +// SPDX-FileCopyrightText: 2015 Stefan Schmidt +// +// SPDX-License-Identifier: ISC + +/* Linux IEEE 802.15.4 ping tool */ #ifdef HAVE_CONFIG_H #include -- 2.41.0
[PATCH 8/9] misc: switch remaining files to SPDX header for license and copyright
Signed-off-by: Stefan Schmidt
---
.github/workflows/main.yml | 4
.gitignore | 4
Makefile.am| 4
autogen.sh | 4
configure.ac | 4
5 files changed, 20 insertions(+)
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index c7b878f..cde0f19 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -1,3 +1,7 @@
+# SPDX-FileCopyrightText: 2023 Stefan Schmidt
+#
+# SPDX-License-Identifier: ISC
+
name: Basic compile test for wpan-tools
on: push
diff --git a/.gitignore b/.gitignore
index cad8dee..1d2621b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,7 @@
+# SPDX-FileCopyrightText: 2014 Alexander Aring
+#
+# SPDX-License-Identifier: ISC
+
*.o
tags
TAGS
diff --git a/Makefile.am b/Makefile.am
index 3f15825..50893e7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,3 +1,7 @@
+# SPDX-FileCopyrightText: 2014 Alexander Aring
+#
+# SPDX-License-Identifier: ISC
+
EXTRA_DIST =
CLEANFILES =
ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
diff --git a/autogen.sh b/autogen.sh
index 0d60b0a..db24799 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -1,5 +1,9 @@
#!/bin/sh -e
+# SPDX-FileCopyrightText: 2014 Alexander Aring
+#
+# SPDX-License-Identifier: ISC
+
if [ -f .git/hooks/pre-commit.sample -a ! -f .git/hooks/pre-commit ] ; then
cp -p .git/hooks/pre-commit.sample .git/hooks/pre-commit && \
chmod +x .git/hooks/pre-commit && \
diff --git a/configure.ac b/configure.ac
index f7bd7f7..fee4b44 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,3 +1,7 @@
+dnl SPDX-FileCopyrightText: 2014 Alexander Aring
+dnl
+dnl SPDX-License-Identifier: ISC
+
AC_PREREQ(2.60)
AC_INIT([Userspace tools for Linux IEEE 802.15.4 stack],
[0.9], [linux-wpan@vger.kernel.org], [wpan-tools],
--
2.41.0
[PATCH 5/9] src/nl802154.h: switch file to SPDX header for license and copyright
This file has its own commit as we are syncing it between the Linux kernel and this project when new netlink functionality is added. The same change needs to be done on the iLinux kernel side as well to avoid conflicts. Signed-off-by: Stefan Schmidt --- src/nl802154.h | 24 ++-- 1 file changed, 6 insertions(+), 18 deletions(-) diff --git a/src/nl802154.h b/src/nl802154.h index dbad1c9..410ee95 100644 --- a/src/nl802154.h +++ b/src/nl802154.h @@ -1,23 +1,11 @@ #ifndef __NL802154_H #define __NL802154_H -/* - * 802.15.4 netlink interface public header - * - * Copyright 2014 Alexander Aring - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - * - */ + +// SPDX-FileCopyrightText: 2014 Alexander Aring +// +// SPDX-License-Identifier: ISC + +/* 802.15.4 netlink interface public header */ #define NL802154_GENL_NAME "nl802154" -- 2.41.0
[PATCH 7/9] src: switch files to SPDX header for license and copyright
Signed-off-by: Stefan Schmidt --- src/.gitignore | 4 src/Makefile.am | 4 src/event.c | 4 src/info.c | 4 src/interface.c | 4 src/iwpan.c | 3 +++ src/iwpan.h | 4 src/mac.c | 4 src/nl_extras.h | 4 src/phy.c | 4 src/scan.c | 4 src/sections.c | 4 12 files changed, 47 insertions(+) diff --git a/src/.gitignore b/src/.gitignore index a0a601d..efe0d9e 100644 --- a/src/.gitignore +++ b/src/.gitignore @@ -1,3 +1,7 @@ +# SPDX-FileCopyrightText: 2014 Alexander Aring +# +# SPDX-License-Identifier: ISC + .deps iwpan *.o diff --git a/src/Makefile.am b/src/Makefile.am index 7933daf..23b54db 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,3 +1,7 @@ +# SPDX-FileCopyrightText: 2014 Alexander Aring +# +# SPDX-License-Identifier: ISC + bin_PROGRAMS = \ iwpan diff --git a/src/event.c b/src/event.c index 5ec597d..d47e778 100644 --- a/src/event.c +++ b/src/event.c @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2023 David Girault +// +// SPDX-License-Identifier: ISC + #include #include #include diff --git a/src/info.c b/src/info.c index 8ed5e4f..8b7e98e 100644 --- a/src/info.c +++ b/src/info.c @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2014 Alexander Aring +// +// SPDX-License-Identifier: ISC + #include #include #include diff --git a/src/interface.c b/src/interface.c index 85d40a8..c078a25 100644 --- a/src/interface.c +++ b/src/interface.c @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2014 Alexander Aring +// +// SPDX-License-Identifier: ISC + #include #include #include diff --git a/src/iwpan.c b/src/iwpan.c index 3cf5fe2..796d380 100644 --- a/src/iwpan.c +++ b/src/iwpan.c @@ -1,3 +1,6 @@ +// SPDX-FileCopyrightText: 2014 Alexander Aring +// +// SPDX-License-Identifier: ISC #include #include diff --git a/src/iwpan.h b/src/iwpan.h index 406940a..24cc926 100644 --- a/src/iwpan.h +++ b/src/iwpan.h @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2014 Alexander Aring +// +// SPDX-License-Identifier: ISC + #ifndef __IWPAN_H #define __IWPAN_H diff --git a/src/mac.c b/src/mac.c index 286802c..79b3ab9 100644 --- a/src/mac.c +++ b/src/mac.c @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2014 Alexander Aring +// +// SPDX-License-Identifier: ISC + #include #include #include diff --git a/src/nl_extras.h b/src/nl_extras.h index 37844f9..2a35f5d 100644 --- a/src/nl_extras.h +++ b/src/nl_extras.h @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2014 Alexander Aring +// +// SPDX-License-Identifier: ISC + #ifndef __NL_EXTRAS_H #define __NL_EXTRAS_H diff --git a/src/phy.c b/src/phy.c index f97900f..f042588 100644 --- a/src/phy.c +++ b/src/phy.c @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2014 Alexander Aring +// +// SPDX-License-Identifier: ISC + #include #include #include diff --git a/src/scan.c b/src/scan.c index e92702d..993e367 100644 --- a/src/scan.c +++ b/src/scan.c @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2023 David Girault +// +// SPDX-License-Identifier: ISC + #include #include #include diff --git a/src/sections.c b/src/sections.c index 40fdc94..8327fea 100644 --- a/src/sections.c +++ b/src/sections.c @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2014 Alexander Aring +// +// SPDX-License-Identifier: ISC + #include "iwpan.h" SECTION(get); -- 2.41.0
[PATCH 2/9] license: clearly indicate license in file name and use new LICENSES folder
For now you would need to identify the license by its actual license text. We never had mentioned ISC anywhere as the license. Make this clear by the filename (in a LICENSES folder as it is practice with reuse). Keeping the old COPYING file around as symlink. Signed-off-by: Stefan Schmidt --- COPYING | 25 + LICENSES/ISC.txt | 23 +++ 2 files changed, 24 insertions(+), 24 deletions(-) mode change 100644 => 12 COPYING create mode 100644 LICENSES/ISC.txt diff --git a/COPYING b/COPYING deleted file mode 100644 index f579f35..000 --- a/COPYING +++ /dev/null @@ -1,24 +0,0 @@ -Copyright (c) 2014 Alexander Aring -Copyright (c) 2015 Stefan Schmidt - - -Code is based on iw tool. - -Original Authors: - -Copyright (c) 2007, 2008 Johannes Berg -Copyright (c) 2007 Andy Lutomirski -Copyright (c) 2007 Mike Kershaw -Copyright (c) 2008-2009Luis R. Rodriguez - -Permission to use, copy, modify, and/or distribute this software for any -purpose with or without fee is hereby granted, provided that the above -copyright notice and this permission notice appear in all copies. - -THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES -WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF -MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR -ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES -WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN -ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF -OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. diff --git a/COPYING b/COPYING new file mode 12 index 000..afdb398 --- /dev/null +++ b/COPYING @@ -0,0 +1 @@ +LICENSES/ISC.txt \ No newline at end of file diff --git a/LICENSES/ISC.txt b/LICENSES/ISC.txt new file mode 100644 index 000..72b508c --- /dev/null +++ b/LICENSES/ISC.txt @@ -0,0 +1,23 @@ +Copyright (c) 2014 Alexander Aring +Copyright (c) 2015 Stefan Schmidt + +Code is based on iw tool. + +Original Authors: + +Copyright (c) 2007, 2008 Johannes Berg +Copyright (c) 2007 Andy Lutomirski +Copyright (c) 2007 Mike Kershaw +Copyright (c) 2008-2009Luis R. Rodriguez + +Permission to use, copy, modify, and/or distribute this software for any +purpose with or without fee is hereby granted, provided that the above +copyright notice and this permission notice appear in all copies. + +THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -- 2.41.0
[PATCH 4/9] wpan-hwsim: switch files to SPDX header for license and copyright
Signed-off-by: Stefan Schmidt --- wpan-hwsim/Makefile.am | 4 wpan-hwsim/mac802154_hwsim.h | 4 wpan-hwsim/wpan-hwsim.c | 22 +- 3 files changed, 13 insertions(+), 17 deletions(-) diff --git a/wpan-hwsim/Makefile.am b/wpan-hwsim/Makefile.am index 0587178..e7ff242 100644 --- a/wpan-hwsim/Makefile.am +++ b/wpan-hwsim/Makefile.am @@ -1,3 +1,7 @@ +# SPDX-FileCopyrightText: 2018 Alexander Aring +# +# SPDX-License-Identifier: ISC + bin_PROGRAMS = wpan-hwsim wpan_hwsim_SOURCES = wpan-hwsim.c \ diff --git a/wpan-hwsim/mac802154_hwsim.h b/wpan-hwsim/mac802154_hwsim.h index 6c6e30e..62e6962 100644 --- a/wpan-hwsim/mac802154_hwsim.h +++ b/wpan-hwsim/mac802154_hwsim.h @@ -1,3 +1,7 @@ +// SPDX-FileCopyrightText: 2018 Alexander Aring +// +// SPDX-License-Identifier: ISC + #ifndef __MAC802154_HWSIM_H #define __MAC802154_HWSIM_H diff --git a/wpan-hwsim/wpan-hwsim.c b/wpan-hwsim/wpan-hwsim.c index 0a7c492..e1f2fe5 100644 --- a/wpan-hwsim/wpan-hwsim.c +++ b/wpan-hwsim/wpan-hwsim.c @@ -1,20 +1,8 @@ -/* - * Linux IEEE 802.15.4 hwsim tool - * - * Copyright (C) 2018 Alexander Aring - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - */ +// SPDX-FileCopyrightText: 2018 Alexander Aring +// +// SPDX-License-Identifier: ISC + +/* Linux IEEE 802.15.4 hwsim tool */ #include #include -- 2.41.0
[PATCH 0/9] wpan-tools: switch to SPDX header for license and copyright
Hello. I took some time to convert wpan-tools over to using the SPDX header format to express copyright and license information. In this process we make the actual license (ISC) more clear and allow downstream users of wpan-tools to have a machine readable format for license compliance. We are also using the reuse tool in our CI to check for this now and generate a SBOM file as an example. regards Stefan Schmidt Stefan Schmidt (9): m4: remove empty folder which only holds a .gitignore file license: clearly indicate license in file name and use new LICENSES folder wpan-ping: switch files to SPDX header for license and copyright wpan-hwsim: switch files to SPDX header for license and copyright src/nl802154.h: switch file to SPDX header for license and copyright examples: switch files to SPDX header for license and copyright src: switch files to SPDX header for license and copyright misc: switch remaining files to SPDX header for license and copyright workflow: add reuse job to check for REUSE compliance .github/workflows/main.yml | 4 .github/workflows/reuse.yml | 19 +++ .gitignore | 5 + COPYING | 25 + LICENSES/ISC.txt | 23 +++ Makefile.am | 4 autogen.sh | 4 configure.ac | 4 examples/.gitignore | 4 examples/Makefile.am | 4 examples/README.examples | 4 examples/af_ieee802154_rx.c | 23 --- examples/af_ieee802154_tx.c | 23 --- examples/af_inet6_rx.c | 23 --- examples/af_inet6_tx.c | 23 --- examples/af_packet_rx.c | 23 --- examples/af_packet_tx.c | 23 --- m4/.gitignore| 5 - src/.gitignore | 4 src/Makefile.am | 4 src/event.c | 4 src/info.c | 4 src/interface.c | 4 src/iwpan.c | 3 +++ src/iwpan.h | 4 src/mac.c| 4 src/nl802154.h | 24 ++-- src/nl_extras.h | 4 src/phy.c| 4 src/scan.c | 4 src/sections.c | 4 wpan-hwsim/Makefile.am | 4 wpan-hwsim/mac802154_hwsim.h | 4 wpan-hwsim/wpan-hwsim.c | 22 +- wpan-ping/.gitignore | 4 wpan-ping/Makefile.am| 4 wpan-ping/README.wpan-ping | 4 wpan-ping/wpan-ping.c| 22 +- 38 files changed, 183 insertions(+), 195 deletions(-) create mode 100644 .github/workflows/reuse.yml mode change 100644 => 12 COPYING create mode 100644 LICENSES/ISC.txt delete mode 100644 m4/.gitignore -- 2.41.0
[PATCH 1/9] m4: remove empty folder which only holds a .gitignore file
we have no project specific files in the m4 folder, it just gets generated from autotools. Ignore the complete folder in the top level .gitignore instead. Signed-off-by: Stefan Schmidt --- .gitignore| 1 + m4/.gitignore | 5 - 2 files changed, 1 insertion(+), 5 deletions(-) delete mode 100644 m4/.gitignore diff --git a/.gitignore b/.gitignore index ef71c6a..cad8dee 100644 --- a/.gitignore +++ b/.gitignore @@ -10,3 +10,4 @@ config.* configure libtool stamp-h1 +m4/ diff --git a/m4/.gitignore b/m4/.gitignore deleted file mode 100644 index 38066dd..000 --- a/m4/.gitignore +++ /dev/null @@ -1,5 +0,0 @@ -libtool.m4 -ltoptions.m4 -ltsugar.m4 -ltversion.m4 -lt~obsolete.m4 -- 2.41.0
Re: [PATCH wpan-next v3 00/11] ieee802154: Associations between devices
Hello Miquel On 18.09.23 17:07, Miquel Raynal wrote: Hello, [I know we are in the middle of the merge window, I don't think it matters on the wpan side, so as the wpan subsystem did not evolve much since the previous merge window I figured I would not delay the sending of this series given the fact that I should have send it at the beginning of the summer...] 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 associate pan_id 2 coord $COORD iwpan dev list_associations iwpan 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: 0x / 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 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 | 69 ++ include/net/ieee802154_netdev.h | 60 + include/net/nl802154.h | 22 +- net/ieee802154/Makefile | 2 +- net/ieee802154/core.c | 24 ++ net/ieee802154/nl802154.c | 223 +- net/ieee802154/pan.c| 115 + 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, 1191 insertions(+), 13 deletions(-) create mode 100644 net/ieee802154/pan.c With my requests for patch 02/11 taken into account and the fallout for the experimental config options fixed (as krobot detected) I am happy with this patchset. Acked-by: Stefan Schmidt regards Stefan Schmidt
Re: [PATCH wpan-next v3 02/11] ieee802154: Internal PAN management
Hello.
On 18.09.23 17:08, Miquel Raynal wrote:
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
---
include/net/cfg802154.h | 46 +
net/ieee802154/Makefile | 2 +-
net/ieee802154/core.c | 2 ++
net/ieee802154/pan.c| 75 +
4 files changed, 124 insertions(+), 1 deletion(-)
create mode 100644 net/ieee802154/pan.c
diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index f79ce133e51a..6c7193b4873c 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,29 @@ 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
+ */
+bool cfg802154_device_is_associated(struct wpan_dev *wpan_dev);
The return value still missing in kdoc. Seems you missed this from my
last review. :-)
+/**
+ * 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 ..012b5e821d54
--- /dev/null
+++ b/net/ieee802154/pan.c
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * IEEE 802.15.4 PAN management
+ *
+ * Copyright (C) 2021 Qorvo US, Inc
Feel free to extend the copyright years to 2023 as well.
regards
Stefan Schmidt
Re: [PATCH wpan-next v2 11/11] ieee802154: Give the user the association list
Hello Miquel.
On 18.09.23 09:08, Miquel Raynal wrote:
Hi Stefan,
ste...@datenfreihafen.org wrote on Sat, 16 Sep 2023 17:36:41 +0200:
Hello Miquel.
On 01.09.23 19:05, Miquel Raynal wrote:
Upon request, we must be able to provide to the user the list of
associations currently in place. Let's add a new netlink command and
attribute for this purpose.
Signed-off-by: Miquel Raynal
---
include/net/nl802154.h| 18 ++-
net/ieee802154/nl802154.c | 107 ++
2 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index 8b26faae49e8..4c752f799957 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -81,6 +81,7 @@ enum nl802154_commands {
NL802154_CMD_ASSOCIATE,
NL802154_CMD_DISASSOCIATE,
NL802154_CMD_SET_MAX_ASSOCIATIONS,
+ NL802154_CMD_LIST_ASSOCIATIONS,
> /* add new commands above here */
> @@ -151,6 +152,7 @@ enum nl802154_attrs {
NL802154_ATTR_SCAN_DONE_REASON,
NL802154_ATTR_BEACON_INTERVAL,
NL802154_ATTR_MAX_ASSOCIATIONS,
+ NL802154_ATTR_PEER,
> /* add attributes here, update the policy in nl802154.c */
> @@ -389,8 +391,6 @@ enum nl802154_supported_bool_states {
NL802154_SUPPORTED_BOOL_MAX = __NL802154_SUPPORTED_BOOL_AFTER_LAST - 1
};
> -#ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
-
enum nl802154_dev_addr_modes {
NL802154_DEV_ADDR_NONE,
__NL802154_DEV_ADDR_INVALID,
@@ -410,12 +410,26 @@ enum nl802154_dev_addr_attrs {
NL802154_DEV_ADDR_ATTR_SHORT,
NL802154_DEV_ADDR_ATTR_EXTENDED,
NL802154_DEV_ADDR_ATTR_PAD,
+ NL802154_DEV_ADDR_ATTR_PEER_TYPE,
> /* keep last */
__NL802154_DEV_ADDR_ATTR_AFTER_LAST,
NL802154_DEV_ADDR_ATTR_MAX = __NL802154_DEV_ADDR_ATTR_AFTER_LAST - 1
};
> +enum nl802154_peer_type {
+ NL802154_PEER_TYPE_UNSPEC,
+
+ NL802154_PEER_TYPE_PARENT,
+ NL802154_PEER_TYPE_CHILD,
+
+ /* keep last */
+ __NL802154_PEER_TYPE_AFTER_LAST,
+ NL802154_PEER_TYPE_MAX = __NL802154_PEER_TYPE_AFTER_LAST - 1
+};
+
+#ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
+
enum nl802154_key_id_modes {
NL802154_KEY_ID_MODE_IMPLICIT,
NL802154_KEY_ID_MODE_INDEX,
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index e16e57fc34d0..e26d7cec02ce 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -235,6 +235,7 @@ static const struct nla_policy
nl802154_policy[NL802154_ATTR_MAX+1] = {
[NL802154_ATTR_BEACON_INTERVAL] =
NLA_POLICY_MAX(NLA_U8, IEEE802154_ACTIVE_SCAN_DURATION),
[NL802154_ATTR_MAX_ASSOCIATIONS] = { .type = NLA_U32 },
+ [NL802154_ATTR_PEER] = { .type = NLA_NESTED },
> #ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
[NL802154_ATTR_SEC_ENABLED] = { .type = NLA_U8, },
@@ -1717,6 +1718,107 @@ static int nl802154_set_max_associations(struct sk_buff
*skb, struct genl_info *
return 0;
}
> +static int nl802154_send_peer_info(struct sk_buff *msg,
+ struct netlink_callback *cb,
+ u32 seq, int flags,
+ struct cfg802154_registered_device *rdev,
+ struct wpan_dev *wpan_dev,
+ struct ieee802154_pan_device *peer,
+ enum nl802154_peer_type type)
+{
+ struct nlattr *nla;
+ void *hdr;
+
+ ASSERT_RTNL();
+
+ hdr = nl802154hdr_put(msg, NETLINK_CB(cb->skb).portid, seq, flags,
+ NL802154_CMD_LIST_ASSOCIATIONS);
+ if (!hdr)
+ return -ENOBUFS;
+
+ genl_dump_check_consistent(cb, hdr);
+
+ if (nla_put_u32(msg, NL802154_ATTR_GENERATION,
+ wpan_dev->association_generation))
This one still confuses me. I only ever see it increasing in the code. Did I
miss something?
I think I took inspiration from nl802154_send_wpan_phy() and
and nl802154_send_iface() which both use an increasing counter to tell
userspace the "version" of the data that is being sent. If the
"version" numbers are identical, the user (I guess) can assume nothing
changed and save itself from parsing the whole payload or something
like that.
TBH I just tried here to mimic the existing behavior inside
nl802154_send_peer_info(), but I will drop that counter with no regrets.
Yes, please drop for now. I does not serve a real purpose at the moment.
If we need such a mechanism for userspace later we can see how we
implement it when we have clear use cases.
regards
Stefan Schmidt
Re: [PATCH wpan-next v2 02/11] ieee802154: Internal PAN management
Hello Miquel.
On 01.09.23 19:04, Miquel Raynal wrote:
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
---
include/net/cfg802154.h | 46
net/ieee802154/Makefile | 2 +-
net/ieee802154/core.c | 2 ++
net/ieee802154/pan.c| 66 +
4 files changed, 115 insertions(+), 1 deletion(-)
create mode 100644 net/ieee802154/pan.c
diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index f79ce133e51a..6c7193b4873c 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,29 @@ 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
Missing return value documentation.
+ */
+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 ..e2a12a42ba2b
--- /dev/null
+++ b/net/ieee802154/pan.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * IEEE 802.15.4 PAN management
+ *
+ * Copyright (C) 2021 Qorvo US, Inc
+ * Authors:
+ * - David Girault
+ * - Miquel Raynal
+ */
+
+#include
+#include
+#include
+
+static bool cfg802154_same_addr(struct ieee802154_pan_device *a,
+ struct ieee802154_addr *b)
+{
+ if (!a || !b)
+ return false;
+
+ switch (b->mode) {
+ case IEEE802154_ADDR_SHORT:
+ return a->short_addr == b->short_addr;
+ case IEEE802154_ADDR_LONG:
+ return a->extended_addr == b->extended_addr;
+ default:
+ return false;
+ }
+}
Don't we already have such a helper already?
regards
Stefan Schmidt
Re: [PATCH wpan-next v2 11/11] ieee802154: Give the user the association list
Hello Miquel.
On 01.09.23 19:05, Miquel Raynal wrote:
Upon request, we must be able to provide to the user the list of
associations currently in place. Let's add a new netlink command and
attribute for this purpose.
Signed-off-by: Miquel Raynal
---
include/net/nl802154.h| 18 ++-
net/ieee802154/nl802154.c | 107 ++
2 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/include/net/nl802154.h b/include/net/nl802154.h
index 8b26faae49e8..4c752f799957 100644
--- a/include/net/nl802154.h
+++ b/include/net/nl802154.h
@@ -81,6 +81,7 @@ enum nl802154_commands {
NL802154_CMD_ASSOCIATE,
NL802154_CMD_DISASSOCIATE,
NL802154_CMD_SET_MAX_ASSOCIATIONS,
+ NL802154_CMD_LIST_ASSOCIATIONS,
/* add new commands above here */
@@ -151,6 +152,7 @@ enum nl802154_attrs {
NL802154_ATTR_SCAN_DONE_REASON,
NL802154_ATTR_BEACON_INTERVAL,
NL802154_ATTR_MAX_ASSOCIATIONS,
+ NL802154_ATTR_PEER,
/* add attributes here, update the policy in nl802154.c */
@@ -389,8 +391,6 @@ enum nl802154_supported_bool_states {
NL802154_SUPPORTED_BOOL_MAX = __NL802154_SUPPORTED_BOOL_AFTER_LAST - 1
};
-#ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
-
enum nl802154_dev_addr_modes {
NL802154_DEV_ADDR_NONE,
__NL802154_DEV_ADDR_INVALID,
@@ -410,12 +410,26 @@ enum nl802154_dev_addr_attrs {
NL802154_DEV_ADDR_ATTR_SHORT,
NL802154_DEV_ADDR_ATTR_EXTENDED,
NL802154_DEV_ADDR_ATTR_PAD,
+ NL802154_DEV_ADDR_ATTR_PEER_TYPE,
/* keep last */
__NL802154_DEV_ADDR_ATTR_AFTER_LAST,
NL802154_DEV_ADDR_ATTR_MAX = __NL802154_DEV_ADDR_ATTR_AFTER_LAST - 1
};
+enum nl802154_peer_type {
+ NL802154_PEER_TYPE_UNSPEC,
+
+ NL802154_PEER_TYPE_PARENT,
+ NL802154_PEER_TYPE_CHILD,
+
+ /* keep last */
+ __NL802154_PEER_TYPE_AFTER_LAST,
+ NL802154_PEER_TYPE_MAX = __NL802154_PEER_TYPE_AFTER_LAST - 1
+};
+
+#ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
+
enum nl802154_key_id_modes {
NL802154_KEY_ID_MODE_IMPLICIT,
NL802154_KEY_ID_MODE_INDEX,
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index e16e57fc34d0..e26d7cec02ce 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -235,6 +235,7 @@ static const struct nla_policy
nl802154_policy[NL802154_ATTR_MAX+1] = {
[NL802154_ATTR_BEACON_INTERVAL] =
NLA_POLICY_MAX(NLA_U8, IEEE802154_ACTIVE_SCAN_DURATION),
[NL802154_ATTR_MAX_ASSOCIATIONS] = { .type = NLA_U32 },
+ [NL802154_ATTR_PEER] = { .type = NLA_NESTED },
#ifdef CONFIG_IEEE802154_NL802154_EXPERIMENTAL
[NL802154_ATTR_SEC_ENABLED] = { .type = NLA_U8, },
@@ -1717,6 +1718,107 @@ static int nl802154_set_max_associations(struct sk_buff
*skb, struct genl_info *
return 0;
}
+static int nl802154_send_peer_info(struct sk_buff *msg,
+ struct netlink_callback *cb,
+ u32 seq, int flags,
+ struct cfg802154_registered_device *rdev,
+ struct wpan_dev *wpan_dev,
+ struct ieee802154_pan_device *peer,
+ enum nl802154_peer_type type)
+{
+ struct nlattr *nla;
+ void *hdr;
+
+ ASSERT_RTNL();
+
+ hdr = nl802154hdr_put(msg, NETLINK_CB(cb->skb).portid, seq, flags,
+ NL802154_CMD_LIST_ASSOCIATIONS);
+ if (!hdr)
+ return -ENOBUFS;
+
+ genl_dump_check_consistent(cb, hdr);
+
+ if (nla_put_u32(msg, NL802154_ATTR_GENERATION,
+ wpan_dev->association_generation))
This one still confuses me. I only ever see it increasing in the code.
Did I miss something?
regards
Stefan Schmidt
Re: [PATCH wpan-next v2 04/11] mac802154: Handle associating
Hello Miquel.
On 01.09.23 19:04, Miquel Raynal wrote:
Joining a PAN officially goes by associating with a coordinator. This
coordinator may have been discovered thanks to the beacons it sent in
the past. Add support to the MAC layer for these associations, which
require:
- Sending an association request
- Receiving an association response
The association response contains the association status, eventually a
reason if the association was unsuccessful, and finally a short address
that we should use for intra-PAN communication from now on, if we
required one (which is the default, and not yet configurable).
Signed-off-by: Miquel Raynal
---
include/net/cfg802154.h | 1 +
include/net/ieee802154_netdev.h | 5 ++
net/ieee802154/core.c | 14
net/mac802154/cfg.c | 70 ++
net/mac802154/ieee802154_i.h| 19 +
net/mac802154/main.c| 2 +
net/mac802154/rx.c | 9 +++
net/mac802154/scan.c| 127
8 files changed, 247 insertions(+)
diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index 1c22cef77425..df1f6c905c2d 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -503,6 +503,7 @@ struct wpan_dev {
struct mutex association_lock;
struct ieee802154_pan_device *parent;
struct list_head children;
+ unsigned int association_generation;
Could you explain what you are suing this for? I see it icreases in
free_peer_structure as weel as in associate. But I am not clear what
this is used for.
regards
Stefan Schmidt
Re: [PATCH wpan-next v2 07/11] mac802154: Handle association requests from peers
+ b/net/mac802154/rx.c
@@ -102,6 +102,14 @@ void mac802154_rx_mac_cmd_worker(struct work_struct *work)
mac802154_process_association_resp(mac_pkt->sdata,
mac_pkt->skb);
break;
+ case IEEE802154_CMD_ASSOCIATION_REQ:
+ dev_dbg(&mac_pkt->sdata->dev->dev, "processing ASSOC REQ\n");
+ if (mac_pkt->sdata->wpan_dev.iftype != NL802154_IFTYPE_COORD)
+ break;
+
+ mac802154_process_association_req(mac_pkt->sdata, mac_pkt->skb);
+ break;
+
default:
break;
}
diff --git a/net/mac802154/scan.c b/net/mac802154/scan.c
index e2f2e1235ec6..9f55b2314fe5 100644
--- a/net/mac802154/scan.c
+++ b/net/mac802154/scan.c
@@ -697,3 +697,150 @@ int mac802154_send_disassociation_notif(struct
ieee802154_sub_if_data *sdata,
dev_dbg(&sdata->dev->dev, "DISASSOC ACK received from %8phC\n",
&teaddr);
return 0;
}
+
+static int
+mac802154_send_association_resp_locked(struct ieee802154_sub_if_data *sdata,
+ struct ieee802154_pan_device *target,
+ struct ieee802154_assoc_resp_pl
*assoc_resp_pl)
+{
+ u64 teaddr = swab64((__force u64)target->extended_addr);
+ struct ieee802154_association_resp_frame frame = {};
+ struct ieee802154_local *local = sdata->local;
+ struct wpan_dev *wpan_dev = &sdata->wpan_dev;
+ struct sk_buff *skb;
+ int ret;
+
+ frame.mhr.fc.type = IEEE802154_FC_TYPE_MAC_CMD;
+ frame.mhr.fc.security_enabled = 0;
+ frame.mhr.fc.frame_pending = 0;
+ frame.mhr.fc.ack_request = 1; /* We always expect an ack here */
+ frame.mhr.fc.intra_pan = 1;
+ frame.mhr.fc.dest_addr_mode = IEEE802154_EXTENDED_ADDRESSING;
+ frame.mhr.fc.version = IEEE802154_2003_STD;
+ frame.mhr.fc.source_addr_mode = IEEE802154_EXTENDED_ADDRESSING;
+ frame.mhr.seq = 10;
Where does the 10 come from and what is the meaning?
regards
Stefan Schmidt
Re: [PRQ#43765] Deletion Request for teamspeak3-kde-link-fix-hack
Unneeded package, functionally a duplicate of the earlier-existing 'teamspeak3-kde-wrapper'. This is not true. 'teamspeak3-kde-wrapper' works entirely differently and comes with its own drawbacks. This package also violates Arch packaging guidelines by putting a script in '/usr/local/bin'. That's correct - hence the name including "hack" - but unfortunately necessary to accomplish its goal. The intention of this package is to unset some environment variables set by teamspeak3 which causes desktop integration issues on KDE. But this solution will affect every process that is opened via xdg-open, not just teamspeak3. That's the entire point, stopping parent processes (ts3 in this case) from polluting the environment of a process started by xdg-open. So I am asking for the deletion of this bad 'hack'. The 'teamspeak3-kde-wrapper' is a much more civilized solution to the same problem. I strongly disagree. Not only does 'teamspeak3-kde-wrapper' provide a wrapper for TeamSpeak, requiring you to remember to start TeamSpeak 3 via this wrapper because all the other launchers remain broken, it also isn't a solution. It's a workaround, one which I found not to be sufficient for me. The solution would be for the TS3 devs to fix passing on the environment variables from their launcher script, something which they haven't done despite the issue being known to them for at least five years.
[yocto] [meta-zephyr][PATCH] zephyr-openthread-rcp: Enable Thread 1.2 capabilities in RCP build
From: Stefan Schmidt
When running an up-to-date userspace component, like otbr-agent or
ot-daemon, with Thread 1.2 enabled we need a firmware matching this
capabilities.
Signed-off-by: Stefan Schmidt
---
.../recipes-kernel/zephyr-kernel/zephyr-openthread-rcp.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-openthread-rcp.bb
b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-openthread-rcp.bb
index 708e56a..6d3f860 100644
--- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-openthread-rcp.bb
+++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-openthread-rcp.bb
@@ -2,7 +2,7 @@ include zephyr-sample.inc
ZEPHYR_SRC_DIR = "${S}/samples/net/openthread/coprocessor"
-EXTRA_OECMAKE += "-DCONF_FILE="prj.conf overlay-rcp.conf
overlay-usb-nrf-br.conf" -DDTC_OVERLAY_FILE="usb.overlay""
+EXTRA_OECMAKE += "-DCONF_FILE="prj.conf overlay-rcp.conf
overlay-usb-nrf-br.conf" -DDTC_OVERLAY_FILE="usb.overlay"
-DCONFIG_OPENTHREAD_THREAD_VERSION_1_2=y"
# The overlay config and OpenThread itself imposes some specific requirements
# towards the boards (e.g. flash layout and ieee802154 radio) so we need to
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56879): https://lists.yoctoproject.org/g/yocto/message/56879
Mute This Topic: https://lists.yoctoproject.org/mt/90682612/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH] ot-br-posix: Fix build with gcc
Hello Khem.
On 19.04.22 23:08, Khem Raj wrote:
Signed-off-by: Khem Raj
Cc: Stefan Schmidt
---
...sable-nonnull-compare-warning-on-gcc.patch | 40 +++
.../openthread/ot-br-posix_git.bb | 1 +
2 files changed, 41 insertions(+)
create mode 100644
meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-cmake-Disable-nonnull-compare-warning-on-gcc.patch
diff --git
a/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-cmake-Disable-nonnull-compare-warning-on-gcc.patch
b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-cmake-Disable-nonnull-compare-warning-on-gcc.patch
new file mode 100644
index 00..f0bb392a9f
--- /dev/null
+++
b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-cmake-Disable-nonnull-compare-warning-on-gcc.patch
@@ -0,0 +1,40 @@
+From aa706d714294b83db696de2beca9a722a512796f Mon Sep 17 00:00:00 2001
+From: Khem Raj
+Date: Tue, 19 Apr 2022 14:04:40 -0700
+Subject: [PATCH] cmake: Disable nonnull-compare warning on gcc
+
+GCC finds a legit warning which clang does not on code like this
+
+class Message;
+void SendResponse(Message & aMessage)
+{
+if ((&aMessage) != nullptr) { return; }
+}
+
+Perhaps it should be fixed upstream but for now disable treating this
+warning as error when using gcc
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj
+---
+ CMakeLists.txt | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 59a567e729..3134740ff6 100644
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -57,6 +57,10 @@ endif()
+
+ set(CMAKE_CXX_EXTENSIONS OFF)
+
++if (CMAKE_CXX_COMPILER_ID MATCHES "GNU")
++ add_compile_options(-Wno-error=nonnull-compare)
++endif()
++
+ if (OTBR_COVERAGE AND CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
+ message(STATUS "Coverage: ON")
+ target_compile_options(otbr-config INTERFACE -g -O0 --coverage)
+--
+2.36.0
+
diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb
b/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb
index c1af388627..a16b77849e 100644
--- a/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb
+++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb
@@ -16,6 +16,7 @@ PV = "0.3.0+git${SRCPV}"
SRC_URI = "gitsm://github.com/openthread/ot-br-posix.git;protocol=https;branch=main \
file://0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch \
+ file://0001-cmake-Disable-nonnull-compare-warning-on-gcc.patch \
"
S = "${WORKDIR}/git"
LGTM
regards
Stefan Schmidt
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#96727):
https://lists.openembedded.org/g/openembedded-devel/message/96727
Mute This Topic: https://lists.openembedded.org/mt/90571737/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH 2/2] wpantund: Add missing dependency on boost
Hello Khem.
On 19.04.22 17:22, Khem Raj wrote:
Fixes
checking for boost/signals2/signal.hpp... no
configure: error: Unable to find a usable implementation of boost::signals2
(not even our internal copy)
Signed-off-by: Khem Raj
---
meta-networking/recipes-connectivity/openthread/wpantund_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
b/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
index bb444d04f5..a7fcc202a4 100644
--- a/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
+++ b/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=e7820bc7f7d1638a6b54fc2e8d7fb103 \
file://third_party/openthread/LICENSE;md5=543b6fe90ec5901a683320a36390c65f \
file://third_party/pt/LICENSE;md5=dcd598b69cad786beea33da7b1ae14b7 \
"
-DEPENDS = "autoconf-archive dbus readline"
+DEPENDS = "autoconf-archive dbus readline boost"
SRCREV = "0fb1f57e4224e2df3e630e146702bfcf63fbf07a"
PV = "0.07.01+git${SRCPV}"
LGTM
JFYI the project does have an internal copy of boost in the
third_party/boost sub-folder (can be enabled by --with-boost=internal),
but given its age I agree that we should rely on newer boost versions
coming through OE.
regards
Stefan Schmidt
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#96726):
https://lists.openembedded.org/g/openembedded-devel/message/96726
Mute This Topic: https://lists.openembedded.org/mt/90563838/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH v3 1/4] ot-br-posix: add recipe for an OpenThread Border Router
Hello Khem On 12.04.22 15:56, Khem Raj wrote: this fails with gcc ( especially with gcc12 ) https://errors.yoctoproject.org/Errors/Details/654559/ I saw you fixed this already while I was enjoying my vacation. Thanks! I like the CFLAGS override for the specific clang musl case also a lot better! regards Stefan Schmidt -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#96691): https://lists.openembedded.org/g/openembedded-devel/message/96691 Mute This Topic: https://lists.openembedded.org/mt/90320831/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [darktable-user] Recovering xmp data from Exported jpg files
Great! Problem solved! Stefan Am 18.04.2022 um 19:27 schrieb Guillermo Rozas: Hi, they're probably failing for the same reason they failed while importing the xmp files directly: in general the history stack data is not backwards compatible. It may be in some cases, but in the particular case of 3.9 and 3.8 it is most certainly not. The good news is the data should still be there, the bad news is that you'll need at least the version you used to save them to read them again. Fortunately there are some dev versions for windows floating around, check here: https://discuss.pixls.us/t/darktable-windows-insider-program-4-17/30415 Best regards, Guillermo On Mon, Apr 18, 2022 at 2:14 PM Stefan Schmidt wrote: I have worked with DT 3.9.0 on Ubuntu. Now I had to change to Windows 10 and installed DT 3.8.1 there. When I imported the pictures I have edited lately, all xmp files written bei DT 3.9.0 were lost and set back to standard. Therefore I tried to load the xmp files from the exported jpgs as described here below by Remco. However this did not work for some reason. When loading the respective jpg I get an error message. Stefan m 20.03.2022 um 07:59 schrieb Remco Viëtor: > On dimanche 20 mars 2022 00:20:09 CET Andrew Greig wrote: >> I have been told that I can recover the xmp files from my exported (and >> correct) jpgs. So I need to discover the process. I imagine that I would >> need to load my jpg files into Darktable instead of my RAW files with >> their ovewritten xmp files. But what is next, please? > No, you should *not* inport your jpegs in darktable. > > What you can do, is read the jpeg as a sidecar file: > select the required image in the lightroom, and in the right sidebar, the > module "history stack" has an option "load sidecar file". Click that and > select the jpeg you want to use the edit from. > Afaik, there's no easy way to automate that for a group of images. > > And may I suggest regular backups of at least the database (ideally > also of > the images and sidecar files)? > > Remco > > P.S. your previous problems were with the *"export"* module, here you > seem to > have been using the "history stack module". Different modules, so the > "append/ > overwrite" switches are independent! > > > > darktable user mailing list > to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org <mailto:darktable-user%2bunsubscr...@lists.darktable.org> > darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org <mailto:darktable-user%2bunsubscr...@lists.darktable.org> darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Fwd: [darktable-user] Recovering xmp data from Exported jpg files
I have worked with DT 3.9.0 on Ubuntu. Now I had to change to Windows 10 and installed DT 3.8.1 there. When I imported the pictures I have edited lately, all xmp files written bei DT 3.9.0 were lost and set back to standard. Therefore I tried to load the xmp files from the exported jpgs as described here below by Remco. However this did not work for some reason. When loading the respective jpg I get an error message. Stefan m 20.03.2022 um 07:59 schrieb Remco Viëtor: On dimanche 20 mars 2022 00:20:09 CET Andrew Greig wrote: I have been told that I can recover the xmp files from my exported (and correct) jpgs. So I need to discover the process. I imagine that I would need to load my jpg files into Darktable instead of my RAW files with their ovewritten xmp files. But what is next, please? No, you should *not* inport your jpegs in darktable. What you can do, is read the jpeg as a sidecar file: select the required image in the lightroom, and in the right sidebar, the module "history stack" has an option "load sidecar file". Click that and select the jpeg you want to use the edit from. Afaik, there's no easy way to automate that for a group of images. And may I suggest regular backups of at least the database (ideally also of the images and sidecar files)? Remco P.S. your previous problems were with the *"export"* module, here you seem to have been using the "history stack module". Different modules, so the "append/ overwrite" switches are independent! darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
[plasmashell] [Bug 452660] Random Plasma crashes
https://bugs.kde.org/show_bug.cgi?id=452660 Stefan Schmidt changed: What|Removed |Added CC||thrimbor+kdeb...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 452660] New: Random Plasma crashes
https://bugs.kde.org/show_bug.cgi?id=452660 Bug ID: 452660 Summary: Random Plasma crashes Product: plasmashell Version: 5.24.4 Platform: Archlinux Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: thrimbor+kdeb...@gmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 Application: plasmashell (5.24.4) Qt Version: 5.15.3 Frameworks Version: 5.93.0 Operating System: Linux 5.17.3-arch1-1 x86_64 Windowing System: X11 Distribution: "Arch Linux" DrKonqi: 5.24.4 [KCrashBackend] -- Information about the crash: I'm experiencing Plasma crashes, but so far couldn't narrow it down to some specific action or situation. Today it crashed when I clicked on the icon of an open dolphin instance in the task bar, two days ago it crashed when I opened Firefox (which opens a lot of windows). These actions do not reliably reproduce the crash, and I've had crashes where I didn't even actively do anything. I've tried to install all debug symbols, but the debug dialog mentioned that the symbols for /usr/bin/plasmashell are still not there. I will try to have debuginfod ready the next time. The crash can be reproduced sometimes. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault [KCrash Handler] #4 std::__atomic_base::load(std::memory_order) const (__m=std::memory_order_relaxed, this=0x70006f006f0070, this=, __m=) at /usr/include/c++/11.2.0/bits/atomic_base.h:479 #5 QAtomicOps::loadRelaxed(std::atomic const&) (_q_value=..., _q_value=) at /usr/include/qt/QtCore/qatomic_cxx11.h:239 #6 QBasicAtomicInteger::loadRelaxed() const (this=0x70006f006f0070, this=) at /usr/include/qt/QtCore/qbasicatomic.h:107 #7 QWeakPointer::internalData() const (this=0x5630186a0e48) at /usr/include/qt/QtCore/qsharedpointer_impl.h:698 #8 QPointer::data() const (this=0x5630186a0e48, this=) at /usr/include/qt/QtCore/qpointer.h:77 #9 QPointer::operator QObject*() const (this=0x5630186a0e48, this=) at /usr/include/qt/QtCore/qpointer.h:83 #10 QQmlDelegateModelPrivate::destroyCacheItem(QQmlDelegateModelItem*) (this=0x563014e01b10, cacheItem=0x5630186a0e20) at /usr/src/debug/qtdeclarative/src/qmlmodels/qqmldelegatemodel.cpp:643 #11 0x7f86f5be1bb2 in std::function::operator()(QQmlDelegateModelItem*) const (__args#0=0x5630186a0e20, this=0x7ffefb8e8220) at /usr/include/c++/11.2.0/bits/std_function.h:560 #12 QQmlReusableDelegateModelItemsPool::drain(int, std::function) (this=0x563014e01d08, maxPoolTime=0, releaseItem=...) at /usr/src/debug/qtdeclarative/src/qmlmodels/qqmldelegatemodel.cpp:3821 #13 0x7f86f5bd1c6b in QQmlDelegateModelPrivate::drainReusableItemsPool(int) (maxPoolTime=, this=) at /usr/src/debug/qtdeclarative/src/qmlmodels/qqmldelegatemodel.cpp:1118 #14 QQmlDelegateModel::drainReusableItemsPool(int) (this=, maxPoolTime=) at /usr/src/debug/qtdeclarative/src/qmlmodels/qqmldelegatemodel.cpp:1123 #15 0x7f86f86d0f15 in QQuickListView::geometryChanged(QRectF const&, QRectF const&) (this=0x5630172220b0, newGeometry=..., oldGeometry=...) at /usr/src/debug/qtdeclarative/src/quick/items/qquicklistview.cpp:3418 #16 0x7f86f85fd530 in QQuickItem::setSize(QSizeF const&) (this=this@entry=0x5630172220b0, size=...) at /usr/src/debug/qtdeclarative/src/quick/items/qquickitem.cpp:7045 #17 0x7f86f0efd2fb in QQuickControlPrivate::resizeContent() (this=) at /usr/src/debug/qtquickcontrols2/src/quicktemplates2/qquickcontrol.cpp:402 #18 0x7f86f0efff6b in QQuickControl::geometryChanged(QRectF const&, QRectF const&) (this=0x56301619e5c0, newGeometry=..., oldGeometry=...) at /usr/src/debug/qtquickcontrols2/src/quicktemplates2/qquickcontrol.cpp: #19 0x7f86f85fd3ec in QQuickItem::setImplicitHeight(double) (this=0x56301619e5c0, h=) at /usr/src/debug/qtdeclarative/src/quick/items/qquickitem.cpp:6944 #20 0x7f86f8149b11 in QQmlPropertyData::writeProperty(QObject*, void*, QFlags) const (this=, target=, value=, flags=...) at ../../include/QtQml/5.15.3/QtQml/private/../../../../../../qtdeclarative/src/qml/qml/qqmlpropertydata_p.h:375 #21 0x7f86f819f73b in GenericBinding<6>::doStore(double, QQmlPropertyData const*, QFlags) const (flags=..., pd=, value=, this=0x563014c4e090) at /usr/src/debug/qtdeclarative/src/qml/qml/qqmlbinding.cpp:342 #22 GenericBinding<6>::write(QV4::Value const&, bool, QFlags) (this=0x563014c4e090, result=..., isUndefined=, flags=...) at /usr/src/debug/qtdeclarative/src/qml/qml/qqmlbinding.cpp:315 #23 0x7f86f81a82e6 in QQmlNonbindingBinding::doUpdate(QQmlJavaScriptExpression::DeleteWatcher const&, QFlags, QV4::Scope&) (this=0x563014c4e090, watcher=..., flags=..., scope=) at /usr/src/debug/qtdeclarative/src/qml/qml/qqmlbinding.cpp:258 #24 0x7f86f81a91cc in QQmlBinding::update(QFlags) (this=0x563014c4e090, flags=...) at /usr/src/debug/qtd
Re: [oe] [meta-networking][PATCH 2/4] ot-daemon: add recipe for OpenThread daemon
Hello. On 07.04.22 21:36, Khem Raj wrote: On Thu, Apr 7, 2022 at 3:28 PM Stefan Schmidt wrote: Hello Khem. On 05.04.22 20:08, Khem Raj wrote: On Tue, Apr 5, 2022 at 4:39 AM Stefan Schmidt mailto:ste...@datenfreihafen.org>> wrote: Hello Khem. On 05.04.22 05:16, Khem Raj wrote: > fails on x86_64/glibc see > https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1610 <https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1610> Ah, its not x86_64/glibc (I tested this) but the fact that the autobuilder uses poky and I tested here without DISTRO in openembedded core. Seems the code base it not happy about the gcc changes to warn on the combination of _FORTIFY_SOURCE and non-optimized code: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp] Hmm so you are not using security flags ? You mean Oniro is not using them? Not sure I can follow you train of thoughts here. :-) poky defaults now a days include security_flags.inc which enables fortify and other good security stuff from compiler's point of view. So it seems your distro is not inheriting all the default distro policies was what I was trying to point at. We actually included security_flags.inc from the very beginning. :-) First in oniro-linux only and since March also in oniro-zephyr. regards Stefan Schmidt -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#96462): https://lists.openembedded.org/g/openembedded-devel/message/96462 Mute This Topic: https://lists.openembedded.org/mt/90240938/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH 2/4] ot-daemon: add recipe for OpenThread daemon
Hello Khem. On 05.04.22 20:08, Khem Raj wrote: On Tue, Apr 5, 2022 at 4:39 AM Stefan Schmidt <mailto:ste...@datenfreihafen.org>> wrote: Hello Khem. On 05.04.22 05:16, Khem Raj wrote: > fails on x86_64/glibc see > https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1610 <https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1610> Ah, its not x86_64/glibc (I tested this) but the fact that the autobuilder uses poky and I tested here without DISTRO in openembedded core. Seems the code base it not happy about the gcc changes to warn on the combination of _FORTIFY_SOURCE and non-optimized code: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp] Hmm so you are not using security flags ? You mean Oniro is not using them? Not sure I can follow you train of thoughts here. :-) That’s not good :) you should inherit good defaults The problem above was from the autobuilder error you pointed me to, building with Poky not Oniro. -O2 -D_FORTIFY_SOURCE=2 itself works on the upstream code base, but it needs optimization enabled (as the error message states). No idea why that went wrong on the autobuilder. regards Stefan Schmidt -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#96459): https://lists.openembedded.org/g/openembedded-devel/message/96459 Mute This Topic: https://lists.openembedded.org/mt/90240938/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH v3 4/4] MAINTAINERS: add entry for OpenThread
From: Stefan Schmidt No need to put the pressure of this also on Khem. I am actively working on this for Oniro and will support this work also upstream here. Signed-off-by: Stefan Schmidt --- meta-networking/MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/meta-networking/MAINTAINERS b/meta-networking/MAINTAINERS index 77e90668c..ce53ec471 100644 --- a/meta-networking/MAINTAINERS +++ b/meta-networking/MAINTAINERS @@ -37,3 +37,7 @@ F: recipes-* NETKIT M: Armin Kuster F: recipes-netkit + +OPENTHREAD +M: Stefan Schmidt +F: recipes-connectivity/openthread/ -- 2.35.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#96458): https://lists.openembedded.org/g/openembedded-devel/message/96458 Mute This Topic: https://lists.openembedded.org/mt/90320834/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH v3 1/4] ot-br-posix: add recipe for an OpenThread Border Router
From: Stefan Schmidt The OpenThread project is an open source implementation of the Thread low-power mesh network protocol. In a Thread network devices can have different roles, and of of these roles is a Border Router that allows a Thread network to be connected with other IP networks. Ot-br-posix runs as a systemd service on a standard Linux system to handle the connection to a Thread network. In terms of patches we need a fix to allow building on musl + clang (CMSG_NXTHDR macro triggers a -Wsign-compare warning) and a systemd unit file change is OE specific and avoids having service dependencies implemented as pre exec hooks. Signed-off-by: Stefan Schmidt --- v3: - Dropped the musl include fixed which was merged upstream and we bumped the version - Version bump also fixed a C++ deprecated-copy error I saw - Included new patch to fix CMSG_NXTHDR macro usage on musl+clang ...ce.in-remove-pre-exec-hook-for-mdns-.patch | 35 + .../Turn-off-sign-compare-for-musl-libc.patch | 131 ++ .../openthread/ot-br-posix_git.bb | 59 3 files changed, 225 insertions(+) create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix/Turn-off-sign-compare-for-musl-libc.patch create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch new file mode 100644 index 0..250de4bdd --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch @@ -0,0 +1,35 @@ +From ed60d4605b81c43b9ba9504a37835109c247c6f8 Mon Sep 17 00:00:00 2001 +From: Stefan Schmidt +Date: Fri, 1 Apr 2022 21:46:03 +0200 +Subject: [PATCH] otbr-agent.service.in: remove pre exec hook for mdns service + +It uses the service command which is not available in all cases under +Yocto/OE. The upstream project uses this mainly with Ubuntu and Raspian +as testbeds. + +In our case we simply ensure that avahi-daemon is installed on the +system inside the recipe. + +Upstream-Status: Inappropriate [OE specific] + +Signed-off-by: Stefan Schmidt +--- + src/agent/otbr-agent.service.in | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/agent/otbr-agent.service.in b/src/agent/otbr-agent.service.in +index 8314121347..4c97869def 100644 +--- a/src/agent/otbr-agent.service.in b/src/agent/otbr-agent.service.in +@@ -6,7 +6,7 @@ After=dbus.socket + + [Service] + EnvironmentFile=-@CMAKE_INSTALL_FULL_SYSCONFDIR@/default/otbr-agent +-@EXEC_START_PRE@ExecStart=@CMAKE_INSTALL_FULL_SBINDIR@/otbr-agent $OTBR_AGENT_OPTS ++ExecStart=@CMAKE_INSTALL_FULL_SBINDIR@/otbr-agent $OTBR_AGENT_OPTS + KillMode=mixed + Restart=on-failure + RestartSec=5 +-- +2.35.1 + diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix/Turn-off-sign-compare-for-musl-libc.patch b/meta-networking/recipes-connectivity/openthread/ot-br-posix/Turn-off-sign-compare-for-musl-libc.patch new file mode 100644 index 0..df84550be --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix/Turn-off-sign-compare-for-musl-libc.patch @@ -0,0 +1,131 @@ +From: Stefan Schmidt +Subject: Turn off sign compare for musl libc + +When building with musl and clang the usage of CMSG_NXTHDR results in +sign-compare error. Disable the check only in this specific part of the +code with a #pragma. + +| /home/stefan/huawei/yocto-upstream/yoe/workspace/sources/ot-br-posix/third_party/openthread/repo/src/posix/platform/udp.cpp:147:28: fatal error: comparison of integers of different signs: 'unsigned long' and 'long' [-Wsign-compare] +| cmsg = CMSG_NXTHDR(&msg, cmsg); +|^~~ +| /home/stefan/huawei/yocto-upstream/yoe/build/tmp/work/cortexa57-yoe-linux-musl/ot-br-posix/0.3.0+git999-r0/recipe-sysroot/usr/include/sys/socket.h:358:44: note: expanded from macro 'CMSG_NXTHDR' +| __CMSG_LEN(cmsg) + sizeof(struct cmsghdr) >= __MHDR_END(mhdr) - (unsigned char *)(cmsg) \ +| ~ ^ ~~ +| 1 error generated. + +Idea and fix taken from +recipes-devtools/breakpad/breakpad/0001-Turn-off-sign-compare-for-musl-libc.patch +by Khem Raj. + +Upstream-Status: Inappropriate [OE specific] + +Signed-off-by: Stefan Schmidt + +diff --git a/src/backbone_router/nd_proxy.cpp b/src/backbone_router/nd_proxy.cpp +index 7136878c3d..8a223c95c7 100644 +--- a/src/backbone_router/nd_proxy.cpp b/src/backbone_router/nd
[oe] [meta-networking][PATCH v3 2/4] ot-daemon: add recipe for OpenThread daemon
From: Stefan Schmidt
The OpenThread daemon allows Linuxes devices to participate in a Thread
mesh network without acting as a full border router. The device
participates like any other child or router devices within the network.
This same repo is used for range of different modes to run the
OpenThread code. From bare metal over vendor SDKs to posix platforms.
For this recipe the focus is on the Linux posix implementation and we do
not pull in all the git submodules on purpose.
There are openthread enabled recipes in meta-zephyr for people who want
to also use OpenThread on MCU based platforms on top of Zephyr.
Signed-off-by: Stefan Schmidt
---
.../openthread/ot-daemon_git.bb | 27 +++
1 file changed, 27 insertions(+)
create mode 100644
meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
diff --git a/meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
b/meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
new file mode 100644
index 0..f3f4c70fa
--- /dev/null
+++ b/meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
@@ -0,0 +1,27 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: Apache-2.0
+SUMMARY = "OpenThread Daemon is an OpenThread POSIX build mode that runs
OpenThread as a service."
+SECTION = "net"
+LICENSE = "BSD-3-Clause & Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=543b6fe90ec5901a683320a36390c65f \
+
file://third_party/mbedtls/repo/LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57 \
+"
+DEPENDS = "readline"
+SRCREV = "7dfde1f12923f03c9680be4d838b94b7a2320324"
+PV = "0.1+git${SRCPV}"
+
+SRC_URI =
"git://github.com/openthread/openthread.git;protocol=https;branch=main \
+ "
+
+S = "${WORKDIR}/git"
+
+inherit cmake
+
+EXTRA_OECMAKE = "-DOT_DAEMON=ON \
+ -DOT_SPINEL_RESET_CONNECTION=ON \
+ -DOT_THREAD_VERSION=1.2 \
+ -DOT_COVERAGE=OFF \
+ -DOT_PLATFORM=posix \
+ -DCMAKE_BUILD_TYPE=Release \
+ "
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#96457):
https://lists.openembedded.org/g/openembedded-devel/message/96457
Mute This Topic: https://lists.openembedded.org/mt/90320833/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH v3 3/4] wpantund: add new recipe
From: Stefan Schmidt
Wpantund is part of the OpenThread project. It is used in a scenario
where the Thread radio operates as a network co-processor (NCP) that is
connected over SPI/UART/USB to the host.
The project itself is in maintenance-only mode right now as the NCP
architecture has been replaced with radio co-processor (RCP) which is
implemented directly in openthread and ot-br-posix. None the less there
might still be project and products out there using it.
Signed-off-by: Stefan Schmidt
---
v3:
- Add additional CVE to ignore list that has a fix in the un-released git
version
.../openthread/wpantund_git.bb| 32 +++
1 file changed, 32 insertions(+)
create mode 100644
meta-networking/recipes-connectivity/openthread/wpantund_git.bb
diff --git a/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
b/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
new file mode 100644
index 0..bb444d04f
--- /dev/null
+++ b/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
@@ -0,0 +1,32 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: Apache-2.0
+SUMMARY = "wpantund, Userspace WPAN Network Daemon"
+SECTION = "net"
+LICENSE = "Apache-2.0 & MIT & BSL-1.0 & BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=e7820bc7f7d1638a6b54fc2e8d7fb103 \
+
file://third_party/assert-macros/LICENSE;md5=cbf35ecdc8161026afe4da2906fab204 \
+
file://third_party/boost/LICENSE;md5=e4224ccaecb14d942c71d31bef20d78c \
+
file://third_party/fgetln/LICENSE;md5=389e03d2254ecad45d0d9bbdefef7129 \
+
file://third_party/openthread/LICENSE;md5=543b6fe90ec5901a683320a36390c65f \
+
file://third_party/pt/LICENSE;md5=dcd598b69cad786beea33da7b1ae14b7 \
+"
+DEPENDS = "autoconf-archive dbus readline"
+SRCREV = "0fb1f57e4224e2df3e630e146702bfcf63fbf07a"
+PV = "0.07.01+git${SRCPV}"
+
+SRC_URI =
"gitsm://github.com/openthread/wpantund.git;protocol=https;branch=master \
+ "
+
+S = "${WORKDIR}/git"
+
+inherit pkgconfig perlnative autotools
+
+# CVE-2020-8916 has been fixed in commit
+# 3f108441e23e033b936e85be5b6877dd0a1fbf1c which is included in the SRCREV
+# CVE-2021-33889 has been fixed in commit
+# a8f3f761f6753b567d1e5ad22cbe6b0ceb6f2649 which is included in the SRCREV
+# There has not been a wpantund release as of yet that includes these fixes.
+# That means cve-check can not match them. Once a new release comes we can
+# remove the ignore statement.
+CVE_CHECK_IGNORE = "CVE-2020-8916 CVE-2021-33889"
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#96456):
https://lists.openembedded.org/g/openembedded-devel/message/96456
Mute This Topic: https://lists.openembedded.org/mt/90320832/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH v2 1/4] ot-br-posix: add recipe for an OpenThread Border Router
Hello Khem. On 07.04.22 02:20, Khem Raj wrote: still fails to build https://errors.yoctoproject.org/Errors/Details/654012/ Sigh, sorry for this. Its a different recipe than the first one that failed. I will sit down and try to figure out why I am not seeing any of the problems in my local builds. Need to check the autobuilder configs. regards Stefan Schmidt On Tue, Apr 5, 2022 at 5:12 AM Stefan Schmidt wrote: From: Stefan Schmidt The OpenThread project is an open source implementation of the Thread low-power mesh network protocol. In a Thread network devices can have different roles, and of of these roles is a Border Router that allows a Thread network to be connected with other IP networks. Ot-br-posix runs as a systemd service on a standard Linux system to handle the connection to a Thread network. The small musl compile fix has been submitted upstream and is pending while the systemd unit file change is OE specific and avoids having service dependencies implemented as pre exec hooks. Signed-off-by: Stefan Schmidt --- v2: - Upstream status of one patch changed from pending to submitted ...ce.in-remove-pre-exec-hook-for-mdns-.patch | 35 +++ ...lient-add-needed-header-for-fd_set-c.patch | 27 + .../openthread/ot-br-posix_git.bb | 59 +++ 3 files changed, 121 insertions(+) create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch new file mode 100644 index 0..250de4bdd --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch @@ -0,0 +1,35 @@ +From ed60d4605b81c43b9ba9504a37835109c247c6f8 Mon Sep 17 00:00:00 2001 +From: Stefan Schmidt +Date: Fri, 1 Apr 2022 21:46:03 +0200 +Subject: [PATCH] otbr-agent.service.in: remove pre exec hook for mdns service + +It uses the service command which is not available in all cases under +Yocto/OE. The upstream project uses this mainly with Ubuntu and Raspian +as testbeds. + +In our case we simply ensure that avahi-daemon is installed on the +system inside the recipe. + +Upstream-Status: Inappropriate [OE specific] + +Signed-off-by: Stefan Schmidt +--- + src/agent/otbr-agent.service.in | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/agent/otbr-agent.service.in b/src/agent/otbr-agent.service.in +index 8314121347..4c97869def 100644 +--- a/src/agent/otbr-agent.service.in b/src/agent/otbr-agent.service.in +@@ -6,7 +6,7 @@ After=dbus.socket + + [Service] + EnvironmentFile=-@CMAKE_INSTALL_FULL_SYSCONFDIR@/default/otbr-agent +-@EXEC_START_PRE@ExecStart=@CMAKE_INSTALL_FULL_SBINDIR@/otbr-agent $OTBR_AGENT_OPTS ++ExecStart=@CMAKE_INSTALL_FULL_SBINDIR@/otbr-agent $OTBR_AGENT_OPTS + KillMode=mixed + Restart=on-failure + RestartSec=5 +-- +2.35.1 + diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch new file mode 100644 index 0..29f2af849 --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch @@ -0,0 +1,27 @@ +From 596eb2b582609794d87f2dbefa4b2e839faf52c8 Mon Sep 17 00:00:00 2001 +From: Stefan Schmidt +Date: Fri, 28 May 2021 14:19:53 +0200 +Subject: [PATCH] web-service/ot-client: add needed header for fd_set() call + +The select.h header file is needed for fd_set(). Depending on the +compiler and settings this will result in an error when not included. + +Upstream-Status: Submitted [https://github.com/openthread/ot-br-posix/pull/1326] + +Signed-off-by: Stefan Schmidt +--- + src/web/web-service/ot_client.cpp | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/web/web-service/ot_client.cpp b/src/web/web-service/ot_client.cpp +index f151a0126..173cc48e1 100644 +--- a/src/web/web-service/ot_client.cpp b/src/web/web-service/ot_client.cpp +@@ -39,6 +39,7 @@ + #include + #include + #include ++#include + #include + + #include "common/code_utils.hpp" diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb b/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb new file mode 100644 index 0..5247ad4db --- /dev/null +++ b/meta-networki
[oe] [meta-networking][PATCH v2 4/4] MAINTAINERS: add entry for OpenThread
From: Stefan Schmidt No need to put the pressure of this also on Khem. I am actively working on this for Oniro and will support this work also upstream here. Signed-off-by: Stefan Schmidt --- meta-networking/MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/meta-networking/MAINTAINERS b/meta-networking/MAINTAINERS index 77e90668c..ce53ec471 100644 --- a/meta-networking/MAINTAINERS +++ b/meta-networking/MAINTAINERS @@ -37,3 +37,7 @@ F: recipes-* NETKIT M: Armin Kuster F: recipes-netkit + +OPENTHREAD +M: Stefan Schmidt +F: recipes-connectivity/openthread/ -- 2.35.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#96424): https://lists.openembedded.org/g/openembedded-devel/message/96424 Mute This Topic: https://lists.openembedded.org/mt/90261624/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH v2 3/4] wpantund: add new recipe
From: Stefan Schmidt
Wpantund is part of the OpenThread project. It is used in a scenario
where the Thread radio operates as a network co-processor (NCP) that is
connected over SPI/UART/USB to the host.
The project itself is in maintenance-only mode right now as the NCP
architecture has been replaced with radio co-processor (RCP) which is
implemented directly in openthread and ot-br-posix. None the less there
might still be project and products out there using it.
Signed-off-by: Stefan Schmidt
---
.../openthread/wpantund_git.bb| 27 +++
1 file changed, 27 insertions(+)
create mode 100644
meta-networking/recipes-connectivity/openthread/wpantund_git.bb
diff --git a/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
b/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
new file mode 100644
index 0..d8baacbb3
--- /dev/null
+++ b/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
@@ -0,0 +1,27 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: Apache-2.0
+SUMMARY = "wpantund, Userspace WPAN Network Daemon"
+SECTION = "net"
+LICENSE = "Apache-2.0 & MIT & BSL-1.0 & BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=e7820bc7f7d1638a6b54fc2e8d7fb103 \
+
file://third_party/assert-macros/LICENSE;md5=cbf35ecdc8161026afe4da2906fab204 \
+
file://third_party/boost/LICENSE;md5=e4224ccaecb14d942c71d31bef20d78c \
+
file://third_party/fgetln/LICENSE;md5=389e03d2254ecad45d0d9bbdefef7129 \
+
file://third_party/openthread/LICENSE;md5=543b6fe90ec5901a683320a36390c65f \
+
file://third_party/pt/LICENSE;md5=dcd598b69cad786beea33da7b1ae14b7 \
+"
+DEPENDS = "autoconf-archive dbus readline"
+SRCREV = "0fb1f57e4224e2df3e630e146702bfcf63fbf07a"
+PV = "0.07.01+git${SRCPV}"
+
+SRC_URI =
"gitsm://github.com/openthread/wpantund.git;protocol=https;branch=master \
+ "
+
+S = "${WORKDIR}/git"
+
+inherit pkgconfig perlnative autotools
+
+# CVE-2020-8916 has been fixed in commit
+# 3f108441e23e033b936e85be5b6877dd0a1fbf1c which is included in the SRCREV
+CVE_CHECK_IGNORE = "CVE-2020-8916"
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#96423):
https://lists.openembedded.org/g/openembedded-devel/message/96423
Mute This Topic: https://lists.openembedded.org/mt/90261623/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH v2 1/4] ot-br-posix: add recipe for an OpenThread Border Router
From: Stefan Schmidt The OpenThread project is an open source implementation of the Thread low-power mesh network protocol. In a Thread network devices can have different roles, and of of these roles is a Border Router that allows a Thread network to be connected with other IP networks. Ot-br-posix runs as a systemd service on a standard Linux system to handle the connection to a Thread network. The small musl compile fix has been submitted upstream and is pending while the systemd unit file change is OE specific and avoids having service dependencies implemented as pre exec hooks. Signed-off-by: Stefan Schmidt --- v2: - Upstream status of one patch changed from pending to submitted ...ce.in-remove-pre-exec-hook-for-mdns-.patch | 35 +++ ...lient-add-needed-header-for-fd_set-c.patch | 27 + .../openthread/ot-br-posix_git.bb | 59 +++ 3 files changed, 121 insertions(+) create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch new file mode 100644 index 0..250de4bdd --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch @@ -0,0 +1,35 @@ +From ed60d4605b81c43b9ba9504a37835109c247c6f8 Mon Sep 17 00:00:00 2001 +From: Stefan Schmidt +Date: Fri, 1 Apr 2022 21:46:03 +0200 +Subject: [PATCH] otbr-agent.service.in: remove pre exec hook for mdns service + +It uses the service command which is not available in all cases under +Yocto/OE. The upstream project uses this mainly with Ubuntu and Raspian +as testbeds. + +In our case we simply ensure that avahi-daemon is installed on the +system inside the recipe. + +Upstream-Status: Inappropriate [OE specific] + +Signed-off-by: Stefan Schmidt +--- + src/agent/otbr-agent.service.in | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/agent/otbr-agent.service.in b/src/agent/otbr-agent.service.in +index 8314121347..4c97869def 100644 +--- a/src/agent/otbr-agent.service.in b/src/agent/otbr-agent.service.in +@@ -6,7 +6,7 @@ After=dbus.socket + + [Service] + EnvironmentFile=-@CMAKE_INSTALL_FULL_SYSCONFDIR@/default/otbr-agent +-@EXEC_START_PRE@ExecStart=@CMAKE_INSTALL_FULL_SBINDIR@/otbr-agent $OTBR_AGENT_OPTS ++ExecStart=@CMAKE_INSTALL_FULL_SBINDIR@/otbr-agent $OTBR_AGENT_OPTS + KillMode=mixed + Restart=on-failure + RestartSec=5 +-- +2.35.1 + diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch new file mode 100644 index 0..29f2af849 --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch @@ -0,0 +1,27 @@ +From 596eb2b582609794d87f2dbefa4b2e839faf52c8 Mon Sep 17 00:00:00 2001 +From: Stefan Schmidt +Date: Fri, 28 May 2021 14:19:53 +0200 +Subject: [PATCH] web-service/ot-client: add needed header for fd_set() call + +The select.h header file is needed for fd_set(). Depending on the +compiler and settings this will result in an error when not included. + +Upstream-Status: Submitted [https://github.com/openthread/ot-br-posix/pull/1326] + +Signed-off-by: Stefan Schmidt +--- + src/web/web-service/ot_client.cpp | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/web/web-service/ot_client.cpp b/src/web/web-service/ot_client.cpp +index f151a0126..173cc48e1 100644 +--- a/src/web/web-service/ot_client.cpp b/src/web/web-service/ot_client.cpp +@@ -39,6 +39,7 @@ + #include + #include + #include ++#include + #include + + #include "common/code_utils.hpp" diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb b/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb new file mode 100644 index 0..5247ad4db --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb @@ -0,0 +1,59 @@ +# SPDX-FileCopyrightText: Huawei Inc. +# +# SPDX-License-Identifier: Apache-2.0 +SUMMARY = "OpenThread Border Router" +SECTION = "net" +LICENSE = "BSD-3-Clause & MIT" +LIC_FILES_CHKSUM = "file://LICENSE;md5=87109e44b2fda96a8991f27684a7349c \ + file://third_party/Simple-web-server/
[oe] [meta-networking][PATCH v2 2/4] ot-daemon: add recipe for OpenThread daemon
From: Stefan Schmidt
The OpenThread daemon allows Linuxes devices to participate in a Thread
mesh network without acting as a full border router. The device
participates like any other child or router devices within the network.
This same repo is used for range of different modes to run the
OpenThread code. From bare metal over vendor SDKs to posix platforms.
For this recipe the focus is on the Linux posix implementation and we do
not pull in all the git submodules on purpose.
There are openthread enabled recipes in meta-zephyr for people who want
to also use OpenThread on MCU based platforms on top of Zephyr.
Signed-off-by: Stefan Schmidt
---
v2:
- Switched to release build
- Ensure we list the license for mbedtls as third_party
.../openthread/ot-daemon_git.bb | 27 +++
1 file changed, 27 insertions(+)
create mode 100644
meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
diff --git a/meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
b/meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
new file mode 100644
index 0..f3f4c70fa
--- /dev/null
+++ b/meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
@@ -0,0 +1,27 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: Apache-2.0
+SUMMARY = "OpenThread Daemon is an OpenThread POSIX build mode that runs
OpenThread as a service."
+SECTION = "net"
+LICENSE = "BSD-3-Clause & Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=543b6fe90ec5901a683320a36390c65f \
+
file://third_party/mbedtls/repo/LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57 \
+"
+DEPENDS = "readline"
+SRCREV = "7dfde1f12923f03c9680be4d838b94b7a2320324"
+PV = "0.1+git${SRCPV}"
+
+SRC_URI =
"git://github.com/openthread/openthread.git;protocol=https;branch=main \
+ "
+
+S = "${WORKDIR}/git"
+
+inherit cmake
+
+EXTRA_OECMAKE = "-DOT_DAEMON=ON \
+ -DOT_SPINEL_RESET_CONNECTION=ON \
+ -DOT_THREAD_VERSION=1.2 \
+ -DOT_COVERAGE=OFF \
+ -DOT_PLATFORM=posix \
+ -DCMAKE_BUILD_TYPE=Release \
+ "
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#96422):
https://lists.openembedded.org/g/openembedded-devel/message/96422
Mute This Topic: https://lists.openembedded.org/mt/90261622/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [oe] [meta-networking][PATCH 2/4] ot-daemon: add recipe for OpenThread daemon
Hello Khem. On 05.04.22 05:16, Khem Raj wrote: fails on x86_64/glibc see https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1610 Ah, its not x86_64/glibc (I tested this) but the fact that the autobuilder uses poky and I tested here without DISTRO in openembedded core. Seems the code base it not happy about the gcc changes to warn on the combination of _FORTIFY_SOURCE and non-optimized code: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp] Will fix and resend. regards Stefan Schmidt -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#96420): https://lists.openembedded.org/g/openembedded-devel/message/96420 Mute This Topic: https://lists.openembedded.org/mt/90240938/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH 4/4] MAINTAINERS: add entry for OpenThread
From: Stefan Schmidt No need to put the pressure of this also on Khem. I am actively working on this for Oniro and will support this work also upstream here. Signed-off-by: Stefan Schmidt --- meta-networking/MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/meta-networking/MAINTAINERS b/meta-networking/MAINTAINERS index 77e90668c..ce53ec471 100644 --- a/meta-networking/MAINTAINERS +++ b/meta-networking/MAINTAINERS @@ -37,3 +37,7 @@ F: recipes-* NETKIT M: Armin Kuster F: recipes-netkit + +OPENTHREAD +M: Stefan Schmidt +F: recipes-connectivity/openthread/ -- 2.35.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#96381): https://lists.openembedded.org/g/openembedded-devel/message/96381 Mute This Topic: https://lists.openembedded.org/mt/90240940/21656 Group Owner: openembedded-devel+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH 3/4] wpantund: add new recipe
From: Stefan Schmidt
Wpantund is part of the OpenThread project. It is used in a scenario
where the Thread radio operates as a network co-processor (NCP) that is
connected over SPI/UART/USB to the host.
The project itself is in maintenance-only mode right now as the NCP
architecture has been replaced with radio co-processor (RCP) which is
implemented directly in openthread and ot-br-posix. None the less there
might still be project and products out there using it.
Signed-off-by: Stefan Schmidt
---
.../openthread/wpantund_git.bb| 27 +++
1 file changed, 27 insertions(+)
create mode 100644
meta-networking/recipes-connectivity/openthread/wpantund_git.bb
diff --git a/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
b/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
new file mode 100644
index 0..d8baacbb3
--- /dev/null
+++ b/meta-networking/recipes-connectivity/openthread/wpantund_git.bb
@@ -0,0 +1,27 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: Apache-2.0
+SUMMARY = "wpantund, Userspace WPAN Network Daemon"
+SECTION = "net"
+LICENSE = "Apache-2.0 & MIT & BSL-1.0 & BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=e7820bc7f7d1638a6b54fc2e8d7fb103 \
+
file://third_party/assert-macros/LICENSE;md5=cbf35ecdc8161026afe4da2906fab204 \
+
file://third_party/boost/LICENSE;md5=e4224ccaecb14d942c71d31bef20d78c \
+
file://third_party/fgetln/LICENSE;md5=389e03d2254ecad45d0d9bbdefef7129 \
+
file://third_party/openthread/LICENSE;md5=543b6fe90ec5901a683320a36390c65f \
+
file://third_party/pt/LICENSE;md5=dcd598b69cad786beea33da7b1ae14b7 \
+"
+DEPENDS = "autoconf-archive dbus readline"
+SRCREV = "0fb1f57e4224e2df3e630e146702bfcf63fbf07a"
+PV = "0.07.01+git${SRCPV}"
+
+SRC_URI =
"gitsm://github.com/openthread/wpantund.git;protocol=https;branch=master \
+ "
+
+S = "${WORKDIR}/git"
+
+inherit pkgconfig perlnative autotools
+
+# CVE-2020-8916 has been fixed in commit
+# 3f108441e23e033b936e85be5b6877dd0a1fbf1c which is included in the SRCREV
+CVE_CHECK_IGNORE = "CVE-2020-8916"
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#96380):
https://lists.openembedded.org/g/openembedded-devel/message/96380
Mute This Topic: https://lists.openembedded.org/mt/90240939/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH 2/4] ot-daemon: add recipe for OpenThread daemon
From: Stefan Schmidt
The OpenThread daemon allows Linuxes devices to participate in a Thread
mesh network without acting as a full border router. The device
participates like any other child or router devices within the network.
This same repo is used for range of different modes to run the
OpenThread code. From bare metal over vendor SDKs to posix platforms.
For this recipe the focus is on the Linux posix implementation and we do
not pull in all the git submodules on purpose.
There are openthread enabled recipes in meta-zephyr for people who want
to also use OpenThread on MCU based platforms on top of Zephyr.
Signed-off-by: Stefan Schmidt
---
.../openthread/ot-daemon_git.bb | 27 +++
1 file changed, 27 insertions(+)
create mode 100644
meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
diff --git a/meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
b/meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
new file mode 100644
index 0..7bce46e22
--- /dev/null
+++ b/meta-networking/recipes-connectivity/openthread/ot-daemon_git.bb
@@ -0,0 +1,27 @@
+# SPDX-FileCopyrightText: Huawei Inc.
+#
+# SPDX-License-Identifier: Apache-2.0
+SUMMARY = "OpenThread Daemon is an OpenThread POSIX build mode that runs
OpenThread as a service."
+SECTION = "net"
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=543b6fe90ec5901a683320a36390c65f"
+DEPENDS = "readline"
+SRCREV = "7dfde1f12923f03c9680be4d838b94b7a2320324"
+PV = "0.1+git${SRCPV}"
+
+# We are not using the git submodules fetch on purpose. None the third_party
+# components are needed for the plain posix build and we can avoid all the
+# differently licensed code.
+SRC_URI =
"git://github.com/openthread/openthread.git;protocol=https;branch=main \
+ "
+
+S = "${WORKDIR}/git"
+
+inherit cmake
+
+EXTRA_OECMAKE = "-DOT_DAEMON=ON \
+ -DOT_SPINEL_RESET_CONNECTION=ON \
+ -DOT_THREAD_VERSION=1.2 \
+ -DOT_COVERAGE=OFF \
+ -DOT_PLATFORM=posix \
+ "
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#96379):
https://lists.openembedded.org/g/openembedded-devel/message/96379
Mute This Topic: https://lists.openembedded.org/mt/90240938/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe] [meta-networking][PATCH 1/4] ot-br-posix: add recipe for an OpenThread Border Router
From: Stefan Schmidt The OpenThread project is an open source implementation of the Thread low-power mesh network protocol. In a Thread network devices can have different roles, and of of these roles is a Border Router that allows a Thread network to be connected with other IP networks. Ot-br-posix runs as a systemd service on a standard Linux system to handle the connection to a Thread network. The small musl compile fix has been submitted upstream and is pending while the systemd unit file change is OE specific and avoids having service dependencies implemented as pre exec hooks. Signed-off-by: Stefan Schmidt --- ...ce.in-remove-pre-exec-hook-for-mdns-.patch | 35 +++ ...lient-add-needed-header-for-fd_set-c.patch | 27 + .../openthread/ot-br-posix_git.bb | 59 +++ 3 files changed, 121 insertions(+) create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch create mode 100644 meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch new file mode 100644 index 0..250de4bdd --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-otbr-agent.service.in-remove-pre-exec-hook-for-mdns-.patch @@ -0,0 +1,35 @@ +From ed60d4605b81c43b9ba9504a37835109c247c6f8 Mon Sep 17 00:00:00 2001 +From: Stefan Schmidt +Date: Fri, 1 Apr 2022 21:46:03 +0200 +Subject: [PATCH] otbr-agent.service.in: remove pre exec hook for mdns service + +It uses the service command which is not available in all cases under +Yocto/OE. The upstream project uses this mainly with Ubuntu and Raspian +as testbeds. + +In our case we simply ensure that avahi-daemon is installed on the +system inside the recipe. + +Upstream-Status: Inappropriate [OE specific] + +Signed-off-by: Stefan Schmidt +--- + src/agent/otbr-agent.service.in | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/agent/otbr-agent.service.in b/src/agent/otbr-agent.service.in +index 8314121347..4c97869def 100644 +--- a/src/agent/otbr-agent.service.in b/src/agent/otbr-agent.service.in +@@ -6,7 +6,7 @@ After=dbus.socket + + [Service] + EnvironmentFile=-@CMAKE_INSTALL_FULL_SYSCONFDIR@/default/otbr-agent +-@EXEC_START_PRE@ExecStart=@CMAKE_INSTALL_FULL_SBINDIR@/otbr-agent $OTBR_AGENT_OPTS ++ExecStart=@CMAKE_INSTALL_FULL_SBINDIR@/otbr-agent $OTBR_AGENT_OPTS + KillMode=mixed + Restart=on-failure + RestartSec=5 +-- +2.35.1 + diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch new file mode 100644 index 0..9536dd4e2 --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix/0001-web-service-ot-client-add-needed-header-for-fd_set-c.patch @@ -0,0 +1,27 @@ +From 596eb2b582609794d87f2dbefa4b2e839faf52c8 Mon Sep 17 00:00:00 2001 +From: Stefan Schmidt +Date: Fri, 28 May 2021 14:19:53 +0200 +Subject: [PATCH] web-service/ot-client: add needed header for fd_set() call + +The select.h header file is needed for fd_set(). Depending on the +compiler and settings this will result in an error when not included. + +Upstream-Status: Pending [https://github.com/openthread/ot-br-posix/pull/1326] + +Signed-off-by: Stefan Schmidt +--- + src/web/web-service/ot_client.cpp | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/web/web-service/ot_client.cpp b/src/web/web-service/ot_client.cpp +index f151a0126..173cc48e1 100644 +--- a/src/web/web-service/ot_client.cpp b/src/web/web-service/ot_client.cpp +@@ -39,6 +39,7 @@ + #include + #include + #include ++#include + #include + + #include "common/code_utils.hpp" diff --git a/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb b/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb new file mode 100644 index 0..5247ad4db --- /dev/null +++ b/meta-networking/recipes-connectivity/openthread/ot-br-posix_git.bb @@ -0,0 +1,59 @@ +# SPDX-FileCopyrightText: Huawei Inc. +# +# SPDX-License-Identifier: Apache-2.0 +SUMMARY = "OpenThread Border Router" +SECTION = "net" +LICENSE = "BSD-3-Clause & MIT" +LIC_FILES_CHKSUM = "file://LICENSE;md5=87109e44b2fda96a8991f27684a7349c \ + file://third_party/Simple-web-server/repo/LICENSE;md5=852b3f7f320b19f6431487b8b2fb1d74 \ +
[yocto] [meta-zephyr][PATCH] zephyr-openthread-rcp: add recipe for OpenThread radio co-processor sample
From: Stefan Schmidt
This builds the sample for the radio co-processor firmware with a specific
set of overlays to work over USB transport.
Signed-off-by: Stefan Schmidt
---
.../zephyr-kernel/zephyr-openthread-rcp.bb | 10 ++
1 file changed, 10 insertions(+)
create mode 100644
meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-openthread-rcp.bb
diff --git
a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-openthread-rcp.bb
b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-openthread-rcp.bb
new file mode 100644
index 000..708e56a
--- /dev/null
+++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-openthread-rcp.bb
@@ -0,0 +1,10 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/net/openthread/coprocessor"
+
+EXTRA_OECMAKE += "-DCONF_FILE="prj.conf overlay-rcp.conf
overlay-usb-nrf-br.conf" -DDTC_OVERLAY_FILE="usb.overlay""
+
+# The overlay config and OpenThread itself imposes some specific requirements
+# towards the boards (e.g. flash layout and ieee802154 radio) so we need to
+# limit to known working machines here.
+COMPATIBLE_MACHINE = "(arduino-nano-33-ble)"
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56264): https://lists.yoctoproject.org/g/yocto/message/56264
Mute This Topic: https://lists.yoctoproject.org/mt/89341775/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[darktable-user] DT 3.6.1 Lens correction Panasonic Cameras Missing
Hi I have just updated from dt 3.2.1. to 3.6.1 I use ubuntu 20.04 and I have installed dt 3.6.1. via the ubuntu software center via snap latest/candidate In the 3.6.1. version my two cameras (Panasonic GX80 (also called GX85) and Panasonic G9) cannot be found in the lens correction module. There is a large list of Panasonic Cameras but not those two. Is there anything necessary to update that list? Best Stefan darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [PATCH 5/5] spi: make remove callback a void function
Hello. On 23.01.22 18:52, Uwe Kleine-König wrote: The value returned by an spi driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Signed-off-by: Uwe Kleine-König --- [...] drivers/net/ieee802154/adf7242.c | 4 +--- drivers/net/ieee802154/at86rf230.c| 4 +--- drivers/net/ieee802154/ca8210.c | 6 ++ drivers/net/ieee802154/cc2520.c | 4 +--- drivers/net/ieee802154/mcr20a.c | 4 +--- drivers/net/ieee802154/mrf24j40.c | 4 +--- [...] For the ieee802154 drivers: Acked-by: Stefan Schmidt regards Stefan Schmidt
[darktable-user] DT 3.6.1 Lens correction Panasonic Cameras Missing
Hi after upgrading to 3.6.1. my Panasonic camera (DMC-GX80 or DMC-GX85) can no longer be found in the module lens correction. Also many other panasonic cameras are missing. I have already updated lensfun but this did not help. For noise reduction / profile a noise profile for my camera can be found. Has anybody an idea what went wrong here? Stefan darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
