Re: [PATCH] binderfs: Fix binderfs.c selftest compilation warning

2020-04-13 Thread Greg KH 
On Sat, Apr 11, 2020 at 10:51:51PM +0800, Tang Bin wrote:
> Fix missing braces compilation warning in the ARM
> compiler environment:
> drivers/android/binderfs.c: In function 'binderfs_fill_super':
> drivers/android/binderfs.c:650:9: warning: missing braces around 
> initializer [-Wmissing-braces]
>   struct binderfs_device device_info = { 0 };
> drivers/android/binderfs.c:650:9: warning: (near initialization for 
> ‘device_info.name’) [-Wmissing-braces]

What compiler and version is giving this warning?  It's odd we have not
seen this yet...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] binderfs: Fix binderfs.c selftest compilation warning

2020-04-13 Thread Tang Bin 

Hi greg：

On 2020/4/12 15:46, Greg KH wrote:

On Sat, Apr 11, 2020 at 10:51:51PM +0800, Tang Bin wrote:

Fix missing braces compilation warning in the ARM
compiler environment:
 drivers/android/binderfs.c: In function 'binderfs_fill_super':
 drivers/android/binderfs.c:650:9: warning: missing braces around 
initializer [-Wmissing-braces]
   struct binderfs_device device_info = { 0 };
 drivers/android/binderfs.c:650:9: warning: (near initialization for 
‘device_info.name’) [-Wmissing-braces]

What compiler and version is giving this warning?  It's odd we have not
seen this yet...

My environment:

  PC : Ubuntu 16.04

  Hardware : I.MX6ULL

  Tool Chain : arm-linux-gnueabihf-gcc (Linaro GCC 4.9-2017.01) 4.9.4



Thank you for your patience.

Tang Bin




___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: Comedi: Drivers: das08: Fixed some coding style issues

2020-04-13 Thread carlosteniswarrior 
Fixed a coding style issue caused by some declarations that weren't separated.

Signed-off-by: Carlos Guerrero Alvarez 
---
 drivers/staging/comedi/drivers/das08.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/comedi/drivers/das08.c 
b/drivers/staging/comedi/drivers/das08.c
index 65e5f2e6c122..f884f5841788 100644
--- a/drivers/staging/comedi/drivers/das08.c
+++ b/drivers/staging/comedi/drivers/das08.c
@@ -141,7 +141,9 @@ static const struct comedi_lrange *const das08_ai_lranges[] 
= {
 static const int das08_pgh_ai_gainlist[] = {
8, 0, 10, 2, 12, 4, 14, 6, 1, 3, 5, 7
 };
+
 static const int das08_pgl_ai_gainlist[] = { 8, 0, 2, 4, 6, 1, 3, 5, 7 };
+
 static const int das08_pgm_ai_gainlist[] = { 8, 0, 10, 12, 14, 9, 11, 13, 15 };
 
 static const int *const das08_ai_gainlists[] = {
-- 
2.26.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: vt6656: Return error code in vnt_rf_write_embedded function

2020-04-13 Thread Oscar Carter 
Use the error code returned by the vnt_control_out function as the
returned value of the vnt_rf_write_embedded function instead of a
boolean value.

Then, fix all vnt_rf_write_embedded calls removing the "and" operations
and replace with a direct assignment to the ret variable and add a check
condition after every call.

Also replace the boolean values true or false in the vnt_rf_set_txpower
function to 0 or error code EINVAL to follow the coding style guide.

The vnt_rf_set_txpower function is called only in the vnt_rf_setpower
function that already returns error codes. The calls to this function
(vnt_rf_set_txpower) not use the returned values, so they not need to be
fixed.

Signed-off-by: Oscar Carter 
---
 drivers/staging/vt6656/rf.c | 99 -
 1 file changed, 64 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 4f9aba0f21b0..5270ef511af9 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -21,6 +21,7 @@
  *
  */

+#include 
 #include "mac.h"
 #include "rf.h"
 #include "baseband.h"
@@ -531,10 +532,8 @@ int vnt_rf_write_embedded(struct vnt_private *priv, u32 
data)
reg_data[2] = (u8)(data >> 16);
reg_data[3] = (u8)(data >> 24);

-   vnt_control_out(priv, MESSAGE_TYPE_WRITE_IFRF,
-   0, 0, ARRAY_SIZE(reg_data), reg_data);
-
-   return true;
+   return vnt_control_out(priv, MESSAGE_TYPE_WRITE_IFRF, 0, 0,
+  ARRAY_SIZE(reg_data), reg_data);
 }

 /* Set Tx power by rate and channel number */
@@ -603,14 +602,14 @@ static u8 vnt_rf_addpower(struct vnt_private *priv)
 int vnt_rf_set_txpower(struct vnt_private *priv, u8 power, u32 rate)
 {
u32 power_setting = 0;
-   int ret = true;
+   int ret = 0;

power += vnt_rf_addpower(priv);
if (power > VNT_RF_MAX_POWER)
power = VNT_RF_MAX_POWER;

if (priv->power == power)
-   return true;
+   return 0;

priv->power = power;

@@ -618,35 +617,50 @@ int vnt_rf_set_txpower(struct vnt_private *priv, u8 
power, u32 rate)
case RF_AL2230:
power_setting = 0x0404090 | (power << 12);

-   ret &= vnt_rf_write_embedded(priv, power_setting);
+   ret = vnt_rf_write_embedded(priv, power_setting);
+   if (ret)
+   return ret;

if (rate <= RATE_11M)
-   ret &= vnt_rf_write_embedded(priv, 0x0001b400);
+   ret = vnt_rf_write_embedded(priv, 0x0001b400);
else
-   ret &= vnt_rf_write_embedded(priv, 0x0005a400);
+   ret = vnt_rf_write_embedded(priv, 0x0005a400);
+
break;
case RF_AL2230S:
power_setting = 0x0404090 | (power << 12);

-   ret &= vnt_rf_write_embedded(priv, power_setting);
+   ret = vnt_rf_write_embedded(priv, power_setting);
+   if (ret)
+   return ret;

if (rate <= RATE_11M) {
-   ret &= vnt_rf_write_embedded(priv, 0x040c1400);
-   ret &= vnt_rf_write_embedded(priv, 0x00299b00);
+   ret = vnt_rf_write_embedded(priv, 0x040c1400);
+   if (ret)
+   return ret;
+
+   ret = vnt_rf_write_embedded(priv, 0x00299b00);
} else {
-   ret &= vnt_rf_write_embedded(priv, 0x0005a400);
-   ret &= vnt_rf_write_embedded(priv, 0x00099b00);
+   ret = vnt_rf_write_embedded(priv, 0x0005a400);
+   if (ret)
+   return ret;
+
+   ret = vnt_rf_write_embedded(priv, 0x00099b00);
}
+
break;

case RF_AIROHA7230:
if (rate <= RATE_11M)
-   ret &= vnt_rf_write_embedded(priv, 0x111bb900);
+   ret = vnt_rf_write_embedded(priv, 0x111bb900);
else
-   ret &= vnt_rf_write_embedded(priv, 0x221bb900);
+   ret = vnt_rf_write_embedded(priv, 0x221bb900);
+
+   if (ret)
+   return ret;

if (power >= AL7230_PWR_IDX_LEN)
-   return false;
+   return -EINVAL;

/*
 * 0x080F1B00 for 3 wire control TxGain(D10)
@@ -654,61 +668,76 @@ int vnt_rf_set_txpower(struct vnt_private *priv, u8 
power, u32 rate)
 */
power_setting = 0x080c0b00 | (power << 12);

-   ret &= vnt_rf_write_embedded(priv, power_setting);
-
+   ret = vnt_rf_write_embedded(priv, power_setting);
break;

case RF_VT3226:
if (power >= VT3226_PWR_IDX_LEN)
-

Re: [PATCH 1/2] staging: rtl8192u: Refactoring setKey function

2020-04-13 Thread Greg KH 
On Mon, Apr 13, 2020 at 03:01:28AM +, Camylla Goncalves Cantanheide wrote:
> Changes of the local variable value and
> modification in the seletive repetition structure.
> 
> Signed-off-by: Camylla Goncalves Cantanheide 
> ---
>  drivers/staging/rtl8192u/r8192U_core.c | 52 --
>  1 file changed, 24 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 9b8d85a4855d..87c02aee3854 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -4880,7 +4880,7 @@ void EnableHWSecurityConfig8192(struct net_device *dev)
>  void setKey(struct net_device *dev, u8 entryno, u8 keyindex, u16 keytype,
>   u8 *macaddr, u8 defaultkey, u32 *keycontent)
>  {
> - u32 target_command = 0;
> + u32 target_command = CAM_CONTENT_COUNT * entryno |  BIT(31) | BIT(16);
>   u32 target_content = 0;
>   u16 us_config = 0;
>   u8 i;
> @@ -4890,39 +4890,35 @@ void setKey(struct net_device *dev, u8 entryno, u8 
> keyindex, u16 keytype,
>  
>   RT_TRACE(COMP_SEC,
>">to %s, dev:%p, EntryNo:%d, KeyIndex:%d, KeyType:%d, 
> MacAddr%pM\n",
> -  __func__, dev, entryno, keyindex, keytype, macaddr);
> +  __func__, dev, entryno, keyindex, keytype, macaddr);
>  
>   if (defaultkey)
>   us_config |= BIT(15) | (keytype << 2);
>   else
>   us_config |= BIT(15) | (keytype << 2) | keyindex;
>  
> - for (i = 0; i < CAM_CONTENT_COUNT; i++) {
> - target_command  = i + CAM_CONTENT_COUNT * entryno;
> - target_command |= BIT(31) | BIT(16);
> -
> - if (i == 0) { /* MAC|Config */
> - target_content = (u32)(*(macaddr + 0)) << 16 |
> - (u32)(*(macaddr + 1)) << 24 |
> - (u32)us_config;
> -
> - write_nic_dword(dev, WCAMI, target_content);
> - write_nic_dword(dev, RWCAM, target_command);
> - } else if (i == 1) { /* MAC */
> - target_content = (u32)(*(macaddr + 2))   |
> - (u32)(*(macaddr + 3)) <<  8 |
> - (u32)(*(macaddr + 4)) << 16 |
> - (u32)(*(macaddr + 5)) << 24;
> - write_nic_dword(dev, WCAMI, target_content);
> - write_nic_dword(dev, RWCAM, target_command);
> - } else {
> - /* Key Material */
> - if (keycontent) {
> - write_nic_dword(dev, WCAMI,
> - *(keycontent + i - 2));
> - write_nic_dword(dev, RWCAM, target_command);
> - }
> - }
> + target_content = macaddr[0] << 16 |
> +  macaddr[0] << 24 |
> + (u32)us_config;
> +
> + write_nic_dword(dev, WCAMI, target_content);
> + write_nic_dword(dev, RWCAM, target_command++);
> +
> + /* MAC */
> + target_content = macaddr[2]   |
> +  macaddr[3] <<  8 |
> +  macaddr[4] << 16 |
> +  macaddr[5] << 24;
> + write_nic_dword(dev, WCAMI, target_content);
> + write_nic_dword(dev, RWCAM, target_command++);
> +
> + /* Key Material */
> + if (!keycontent)
> + return;
> +
> + for (i = 2; i < CAM_CONTENT_COUNT; i++) {
> + write_nic_dword(dev, WCAMI, *keycontent++);
> + write_nic_dword(dev, RWCAM, target_command++);
>   }
>  }
>  
> -- 
> 2.20.1
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This will make it easier to review the
  patches to ensure that they are correct, and to help alleviate any
  merge issues that larger patches can cause.

- You did not specify a description of why the patch is needed

Re: [PATCH] Staging: Comedi: Drivers: das08: Fixed some coding style issues

2020-04-13 Thread Greg KH 
On Mon, Apr 13, 2020 at 10:05:55AM +0200, carlosteniswarr...@gmail.com wrote:
> Fixed a coding style issue caused by some declarations that weren't separated.
> 
> Signed-off-by: Carlos Guerrero Alvarez 

Your From: line in your email client does not match with this :(

> ---
>  drivers/staging/comedi/drivers/das08.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/comedi/drivers/das08.c 
> b/drivers/staging/comedi/drivers/das08.c
> index 65e5f2e6c122..f884f5841788 100644
> --- a/drivers/staging/comedi/drivers/das08.c
> +++ b/drivers/staging/comedi/drivers/das08.c
> @@ -141,7 +141,9 @@ static const struct comedi_lrange *const 
> das08_ai_lranges[] = {
>  static const int das08_pgh_ai_gainlist[] = {
>   8, 0, 10, 2, 12, 4, 14, 6, 1, 3, 5, 7
>  };
> +
>  static const int das08_pgl_ai_gainlist[] = { 8, 0, 2, 4, 6, 1, 3, 5, 7 };
> +
>  static const int das08_pgm_ai_gainlist[] = { 8, 0, 10, 12, 14, 9, 11, 13, 15 
> };

What is wrong with the original code?  It makes more sense, don't you
think?

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] staging: rtl8192u: Renames variables in setKey function

2020-04-13 Thread Greg KH 
On Mon, Apr 13, 2020 at 03:01:29AM +, Camylla Goncalves Cantanheide wrote:
> Renames the local variables of the setKey
> function, making them explicit.

Why do this?

> 
> Signed-off-by: Camylla Goncalves Cantanheide 
> ---
>  drivers/staging/rtl8192u/r8192U_core.c | 48 +-
>  1 file changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 87c02aee3854..cc02c3b1eb91 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -4877,48 +4877,48 @@ void EnableHWSecurityConfig8192(struct net_device 
> *dev)
>   write_nic_byte(dev, SECR,  SECR_value);
>  }
>  
> -void setKey(struct net_device *dev, u8 entryno, u8 keyindex, u16 keytype,
> - u8 *macaddr, u8 defaultkey, u32 *keycontent)
> +void setKey(struct net_device *dev, u8 entry_no, u8 key_idx, u16 key_type,
> + u8 *mac_addr, u8 default_key, u32 *key_content)

What was wrong with the original names?  Why add a '_' character for no
good reason?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: comedi: drivers: jr3_pci: fixed two warnings

2020-04-13 Thread Greg KH 
On Sun, Apr 12, 2020 at 04:25:08PM +0200, carlosteniswarr...@gmail.com wrote:
> Fixed two checkpatch warnings.
> 
> Signed-off-by: Carlos Guerrero Alvarez 
> ---
>  drivers/staging/comedi/drivers/jr3_pci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/comedi/drivers/jr3_pci.c 
> b/drivers/staging/comedi/drivers/jr3_pci.c
> index c3c88e6d298f..6bc87d3c6c3b 100644
> --- a/drivers/staging/comedi/drivers/jr3_pci.c
> +++ b/drivers/staging/comedi/drivers/jr3_pci.c
> @@ -91,8 +91,8 @@ struct jr3_pci_dev_private {
>  };
>  
>  union jr3_pci_single_range {
> - struct comedi_lrange l;
> - char _reserved[offsetof(struct comedi_lrange, range[1])];
> + const comedi_lrange l;
> + char _reserved[offsetof(const comedi_lrange, range[1])];
>  };

Please work on your knowledge of C first, before modifying Linux kernel
code.  Mistakes like this show you need a bit more work there first.

Good luck!

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/2] staging: vt6656: Refactor the assignment of the phy->signal variable

2020-04-13 Thread Greg Kroah-Hartman 
On Sat, Apr 11, 2020 at 02:26:09PM +0200, Oscar Carter wrote:
> Create a constant array with the values of the "phy->signal" for every
> rate. Remove all "phy->signal" assignments inside the switch statement
> and replace these with a single reading from the new vnt_phy_signal
> array.
> 
> The constant array can be of one dimension because the OR mask with
> BIT(3) or BIT(4) allow obtain a second value according to the rate,
> the preamble_type and the pkt_type.
> 
> Signed-off-by: Oscar Carter 
> ---
>  drivers/staging/vt6656/baseband.c | 105 --
>  1 file changed, 26 insertions(+), 79 deletions(-)

This series did not apply to my tree, please rebase and resend.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 1/2] staging: vt6656: Use define instead of magic number for tx_rate

2020-04-13 Thread Greg Kroah-Hartman 
On Tue, Apr 07, 2020 at 06:39:14PM +0200, Oscar Carter wrote:
> Use the define RATE_11M present in the file "device.h" instead of the
> magic number 3. So the code is more clear.
> 
> Reviewed-by: Dan Carpenter 
> Signed-off-by: Oscar Carter 
> ---
>  drivers/staging/vt6656/baseband.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

This patch did not apply to my tree, please rebase and resend.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: vt6656: Use BIT() macro instead of bit shift operator

2020-04-13 Thread Greg Kroah-Hartman 
On Sun, Apr 12, 2020 at 11:33:11AM +0200, Oscar Carter wrote:
> Use the BIT() macro instead of the bit left shift operator. So the code
> is more clear.
> 
> It's safe to remove the casting to u16 type because the value obtained
> never exceeds 16 bits. So the casting is unnecessary.
> 
> Signed-off-by: Oscar Carter 
> ---
>  drivers/staging/vt6656/card.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

This too did not apply :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: vt6656: Return error code in vnt_rf_write_embedded function

2020-04-13 Thread Greg Kroah-Hartman 
On Mon, Apr 13, 2020 at 12:19:31PM +0200, Oscar Carter wrote:
> Use the error code returned by the vnt_control_out function as the
> returned value of the vnt_rf_write_embedded function instead of a
> boolean value.
> 
> Then, fix all vnt_rf_write_embedded calls removing the "and" operations
> and replace with a direct assignment to the ret variable and add a check
> condition after every call.
> 
> Also replace the boolean values true or false in the vnt_rf_set_txpower
> function to 0 or error code EINVAL to follow the coding style guide.
> 
> The vnt_rf_set_txpower function is called only in the vnt_rf_setpower
> function that already returns error codes. The calls to this function
> (vnt_rf_set_txpower) not use the returned values, so they not need to be
> fixed.
> 
> Signed-off-by: Oscar Carter 
> ---
>  drivers/staging/vt6656/rf.c | 99 -
>  1 file changed, 64 insertions(+), 35 deletions(-)

This too did not apply :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC] staging: vt6656: Add formula to the vnt_rf_addpower function

2020-04-13 Thread Oscar Carter 
Use a formula to calculate the return value of the vnt_rf_addpower
function instead of the "if" statement with literal values for every
case.

Signed-off-by: Oscar Carter 
---
What is the better approach for this function ? Leave it as is or use
a formula although it is less clear.

I prefer the formula as it is a more compact function.
What do you think ? Feedback wellcome.

Thanks,
Oscar Carter

 drivers/staging/vt6656/rf.c | 20 +++-
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 4f9aba0f21b0..3b200d7290a5 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -575,28 +575,14 @@ int vnt_rf_setpower(struct vnt_private *priv, u32 rate, 
u32 channel)

 static u8 vnt_rf_addpower(struct vnt_private *priv)
 {
+   s32 base;
s32 rssi = -priv->current_rssi;

if (!rssi)
return 7;

-   if (priv->rf_type == RF_VT3226D0) {
-   if (rssi < -70)
-   return 9;
-   else if (rssi < -65)
-   return 7;
-   else if (rssi < -60)
-   return 5;
-   } else {
-   if (rssi < -80)
-   return 9;
-   else if (rssi < -75)
-   return 7;
-   else if (rssi < -70)
-   return 5;
-   }
-
-   return 0;
+   base = (priv->rf_type == RF_VT3226D0) ? -60 : -70;
+   return (rssi < base--) ? ((rssi - base) / -5) * 2 + 5 : 0;
 }

 /* Set Tx power by power level and rate */
--
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 1/2] staging: vt6656: Use define instead of magic number for tx_rate

2020-04-13 Thread Oscar Carter 
On Mon, Apr 13, 2020 at 02:56:33PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 07, 2020 at 06:39:14PM +0200, Oscar Carter wrote:
> > Use the define RATE_11M present in the file "device.h" instead of the
> > magic number 3. So the code is more clear.
> >
> > Reviewed-by: Dan Carpenter 
> > Signed-off-by: Oscar Carter 
> > ---
> >  drivers/staging/vt6656/baseband.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
>
> This patch did not apply to my tree, please rebase and resend.
>
I need to rebase only this patch for this serie so, it's necessary to send all
the serie or only this patch?

If it's only this patch I need to indicate v4 in the subject or a v2 due it's
related only with this patch?

> thanks,
>
> greg k-h

thanks,

oscar carter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/2] staging: vt6656: Refactor the assignment of the phy->signal variable

2020-04-13 Thread Oscar Carter 
On Mon, Apr 13, 2020 at 02:56:16PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 11, 2020 at 02:26:09PM +0200, Oscar Carter wrote:
> > Create a constant array with the values of the "phy->signal" for every
> > rate. Remove all "phy->signal" assignments inside the switch statement
> > and replace these with a single reading from the new vnt_phy_signal
> > array.
> >
> > The constant array can be of one dimension because the OR mask with
> > BIT(3) or BIT(4) allow obtain a second value according to the rate,
> > the preamble_type and the pkt_type.
> >
> > Signed-off-by: Oscar Carter 
> > ---
> >  drivers/staging/vt6656/baseband.c | 105 --
> >  1 file changed, 26 insertions(+), 79 deletions(-)
>
> This series did not apply to my tree, please rebase and resend.

Rebase the patchs is a normal process in the development or am I doing something
wrong ?

>
> thanks,
>
> greg k-h

thanks,

oscar carter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 1/2] staging: vt6656: Use define instead of magic number for tx_rate

2020-04-13 Thread Greg Kroah-Hartman 
On Mon, Apr 13, 2020 at 04:13:15PM +0200, Oscar Carter wrote:
> On Mon, Apr 13, 2020 at 02:56:33PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 07, 2020 at 06:39:14PM +0200, Oscar Carter wrote:
> > > Use the define RATE_11M present in the file "device.h" instead of the
> > > magic number 3. So the code is more clear.
> > >
> > > Reviewed-by: Dan Carpenter 
> > > Signed-off-by: Oscar Carter 
> > > ---
> > >  drivers/staging/vt6656/baseband.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > This patch did not apply to my tree, please rebase and resend.
> >
> I need to rebase only this patch for this serie so, it's necessary to send all
> the serie or only this patch?

If I applied the other one, just this patch.

> If it's only this patch I need to indicate v4 in the subject or a v2 due it's
> related only with this patch?

As so many of your patches were rejected because of this, rebase them
all, and resend them all as a single patch series, so that I know what
order to apply them in and have a chance to get it right :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/2] staging: vt6656: Refactor the assignment of the phy->signal variable

2020-04-13 Thread Greg Kroah-Hartman 
On Mon, Apr 13, 2020 at 04:25:17PM +0200, Oscar Carter wrote:
> On Mon, Apr 13, 2020 at 02:56:16PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Apr 11, 2020 at 02:26:09PM +0200, Oscar Carter wrote:
> > > Create a constant array with the values of the "phy->signal" for every
> > > rate. Remove all "phy->signal" assignments inside the switch statement
> > > and replace these with a single reading from the new vnt_phy_signal
> > > array.
> > >
> > > The constant array can be of one dimension because the OR mask with
> > > BIT(3) or BIT(4) allow obtain a second value according to the rate,
> > > the preamble_type and the pkt_type.
> > >
> > > Signed-off-by: Oscar Carter 
> > > ---
> > >  drivers/staging/vt6656/baseband.c | 105 --
> > >  1 file changed, 26 insertions(+), 79 deletions(-)
> >
> > This series did not apply to my tree, please rebase and resend.
> 
> Rebase the patchs is a normal process in the development or am I doing 
> something
> wrong ?

It's normal when multiple people are working on the same area with lots
of patches flying around.  Not a problem, it doesn't bother me at all :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 1/2] staging: vt6656: Use define instead of magic number for tx_rate

2020-04-13 Thread Oscar Carter 
On Mon, Apr 13, 2020 at 04:29:07PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 13, 2020 at 04:13:15PM +0200, Oscar Carter wrote:
> > On Mon, Apr 13, 2020 at 02:56:33PM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Apr 07, 2020 at 06:39:14PM +0200, Oscar Carter wrote:
> > > > Use the define RATE_11M present in the file "device.h" instead of the
> > > > magic number 3. So the code is more clear.
> > > >
> > > > Reviewed-by: Dan Carpenter 
> > > > Signed-off-by: Oscar Carter 
> > > > ---
> > > >  drivers/staging/vt6656/baseband.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > This patch did not apply to my tree, please rebase and resend.
> > >
> > I need to rebase only this patch for this serie so, it's necessary to send 
> > all
> > the serie or only this patch?
>
> If I applied the other one, just this patch.
>
> > If it's only this patch I need to indicate v4 in the subject or a v2 due 
> > it's
> > related only with this patch?
>
> As so many of your patches were rejected because of this, rebase them
> all, and resend them all as a single patch series, so that I know what
> order to apply them in and have a chance to get it right :)

Ok, I will create a patch series with all the rejected patches rebased.
>
> thanks,
>
> greg k-h

thanks,

oscar carter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/2] staging: vt6656: Refactor the assignment of the phy->signal variable

2020-04-13 Thread Oscar Carter 
On Mon, Apr 13, 2020 at 04:32:58PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 13, 2020 at 04:25:17PM +0200, Oscar Carter wrote:
> > On Mon, Apr 13, 2020 at 02:56:16PM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Apr 11, 2020 at 02:26:09PM +0200, Oscar Carter wrote:
> > > > Create a constant array with the values of the "phy->signal" for every
> > > > rate. Remove all "phy->signal" assignments inside the switch statement
> > > > and replace these with a single reading from the new vnt_phy_signal
> > > > array.
> > > >
> > > > The constant array can be of one dimension because the OR mask with
> > > > BIT(3) or BIT(4) allow obtain a second value according to the rate,
> > > > the preamble_type and the pkt_type.
> > > >
> > > > Signed-off-by: Oscar Carter 
> > > > ---
> > > >  drivers/staging/vt6656/baseband.c | 105 --
> > > >  1 file changed, 26 insertions(+), 79 deletions(-)
> > >
> > > This series did not apply to my tree, please rebase and resend.
> >
> > Rebase the patchs is a normal process in the development or am I doing 
> > something
> > wrong ?
>
> It's normal when multiple people are working on the same area with lots
> of patches flying around.  Not a problem, it doesn't bother me at all :)

Thanks for the clarification about this theme.

>
> thanks,
>
> greg k-h

thanks,

oscar carter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[staging:staging-next] BUILD SUCCESS 73a6e90041ce80d5683f62bee0eaf7226ce73392

2020-04-13 Thread kbuild test robot 
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
 staging-next
branch HEAD: 73a6e90041ce80d5683f62bee0eaf7226ce73392  staging: rtl8723bs: hal: 
Correct misspelled symbolic name

elapsed time: 508m

configs tested: 166
configs skipped: 0

The following configs have been built successfully.
More configs may be tested in the coming days.

arm  allmodconfig
arm   allnoconfig
arm  allyesconfig
arm64allmodconfig
arm64 allnoconfig
arm64allyesconfig
arm at91_dt_defconfig
arm   efm32_defconfig
arm  exynos_defconfig
armmulti_v5_defconfig
armmulti_v7_defconfig
armshmobile_defconfig
arm   sunxi_defconfig
arm64   defconfig
sparcallyesconfig
openriscor1ksim_defconfig
powerpc   ppc64_defconfig
h8300h8300h-sim_defconfig
sparc64  allmodconfig
pariscgeneric-32bit_defconfig
cskydefconfig
pariscgeneric-64bit_defconfig
ia64defconfig
powerpc defconfig
pariscallnoconfig
shallnoconfig
i386  allnoconfig
i386 allyesconfig
i386 alldefconfig
i386defconfig
i386  debian-10.3
ia64 alldefconfig
ia64 allmodconfig
ia64  allnoconfig
ia64 allyesconfig
c6x  allyesconfig
c6xevmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openrisc simple_smp_defconfig
xtensa   common_defconfig
xtensa  iss_defconfig
nds32   defconfig
nds32 allnoconfig
alpha   defconfig
h8300   h8s-sim_defconfig
h8300 edosk2674_defconfig
m68k   m5475evb_defconfig
m68k allmodconfig
m68k   sun3_defconfig
m68k  multi_defconfig
arc  allyesconfig
arc defconfig
microblaze  mmu_defconfig
microblazenommu_defconfig
powerpc   allnoconfig
powerpc  rhel-kconfig
mips  fuloong2e_defconfig
mips  malta_kvm_defconfig
mips allyesconfig
mips 64r6el_defconfig
mips  allnoconfig
mips   32r2_defconfig
mips allmodconfig
parisc   allyesconfig
x86_64   randconfig-a001-20200413
x86_64   randconfig-a002-20200413
x86_64   randconfig-a003-20200413
i386 randconfig-a001-20200413
i386 randconfig-a002-20200413
i386 randconfig-a003-20200413
mips randconfig-a001-20200413
nds32randconfig-a001-20200413
m68k randconfig-a001-20200413
parisc   randconfig-a001-20200413
alpharandconfig-a001-20200413
riscvrandconfig-a001-20200413
c6x  randconfig-a001-20200413
h8300randconfig-a001-20200413
microblaze   randconfig-a001-20200413
nios2randconfig-a001-20200413
sparc64  randconfig-a001-20200413
s390 randconfig-a001-20200413
xtensa   randconfig-a001-20200413
sh   randconfig-a001-20200413
openrisc randconfig-a001-20200413
csky randconfig-a001-20200413
x86_64   randconfig-b002-20200413
i386 randconfig-b001-20200413
x86_64   randconfig-b001-20200413
x86_64   randconfig-b003-20200413
i386 randconfig-b003-20200413
i386 randconfig-b002-20200413
x86_64   randconfig-c003-20200413
i386 randconfig-c003-20200413
i386 randconfig-c002-20200413
x86_64   randconfig-c002-20200413
i386 randconfig-c001-20200413
x86_64   randconfig-c001-20200413
x86_64   randconfig-d001-20200413
x86_64

Re: [PATCH 1/2] staging: rtl8192u: Refactoring setKey function

2020-04-13 Thread Joe Perches 
On Mon, 2020-04-13 at 14:50 +0200, Greg KH wrote:
> On Mon, Apr 13, 2020 at 03:01:28AM +, Camylla Goncalves Cantanheide wrote:
> > Changes of the local variable value and
> > modification in the seletive repetition structure.
[]
> > diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> > b/drivers/staging/rtl8192u/r8192U_core.c
[]
> You are receiving this message because of the following common error(s)
> as indicated below:
[]
> greg k-h's patch email bot

Hey Greg.

I think I wrote most (all?) of this as a suggestion
to Camylla.

It's a refactoring patch which would be difficult
or impossible to separate into multiple patches.


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/3] staging: mt7621-pci: add clarification comment in 'mt7621_pcie_init_virtual_bridges'

2020-04-13 Thread Sergio Paracuellos 
Add a comment explaining a bit what is going on in this function.
It would be helfulp for other people for a better understanding
of the code.

Suggested-by: NeilBrown 
Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 6a9f4b6cdd93..eede8d9268ac 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -622,6 +622,11 @@ static int mt7621_pcie_init_virtual_bridges(struct 
mt7621_pcie *pcie)
if (pcie_link_status == 0)
return -1;
 
+   /*
+* Assign device numbers from zero to the enabled ports,
+* then assigning remaining device numbers to any disabled
+* ports.
+*/
n = 0;
for (i = 0; i < PCIE_P2P_CNT; i++)
if (pcie_link_status & BIT(i))
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/3] staging: mt7621-pci: initialize 'n' variable when it is declared

2020-04-13 Thread Sergio Paracuellos 
Variable 'n' in 'mt7621_pcie_init_virtual_bridges' function
can be directly initialized when it is declared instead of
doing it before using it first.

Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index eede8d9268ac..f961b353c22e 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -605,7 +605,7 @@ static void mt7621_pcie_enable_ports(struct mt7621_pcie 
*pcie)
 static int mt7621_pcie_init_virtual_bridges(struct mt7621_pcie *pcie)
 {
u32 pcie_link_status = 0;
-   u32 n;
+   u32 n = 0;
int i = 0;
u32 p2p_br_devnum[PCIE_P2P_CNT];
int irqs[PCIE_P2P_CNT];
@@ -627,7 +627,6 @@ static int mt7621_pcie_init_virtual_bridges(struct 
mt7621_pcie *pcie)
 * then assigning remaining device numbers to any disabled
 * ports.
 */
-   n = 0;
for (i = 0; i < PCIE_P2P_CNT; i++)
if (pcie_link_status & BIT(i))
p2p_br_devnum[i] = n++;
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] staging: mt7621-pci: rename 'PCIE_P2P_MAX' into 'PCIE_P2P_CNT'

2020-04-13 Thread Sergio Paracuellos 
Definition 'PCIE_P2P_MAX' is '3'. The value here is not a MAXimum.
It is a count or a number. It is how many masks there are.
The masks are numbered 0, 1, 2 so the maximum is 2. Hence rename
variable into 'PCIE_P2P_CNT' which is a more accurate name.

Suggested-by: NeilBrown 
Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 36207243a71b..6a9f4b6cdd93 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -55,7 +55,7 @@
 #define RALINK_PCI_IOBASE  0x002C
 
 /* PCICFG virtual bridges */
-#define PCIE_P2P_MAX   3
+#define PCIE_P2P_CNT   3
 #define PCIE_P2P_BR_DEVNUM_SHIFT(p)(16 + (p) * 4)
 #define PCIE_P2P_BR_DEVNUM0_SHIFT  PCIE_P2P_BR_DEVNUM_SHIFT(0)
 #define PCIE_P2P_BR_DEVNUM1_SHIFT  PCIE_P2P_BR_DEVNUM_SHIFT(1)
@@ -138,7 +138,7 @@ struct mt7621_pcie {
} offset;
unsigned long io_map_base;
struct list_head ports;
-   int irq_map[PCIE_P2P_MAX];
+   int irq_map[PCIE_P2P_CNT];
bool resets_inverted;
 };
 
@@ -607,8 +607,8 @@ static int mt7621_pcie_init_virtual_bridges(struct 
mt7621_pcie *pcie)
u32 pcie_link_status = 0;
u32 n;
int i = 0;
-   u32 p2p_br_devnum[PCIE_P2P_MAX];
-   int irqs[PCIE_P2P_MAX];
+   u32 p2p_br_devnum[PCIE_P2P_CNT];
+   int irqs[PCIE_P2P_CNT];
struct mt7621_pcie_port *port;
 
list_for_each_entry(port, &pcie->ports, list) {
@@ -623,11 +623,11 @@ static int mt7621_pcie_init_virtual_bridges(struct 
mt7621_pcie *pcie)
return -1;
 
n = 0;
-   for (i = 0; i < PCIE_P2P_MAX; i++)
+   for (i = 0; i < PCIE_P2P_CNT; i++)
if (pcie_link_status & BIT(i))
p2p_br_devnum[i] = n++;
 
-   for (i = 0; i < PCIE_P2P_MAX; i++)
+   for (i = 0; i < PCIE_P2P_CNT; i++)
if ((pcie_link_status & BIT(i)) == 0)
p2p_br_devnum[i] = n++;
 
@@ -639,11 +639,11 @@ static int mt7621_pcie_init_virtual_bridges(struct 
mt7621_pcie *pcie)
 
/* Assign IRQs */
n = 0;
-   for (i = 0; i < PCIE_P2P_MAX; i++)
+   for (i = 0; i < PCIE_P2P_CNT; i++)
if (pcie_link_status & BIT(i))
pcie->irq_map[n++] = irqs[i];
 
-   for (i = n; i < PCIE_P2P_MAX; i++)
+   for (i = n; i < PCIE_P2P_CNT; i++)
pcie->irq_map[i] = -1;
 
return 0;
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[driver-core:debugfs_remove_return_value] BUILD SUCCESS d8691ced73b1fb17a5308bd4e5c4fc73e9ed7e95

2020-04-13 Thread kbuild test robot 
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git  
debugfs_remove_return_value
branch HEAD: d8691ced73b1fb17a5308bd4e5c4fc73e9ed7e95  debugfs: remove return 
value of debugfs_create_u32()

elapsed time: 484m

configs tested: 161
configs skipped: 0

The following configs have been built successfully.
More configs may be tested in the coming days.

arm64 allnoconfig
arm   allnoconfig
arm at91_dt_defconfig
arm   efm32_defconfig
arm  exynos_defconfig
armmulti_v5_defconfig
armmulti_v7_defconfig
armshmobile_defconfig
arm   sunxi_defconfig
arm64   defconfig
sparcallyesconfig
h8300h8300h-sim_defconfig
sparc64  allmodconfig
pariscgeneric-32bit_defconfig
cskydefconfig
ia64defconfig
powerpc defconfig
pariscallnoconfig
shallnoconfig
i386  allnoconfig
i386 alldefconfig
i386 allyesconfig
i386  debian-10.3
i386defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64  allnoconfig
ia64 allyesconfig
arm  allmodconfig
nios2 3c120_defconfig
nios2 10m50_defconfig
c6xevmc6678_defconfig
xtensa  iss_defconfig
c6x  allyesconfig
xtensa   common_defconfig
openrisc simple_smp_defconfig
openriscor1ksim_defconfig
nds32   defconfig
nds32 allnoconfig
alpha   defconfig
h8300   h8s-sim_defconfig
h8300 edosk2674_defconfig
m68k   m5475evb_defconfig
m68k allmodconfig
m68k   sun3_defconfig
m68k  multi_defconfig
arc defconfig
arc  allyesconfig
powerpc  rhel-kconfig
microblaze  mmu_defconfig
microblazenommu_defconfig
powerpc   allnoconfig
powerpc   ppc64_defconfig
mips  fuloong2e_defconfig
mips  malta_kvm_defconfig
mips allyesconfig
mips 64r6el_defconfig
mips  allnoconfig
mips   32r2_defconfig
mips allmodconfig
pariscgeneric-64bit_defconfig
parisc   allyesconfig
i386 randconfig-a002-20200413
x86_64   randconfig-a002-20200413
i386 randconfig-a003-20200413
i386 randconfig-a001-20200413
mips randconfig-a001-20200413
nds32randconfig-a001-20200413
riscvrandconfig-a001-20200413
m68k randconfig-a001-20200413
parisc   randconfig-a001-20200413
alpharandconfig-a001-20200413
c6x  randconfig-a001-20200413
h8300randconfig-a001-20200413
microblaze   randconfig-a001-20200413
nios2randconfig-a001-20200413
sparc64  randconfig-a001-20200413
s390 randconfig-a001-20200413
xtensa   randconfig-a001-20200413
sh   randconfig-a001-20200413
openrisc randconfig-a001-20200413
csky randconfig-a001-20200413
x86_64   randconfig-b002-20200413
i386 randconfig-b001-20200413
x86_64   randconfig-b001-20200413
x86_64   randconfig-b003-20200413
i386 randconfig-b003-20200413
i386 randconfig-b002-20200413
x86_64   randconfig-c003-20200413
i386 randconfig-c003-20200413
i386 randconfig-c002-20200413
x86_64   randconfig-c002-20200413
i386 randconfig-c001-20200413
x86_64   randconfig-c001-20200413
i386 randconfig-d002-20200413
x86_64   randconfig-d003-20200413
x86_64   randconfig-d001-20200413
i386 randconfig-d003-20200413
i386 randconfig-d001-20200413
x86_64   randconfig-d002-20200413
x86_64

[PATCH] staging: sm750fb: Make function arguments alignment match open parenthesis

2020-04-13 Thread R Veera Kumar 
Make function arguments alignment match open parenthesis.
Found using checkpatch.pl.

Signed-off-by: R Veera Kumar 
---
 drivers/staging/sm750fb/sm750.h| 23 +--
 drivers/staging/sm750fb/sm750_hw.c |  2 +-
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index ce90adcb449d..55fe5a28a174 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -59,16 +59,19 @@ struct lynx_accel {
 
int (*de_wait)(void);/* see if hardware ready to work */
 
-   int (*de_fillrect)(struct lynx_accel *, u32, u32, u32, u32,
-   u32, u32, u32, u32, u32);
-
-   int (*de_copyarea)(struct lynx_accel *, u32, u32, u32, u32,
-   u32, u32, u32, u32,
-   u32, u32, u32, u32);
-
-   int (*de_imageblit)(struct lynx_accel *, const char *, u32, u32, u32, 
u32,
-  u32, u32, u32, 
u32,
-  u32, u32, u32, 
u32);
+   int (*de_fillrect)(struct lynx_accel *,
+  u32, u32, u32, u32,
+  u32, u32, u32, u32, u32);
+
+   int (*de_copyarea)(struct lynx_accel *,
+  u32, u32, u32, u32,
+  u32, u32, u32, u32,
+  u32, u32, u32, u32);
+
+   int (*de_imageblit)(struct lynx_accel *, const char *,
+   u32, u32, u32, u32,
+   u32, u32, u32, u32,
+   u32, u32, u32, u32);
 
 };
 
diff --git a/drivers/staging/sm750fb/sm750_hw.c 
b/drivers/staging/sm750fb/sm750_hw.c
index b8d60701f898..7136d751cff5 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -51,7 +51,7 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev 
*pdev)
 
/* now map mmio and vidmem */
sm750_dev->pvReg = ioremap(sm750_dev->vidreg_start,
-  sm750_dev->vidreg_size);
+  sm750_dev->vidreg_size);
if (!sm750_dev->pvReg) {
pr_err("mmio failed\n");
ret = -EFAULT;
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: vc04_services: bcm2835-audio: Make function arguments alignment match open parenthesis

2020-04-13 Thread R Veera Kumar 
Make function arguments alignment match open parenthesis.
Found using checkpatch.pl.

Signed-off-by: R Veera Kumar 
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
index 33485184a98a..f783b632141b 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
@@ -233,7 +233,7 @@ static int snd_bcm2835_pcm_prepare(struct snd_pcm_substream 
*substream)
 }
 
 static void snd_bcm2835_pcm_transfer(struct snd_pcm_substream *substream,
-   struct snd_pcm_indirect *rec, size_t bytes)
+struct snd_pcm_indirect *rec, size_t bytes)
 {
struct snd_pcm_runtime *runtime = substream->runtime;
struct bcm2835_alsa_stream *alsa_stream = runtime->private_data;
@@ -346,7 +346,7 @@ int snd_bcm2835_new_pcm(struct bcm2835_chip *chip, const 
char *name,
&snd_bcm2835_playback_ops);
 
snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_DEV,
-   chip->card->dev, 128 * 1024, 128 * 1024);
+  chip->card->dev, 128 * 1024, 128 * 1024);
 
if (spdif)
chip->pcm_spdif = pcm;
-- 
2.20.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/3] staging: rtl8188eu: checkpatch cleanups in hal/fw.c

2020-04-13 Thread Michael Straube 
This series clears the last remaining checkpatch issues in the file
hal/fw.c.

Michael Straube (3):
  staging: rtl8188eu: rename define to upper case
  staging: rtl8188eu: cleanup long line in fw.c
  staging: rtl8188eu: make const char array static

 drivers/staging/rtl8188eu/hal/fw.c| 7 ---
 drivers/staging/rtl8188eu/include/rtl8188e_spec.h | 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

-- 
2.26.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/3] staging: rtl8188eu: cleanup long line in fw.c

2020-04-13 Thread Michael Straube 
Add line break to avoid line length over 80 characters.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/hal/fw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/fw.c 
b/drivers/staging/rtl8188eu/hal/fw.c
index dbf7883f9ed7..432e6bea5ea1 100644
--- a/drivers/staging/rtl8188eu/hal/fw.c
+++ b/drivers/staging/rtl8188eu/hal/fw.c
@@ -192,7 +192,8 @@ int rtl88eu_download_fw(struct adapter *adapt)
rtl88e_firmware_selfreset(adapt);
}
_rtl88e_enable_fw_download(adapt, true);
-   usb_write8(adapt, REG_MCUFWDL, usb_read8(adapt, REG_MCUFWDL) | 
FWDL_CHKSUM_RPT);
+   usb_write8(adapt, REG_MCUFWDL,
+  usb_read8(adapt, REG_MCUFWDL) | FWDL_CHKSUM_RPT);
_rtl88e_write_fw(adapt, download_data, download_size);
_rtl88e_enable_fw_download(adapt, false);
 
-- 
2.26.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/3] staging: rtl8188eu: make const char array static

2020-04-13 Thread Michael Straube 
Make const char array 'fw_name' static. Clears a checkpatch warning
and reduces object file size by 17 bytes (gcc 9.3.1 x86_64).

WARNING: const array should probably be static const

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/hal/fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/fw.c 
b/drivers/staging/rtl8188eu/hal/fw.c
index 432e6bea5ea1..3d1d29e9f8e0 100644
--- a/drivers/staging/rtl8188eu/hal/fw.c
+++ b/drivers/staging/rtl8188eu/hal/fw.c
@@ -146,7 +146,7 @@ int rtl88eu_download_fw(struct adapter *adapt)
struct dvobj_priv *dvobj = adapter_to_dvobj(adapt);
struct device *device = dvobj_to_dev(dvobj);
const struct firmware *fw;
-   const char fw_name[] = "rtlwifi/rtl8188eufw.bin";
+   static const char fw_name[] = "rtlwifi/rtl8188eufw.bin";
struct rtl92c_firmware_header *pfwheader = NULL;
u8 *download_data, *fw_data;
size_t download_size;
-- 
2.26.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] staging: rtl8188eu: rename define to upper case

2020-04-13 Thread Michael Straube 
Rename 'FWDL_ChkSum_rpt' to 'FWDL_CHKSUM_RPT' as defines are normaly
named all upper case. Also clears a camel case checkpatch warning.

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8188eu/hal/fw.c| 4 ++--
 drivers/staging/rtl8188eu/include/rtl8188e_spec.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/fw.c 
b/drivers/staging/rtl8188eu/hal/fw.c
index 486ee4bd4744..dbf7883f9ed7 100644
--- a/drivers/staging/rtl8188eu/hal/fw.c
+++ b/drivers/staging/rtl8188eu/hal/fw.c
@@ -111,7 +111,7 @@ static int _rtl88e_fw_free_to_go(struct adapter *adapt)
 
do {
value32 = usb_read32(adapt, REG_MCUFWDL);
-   if (value32 & FWDL_ChkSum_rpt)
+   if (value32 & FWDL_CHKSUM_RPT)
break;
} while (counter++ < POLLING_READY_TIMEOUT_COUNT);
 
@@ -192,7 +192,7 @@ int rtl88eu_download_fw(struct adapter *adapt)
rtl88e_firmware_selfreset(adapt);
}
_rtl88e_enable_fw_download(adapt, true);
-   usb_write8(adapt, REG_MCUFWDL, usb_read8(adapt, REG_MCUFWDL) | 
FWDL_ChkSum_rpt);
+   usb_write8(adapt, REG_MCUFWDL, usb_read8(adapt, REG_MCUFWDL) | 
FWDL_CHKSUM_RPT);
_rtl88e_write_fw(adapt, download_data, download_size);
_rtl88e_enable_fw_download(adapt, false);
 
diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_spec.h 
b/drivers/staging/rtl8188eu/include/rtl8188e_spec.h
index dd943c831d91..be30c9434a29 100644
--- a/drivers/staging/rtl8188eu/include/rtl8188e_spec.h
+++ b/drivers/staging/rtl8188eu/include/rtl8188e_spec.h
@@ -817,7 +817,7 @@ So the following defines for 92C is not entire!!
 /* 2 MCUFWDL */
 #define MCUFWDL_EN BIT(0)
 #define MCUFWDL_RDYBIT(1)
-#define FWDL_ChkSum_rptBIT(2)
+#define FWDL_CHKSUM_RPTBIT(2)
 #define MACINI_RDY BIT(3)
 #define BBINI_RDY  BIT(4)
 #define RFINI_RDY  BIT(5)
-- 
2.26.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[staging:staging-testing] BUILD SUCCESS ce920326663b3df22c94ade99a8b234baa6ccaa5

2020-04-13 Thread kbuild test robot 
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
 staging-testing
branch HEAD: ce920326663b3df22c94ade99a8b234baa6ccaa5  staging: vt6656: 
formulate rspinf values into tables

elapsed time: 480m

configs tested: 166
configs skipped: 0

The following configs have been built successfully.
More configs may be tested in the coming days.

arm  allmodconfig
arm   allnoconfig
arm  allyesconfig
arm64allmodconfig
arm64 allnoconfig
arm64allyesconfig
arm   efm32_defconfig
arm at91_dt_defconfig
armshmobile_defconfig
arm64   defconfig
arm  exynos_defconfig
armmulti_v5_defconfig
arm   sunxi_defconfig
armmulti_v7_defconfig
sparcallyesconfig
ia64  allnoconfig
pariscgeneric-32bit_defconfig
sparc   defconfig
i386 allyesconfig
ia64defconfig
powerpc defconfig
sh   allmodconfig
i386  allnoconfig
i386 alldefconfig
i386defconfig
i386  debian-10.3
ia64 allmodconfig
ia64 allyesconfig
ia64 alldefconfig
c6x  allyesconfig
c6xevmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openriscor1ksim_defconfig
openrisc simple_smp_defconfig
xtensa   common_defconfig
xtensa  iss_defconfig
nds32   defconfig
nds32 allnoconfig
cskydefconfig
alpha   defconfig
h8300   h8s-sim_defconfig
h8300 edosk2674_defconfig
m68k   m5475evb_defconfig
m68k allmodconfig
h8300h8300h-sim_defconfig
m68k   sun3_defconfig
m68k  multi_defconfig
arc  allyesconfig
arc defconfig
microblaze  mmu_defconfig
microblazenommu_defconfig
powerpc   allnoconfig
powerpc   ppc64_defconfig
powerpc  rhel-kconfig
mips   32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips  allnoconfig
mips allyesconfig
mips  fuloong2e_defconfig
mips  malta_kvm_defconfig
pariscallnoconfig
pariscgeneric-64bit_defconfig
parisc   allyesconfig
x86_64   randconfig-a001-20200413
x86_64   randconfig-a002-20200413
x86_64   randconfig-a003-20200413
i386 randconfig-a001-20200413
i386 randconfig-a002-20200413
i386 randconfig-a003-20200413
alpharandconfig-a001-20200413
m68k randconfig-a001-20200413
mips randconfig-a001-20200413
nds32randconfig-a001-20200413
parisc   randconfig-a001-20200413
riscvrandconfig-a001-20200413
c6x  randconfig-a001-20200413
h8300randconfig-a001-20200413
microblaze   randconfig-a001-20200413
nios2randconfig-a001-20200413
sparc64  randconfig-a001-20200413
s390 randconfig-a001-20200413
xtensa   randconfig-a001-20200413
sh   randconfig-a001-20200413
openrisc randconfig-a001-20200413
csky randconfig-a001-20200413
x86_64   randconfig-b002-20200413
i386 randconfig-b001-20200413
x86_64   randconfig-b001-20200413
x86_64   randconfig-b003-20200413
i386 randconfig-b003-20200413
i386 randconfig-b002-20200413
x86_64   randconfig-c003-20200413
i386 randconfig-c003-20200413
i386 randconfig-c002-20200413
x86_64   randconfig-c002-20200413
i386 randconfig-c001-20200413
x86_64   randconfig-c001-20200413
i386 randconfig-d002-20200413
x86_64

[PATCH 0/2] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-04-13 Thread Waiman Long 
This patchset makes a global rename of the kzfree() to kfree_sensitive()
to highlight the fact buffer clearing is only needed if the data objects
contain sensitive information like encrpytion key. The fact that kzfree()
uses memset() to do the clearing isn't totally safe either as compiler
may compile out the clearing in their optimizer. Instead, the new
kfree_sensitive() uses memzero_explicit() which won't get compiled out.

Waiman Long (2):
  mm, treewide: Rename kzfree() to kfree_sensitive()
  crypto: Remove unnecessary memzero_explicit()

 arch/s390/crypto/prng.c   |  4 +--
 arch/x86/power/hibernate.c|  2 +-
 crypto/adiantum.c |  2 +-
 crypto/ahash.c|  4 +--
 crypto/api.c  |  2 +-
 crypto/asymmetric_keys/verify_pefile.c|  4 +--
 crypto/deflate.c  |  2 +-
 crypto/drbg.c | 10 +++---
 crypto/ecc.c  |  8 ++---
 crypto/ecdh.c |  2 +-
 crypto/gcm.c  |  2 +-
 crypto/gf128mul.c |  4 +--
 crypto/jitterentropy-kcapi.c  |  2 +-
 crypto/rng.c  |  2 +-
 crypto/rsa-pkcs1pad.c |  6 ++--
 crypto/seqiv.c|  2 +-
 crypto/shash.c|  2 +-
 crypto/skcipher.c |  2 +-
 crypto/testmgr.c  |  6 ++--
 crypto/zstd.c |  2 +-
 .../allwinner/sun8i-ce/sun8i-ce-cipher.c  | 17 +++---
 .../allwinner/sun8i-ss/sun8i-ss-cipher.c  | 18 +++---
 drivers/crypto/amlogic/amlogic-gxl-cipher.c   | 14 +++-
 drivers/crypto/atmel-ecc.c|  2 +-
 drivers/crypto/caam/caampkc.c | 28 +++
 drivers/crypto/cavium/cpt/cptvf_main.c|  6 ++--
 drivers/crypto/cavium/cpt/cptvf_reqmanager.c  | 12 +++
 drivers/crypto/cavium/nitrox/nitrox_lib.c |  4 +--
 drivers/crypto/cavium/zip/zip_crypto.c|  6 ++--
 drivers/crypto/ccp/ccp-crypto-rsa.c   |  6 ++--
 drivers/crypto/ccree/cc_aead.c|  4 +--
 drivers/crypto/ccree/cc_buffer_mgr.c  |  4 +--
 drivers/crypto/ccree/cc_cipher.c  |  6 ++--
 drivers/crypto/ccree/cc_hash.c|  8 ++---
 drivers/crypto/ccree/cc_request_mgr.c |  2 +-
 drivers/crypto/inside-secure/safexcel_hash.c  |  3 +-
 drivers/crypto/marvell/cesa/hash.c|  2 +-
 .../crypto/marvell/octeontx/otx_cptvf_main.c  |  6 ++--
 .../marvell/octeontx/otx_cptvf_reqmgr.h   |  2 +-
 drivers/crypto/mediatek/mtk-aes.c |  2 +-
 drivers/crypto/nx/nx.c|  4 +--
 drivers/crypto/virtio/virtio_crypto_algs.c| 12 +++
 drivers/crypto/virtio/virtio_crypto_core.c|  2 +-
 drivers/md/dm-crypt.c | 34 +--
 drivers/md/dm-integrity.c |  6 ++--
 drivers/misc/ibmvmc.c |  6 ++--
 .../hisilicon/hns3/hns3pf/hclge_mbx.c |  2 +-
 .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c|  6 ++--
 drivers/net/ppp/ppp_mppe.c|  6 ++--
 drivers/net/wireguard/noise.c |  4 +--
 drivers/net/wireguard/peer.c  |  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c  |  2 +-
 .../net/wireless/intel/iwlwifi/pcie/tx-gen2.c |  6 ++--
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c  |  6 ++--
 drivers/net/wireless/intersil/orinoco/wext.c  |  4 +--
 drivers/s390/crypto/ap_bus.h  |  4 +--
 drivers/staging/ks7010/ks_hostif.c|  2 +-
 drivers/staging/rtl8723bs/core/rtw_security.c |  2 +-
 drivers/staging/wlan-ng/p80211netdev.c|  2 +-
 drivers/target/iscsi/iscsi_target_auth.c  |  2 +-
 fs/btrfs/ioctl.c  |  2 +-
 fs/cifs/cifsencrypt.c |  2 +-
 fs/cifs/connect.c | 10 +++---
 fs/cifs/dfs_cache.c   |  2 +-
 fs/cifs/misc.c|  8 ++---
 fs/crypto/keyring.c   |  6 ++--
 fs/crypto/keysetup_v1.c   |  4 +--
 fs/ecryptfs/keystore.c|  4 +--
 fs/ecryptfs/messaging.c   |  2 +-
 include/crypto/aead.h |  2 +-
 include/crypto/akcipher.h |  2 +-
 include/crypto/gf128mul.h |  2 +-
 include/crypto/hash.h |  2 +-
 include/crypto/internal/acompress.h   |  2 +-
 include/crypto/kpp.h  |  2 +-
 include/crypto/skcipher.h |  2 +-
 include/linux/slab.h  |  2 +-
 lib/mpi/mpiutil.c |  6 ++--
 lib/test_kasan.c

[PATCH 2/2] crypto: Remove unnecessary memzero_explicit()

2020-04-13 Thread Waiman Long 
Since kfree_sensitive() will do an implicit memzero_explicit(), there
is no need to call memzero_explicit() before it. Eliminate those
memzero_explicit() and simplify the call sites.

Signed-off-by: Waiman Long 
---
 .../crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c  | 15 +++
 .../crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c  | 16 +++-
 drivers/crypto/amlogic/amlogic-gxl-cipher.c  | 10 ++
 drivers/crypto/inside-secure/safexcel_hash.c |  3 +--
 4 files changed, 9 insertions(+), 35 deletions(-)

diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c 
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index aa4e8fdc2b32..46c10c7ca6d0 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tfm)
 {
struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key);
crypto_free_sync_skcipher(op->fallback_tfm);
pm_runtime_put_sync_suspend(op->ce->dev);
 }
@@ -391,10 +388,7 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, const 
u8 *key,
dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
return -EINVAL;
}
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key);
op->keylen = keylen;
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
@@ -416,10 +410,7 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
if (err)
return err;
 
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   free_sensitive(op->key, op->keylen);
op->keylen = keylen;
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c 
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
index 5246ef4f5430..7e09a923cbaf 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
@@ -249,7 +249,6 @@ static int sun8i_ss_cipher(struct skcipher_request *areq)
offset = areq->cryptlen - ivsize;
if (rctx->op_dir & SS_DECRYPTION) {
memcpy(areq->iv, backup_iv, ivsize);
-   memzero_explicit(backup_iv, ivsize);
kfree_sensitive(backup_iv);
} else {
scatterwalk_map_and_copy(areq->iv, areq->dst, 
offset,
@@ -367,10 +366,7 @@ void sun8i_ss_cipher_exit(struct crypto_tfm *tfm)
 {
struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key);
crypto_free_sync_skcipher(op->fallback_tfm);
pm_runtime_put_sync(op->ss->dev);
 }
@@ -392,10 +388,7 @@ int sun8i_ss_aes_setkey(struct crypto_skcipher *tfm, const 
u8 *key,
dev_dbg(ss->dev, "ERROR: Invalid keylen %u\n", keylen);
return -EINVAL;
}
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key);
op->keylen = keylen;
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
@@ -418,10 +411,7 @@ int sun8i_ss_des3_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
return -EINVAL;
}
 
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key);
op->keylen = keylen;
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
diff --git a/drivers/crypto/amlogic/amlogic-gxl-cipher.c 
b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
index fd1269900d67..f424397fbba4 100644
--- a/drivers/crypto/amlogic/amlogic-gxl-cipher.c
+++ b/drivers/crypto/amlogic/amlogic-gxl-cipher.c
@@ -341,10 +341,7 @@ void meson_cipher_exit(struct crypto_tfm *tfm)
 {
struct meson_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key)
crypto_free_sync_skcipher(op->fallback_tfm);
 }
 
