Re: [PATCH] hw_random: timeriomem-rng: Remove 'max < 4' condition check

[PrasannaKumar Muralidharan]

Hi Rick,

On 22 August 2017 at 22:23, Rick Altherr  wrote:
> On Tue, Aug 22, 2017 at 9:22 AM, PrasannaKumar Muralidharan
>  wrote:
>>
>> In read routiene max is always >= 4. The check whether 'max < 4' is not
>> necessary. Remove it.
>
> Missed that in the header.

It was added recently so you could have not missed it.

>
> Acked-By: Rick Altherr 
>
>>
>> Signed-off-by: PrasannaKumar Muralidharan 
>> ---
>>  drivers/char/hw_random/timeriomem-rng.c | 7 ---
>>  1 file changed, 7 deletions(-)
>>
>> diff --git a/drivers/char/hw_random/timeriomem-rng.c 
>> b/drivers/char/hw_random/timeriomem-rng.c
>> index 03ff548..f615684 100644
>> --- a/drivers/char/hw_random/timeriomem-rng.c
>> +++ b/drivers/char/hw_random/timeriomem-rng.c
>> @@ -53,13 +53,6 @@ static int timeriomem_rng_read(struct hwrng *hwrng, void 
>> *data,
>> int period_us = ktime_to_us(priv->period);
>>
>> /*
>> -* The RNG provides 32-bits per read.  Ensure there is enough space 
>> for
>> -* at minimum one read.
>> -*/
>> -   if (max < sizeof(u32))
>> -   return 0;
>> -
>> -   /*
>>  * There may not have been enough time for new data to be generated
>>  * since the last request.  If the caller doesn't want to wait, let 
>> them
>>  * bail out.  Otherwise, wait for the completion.  If the new data 
>> has
>> --
>> 2.10.0
>>

Regards,
PrasannaKumar

[PATCH v2 4/4] crypto: jz4780-rng: Enable PRNG support in CI20 defconfig

[PrasannaKumar Muralidharan]

Enable PRNG driver support in MIPS Creator CI20 default config.

Signed-off-by: PrasannaKumar Muralidharan 
---
No changes in v2

 arch/mips/configs/ci20_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index b42cfa7..9f48f2c 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -88,6 +88,11 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=5
 CONFIG_SERIAL_8250_INGENIC=y
 CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HW_RANDOM is not set
+CONFIG_CRYPTO_USER=y
+CONFIG_CRYPTO_USER_API=y
+CONFIG_CRYPTO_USER_API_RNG=y
+CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_DEV_JZ4780_RNG=y
 CONFIG_I2C=y
 CONFIG_I2C_JZ4780=y
 CONFIG_GPIO_SYSFS=y
-- 
2.10.0

[PATCH v2 3/4] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

[PrasannaKumar Muralidharan]

Add RNG node to jz4780 dtsi. This driver uses registers that are part of
the register set used by Ingenic CGU driver. Make RNG node as child of
CGU node.

Signed-off-by: PrasannaKumar Muralidharan 
---
Changes in v2:
* Add "syscon" in CGU node's compatible section
* Make RNG child node of CGU.

 arch/mips/boot/dts/ingenic/jz4780.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 4853ef6..411e16c 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -35,13 +35,17 @@
};
 
cgu: jz4780-cgu@1000 {
-   compatible = "ingenic,jz4780-cgu";
+   compatible = "ingenic,jz4780-cgu", "syscon";
reg = <0x1000 0x100>;
 
clocks = <>, <>;
clock-names = "ext", "rtc";
 
#clock-cells = <1>;
+
+   rng: rng@d8 {
+   compatible = "ingenic,jz480-rng";
+   };
};
 
pinctrl: pin-controller@1001 {
-- 
2.10.0

[PATCH v2 1/4] crypto: jz4780-rng: Add JZ4780 PRNG devicetree binding documentation

[PrasannaKumar Muralidharan]

Add devicetree bindings for hardware pseudo random number generator
present in Ingenic JZ4780 SoC.

Signed-off-by: PrasannaKumar Muralidharan 
---
Changes in v2:
* Add "syscon" in CGU node's compatible section
* Make RNG child node of CGU.

 .../bindings/crypto/ingenic,jz4780-rng.txt   | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/crypto/ingenic,jz4780-rng.txt

diff --git a/Documentation/devicetree/bindings/crypto/ingenic,jz4780-rng.txt 
b/Documentation/devicetree/bindings/crypto/ingenic,jz4780-rng.txt
new file mode 100644
index 000..a0c18e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/ingenic,jz4780-rng.txt
@@ -0,0 +1,20 @@
+Ingenic jz4780 RNG driver
+
+Required properties:
+- compatible : Should be "ingenic,jz4780-rng"
+
+Example:
+
+cgu: jz4780-cgu@1000 {
+   compatible = "ingenic,jz4780-cgu", "syscon";
+   reg = <0x1000 0x100>;
+
+   clocks = <>, <>;
+   clock-names = "ext", "rtc";
+
+   #clock-cells = <1>;
+
+   rng: rng@d8 {
+   compatible = "ingenic,jz480-rng";
+   };
+};
-- 
2.10.0

[PATCH v2 2/4] crypto: jz4780-rng: Add Ingenic JZ4780 hardware PRNG driver

[PrasannaKumar Muralidharan]

JZ4780 SoC pseudo random number generator driver using crypto framework.

Adding a delay before reading RNG data and disabling RNG after reading
data was suggested by Jeffery Walton.

Tested-by: Mathieu Malaterre 
Suggested-by: Jeffrey Walton 
Signed-off-by: PrasannaKumar Muralidharan 
---
Changes in v2:
* Fixed buffer overflow in generate function pointed out in Stephan's review
* Fold patch that had only MAINTAINERS file change with this patch
* Removed unnecessary comment in code

 MAINTAINERS |   5 ++
 drivers/crypto/Kconfig  |  19 +
 drivers/crypto/Makefile |   1 +
 drivers/crypto/jz4780-rng.c | 168 
 4 files changed, 193 insertions(+)
 create mode 100644 drivers/crypto/jz4780-rng.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c3feff..f662a70 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6672,6 +6672,11 @@ L:   linux-...@lists.infradead.org
 S: Maintained
 F: drivers/mtd/nand/jz4780_*
 
+INGENIC JZ4780 PRNG DRIVER
+M: PrasannaKumar Muralidharan 
+S: Maintained
+F: drivers/crypto/jz4780-rng.c
+
 INOTIFY
 M: John McCutchan 
 M: Robert Love 
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4b75084..de2459f 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -599,6 +599,25 @@ config CRYPTO_DEV_IMGTEC_HASH
  hardware hash accelerator. Supporting MD5/SHA1/SHA224/SHA256
  hashing algorithms.
 
+config CRYPTO_DEV_JZ4780_RNG
+   tristate "JZ4780 HW pseudo random number generator support"
+   depends on MACH_JZ4780 || COMPILE_TEST
+   depends on HAS_IOMEM
+   select CRYPTO_RNG
+   select REGMAP
+   select SYSCON
+   select MFD_SYSCON
+   ---help---
+ This driver provides kernel-side support through the
+ cryptographic API for the pseudo random number generator
+ hardware found in ingenic JZ4780 and X1000 SoC. MIPS
+ Creator CI20 uses JZ4780 SoC.
+
+ To compile this driver as a module, choose M here: the
+ module will be called jz4780-rng.
+
+ If unsure, say Y.
+
 config CRYPTO_DEV_SUN4I_SS
tristate "Support for Allwinner Security System cryptographic 
accelerator"
depends on ARCH_SUNXI && !64BIT
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 2c555a3..1df48f9 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
 obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
 obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o
 obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
+obj-$(CONFIG_CRYPTO_DEV_JZ4780_RNG) += jz4780-rng.o
 obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o
 obj-$(CONFIG_CRYPTO_DEV_MARVELL_CESA) += marvell/
 obj-$(CONFIG_CRYPTO_DEV_MEDIATEK) += mediatek/
diff --git a/drivers/crypto/jz4780-rng.c b/drivers/crypto/jz4780-rng.c
new file mode 100644
index 000..682
--- /dev/null
+++ b/drivers/crypto/jz4780-rng.c
@@ -0,0 +1,168 @@
+/*
+ * jz4780-rng.c - Random Number Generator driver for the jz4780
+ *
+ * Copyright (c) 2017 PrasannaKumar Muralidharan 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation;
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define REG_RNG_CTRL   0xD8
+#define REG_RNG_DATA   0xDC
+
+/* Context for crypto */
+struct jz4780_rng_ctx {
+   struct jz4780_rng *rng;
+};
+
+/* Device associated memory */
+struct jz4780_rng {
+   struct device *dev;
+   struct regmap *regmap;
+};
+
+static struct jz4780_rng *jz4780_rng;
+
+static int jz4780_rng_readl(struct jz4780_rng *rng, u32 offset)
+{
+   u32 val = 0;
+   int ret;
+
+   ret = regmap_read(rng->regmap, offset, );
+   if (!ret)
+   return val;
+
+   return ret;
+}
+
+static int jz4780_rng_writel(struct jz4780_rng *rng, u32 val, u32 offset)
+{
+   return regmap_write(rng->regmap, offset, val);
+}
+
+static int jz4780_rng_generate(struct crypto_rng *tfm,
+  const u8 *src, unsigned int slen,
+  u8 *dst, unsigned int dlen)
+{
+   struct jz4780_rng_ctx *ctx = crypto_rng_ctx(tfm);
+   struct jz4780_rng *rng = ctx->rng;
+   u32 data;
+
+   /*
+* A delay is required so that the current RNG data is not bit shifted
+* version of previous RNG data which could happen if 

[PATCH v2 0/4] crypto: Add driver for JZ4780 PRNG

[PrasannaKumar Muralidharan]

This patch series adds support of pseudo random number generator found
in Ingenic's JZ4780 and X1000 SoC.

Based on Paul's review comments, add 'syscon' compatible in CGU node in
jz4780.dtsi. jz4780-rng driver uses regmap exposed via syscon interface
to access the RNG registers. CGU driver is not modified in this patch
set as registers used by CGU driver and this driver are different.

PrasannaKumar Muralidharan (4):
  crypto: jz4780-rng: Add JZ4780 PRNG devicetree binding documentation
  crypto: jz4780-rng: Add Ingenic JZ4780 hardware PRNG driver
  crypto: jz4780-rng: Add RNG node to jz4780.dtsi
  crypto: jz4780-rng: Enable PRNG support in CI20 defconfig

 .../bindings/crypto/ingenic,jz4780-rng.txt |  20 +++
 MAINTAINERS|   5 +
 arch/mips/boot/dts/ingenic/jz4780.dtsi |   6 +-
 arch/mips/configs/ci20_defconfig   |   5 +
 drivers/crypto/Kconfig |  19 +++
 drivers/crypto/Makefile|   1 +
 drivers/crypto/jz4780-rng.c| 168 +
 7 files changed, 223 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/crypto/ingenic,jz4780-rng.txt
 create mode 100644 drivers/crypto/jz4780-rng.c

-- 
2.10.0

Re: [PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

[Andy Shevchenko]

On Tue, Aug 22, 2017 at 8:55 PM, Logan Gunthorpe  wrote:
> On 22/08/17 11:40 AM, Andy Shevchenko wrote:
>> Recomendation is kinda arguable. I doubt modern architectures make
>> difference between IO operations and MMIO.
>> Does, for example, PCI requires some special signal (message / wire)
>> handling when pio_*() accessors used vs. mmio_*() ones?

> Sort of. There is a difference between the two in x86.

Yes, the difference is in signaling. The question is if it's still in
use. Looks like yes...

> But really if it's
> not a valid recommendation someone should just go through and deprecate one
> of them or document better when one should be used over the other. In any
> case it's still really ugly to mix the two types in the same driver.

Mixing is ugly, totally agree.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

[Andy Shevchenko]

On Tue, Aug 22, 2017 at 8:56 PM, Logan Gunthorpe  wrote:
>
>
> On 22/08/17 11:41 AM, Andy Shevchenko wrote:
>>>
>>> @@ -59,6 +59,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>
>>
>> I would rather try to squeeze to most alpabetiacelly ordered part of this
>> block.
>> Otherwise it's a pretty nice clean up!
>>
>
> I don't understand. The includes were not alphabetically in any order
> originally and I'd rather not reorder them in my patch.

In excerpt I see if you put your include before random.h you will get
3 headers in order.
There may be even better sequence, I didn't check.


-- 
With Best Regards,
Andy Shevchenko

★beijing--“JEC world 2018 世界复合材料展览及会议”将于“3月06-08日”在“法国巴黎”举行 （地右P1-L-Me）

[linux-crypto-owner]

尊敬的 beij...@cpahkltd.com 企业领导/公司负责人/业界专家，您好：
　　
　　
新材料为21世纪三大共性关键技术之一，已成为全球经济迅速增长的源动力和提升核心竞争力的战略焦点。材料作为制造业的基础，特别是新材料研究和产业发展的水平与规模，已经成为衡量一个国家科技进步和综合实力的重要标志。在新材料发展与应用中，复合材料占有相当重要的地位，特别广泛的应用在汽车、交通、风能、航空、航天、兵器、船舶、国防、机械、电子、化工、建筑、农业、渔业、纺织、运动器材等领域，一直是世界各国优先发展和竞争激烈的重要行业。
　　
　　“JEC世界复合材料展览及会议”（JEC world Composites Show & 
Conferences）创办于1963年，每年举办一届，至2017年总共举办了52届，主办单位是法国JEC复合材料发展促进会/JEC集团，中国总展团展商组织单位为映德国际会展集团中国代表处，在北京、上海等地设有分支机构，负责该展会在中国的推广和招商工作（JEC中国总展团报名热线：4000-680-860转8144、5220）。JEC复合材料展已成为世界上历史最悠久、规模最大的复合材料行业专业展览会，展示和反映了当前复合材料行业的最新技术和应用成果。
　　
　　为了增进国内外复合材料行业的交流与合作，同时展示我国复合材料产业的发展与成就，帮助境内企业开拓国内外市场，中国国际复材协会、映德国际会展集团（YOND 
EXPO）中国代表处已近十年组织中国企业参与该展会，为中国复合材料集团、中材科技、中钢集团、中国建材集团、中国商飞、北京玻钢院、上海杰事杰新材料集团、重庆国际复合材料、中南控股集团、秦皇岛耀华玻璃钢、烟台氨纶、天马集团、华东理工大学、哈尔滨工业大学、巨石集团、中冶集团、金光集团、江苏恒神纤维材料、重庆大学、上海玻璃钢研究院、中南大学、哈尔滨玻璃钢研究院等众多行业巨头和知名机构提供了优质高效的境外展贸服务。
　　
　　“JEC world 2018 
第五十三世界复合材料展览及会议”将于“3月06-08日”在“法国巴黎展览会议中心”再度举行，我们诚邀全国各地复合材料及新材料相关单位与业界人士加入咱们的中国总展团前往参展参观。
　　
　　
　　有关参展参观“JEC世界复合材料展”事宜，请联络【中国总展团】组办方—— 
全国统一客服热线：4000-580-850（转5220、8144、）、010—6923-6944； 邮箱/QQ：12809395#qq.com； 
微信： CanZhanXiaoXi（参展消息）、ZhanShangZhiJia（展商之家）； 
微博：http://weibo.com/jecshow（展会）、http://weibo.com/yingdehuizhan（公司）。
　　
　　参加JEC展会是一个复合材料及新材料企业走向国际化的标志和途径！
　　
　　
　　
　　
__
　　
（百万群发系统|为您发送|如不希望再收到此行业资讯|请回复“TD+JEC”至邮箱1055800...@qq.com）

Re: [PATCH] crypto: ccp - Fix XTS-AES-128 support on v5 CCPs

[Gary R Hook]

On 08/18/2017 11:02 PM, Herbert Xu wrote:

On Fri, Aug 18, 2017 at 11:41:04AM -0500, Gary R Hook wrote:

On Tue, Jul 25, 2017 at 02:12:11PM -0500, Gary R Hook wrote:

Version 5 CCPs have some new requirements for XTS-AES: the type field
must be specified, and the key requires 512 bits, with each part
occupying 256 bits and padded with zeroes.

cc:  # 4.9.x+

Signed-off-by: Gary R Hook 


Patch applied.  Thanks.


Herbert,

*ping*

This is a bug fix, Could we push this into 4.13, please?


I don't think this one is critical enough to go in right now.
Is there any reason why it can't wait until the next merge window?


I am happy to defer to your expertise in this area. My concern was
whether the patch had been overlooked. I see now that it had not.

Thank you, sir.

Re: [PATCH v7 0/7] make io{read|write}64 globally usable

[Logan Gunthorpe]

On 22/08/17 11:43 AM, Andy Shevchenko wrote:

Overall quite a good clean up! Thanks!
After addressing my comments you may take my
Reviewed-by: Andy Shevchenko 


Great, Thanks!

Logan

Re: [PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

[Logan Gunthorpe]

On 22/08/17 11:41 AM, Andy Shevchenko wrote:

@@ -59,6 +59,7 @@
  #include 
  #include 
  #include 
+#include 


I would rather try to squeeze to most alpabetiacelly ordered part of this block.
Otherwise it's a pretty nice clean up!



I don't understand. The includes were not alphabetically in any order 
originally and I'd rather not reorder them in my patch.


Logan

Re: [PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

[Logan Gunthorpe]

On 22/08/17 11:40 AM, Andy Shevchenko wrote:

ldd -> LDD


Ok.


Recomendation is kinda arguable. I doubt modern architectures make
difference between IO operations and MMIO.
Does, for example, PCI requires some special signal (message / wire)
handling when pio_*() accessors used vs. mmio_*() ones?


Sort of. There is a difference between the two in x86. But really if 
it's not a valid recommendation someone should just go through and 
deprecate one of them or document better when one should be used over 
the other. In any case it's still really ugly to mix the two types in 
the same driver.



cc -> Cc ?


Fixed.

Logan

Re: [PATCH v7 0/7] make io{read|write}64 globally usable

[Andy Shevchenko]

On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe  wrote:
> This is just a resend seeing I've gotten no feedback in a couple weeks.

Overall quite a good clean up! Thanks!
After addressing my comments you may take my
Reviewed-by: Andy Shevchenko 

> Changes since v6:
>  ** none **
>
> Changes since v5:
> - Added a fix to the tilcdc driver to ensure it doesn't use the
>   non-atomic operation. (This includes adding 
> io{read|write}64[be]_is_nonatomic
>   defines).
>
> Changes since v4:
> - Add functions so the powerpc implementation of iomap.c compiles. (As
>   noticed by Horia)
>
> Changes since v3:
>
> - I noticed powerpc didn't use the appropriate functions seeing
>   readq/writeq were not defined when iomap.h was included. Thus I've
>   included a patch to adjust this
> - Fixed some mistakes with a couple of the defines in io-64-nonatomic*
>   headers
> - Fixed a typo noticed by Horia.
>
> (earlier versions were drastically different)
>
> Horia Geantă (1):
>   crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
>
> Logan Gunthorpe (6):
>   drm/tilcdc: ensure nonatomic iowrite64 is not used
>   powerpc: io.h: move iomap.h include so that it can use readq/writeq
> defs
>   powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}
>   iomap: introduce io{read|write}64_{lo_hi|hi_lo}
>   io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
>   ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
>
>  arch/powerpc/include/asm/io.h |   6 +-
>  arch/powerpc/kernel/iomap.c   |  40 +++
>  drivers/crypto/caam/regs.h|  35 ++---
>  drivers/gpu/drm/tilcdc/tilcdc_regs.h  |   2 +-
>  drivers/ntb/hw/intel/ntb_hw_intel.c   |  30 +---
>  include/asm-generic/iomap.h   |  26 +--
>  include/linux/io-64-nonatomic-hi-lo.h |  64 +
>  include/linux/io-64-nonatomic-lo-hi.h |  64 +
>  lib/iomap.c   | 132 
> ++
>  9 files changed, 331 insertions(+), 68 deletions(-)
>
> --
> 2.11.0



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

[Andy Shevchenko]

On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe  wrote:
> Now that ioread64 and iowrite64 are available in io-64-nonatomic,
> we can remove the hack at the top of ntb_hw_intel.c and replace it
> with an include.

> @@ -59,6 +59,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

I would rather try to squeeze to most alpabetiacelly ordered part of this block.
Otherwise it's a pretty nice clean up!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

[Andy Shevchenko]

On Tue, Aug 22, 2017 at 8:02 PM, Logan Gunthorpe  wrote:
> This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
> they are not already defined by the architecture. (As they are provided
> by the generic iomap library).
>
> The patch also points io{read|write}64[be] to the variant specified by the
> header name.
>
> This is because new drivers are encouraged to use ioreadXX, et al instead
> of readX[1], et al -- and mixing ioreadXX with readq is pretty ugly.
>
> [1] ldd3: section 9.4.2

ldd -> LDD

It's a pretty outdated book, though quite many chapters are actual for
these days.

Recomendation is kinda arguable. I doubt modern architectures make
difference between IO operations and MMIO.
Does, for example, PCI requires some special signal (message / wire)
handling when pio_*() accessors used vs. mmio_*() ones?

> cc: Christoph Hellwig 
> cc: Arnd Bergmann 
> cc: Alan Cox 
> cc: Greg Kroah-Hartman 

cc -> Cc ?

-- 
With Best Regards,
Andy Shevchenko

Re: Re: [PATCH 0/6] Add support for ECDSA algorithm

[Sandy Harris]

On Tue, Aug 22, 2017 at 12:14 PM, Tudor Ambarus
 wrote:
> Hi, Herbert,
>
> On 02/02/2017 03:57 PM, Herbert Xu wrote:
>>
>> Yes but RSA had an in-kernel user in the form of module signature
>> verification.  We don't add algorithms to the kernel without
>> actual users.  So this patch-set needs to come with an actual
>> in-kernel user of ECDSA.
>
>
> ECDSA can be used by the kernel module signing facility too. Is there
> any interest in using ECDSA by the kernel module signing facility?

I'd say keep it simple wherever possible; adding an algorithm should
need "is required by" not just "can be used by".

Even then, there is room for questions. In particular, whether such a
fragile algorithm should be trusted at all, let alone for signatures
on infrastructure modules that the whole OS will trust.
https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Security

[PATCH v7 0/7] make io{read|write}64 globally usable

[Logan Gunthorpe]

This is just a resend seeing I've gotten no feedback in a couple weeks.


Changes since v6:
 ** none **

Changes since v5:
- Added a fix to the tilcdc driver to ensure it doesn't use the
  non-atomic operation. (This includes adding io{read|write}64[be]_is_nonatomic
  defines).

Changes since v4:
- Add functions so the powerpc implementation of iomap.c compiles. (As
  noticed by Horia)

Changes since v3:

- I noticed powerpc didn't use the appropriate functions seeing
  readq/writeq were not defined when iomap.h was included. Thus I've
  included a patch to adjust this
- Fixed some mistakes with a couple of the defines in io-64-nonatomic*
  headers
- Fixed a typo noticed by Horia.

(earlier versions were drastically different)

Horia Geantă (1):
  crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Logan Gunthorpe (6):
  drm/tilcdc: ensure nonatomic iowrite64 is not used
  powerpc: io.h: move iomap.h include so that it can use readq/writeq
defs
  powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}
  iomap: introduce io{read|write}64_{lo_hi|hi_lo}
  io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
  ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

 arch/powerpc/include/asm/io.h |   6 +-
 arch/powerpc/kernel/iomap.c   |  40 +++
 drivers/crypto/caam/regs.h|  35 ++---
 drivers/gpu/drm/tilcdc/tilcdc_regs.h  |   2 +-
 drivers/ntb/hw/intel/ntb_hw_intel.c   |  30 +---
 include/asm-generic/iomap.h   |  26 +--
 include/linux/io-64-nonatomic-hi-lo.h |  64 +
 include/linux/io-64-nonatomic-lo-hi.h |  64 +
 lib/iomap.c   | 132 ++
 9 files changed, 331 insertions(+), 68 deletions(-)

--
2.11.0

[PATCH v7 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

[Logan Gunthorpe]

Now that ioread64 and iowrite64 are available in io-64-nonatomic,
we can remove the hack at the top of ntb_hw_intel.c and replace it
with an include.

Signed-off-by: Logan Gunthorpe 
Acked-by: Dave Jiang 
Acked-by: Allen Hubbe 
Acked-by: Jon Mason 
---
 drivers/ntb/hw/intel/ntb_hw_intel.c | 30 +-
 1 file changed, 1 insertion(+), 29 deletions(-)

diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
b/drivers/ntb/hw/intel/ntb_hw_intel.c
index 2557e2c05b90..606c90f59d4b 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.c
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ntb_hw_intel.h"
 
@@ -155,35 +156,6 @@ MODULE_PARM_DESC(xeon_b2b_dsd_bar5_addr32,
 static inline enum ntb_topo xeon_ppd_topo(struct intel_ntb_dev *ndev, u8 ppd);
 static int xeon_init_isr(struct intel_ntb_dev *ndev);
 
-#ifndef ioread64
-#ifdef readq
-#define ioread64 readq
-#else
-#define ioread64 _ioread64
-static inline u64 _ioread64(void __iomem *mmio)
-{
-   u64 low, high;
-
-   low = ioread32(mmio);
-   high = ioread32(mmio + sizeof(u32));
-   return low | (high << 32);
-}
-#endif
-#endif
-
-#ifndef iowrite64
-#ifdef writeq
-#define iowrite64 writeq
-#else
-#define iowrite64 _iowrite64
-static inline void _iowrite64(u64 val, void __iomem *mmio)
-{
-   iowrite32(val, mmio);
-   iowrite32(val >> 32, mmio + sizeof(u32));
-}
-#endif
-#endif
-
 static inline int pdev_is_atom(struct pci_dev *pdev)
 {
switch (pdev->device) {
-- 
2.11.0

[PATCH v7 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

[Logan Gunthorpe]

From: Horia Geantă 

We can now make use of the io-64-nonatomic-lo-hi header to always
provide 64 bit IO operations. So this patch cleans up the extra
CONFIG_64BIT ifdefs.

To be consistent with CAAM engine HW spec: in case of 64-bit registers,
irrespective of device endianness, the lower address should be read from
/ written to first, followed by the upper address. Indeed the I/O
accessors in CAAM driver currently don't follow the spec, however this
is a good opportunity to fix the code.

Signed-off-by: Horia Geantă 
Signed-off-by: Logan Gunthorpe 
Cc: Horia Geantă 
Cc: Dan Douglass 
Cc: Herbert Xu 
Cc: "David S. Miller" 
---
 drivers/crypto/caam/regs.h | 35 +--
 1 file changed, 5 insertions(+), 30 deletions(-)

diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 84d2f838a063..0c45505458e7 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -9,7 +9,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 /*
  * Architecture-specific register access methods
@@ -134,50 +134,25 @@ static inline void clrsetbits_32(void __iomem *reg, u32 
clear, u32 set)
  *base + 0x : least-significant 32 bits
  *base + 0x0004 : most-significant 32 bits
  */
-#ifdef CONFIG_64BIT
 static inline void wr_reg64(void __iomem *reg, u64 data)
 {
+#ifndef CONFIG_CRYPTO_DEV_FSL_CAAM_IMX
if (caam_little_end)
iowrite64(data, reg);
else
-   iowrite64be(data, reg);
-}
-
-static inline u64 rd_reg64(void __iomem *reg)
-{
-   if (caam_little_end)
-   return ioread64(reg);
-   else
-   return ioread64be(reg);
-}
-
-#else /* CONFIG_64BIT */
-static inline void wr_reg64(void __iomem *reg, u64 data)
-{
-#ifndef CONFIG_CRYPTO_DEV_FSL_CAAM_IMX
-   if (caam_little_end) {
-   wr_reg32((u32 __iomem *)(reg) + 1, data >> 32);
-   wr_reg32((u32 __iomem *)(reg), data);
-   } else
 #endif
-   {
-   wr_reg32((u32 __iomem *)(reg), data >> 32);
-   wr_reg32((u32 __iomem *)(reg) + 1, data);
-   }
+   iowrite64be(data, reg);
 }
 
 static inline u64 rd_reg64(void __iomem *reg)
 {
 #ifndef CONFIG_CRYPTO_DEV_FSL_CAAM_IMX
if (caam_little_end)
-   return ((u64)rd_reg32((u32 __iomem *)(reg) + 1) << 32 |
-   (u64)rd_reg32((u32 __iomem *)(reg)));
+   return ioread64(reg);
else
 #endif
-   return ((u64)rd_reg32((u32 __iomem *)(reg)) << 32 |
-   (u64)rd_reg32((u32 __iomem *)(reg) + 1));
+   return ioread64be(reg);
 }
-#endif /* CONFIG_64BIT  */
 
 #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
 #ifdef CONFIG_SOC_IMX7D
-- 
2.11.0

[PATCH v7 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

[Logan Gunthorpe]

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
they are not already defined by the architecture. (As they are provided
by the generic iomap library).

The patch also points io{read|write}64[be] to the variant specified by the
header name.

This is because new drivers are encouraged to use ioreadXX, et al instead
of readX[1], et al -- and mixing ioreadXX with readq is pretty ugly.

[1] ldd3: section 9.4.2

Signed-off-by: Logan Gunthorpe 
cc: Christoph Hellwig 
cc: Arnd Bergmann 
cc: Alan Cox 
cc: Greg Kroah-Hartman 
---
 include/linux/io-64-nonatomic-hi-lo.h | 64 +++
 include/linux/io-64-nonatomic-lo-hi.h | 64 +++
 2 files changed, 128 insertions(+)

diff --git a/include/linux/io-64-nonatomic-hi-lo.h 
b/include/linux/io-64-nonatomic-hi-lo.h
index defcc4644ce3..410c8b177080 100644
--- a/include/linux/io-64-nonatomic-hi-lo.h
+++ b/include/linux/io-64-nonatomic-hi-lo.h
@@ -54,4 +54,68 @@ static inline void hi_lo_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 #define writeq_relaxed hi_lo_writeq_relaxed
 #endif
 
+#ifndef ioread64_hi_lo
+#define ioread64_hi_lo ioread64_hi_lo
+static inline u64 ioread64_hi_lo(void __iomem *addr)
+{
+   u32 low, high;
+
+   high = ioread32(addr + sizeof(u32));
+   low = ioread32(addr);
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64_hi_lo
+#define iowrite64_hi_lo iowrite64_hi_lo
+static inline void iowrite64_hi_lo(u64 val, void __iomem *addr)
+{
+   iowrite32(val >> 32, addr + sizeof(u32));
+   iowrite32(val, addr);
+}
+#endif
+
+#ifndef ioread64be_hi_lo
+#define ioread64be_hi_lo ioread64be_hi_lo
+static inline u64 ioread64be_hi_lo(void __iomem *addr)
+{
+   u32 low, high;
+
+   high = ioread32be(addr);
+   low = ioread32be(addr + sizeof(u32));
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64be_hi_lo
+#define iowrite64be_hi_lo iowrite64be_hi_lo
+static inline void iowrite64be_hi_lo(u64 val, void __iomem *addr)
+{
+   iowrite32be(val >> 32, addr);
+   iowrite32be(val, addr + sizeof(u32));
+}
+#endif
+
+#ifndef ioread64
+#define ioread64_is_nonatomic
+#define ioread64 ioread64_hi_lo
+#endif
+
+#ifndef iowrite64
+#define iowrite64_is_nonatomic
+#define iowrite64 iowrite64_hi_lo
+#endif
+
+#ifndef ioread64be
+#define ioread64be_is_nonatomic
+#define ioread64be ioread64be_hi_lo
+#endif
+
+#ifndef iowrite64be
+#define iowrite64be_is_nonatomic
+#define iowrite64be iowrite64be_hi_lo
+#endif
+
 #endif /* _LINUX_IO_64_NONATOMIC_HI_LO_H_ */
diff --git a/include/linux/io-64-nonatomic-lo-hi.h 
b/include/linux/io-64-nonatomic-lo-hi.h
index 084461a4e5ab..acba36812be8 100644
--- a/include/linux/io-64-nonatomic-lo-hi.h
+++ b/include/linux/io-64-nonatomic-lo-hi.h
@@ -54,4 +54,68 @@ static inline void lo_hi_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 #define writeq_relaxed lo_hi_writeq_relaxed
 #endif
 
+#ifndef ioread64_lo_hi
+#define ioread64_lo_hi ioread64_lo_hi
+static inline u64 ioread64_lo_hi(void __iomem *addr)
+{
+   u32 low, high;
+
+   low = ioread32(addr);
+   high = ioread32(addr + sizeof(u32));
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64_lo_hi
+#define iowrite64_lo_hi iowrite64_lo_hi
+static inline void iowrite64_lo_hi(u64 val, void __iomem *addr)
+{
+   iowrite32(val, addr);
+   iowrite32(val >> 32, addr + sizeof(u32));
+}
+#endif
+
+#ifndef ioread64be_lo_hi
+#define ioread64be_lo_hi ioread64be_lo_hi
+static inline u64 ioread64be_lo_hi(void __iomem *addr)
+{
+   u32 low, high;
+
+   low = ioread32be(addr + sizeof(u32));
+   high = ioread32be(addr);
+
+   return low + ((u64)high << 32);
+}
+#endif
+
+#ifndef iowrite64be_lo_hi
+#define iowrite64be_lo_hi iowrite64be_lo_hi
+static inline void iowrite64be_lo_hi(u64 val, void __iomem *addr)
+{
+   iowrite32be(val, addr + sizeof(u32));
+   iowrite32be(val >> 32, addr);
+}
+#endif
+
+#ifndef ioread64
+#define ioread64_is_nonatomic
+#define ioread64 ioread64_lo_hi
+#endif
+
+#ifndef iowrite64
+#define iowrite64_is_nonatomic
+#define iowrite64 iowrite64_lo_hi
+#endif
+
+#ifndef ioread64be
+#define ioread64be_is_nonatomic
+#define ioread64be ioread64be_lo_hi
+#endif
+
+#ifndef iowrite64be
+#define iowrite64be_is_nonatomic
+#define iowrite64be iowrite64be_lo_hi
+#endif
+
 #endif /* _LINUX_IO_64_NONATOMIC_LO_HI_H_ */
-- 
2.11.0

[PATCH v7 2/7] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

[Logan Gunthorpe]

Subsequent patches in this series makes use of the readq and writeq
defines in iomap.h. However, as is, they get missed on the powerpc
platform seeing the include comes before the define. This patch
moves the include down to fix this.

Signed-off-by: Logan Gunthorpe 
Acked-By: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Suresh Warrier 
Cc: "Oliver O'Halloran" 
---
 arch/powerpc/include/asm/io.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 422f99cf9924..af074923d598 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -33,8 +33,6 @@ extern struct pci_dev *isa_bridge_pcidev;
 #include 
 #include 
 
-#include 
-
 #ifdef CONFIG_PPC64
 #include 
 #endif
@@ -663,6 +661,8 @@ static inline void name at  
\
 #define writel_relaxed(v, addr)writel(v, addr)
 #define writeq_relaxed(v, addr)writeq(v, addr)
 
+#include 
+
 #ifdef CONFIG_PPC32
 #define mmiowb()
 #else
-- 
2.11.0

[PATCH v7 3/7] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

[Logan Gunthorpe]

These functions will be introduced into the generic iomap.c so
they can deal with PIO accesses in hi-lo/lo-hi variants. Thus,
the powerpc version of iomap.c will need to provide the same
functions even though, in this arch, they are identical to the
regular io{read|write}64 functions.

Signed-off-by: Logan Gunthorpe 
Tested-by: Horia Geantă 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
---
 arch/powerpc/kernel/iomap.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
index a1854d1ded8b..b43dbadfd24f 100644
--- a/arch/powerpc/kernel/iomap.c
+++ b/arch/powerpc/kernel/iomap.c
@@ -44,12 +44,32 @@ u64 ioread64(void __iomem *addr)
 {
return readq(addr);
 }
+u64 ioread64_lo_hi(void __iomem *addr)
+{
+   return readq(addr);
+}
+u64 ioread64_hi_lo(void __iomem *addr)
+{
+   return readq(addr);
+}
 u64 ioread64be(void __iomem *addr)
 {
return readq_be(addr);
 }
+u64 ioread64be_lo_hi(void __iomem *addr)
+{
+   return readq_be(addr);
+}
+u64 ioread64be_hi_lo(void __iomem *addr)
+{
+   return readq_be(addr);
+}
 EXPORT_SYMBOL(ioread64);
+EXPORT_SYMBOL(ioread64_lo_hi);
+EXPORT_SYMBOL(ioread64_hi_lo);
 EXPORT_SYMBOL(ioread64be);
+EXPORT_SYMBOL(ioread64be_lo_hi);
+EXPORT_SYMBOL(ioread64be_hi_lo);
 #endif /* __powerpc64__ */
 
 void iowrite8(u8 val, void __iomem *addr)
@@ -82,12 +102,32 @@ void iowrite64(u64 val, void __iomem *addr)
 {
writeq(val, addr);
 }
+void iowrite64_lo_hi(u64 val, void __iomem *addr)
+{
+   writeq(val, addr);
+}
+void iowrite64_hi_lo(u64 val, void __iomem *addr)
+{
+   writeq(val, addr);
+}
 void iowrite64be(u64 val, void __iomem *addr)
 {
writeq_be(val, addr);
 }
+void iowrite64be_lo_hi(u64 val, void __iomem *addr)
+{
+   writeq_be(val, addr);
+}
+void iowrite64be_hi_lo(u64 val, void __iomem *addr)
+{
+   writeq_be(val, addr);
+}
 EXPORT_SYMBOL(iowrite64);
+EXPORT_SYMBOL(iowrite64_lo_hi);
+EXPORT_SYMBOL(iowrite64_hi_lo);
 EXPORT_SYMBOL(iowrite64be);
+EXPORT_SYMBOL(iowrite64be_lo_hi);
+EXPORT_SYMBOL(iowrite64be_hi_lo);
 #endif /* __powerpc64__ */
 
 /*
-- 
2.11.0

[PATCH v7 4/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

[Logan Gunthorpe]

In order to provide non-atomic functions for io{read|write}64 that will
use readq and writeq when appropriate. We define a number of variants
of these functions in the generic iomap that will do non-atomic
operations on pio but atomic operations on mmio.

These functions are only defined if readq and writeq are defined. If
they are not, then the wrappers that always use non-atomic operations
from include/linux/io-64-nonatomic*.h will be used.

Signed-off-by: Logan Gunthorpe 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Arnd Bergmann 
Cc: Suresh Warrier 
Cc: Nicholas Piggin 
---
 arch/powerpc/include/asm/io.h |   2 +
 include/asm-generic/iomap.h   |  26 +++--
 lib/iomap.c   | 132 ++
 3 files changed, 154 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index af074923d598..4cc420cfaa78 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -788,8 +788,10 @@ extern void __iounmap_at(void *ea, unsigned long size);
 
 #define mmio_read16be(addr)readw_be(addr)
 #define mmio_read32be(addr)readl_be(addr)
+#define mmio_read64be(addr)readq_be(addr)
 #define mmio_write16be(val, addr)  writew_be(val, addr)
 #define mmio_write32be(val, addr)  writel_be(val, addr)
+#define mmio_write64be(val, addr)  writeq_be(val, addr)
 #define mmio_insb(addr, dst, count)readsb(addr, dst, count)
 #define mmio_insw(addr, dst, count)readsw(addr, dst, count)
 #define mmio_insl(addr, dst, count)readsl(addr, dst, count)
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 650fede33c25..30edebf627fe 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -30,9 +30,16 @@ extern unsigned int ioread16(void __iomem *);
 extern unsigned int ioread16be(void __iomem *);
 extern unsigned int ioread32(void __iomem *);
 extern unsigned int ioread32be(void __iomem *);
-#ifdef CONFIG_64BIT
-extern u64 ioread64(void __iomem *);
-extern u64 ioread64be(void __iomem *);
+
+#ifdef readq
+#define ioread64_lo_hi ioread64_lo_hi
+#define ioread64_hi_lo ioread64_hi_lo
+#define ioread64be_lo_hi ioread64be_lo_hi
+#define ioread64be_hi_lo ioread64be_hi_lo
+extern u64 ioread64_lo_hi(void __iomem *addr);
+extern u64 ioread64_hi_lo(void __iomem *addr);
+extern u64 ioread64be_lo_hi(void __iomem *addr);
+extern u64 ioread64be_hi_lo(void __iomem *addr);
 #endif
 
 extern void iowrite8(u8, void __iomem *);
@@ -40,9 +47,16 @@ extern void iowrite16(u16, void __iomem *);
 extern void iowrite16be(u16, void __iomem *);
 extern void iowrite32(u32, void __iomem *);
 extern void iowrite32be(u32, void __iomem *);
-#ifdef CONFIG_64BIT
-extern void iowrite64(u64, void __iomem *);
-extern void iowrite64be(u64, void __iomem *);
+
+#ifdef writeq
+#define iowrite64_lo_hi iowrite64_lo_hi
+#define iowrite64_hi_lo iowrite64_hi_lo
+#define iowrite64be_lo_hi iowrite64be_lo_hi
+#define iowrite64be_hi_lo iowrite64be_hi_lo
+extern void iowrite64_lo_hi(u64 val, void __iomem *addr);
+extern void iowrite64_hi_lo(u64 val, void __iomem *addr);
+extern void iowrite64be_lo_hi(u64 val, void __iomem *addr);
+extern void iowrite64be_hi_lo(u64 val, void __iomem *addr);
 #endif
 
 /*
diff --git a/lib/iomap.c b/lib/iomap.c
index fc3dcb4b238e..845b9c41082c 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -66,6 +66,7 @@ static void bad_io_access(unsigned long port, const char 
*access)
 #ifndef mmio_read16be
 #define mmio_read16be(addr) be16_to_cpu(__raw_readw(addr))
 #define mmio_read32be(addr) be32_to_cpu(__raw_readl(addr))
+#define mmio_read64be(addr) be64_to_cpu(__raw_readq(addr))
 #endif
 
 unsigned int ioread8(void __iomem *addr)
@@ -99,6 +100,80 @@ EXPORT_SYMBOL(ioread16be);
 EXPORT_SYMBOL(ioread32);
 EXPORT_SYMBOL(ioread32be);
 
+#ifdef readq
+static u64 pio_read64_lo_hi(unsigned long port)
+{
+   u64 lo, hi;
+
+   lo = inl(port);
+   hi = inl(port + sizeof(u32));
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64_hi_lo(unsigned long port)
+{
+   u64 lo, hi;
+
+   hi = inl(port + sizeof(u32));
+   lo = inl(port);
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64be_lo_hi(unsigned long port)
+{
+   u64 lo, hi;
+
+   lo = pio_read32be(port + sizeof(u32));
+   hi = pio_read32be(port);
+
+   return lo | (hi << 32);
+}
+
+static u64 pio_read64be_hi_lo(unsigned long port)
+{
+   u64 lo, hi;
+
+   hi = pio_read32be(port);
+   lo = pio_read32be(port + sizeof(u32));
+
+   return lo | (hi << 32);
+}
+
+u64 ioread64_lo_hi(void __iomem *addr)
+{
+   IO_COND(addr, return pio_read64_lo_hi(port), return readq(addr));
+   return 0xULL;
+}
+
+u64 ioread64_hi_lo(void __iomem *addr)
+{
+   

[PATCH v7 1/7] drm/tilcdc: ensure nonatomic iowrite64 is not used

[Logan Gunthorpe]

Add a check to ensure iowrite64 is only used if it is atomic.

It was decided in [1] that the tilcdc driver should not be using an
atomic operation (so it was left out of this patchset). However, it turns
out that through the drm code, a nonatomic header is actually included:

include/linux/io-64-nonatomic-lo-hi.h
is included from include/drm/drm_os_linux.h:9:0,
from include/drm/drmP.h:74,
from include/drm/drm_modeset_helper.h:26,
from include/drm/drm_atomic_helper.h:33,
from drivers/gpu/drm/tilcdc/tilcdc_crtc.c:19:

And thus, without this change, this patchset would inadvertantly
change the behaviour of the tilcdc driver.

[1] 
lkml.kernel.org/r/cak8p3a2hho_zcnstzq7hmwsz5la5thu19fwzpun16imnyyn...@mail.gmail.com

Signed-off-by: Logan Gunthorpe 
Cc: Jyri Sarha 
Cc: Arnd Bergmann 
Cc: Tomi Valkeinen 
Cc: David Airlie 
---
 drivers/gpu/drm/tilcdc/tilcdc_regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index 9d528c0a67a4..5048ebb86835 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -133,7 +133,7 @@ static inline void tilcdc_write64(struct drm_device *dev, 
u32 reg, u64 data)
struct tilcdc_drm_private *priv = dev->dev_private;
volatile void __iomem *addr = priv->mmio + reg;
 
-#ifdef iowrite64
+#if defined(iowrite64) && !defined(iowrite64_is_nonatomic)
iowrite64(data, addr);
 #else
__iowmb();
-- 
2.11.0

Re: [PATCH] hw_random: timeriomem-rng: Remove 'max < 4' condition check

[Rick Altherr]

On Tue, Aug 22, 2017 at 9:22 AM, PrasannaKumar Muralidharan
 wrote:
>
> In read routiene max is always >= 4. The check whether 'max < 4' is not
> necessary. Remove it.

Missed that in the header.

Acked-By: Rick Altherr 

>
> Signed-off-by: PrasannaKumar Muralidharan 
> ---
>  drivers/char/hw_random/timeriomem-rng.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/drivers/char/hw_random/timeriomem-rng.c 
> b/drivers/char/hw_random/timeriomem-rng.c
> index 03ff548..f615684 100644
> --- a/drivers/char/hw_random/timeriomem-rng.c
> +++ b/drivers/char/hw_random/timeriomem-rng.c
> @@ -53,13 +53,6 @@ static int timeriomem_rng_read(struct hwrng *hwrng, void 
> *data,
> int period_us = ktime_to_us(priv->period);
>
> /*
> -* The RNG provides 32-bits per read.  Ensure there is enough space 
> for
> -* at minimum one read.
> -*/
> -   if (max < sizeof(u32))
> -   return 0;
> -
> -   /*
>  * There may not have been enough time for new data to be generated
>  * since the last request.  If the caller doesn't want to wait, let 
> them
>  * bail out.  Otherwise, wait for the completion.  If the new data has
> --
> 2.10.0
>

[PATCH] hw_random: timeriomem-rng: Remove 'max < 4' condition check

[PrasannaKumar Muralidharan]

In read routiene max is always >= 4. The check whether 'max < 4' is not
necessary. Remove it.

Signed-off-by: PrasannaKumar Muralidharan 
---
 drivers/char/hw_random/timeriomem-rng.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/char/hw_random/timeriomem-rng.c 
b/drivers/char/hw_random/timeriomem-rng.c
index 03ff548..f615684 100644
--- a/drivers/char/hw_random/timeriomem-rng.c
+++ b/drivers/char/hw_random/timeriomem-rng.c
@@ -53,13 +53,6 @@ static int timeriomem_rng_read(struct hwrng *hwrng, void 
*data,
int period_us = ktime_to_us(priv->period);
 
/*
-* The RNG provides 32-bits per read.  Ensure there is enough space for
-* at minimum one read.
-*/
-   if (max < sizeof(u32))
-   return 0;
-
-   /*
 * There may not have been enough time for new data to be generated
 * since the last request.  If the caller doesn't want to wait, let them
 * bail out.  Otherwise, wait for the completion.  If the new data has
-- 
2.10.0

[PATCH] Documentation: hw_random: Fix issue related to feeding entropy pool

[PrasannaKumar Muralidharan]

There is no need to use rng-tools for feeding random data into kernel
entropy pool as hw_random core handles it. Documentation suggested that
rng-tools is required which is incorrect. So remove it.

Signed-off-by: PrasannaKumar Muralidharan 
---
 Documentation/hw_random.txt | 4 
 1 file changed, 4 deletions(-)

diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt
index 121de96..46b2480 100644
--- a/Documentation/hw_random.txt
+++ b/Documentation/hw_random.txt
@@ -19,10 +19,6 @@ hw_random driver's official Web site:
 
http://sourceforge.net/projects/gkernel/
 
-Those tools use /dev/hwrng to fill the kernel entropy pool,
-which is used internally and exported by the /dev/urandom and
-/dev/random special files.
-
 Theory of operation
 ===
 
-- 
2.10.0

Re: Re: [PATCH 0/6] Add support for ECDSA algorithm

[Tudor Ambarus]

Hi, Herbert,

On 02/02/2017 03:57 PM, Herbert Xu wrote:

Yes but RSA had an in-kernel user in the form of module signature
verification.  We don't add algorithms to the kernel without
actual users.  So this patch-set needs to come with an actual
in-kernel user of ECDSA.


ECDSA can be used by the kernel module signing facility too. Is there
any interest in using ECDSA by the kernel module signing facility?

Thanks,
ta

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

[Dan Carpenter]

Try saving this email and then do `cat email.txt | git am`.  It is
corrupted.  This is not how to send a v2 patch.  Please read:

https://kernelnewbies.org/FirstKernelPatch#head-5c81b3c517a1d0bbc24f92594cb734e155fcbbcb

Look through the email archives for examples of other v2 patches.

regards,
dan carpenter

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

[Rishabh Hardas]

On Wed, Aug 16, 2017 at 03:09:09PM -0700, Greg KH wrote:
> On Mon, Jul 31, 2017 at 02:47:23PM +0530, RishabhHardas wrote:
> > From: RishabhHardas 
> > 
> > Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and 
> > 'fips_handler'
> > that they were not declared and need to be made static. This patch makes 
> > both the symbols
> > static inline, to remove the warnings.
> > 
> > Signed-off-by: RishabhHardas 
> 
> I doubt you sign your name on legal documents without a ' ' somewhere in
> it :(
> 
> Please fix up and resend.
> 
> thanks,
> 
> greg k-h

>From 717ec264a6212b8526c381d3673dd0ee45352266 Mon Sep 17 00:00:00 2001
From: Rishabh Hardas 
Date: Tue, 22 Aug 2017 18:56:45 +0530
Subject: [PATCH v2] staging/ccree: Declare compiled out fuctions static inline

Signed-off-by: Rishabh Hardas 
---

Changes in v2:
Corrected my Name.
 drivers/staging/ccree/ssi_fips.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_fips.h b/drivers/staging/ccree/ssi_fips.h
index 369ddf9..63bcca7 100644
--- a/drivers/staging/ccree/ssi_fips.h
+++ b/drivers/staging/ccree/ssi_fips.h
@@ -40,8 +40,8 @@ static inline int ssi_fips_init(struct ssi_drvdata *p_drvdata)
 }

 static inline void ssi_fips_fini(struct ssi_drvdata *drvdata) {}
-void cc_set_ree_fips_status(struct ssi_drvdata *drvdata, bool ok) {}
-void fips_handler(struct ssi_drvdata *drvdata) {}
+static inline void cc_set_ree_fips_status(struct ssi_drvdata *drvdata, bool 
ok) {}
+static inline void fips_handler(struct ssi_drvdata *drvdata) {}

 #endif /* CONFIG_CRYPTO_FIPS */

--
1.9.1

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

[Dan Carpenter]

Google for how to send a v2 patch.

https://www.google.com/search?q=how+to+send+a+v2+patch

https://kernelnewbies.org/FirstKernelPatch

regards,
dan carpenter

Re: [PATCH] staging/ccree: Declare compiled out fuctions static inline

[Rishabh Hardas]

On Wed, Aug 16, 2017 at 03:09:09PM -0700, Greg KH wrote:
> On Mon, Jul 31, 2017 at 02:47:23PM +0530, RishabhHardas wrote:
> > From: RishabhHardas 
> > 
> > Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and 
> > 'fips_handler'
> > that they were not declared and need to be made static. This patch makes 
> > both the symbols
> > static inline, to remove the warnings.
> > 
> > Signed-off-by: RishabhHardas 
> 
> I doubt you sign your name on legal documents without a ' ' somewhere in
> it :(
> 
> Please fix up and resend.
> 
> thanks,
> 
> greg k-h
From: Rishabh Hardas 

Sparse was giving out a warning for symbols 'cc_set_ree_fips_status' and 
'fips_handler'
that they were not declared and need to be made static. This patch makes both 
the symbols
static inline, to remove the warnings.

Signed-off-by: Rishabh Hardas 
---
 drivers/staging/ccree/ssi_fips.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_fips.h b/drivers/staging/ccree/ssi_fips.h
index 369ddf9..63bcca7 100644
--- a/drivers/staging/ccree/ssi_fips.h
+++ b/drivers/staging/ccree/ssi_fips.h
@@ -40,1 +40,1 @@ static inline int ssi_fips_init(struct ssi_drvdata *p_drvdata)
 }

 static inline void ssi_fips_fini(struct ssi_drvdata *drvdata) {}
-void cc_set_ree_fips_status(struct ssi_drvdata *drvdata, bool ok) {}
-void fips_handler(struct ssi_drvdata *drvdata) {}
+static inline void cc_set_ree_fips_status(struct ssi_drvdata *drvdata, bool 
ok) {}
+static inline void fips_handler(struct ssi_drvdata *drvdata) {}

 #endif /* CONFIG_CRYPTO_FIPS */

--
1.9.1

[PATCH 00/11] crypto: gcm - add GCM IV size constant

[Corentin Labbe]

Many GCM users use directly GCM IV size instead of using some constant.

This patch add all IV size constant used by GCM and convert drivers for using 
them..

Corentin Labbe (11):
  crypto: gcm - add GCM iv size constant
  crypto: caam - Use GCM IV size constant
  crypto: ccp - Use GCM IV size constant
  crypto: nx - Use GCM IV size constant
  crypto: atmel - Use GCM IV size constant
  crypto: bcm - Use GCM IV size constant
  crypto: mediatek - Use GCM IV size constant
  crypto: chelsio - Use GCM IV size constant
  crypto: omap - Use GCM IV size constant
  crypto: gcm - Use GCM IV size constant
  crypto: aesni - Use GCM IV size constant

 arch/x86/crypto/aesni-intel_glue.c |  7 ---
 crypto/gcm.c   | 23 ---
 drivers/crypto/atmel-aes.c |  5 +++--
 drivers/crypto/bcm/cipher.c|  8 
 drivers/crypto/bcm/cipher.h|  3 +--
 drivers/crypto/caam/caamalg.c  | 10 +-
 drivers/crypto/caam/compat.h   |  1 +
 drivers/crypto/ccp/ccp-crypto-aes-galois.c |  9 -
 drivers/crypto/chelsio/chcr_algo.c |  9 +
 drivers/crypto/mediatek/mtk-aes.c  |  3 ++-
 drivers/crypto/nx/nx-aes-gcm.c |  9 +
 drivers/crypto/omap-aes-gcm.c  |  7 ---
 drivers/crypto/omap-aes.c  |  5 +++--
 include/crypto/gcm.h   |  8 
 14 files changed, 61 insertions(+), 46 deletions(-)
 create mode 100644 include/crypto/gcm.h

-- 
2.13.0

[PATCH 02/11] crypto: caam - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/caam/caamalg.c | 10 +-
 drivers/crypto/caam/compat.h  |  1 +
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 54f3b375a453..baa8dd52472d 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -992,7 +992,7 @@ static void init_gcm_job(struct aead_request *req,
struct caam_ctx *ctx = crypto_aead_ctx(aead);
unsigned int ivsize = crypto_aead_ivsize(aead);
u32 *desc = edesc->hw_desc;
-   bool generic_gcm = (ivsize == 12);
+   bool generic_gcm = (ivsize == GCM_AES_IV_SIZE);
unsigned int last;
 
init_aead_job(req, edesc, all_contig, encrypt);
@@ -1004,7 +1004,7 @@ static void init_gcm_job(struct aead_request *req,
 
/* Read GCM IV */
append_cmd(desc, CMD_FIFO_LOAD | FIFOLD_CLASS_CLASS1 | IMMEDIATE |
-FIFOLD_TYPE_IV | FIFOLD_TYPE_FLUSH1 | 12 | last);
+FIFOLD_TYPE_IV | FIFOLD_TYPE_FLUSH1 | GCM_AES_IV_SIZE 
| last);
/* Append Salt */
if (!generic_gcm)
append_data(desc, ctx->key + ctx->cdata.keylen, 4);
@@ -1953,7 +1953,7 @@ static struct caam_aead_alg driver_aeads[] = {
.setauthsize = rfc4106_setauthsize,
.encrypt = ipsec_gcm_encrypt,
.decrypt = ipsec_gcm_decrypt,
-   .ivsize = 8,
+   .ivsize = GCM_RFC4106_IV_SIZE,
.maxauthsize = AES_BLOCK_SIZE,
},
.caam = {
@@ -1971,7 +1971,7 @@ static struct caam_aead_alg driver_aeads[] = {
.setauthsize = rfc4543_setauthsize,
.encrypt = ipsec_gcm_encrypt,
.decrypt = ipsec_gcm_decrypt,
-   .ivsize = 8,
+   .ivsize = GCM_RFC4543_IV_SIZE,
.maxauthsize = AES_BLOCK_SIZE,
},
.caam = {
@@ -1990,7 +1990,7 @@ static struct caam_aead_alg driver_aeads[] = {
.setauthsize = gcm_setauthsize,
.encrypt = gcm_encrypt,
.decrypt = gcm_decrypt,
-   .ivsize = 12,
+   .ivsize = GCM_AES_IV_SIZE,
.maxauthsize = AES_BLOCK_SIZE,
},
.caam = {
diff --git a/drivers/crypto/caam/compat.h b/drivers/crypto/caam/compat.h
index 7149cd2492e0..5b8d930f3dd8 100644
--- a/drivers/crypto/caam/compat.h
+++ b/drivers/crypto/caam/compat.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.13.0

[PATCH 01/11] crypto: gcm - add GCM IV size constant

[Corentin Labbe]

Many GCM users use directly GCM IV size instead of using some constant.

This patch add all IV size constant used by GCM.

Signed-off-by: Corentin Labbe 
---
 include/crypto/gcm.h | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 include/crypto/gcm.h

diff --git a/include/crypto/gcm.h b/include/crypto/gcm.h
new file mode 100644
index ..c50e057ea17e
--- /dev/null
+++ b/include/crypto/gcm.h
@@ -0,0 +1,8 @@
+#ifndef _CRYPTO_GCM_H
+#define _CRYPTO_GCM_H
+
+#define GCM_AES_IV_SIZE 12
+#define GCM_RFC4106_IV_SIZE 8
+#define GCM_RFC4543_IV_SIZE 8
+
+#endif
-- 
2.13.0

[PATCH 03/11] crypto: ccp - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/ccp/ccp-crypto-aes-galois.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-crypto-aes-galois.c 
b/drivers/crypto/ccp/ccp-crypto-aes-galois.c
index 52313524a4dd..ff02b713c6f6 100644
--- a/drivers/crypto/ccp/ccp-crypto-aes-galois.c
+++ b/drivers/crypto/ccp/ccp-crypto-aes-galois.c
@@ -19,13 +19,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include "ccp-crypto.h"
 
-#defineAES_GCM_IVSIZE  12
-
 static int ccp_aes_gcm_complete(struct crypto_async_request *async_req, int 
ret)
 {
return ret;
@@ -95,9 +94,9 @@ static int ccp_aes_gcm_crypt(struct aead_request *req, bool 
encrypt)
 */
 
/* Prepare the IV: 12 bytes + an integer (counter) */
-   memcpy(rctx->iv, req->iv, AES_GCM_IVSIZE);
+   memcpy(rctx->iv, req->iv, GCM_AES_IV_SIZE);
for (i = 0; i < 3; i++)
-   rctx->iv[i + AES_GCM_IVSIZE] = 0;
+   rctx->iv[i + GCM_AES_IV_SIZE] = 0;
rctx->iv[AES_BLOCK_SIZE - 1] = 1;
 
/* Set up a scatterlist for the IV */
@@ -160,7 +159,7 @@ static struct aead_alg ccp_aes_gcm_defaults = {
.encrypt = ccp_aes_gcm_encrypt,
.decrypt = ccp_aes_gcm_decrypt,
.init = ccp_aes_gcm_cra_init,
-   .ivsize = AES_GCM_IVSIZE,
+   .ivsize = GCM_AES_IV_SIZE,
.maxauthsize = AES_BLOCK_SIZE,
.base = {
.cra_flags  = CRYPTO_ALG_TYPE_ABLKCIPHER |
-- 
2.13.0

[PATCH 06/11] crypto: bcm - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/bcm/cipher.c | 8 
 drivers/crypto/bcm/cipher.h | 3 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index 8685c7e4debd..537a67483aa3 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -1367,11 +1367,11 @@ static int handle_aead_req(struct iproc_reqctx_s *rctx)
 * expects AAD to include just SPI and seqno. So
 * subtract off the IV len.
 */
-   aead_parms.assoc_size -= GCM_ESP_IV_SIZE;
+   aead_parms.assoc_size -= GCM_RFC4106_IV_SIZE;
 
if (rctx->is_encrypt) {
aead_parms.return_iv = true;
-   aead_parms.ret_iv_len = GCM_ESP_IV_SIZE;
+   aead_parms.ret_iv_len = GCM_RFC4106_IV_SIZE;
aead_parms.ret_iv_off = GCM_ESP_SALT_SIZE;
}
} else {
@@ -3255,7 +3255,7 @@ static struct iproc_alg_s driver_algs[] = {
.cra_flags = CRYPTO_ALG_NEED_FALLBACK
 },
 .setkey = aead_gcm_esp_setkey,
-.ivsize = GCM_ESP_IV_SIZE,
+.ivsize = GCM_RFC4106_IV_SIZE,
 .maxauthsize = AES_BLOCK_SIZE,
 },
 .cipher_info = {
@@ -3301,7 +3301,7 @@ static struct iproc_alg_s driver_algs[] = {
.cra_flags = CRYPTO_ALG_NEED_FALLBACK
 },
 .setkey = rfc4543_gcm_esp_setkey,
-.ivsize = GCM_ESP_IV_SIZE,
+.ivsize = GCM_RFC4106_IV_SIZE,
 .maxauthsize = AES_BLOCK_SIZE,
 },
 .cipher_info = {
diff --git a/drivers/crypto/bcm/cipher.h b/drivers/crypto/bcm/cipher.h
index 57a55eb2a255..763c425c41ca 100644
--- a/drivers/crypto/bcm/cipher.h
+++ b/drivers/crypto/bcm/cipher.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -39,8 +40,6 @@
 #define ARC4_STATE_SIZE 4
 
 #define CCM_AES_IV_SIZE16
-#define GCM_AES_IV_SIZE12
-#define GCM_ESP_IV_SIZE 8
 #define CCM_ESP_IV_SIZE 8
 #define RFC4543_ICV_SIZE   16
 
-- 
2.13.0

[PATCH 05/11] crypto: atmel - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/atmel-aes.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c
index 29e20c37f3a6..903fd43f23a5 100644
--- a/drivers/crypto/atmel-aes.c
+++ b/drivers/crypto/atmel-aes.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1532,7 +1533,7 @@ static int atmel_aes_gcm_start(struct atmel_aes_dev *dd)
if (err)
return atmel_aes_complete(dd, err);
 
-   if (likely(ivsize == 12)) {
+   if (likely(ivsize == GCM_AES_IV_SIZE)) {
memcpy(ctx->j0, iv, ivsize);
ctx->j0[3] = cpu_to_be32(1);
return atmel_aes_gcm_process(dd);
@@ -1820,7 +1821,7 @@ static struct aead_alg aes_gcm_alg = {
.decrypt= atmel_aes_gcm_decrypt,
.init   = atmel_aes_gcm_init,
.exit   = atmel_aes_gcm_exit,
-   .ivsize = 12,
+   .ivsize = GCM_AES_IV_SIZE,
.maxauthsize= AES_BLOCK_SIZE,
 
.base = {
-- 
2.13.0

[PATCH 10/11] crypto: gcm - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 crypto/gcm.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/crypto/gcm.c b/crypto/gcm.c
index 3841b5eafa7e..80cf6cfe082b 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "internal.h"
 #include 
@@ -197,8 +198,8 @@ static void crypto_gcm_init_common(struct aead_request *req)
struct scatterlist *sg;
 
memset(pctx->auth_tag, 0, sizeof(pctx->auth_tag));
-   memcpy(pctx->iv, req->iv, 12);
-   memcpy(pctx->iv + 12, , 4);
+   memcpy(pctx->iv, req->iv, GCM_AES_IV_SIZE);
+   memcpy(pctx->iv + GCM_AES_IV_SIZE, , 4);
 
sg_init_table(pctx->src, 3);
sg_set_buf(pctx->src, pctx->auth_tag, sizeof(pctx->auth_tag));
@@ -695,7 +696,7 @@ static int crypto_gcm_create_common(struct crypto_template 
*tmpl,
inst->alg.base.cra_alignmask = ghash->base.cra_alignmask |
   ctr->base.cra_alignmask;
inst->alg.base.cra_ctxsize = sizeof(struct crypto_gcm_ctx);
-   inst->alg.ivsize = 12;
+   inst->alg.ivsize = GCM_AES_IV_SIZE;
inst->alg.chunksize = crypto_skcipher_alg_chunksize(ctr);
inst->alg.maxauthsize = 16;
inst->alg.init = crypto_gcm_init_tfm;
@@ -832,20 +833,20 @@ static struct aead_request *crypto_rfc4106_crypt(struct 
aead_request *req)
u8 *iv = PTR_ALIGN((u8 *)(subreq + 1) + crypto_aead_reqsize(child),
   crypto_aead_alignmask(child) + 1);
 
-   scatterwalk_map_and_copy(iv + 12, req->src, 0, req->assoclen - 8, 0);
+   scatterwalk_map_and_copy(iv + GCM_AES_IV_SIZE, req->src, 0, 
req->assoclen - 8, 0);
 
memcpy(iv, ctx->nonce, 4);
memcpy(iv + 4, req->iv, 8);
 
sg_init_table(rctx->src, 3);
-   sg_set_buf(rctx->src, iv + 12, req->assoclen - 8);
+   sg_set_buf(rctx->src, iv + GCM_AES_IV_SIZE, req->assoclen - 8);
sg = scatterwalk_ffwd(rctx->src + 1, req->src, req->assoclen);
if (sg != rctx->src + 1)
sg_chain(rctx->src, 2, sg);
 
if (req->src != req->dst) {
sg_init_table(rctx->dst, 3);
-   sg_set_buf(rctx->dst, iv + 12, req->assoclen - 8);
+   sg_set_buf(rctx->dst, iv + GCM_AES_IV_SIZE, req->assoclen - 8);
sg = scatterwalk_ffwd(rctx->dst + 1, req->dst, req->assoclen);
if (sg != rctx->dst + 1)
sg_chain(rctx->dst, 2, sg);
@@ -957,7 +958,7 @@ static int crypto_rfc4106_create(struct crypto_template 
*tmpl,
err = -EINVAL;
 
/* Underlying IV size must be 12. */
-   if (crypto_aead_alg_ivsize(alg) != 12)
+   if (crypto_aead_alg_ivsize(alg) != GCM_AES_IV_SIZE)
goto out_drop_alg;
 
/* Not a stream cipher? */
@@ -980,7 +981,7 @@ static int crypto_rfc4106_create(struct crypto_template 
*tmpl,
 
inst->alg.base.cra_ctxsize = sizeof(struct crypto_rfc4106_ctx);
 
-   inst->alg.ivsize = 8;
+   inst->alg.ivsize = GCM_RFC4106_IV_SIZE;
inst->alg.chunksize = crypto_aead_alg_chunksize(alg);
inst->alg.maxauthsize = crypto_aead_alg_maxauthsize(alg);
 
@@ -1134,7 +1135,7 @@ static int crypto_rfc4543_init_tfm(struct crypto_aead 
*tfm)
tfm,
sizeof(struct crypto_rfc4543_req_ctx) +
ALIGN(crypto_aead_reqsize(aead), crypto_tfm_ctx_alignment()) +
-   align + 12);
+   align + GCM_AES_IV_SIZE);
 
return 0;
 
@@ -1199,7 +1200,7 @@ static int crypto_rfc4543_create(struct crypto_template 
*tmpl,
err = -EINVAL;
 
/* Underlying IV size must be 12. */
-   if (crypto_aead_alg_ivsize(alg) != 12)
+   if (crypto_aead_alg_ivsize(alg) != GCM_AES_IV_SIZE)
goto out_drop_alg;
 
/* Not a stream cipher? */
@@ -1222,7 +1223,7 @@ static int crypto_rfc4543_create(struct crypto_template 
*tmpl,
 
inst->alg.base.cra_ctxsize = sizeof(struct crypto_rfc4543_ctx);
 
-   inst->alg.ivsize = 8;
+   inst->alg.ivsize = GCM_RFC4543_IV_SIZE;
inst->alg.chunksize = crypto_aead_alg_chunksize(alg);
inst->alg.maxauthsize = crypto_aead_alg_maxauthsize(alg);
 
-- 
2.13.0

[PATCH 11/11] crypto: aesni - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 arch/x86/crypto/aesni-intel_glue.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_glue.c 
b/arch/x86/crypto/aesni-intel_glue.c
index 5c15d6b57329..80664368bf14 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1131,7 +1132,7 @@ static struct aead_alg aesni_aead_algs[] = { {
.setauthsize= common_rfc4106_set_authsize,
.encrypt= helper_rfc4106_encrypt,
.decrypt= helper_rfc4106_decrypt,
-   .ivsize = 8,
+   .ivsize = GCM_RFC4106_IV_SIZE,
.maxauthsize= 16,
.base = {
.cra_name   = "__gcm-aes-aesni",
@@ -1149,7 +1150,7 @@ static struct aead_alg aesni_aead_algs[] = { {
.setauthsize= rfc4106_set_authsize,
.encrypt= rfc4106_encrypt,
.decrypt= rfc4106_decrypt,
-   .ivsize = 8,
+   .ivsize = GCM_RFC4106_IV_SIZE,
.maxauthsize= 16,
.base = {
.cra_name   = "rfc4106(gcm(aes))",
@@ -1165,7 +1166,7 @@ static struct aead_alg aesni_aead_algs[] = { {
.setauthsize= generic_gcmaes_set_authsize,
.encrypt= generic_gcmaes_encrypt,
.decrypt= generic_gcmaes_decrypt,
-   .ivsize = 12,
+   .ivsize = GCM_AES_IV_SIZE,
.maxauthsize= 16,
.base = {
.cra_name   = "gcm(aes)",
-- 
2.13.0

[PATCH 09/11] crypto: omap - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/omap-aes-gcm.c | 7 ---
 drivers/crypto/omap-aes.c | 5 +++--
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 7d4f8a4be6d8..9b8f1c752168 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -311,7 +312,7 @@ static int omap_aes_gcm_crypt(struct aead_request *req, 
unsigned long mode)
int err, assoclen;
 
memset(rctx->auth_tag, 0, sizeof(rctx->auth_tag));
-   memcpy(rctx->iv + 12, , 4);
+   memcpy(rctx->iv + GCM_AES_IV_SIZE, , 4);
 
err = do_encrypt_iv(req, (u32 *)rctx->auth_tag, (u32 *)rctx->iv);
if (err)
@@ -339,7 +340,7 @@ int omap_aes_gcm_encrypt(struct aead_request *req)
 {
struct omap_aes_reqctx *rctx = aead_request_ctx(req);
 
-   memcpy(rctx->iv, req->iv, 12);
+   memcpy(rctx->iv, req->iv, GCM_AES_IV_SIZE);
return omap_aes_gcm_crypt(req, FLAGS_ENCRYPT | FLAGS_GCM);
 }
 
@@ -347,7 +348,7 @@ int omap_aes_gcm_decrypt(struct aead_request *req)
 {
struct omap_aes_reqctx *rctx = aead_request_ctx(req);
 
-   memcpy(rctx->iv, req->iv, 12);
+   memcpy(rctx->iv, req->iv, GCM_AES_IV_SIZE);
return omap_aes_gcm_crypt(req, FLAGS_GCM);
 }
 
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index c376a3ee7c2c..1f3686a1ebfa 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -767,7 +768,7 @@ static struct aead_alg algs_aead_gcm[] = {
},
.init   = omap_aes_gcm_cra_init,
.exit   = omap_aes_gcm_cra_exit,
-   .ivsize = 12,
+   .ivsize = GCM_AES_IV_SIZE,
.maxauthsize= AES_BLOCK_SIZE,
.setkey = omap_aes_gcm_setkey,
.encrypt= omap_aes_gcm_encrypt,
@@ -788,7 +789,7 @@ static struct aead_alg algs_aead_gcm[] = {
.init   = omap_aes_gcm_cra_init,
.exit   = omap_aes_gcm_cra_exit,
.maxauthsize= AES_BLOCK_SIZE,
-   .ivsize = 8,
+   .ivsize = GCM_RFC4106_IV_SIZE,
.setkey = omap_aes_4106gcm_setkey,
.encrypt= omap_aes_4106gcm_encrypt,
.decrypt= omap_aes_4106gcm_decrypt,
-- 
2.13.0

[PATCH 08/11] crypto: chelsio - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/chelsio/chcr_algo.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/chelsio/chcr_algo.c 
b/drivers/crypto/chelsio/chcr_algo.c
index 0e8160701833..936bdd895efa 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2534,9 +2535,9 @@ static struct sk_buff *create_gcm_wr(struct aead_request 
*req,
if (get_aead_subtype(tfm) ==
CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106) {
memcpy(reqctx->iv, aeadctx->salt, 4);
-   memcpy(reqctx->iv + 4, req->iv, 8);
+   memcpy(reqctx->iv + 4, req->iv, GCM_RFC4106_IV_SIZE);
} else {
-   memcpy(reqctx->iv, req->iv, 12);
+   memcpy(reqctx->iv, req->iv, GCM_AES_IV_SIZE);
}
*((unsigned int *)(reqctx->iv + 12)) = htonl(0x01);
 
@@ -3385,7 +3386,7 @@ static struct chcr_alg_template driver_algs[] = {
sizeof(struct chcr_aead_ctx) +
sizeof(struct chcr_gcm_ctx),
},
-   .ivsize = 12,
+   .ivsize = GCM_AES_IV_SIZE,
.maxauthsize = GHASH_DIGEST_SIZE,
.setkey = chcr_gcm_setkey,
.setauthsize = chcr_gcm_setauthsize,
@@ -3405,7 +3406,7 @@ static struct chcr_alg_template driver_algs[] = {
sizeof(struct chcr_gcm_ctx),
 
},
-   .ivsize = 8,
+   .ivsize = GCM_RFC4106_IV_SIZE,
.maxauthsize= GHASH_DIGEST_SIZE,
.setkey = chcr_gcm_setkey,
.setauthsize= chcr_4106_4309_setauthsize,
-- 
2.13.0

[PATCH 04/11] crypto: nx - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/nx/nx-aes-gcm.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/nx/nx-aes-gcm.c b/drivers/crypto/nx/nx-aes-gcm.c
index abd465f479c4..a810596b97c2 100644
--- a/drivers/crypto/nx/nx-aes-gcm.c
+++ b/drivers/crypto/nx/nx-aes-gcm.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -433,7 +434,7 @@ static int gcm_aes_nx_encrypt(struct aead_request *req)
struct nx_gcm_rctx *rctx = aead_request_ctx(req);
char *iv = rctx->iv;
 
-   memcpy(iv, req->iv, 12);
+   memcpy(iv, req->iv, GCM_AES_IV_SIZE);
 
return gcm_aes_nx_crypt(req, 1, req->assoclen);
 }
@@ -443,7 +444,7 @@ static int gcm_aes_nx_decrypt(struct aead_request *req)
struct nx_gcm_rctx *rctx = aead_request_ctx(req);
char *iv = rctx->iv;
 
-   memcpy(iv, req->iv, 12);
+   memcpy(iv, req->iv, GCM_AES_IV_SIZE);
 
return gcm_aes_nx_crypt(req, 0, req->assoclen);
 }
@@ -498,7 +499,7 @@ struct aead_alg nx_gcm_aes_alg = {
},
.init= nx_crypto_ctx_aes_gcm_init,
.exit= nx_crypto_ctx_aead_exit,
-   .ivsize  = 12,
+   .ivsize  = GCM_AES_IV_SIZE,
.maxauthsize = AES_BLOCK_SIZE,
.setkey  = gcm_aes_nx_set_key,
.encrypt = gcm_aes_nx_encrypt,
@@ -516,7 +517,7 @@ struct aead_alg nx_gcm4106_aes_alg = {
},
.init= nx_crypto_ctx_aes_gcm_init,
.exit= nx_crypto_ctx_aead_exit,
-   .ivsize  = 8,
+   .ivsize  = GCM_RFC4106_IV_SIZE,
.maxauthsize = AES_BLOCK_SIZE,
.setkey  = gcm4106_aes_nx_set_key,
.setauthsize = gcm4106_aes_nx_setauthsize,
-- 
2.13.0

[PATCH 07/11] crypto: mediatek - Use GCM IV size constant

[Corentin Labbe]

This patch replace GCM IV size value by their constant name.

Signed-off-by: Corentin Labbe 
---
 drivers/crypto/mediatek/mtk-aes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index 9e845e866dec..87e15b624f84 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include "mtk-platform.h"
 
 #define AES_QUEUE_SIZE 512
@@ -1098,7 +1099,7 @@ static struct aead_alg aes_gcm_alg = {
.decrypt= mtk_aes_gcm_decrypt,
.init   = mtk_aes_gcm_init,
.exit   = mtk_aes_gcm_exit,
-   .ivsize = 12,
+   .ivsize = GCM_AES_IV_SIZE,
.maxauthsize= AES_BLOCK_SIZE,
 
.base = {
-- 
2.13.0

Re: [PATCH] crypto: sahara: constify platform_device_id

[Herbert Xu]

On Sun, Aug 13, 2017 at 02:34:00PM +0530, Arvind Yadav wrote:
> platform_device_id are not supposed to change at runtime. All functions
> working with platform_device_id provided by 
> work with const platform_device_id. So mark the non-const structs as
> const.
> 
> Signed-off-by: Arvind Yadav 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 1/2] crypto/chacha20: fix handling of chunked input

[Herbert Xu]

On Mon, Aug 14, 2017 at 02:28:14PM +0100, Ard Biesheuvel wrote:
> Commit 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 versions
> to skcipher") ported the existing chacha20 code to use the new skcipher
> API, and introduced a bug along the way. Unfortunately, the tcrypt tests
> did not catch the error, and it was only found recently by Tobias.
> 
> Stefan kindly diagnosed the error, and proposed a fix which is similar
> to the one below, with the exception that 'walk.stride' is used rather
> than the hardcoded block size. This does not actually matter in this
> case, but it's a better example of how to use the skcipher walk API.
> 
> Fixes: 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 ...")
> Cc:  # v4.11+
> Cc: Steffen Klassert 
> Reported-by: Tobias Brunner 
> Signed-off-by: Ard Biesheuvel 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: rockchip: Don't dequeue the request when device is busy

[Herbert Xu]

On Tue, Aug 15, 2017 at 03:48:15PM +0800, zain wang wrote:
> The device can only process one request at a time. So if multiple
> requests came at the same time, we can enqueue them first, and
> dequeue them one by one when the device is idle.
> 
> Signed-off-by: zain wang 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: inside-secure - fix an error handling path in safexcel_probe()

[Herbert Xu]

On Tue, Aug 15, 2017 at 09:33:24PM +0200, Christophe JAILLET wrote:
> 'ret' is known to be 0 at this point.
> If 'safexcel_request_ring_irq()' fails, it returns an error code.
> Return this value instead of 0 which means success.
> 
> Signed-off-by: Christophe JAILLET 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: cavium/nitrox - Fix an error handling path in 'nitrox_probe()'

[Herbert Xu]

On Wed, Aug 16, 2017 at 07:16:06AM +0200, Christophe JAILLET wrote:
> 'err' is known to be 0 at this point.
> If 'kzalloc()' fails, returns -ENOMEM instead of 0 which means success.
> 
> Signed-off-by: Christophe JAILLET 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v4] crypto: only call put_page on referenced and used pages

[Herbert Xu]

On Wed, Aug 16, 2017 at 11:56:24AM +0200, Stephan Müller wrote:
> Hi Herbert,
> 
> This patch was created against the current Linus development tree.
> 
> The functional test was conducted at the time v3 was aired. The patch
> v4 is compile-tested.
> 
> Ciao
> Stephan
> 
> ---8<---
> For asynchronous operation, SGs are allocated without a page mapped to
> them or with a page that is not used (ref-counted). If the SGL is freed,
> the code must only call put_page for an SG if there was a page assigned
> and ref-counted in the first place.
> 
> This fixes a kernel crash when using io_submit with more than one iocb
> using the sendmsg and sendpage (vmsplice/splice) interface.
> 
> Signed-off-by: Stephan Mueller 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 2/2] crypto: testmgr - add chunked test cases for chacha20

[Herbert Xu]

On Mon, Aug 14, 2017 at 02:28:15PM +0100, Ard Biesheuvel wrote:
> We failed to catch a bug in the chacha20 code after porting it to the
> skcipher API. We would have caught it if any chunked tests had been
> defined, so define some now so we will catch future regressions.
> 
> Signed-off-by: Ard Biesheuvel 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: cavium - add release_firmware to all return case

[Herbert Xu]

On Mon, Aug 14, 2017 at 01:58:54PM +0200, Corentin Labbe wrote:
> Two return case misses to call release_firmware() and so leak some
> memory.
> 
> This patch create a fw_release label (and so a common error path)
> and use it on all return case.
> 
> Detected by CoverityScan, CID#1416422 ("Resource Leak")
> 
> Signed-off-by: Corentin Labbe 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: AF_ALG - get_page upon reassignment to TX SGL

[Herbert Xu]

On Thu, Aug 10, 2017 at 04:40:03PM +0200, Stephan Müller wrote:
> Hi Herbert,
> 
> The error can be triggered with the following test. Invoking that test
> in a while [ 1 ] loop shows that no memory is leaked.

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: algif_aead - fix comment regarding memory layout

[Herbert Xu]

On Wed, Aug 09, 2017 at 04:20:00PM +0200, Stephan Müller wrote:
> Signed-off-by: Stephan Mueller 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: MPI - kunmap after finishing accessing buffer

[Herbert Xu]

On Thu, Aug 10, 2017 at 08:06:18AM +0200, Stephan Müller wrote:
> Hi Herbert,
> 
> I found that issue while playing around with edge conditions in my
> algif_akcipher implementation. This issue only manifests in a
> segmentation violation on 32 bit machines and with an SGL where each
> SG points to one byte. SGLs with larger buffers seem to be not
> affected by this issue.
> 
> Yet this access-after-unmap should be a candidate for stable, IMHO.
> 
> ---8<---
> 
> Using sg_miter_start and sg_miter_next, the buffer of an SG is kmap'ed
> to *buff. The current code calls sg_miter_stop (and thus kunmap) on the
> SG entry before the last access of *buff.
> 
> The patch moves the sg_miter_stop call after the last access to *buff to
> ensure that the memory pointed to by *buff is still mapped.
> 
> Signed-off-by: Stephan Mueller 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v4 0/4] crypto: add driver for Axis ARTPEC crypto accelerator

[Herbert Xu]

On Thu, Aug 10, 2017 at 02:53:50PM +0200, Lars Persson wrote:
> This series adds a driver for the crypto accelerator in the ARTPEC series of
> SoCs from Axis Communications AB.
> 
> Changelog v4:
> - The skcipher conversion had a mistake where the algos were registered
>   instead of unregistered at module unloading.

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v1] crypto: mediatek - Add empty messages check in GCM mode

[Ryder Lee]

Currently, empty messages are not supported in GCM mode, hence add
a check to prevent producing incorrect results.

Signed-off-by: Ryder Lee 
---
changes since v1: 
- fix build erro: add a missing semicolon.

 drivers/crypto/mediatek/mtk-aes.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/crypto/mediatek/mtk-aes.c 
b/drivers/crypto/mediatek/mtk-aes.c
index 9e845e8..72e4549 100644
--- a/drivers/crypto/mediatek/mtk-aes.c
+++ b/drivers/crypto/mediatek/mtk-aes.c
@@ -928,8 +928,13 @@ static int mtk_aes_gcm_start(struct mtk_cryp *cryp, struct 
mtk_aes_rec *aes)
 static int mtk_aes_gcm_crypt(struct aead_request *req, u64 mode)
 {
struct mtk_aes_base_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
+   struct mtk_aes_gcm_ctx *gctx = mtk_aes_gcm_ctx_cast(ctx);
struct mtk_aes_reqctx *rctx = aead_request_ctx(req);
 
+   /* Empty messages are not supported yet */
+   if (!gctx->textlen && !req->assoclen)
+   return -EINVAL;
+
rctx->mode = AES_FLAGS_GCM | mode;
 
return mtk_aes_handle_queue(ctx->cryp, !!(mode & AES_FLAGS_ENCRYPT),
-- 
1.9.1

Re: [PATCH] crypto: mediatek - Add empty messages check in GCM mode

[Ryder Lee]

Hi,
On Tue, 2017-08-22 at 15:01 +0800, Herbert Xu wrote:
> On Wed, Aug 16, 2017 at 07:19:48PM +0800, Ryder Lee wrote:
> > Currently, empty messages are not supported in GCM mode, hence add
> > a check to prevent producing incorrect results.
> > 
> > Signed-off-by: Ryder Lee 
> > ---
> >  drivers/crypto/mediatek/mtk-aes.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/crypto/mediatek/mtk-aes.c 
> > b/drivers/crypto/mediatek/mtk-aes.c
> > index 9e845e8..efe4e63 100644
> > --- a/drivers/crypto/mediatek/mtk-aes.c
> > +++ b/drivers/crypto/mediatek/mtk-aes.c
> > @@ -928,8 +928,13 @@ static int mtk_aes_gcm_start(struct mtk_cryp *cryp, 
> > struct mtk_aes_rec *aes)
> >  static int mtk_aes_gcm_crypt(struct aead_request *req, u64 mode)
> >  {
> > struct mtk_aes_base_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
> > +   struct mtk_aes_gcm_ctx *gctx = mtk_aes_gcm_ctx_cast(ctx);
> > struct mtk_aes_reqctx *rctx = aead_request_ctx(req);
> >  
> > +   /* Empty messages are not supported yet */
> > +   if (!gctx->textlen && !req->assoclen)
> > +   return -EINVAL
> 
> Your patch does not compile.

Ohh..Somehow I delete the semicolon. I will send v1 soon, sorry about
that.

Ryder

Re: [PATCH] crypto: mediatek - Add empty messages check in GCM mode

[Herbert Xu]

On Wed, Aug 16, 2017 at 07:19:48PM +0800, Ryder Lee wrote:
> Currently, empty messages are not supported in GCM mode, hence add
> a check to prevent producing incorrect results.
> 
> Signed-off-by: Ryder Lee 
> ---
>  drivers/crypto/mediatek/mtk-aes.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/crypto/mediatek/mtk-aes.c 
> b/drivers/crypto/mediatek/mtk-aes.c
> index 9e845e8..efe4e63 100644
> --- a/drivers/crypto/mediatek/mtk-aes.c
> +++ b/drivers/crypto/mediatek/mtk-aes.c
> @@ -928,8 +928,13 @@ static int mtk_aes_gcm_start(struct mtk_cryp *cryp, 
> struct mtk_aes_rec *aes)
>  static int mtk_aes_gcm_crypt(struct aead_request *req, u64 mode)
>  {
>   struct mtk_aes_base_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
> + struct mtk_aes_gcm_ctx *gctx = mtk_aes_gcm_ctx_cast(ctx);
>   struct mtk_aes_reqctx *rctx = aead_request_ctx(req);
>  
> + /* Empty messages are not supported yet */
> + if (!gctx->textlen && !req->assoclen)
> + return -EINVAL

Your patch does not compile.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v4] crypto: only call put_page on referenced and used pages

[Herbert Xu]

On Wed, Aug 16, 2017 at 11:56:24AM +0200, Stephan Müller wrote:
> Hi Herbert,
> 
> This patch was created against the current Linus development tree.
> 
> The functional test was conducted at the time v3 was aired. The patch
> v4 is compile-tested.

Thanks!

Cc: 
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: MPI - kunmap after finishing accessing buffer

[Herbert Xu]

On Thu, Aug 10, 2017 at 08:06:18AM +0200, Stephan Müller wrote:
> Hi Herbert,
> 
> I found that issue while playing around with edge conditions in my
> algif_akcipher implementation. This issue only manifests in a
> segmentation violation on 32 bit machines and with an SGL where each
> SG points to one byte. SGLs with larger buffers seem to be not
> affected by this issue.
> 
> Yet this access-after-unmap should be a candidate for stable, IMHO.

Good catch.  Thanks!

Fixes: 4816c9406430 ("lib/mpi: Fix SG miter leak")
Cc: 
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt