Product Inquiry

[Julian Smith]

Hello, 

My name is Ms Julian Smith and i am from Sinara Group Co.
We are glad to know about your company from the web and we are interested in
your products.Please send us your Latest catalog and price list for our
trial order. 

Julian Smith, 
Purchasing Manager
Sinara Group Co.
7 Krasnogo Znameni Ave.
Vladivostok,690106,Ukraine

Re: [PATCH v2 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

[Brijesh Singh]

On 06/26/2017 04:17 PM, Tom Lendacky wrote:

+const struct ccp_vdata ccpv3_platform = {
+.version = CCP_VERSION(3, 0),
+.setup = NULL,
+.perform = _actions,
+.bar = 2,


Platform devices don't use BARs so should probably delete this (unless
you want to make it more generic and then use this value for the
IORESOURCE_MEM entry).



Yep, we don't need bar for platform device, it was copy paste from existing
ccpv3 structure. I will fix it in v3. thanks


+}
  #endif
+int ccp_dev_init(struct ccp_device *ccp)
+{
+if (ccp->vdata->setup)
+ccp->vdata->setup(ccp);
+
+ccp->io_regs = ccp->io_map + ccp->vdata->offset;


This should be before the above call to setup().



Good catch, actually the second patch takes care of it. But I agree with your
feedback, I will make sure that io_regs is set before invoking the setup() in
the first patch itself.


Thanks
Brijesh

Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64

[Logan Gunthorpe]

On 6/26/2017 2:43 PM, Arnd Bergmann wrote:

This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which
I find rather confusing, as only about one in five drivers wants this
behavior.

I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures,
but rather use the same logic that we have for readq/writeq in
io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h, adding
{lo_hi,hi_lo}_{ioread,iowrite}{,be} to the same files, and provide
the {ioread,iowrite}{,be} macros only if they have not been defined
at that point.


Thanks Arnd. Yes, I'm already reworking this patchset to do exactly that.

Logan

Re: [PATCH v2 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

[Tom Lendacky]

On 6/23/2017 11:06 AM, Brijesh Singh wrote:

Update pci and platform files to use devres interface to allocate the PCI
and iomap resources. Also add helper functions to consolicate module init,
exit and power mangagement code duplication.

Signed-off-by: Brijesh Singh 
---
  drivers/crypto/ccp/ccp-dev-v3.c   |   8 +++
  drivers/crypto/ccp/ccp-dev.c  |  61 
  drivers/crypto/ccp/ccp-dev.h  |   6 ++
  drivers/crypto/ccp/ccp-pci.c  | 114 +-
  drivers/crypto/ccp/ccp-platform.c |  56 ++-
  5 files changed, 107 insertions(+), 138 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 367c2e3..1cae5a3 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -586,6 +586,14 @@ static const struct ccp_actions ccp3_actions = {
.irqhandler = ccp_irq_handler,
  };
  
+const struct ccp_vdata ccpv3_platform = {

+   .version = CCP_VERSION(3, 0),
+   .setup = NULL,
+   .perform = _actions,
+   .bar = 2,


Platform devices don't use BARs so should probably delete this (unless
you want to make it more generic and then use this value for the
IORESOURCE_MEM entry).


+   .offset = 0,
+};
+
  const struct ccp_vdata ccpv3 = {
.version = CCP_VERSION(3, 0),
.setup = NULL,
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 2506b50..ce35e43 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -538,8 +538,69 @@ bool ccp_queues_suspended(struct ccp_device *ccp)
  
  	return ccp->cmd_q_count == suspended;

  }
+
+int ccp_dev_suspend(struct ccp_device *ccp, pm_message_t state)
+{
+   unsigned long flags;
+   unsigned int i;
+
+   spin_lock_irqsave(>cmd_lock, flags);
+
+   ccp->suspending = 1;
+
+   /* Wake all the queue kthreads to prepare for suspend */
+   for (i = 0; i < ccp->cmd_q_count; i++)
+   wake_up_process(ccp->cmd_q[i].kthread);
+
+   spin_unlock_irqrestore(>cmd_lock, flags);
+
+   /* Wait for all queue kthreads to say they're done */
+   while (!ccp_queues_suspended(ccp))
+   wait_event_interruptible(ccp->suspend_queue,
+ccp_queues_suspended(ccp));
+
+   return 0;
+}
+
+int ccp_dev_resume(struct ccp_device *ccp)
+{
+   unsigned long flags;
+   unsigned int i;
+
+   spin_lock_irqsave(>cmd_lock, flags);
+
+   ccp->suspending = 0;
+
+   /* Wake up all the kthreads */
+   for (i = 0; i < ccp->cmd_q_count; i++) {
+   ccp->cmd_q[i].suspended = 0;
+   wake_up_process(ccp->cmd_q[i].kthread);
+   }
+
+   spin_unlock_irqrestore(>cmd_lock, flags);
+
+   return 0;
+}
  #endif
  
+int ccp_dev_init(struct ccp_device *ccp)

+{
+   if (ccp->vdata->setup)
+   ccp->vdata->setup(ccp);
+
+   ccp->io_regs = ccp->io_map + ccp->vdata->offset;


This should be before the above call to setup().

Thanks,
Tom


+
+   return ccp->vdata->perform->init(ccp);
+}
+
+void ccp_dev_destroy(struct ccp_device *ccp)
+{
+   if (!ccp)
+   return;
+
+   ccp->vdata->perform->destroy(ccp);
+}
+
  static int __init ccp_mod_init(void)
  {
  #ifdef CONFIG_X86

Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64

[Arnd Bergmann]

> +u64 ioread64(void __iomem *addr)
> +{
> +   u64 low, high;
> +
> +   low = ioread32(addr);
> +   high = ioread32(addr + sizeof(u32));
> +   return low | (high << 32);
> +}
> +u64 ioread64be(void __iomem *addr)
> +{
> +   u64 low, high;
> +
> +   low = ioread32be(addr + sizeof(u32));
> +   high = ioread32be(addr);
> +   return low | (high << 32);
> +}
> +#endif

This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which
I find rather confusing, as only about one in five drivers wants this
behavior.

I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures,
but rather use the same logic that we have for readq/writeq in
io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h, adding
{lo_hi,hi_lo}_{ioread,iowrite}{,be} to the same files, and provide
the {ioread,iowrite}{,be} macros only if they have not been defined
at that point.

   Arnd

[PATCH] crypto: qat: fix spelling mistake: "runing" -> "running"

[Colin King]

From: Colin Ian King 

trivial fix to spelling mistake in dev_info message

Signed-off-by: Colin Ian King 
---
 drivers/crypto/qat/qat_common/adf_aer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/qat/qat_common/adf_aer.c 
b/drivers/crypto/qat/qat_common/adf_aer.c
index d3e25c37dc33..da8a2d3b5e9a 100644
--- a/drivers/crypto/qat/qat_common/adf_aer.c
+++ b/drivers/crypto/qat/qat_common/adf_aer.c
@@ -208,7 +208,7 @@ static pci_ers_result_t adf_slot_reset(struct pci_dev *pdev)
 static void adf_resume(struct pci_dev *pdev)
 {
dev_info(>dev, "Acceleration driver reset completed\n");
-   dev_info(>dev, "Device is up and runnig\n");
+   dev_info(>dev, "Device is up and running\n");
 }
 
 static const struct pci_error_handlers adf_err_handler = {
-- 
2.11.0

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

[Stephan Müller]

Am Montag, 26. Juni 2017, 03:23:09 CEST schrieb Nicholas A. Bellinger:

Hi Nicholas,

> Hi Stephan, Lee & Jason,
> 
> (Adding target-devel CC')
> 
> Apologies for coming late to the discussion.  Comments below.
> 
> On Sun, 2017-06-18 at 10:04 +0200, Stephan Müller wrote:
> > Am Samstag, 17. Juni 2017, 05:45:57 CEST schrieb Lee Duncan:
> > 
> > Hi Lee,
> > 
> > > In your testing, how long might a process have to wait? Are we talking
> > > seconds? Longer? What about timeouts?
> > 
> > In current kernels (starting with 4.8) this timeout should clear within a
> > few seconds after boot.
> > 
> > In older kernels (pre 4.8), my KVM takes up to 90 seconds to reach that
> > seeding point. I have heard that on IBM System Z this trigger point
> > requires minutes to be reached.
> 
> I share the same concern as Lee wrt to introducing latency into the
> existing iscsi-target login sequence.
> 
> Namely in the use-cases where a single node is supporting ~1K unique
> iscsi-target IQNs, and fail-over + re-balancing of IQNs where 100s of
> login attempts are expected to occur in parallel.
> 
> If environments exist that require non trivial amounts of time for RNG
> seeding to be ready for iscsi-target usage, then enforcing this
> requirement at iscsi login time can open up problems, especially when
> iscsi host environments may be sensitive to login timeouts, I/O
> timeouts, et al.
> 
> That said, I'd prefer to simply wait for RNG to be seeded at modprobe
> iscsi_target_mod time, instead of trying to enforce randomness during
> login.
> 
> This way, those of use who have distributed storage platforms can know
> to avoid putting a node into a state to accept iscsi-target IQN export
> migration, before modprobe iscsi_target_mod has successfully loaded and
> RNG seeding has been confirmed.
> 
> WDYT..?

We may have a chicken and egg problem when the wait is at the modprobe time. 
Assume the modprobe happens during initramfs time to get access to the root 
file system. In this case, you entire boot process will lock up for an 
indefinite amount of time. The reason is that in order to obtain events 
detected by the RNG, devices need to be initialized and working. Such devices 
commonly start working after the the root partition is mounted as it contains 
all drivers, all configuration information etc.

Note, during the development of my /dev/random implementation, I added the 
getrandom-like blocking behavior to /dev/urandom (which is the equivalent to 
Jason's patch except that it applies to user space). The boot process locked 
up since systemd wanted data from /dev/urandom while it processed the 
initramfs. As it did not get any, the boot process did not commence that could 
deliver new events to be picked up by the RNG.

As I do not have such an iscsi system, I cannot test Jason's patch. But maybe 
the mentioned chicken-and-egg problem I mentioned above is already visible 
with the current patch as it will lead to a blocking of the mounting of the 
root partition in case the root partition is on an iscsi target.

Ciao
Stephan

Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64

[Logan Gunthorpe]

Hi Jyri,

Thanks for the ack. However, I'm reworking this patch set to use the
include/linux/io-64-nonatomic* headers which will explicitly devolve
into two 32-bit transfers. It's not clear whether this is appropriate
for the tilcdc driver as it was never setup to use 32-bit transfers
(unlike the others I had patched).

If you think it's ok, I can still patch this driver to use the
non-atomic headers. Otherwise I can leave it out. Please let me know.

Thanks,

Logan


On 26/06/17 02:55 AM, Jyri Sarha wrote:
> Acked-by: Jyri Sarha 
> 
> And thanks!
> 
>> ---
>>  drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 --
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
>> b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
>> index e9ce725698a9..0b901405f30a 100644
>> --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
>> @@ -133,13 +133,7 @@ static inline void tilcdc_write64(struct drm_device 
>> *dev, u32 reg, u64 data)
>>  struct tilcdc_drm_private *priv = dev->dev_private;
>>  void __iomem *addr = priv->mmio + reg;
>>  
>> -#ifdef iowrite64
>>  iowrite64(data, addr);
>> -#else
>> -__iowmb();
>> -/* This compiles to strd (=64-bit write) on ARM7 */
>> -*(u64 __force *)addr = __cpu_to_le64(data);
>> -#endif
>>  }
>>  
>>  static inline u32 tilcdc_read(struct drm_device *dev, u32 reg)
>>
> 

Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure

[Levin, Alexander (Sasha Levin)]

On Mon, Jun 26, 2017 at 07:30:19AM -0700, Dave Watson wrote:
>On 06/25/17 02:42 AM, Levin, Alexander (Sasha Levin) wrote:
>> On Wed, Jun 14, 2017 at 11:37:14AM -0700, Dave Watson wrote:
>> >Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP
>> >sockets. Based on a similar infrastructure in tcp_cong.  The idea is that 
>> >any
>> >ULP can add its own logic by changing the TCP proto_ops structure to its own
>> >methods.
>> >
>> >Example usage:
>> >
>> >setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
>> >
>> >modules will call:
>> >tcp_register_ulp(_tls_ulp_ops);
>> >
>> >to register/unregister their ulp, with an init function and name.
>> >
>> >A list of registered ulps will be returned by tcp_get_available_ulp, which 
>> >is
>> >hooked up to /proc.  Example:
>> >
>> >$ cat /proc/sys/net/ipv4/tcp_available_ulp
>> >tls
>> >
>> >There is currently no functionality to remove or chain ULPs, but
>> >it should be possible to add these in the future if needed.
>> >
>> >Signed-off-by: Boris Pismenny 
>> >Signed-off-by: Dave Watson 
>>
>> Hey Dave,
>>
>> I'm seeing the following while fuzzing, which was bisected to this commit:
>>
>> ==
>> BUG: KASAN: null-ptr-deref in copy_to_user include/linux/uaccess.h:168 
>> [inline]
>> BUG: KASAN: null-ptr-deref in do_tcp_getsockopt.isra.33+0x24f/0x1e30 
>> net/ipv4/tcp.c:3057
>> Read of size 4 at addr 0020 by task syz-executor1/15452
>
>At a glance, this looks like it was fixed already by
>
>https://www.mail-archive.com/netdev@vger.kernel.org/msg175226.html
>
>Can you recheck with that patch, or verify that you already have it?
>Thanks.

I've already tried this patch, it doesn't fix the issue I've reported.

-- 

Thanks,
Sasha

Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure

[Dave Watson]

On 06/25/17 02:42 AM, Levin, Alexander (Sasha Levin) wrote:
> On Wed, Jun 14, 2017 at 11:37:14AM -0700, Dave Watson wrote:
> >Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP
> >sockets. Based on a similar infrastructure in tcp_cong.  The idea is that any
> >ULP can add its own logic by changing the TCP proto_ops structure to its own
> >methods.
> >
> >Example usage:
> >
> >setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
> >
> >modules will call:
> >tcp_register_ulp(_tls_ulp_ops);
> >
> >to register/unregister their ulp, with an init function and name.
> >
> >A list of registered ulps will be returned by tcp_get_available_ulp, which is
> >hooked up to /proc.  Example:
> >
> >$ cat /proc/sys/net/ipv4/tcp_available_ulp
> >tls
> >
> >There is currently no functionality to remove or chain ULPs, but
> >it should be possible to add these in the future if needed.
> >
> >Signed-off-by: Boris Pismenny 
> >Signed-off-by: Dave Watson 
> 
> Hey Dave,
> 
> I'm seeing the following while fuzzing, which was bisected to this commit:
> 
> ==
> BUG: KASAN: null-ptr-deref in copy_to_user include/linux/uaccess.h:168 
> [inline]
> BUG: KASAN: null-ptr-deref in do_tcp_getsockopt.isra.33+0x24f/0x1e30 
> net/ipv4/tcp.c:3057
> Read of size 4 at addr 0020 by task syz-executor1/15452

At a glance, this looks like it was fixed already by

https://www.mail-archive.com/netdev@vger.kernel.org/msg175226.html

Can you recheck with that patch, or verify that you already have it?
Thanks.

Re: [PATCH v4] crypto: sun4i-ss: support the Security System PRNG

[Frans Klaver]

Hi,

On Mon, Jun 26, 2017 at 2:20 PM, Corentin Labbe
 wrote:
> The Security System have a PRNG, this patch add support for it via
> crypto_rng.

s,have,has,
s,add,adds,

>
> Signed-off-by: Corentin Labbe 
> ---
>
> Changes since v3 (note: the v3 miss changes and version tag sorry)
> - Replaced all len values with bits / BITS_PER_LONG or BITS_PER_BYTE
>
> Changes since v2
>  - converted to crypto_rng
>
> Changes since v1:
>  - Replaced all spin_lock_bh by simple spin_lock
>  - Removed handling of size not modulo 4 which will never happen
>  - Added add_random_ready_callback()
>
>  drivers/crypto/Kconfig  |  8 +
>  drivers/crypto/sunxi-ss/Makefile|  1 +
>  drivers/crypto/sunxi-ss/sun4i-ss-core.c | 30 ++
>  drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 56 
> +
>  drivers/crypto/sunxi-ss/sun4i-ss.h  | 11 +++
>  5 files changed, 106 insertions(+)
>  create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-prng.c
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index ab82536d64e2..bde0b102eb70 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -618,6 +618,14 @@ config CRYPTO_DEV_SUN4I_SS
>   To compile this driver as a module, choose M here: the module
>   will be called sun4i-ss.
>
> +config CRYPTO_DEV_SUN4I_SS_PRNG
> +   bool "Support for Allwinner Security System PRNG"
> +   depends on CRYPTO_DEV_SUN4I_SS
> +   select CRYPTO_RNG
> +   help
> + Select this option if you to provides kernel-side support for
> + the Pseudo-Random Number Generator found in the Security System.

This sentence does not parse. "Select this option if you want to
provide kernel-side for ...". Alternatively: "This option enables
kernel-side support for ..."

Frans

[PATCH v4] crypto: sun4i-ss: support the Security System PRNG

[Corentin Labbe]

The Security System have a PRNG, this patch add support for it via
crypto_rng.

Signed-off-by: Corentin Labbe 
---

Changes since v3 (note: the v3 miss changes and version tag sorry)
- Replaced all len values with bits / BITS_PER_LONG or BITS_PER_BYTE

Changes since v2
 - converted to crypto_rng

Changes since v1:
 - Replaced all spin_lock_bh by simple spin_lock
 - Removed handling of size not modulo 4 which will never happen
 - Added add_random_ready_callback()

 drivers/crypto/Kconfig  |  8 +
 drivers/crypto/sunxi-ss/Makefile|  1 +
 drivers/crypto/sunxi-ss/sun4i-ss-core.c | 30 ++
 drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 56 +
 drivers/crypto/sunxi-ss/sun4i-ss.h  | 11 +++
 5 files changed, 106 insertions(+)
 create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-prng.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index ab82536d64e2..bde0b102eb70 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -618,6 +618,14 @@ config CRYPTO_DEV_SUN4I_SS
  To compile this driver as a module, choose M here: the module
  will be called sun4i-ss.
 
+config CRYPTO_DEV_SUN4I_SS_PRNG
+   bool "Support for Allwinner Security System PRNG"
+   depends on CRYPTO_DEV_SUN4I_SS
+   select CRYPTO_RNG
+   help
+ Select this option if you to provides kernel-side support for
+ the Pseudo-Random Number Generator found in the Security System.
+
 config CRYPTO_DEV_ROCKCHIP
tristate "Rockchip's Cryptographic Engine driver"
depends on OF && ARCH_ROCKCHIP
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
index 8f4c7a273141..ccb893219079 100644
--- a/drivers/crypto/sunxi-ss/Makefile
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
 sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
+sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-prng.o
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 02ad8256e900..1547cbe13dc2 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -213,6 +213,23 @@ static struct sun4i_ss_alg_template ss_algs[] = {
}
}
 },
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+{
+   .type = CRYPTO_ALG_TYPE_RNG,
+   .alg.rng = {
+   .base = {
+   .cra_name   = "stdrng",
+   .cra_driver_name= "sun4i_ss_rng",
+   .cra_priority   = 300,
+   .cra_ctxsize= 0,
+   .cra_module = THIS_MODULE,
+   },
+   .generate   = sun4i_ss_prng_generate,
+   .seed   = sun4i_ss_prng_seed,
+   .seedsize   = SS_SEED_LEN / BITS_PER_BYTE,
+   }
+},
+#endif
 };
 
 static int sun4i_ss_probe(struct platform_device *pdev)
@@ -355,6 +372,13 @@ static int sun4i_ss_probe(struct platform_device *pdev)
goto error_alg;
}
break;
+   case CRYPTO_ALG_TYPE_RNG:
+   err = crypto_register_rng(_algs[i].alg.rng);
+   if (err) {
+   dev_err(ss->dev, "Fail to register %s\n",
+   ss_algs[i].alg.rng.base.cra_name);
+   }
+   break;
}
}
platform_set_drvdata(pdev, ss);
@@ -369,6 +393,9 @@ static int sun4i_ss_probe(struct platform_device *pdev)
case CRYPTO_ALG_TYPE_AHASH:
crypto_unregister_ahash(_algs[i].alg.hash);
break;
+   case CRYPTO_ALG_TYPE_RNG:
+   crypto_unregister_rng(_algs[i].alg.rng);
+   break;
}
}
if (ss->reset)
@@ -393,6 +420,9 @@ static int sun4i_ss_remove(struct platform_device *pdev)
case CRYPTO_ALG_TYPE_AHASH:
crypto_unregister_ahash(_algs[i].alg.hash);
break;
+   case CRYPTO_ALG_TYPE_RNG:
+   crypto_unregister_rng(_algs[i].alg.rng);
+   break;
}
}
 
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-prng.c 
b/drivers/crypto/sunxi-ss/sun4i-ss-prng.c
new file mode 100644
index ..0d01d1624252
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-prng.c
@@ -0,0 +1,56 @@
+#include "sun4i-ss.h"
+
+int sun4i_ss_prng_seed(struct crypto_rng *tfm, const u8 *seed,
+  unsigned int slen)
+{
+   struct sun4i_ss_alg_template *algt;
+   struct rng_alg *alg = crypto_rng_alg(tfm);
+
+   algt = container_of(alg, struct 

Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64

[Jyri Sarha]

On 06/22/17 19:48, Logan Gunthorpe wrote:
> Now that we can expect iowrite64 to always exist the hack is no longer
> necessary so we just call iowrite64 directly.
> 
> Signed-off-by: Logan Gunthorpe 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Cc: David Airlie 

Acked-by: Jyri Sarha 

And thanks!

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
> b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> index e9ce725698a9..0b901405f30a 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> @@ -133,13 +133,7 @@ static inline void tilcdc_write64(struct drm_device 
> *dev, u32 reg, u64 data)
>   struct tilcdc_drm_private *priv = dev->dev_private;
>   void __iomem *addr = priv->mmio + reg;
>  
> -#ifdef iowrite64
>   iowrite64(data, addr);
> -#else
> - __iowmb();
> - /* This compiles to strd (=64-bit write) on ARM7 */
> - *(u64 __force *)addr = __cpu_to_le64(data);
> -#endif
>  }
>  
>  static inline u32 tilcdc_read(struct drm_device *dev, u32 reg)
> 

Re: [PATCH 1/7] drm/tilcdc: don't use volatile with iowrite64

[Jyri Sarha]

On 06/22/17 19:48, Logan Gunthorpe wrote:
> This is a prep patch for adding a universal iowrite64.
> 
> The patch is to prevent compiler warnings when we add iowrite64 that
> would occur because there is an unnecessary volatile in this driver.
> 
> Signed-off-by: Logan Gunthorpe 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Cc: David Airlie 

Acked-by: Jyri Sarha 

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_regs.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
> b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> index 9d528c0a67a4..e9ce725698a9 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> @@ -131,14 +131,14 @@ static inline void tilcdc_write(struct drm_device *dev, 
> u32 reg, u32 data)
>  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;
> + void __iomem *addr = priv->mmio + reg;
>  
>  #ifdef iowrite64
>   iowrite64(data, addr);
>  #else
>   __iowmb();
>   /* This compiles to strd (=64-bit write) on ARM7 */
> - *(volatile u64 __force *)addr = __cpu_to_le64(data);
> + *(u64 __force *)addr = __cpu_to_le64(data);
>  #endif
>  }
>  
> 

Re: [PATCH] crypto: qat - avoid an uninitialized variable warning

[Christoph Hellwig]

Thanks Arnd,

added to the dma-mapping tree.

Re: [RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt

[Herbert Xu]

On Mon, Jun 26, 2017 at 07:40:58AM +0200, David Gstir wrote:
>
> So, am I correct in assuming that it is required for all modes including AEAD 
> modes like GCM?
> In that case I'll include a fix for the CAAM GCM mode too.

It's only required for skcihper.  As we do not do chunking/streaming
with our AEAD interface it is not required for GCM.
  
Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt