Re: [RFC net-next] net: mac802154: Remove unused ieee802154_mlme_tx_one
Hello Dave,
On 30.12.24 18:44, Dr. David Alan Gilbert wrote:
* Stefan Schmidt (ste...@datenfreihafen.org) wrote:
Hello li...@treblig.org.
On Wed, 25 Dec 2024 01:24:23 +, li...@treblig.org wrote:
ieee802154_mlme_tx_one() was added in 2022 by
commit ddd9ee7cda12 ("net: mac802154: Introduce a synchronous API for MLME
commands") but has remained unused.
Remove it.
Note, there's still a ieee802154_mlme_tx_one_locked()
variant that is used.
[...]
Applied to wpan/wpan-next.git, thanks!
Thanks! I'd been thinking I had to wait for net-next to reopen.
It's in my wpan-next tree and I will send a pull request to net-next
when it opens up again.
regards
Stefan Schmidt
Re: [RFC net-next] net: mac802154: Remove unused ieee802154_mlme_tx_one
Hello li...@treblig.org.
On Wed, 25 Dec 2024 01:24:23 +, li...@treblig.org wrote:
> ieee802154_mlme_tx_one() was added in 2022 by
> commit ddd9ee7cda12 ("net: mac802154: Introduce a synchronous API for MLME
> commands") but has remained unused.
>
> Remove it.
>
> Note, there's still a ieee802154_mlme_tx_one_locked()
> variant that is used.
>
> [...]
Applied to wpan/wpan-next.git, thanks!
[1/1] net: mac802154: Remove unused ieee802154_mlme_tx_one
https://git.kernel.org/wpan/wpan-next/c/bddfe23be8f8
regards,
Stefan Schmidt
Re: [PATCH V2] mac802154: check local interfaces before deleting sdata list
Hello Lizhi Xu. On Wed, 13 Nov 2024 17:51:29 +0800, Lizhi Xu wrote: > syzkaller reported a corrupted list in ieee802154_if_remove. [1] > > Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4 > hardware device from the system. > > CPU0 CPU1 > > genl_family_rcv_msg_doit ieee802154_unregister_hw > ieee802154_del_iface ieee802154_remove_interfaces > rdev_del_virtual_intf_deprecated list_del(&sdata->list) > ieee802154_if_remove > list_del_rcu > > [...] Applied to wpan/wpan.git, thanks! [1/1] mac802154: check local interfaces before deleting sdata list https://git.kernel.org/wpan/wpan/c/eb09fbeb4870 regards, Stefan Schmidt
Re: [PATCH net-next] ieee802154: Replace BOOL_TO_STR() with str_true_false()
Hello. On 28.10.24 17:42, Thorsten Blum wrote: Hi Stefan, On 28. Oct 2024, at 16:57, Stefan Schmidt wrote: Hello Thorsten Blum. On Sun, 20 Oct 2024 13:23:13 +0200, Thorsten Blum wrote: Replace the custom BOOL_TO_STR() macro with the str_true_false() helper function and remove the macro. Applied to wpan/wpan-next.git, thanks! [1/1] ieee802154: Replace BOOL_TO_STR() with str_true_false() https://git.kernel.org/wpan/wpan-next/c/299875256571 I'm actually not sure this works after getting feedback on a similar patch [1]. That is unfortunate. I'd probably revert it to be safe. I removed it completely now, as it has not been part of any pull request yet. regards Stefan Schmidt
Re: [PATCH net-next] ieee802154: Replace BOOL_TO_STR() with str_true_false()
Hello Thorsten Blum. On Sun, 20 Oct 2024 13:23:13 +0200, Thorsten Blum wrote: > Replace the custom BOOL_TO_STR() macro with the str_true_false() helper > function and remove the macro. > > Applied to wpan/wpan-next.git, thanks! [1/1] ieee802154: Replace BOOL_TO_STR() with str_true_false() https://git.kernel.org/wpan/wpan-next/c/299875256571 regards, Stefan Schmidt
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: [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: [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] [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 v2] net: mac802154: Fix general protection fault
Hello. On 05.04.21 13:50, Alexander Aring wrote: Hi, On Mon, 5 Apr 2021 at 01:45, Pavel Skripkin wrote: Hi! ... I forgot to check the patch with ./scripts/checkpatch.pl :( Dumb question: What is the meaning of it? This is for gerrit code review. This is required to push changes to gerrit public mirror. I'm using it to check patches with syzbot. Change ids are useless outside gerrit, so it shouldn't be here. Btw, should I sent v2 or this is already fixed? Otherwise the patch looks good. May Stefan can fix this. Acked-by: Alexander Aring I removed the Change-ID locally here. 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 v2] net: mac802154: Fix general protection fault
Hello. On 04.03.21 16:21, Pavel Skripkin wrote: syzbot found general protection fault in crypto_destroy_tfm()[1]. It was caused by wrong clean up loop in llsec_key_alloc(). If one of the tfm array members is in IS_ERR() range it will cause general protection fault in clean up function [1]. Call Trace: crypto_free_aead include/crypto/aead.h:191 [inline] [1] llsec_key_alloc net/mac802154/llsec.c:156 [inline] mac802154_llsec_key_add+0x9e0/0xcc0 net/mac802154/llsec.c:249 ieee802154_add_llsec_key+0x56/0x80 net/mac802154/cfg.c:338 rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] nl802154_add_llsec_key+0x3d3/0x560 net/ieee802154/nl802154.c:1584 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Pavel Skripkin Reported-by: syzbot+9ec037722d2603a9f...@syzkaller.appspotmail.com Change-Id: I29f7ac641a039096d63d1e6070bb32cb5a3beb07 --- net/mac802154/llsec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c index 585d33144c33..0ead2ced 100644 --- a/net/mac802154/llsec.c +++ b/net/mac802154/llsec.c @@ -152,7 +152,7 @@ llsec_key_alloc(const struct ieee802154_llsec_key *template) crypto_free_sync_skcipher(key->tfm0); err_tfm: for (i = 0; i < ARRAY_SIZE(key->tfm); i++) - if (key->tfm[i]) + if (!IS_ERR_OR_NULL(key->tfm[i])) crypto_free_aead(key->tfm[i]); kfree_sensitive(key); Alex, are you happy with this patch now? I would like to get it applied. Waiting for your review or ack given you had comments on the first version. regards Stefan Schmidt
Re: UBSAN: shift-out-of-bounds in nl802154_new_interface
Hello Alex. On 24.02.21 01:49, Jakub Kicinski wrote: On Tue, 23 Feb 2021 19:26:26 -0500 Alexander Aring wrote: Hi, On Tue, 23 Feb 2021 at 18:48, Jakub Kicinski wrote: Alex, there seems to be a few more syzbot reports for nl802154 beyond what you posted fixes for. Are you looking at these? Yes, I have it on my list. I will try to fix them at the weekend. Great, thank you! Thanks for handling these. Your first batch is reviewed and applied. I will wait for the next round before I send a pull request to net. regards Stefan Schmidt
Re: [PATCH] net/ieee802154: remove unused macros to tame gcc
Hello. On 06.11.20 09:10, Alex Shi wrote: Signed-off-by: Alex Shi Cc: Alexander Aring Cc: Stefan Schmidt Cc: "David S. Miller" Cc: Jakub Kicinski Cc: linux-w...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- net/ieee802154/nl802154.c | 4 1 file changed, 4 deletions(-) diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c index 7c5a1aa5adb4..1cebdcedc48c 100644 --- a/net/ieee802154/nl802154.c +++ b/net/ieee802154/nl802154.c @@ -2098,11 +2098,7 @@ static int nl802154_del_llsec_seclevel(struct sk_buff *skb, #define NL802154_FLAG_NEED_NETDEV 0x02 #define NL802154_FLAG_NEED_RTNL 0x04 #define NL802154_FLAG_CHECK_NETDEV_UP 0x08 -#define NL802154_FLAG_NEED_NETDEV_UP (NL802154_FLAG_NEED_NETDEV |\ -NL802154_FLAG_CHECK_NETDEV_UP) #define NL802154_FLAG_NEED_WPAN_DEV 0x10 -#define NL802154_FLAG_NEED_WPAN_DEV_UP (NL802154_FLAG_NEED_WPAN_DEV |\ -NL802154_FLAG_CHECK_NETDEV_UP) static int nl802154_pre_doit(const struct genl_ops *ops, struct sk_buff *skb, struct genl_info *info) 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 v5 25/52] docs: net: ieee802154.rst: fix C expressions
Hello.
[Sorry for the earlier empty mail]
On 06.10.20 16:03, Mauro Carvalho Chehab wrote:
There are some warnings produced with Sphinx 3.x:
Documentation/networking/ieee802154.rst:29: WARNING: Error in
declarator or parameters
Invalid C declaration: Expecting "(" in parameters. [error at 7]
int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
---^
Documentation/networking/ieee802154.rst:134: WARNING: Invalid C
declaration: Expected end of definition. [error at 81]
void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff
*skb, u8 lqi):
-^
Documentation/networking/ieee802154.rst:139: WARNING: Invalid C
declaration: Expected end of definition. [error at 95]
void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct
sk_buff *skb, bool ifs_handling):
---^
Documentation/networking/ieee802154.rst:158: WARNING: Invalid C
declaration: Expected end of definition. [error at 35]
int start(struct ieee802154_hw *hw):
---^
Documentation/networking/ieee802154.rst:162: WARNING: Invalid C
declaration: Expected end of definition. [error at 35]
void stop(struct ieee802154_hw *hw):
---^
Documentation/networking/ieee802154.rst:166: WARNING: Invalid C
declaration: Expected end of definition. [error at 61]
int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
-^
Documentation/networking/ieee802154.rst:171: WARNING: Invalid C
declaration: Expected end of definition. [error at 43]
int ed(struct ieee802154_hw *hw, u8 *level):
---^
Documentation/networking/ieee802154.rst:176: WARNING: Invalid C
declaration: Expected end of definition. [error at 62]
int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
--^
Caused by some bad c:function: prototypes. Fix them.
Acked-by: David S. Miller
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/ieee802154.rst | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH v5 25/52] docs: net: ieee802154.rst: fix C expressions
On 06.10.20 16:03, Mauro Carvalho Chehab wrote:
There are some warnings produced with Sphinx 3.x:
Documentation/networking/ieee802154.rst:29: WARNING: Error in
declarator or parameters
Invalid C declaration: Expecting "(" in parameters. [error at 7]
int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
---^
Documentation/networking/ieee802154.rst:134: WARNING: Invalid C
declaration: Expected end of definition. [error at 81]
void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff
*skb, u8 lqi):
-^
Documentation/networking/ieee802154.rst:139: WARNING: Invalid C
declaration: Expected end of definition. [error at 95]
void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct
sk_buff *skb, bool ifs_handling):
---^
Documentation/networking/ieee802154.rst:158: WARNING: Invalid C
declaration: Expected end of definition. [error at 35]
int start(struct ieee802154_hw *hw):
---^
Documentation/networking/ieee802154.rst:162: WARNING: Invalid C
declaration: Expected end of definition. [error at 35]
void stop(struct ieee802154_hw *hw):
---^
Documentation/networking/ieee802154.rst:166: WARNING: Invalid C
declaration: Expected end of definition. [error at 61]
int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
-^
Documentation/networking/ieee802154.rst:171: WARNING: Invalid C
declaration: Expected end of definition. [error at 43]
int ed(struct ieee802154_hw *hw, u8 *level):
---^
Documentation/networking/ieee802154.rst:176: WARNING: Invalid C
declaration: Expected end of definition. [error at 62]
int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
--^
Caused by some bad c:function: prototypes. Fix them.
Acked-by: David S. Miller
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/ieee802154.rst | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/Documentation/networking/ieee802154.rst
b/Documentation/networking/ieee802154.rst
index 6f4bf8447a21..f27856d77c8b 100644
--- a/Documentation/networking/ieee802154.rst
+++ b/Documentation/networking/ieee802154.rst
@@ -26,7 +26,9 @@ The stack is composed of three main parts:
Socket API
==
-.. c:function:: int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
+::
+
+int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
The address family, socket addresses etc. are defined in the
include/net/af_ieee802154.h header or in the special header
@@ -131,12 +133,12 @@ Register PHY in the system.
Freeing registered PHY.
-.. c:function:: void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct sk_buff *skb, u8 lqi):
+.. c:function:: void ieee802154_rx_irqsafe(struct ieee802154_hw *hw, struct
sk_buff *skb, u8 lqi)
Telling 802.15.4 module there is a new received frame in the skb with
the RF Link Quality Indicator (LQI) from the hardware device.
-.. c:function:: void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct sk_buff *skb, bool ifs_handling):
+.. c:function:: void ieee802154_xmit_complete(struct ieee802154_hw *hw, struct
sk_buff *skb, bool ifs_handling)
Telling 802.15.4 module the frame in the skb is or going to be
transmitted through the hardware device
@@ -155,25 +157,25 @@ operations structure at least::
...
};
-.. c:function:: int start(struct ieee802154_hw *hw):
+.. c:function:: int start(struct ieee802154_hw *hw)
Handler that 802.15.4 module calls for the hardware device initialization.
-.. c:function:: void stop(struct ieee802154_hw *hw):
+.. c:function:: void stop(struct ieee802154_hw *hw)
Handler that 802.15.4 module calls for the hardware device cleanup.
-.. c:function:: int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb):
+.. c:function:: int xmit_async(struct ieee802154_hw *hw, struct sk_buff *skb)
Handler that 802.15.4 module calls for each frame in the skb going to be
transmitted through the hardware device.
-.. c:function:: int ed(struct ieee802154_hw *hw, u8 *level):
+.. c:function:: int ed(struct ieee802154_hw *hw, u8 *level)
Handler that 802.15.4 module calls for Energy Detection from the hardware
device.
-.. c:function:: int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel):
+.. c:function:: int set_channel(struct ieee802154_hw *hw, u8 page, u8 channel)
Set radio for listening on specific channel of the hardwa
Re: [PATCH 4/8] net: mac802154: convert tasklets to use new tasklet_setup() API
Hello.
On 17.08.20 10:51, Allen Pais wrote:
From: Allen Pais
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier
Signed-off-by: Allen Pais
---
net/mac802154/main.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/mac802154/main.c b/net/mac802154/main.c
index 06ea0f8bfd5c..520cedc594e1 100644
--- a/net/mac802154/main.c
+++ b/net/mac802154/main.c
@@ -20,9 +20,9 @@
#include "ieee802154_i.h"
#include "cfg.h"
-static void ieee802154_tasklet_handler(unsigned long data)
+static void ieee802154_tasklet_handler(struct tasklet_struct *t)
{
- struct ieee802154_local *local = (struct ieee802154_local *)data;
+ struct ieee802154_local *local = from_tasklet(local, t, tasklet);
struct sk_buff *skb;
while ((skb = skb_dequeue(&local->skb_queue))) {
@@ -91,9 +91,7 @@ ieee802154_alloc_hw(size_t priv_data_len, const struct
ieee802154_ops *ops)
INIT_LIST_HEAD(&local->interfaces);
mutex_init(&local->iflist_mtx);
- tasklet_init(&local->tasklet,
-ieee802154_tasklet_handler,
-(unsigned long)local);
+ tasklet_setup(&local->tasklet, ieee802154_tasklet_handler);
skb_queue_head_init(&local->skb_queue);
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH] ieee802154/adf7242: check status of adf7242_read_reg
Hello.
On 02.08.20 16:23, t...@redhat.com wrote:
From: Tom Rix
Clang static analysis reports this error
adf7242.c:887:6: warning: Assigned value is garbage or undefined
len = len_u8;
^ ~~
len_u8 is set in
adf7242_read_reg(lp, 0, &len_u8);
When this call fails, len_u8 is not set.
So check the return code.
Fixes: 7302b9d90117 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154")
Signed-off-by: Tom Rix
---
drivers/net/ieee802154/adf7242.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index c11f32f644db..7db9cbd0f5de 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -882,7 +882,9 @@ static int adf7242_rx(struct adf7242_local *lp)
int ret;
u8 lqi, len_u8, *data;
- adf7242_read_reg(lp, 0, &len_u8);
+ ret = adf7242_read_reg(lp, 0, &len_u8);
+ if (ret)
+ return ret;
len = len_u8;
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 24/24] net: pass a sockptr_t into ->setsockopt
(struct sock *sk, int level, int optname,
- char __user *optval, unsigned int optlen)
+ sockptr_t optval, unsigned int optlen)
{
struct dccp_sock *dp = dccp_sk(sk);
int val, err = 0;
@@ -520,7 +520,7 @@ static int do_dccp_setsockopt(struct sock *sk, int level,
int optname,
if (optlen < (int)sizeof(int))
return -EINVAL;
- if (get_user(val, (int __user *)optval))
+ if (copy_from_sockptr(&val, optval, sizeof(int)))
return -EFAULT;
if (optname == DCCP_SOCKOPT_SERVICE)
@@ -563,8 +563,8 @@ static int do_dccp_setsockopt(struct sock *sk, int level,
int optname,
return err;
}
-int dccp_setsockopt(struct sock *sk, int level, int optname,
- char __user *optval, unsigned int optlen)
+int dccp_setsockopt(struct sock *sk, int level, int optname, sockptr_t optval,
+ unsigned int optlen)
{
if (level != SOL_DCCP)
return inet_csk(sk)->icsk_af_ops->setsockopt(sk, level,
diff --git a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
index 7d51ab608fb3f1..3b53d766789d47 100644
--- a/net/decnet/af_decnet.c
+++ b/net/decnet/af_decnet.c
@@ -150,7 +150,8 @@ static struct hlist_head dn_sk_hash[DN_SK_HASH_SIZE];
static struct hlist_head dn_wild_sk;
static atomic_long_t decnet_memory_allocated;
-static int __dn_setsockopt(struct socket *sock, int level, int optname, char __user *optval, unsigned int optlen, int flags);
+static int __dn_setsockopt(struct socket *sock, int level, int optname,
+ sockptr_t optval, unsigned int optlen, int flags);
static int __dn_getsockopt(struct socket *sock, int level, int optname, char
__user *optval, int __user *optlen, int flags);
static struct hlist_head *dn_find_list(struct sock *sk)
@@ -1320,7 +1321,8 @@ static int dn_shutdown(struct socket *sock, int how)
return err;
}
-static int dn_setsockopt(struct socket *sock, int level, int optname, char __user *optval, unsigned int optlen)
+static int dn_setsockopt(struct socket *sock, int level, int optname,
+ sockptr_t optval, unsigned int optlen)
{
struct sock *sk = sock->sk;
int err;
@@ -1332,14 +1334,14 @@ static int dn_setsockopt(struct socket *sock, int
level, int optname, char __use
/* we need to exclude all possible ENOPROTOOPTs except default case */
if (err == -ENOPROTOOPT && optname != DSO_LINKINFO &&
optname != DSO_STREAM && optname != DSO_SEQPACKET)
- err = nf_setsockopt(sk, PF_DECnet, optname,
- USER_SOCKPTR(optval), optlen);
+ err = nf_setsockopt(sk, PF_DECnet, optname, optval, optlen);
#endif
return err;
}
-static int __dn_setsockopt(struct socket *sock, int level,int optname, char __user *optval, unsigned int optlen, int flags)
+static int __dn_setsockopt(struct socket *sock, int level, int optname,
+ sockptr_t optval, unsigned int optlen, int flags)
{
struct sock *sk = sock->sk;
struct dn_scp *scp = DN_SK(sk);
@@ -1355,13 +1357,13 @@ static int __dn_setsockopt(struct socket *sock, int
level,int optname, char __us
} u;
int err;
- if (optlen && !optval)
+ if (optlen && sockptr_is_null(optval))
return -EINVAL;
if (optlen > sizeof(u))
return -EINVAL;
- if (copy_from_user(&u, optval, optlen))
+ if (copy_from_sockptr(&u, optval, optlen))
return -EFAULT;
switch (optname) {
diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
index 94ae9662133e30..a45a0401adc50b 100644
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -382,7 +382,7 @@ static int raw_getsockopt(struct sock *sk, int level, int
optname,
}
static int raw_setsockopt(struct sock *sk, int level, int optname,
- char __user *optval, unsigned int optlen)
+ sockptr_t optval, unsigned int optlen)
{
return -EOPNOTSUPP;
}
@@ -872,7 +872,7 @@ static int dgram_getsockopt(struct sock *sk, int level, int
optname,
}
static int dgram_setsockopt(struct sock *sk, int level, int optname,
- char __user *optval, unsigned int optlen)
+ sockptr_t optval, unsigned int optlen)
{
struct dgram_sock *ro = dgram_sk(sk);
struct net *net = sock_net(sk);
@@ -882,7 +882,7 @@ static int dgram_setsockopt(struct sock *sk, int level, int
optname,
if (optlen < sizeof(int))
return -EINVAL;
- if (get_user(val, (int __user *)optval))
+ if (copy_from_sockptr(&val, optval, sizeof(int)))
return -EFAULT;
For the ieee802154 part:
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH for v5.9] net: ieee802154: adf7242: Replace HTTP links with HTTPS ones
Hello. On 19.07.20 13:31, Alexander A. Klimov wrote: Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Continuing my work started at 93431e0607e5. See also: git log --oneline '--author=Alexander A. Klimov ' v5.7..master (Actually letting a shell for loop submit all this stuff for me.) If there are any URLs to be removed completely or at least not (just) HTTPSified: Just clearly say so and I'll *undo my change*. See also: https://lkml.org/lkml/2020/6/27/64 If there are any valid, but yet not changed URLs: See: https://lkml.org/lkml/2020/6/26/837 If you apply the patch, please let me know. Sorry again to all maintainers who complained about subject lines. Now I realized that you want an actually perfect prefixes, not just subsystem ones. I tried my best... And yes, *I could* (at least half-)automate it. Impossible is nothing! :) drivers/net/ieee802154/adf7242.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c index 5a37514e4234..60a016a6806a 100644 --- a/drivers/net/ieee802154/adf7242.c +++ b/drivers/net/ieee802154/adf7242.c @@ -4,7 +4,7 @@ * * Copyright 2009-2017 Analog Devices Inc. * - * http://www.analog.com/ADF7242 + * https://www.analog.com/ADF7242 */ #include 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 05/22] net: remove compat_sock_common_{get,set}sockopt
e(struct sock *sk)
{
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index a7e989919c5307..316cc5ac0da72b 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -999,10 +999,6 @@ static const struct proto_ops inet_dccp_ops = {
.recvmsg = sock_common_recvmsg,
.mmap = sock_no_mmap,
.sendpage = sock_no_sendpage,
-#ifdef CONFIG_COMPAT
- .compat_setsockopt = compat_sock_common_setsockopt,
- .compat_getsockopt = compat_sock_common_getsockopt,
-#endif
};
static struct inet_protosw dccp_v4_protosw = {
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 650187d688519c..b50f85a72cd5fc 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -1083,8 +1083,6 @@ static const struct proto_ops inet6_dccp_ops = {
.sendpage = sock_no_sendpage,
#ifdef CONFIG_COMPAT
.compat_ioctl = inet6_compat_ioctl,
- .compat_setsockopt = compat_sock_common_setsockopt,
- .compat_getsockopt = compat_sock_common_getsockopt,
#endif
};
diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
index d93d4531aa9bc5..94ae9662133e30 100644
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -423,10 +423,6 @@ static const struct proto_ops ieee802154_raw_ops = {
.recvmsg = sock_common_recvmsg,
.mmap = sock_no_mmap,
.sendpage = sock_no_sendpage,
-#ifdef CONFIG_COMPAT
- .compat_setsockopt = compat_sock_common_setsockopt,
- .compat_getsockopt = compat_sock_common_getsockopt,
-#endif
};
/* DGRAM Sockets (802.15.4 dataframes) */
@@ -986,10 +982,6 @@ static const struct proto_ops ieee802154_dgram_ops = {
.recvmsg = sock_common_recvmsg,
.mmap = sock_no_mmap,
.sendpage = sock_no_sendpage,
-#ifdef CONFIG_COMPAT
- .compat_setsockopt = compat_sock_common_setsockopt,
- .compat_getsockopt = compat_sock_common_getsockopt,
-#endif
For the ieee802154 part:
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH] ieee802154: ca8210: prevent memory leak
Hello.
On 18.09.19 00:47, Navid Emamdoost wrote:
In ca8210_probe the allocated pdata needs to be assigned to
spi_device->dev.platform_data before calling ca8210_get_platform_data.
Othrwise when ca8210_get_platform_data fails pdata cannot be released.
Signed-off-by: Navid Emamdoost
---
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 b188fce3f641..229d70a897ca 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -3152,12 +3152,12 @@ static int ca8210_probe(struct spi_device *spi_device)
goto error;
}
+ priv->spi->dev.platform_data = pdata;
ret = ca8210_get_platform_data(priv->spi, pdata);
if (ret) {
dev_crit(&spi_device->dev, "ca8210_get_platform_data failed\n");
goto error;
}
- priv->spi->dev.platform_data = pdata;
ret = ca8210_dev_com_init(priv);
if (ret) {
As Harry seems to be unavailable I am taking this patch directly.
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] ieee802154: mcr20a: simplify a bit 'mcr20a_handle_rx_read_buf_complete()'
Hello.
On 24.09.19 23:40, Xue Liu wrote:
On Sat, 21 Sep 2019 at 13:52, Stefan Schmidt wrote:
Hello Xue.
On 20.09.19 21:45, Christophe JAILLET wrote:
Use a 'skb_put_data()' variant instead of rewritting it.
The __skb_put_data variant is safe here. It is obvious that the skb can
not overflow. It has just been allocated a few lines above with the same
'len'.
Signed-off-by: Christophe JAILLET
---
drivers/net/ieee802154/mcr20a.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
index 17f2300e63ee..8dc04e2590b1 100644
--- a/drivers/net/ieee802154/mcr20a.c
+++ b/drivers/net/ieee802154/mcr20a.c
@@ -800,7 +800,7 @@ mcr20a_handle_rx_read_buf_complete(void *context)
if (!skb)
return;
- memcpy(skb_put(skb, len), lp->rx_buf, len);
+ __skb_put_data(skb, lp->rx_buf, len);
ieee802154_rx_irqsafe(lp->hw, skb, lp->rx_lqi[0]);
print_hex_dump_debug("mcr20a rx: ", DUMP_PREFIX_OFFSET, 16, 1,
Could you please review and ACK this? If you are happy I will take it
through my tree.
regards
Stefan Schmidt
Acked-by: Xue Liu
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] ieee802154: mcr20a: simplify a bit 'mcr20a_handle_rx_read_buf_complete()'
Hello Xue.
On 20.09.19 21:45, Christophe JAILLET wrote:
> Use a 'skb_put_data()' variant instead of rewritting it.
> The __skb_put_data variant is safe here. It is obvious that the skb can
> not overflow. It has just been allocated a few lines above with the same
> 'len'.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/net/ieee802154/mcr20a.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
> index 17f2300e63ee..8dc04e2590b1 100644
> --- a/drivers/net/ieee802154/mcr20a.c
> +++ b/drivers/net/ieee802154/mcr20a.c
> @@ -800,7 +800,7 @@ mcr20a_handle_rx_read_buf_complete(void *context)
> if (!skb)
> return;
>
> - memcpy(skb_put(skb, len), lp->rx_buf, len);
> + __skb_put_data(skb, lp->rx_buf, len);
> ieee802154_rx_irqsafe(lp->hw, skb, lp->rx_lqi[0]);
>
> print_hex_dump_debug("mcr20a rx: ", DUMP_PREFIX_OFFSET, 16, 1,
>
Could you please review and ACK this? If you are happy I will take it
through my tree.
regards
Stefan Schmidt
Re: [PATCH] ieee802154: ca8210: prevent memory leak
Hello Harry.
On 18.09.19 00:47, Navid Emamdoost wrote:
> In ca8210_probe the allocated pdata needs to be assigned to
> spi_device->dev.platform_data before calling ca8210_get_platform_data.
> Othrwise when ca8210_get_platform_data fails pdata cannot be released.
>
> Signed-off-by: Navid Emamdoost
> ---
> 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 b188fce3f641..229d70a897ca 100644
> --- a/drivers/net/ieee802154/ca8210.c
> +++ b/drivers/net/ieee802154/ca8210.c
> @@ -3152,12 +3152,12 @@ static int ca8210_probe(struct spi_device *spi_device)
> goto error;
> }
>
> + priv->spi->dev.platform_data = pdata;
> ret = ca8210_get_platform_data(priv->spi, pdata);
> if (ret) {
> dev_crit(&spi_device->dev, "ca8210_get_platform_data failed\n");
> goto error;
> }
> - priv->spi->dev.platform_data = pdata;
>
> ret = ca8210_dev_com_init(priv);
> if (ret) {
>
Could you review this patch for the ca8210 driver?
regards
Stefan Schmidt
Re: [PATCH] ieee802154: atusb: fix use-after-free at disconnect
Hello.
On 19.09.19 14:12, Johan Hovold wrote:
> The disconnect callback was accessing the hardware-descriptor private
> data after having having freed it.
>
> Fixes: 7490b008d123 ("ieee802154: add support for atusb transceiver")
> Cc: stable # 4.2
> Cc: Alexander Aring
> Reported-by: syzbot+f4509a9138a1472e7...@syzkaller.appspotmail.com
> Signed-off-by: Johan Hovold
> ---
>
> #syz test: https://github.com/google/kasan.git f0df5c1b
>
> drivers/net/ieee802154/atusb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> index ceddb424f887..0dd0ba915ab9 100644
> --- a/drivers/net/ieee802154/atusb.c
> +++ b/drivers/net/ieee802154/atusb.c
> @@ -1137,10 +1137,11 @@ static void atusb_disconnect(struct usb_interface
> *interface)
>
> ieee802154_unregister_hw(atusb->hw);
>
> + usb_put_dev(atusb->usb_dev);
> +
> ieee802154_free_hw(atusb->hw);
>
> usb_set_intfdata(interface, NULL);
> - usb_put_dev(atusb->usb_dev);
>
> pr_debug("%s done\n", __func__);
> }
>
This patch has been applied to the wpan tree and will be
part of the next pull request to net.
Thanks a lot for having a look at this!
regards
Stefan Schmidt
Re: [PATCH] net: ieee802154: remove redundant assignment to rc
Hello.
On 13.08.19 16:28, Colin King wrote:
> From: Colin Ian King
>
> Variable rc is initialized to a value that is never read and it is
> re-assigned later. The initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> net/ieee802154/socket.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
> index dacbd58e1799..badc5cfe4dc6 100644
> --- a/net/ieee802154/socket.c
> +++ b/net/ieee802154/socket.c
> @@ -1092,7 +1092,7 @@ static struct packet_type ieee802154_packet_type = {
>
> static int __init af_ieee802154_init(void)
> {
> - int rc = -EINVAL;
> + int rc;
>
> rc = proto_register(&ieee802154_raw_prot, 1);
> if (rc)
>
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] ieee802154: mcr20a: fix indentation, remove tabs
Hello.
On 14.01.19 16:48, Colin King wrote:
> From: Colin Ian King
>
> The are a couple of statments that are one level too deep, fix this by
> removing tabs.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/net/ieee802154/mcr20a.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
> index 44de81e5f140..c589f5ae75bb 100644
> --- a/drivers/net/ieee802154/mcr20a.c
> +++ b/drivers/net/ieee802154/mcr20a.c
> @@ -905,9 +905,9 @@ mcr20a_irq_clean_complete(void *context)
> }
> break;
> case (DAR_IRQSTS1_RXIRQ | DAR_IRQSTS1_SEQIRQ):
> - /* rx is starting */
> - dev_dbg(printdev(lp), "RX is starting\n");
> - mcr20a_handle_rx(lp);
> + /* rx is starting */
> + dev_dbg(printdev(lp), "RX is starting\n");
> + mcr20a_handle_rx(lp);
> break;
> case (DAR_IRQSTS1_RXIRQ | DAR_IRQSTS1_TXIRQ | DAR_IRQSTS1_SEQIRQ):
> if (lp->is_tx) {
>
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 net-next] ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_done
Hello.
On 11.12.18 04:13, YueHaibing wrote:
> gcc warning this:
>
> drivers/net/ieee802154/ca8210.c:730:10: warning:
> comparison is always false due to limited range of data type [-Wtype-limits]
>
> 'len' is u8 type, we get it from buf[1] adding 2, which can overflow.
> This patch change the type of 'len' to unsigned int to avoid this,also fix
> the gcc warning.
>
> Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
> Signed-off-by: YueHaibing
> ---
> drivers/net/ieee802154/ca8210.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
> index 0ff5a40..b2ff903 100644
> --- a/drivers/net/ieee802154/ca8210.c
> +++ b/drivers/net/ieee802154/ca8210.c
> @@ -721,7 +721,7 @@ static void ca8210_mlme_reset_worker(struct work_struct
> *work)
> static void ca8210_rx_done(struct cas_control *cas_ctl)
> {
> u8 *buf;
> - u8 len;
> + unsigned int len;
> struct work_priv_container *mlme_reset_wpc;
> struct ca8210_priv *priv = cas_ctl->priv;
>
> @@ -730,7 +730,7 @@ static void ca8210_rx_done(struct cas_control *cas_ctl)
> if (len > CA8210_SPI_BUF_SIZE) {
> dev_crit(
> &priv->spi->dev,
> - "Received packet len (%d) erroneously long\n",
> + "Received packet len (%u) erroneously long\n",
> len
> );
> goto finish;
>
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 net-next] ieee802154: ca8210: fix possible u8 overflow in ca8210_rx_done
Hello Dave.
On 11.12.18 07:01, David Miller wrote:
> From: YueHaibing
> Date: Tue, 11 Dec 2018 11:13:39 +0800
>
>> gcc warning this:
>>
>> drivers/net/ieee802154/ca8210.c:730:10: warning:
>> comparison is always false due to limited range of data type [-Wtype-limits]
>>
>> 'len' is u8 type, we get it from buf[1] adding 2, which can overflow.
>> This patch change the type of 'len' to unsigned int to avoid this,also fix
>> the gcc warning.
>>
>> Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
>> Signed-off-by: YueHaibing
>
> WPAN maintainers, I am assuming that as maintainers you will be
> picking this up and sending it to me.
That's correct. On driver patches I always wait 2 days or so to give the
driver maintainer a chance to reply before I go ahead and apply it.
I will take this one directly now and do some smoke testing. It will
come together with another fix as pull request to you.
regards
Stefan Schmidt
Re: [PATCH] ieee802154: ca8210: remove redundant condition check before debugfs_remove
Hello Zhong.
On 14/09/2018 07:04, zhong jiang wrote:
> debugfs_remove has taken the IS_ERR into account. Just
> remove the unnecessary condition.
>
> Signed-off-by: zhong jiang
> ---
> 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 58299fb..46b4818 100644
> --- a/drivers/net/ieee802154/ca8210.c
> +++ b/drivers/net/ieee802154/ca8210.c
> @@ -3044,8 +3044,7 @@ static void ca8210_test_interface_clear(struct
> ca8210_priv *priv)
> {
> struct ca8210_test *test = &priv->test;
>
> - if (!IS_ERR(test->ca8210_dfs_spi_int))
> - debugfs_remove(test->ca8210_dfs_spi_int);
> + debugfs_remove(test->ca8210_dfs_spi_int);
> kfifo_free(&test->up_fifo);
> dev_info(&priv->spi->dev, "Test interface removed\n");
> }
>
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] ieee802154: remove a redundant local variable 'i'
Hello.
On 19/09/2018 16:41, zhong jiang wrote:
> The local variable 'i' is never used after being assigned.
> hence it should be redundant adn can be removed.
>
> Signed-off-by: zhong jiang
> ---
> net/ieee802154/nl802154.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
> index 99f6c25..5b90151 100644
> --- a/net/ieee802154/nl802154.c
> +++ b/net/ieee802154/nl802154.c
> @@ -445,7 +445,6 @@ static int nl802154_send_wpan_phy(struct
> cfg802154_registered_device *rdev,
> {
> struct nlattr *nl_cmds;
> void *hdr;
> - int i;
>
> hdr = nl802154hdr_put(msg, portid, seq, flags, cmd);
> if (!hdr)
> @@ -508,7 +507,6 @@ static int nl802154_send_wpan_phy(struct
> cfg802154_registered_device *rdev,
> if (!nl_cmds)
> goto nla_put_failure;
>
> - i = 0;
> #define CMD(op, n) \
> do {\
> if (rdev->ops->op) {\
>
Sorry, but this patch is wrong. The variable i is used in line 513
inside the CMD() macro. The compiler clearly tells this when running
with your patch:
net/ieee802154/nl802154.c: In function ‘nl802154_send_wpan_phy’:
net/ieee802154/nl802154.c:513:4: error: ‘i’ undeclared (first use in
this function)
I would appreciate if patches sent out would at least be compile tested.
regards
Stefan Schmidt
Re: [PATCH net-next] ieee802154: Use kmemdup instead of duplicating it in ca8210_test_int_driver_write
Hello. On 08/09/2018 08:44 AM, YueHaibing wrote: > Replace calls to kmalloc followed by a memcpy with a direct call to > kmemdup. > > Signed-off-by: YueHaibing > --- > 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 58299fb..e21279d 100644 > --- a/drivers/net/ieee802154/ca8210.c > +++ b/drivers/net/ieee802154/ca8210.c > @@ -634,10 +634,9 @@ static int ca8210_test_int_driver_write( > for (i = 0; i < len; i++) > dev_dbg(&priv->spi->dev, "%#03x\n", buf[i]); > > - fifo_buffer = kmalloc(len, GFP_KERNEL); > + fifo_buffer = kmemdup(buf, len, GFP_KERNEL); > if (!fifo_buffer) > return -ENOMEM; > - memcpy(fifo_buffer, buf, len); > kfifo_in(&test->up_fifo, &fifo_buffer, 4); > wake_up_interruptible(&priv->test.readq); > 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] net: ieee802154: atusb: Replace GFP_ATOMIC with GFP_KERNEL in atusb_probe
Hello. On 04/11/2018 04:14 AM, Jia-Ju Bai wrote: > atusb_probe() is never called in atomic context. > This function is only set as ".probe" in struct usb_driver. > > Despite never getting called from atomic context, > atusb_probe() calls usb_alloc_urb() with GFP_ATOMIC, > which does not sleep for allocation. > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, > which can sleep and improve the possibility of sucessful allocation. > > This is found by a static analysis tool named DCNS written by myself. > And I also manually check it. > > Signed-off-by: Jia-Ju Bai > --- > drivers/net/ieee802154/atusb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c > index ef68851..ab6a505 100644 > --- a/drivers/net/ieee802154/atusb.c > +++ b/drivers/net/ieee802154/atusb.c > @@ -789,7 +789,7 @@ static int atusb_probe(struct usb_interface *interface, > atusb->tx_dr.bRequest = ATUSB_TX; > atusb->tx_dr.wValue = cpu_to_le16(0); > > - atusb->tx_urb = usb_alloc_urb(0, GFP_ATOMIC); > + atusb->tx_urb = usb_alloc_urb(0, GFP_KERNEL); > if (!atusb->tx_urb) > goto fail; > 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] ieee802154: mcr20a: Fix memory leak in mcr20a_probe
Hello.
On 04/05/2018 06:20 PM, Gustavo A. R. Silva wrote:
> Free allocated memory for pdata before return.
>
> Addresses-Coverity-ID: 1466096 ("Resource leak")
> Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver
> driver")
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/net/ieee802154/mcr20a.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
> index 55a22c7..944470d 100644
> --- a/drivers/net/ieee802154/mcr20a.c
> +++ b/drivers/net/ieee802154/mcr20a.c
> @@ -1267,7 +1267,7 @@ mcr20a_probe(struct spi_device *spi)
> ret = mcr20a_get_platform_data(spi, pdata);
> if (ret < 0) {
> dev_crit(&spi->dev, "mcr20a_get_platform_data failed.\n");
> - return ret;
> + goto free_pdata;
> }
>
> /* init reset gpio */
> @@ -1275,7 +1275,7 @@ mcr20a_probe(struct spi_device *spi)
> ret = devm_gpio_request_one(&spi->dev, pdata->rst_gpio,
> GPIOF_OUT_INIT_HIGH, "reset");
> if (ret)
> - return ret;
> + goto free_pdata;
> }
>
> /* reset mcr20a */
> @@ -1291,7 +1291,8 @@ mcr20a_probe(struct spi_device *spi)
> hw = ieee802154_alloc_hw(sizeof(*lp), &mcr20a_hw_ops);
> if (!hw) {
> dev_crit(&spi->dev, "ieee802154_alloc_hw failed\n");
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto free_pdata;
> }
>
> /* init mcr20a local data */
> @@ -1366,6 +1367,8 @@ mcr20a_probe(struct spi_device *spi)
>
> free_dev:
> ieee802154_free_hw(lp->hw);
> +free_pdata:
> + kfree(pdata);
>
> return 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] ieee802154: mcr20a: Fix memory leak in mcr20a_probe
Hello. On 04/10/2018 11:54 AM, Xue Liu wrote: > Hallo, > > Thanks for the fix. It looks good. > > ACK-by: Xue Liu Thanks for the ACK Xue. The correct format would be Acked-by: Xue Liu That way patchwork also picks the ACK up and adds it to the patch before I apply it from there. No worries, I did this manually for you this time. For the next time please use the correct format to have this tracked. regards Stefan Schmidt
Re: [PATCH][next] ieee802154: remove unused variable 'val'
Hello.
On 03/01/2018 03:40 PM, Colin King wrote:
> From: Colin Ian King
>
> Variable 'val' is not being initialized and is later being logically
> or'd with DAR_PHY_CTRL4_PROMISCUOUS. Considering this variable is never
> being read anyway we may as well remove val altogether.
>
> Cleans up error detected by cppcheck:
> drivers/net/ieee802154/mcr20a.c:732: (error) Uninitialized variable: val
>
> Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver
> driver")
> Signed-off-by: Colin Ian King
> ---
> drivers/net/ieee802154/mcr20a.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
> index d9eb22a52551..55a22c761808 100644
> --- a/drivers/net/ieee802154/mcr20a.c
> +++ b/drivers/net/ieee802154/mcr20a.c
> @@ -723,13 +723,11 @@ mcr20a_set_promiscuous_mode(struct ieee802154_hw *hw,
> const bool on)
> struct mcr20a_local *lp = hw->priv;
> int ret;
> u8 rx_frame_filter_reg = 0x0;
> - u8 val;
>
> dev_dbg(printdev(lp), "%s(%d)\n", __func__, on);
>
> if (on) {
> /* All frame types accepted*/
> - val |= DAR_PHY_CTRL4_PROMISCUOUS;
> rx_frame_filter_reg &= ~(IAR_RX_FRAME_FLT_FRM_VER);
> rx_frame_filter_reg |= (IAR_RX_FRAME_FLT_ACK_FT |
> IAR_RX_FRAME_FLT_NS_FT);
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: mrf24j40: fix incorrect mask in mrf24j40_stop
Hello.
On 31.10.2017 07:31, Gustavo A. R. Silva wrote:
> It seems that this is a copy/paste error and the proper bit masking is:
> BIT_TXNIE | BIT_RXIE
>
> This issue was detected with the help of Coccinelle.
>
> Reported-by: Julia Lawall
> Signed-off-by: Gustavo A. R. Silva
> Fixes: 7d840545e5b9 ("mrf24j40: replace magic numbers")
> ---
> drivers/net/ieee802154/mrf24j40.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ieee802154/mrf24j40.c
> b/drivers/net/ieee802154/mrf24j40.c
> index ee7084b..cf4788d 100644
> --- a/drivers/net/ieee802154/mrf24j40.c
> +++ b/drivers/net/ieee802154/mrf24j40.c
> @@ -635,7 +635,7 @@ static void mrf24j40_stop(struct ieee802154_hw *hw)
>
> /* Set TXNIE and RXIE. Disable Interrupts */
> regmap_update_bits(devrec->regmap_short, REG_INTCON,
> -BIT_TXNIE | BIT_TXNIE, BIT_TXNIE | BIT_TXNIE);
> +BIT_TXNIE | BIT_RXIE, BIT_TXNIE | BIT_RXIE);
> }
>
> static int mrf24j40_set_channel(struct ieee802154_hw *hw, u8 page, u8
> channel)
>
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: mrf24j40: fix incorrect mask in mrf24j40_stop
Hello Alan.
On 10/31/2017 07:31 AM, Gustavo A. R. Silva wrote:
> It seems that this is a copy/paste error and the proper bit masking is:
> BIT_TXNIE | BIT_RXIE
>
> This issue was detected with the help of Coccinelle.
>
> Reported-by: Julia Lawall
> Signed-off-by: Gustavo A. R. Silva
> Fixes: 7d840545e5b9 ("mrf24j40: replace magic numbers")
> ---
> drivers/net/ieee802154/mrf24j40.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ieee802154/mrf24j40.c
> b/drivers/net/ieee802154/mrf24j40.c
> index ee7084b..cf4788d 100644
> --- a/drivers/net/ieee802154/mrf24j40.c
> +++ b/drivers/net/ieee802154/mrf24j40.c
> @@ -635,7 +635,7 @@ static void mrf24j40_stop(struct ieee802154_hw *hw)
>
> /* Set TXNIE and RXIE. Disable Interrupts */
> regmap_update_bits(devrec->regmap_short, REG_INTCON,
> -BIT_TXNIE | BIT_TXNIE, BIT_TXNIE | BIT_TXNIE);
> +BIT_TXNIE | BIT_RXIE, BIT_TXNIE | BIT_RXIE);
> }
>
> static int mrf24j40_set_channel(struct ieee802154_hw *hw, u8 page, u8
> channel)
>
Could you review this and give me your ack when you are happy so I can apply it
to my tree?
regards
Stefan Schmidt
Re: linux-4.14-rc3/drivers/net/ieee802154/atusb.c:827: pointless test ?
Hello. [Sorry for the delay, not really at my machine the last few weeks] On 10/06/2017 09:06 PM, David Binderman wrote: > Hello there, > > linux-4.14-rc3/drivers/net/ieee802154/atusb.c:827]: (style) Unsigned variable > 'fw_ver_maj' can't be negative so it is unnecessary to test it. > > Source code is > > if (atusb->fw_ver_maj >= 0 && atusb->fw_ver_min >= 3) > > but > > unsigned char fw_ver_maj; /* Firmware major version number */ > > Suggest remove pointless test. Thanks for pointing this out. Geert pointed the compiler warnign out a while ago and I actually did a fix that works for it already. https://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git/commit/?id=763556980dde78166886734ae470664c67067dd4 Its waiting for getting pulled into net-next right now. regards Stefan Schmidt
Re: [PATCH] inet: frags: Convert timers to use timer_setup()
Hello.
On 05.10.2017 02:52, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Alexander Aring
> Cc: Stefan Schmidt
> Cc: "David S. Miller"
> Cc: Alexey Kuznetsov
> Cc: Hideaki YOSHIFUJI
> Cc: Pablo Neira Ayuso
> Cc: Jozsef Kadlecsik
> Cc: Florian Westphal
> Cc: linux-w...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: netfilter-de...@vger.kernel.org
> Cc: coret...@netfilter.org
> Cc: Thomas Gleixner
> Signed-off-by: Kees Cook
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.
> ---
> include/net/inet_frag.h | 2 +-
> net/ieee802154/6lowpan/reassembly.c | 5 +++--
> net/ipv4/inet_fragment.c| 4 ++--
> net/ipv4/ip_fragment.c | 5 +++--
> net/ipv6/netfilter/nf_conntrack_reasm.c | 5 +++--
> net/ipv6/reassembly.c | 5 +++--
> 6 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
> index fc59e0775e00..c695807ca707 100644
> --- a/include/net/inet_frag.h
> +++ b/include/net/inet_frag.h
> @@ -95,7 +95,7 @@ struct inet_frags {
> void(*constructor)(struct inet_frag_queue *q,
> const void *arg);
> void(*destructor)(struct inet_frag_queue *);
> - void(*frag_expire)(unsigned long data);
> + void(*frag_expire)(struct timer_list *t);
> struct kmem_cache *frags_cachep;
> const char *frags_cache_name;
> };
> diff --git a/net/ieee802154/6lowpan/reassembly.c
> b/net/ieee802154/6lowpan/reassembly.c
> index f85b08baff16..85bf86ad6b18 100644
> --- a/net/ieee802154/6lowpan/reassembly.c
> +++ b/net/ieee802154/6lowpan/reassembly.c
> @@ -80,12 +80,13 @@ static void lowpan_frag_init(struct inet_frag_queue *q,
> const void *a)
> fq->daddr = *arg->dst;
> }
>
> -static void lowpan_frag_expire(unsigned long data)
> +static void lowpan_frag_expire(struct timer_list *t)
> {
> + struct inet_frag_queue *frag = from_timer(frag, t, timer);
> struct frag_queue *fq;
> struct net *net;
>
> - fq = container_of((struct inet_frag_queue *)data, struct frag_queue, q);
> + fq = container_of(frag, struct frag_queue, q);
> net = container_of(fq->q.net, struct net, ieee802154_lowpan.frags);
>
> spin_lock(&fq->q.lock);
> diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> index af74d0433453..7f3ef5c287a1 100644
> --- a/net/ipv4/inet_fragment.c
> +++ b/net/ipv4/inet_fragment.c
> @@ -147,7 +147,7 @@ inet_evict_bucket(struct inet_frags *f, struct
> inet_frag_bucket *hb)
> spin_unlock(&hb->chain_lock);
>
> hlist_for_each_entry_safe(fq, n, &expired, list_evictor)
> - f->frag_expire((unsigned long) fq);
> + f->frag_expire(&fq->timer);
>
> return evicted;
> }
> @@ -366,7 +366,7 @@ static struct inet_frag_queue *inet_frag_alloc(struct
> netns_frags *nf,
> f->constructor(q, arg);
> add_frag_mem_limit(nf, f->qsize);
>
> - setup_timer(&q->timer, f->frag_expire, (unsigned long)q);
> + timer_setup(&q->timer, f->frag_expire, 0);
> spin_lock_init(&q->lock);
> refcount_set(&q->refcnt, 1);
>
> diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
> index 46408c220d9d..9215654a401f 100644
> --- a/net/ipv4/ip_fragment.c
> +++ b/net/ipv4/ip_fragment.c
> @@ -190,12 +190,13 @@ static bool frag_expire_skip_icmp(u32 user)
> /*
> * Oops, a fragment queue timed out. Kill it and send an ICMP reply.
> */
> -static void ip_expire(unsigned long arg)
> +static void ip_expire(struct timer_list *t)
> {
> + struct inet_frag_queue *frag = from_timer(frag, t, timer);
> struct ipq *qp;
> struct net *net;
>
> - qp = container_of((struct inet_frag_queue *) arg, struct ipq, q);
> + qp = container_of(frag, struct ipq, q);
> net = container_of(qp->q.net, struct net, ipv4.frags);
>
> rcu_read_lock();
> diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c
> b/net/ipv6/netfilter/nf_conntrack_reasm.c
> index b263bf3a19f7..977d8900cfd1 100644
> --- a/net/ipv6/netfilter/nf_conntrack_reasm.c
> +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
> @@ -169,12 +1
Re: [PATCH][next] ieee802154: atusb: make two structures static, fixes warnings
Hello.
On 09/26/2017 03:18 PM, Colin King wrote:
> From: Colin Ian King
>
> The arrays atusb_chip_data and hulusb_chip_data are local to the source
> and do not need to be in global scope, so make them static. Also
> remove unnecessary forward declaration of atusb_chip_data.
>
> Cleans up sparse warnings:
> symbol 'atusb_chip_data' was not declared. Should it be static?
> symbol 'hulusb_chip_data' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King
> ---
> drivers/net/ieee802154/atusb.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
> index 115fa3f37a86..8b0718de568f 100644
> --- a/drivers/net/ieee802154/atusb.c
> +++ b/drivers/net/ieee802154/atusb.c
> @@ -45,8 +45,6 @@
> #define ATUSB_ALLOC_DELAY_MS 100 /* delay after failed allocation */
> #define ATUSB_TX_TIMEOUT_MS 200 /* on the air timeout */
>
> -struct atusb_chip_data;
> -
> struct atusb {
> struct ieee802154_hw *hw;
> struct usb_device *usb_dev;
> @@ -767,14 +765,14 @@ atusb_set_promiscuous_mode(struct ieee802154_hw *hw,
> const bool on)
> return 0;
> }
>
> -struct atusb_chip_data atusb_chip_data = {
> +static struct atusb_chip_data atusb_chip_data = {
> .t_channel_switch = 1,
> .rssi_base_val = -91,
> .set_txpower = atusb_set_txpower,
> .set_channel = atusb_set_channel,
> };
>
> -struct atusb_chip_data hulusb_chip_data = {
> +static struct atusb_chip_data hulusb_chip_data = {
> .t_channel_switch = 11,
> .rssi_base_val = -100,
> .set_txpower = hulusb_set_txpower,
>
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: fix gcc-4.9 warnings
Hello.
On 09/12/2017 12:16 PM, Arnd Bergmann wrote:
All older compiler versions up to gcc-4.9 produce these
harmless warnings:
drivers/net/ieee802154/ca8210.c: In function 'ca8210_skb_tx':
drivers/net/ieee802154/ca8210.c:1947:9: warning: missing braces around
initializer [-Wmissing-braces]
This changes the syntax to something that works on all versions
without warnings.
Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Signed-off-by: Arnd Bergmann
---
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 24a1eabbbc9d..e6b8ce81a6c3 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -1944,7 +1944,7 @@ static int ca8210_skb_tx(
)
{
int status;
- struct ieee802154_hdr header = { 0 };
+ struct ieee802154_hdr header = { };
struct secspec secspec;
unsigned int mac_len;
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH 3/7] ieee802154: 6lowpan: make header_ops const
Hello.
On 08/25/2017 04:21 PM, Bhumika Goyal wrote:
Make this const as it is only stored as a reference in a const field of
a net_device structure.
Signed-off-by: Bhumika Goyal
---
net/ieee802154/6lowpan/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
index de2661c..974765b 100644
--- a/net/ieee802154/6lowpan/core.c
+++ b/net/ieee802154/6lowpan/core.c
@@ -54,7 +54,7 @@
static int open_count;
-static struct header_ops lowpan_header_ops = {
+static const struct header_ops lowpan_header_ops = {
.create = lowpan_header_create,
};
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH] net: ieee802154: fix net_device reference release too early
Hello. On Thu, 2017-05-18 at 15:14, Stefan Schmidt wrote: > Hello. > > On Thu, 2017-05-18 at 15:50, linzhang wrote: > > This patch fixes the kernel oops when release net_device reference in > > advance. In function raw_sendmsg(i think the dgram_sendmsg has the same > > problem), there is a race condition between dev_put and dev_queue_xmit > > when the device is gong that maybe lead to dev_queue_ximt to see > > an illegal net_device pointer. > > > > You have a test case to reproduce this oops? I fear I have not seen > one. If you have a test case handy adding it to the commit would be handy. If you do not have one around we can do without. > > So i think that dev_put should be behind of the dev_queue_xmit. > > > > Also, explicit set skb->sk is needless, sock_alloc_send_skb is > > already set it. > > You could have put this fixup in a different patch. I actually would request you to split this into two patches. One for the removal of the sk setting and one for the race condition fix. > > Signed-off-by: linzhang > > This looks more like a username instead of a real name. If you have Lin > Zhang as you English real name that would be better here. :) This would be also appreciated. > > --- > > net/ieee802154/socket.c | 10 -- > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c > > index eedba76..a60658c 100644 > > --- a/net/ieee802154/socket.c > > +++ b/net/ieee802154/socket.c > > @@ -301,15 +301,14 @@ static int raw_sendmsg(struct sock *sk, struct msghdr > > *msg, size_t size) > > goto out_skb; > > > > skb->dev = dev; > > - skb->sk = sk; > > skb->protocol = htons(ETH_P_IEEE802154); > > > > - dev_put(dev); > > - > > err = dev_queue_xmit(skb); > > if (err > 0) > > err = net_xmit_errno(err); > > > > + dev_put(dev); > > + > > return err ?: size; > > > > out_skb: > > @@ -690,15 +689,14 @@ static int dgram_sendmsg(struct sock *sk, struct > > msghdr *msg, size_t size) > > goto out_skb; > > > > skb->dev = dev; > > - skb->sk = sk; > > skb->protocol = htons(ETH_P_IEEE802154); > > > > - dev_put(dev); > > - > > err = dev_queue_xmit(skb); > > if (err > 0) > > err = net_xmit_errno(err); > > > > + dev_put(dev); > > + > > return err ?: size; > > Going to give this a test ride here now. I gave it a ride in my testbed and I encountered no problems. While I have never seen the race and oops myself doing the dev_put before the xmit can surely lead to such a race and the fix is valid. Once you have done the changes requested above and re-submit your two patches you can add my Acked-by: Stefan Schmidt to both of them. regards Stefan Schmidt
Re: [PATCH] net: ieee802154: fix net_device reference release too early
Hello. On Thu, 2017-05-18 at 15:50, linzhang wrote: > This patch fixes the kernel oops when release net_device reference in > advance. In function raw_sendmsg(i think the dgram_sendmsg has the same > problem), there is a race condition between dev_put and dev_queue_xmit > when the device is gong that maybe lead to dev_queue_ximt to see > an illegal net_device pointer. > You have a test case to reproduce this oops? I fear I have not seen one. > So i think that dev_put should be behind of the dev_queue_xmit. > > Also, explicit set skb->sk is needless, sock_alloc_send_skb is > already set it. You could have put this fixup in a different patch. > Signed-off-by: linzhang This looks more like a username instead of a real name. If you have Lin Zhang as you English real name that would be better here. :) > --- > net/ieee802154/socket.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c > index eedba76..a60658c 100644 > --- a/net/ieee802154/socket.c > +++ b/net/ieee802154/socket.c > @@ -301,15 +301,14 @@ static int raw_sendmsg(struct sock *sk, struct msghdr > *msg, size_t size) > goto out_skb; > > skb->dev = dev; > - skb->sk = sk; > skb->protocol = htons(ETH_P_IEEE802154); > > - dev_put(dev); > - > err = dev_queue_xmit(skb); > if (err > 0) > err = net_xmit_errno(err); > > + dev_put(dev); > + > return err ?: size; > > out_skb: > @@ -690,15 +689,14 @@ static int dgram_sendmsg(struct sock *sk, struct msghdr > *msg, size_t size) > goto out_skb; > > skb->dev = dev; > - skb->sk = sk; > skb->protocol = htons(ETH_P_IEEE802154); > > - dev_put(dev); > - > err = dev_queue_xmit(skb); > if (err > 0) > err = net_xmit_errno(err); > > + dev_put(dev); > + > return err ?: size; Going to give this a test ride here now. regards Stefan Schmidt
Re: [PATCH] Add checks for kmalloc allocation failures
Hello.
On 03/29/2017 06:21 PM, Eric Dumazet wrote:
On Wed, 2017-03-29 at 16:54 +0100, Colin King wrote:
From: Colin Ian King
Ensure we don't end up with a null pointer dereferences by checking
for for allocation failures. Allocate by sizeof(*ptr) rather than
the type to fix checkpack warnings. Also merge multiple lines into
one line for the kmalloc call.
Detected by CoverityScan, CID#1422435 ("Dereference null return value")
OK, but could you change patch title to be less generic ?
Also, what tree is this patch targeting ?
# ls -l drivers/net/ieee802154/ca8210.c
ls: cannot access drivers/net/ieee802154/ca8210.c: No such file or
directory
This new driver is sitting in bluetooth-next right now for the next merge.
regards
Stefan Schmidt
Re: [ieee802154_unregister_hw] bea5b158ff BUG: scheduling while atomic: swapper/1/0x00000002
Hello.
On 02/26/2017 12:07 PM, Alexander Aring wrote:
Hi,
On 02/26/2017 10:43 AM, Fengguang Wu wrote:
Greetings,
FYI, this debug patch discloses an old-but-still-active bug in
ieee802154/fakelb. The attached reproduce-* script may help debug it.
fixed by: bdca1fd9a6df ("fakelb: fix schedule while atomic").
Some more context. Looking at your config and script file names they
suggest this is tested with 4.8.0-rc4. Fengguang, is that correct?
The fix from above is in 4.8.0-rc7
git describe bdca1fd9a6df
v4.8-rc6-1377-gbdca1fd
It should be send to stable. Stefan can you do that please?
The latest stable kernel is 4.10.1 and the latest longterm stable is
4.9.13. Both of them should have this fix already.
If there is a desire I could try sending it for the older longterm
stable tree 4.4.x. Not sure if this is really worth the effort. Comments?
regards
Stefan Schmidt
Re: [PATCH] at86rf230: Allow slow GPIO pins for "rstn"
Hello. On 21/12/16 19:30, Chris Healy wrote: On Dec 21, 2016 5:11 AM, "Stefan Schmidt" mailto:ste...@osg.samsung.com>> wrote: Hello. On 19/12/16 00:25, Andrey Smirnov wrote: Driver code never touches "rstn" signal in atomic context, so there's no need to implicitly put such restriction on it by using gpio_set_value to manipulate it. Replace gpio_set_value to gpio_set_value_cansleep to fix that. We need to make sure we are not assuming it can be called in such a context in the future now. But that is something we can worry about if it comes up. As a an example of where such restriction might be inconvenient, consider a hardware design where "rstn" is connected to a pin of I2C/SPI GPIO expander chip. Is this a real life issue you run into? I have a platform with this configuration. The DTS for the platform is in the process of being mainlined right now. Thanks for letting us know. What platform is that? I'm always interested in hearing about devices that use the Linux ieee802154 subsystem. :) regards Stefan Schmidt
Re: [PATCH] at86rf230: Allow slow GPIO pins for "rstn"
Hello.
On 19/12/16 00:25, Andrey Smirnov wrote:
Driver code never touches "rstn" signal in atomic context, so there's
no need to implicitly put such restriction on it by using gpio_set_value
to manipulate it. Replace gpio_set_value to gpio_set_value_cansleep to
fix that.
We need to make sure we are not assuming it can be called in such a
context in the future now. But that is something we can worry about if
it comes up.
As a an example of where such restriction might be inconvenient,
consider a hardware design where "rstn" is connected to a pin of I2C/SPI
GPIO expander chip.
Is this a real life issue you run into?
Cc: Chris Healy
Signed-off-by: Andrey Smirnov
---
drivers/net/ieee802154/at86rf230.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/at86rf230.c
b/drivers/net/ieee802154/at86rf230.c
index 9f10da6..7700690 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
@@ -1710,9 +1710,9 @@ static int at86rf230_probe(struct spi_device *spi)
/* Reset */
if (gpio_is_valid(rstn)) {
udelay(1);
- gpio_set_value(rstn, 0);
+ gpio_set_value_cansleep(rstn, 0);
udelay(1);
- gpio_set_value(rstn, 1);
+ gpio_set_value_cansleep(rstn, 1);
usleep_range(120, 240);
}
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH 5/8] linux: drop __bitwise__ everywhere
t;
+typedef uint32_t __bitwise itt_t;
/* below makes sense only for initiator that created this tag */
#define build_itt(itt, age) ((__force itt_t)\
((itt) | ((age) << ISCSI_AGE_SHIFT)))
diff --git a/include/target/target_core_base.h
b/include/target/target_core_base.h
index c211900..0055828 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -149,7 +149,7 @@ enum se_cmd_flags_table {
* Used by transport_send_check_condition_and_sense()
* to signal which ASC/ASCQ sense payload should be built.
*/
-typedef unsigned __bitwise__ sense_reason_t;
+typedef unsigned __bitwise sense_reason_t;
enum tcm_sense_reason_table {
#define R(x) (__force sense_reason_t )(x)
diff --git a/include/uapi/linux/virtio_types.h
b/include/uapi/linux/virtio_types.h
index e845e8c..55c3b73 100644
--- a/include/uapi/linux/virtio_types.h
+++ b/include/uapi/linux/virtio_types.h
@@ -39,8 +39,8 @@
* - __le{16,32,64} for standard-compliant virtio devices
*/
-typedef __u16 __bitwise__ __virtio16;
-typedef __u32 __bitwise__ __virtio32;
-typedef __u64 __bitwise__ __virtio64;
+typedef __u16 __bitwise __virtio16;
+typedef __u32 __bitwise __virtio32;
+typedef __u64 __bitwise __virtio64;
#endif /* _UAPI_LINUX_VIRTIO_TYPES_H */
diff --git a/net/ieee802154/6lowpan/6lowpan_i.h
b/net/ieee802154/6lowpan/6lowpan_i.h
index 5ac7789..ac7c96b 100644
--- a/net/ieee802154/6lowpan/6lowpan_i.h
+++ b/net/ieee802154/6lowpan/6lowpan_i.h
@@ -7,7 +7,7 @@
#include
#include
-typedef unsigned __bitwise__ lowpan_rx_result;
+typedef unsigned __bitwise lowpan_rx_result;
#define RX_CONTINUE((__force lowpan_rx_result) 0u)
#define RX_DROP_UNUSABLE ((__force lowpan_rx_result) 1u)
#define RX_DROP((__force lowpan_rx_result) 2u)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index d37a577..b2069fb 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -159,7 +159,7 @@ enum ieee80211_bss_valid_data_flags {
IEEE80211_BSS_VALID_ERP = BIT(3)
};
-typedef unsigned __bitwise__ ieee80211_tx_result;
+typedef unsigned __bitwise ieee80211_tx_result;
#define TX_CONTINUE((__force ieee80211_tx_result) 0u)
#define TX_DROP((__force ieee80211_tx_result) 1u)
#define TX_QUEUED ((__force ieee80211_tx_result) 2u)
@@ -180,7 +180,7 @@ struct ieee80211_tx_data {
};
-typedef unsigned __bitwise__ ieee80211_rx_result;
+typedef unsigned __bitwise ieee80211_rx_result;
#define RX_CONTINUE((__force ieee80211_rx_result) 0u)
#define RX_DROP_UNUSABLE ((__force ieee80211_rx_result) 1u)
#define RX_DROP_MONITOR((__force ieee80211_rx_result) 2u)
For net/ieee802154/6lowpan/6lowpan_i.h
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH 1/1] Fixed to BUG_ON to WARN_ON def
Hello. On 12/12/16 11:58, Ozgur Karatas wrote: Hello all, I think should be use to "WARN_ON" and checkpatch script give to error, I fixed and I think should don't use "BUG_ON". Regards, Signed-off-by: Ozgur Karatas I pointed you already before to the Documentation how to prepare a commit subject and commit message. You just replied with that you are new to contributing patches. That is all fine and many people are new each release. Please take the time to read the provided and pointed out docs. If you keep ignoring such suggestions and docs I would think people will keep ignoring your patches. regards Stefan Schmidt
Re: [PATCH] Fixed to checkpatch.pl errors to vlan_dev.c
Hello.
On 05/12/16 16:34, Ozgur Karatas wrote:
Hello all,
I will solve a checkpatch errors.
Signed-off-by: Ozgur Karatas
The patch itself looks good, but please have a read about having a good
commit message. I would suggest reading Documentation/SubmittingPatches
section 14: The canonical patch format
Especially the parts about the subject line and summary.
---
net/8021q/vlan_dev.c | 2 +-
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index fbfacd5..2edb495 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -738,7 +738,7 @@ static int vlan_dev_netpoll_setup(struct net_device *dev,
struct netpoll_info *n
static void vlan_dev_netpoll_cleanup(struct net_device *dev)
{
- struct vlan_dev_priv *vlan= vlan_dev_priv(dev);
+ struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
struct netpoll *netpoll = vlan->netpoll;
if (!netpoll)
regards
Stefan Schmidt
Re: [PATCH] ARM: pxa: ezx: fix a910 camera data
Hello.
On 03.12.2016 17:55, Antonio Ospite wrote:
> On Sat, 26 Nov 2016 00:30:52 +0100
> Stefan Schmidt wrote:
>
>> Hello.
>>
>
> Hi everyone,
>
>> On 25.11.2016 20:53, Robert Jarzmik wrote:
>>> Stefan Schmidt writes:
>>>
>>>> Hello.
>>>>
>>>> On 24.11.2016 17:29, Arnd Bergmann wrote:
>>>>> The camera_supply_dummy_device definition is shared between a780 and a910,
>>>>> but only provided when the first is enabled and fails to build for a
>>>>> configuration with only a910:
>>>>>
>>>>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device'
>>>>> undeclared here (not in a function)
>>>>>
>>>>> This moves the definition into its own section.
>>>>>
>>>>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera
>>>>> platform_data")
>>>>> Signed-off-by: Arnd Bergmann
>>>>> ---
>>>>> arch/arm/mach-pxa/ezx.c | 56
>>>>> ++---
>>>>
>>>> I wonder what we should do with ezx.c.
>>>>
>>>> As far as I know neither Daniel nor Harald or myself are doing anything
>>>> with this devices anymore. Besides a basic compile test having an ack or
>>>> reviewed by from our side is a bit worthless. :/
>>>>
>>>> I should still have some of these phones around in a box somewhere. If
>>>> there is someone with a good motivation and time to take over on this
>>>> platform we will find a way to get the person this devices.
>>>>
>>>> Any takers? Robert? I guess you are already overloaded but you might
>>>> also have an interest. Worth asking :)
>>> Oh yes, I'm very interested in your box. Besides I really like old platforms
>>> :)
>>
>>
>> Great! I should have at least 3 or 4 different devices from the EZX
>> platform around. I will go and search for the box over the weekend :)
>>
>>>> In the case nobody wants to pick up here what would you consider the
>>>> bets way forward? I could send a patch removing ezx platform support
>>>> from the kernel (basically ezx.c plus build support) or I can send a
>>>> patch marking it at least orphan in MAINTAINERS. Let me know what you
>>>> think.
>>>>
>>>> Daniel, Harald, if one of you is still interested in these and what to
>>>> pick up the work again, please speak up now. :)
>>> Unless another maintainer steps in, you can submit a patch to transfer the
>>> maintainance onto me, and we'll see off mailing lists how we could arange
>>> the
>>> boards transfer.
>>
>> I cc'ed another developer who did a lot of work regarding EZX.
>>
>> Antonio, as you can see from the mail above we are pondering what who
>> will maintain the ezx platform in the kernel going forward. Neither
>> Daniel, Harald or me is going to do so. If you have time, interest and
>> motivation to do so please speak up. I know life moved on and you ahve
>> other projects and interests so do not feel pressured here. Just say no
>> if you have no interest. Robert already agreed to act as a fallback so
>> we would still be safe. :)
>>
>
> I still use a Motorola A1200 with the original EZX stack as my main
> phone (and that tells something about how much I use a phone...)
hehe :)
> however I haven't touched any OpenEZX stuff in a while.
>
> I don't think I am going to play with these devices anytime soon, but I
> can provide Robert any info he may need about OpenEZX, the development
> tools and the out-of-tree patches required to make the phones somewhat
> usable.
Great. I think this will be a great help for Robert when he tries to get
things going. Thanks a lot!
Robert, please send me your address details off list so we can arrange
for the device shipping. I will send a patch transferring the
maintainership for the EZX platform over to you in the next days.
regards
Stefan Schmidt
Re: [PATCH] ARM: pxa: ezx: fix a910 camera data
Hello.
On 25.11.2016 20:53, Robert Jarzmik wrote:
> Stefan Schmidt writes:
>
>> Hello.
>>
>> On 24.11.2016 17:29, Arnd Bergmann wrote:
>>> The camera_supply_dummy_device definition is shared between a780 and a910,
>>> but only provided when the first is enabled and fails to build for a
>>> configuration with only a910:
>>>
>>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device'
>>> undeclared here (not in a function)
>>>
>>> This moves the definition into its own section.
>>>
>>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
>>> Signed-off-by: Arnd Bergmann
>>> ---
>>> arch/arm/mach-pxa/ezx.c | 56
>>> ++---
>>
>> I wonder what we should do with ezx.c.
>>
>> As far as I know neither Daniel nor Harald or myself are doing anything
>> with this devices anymore. Besides a basic compile test having an ack or
>> reviewed by from our side is a bit worthless. :/
>>
>> I should still have some of these phones around in a box somewhere. If
>> there is someone with a good motivation and time to take over on this
>> platform we will find a way to get the person this devices.
>>
>> Any takers? Robert? I guess you are already overloaded but you might
>> also have an interest. Worth asking :)
> Oh yes, I'm very interested in your box. Besides I really like old platforms
> :)
Great! I should have at least 3 or 4 different devices from the EZX
platform around. I will go and search for the box over the weekend :)
>> In the case nobody wants to pick up here what would you consider the
>> bets way forward? I could send a patch removing ezx platform support
>> from the kernel (basically ezx.c plus build support) or I can send a
>> patch marking it at least orphan in MAINTAINERS. Let me know what you think.
>>
>> Daniel, Harald, if one of you is still interested in these and what to
>> pick up the work again, please speak up now. :)
> Unless another maintainer steps in, you can submit a patch to transfer the
> maintainance onto me, and we'll see off mailing lists how we could arange the
> boards transfer.
I cc'ed another developer who did a lot of work regarding EZX.
Antonio, as you can see from the mail above we are pondering what who
will maintain the ezx platform in the kernel going forward. Neither
Daniel, Harald or me is going to do so. If you have time, interest and
motivation to do so please speak up. I know life moved on and you ahve
other projects and interests so do not feel pressured here. Just say no
if you have no interest. Robert already agreed to act as a fallback so
we would still be safe. :)
regards
Stefan Schmidt
Re: [PATCH] ARM: pxa: ezx: fix a910 camera data
Hello.
On 24.11.2016 17:29, Arnd Bergmann wrote:
> The camera_supply_dummy_device definition is shared between a780 and a910,
> but only provided when the first is enabled and fails to build for a
> configuration with only a910:
>
> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device'
> undeclared here (not in a function)
>
> This moves the definition into its own section.
>
> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/mach-pxa/ezx.c | 56
> ++---
I wonder what we should do with ezx.c.
As far as I know neither Daniel nor Harald or myself are doing anything
with this devices anymore. Besides a basic compile test having an ack or
reviewed by from our side is a bit worthless. :/
I should still have some of these phones around in a box somewhere. If
there is someone with a good motivation and time to take over on this
platform we will find a way to get the person this devices.
Any takers? Robert? I guess you are already overloaded but you might
also have an interest. Worth asking :)
In the case nobody wants to pick up here what would you consider the
bets way forward? I could send a patch removing ezx platform support
from the kernel (basically ezx.c plus build support) or I can send a
patch marking it at least orphan in MAINTAINERS. Let me know what you think.
Daniel, Harald, if one of you is still interested in these and what to
pick up the work again, please speak up now. :)
regards
Stefan Schmidt
Re: [PATCH] net: ieee802154: drop duplicate header delay.h
Hello. On 24/11/16 14:58, Geliang Tang wrote: Drop duplicate header delay.h from adf7242.c. Signed-off-by: Geliang Tang --- drivers/net/ieee802154/adf7242.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c index 4ff4c7d..3e4c8b2 100644 --- a/drivers/net/ieee802154/adf7242.c +++ b/drivers/net/ieee802154/adf7242.c @@ -20,7 +20,6 @@ #include #include #include -#include #include #include #include Good catch. Acked-by: Stefan Schmidt regards Stefan Schmidt
Re: [PATCH] net: ieee802154: constify ieee802154_ops structures
Hello.
On 21/11/16 21:30, Bhumika Goyal wrote:
Declare the structure ieee802154_ops as const as it is only passed as an
argument to the function ieee802154_alloc_hw. This argument is of type
const struct ieee802154_ops *, so ieee80254_ops structures having this
property can be declared as const.
Done using Coccinelle:
@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct ieee802154_ops i@p = {...};
@ok1@
identifier r1.i;
position p;
expression e1;
@@
ieee802154_alloc_hw(e1,&i@p)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct ieee802154_ops i={...};
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct ieee802154_ops i;
The before and after size details of the affected files are:
textdata bss dec hex filename
86691176 1698612685 drivers/net/ieee802154/adf7242.o
88051048 169869268d drivers/net/ieee802154/adf7242.o
textdata bss dec hex filename
72112296 3295392543 drivers/net/ieee802154/atusb.o
73392160 329531253b drivers/net/ieee802154/atusb.o
Signed-off-by: Bhumika Goyal
---
drivers/net/ieee802154/adf7242.c | 2 +-
drivers/net/ieee802154/atusb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/adf7242.c b/drivers/net/ieee802154/adf7242.c
index 9fa7ac9..4ff4c7d 100644
--- a/drivers/net/ieee802154/adf7242.c
+++ b/drivers/net/ieee802154/adf7242.c
@@ -874,7 +874,7 @@ static int adf7242_rx(struct adf7242_local *lp)
return 0;
}
-static struct ieee802154_ops adf7242_ops = {
+static const struct ieee802154_ops adf7242_ops = {
.owner = THIS_MODULE,
.xmit_sync = adf7242_xmit,
.ed = adf7242_ed,
diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
index 1056ed1..322864a 100644
--- a/drivers/net/ieee802154/atusb.c
+++ b/drivers/net/ieee802154/atusb.c
@@ -567,7 +567,7 @@ static void atusb_stop(struct ieee802154_hw *hw)
return 0;
}
-static struct ieee802154_ops atusb_ops = {
+static const struct ieee802154_ops atusb_ops = {
.owner = THIS_MODULE,
.xmit_async = atusb_xmit,
.ed = atusb_ed,
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
Re: [PATCH 17/26] mac802154: Use skcipher
Hello.
On 24/01/16 14:18, Herbert Xu wrote:
This patch replaces uses of blkcipher with skcipher.
Signed-off-by: Herbert Xu
---
net/mac802154/llsec.c | 41 +++--
net/mac802154/llsec.h |3 +--
2 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index a13d02b..6a3e1c2 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -17,9 +17,9 @@
#include
#include
#include
-#include
#include
#include
+#include
#include "ieee802154_i.h"
#include "llsec.h"
@@ -144,18 +144,18 @@ llsec_key_alloc(const struct ieee802154_llsec_key
*template)
goto err_tfm;
}
- key->tfm0 = crypto_alloc_blkcipher("ctr(aes)", 0, CRYPTO_ALG_ASYNC);
+ key->tfm0 = crypto_alloc_skcipher("ctr(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(key->tfm0))
goto err_tfm;
- if (crypto_blkcipher_setkey(key->tfm0, template->key,
- IEEE802154_LLSEC_KEY_SIZE))
+ if (crypto_skcipher_setkey(key->tfm0, template->key,
+ IEEE802154_LLSEC_KEY_SIZE))
goto err_tfm0;
return key;
err_tfm0:
- crypto_free_blkcipher(key->tfm0);
+ crypto_free_skcipher(key->tfm0);
err_tfm:
for (i = 0; i < ARRAY_SIZE(key->tfm); i++)
if (key->tfm[i])
@@ -175,7 +175,7 @@ static void llsec_key_release(struct kref *ref)
for (i = 0; i < ARRAY_SIZE(key->tfm); i++)
crypto_free_aead(key->tfm[i]);
- crypto_free_blkcipher(key->tfm0);
+ crypto_free_skcipher(key->tfm0);
kzfree(key);
}
@@ -620,15 +620,17 @@ llsec_do_encrypt_unauth(struct sk_buff *skb, const struct mac802154_llsec *sec,
{
u8 iv[16];
struct scatterlist src;
- struct blkcipher_desc req = {
- .tfm = key->tfm0,
- .info = iv,
- .flags = 0,
- };
+ SKCIPHER_REQUEST_ON_STACK(req, key->tfm0);
+ int err;
llsec_geniv(iv, sec->params.hwaddr, &hdr->sec);
sg_init_one(&src, skb->data, skb->len);
- return crypto_blkcipher_encrypt_iv(&req, &src, &src, skb->len);
+ skcipher_request_set_tfm(req, key->tfm0);
+ skcipher_request_set_callback(req, 0, NULL, NULL);
+ skcipher_request_set_crypt(req, &src, &src, skb->len, iv);
+ err = crypto_skcipher_encrypt(req);
+ skcipher_request_zero(req);
+ return err;
}
static struct crypto_aead*
@@ -830,11 +832,8 @@ llsec_do_decrypt_unauth(struct sk_buff *skb, const struct
mac802154_llsec *sec,
unsigned char *data;
int datalen;
struct scatterlist src;
- struct blkcipher_desc req = {
- .tfm = key->tfm0,
- .info = iv,
- .flags = 0,
- };
+ SKCIPHER_REQUEST_ON_STACK(req, key->tfm0);
+ int err;
llsec_geniv(iv, dev_addr, &hdr->sec);
data = skb_mac_header(skb) + skb->mac_len;
@@ -842,7 +841,13 @@ llsec_do_decrypt_unauth(struct sk_buff *skb, const struct
mac802154_llsec *sec,
sg_init_one(&src, data, datalen);
- return crypto_blkcipher_decrypt_iv(&req, &src, &src, datalen);
+ skcipher_request_set_tfm(req, key->tfm0);
+ skcipher_request_set_callback(req, 0, NULL, NULL);
+ skcipher_request_set_crypt(req, &src, &src, datalen, iv);
+
+ err = crypto_skcipher_decrypt(req);
+ skcipher_request_zero(req);
+ return err;
}
static int
diff --git a/net/mac802154/llsec.h b/net/mac802154/llsec.h
index 950578e..6f3b658 100644
--- a/net/mac802154/llsec.h
+++ b/net/mac802154/llsec.h
@@ -19,7 +19,6 @@
#include
#include
-#include
#include
#include
#include
@@ -30,7 +29,7 @@ struct mac802154_llsec_key {
/* one tfm for each authsize (4/8/16) */
struct crypto_aead *tfm[3];
- struct crypto_blkcipher *tfm0;
+ struct crypto_skcipher *tfm0;
struct kref ref;
};
Reviewed-by: Stefan Schmidt
regards
Stefan Schmidt
Re: ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"
Hello. On 11/12/15 14:07, SF Markus Elfring wrote: this slipped through, but now it does no longer apply. Applying: ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb" error: patch failed: drivers/net/ieee802154/atusb.c:310 error: drivers/net/ieee802154/atusb.c: patch does not apply Patch failed at 0001 ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb" How can this hiccup happen? I might have been a problem when I was resending your patch the first time as Marcel was not able to find the original one. I have send it a second time now and it worked fine. The patch is already applied to the bluetooth-next tree and thus on its way. All good now. https://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=4188146566a9f1d57dfce77fd9457f7304b69dfa regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"
Hello. On 10/12/15 19:16, Marcel Holtmann wrote: Hi Stefan, From: Markus Elfring Date: Mon, 16 Nov 2015 13:50:23 +0100 The kfree_skb() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/ieee802154/atusb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c index 199a94a..b1cd865 100644 --- a/drivers/net/ieee802154/atusb.c +++ b/drivers/net/ieee802154/atusb.c @@ -310,8 +310,7 @@ static void atusb_free_urbs(struct atusb *atusb) urb = usb_get_from_anchor(&atusb->idle_urbs); if (!urb) break; -if (urb->context) -kfree_skb(urb->context); +kfree_skb(urb->context); usb_free_urb(urb); } } Acked-by: Stefan Schmidt You got the original patch and my ACK on this one or would you prefer me to resend it again? this slipped through, but now it does no longer apply. Applying: ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb" error: patch failed: drivers/net/ieee802154/atusb.c:310 error: drivers/net/ieee802154/atusb.c: patch does not apply Patch failed at 0001 ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb" Not good. I did another resend, this one applied, compiled and worked fine for me. You will be in the to line. regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"
Marcel, On 17/11/15 17:18, Stefan Schmidt wrote: Hello. On 17/11/15 17:17, Stefan Schmidt wrote: From: Markus Elfring Date: Mon, 16 Nov 2015 13:50:23 +0100 The kfree_skb() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/ieee802154/atusb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c index 199a94a..b1cd865 100644 --- a/drivers/net/ieee802154/atusb.c +++ b/drivers/net/ieee802154/atusb.c @@ -310,8 +310,7 @@ static void atusb_free_urbs(struct atusb *atusb) urb = usb_get_from_anchor(&atusb->idle_urbs); if (!urb) break; -if (urb->context) -kfree_skb(urb->context); +kfree_skb(urb->context); usb_free_urb(urb); } } Acked-by: Stefan Schmidt You got the original patch and my ACK on this one or would you prefer me to resend it again? regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"
Hello. On 17/11/15 15:01, Marcel Holtmann wrote: Hi Stefan, The kfree_skb() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/ieee802154/atusb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c index 199a94a..b1cd865 100644 --- a/drivers/net/ieee802154/atusb.c +++ b/drivers/net/ieee802154/atusb.c @@ -310,8 +310,7 @@ static void atusb_free_urbs(struct atusb *atusb) urb = usb_get_from_anchor(&atusb->idle_urbs); if (!urb) break; - if (urb->context) - kfree_skb(urb->context); + kfree_skb(urb->context); usb_free_urb(urb); } } Acked-by: Stefan Schmidt for some reason I am missing the original patch, can someone resend it please. Done. Resend the original message from my address but with the From line intact inside the patch. Please check if it really lists Markus as author when applying. Acked-by also resend as reply to the resend patch. regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"
From: Markus Elfring Date: Mon, 16 Nov 2015 13:50:23 +0100 The kfree_skb() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/ieee802154/atusb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c index 199a94a..b1cd865 100644 --- a/drivers/net/ieee802154/atusb.c +++ b/drivers/net/ieee802154/atusb.c @@ -310,8 +310,7 @@ static void atusb_free_urbs(struct atusb *atusb) urb = usb_get_from_anchor(&atusb->idle_urbs); if (!urb) break; - if (urb->context) - kfree_skb(urb->context); + kfree_skb(urb->context); usb_free_urb(urb); } } -- 2.6.2 -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"
Hello. On 17/11/15 17:17, Stefan Schmidt wrote: From: Markus Elfring Date: Mon, 16 Nov 2015 13:50:23 +0100 The kfree_skb() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/ieee802154/atusb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c index 199a94a..b1cd865 100644 --- a/drivers/net/ieee802154/atusb.c +++ b/drivers/net/ieee802154/atusb.c @@ -310,8 +310,7 @@ static void atusb_free_urbs(struct atusb *atusb) urb = usb_get_from_anchor(&atusb->idle_urbs); if (!urb) break; -if (urb->context) -kfree_skb(urb->context); +kfree_skb(urb->context); usb_free_urb(urb); } } Acked-by: Stefan Schmidt regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"
Hello. On 16/11/15 13:57, SF Markus Elfring wrote: From: Markus Elfring Date: Mon, 16 Nov 2015 13:50:23 +0100 The kfree_skb() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/net/ieee802154/atusb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c index 199a94a..b1cd865 100644 --- a/drivers/net/ieee802154/atusb.c +++ b/drivers/net/ieee802154/atusb.c @@ -310,8 +310,7 @@ static void atusb_free_urbs(struct atusb *atusb) urb = usb_get_from_anchor(&atusb->idle_urbs); if (!urb) break; - if (urb->context) - kfree_skb(urb->context); + kfree_skb(urb->context); usb_free_urb(urb); } } Acked-by: Stefan Schmidt regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mac802154: select CRYPTO when needed
Hello. On 19/05/15 14:18, Arnd Bergmann wrote: The mac802154 subsystem uses functions from the crypto layer and correctly selects the individual crypto algorithms, but fails to build when the crypto layer is disabled altogether: crypto/built-in.o: In function `crypto_ctr_free': :(.text+0x80): undefined reference to `crypto_drop_spawn' crypto/built-in.o: In function `crypto_rfc3686_free': :(.text+0xac): undefined reference to `crypto_drop_spawn' crypto/built-in.o: In function `crypto_ctr_crypt': :(.text+0x2f0): undefined reference to `blkcipher_walk_virt_block' :(.text+0x2f8): undefined reference to `crypto_inc' To solve that, this patch also selects the core crypto code, like all other users of that code do. Signed-off-by: Arnd Bergmann --- Found in ARM randconfig testing diff --git a/net/mac802154/Kconfig b/net/mac802154/Kconfig index aa462b480a39..b355989c63b3 100644 --- a/net/mac802154/Kconfig +++ b/net/mac802154/Kconfig @@ -1,6 +1,7 @@ config MAC802154 tristate "Generic IEEE 802.15.4 Soft Networking Stack (mac802154)" depends on IEEE802154 + select CRYPTO select CRC_CCITT select CRYPTO_AUTHENC select CRYPTO_CCM Good point. I thought that would have been pulled in by CRYPTO_* automatically. Nicely spotted. Reviewed-by: Stefan Schmidt regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Hello. On Sat, 2007-02-10 at 09:26, Neil Brown wrote: > On Friday February 9, [EMAIL PROTECTED] wrote: > > > > Ok. Now... any questions? > > > > Yes. Does this require a closed user-space helper like the other > 3945ABG driver, or is it completely open (maybe excepting firmware)? Quote from the mentioned website: "In addition to using the new d80211 subsystem, this project uses a new microcode image which removes the need for the user space regulatory daemon for this adapter" regards Stefan Schmidt signature.asc Description: Digital signature
Re: [patch 2/3] acpi: Add a docked sysfs file to the dock driver.
Hello.
On Wed, 2006-12-13 at 10:14, Kay Sievers wrote:
> On Wed, 2006-12-13 at 00:26 +0100, Stefan Schmidt wrote:
> > On Tue, 2006-12-12 at 15:00, Kristen Carlson Accardi wrote:
> > >
> > > I did have different dock/undock events a few months ago - but
> > > after some discussion we scrapped them because Kay wants to avoid driver
> > > specific events. The "change" event is the only thing that makes sense,
> > > given the set of uevents available right now, and userspace should be
> > > able to handle checking a file to get driver specific details (i.e. dock
> > > and undock status). If you have a specific reason why this won't work,
> > > let me know.
> >
> > It's fine with me. I just find two different events more handy.
> > Checking the file after the event in userspace should not be aproblem.
>
> The thing is that we try to avoid driver-core "features" that are
> specific to a single subsystem or driver.
>
> You can easily add additional environment variables today, while sending
> a "change"-event with kobject_uevent_env(), like
> ACPI_DOCK={lock,unlock,insert,remove,...}. Just pass any driver-specific
> string you like along with the event, and it will be available just like
> the "action" string.
Thanks for the explanation. I can live with both solutions. It's up to
Kristen.
> This should fit all requirements, without the need to introduce all
> sorts of new generic action-strings, that can almost never be changed
> later for compatibility reasons. That way, if "drivers" later find out,
> that they need to send different actions/flags, they can just add as
> many new strings as they like on top of the event. :)
Fair enough.
regards
Stefan Schmidt
signature.asc
Description: Digital signature
Re: [patch 2/3] acpi: Add a docked sysfs file to the dock driver.
Hello. On Tue, 2006-12-12 at 15:00, Kristen Carlson Accardi wrote: > > I did have different dock/undock events a few months ago - but > after some discussion we scrapped them because Kay wants to avoid driver > specific events. The "change" event is the only thing that makes sense, > given the set of uevents available right now, and userspace should be > able to handle checking a file to get driver specific details (i.e. dock > and undock status). If you have a specific reason why this won't work, > let me know. It's fine with me. I just find two different events more handy. Checking the file after the event in userspace should not be aproblem. regards Stefan Schmidt signature.asc Description: Digital signature
Re: [patch 2/3] acpi: Add a docked sysfs file to the dock driver.
Hello. On Mon, 2006-12-11 at 12:05, Kristen Carlson Accardi wrote: > On Sat, 9 Dec 2006 12:59:58 +0100 > Holger Macht <[EMAIL PROTECTED]> wrote: > > > Well, I like to have them ;-) > > Ok - how is this? > > Send a uevent to indicate a device change whenever we dock or > undock, so that userspace may now check the dock status via > sysfs. I would like to have two different events for dock and undock. This way the userspace listener don't need to check the status file in sysfs to know if there was a dock or undock after getting the event. Anyway the status file is still usefull for programs don't react on the events, but like to know if the laptop is docked before starting for example. regards Stefan Schmidt signature.asc Description: Digital signature
Re: [PATCH] acpi: add backlight support to the sony_acpi driver (v2)
Hello. On Wed, 2006-12-06 at 19:54, Pavel Machek wrote: > > Please don't top-post... > > > Its nice to see acpi moving to the backlight api. Will acpi also move to > > hwmon and led class support ? > > It would be nice... ACPI does not drive many leds ... usually ... I work on led class support for ibm-acpi. It's on is way. regards Stefan Schmidt signature.asc Description: Digital signature
e1000||ICH5-ATA BUG in 2.6.12-rc1 triggered by ill behaved CD-ROM drive
Here's the story again but shorter: (-> netdev: "(solved) Re: Fw: 2.6.11-mm2 weird ethernet RTTs" ) It seems after some reboot my CD-ROM drive went nuts and hogged up my IDE-Controller (ICH5) which in turn either generated a lot of interrupts or did not properly respond to em. Half of the time i tried booting the machine with the CD-ROM drive attached to ide1 and the HD at ide0 i experienced heavy disk timeouts due to DMA timeouts (°1) and the other half of the time the following kernel BUG was triggered. Removing the CD-ROM resolved all those problems. (typos probable - no camera was handy ;-() Configuring network interfaces ... --- cut here --- kernel BUG at include/linux/netdevice.h:860! invalid operand: [#1] PREEMPT SMP Modules linked in: ide_cd cdrom ... (left out some here) ... commoncap e1000 3c59x mii CPU: 0 EIP: 0060: [] Not tainted VLI EFLAGS: 00010046 (2.6.12-rc1) EIP is at e1000_clean+0xcb/0xe0 [e1000] eax: 0017 ebx: 0287 ecx: edx: e81e6000 esi: edi: de67e800 ebp: 0040 esp: c042efb0 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c042e000 task=c0360c00) Stack: de67ea40 de67e904 de67e800 c13f5fa0 c13f5f80 c02adedf fffbbf83 012c 0001 c03ec198 c0427bc0 c0123fc6 000a c03f4f88 0046 c03f4000 0047a007 c010552a Call Trace: [] net_rx_action+0x7f/0x110 [] __do_softirq+0xb6/0xd0 [] do_softirq+0x4a/0x60 [] irq_exit+0x39/0x40 [] do_IRQ+0x4d/0x70 [] common_interrupt+0x1a/0x20 [] default_idle+0x23/0x30 [] start_kernel+0x15f/0x180 [] unknown_bootoption+0x0/0x1e0 Code: c0 84 c0 74 1a 8b 82 24 02 00 00 b9 9d 00 00 00 89 88 d0 00 00 00 8b 82 24 02 00 00 8b 40 08 31 d2 82 c4 08 89 d0 5b 5e 5f 5d c3 <0f> 0b 5c 03 35 c6 05 e0 eb 91 8d 74 26 00 8d bc 27 00 00 00 00 <0> Kernel panic - not syncing: Fatal exception in interrupt e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex --- The End --- Kernel-config and lspci -vvv attached. °1: Mar 18 14:47:53 giscard kernel: irq 177: nobody cared! Mar 18 14:47:53 giscard kernel: [__report_bad_irq+36/144] __report_bad_irq+0x24/0x90 Mar 18 14:47:53 giscard kernel: [note_interrupt+97/144] note_interrupt+0x61/0x90 Mar 18 14:47:53 giscard kernel: [__do_IRQ+284/288] __do_IRQ+0x11c/0x120 Mar 18 14:47:53 giscard kernel: [do_IRQ+70/112] do_IRQ+0x46/0x70 Mar 18 14:47:53 giscard kernel: === Mar 18 14:47:53 giscard kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20 Mar 18 14:47:53 giscard kernel: [default_idle+35/48] default_idle+0x23/0x30 Mar 18 14:47:53 giscard kernel: [cpu_idle+95/112] cpu_idle+0x5f/0x70 Mar 18 14:47:53 giscard kernel: [start_kernel+351/384] start_kernel+0x15f/0x180 Mar 18 14:47:53 giscard kernel: [unknown_bootoption+0/448] unknown_bootoption+0x0/0x1c0 Mar 18 14:47:53 giscard kernel: handlers: Mar 18 14:47:53 giscard kernel: [ide_intr+0/336] (ide_intr+0x0/0x150) Mar 18 14:47:53 giscard kernel: [ide_intr+0/336] (ide_intr+0x0/0x150) Mar 18 14:47:53 giscard kernel: [usb_hcd_irq+0/96] (usb_hcd_irq+0x0/0x60) Mar 18 14:47:53 giscard kernel: [pg0+532648896/1069179904] (e1000_intr+0x0/0x110 [e1000]) Mar 18 14:47:53 giscard kernel: Disabling IRQ #177 Mar 18 14:47:53 giscard kernel: hda: dma_timer_expiry: dma status == 0x24 Mar 18 14:47:53 giscard kernel: hda: DMA interrupt recovery Mar 18 14:47:53 giscard kernel: hda: lost interrupt Stefan -- "Reality is a poor substitute for my dreams." - anonymous :00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 80a5 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- :00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Asustek Computer, Inc. P4P800 Mainboard Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1 # Fri Mar 18 13:49:06 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG
