Re: [PATCH] [v4] ieee802154: ca8210: Fix a potential UAF in ca8210_probe

[Stefan Schmidt]

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

[Stefan Schmidt]

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

[Stefan Schmidt]

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(
>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

[Stefan Schmidt]

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

[Stefan Schmidt]

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

[Stefan Schmidt]

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

[Stefan Schmidt]

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

[Stefan Schmidt]

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

[Stefan Schmidt]

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 

Re: [PATCH 4/8] net: mac802154: convert tasklets to use new tasklet_setup() API

[Stefan Schmidt]

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(>skb_queue))) {

@@ -91,9 +91,7 @@ ieee802154_alloc_hw(size_t priv_data_len, const struct 
ieee802154_ops *ops)
INIT_LIST_HEAD(>interfaces);
mutex_init(>iflist_mtx);
  
-	tasklet_init(>tasklet,

-ieee802154_tasklet_handler,
-(unsigned long)local);
+   tasklet_setup(>tasklet, ieee802154_tasklet_handler);
  
  	skb_queue_head_init(>skb_queue);
  




Acked-by: Stefan Schmidt 

regards
Stefan Schmidt

Re: [PATCH] ieee802154/adf7242: check status of adf7242_read_reg

[Stefan Schmidt]

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, _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, _u8);

+   ret = adf7242_read_reg(lp, 0, _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

[Stefan Schmidt]

ockptr(, 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(, optval, optlen))

+   if (copy_from_sockptr(, 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(, 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

[Stefan Schmidt]

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

[Stefan Schmidt]

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

[Stefan Schmidt]

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(_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()'

[Stefan Schmidt]

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()'

[Stefan Schmidt]

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

[Stefan Schmidt]

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(_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

[Stefan Schmidt]

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

[Stefan Schmidt]

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(_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

[Stefan Schmidt]

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

[Stefan Schmidt]

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(
>   >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

[Stefan Schmidt]

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

[Stefan Schmidt]

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 = >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(>up_fifo);
>   dev_info(>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: ca8210: remove redundant condition check before debugfs_remove

[Stefan Schmidt]

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 = >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(>up_fifo);
>   dev_info(>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'

[Stefan Schmidt]

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] ieee802154: remove a redundant local variable 'i'

[Stefan Schmidt]

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

[Stefan Schmidt]

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(>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(>up_fifo, _buffer, 4);
>   wake_up_interruptible(>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-next] ieee802154: Use kmemdup instead of duplicating it in ca8210_test_int_driver_write

[Stefan Schmidt]

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(>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(>up_fifo, _buffer, 4);
>   wake_up_interruptible(>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

[Stefan Schmidt]

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 <baijiaju1...@gmail.com>
> ---
>  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] net: ieee802154: atusb: Replace GFP_ATOMIC with GFP_KERNEL in atusb_probe

[Stefan Schmidt]

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

[Stefan Schmidt]

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 <gust...@embeddedor.com>
> ---
>  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(>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(>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), _hw_ops);
>   if (!hw) {
>   dev_crit(>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

[Stefan Schmidt]

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(>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(>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), _hw_ops);
>   if (!hw) {
>   dev_crit(>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

[Stefan Schmidt]

Hello.


On 04/10/2018 11:54 AM, Xue Liu wrote:
> Hallo,
>
> Thanks for the fix. It looks good.
>
> ACK-by: Xue Liu <liuxuenetm...@gmail.com>

Thanks for the ACK Xue. The correct format would be

Acked-by: Xue Liu <liuxuenetm...@gmail.com>

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] ieee802154: mcr20a: Fix memory leak in mcr20a_probe

[Stefan Schmidt]

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'

[Stefan Schmidt]

Hello.


On 03/01/2018 03:40 PM, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> 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 <colin.k...@canonical.com>
> ---
>  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][next] ieee802154: remove unused variable 'val'

[Stefan Schmidt]

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

[Stefan Schmidt]

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 <julia.law...@lip6.fr>
> Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com>
> 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

[Stefan Schmidt]

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

[Stefan Schmidt]

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 <julia.law...@lip6.fr>
> Signed-off-by: Gustavo A. R. Silva <garsi...@embeddedor.com>
> 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: [PATCH] ieee802154: mrf24j40: fix incorrect mask in mrf24j40_stop

[Stefan Schmidt]

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 ?

[Stefan Schmidt]

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: linux-4.14-rc3/drivers/net/ieee802154/atusb.c:827: pointless test ?

[Stefan Schmidt]

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()

[Stefan Schmidt]

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 <alex.ar...@gmail.com>
> Cc: Stefan Schmidt <ste...@osg.samsung.com>
> Cc: "David S. Miller" <da...@davemloft.net>
> Cc: Alexey Kuznetsov <kuz...@ms2.inr.ac.ru>
> Cc: Hideaki YOSHIFUJI <yoshf...@linux-ipv6.org>
> Cc: Pablo Neira Ayuso <pa...@netfilter.org>
> Cc: Jozsef Kadlecsik <kad...@blackhole.kfki.hu>
> Cc: Florian Westphal <f...@strlen.de>
> Cc: linux-w...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: netfilter-de...@vger.kernel.org
> Cc: coret...@netfilter.org
> Cc: Thomas Gleixner <t...@linutronix.de>
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> ---
> 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(>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(>chain_lock);
>  
>   hlist_for_each_entry_safe(fq, n, , list_evictor)
> - f->frag_expire((unsigned long) fq);
> + f->frag_expire(>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(>timer, f->frag_expire, (unsigned long)q);
> + timer_setup(>timer, f->frag_expire, 0);
>   spin_lock_init(>lock);
>   refcount_set(>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 

Re: [PATCH] inet: frags: Convert timers to use timer_setup()

[Stefan Schmidt]

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(>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(>chain_lock);
>  
>   hlist_for_each_entry_safe(fq, n, , list_evictor)
> - f->frag_expire((unsigned long) fq);
> + f->frag_expire(>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(>timer, f->frag_expire, (unsigned long)q);
> + timer_setup(>timer, f->frag_expire, 0);
>   spin_lock_init(>lock);
>   refcount_set(>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 +169,13 @@ static unsigned int nf_hashfn(const struct 
> inet_frag_que

Re: [PATCH][next] ieee802154: atusb: make two structures static, fixes warnings

[Stefan Schmidt]

Hello.

On 09/26/2017 03:18 PM, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
> 
> 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 <colin.k...@canonical.com>
> ---
>  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][next] ieee802154: atusb: make two structures static, fixes warnings

[Stefan Schmidt]

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

[Stefan Schmidt]

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 <a...@arndb.de>
---
  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 <ste...@osg.samsung.com>

regards
Stefan Schmidt

Re: [PATCH] ieee802154: fix gcc-4.9 warnings

[Stefan Schmidt]

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

[Stefan Schmidt]

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 <bhumi...@gmail.com>
---
  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 <ste...@osg.samsung.com>

regards
Stefan Schmidt

Re: [PATCH 3/7] ieee802154: 6lowpan: make header_ops const

[Stefan Schmidt]

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

[Stefan Schmidt]

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 <xiaolou4...@gmail.com>
> 
> 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 <ste...@osg.samsung.com>

to both of them.

regards
Stefan Schmidt

Re: [PATCH] net: ieee802154: fix net_device reference release too early

[Stefan Schmidt]

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

[Stefan Schmidt]

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 <xiaolou4...@gmail.com>

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] net: ieee802154: fix net_device reference release too early

[Stefan Schmidt]

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

[Stefan Schmidt]

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 <colin.k...@canonical.com>

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: [PATCH] Add checks for kmalloc allocation failures

[Stefan Schmidt]

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

[Stefan Schmidt]

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: [ieee802154_unregister_hw] bea5b158ff BUG: scheduling while atomic: swapper/1/0x00000002

[Stefan Schmidt]

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"

[Stefan Schmidt]

Hello.

On 21/12/16 19:30, Chris Healy wrote:



On Dec 21, 2016 5:11 AM, "Stefan Schmidt" <ste...@osg.samsung.com
<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"

[Stefan Schmidt]

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"

[Stefan Schmidt]

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 <cphe...@gmail.com>
Signed-off-by: Andrey Smirnov <andrew.smir...@gmail.com>
---
 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 <ste...@osg.samsung.com>

regards
Stefan Schmidt

Re: [PATCH] at86rf230: Allow slow GPIO pins for "rstn"

[Stefan Schmidt]

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

[Stefan Schmidt]

_bitwise__ itt_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 <ste...@osg.samsung.com>

regards
Stefan Schmidt

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

[Stefan Schmidt]

f 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

[Stefan Schmidt]

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 <okara...@member.fsf.org>


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 1/1] Fixed to BUG_ON to WARN_ON def

[Stefan Schmidt]

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

[Stefan Schmidt]

Hello.

On 05/12/16 16:34, Ozgur Karatas wrote:

Hello all,

I will solve a checkpatch errors.

Signed-off-by: Ozgur Karatas <oz...@member.fsf.org>


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] Fixed to checkpatch.pl errors to vlan_dev.c

[Stefan Schmidt]

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

[Stefan Schmidt]

Hello.

On 03.12.2016 17:55, Antonio Ospite wrote:
> On Sat, 26 Nov 2016 00:30:52 +0100
> Stefan Schmidt <ste...@datenfreihafen.org> wrote:
> 
>> Hello.
>>
> 
> Hi everyone,
> 
>> On 25.11.2016 20:53, Robert Jarzmik wrote:
>>> Stefan Schmidt <ste...@datenfreihafen.org> 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 <a...@arndb.de>
>>>>> ---
>>>>>  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

[Stefan Schmidt]

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

[Stefan Schmidt]

Hello.

On 25.11.2016 20:53, Robert Jarzmik wrote:
> Stefan Schmidt <ste...@datenfreihafen.org> 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 <a...@arndb.de>
>>> ---
>>>  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

[Stefan Schmidt]

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

[Stefan Schmidt]

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 <a...@arndb.de>
> ---
>  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] ARM: pxa: ezx: fix a910 camera data

[Stefan Schmidt]

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

[Stefan Schmidt]

Hello.

On 24/11/16 14:58, Geliang Tang wrote:

Drop duplicate header delay.h from adf7242.c.

Signed-off-by: Geliang Tang <geliangt...@gmail.com>
---
 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 <ste...@osg.samsung.com>

regards
Stefan Schmidt

Re: [PATCH] net: ieee802154: drop duplicate header delay.h

[Stefan Schmidt]

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

[Stefan Schmidt]

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,@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 <bhumi...@gmail.com>
---
 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 <ste...@osg.samsung.com>

regards
Stefan Schmidt

Re: [PATCH] net: ieee802154: constify ieee802154_ops structures

[Stefan Schmidt]

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,@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

[Stefan Schmidt]

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, >sec);

sg_init_one(, skb->data, skb->len);
-   return crypto_blkcipher_encrypt_iv(, , , skb->len);
+   skcipher_request_set_tfm(req, key->tfm0);
+   skcipher_request_set_callback(req, 0, NULL, NULL);
+   skcipher_request_set_crypt(req, , , 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, >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(, data, datalen);
  
-	return crypto_blkcipher_decrypt_iv(, , , datalen);

+   skcipher_request_set_tfm(req, key->tfm0);
+   skcipher_request_set_callback(req, 0, NULL, NULL);
+   skcipher_request_set_crypt(req, , , 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: [PATCH 17/26] mac802154: Use skcipher

[Stefan Schmidt]

Hello.

On 24/01/16 14:18, Herbert Xu wrote:

This patch replaces uses of blkcipher with skcipher.

Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>

---

  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, >sec);

sg_init_one(, skb->data, skb->len);
-   return crypto_blkcipher_encrypt_iv(, , , skb->len);
+   skcipher_request_set_tfm(req, key->tfm0);
+   skcipher_request_set_callback(req, 0, NULL, NULL);
+   skcipher_request_set_crypt(req, , , 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, >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(, data, datalen);
  
-	return crypto_blkcipher_decrypt_iv(, , , datalen);

+   skcipher_request_set_tfm(req, key->tfm0);
+   skcipher_request_set_callback(req, 0, NULL, NULL);
+   skcipher_request_set_crypt(req, , , 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 <ste...@osg.samsung.com>

regards
Stefan Schmidt

Re: ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"

[Stefan Schmidt]

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: ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"

[Stefan Schmidt]

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"

[Stefan Schmidt]

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(>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"

[Stefan Schmidt]

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(>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"

[Stefan Schmidt]

Hello.

On 10/12/15 19:16, Marcel Holtmann wrote:

Hi Stefan,


From: Markus Elfring <elfr...@users.sourceforge.net>
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 <elfr...@users.sourceforge.net>
---
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(>idle_urbs);
 if (!urb)
 break;
-if (urb->context)
-kfree_skb(urb->context);
+kfree_skb(urb->context);
 usb_free_urb(urb);
     }
}

Acked-by: Stefan Schmidt <ste...@osg.samsung.com>


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"

[Stefan Schmidt]

Marcel,

On 17/11/15 17:18, Stefan Schmidt wrote:

Hello.

On 17/11/15 17:17, Stefan Schmidt wrote:

From: Markus Elfring <elfr...@users.sourceforge.net>
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 <elfr...@users.sourceforge.net>
---
 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(>idle_urbs);
 if (!urb)
 break;
-if (urb->context)
-kfree_skb(urb->context);
+kfree_skb(urb->context);
 usb_free_urb(urb);
 }
 }


Acked-by: Stefan Schmidt <ste...@osg.samsung.com>



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"

[Stefan Schmidt]

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(>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"

[Stefan Schmidt]

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(>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"

[Stefan Schmidt]

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(>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"

[Stefan Schmidt]

Hello.

On 17/11/15 17:17, Stefan Schmidt wrote:

From: Markus Elfring <elfr...@users.sourceforge.net>
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 <elfr...@users.sourceforge.net>
---
 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(>idle_urbs);
 if (!urb)
 break;
-if (urb->context)
-kfree_skb(urb->context);
+kfree_skb(urb->context);
 usb_free_urb(urb);
 }
 }


Acked-by: Stefan Schmidt <ste...@osg.samsung.com>

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"

[Stefan Schmidt]

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(>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"

[Stefan Schmidt]

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 <elfr...@users.sourceforge.net>
---
  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(>idle_urbs);
if (!urb)
break;
-   if (urb->context)
-   kfree_skb(urb->context);
+   kfree_skb(urb->context);
usb_free_urb(urb);
    }
  }

Acked-by: Stefan Schmidt <ste...@osg.samsung.com>

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/

Re: [PATCH] ieee802154-atusb: Delete an unnecessary check before the function call "kfree_skb"

[Stefan Schmidt]

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(>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"

[Stefan Schmidt]

Hello.

On 16/11/15 13:57, SF Markus Elfring wrote:

From: Markus Elfring <elfr...@users.sourceforge.net>
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 <elfr...@users.sourceforge.net>
---
  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(>idle_urbs);
if (!urb)
break;
-   if (urb->context)
-   kfree_skb(urb->context);
+   kfree_skb(urb->context);
usb_free_urb(urb);
    }
  }


Acked-by: Stefan Schmidt <ste...@osg.samsung.com>

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

[Stefan Schmidt]

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: [PATCH] mac802154: select CRYPTO when needed

[Stefan Schmidt]

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 a...@arndb.de
---
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 ste...@osg.samsung.com

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

[Stefan Schmidt]

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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG

[Stefan Schmidt]

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.

[Stefan Schmidt]

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