@@ -368,10 +365,7 @@ int meson_aes_setkey(struct crypto_skcipher *tfm, const u8 
*key,
dev_dbg(mc->dev, "ERROR: Invalid keylen %u\n", keylen);
return -EINVAL;
}
-   if (op->key) {
-   memzero_explicit

[PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()

2020-04-13 Thread Waiman Long 
As said by Linus:

  A symmetric naming is only helpful if it implies symmetries in use.
  Otherwise it's actively misleading.

  In "kzalloc()", the z is meaningful and an important part of what the
  caller wants.

  In "kzfree()", the z is actively detrimental, because maybe in the
  future we really _might_ want to use that "memfill(0xdeadbeef)" or
  something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the
recently added kvfree_sensitive() and make the intention of the API
more explicit. In addition, memzero_explicit() is used to clear the
memory to make sure that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

  git grep -w --name-only kzfree |\
  xargs sed -i 's/\bkzfree\b/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and the
use of memzero_explicit() instead of memset().

Suggested-by: Joe Perches 
Signed-off-by: Waiman Long 
---
 arch/s390/crypto/prng.c   |  4 +--
 arch/x86/power/hibernate.c|  2 +-
 crypto/adiantum.c |  2 +-
 crypto/ahash.c|  4 +--
 crypto/api.c  |  2 +-
 crypto/asymmetric_keys/verify_pefile.c|  4 +--
 crypto/deflate.c  |  2 +-
 crypto/drbg.c | 10 +++---
 crypto/ecc.c  |  8 ++---
 crypto/ecdh.c |  2 +-
 crypto/gcm.c  |  2 +-
 crypto/gf128mul.c |  4 +--
 crypto/jitterentropy-kcapi.c  |  2 +-
 crypto/rng.c  |  2 +-
 crypto/rsa-pkcs1pad.c |  6 ++--
 crypto/seqiv.c|  2 +-
 crypto/shash.c|  2 +-
 crypto/skcipher.c |  2 +-
 crypto/testmgr.c  |  6 ++--
 crypto/zstd.c |  2 +-
 .../allwinner/sun8i-ce/sun8i-ce-cipher.c  |  2 +-
 .../allwinner/sun8i-ss/sun8i-ss-cipher.c  |  2 +-
 drivers/crypto/amlogic/amlogic-gxl-cipher.c   |  4 +--
 drivers/crypto/atmel-ecc.c|  2 +-
 drivers/crypto/caam/caampkc.c | 28 +++
 drivers/crypto/cavium/cpt/cptvf_main.c|  6 ++--
 drivers/crypto/cavium/cpt/cptvf_reqmanager.c  | 12 +++
 drivers/crypto/cavium/nitrox/nitrox_lib.c |  4 +--
 drivers/crypto/cavium/zip/zip_crypto.c|  6 ++--
 drivers/crypto/ccp/ccp-crypto-rsa.c   |  6 ++--
 drivers/crypto/ccree/cc_aead.c|  4 +--
 drivers/crypto/ccree/cc_buffer_mgr.c  |  4 +--
 drivers/crypto/ccree/cc_cipher.c  |  6 ++--
 drivers/crypto/ccree/cc_hash.c|  8 ++---
 drivers/crypto/ccree/cc_request_mgr.c |  2 +-
 drivers/crypto/marvell/cesa/hash.c|  2 +-
 .../crypto/marvell/octeontx/otx_cptvf_main.c  |  6 ++--
 .../marvell/octeontx/otx_cptvf_reqmgr.h   |  2 +-
 drivers/crypto/mediatek/mtk-aes.c |  2 +-
 drivers/crypto/nx/nx.c|  4 +--
 drivers/crypto/virtio/virtio_crypto_algs.c| 12 +++
 drivers/crypto/virtio/virtio_crypto_core.c|  2 +-
 drivers/md/dm-crypt.c | 34 +--
 drivers/md/dm-integrity.c |  6 ++--
 drivers/misc/ibmvmc.c |  6 ++--
 .../hisilicon/hns3/hns3pf/hclge_mbx.c |  2 +-
 .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c|  6 ++--
 drivers/net/ppp/ppp_mppe.c|  6 ++--
 drivers/net/wireguard/noise.c |  4 +--
 drivers/net/wireguard/peer.c  |  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c  |  2 +-
 .../net/wireless/intel/iwlwifi/pcie/tx-gen2.c |  6 ++--
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c  |  6 ++--
 drivers/net/wireless/intersil/orinoco/wext.c  |  4 +--
 drivers/s390/crypto/ap_bus.h  |  4 +--
 drivers/staging/ks7010/ks_hostif.c|  2 +-
 drivers/staging/rtl8723bs/core/rtw_security.c |  2 +-
 drivers/staging/wlan-ng/p80211netdev.c|  2 +-
 drivers/target/iscsi/iscsi_target_auth.c  |  2 +-
 fs/btrfs/ioctl.c  |  2 +-
 fs/cifs/cifsencrypt.c |  2 +-
 fs/cifs/connect.c | 10 +++---
 fs/cifs/dfs_cache.c   |  2 +-
 fs/cifs/misc.c|  8 ++---
 fs/crypto/keyring.c   |  6 ++--
 fs/crypto/keysetup_v1.c   |  4 +--
 fs/ecryptfs/keystore.c|  4 +--
 fs/ecryptfs/messaging.c   |  2 +-
 i

Re: [PATCH 2/2] crypto: Remove unnecessary memzero_explicit()

2020-04-13 Thread Joe Perches 
On Mon, 2020-04-13 at 17:15 -0400, Waiman Long wrote:
> Since kfree_sensitive() will do an implicit memzero_explicit(), there
> is no need to call memzero_explicit() before it. Eliminate those
> memzero_explicit() and simplify the call sites.

2 bits of trivia:

> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c 
> b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
[]
> @@ -391,10 +388,7 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, 
> const u8 *key,
>   dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
>   return -EINVAL;
>   }
> - if (op->key) {
> - memzero_explicit(op->key, op->keylen);
> - kfree(op->key);
> - }
> + kfree_sensitive(op->key);
>   op->keylen = keylen;
>   op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>   if (!op->key)

It might be a defect to set op->keylen before the kmemdup succeeds.

> @@ -416,10 +410,7 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, 
> const u8 *key,
>   if (err)
>   return err;
>  
> - if (op->key) {
> - memzero_explicit(op->key, op->keylen);
> - kfree(op->key);
> - }
> + free_sensitive(op->key, op->keylen);

Why not kfree_sensitive(op->key) ?


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/2] crypto: Remove unnecessary memzero_explicit()

2020-04-13 Thread Waiman Long 
On 4/13/20 5:31 PM, Joe Perches wrote:
> On Mon, 2020-04-13 at 17:15 -0400, Waiman Long wrote:
>> Since kfree_sensitive() will do an implicit memzero_explicit(), there
>> is no need to call memzero_explicit() before it. Eliminate those
>> memzero_explicit() and simplify the call sites.
> 2 bits of trivia:
>
>> diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c 
>> b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
> []
>> @@ -391,10 +388,7 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, 
>> const u8 *key,
>>  dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
>>  return -EINVAL;
>>  }
>> -if (op->key) {
>> -memzero_explicit(op->key, op->keylen);
>> -kfree(op->key);
>> -}
>> +kfree_sensitive(op->key);
>>  op->keylen = keylen;
>>  op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
>>  if (!op->key)
> It might be a defect to set op->keylen before the kmemdup succeeds.
It could be. I can move it down after the op->key check.
>> @@ -416,10 +410,7 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, 
>> const u8 *key,
>>  if (err)
>>  return err;
>>  
>> -if (op->key) {
>> -memzero_explicit(op->key, op->keylen);
>> -kfree(op->key);
>> -}
>> +free_sensitive(op->key, op->keylen);
> Why not kfree_sensitive(op->key) ?

Oh, it is a bug. I will send out v2 to fix that.

Thanks for spotting it.

Cheers,
Longman


>
>

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8712: correct spelling mistake in comment

2020-04-13 Thread Michael Straube 
Correct a spelling mistake discovered by checkpatch.
attatch -> attach

Signed-off-by: Michael Straube 
---
 drivers/staging/rtl8712/usb_halinit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/usb_halinit.c 
b/drivers/staging/rtl8712/usb_halinit.c
index 6cc4a704c3a0..313c569748e9 100644
--- a/drivers/staging/rtl8712/usb_halinit.c
+++ b/drivers/staging/rtl8712/usb_halinit.c
@@ -58,7 +58,7 @@ u8 r8712_usb_hal_bus_init(struct _adapter *adapter)
r8712_write8(adapter, SYS_ISO_CTRL + 1, val8);
val8 = r8712_read8(adapter, SYS_ISO_CTRL + 1);
val8 = val8 & 0xEF;
-   /* attatch AFE PLL to MACTOP/BB/PCIe Digital */
+   /* attach AFE PLL to MACTOP/BB/PCIe Digital */
r8712_write8(adapter, SYS_ISO_CTRL + 1, val8);
val8 = r8712_read8(adapter, AFE_XTAL_CTRL + 1);
val8 = val8 & 0xFB;
-- 
2.26.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()

2020-04-13 Thread Waiman Long 
Since kfree_sensitive() will do an implicit memzero_explicit(), there
is no need to call memzero_explicit() before it. Eliminate those
memzero_explicit() and simplify the call sites. For better correctness,
the setting of keylen is also moved down after the key pointer check.

Signed-off-by: Waiman Long 
---
 .../allwinner/sun8i-ce/sun8i-ce-cipher.c  | 19 +-
 .../allwinner/sun8i-ss/sun8i-ss-cipher.c  | 20 +--
 drivers/crypto/amlogic/amlogic-gxl-cipher.c   | 12 +++
 drivers/crypto/inside-secure/safexcel_hash.c  |  3 +--
 4 files changed, 14 insertions(+), 40 deletions(-)

diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c 
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index aa4e8fdc2b32..8358fac98719 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tfm)
 {
struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key);
crypto_free_sync_skcipher(op->fallback_tfm);
pm_runtime_put_sync_suspend(op->ce->dev);
 }
@@ -391,14 +388,11 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
return -EINVAL;
}
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
-   op->keylen = keylen;
+   kfree_sensitive(op->key);
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
return -ENOMEM;
+   op->keylen = keylen;
 
crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & 
CRYPTO_TFM_REQ_MASK);
@@ -416,14 +410,11 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
if (err)
return err;
 
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
-   op->keylen = keylen;
+   kfree_sensitive(op->key);
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
return -ENOMEM;
+   op->keylen = keylen;
 
crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & 
CRYPTO_TFM_REQ_MASK);
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c 
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
index 5246ef4f5430..0495fbc27fcc 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
@@ -249,7 +249,6 @@ static int sun8i_ss_cipher(struct skcipher_request *areq)
offset = areq->cryptlen - ivsize;
if (rctx->op_dir & SS_DECRYPTION) {
memcpy(areq->iv, backup_iv, ivsize);
-   memzero_explicit(backup_iv, ivsize);
kfree_sensitive(backup_iv);
} else {
scatterwalk_map_and_copy(areq->iv, areq->dst, 
offset,
@@ -367,10 +366,7 @@ void sun8i_ss_cipher_exit(struct crypto_tfm *tfm)
 {
struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
 
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key);
crypto_free_sync_skcipher(op->fallback_tfm);
pm_runtime_put_sync(op->ss->dev);
 }
@@ -392,14 +388,11 @@ int sun8i_ss_aes_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
dev_dbg(ss->dev, "ERROR: Invalid keylen %u\n", keylen);
return -EINVAL;
}
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
-   op->keylen = keylen;
+   kfree_sensitive(op->key);
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
return -ENOMEM;
+   op->keylen = keylen;
 
crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);
crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & 
CRYPTO_TFM_REQ_MASK);
@@ -418,14 +411,11 @@ int sun8i_ss_des3_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
return -EINVAL;
}
 
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
-   op->keylen = keylen;
+   kfree_sensitive(op->key);
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
return -EN

[staging:staging-linus] BUILD SUCCESS ed87d33ddbcd9a1c3b5ae87995da34e6f51a862c

2020-04-13 Thread kbuild test robot 
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
 staging-linus
branch HEAD: ed87d33ddbcd9a1c3b5ae87995da34e6f51a862c  staging: comedi: dt2815: 
fix writing hi byte of analog output

elapsed time: 480m

configs tested: 166
configs skipped: 0

The following configs have been built successfully.
More configs may be tested in the coming days.

arm  allmodconfig
arm   allnoconfig
arm  allyesconfig
arm64allmodconfig
arm64 allnoconfig
arm64allyesconfig
arm at91_dt_defconfig
arm   efm32_defconfig
arm  exynos_defconfig
armmulti_v5_defconfig
armmulti_v7_defconfig
armshmobile_defconfig
arm   sunxi_defconfig
arm64   defconfig
sparcallyesconfig
um i386_defconfig
i386 allyesconfig
openrisc simple_smp_defconfig
i386  allnoconfig
i386 alldefconfig
i386  debian-10.3
i386defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64  allnoconfig
ia64 allyesconfig
ia64defconfig
c6x  allyesconfig
c6xevmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openriscor1ksim_defconfig
xtensa   common_defconfig
xtensa  iss_defconfig
nds32   defconfig
nds32 allnoconfig
cskydefconfig
alpha   defconfig
h8300   h8s-sim_defconfig
h8300 edosk2674_defconfig
m68k   m5475evb_defconfig
m68k allmodconfig
h8300h8300h-sim_defconfig
m68k   sun3_defconfig
m68k  multi_defconfig
arc  allyesconfig
arc defconfig
microblaze  mmu_defconfig
microblazenommu_defconfig
powerpc   allnoconfig
powerpc defconfig
powerpc   ppc64_defconfig
powerpc  rhel-kconfig
mips   32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips  allnoconfig
mips allyesconfig
mips  fuloong2e_defconfig
mips  malta_kvm_defconfig
pariscallnoconfig
parisc   allyesconfig
pariscgeneric-32bit_defconfig
pariscgeneric-64bit_defconfig
x86_64   randconfig-a001-20200413
x86_64   randconfig-a002-20200413
x86_64   randconfig-a003-20200413
i386 randconfig-a001-20200413
i386 randconfig-a002-20200413
i386 randconfig-a003-20200413
alpharandconfig-a001-20200413
m68k randconfig-a001-20200413
mips randconfig-a001-20200413
nds32randconfig-a001-20200413
parisc   randconfig-a001-20200413
riscvrandconfig-a001-20200413
c6x  randconfig-a001-20200413
h8300randconfig-a001-20200413
microblaze   randconfig-a001-20200413
nios2randconfig-a001-20200413
sparc64  randconfig-a001-20200413
s390 randconfig-a001-20200413
xtensa   randconfig-a001-20200413
sh   randconfig-a001-20200413
openrisc randconfig-a001-20200413
csky randconfig-a001-20200413
x86_64   randconfig-b001-20200413
x86_64   randconfig-b002-20200413
x86_64   randconfig-b003-20200413
i386 randconfig-b001-20200413
i386 randconfig-b002-20200413
i386 randconfig-b003-20200413
x86_64   randconfig-c001-20200413
x86_64   randconfig-c002-20200413
x86_64   randconfig-c003-20200413
i386 randconfig-c001-20200413
i386 randconfig-c002-20200413
i386 randconfig-c003-20200413
x86_64   randconfig-d001-20200413
x86_64   randconfig-d002-20200413
x86_64

Re: [PATCH v2 2/2] crypto: Remove unnecessary memzero_explicit()

2020-04-13 Thread Christophe Leroy 



Le 14/04/2020 à 00:28, Waiman Long a écrit :

Since kfree_sensitive() will do an implicit memzero_explicit(), there
is no need to call memzero_explicit() before it. Eliminate those
memzero_explicit() and simplify the call sites. For better correctness,
the setting of keylen is also moved down after the key pointer check.

Signed-off-by: Waiman Long 
---
  .../allwinner/sun8i-ce/sun8i-ce-cipher.c  | 19 +-
  .../allwinner/sun8i-ss/sun8i-ss-cipher.c  | 20 +--
  drivers/crypto/amlogic/amlogic-gxl-cipher.c   | 12 +++
  drivers/crypto/inside-secure/safexcel_hash.c  |  3 +--
  4 files changed, 14 insertions(+), 40 deletions(-)

diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c 
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index aa4e8fdc2b32..8358fac98719 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -366,10 +366,7 @@ void sun8i_ce_cipher_exit(struct crypto_tfm *tfm)
  {
struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
  
-	if (op->key) {

-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key);
crypto_free_sync_skcipher(op->fallback_tfm);
pm_runtime_put_sync_suspend(op->ce->dev);
  }
@@ -391,14 +388,11 @@ int sun8i_ce_aes_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
dev_dbg(ce->dev, "ERROR: Invalid keylen %u\n", keylen);
return -EINVAL;
}
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
-   op->keylen = keylen;
+   kfree_sensitive(op->key);
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
return -ENOMEM;
+   op->keylen = keylen;


Does it matter at all to ensure op->keylen is not set when of->key is 
NULL ? I'm not sure.


But if it does, then op->keylen should be set to 0 when freeing op->key.

  
  	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);

crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & 
CRYPTO_TFM_REQ_MASK);
@@ -416,14 +410,11 @@ int sun8i_ce_des3_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
if (err)
return err;
  
-	if (op->key) {

-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
-   op->keylen = keylen;
+   kfree_sensitive(op->key);
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
return -ENOMEM;
+   op->keylen = keylen;


Same comment as above.

  
  	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);

crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & 
CRYPTO_TFM_REQ_MASK);
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c 
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
index 5246ef4f5430..0495fbc27fcc 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
@@ -249,7 +249,6 @@ static int sun8i_ss_cipher(struct skcipher_request *areq)
offset = areq->cryptlen - ivsize;
if (rctx->op_dir & SS_DECRYPTION) {
memcpy(areq->iv, backup_iv, ivsize);
-   memzero_explicit(backup_iv, ivsize);
kfree_sensitive(backup_iv);
} else {
scatterwalk_map_and_copy(areq->iv, areq->dst, 
offset,
@@ -367,10 +366,7 @@ void sun8i_ss_cipher_exit(struct crypto_tfm *tfm)
  {
struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm);
  
-	if (op->key) {

-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
+   kfree_sensitive(op->key);
crypto_free_sync_skcipher(op->fallback_tfm);
pm_runtime_put_sync(op->ss->dev);
  }
@@ -392,14 +388,11 @@ int sun8i_ss_aes_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
dev_dbg(ss->dev, "ERROR: Invalid keylen %u\n", keylen);
return -EINVAL;
}
-   if (op->key) {
-   memzero_explicit(op->key, op->keylen);
-   kfree(op->key);
-   }
-   op->keylen = keylen;
+   kfree_sensitive(op->key);
op->key = kmemdup(key, keylen, GFP_KERNEL | GFP_DMA);
if (!op->key)
return -ENOMEM;
+   op->keylen = keylen;


Same comment as above.

  
  	crypto_sync_skcipher_clear_flags(op->fallback_tfm, CRYPTO_TFM_REQ_MASK);

crypto_sync_skcipher_set_flags(op->fallback_tfm, tfm->base.crt_flags & 
CRYPTO_TFM_REQ_MASK);
@@ -418,14 +411,11 @@ int sun8i_ss_des3_setkey(struct crypto_skcipher *tfm, 
const u8 *key,
return -EINVAL;
}
  
-	if (op->key) {

-