* Re: [PATCH 00/12] crypto: caam - fixes
From: Herbert Xu @ 2017-02-15 5:33 UTC (permalink / raw)
To: Horia Geantă
Cc: David S. Miller, Dan Douglass, Tudor Ambarus, Cristian Stoica,
linux-crypto
In-Reply-To: <1486728445-13047-1-git-send-email-horia.geanta@nxp.com>
On Fri, Feb 10, 2017 at 02:07:13PM +0200, Horia Geantă wrote:
> This batch consists mostly of DMA API related fixes and simplifications.
>
> Since no no arch calls:
> dma_debug_add_bus(&platform_bus_type);
> DMA API debugging does not have the chance to report leaks when modules
> are removed.
>
> I am not sure why dma_debug_add_bus() is not used for the platform bus,
> however when I did that for testing purposes, I could notice quite a few
> problems in caam driver.
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/2] crypto: ccm - honour alignmask of subordinate MAC cipher
From: Herbert Xu @ 2017-02-15 5:34 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1486841122-1686-1-git-send-email-ard.biesheuvel@linaro.org>
On Sat, Feb 11, 2017 at 07:25:21PM +0000, Ard Biesheuvel wrote:
> The CCM driver was recently updated to defer the MAC part of the algorithm
> to a dedicated crypto transform, and a template for instantiating such
> transforms was added at the same time.
>
> However, this new cbcmac template fails to take the alignmask of the
> encapsulated cipher into account, which may result in buffer addresses
> being passed down that are not sufficiently aligned.
>
> So update the code to ensure that the digest buffer in the desc ctx
> appears at a sufficiently aligned offset, and tweak the code so that all
> calls to crypto_cipher_encrypt_one() operate on this buffer exclusively.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] crypto: ccm - drop unnecessary minimum 32-bit alignment
From: Herbert Xu @ 2017-02-15 5:34 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1486841122-1686-2-git-send-email-ard.biesheuvel@linaro.org>
On Sat, Feb 11, 2017 at 07:25:22PM +0000, Ard Biesheuvel wrote:
> The CCM driver forces 32-bit alignment even if the underlying ciphers
> don't care about alignment. This is because crypto_xor() used to require
> this, but since this is no longer the case, drop the hardcoded minimum
> of 32 bits.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hw_random: update help description for omap-rng
From: Herbert Xu @ 2017-02-15 5:34 UTC (permalink / raw)
To: Russell King; +Cc: Romain Perier, Matt Mackall, linux-crypto
In-Reply-To: <E1cdFMW-0004yZ-OB@rmk-PC.armlinux.org.uk>
On Mon, Feb 13, 2017 at 12:04:08PM +0000, Russell King wrote:
> omap-rng also supports Marvell Armada 7k/8k SoCs, but no mention of this
> is made in the help text, despite the dependency being added. Explicitly
> mention these SoCs in the help description so people know that it covers
> more than just TI SoCs.
>
> Fixes: 383212425c92 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K")
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: fix typo in doc
From: Herbert Xu @ 2017-02-15 5:34 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: dm-devel, Jonathan Corbet, linux-crypto, linux-doc,
gilad.benyossef
In-Reply-To: <1487053305-1790-1-git-send-email-gilad@benyossef.com>
On Tue, Feb 14, 2017 at 08:21:45AM +0200, Gilad Ben-Yossef wrote:
> Fix a single letter typo in api-skcipher.rst.
>
> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] drivers: crypto: cpt: cpt_bind_vq_to_grp could return an error code
From: Herbert Xu @ 2017-02-15 5:35 UTC (permalink / raw)
To: George Cherian; +Cc: davem, dan.carpenter, linux-kernel, linux-crypto
In-Reply-To: <1487064197-1659-1-git-send-email-george.cherian@cavium.com>
On Tue, Feb 14, 2017 at 09:23:17AM +0000, George Cherian wrote:
> cpt_bind_vq_to_grp() could return an error code. However, it currently
> returns a u8. This produce the static checker warning.
>
> drivers/crypto/cavium/cpt/cptpf_mbox.c:70 cpt_bind_vq_to_grp() warn: signedness bug returning '(-22)'
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: George Cherian <george.cherian@cavium.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: cavium: fix Kconfig dependencies
From: Herbert Xu @ 2017-02-15 5:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: George Cherian, David S. Miller, David Daney, linux-crypto,
linux-kernel
In-Reply-To: <20170214170739.2687818-1-arnd@arndb.de>
On Tue, Feb 14, 2017 at 06:07:31PM +0100, Arnd Bergmann wrote:
> The driver fails to build if MSI support is disabled:
>
> In file included from /git/arm-soc/drivers/crypto/cavium/cpt/cptpf_main.c:18:0:
> drivers/crypto/cavium/cpt/cptpf.h:57:20: error: array type has incomplete element type 'struct msix_entry'
> struct msix_entry msix_entries[CPT_PF_MSIX_VECTORS];
> ^~~~~~~~~~~~
> drivers/crypto/cavium/cpt/cptpf_main.c: In function 'cpt_enable_msix':
> drivers/crypto/cavium/cpt/cptpf_main.c:344:8: error: implicit declaration of function 'pci_enable_msix';did you mean 'cpt_enable_msix'? [-Werror=implicit-function-declaration]
>
> On the other hand, it doesn't seem to have any build dependency on ARCH_THUNDER,
> so let's allow compile-testing to catch this kind of problem more easily.
> The 64-bit dependency is needed for the use of readq/writeq.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/1] crypto: brcm - Avoid double free in ahash_finup()
From: Herbert Xu @ 2017-02-15 5:35 UTC (permalink / raw)
To: Rob Rice
Cc: David S. Miller, Dan Carpenter, linux-crypto, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <1487094352-2016-1-git-send-email-rob.rice@broadcom.com>
On Tue, Feb 14, 2017 at 12:45:52PM -0500, Rob Rice wrote:
> In Broadcom SPU driver, in case where incremental hash
> is done in software in ahash_finup(), tmpbuf was freed
> twice.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Rob Rice <rob.rice@broadcom.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v4 3/4] dmaengine: Add Broadcom SBA RAID driver
From: Anup Patel @ 2017-02-15 6:25 UTC (permalink / raw)
To: Dan Williams
Cc: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar, Ray Jui, Scott Branden, Jon Mason,
Rob Rice, BCM Kernel Feedback,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Device Tree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, linux-raid
In-Reply-To: <CAPcyv4g5PU1EQWq-SCbt0QB=vSaMyafqa-ThJifDxEoQha-6Hw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Feb 14, 2017 at 10:04 PM, Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Feb 13, 2017 at 10:51 PM, Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>> The Broadcom stream buffer accelerator (SBA) provides offloading
>> capabilities for RAID operations. This SBA offload engine is
>> accessible via Broadcom SoC specific ring manager.
>>
>> This patch adds Broadcom SBA RAID driver which provides one
>> DMA device with RAID capabilities using one or more Broadcom
>> SoC specific ring manager channels. The SBA RAID driver in its
>> current shape implements memcpy, xor, and pq operations.
>>
>> Signed-off-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> ---
>> drivers/dma/Kconfig | 13 +
>> drivers/dma/Makefile | 1 +
>> drivers/dma/bcm-sba-raid.c | 1694 ++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 1708 insertions(+)
>> create mode 100644 drivers/dma/bcm-sba-raid.c
>>
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index 263495d..bf8fb84 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -99,6 +99,19 @@ config AXI_DMAC
>> controller is often used in Analog Device's reference designs for FPGA
>> platforms.
>>
>> +config BCM_SBA_RAID
>> + tristate "Broadcom SBA RAID engine support"
>> + depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
>> + select DMA_ENGINE
>> + select DMA_ENGINE_RAID
>> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>
> I thought you agreed to drop this. Its usage is broken.
If ASYNC_TX_ENABLE_CHANNEL_SWITCH is not selected
then async_dma_find_channel() will only try to find channel
with DMA_ASYNC_TX capability.
The DMA_ASYNC_TX capability is set by
dma_async_device_register() when all Async Tx
capabilities are supported by a DMA devices namely
DMA_INTERRUPT, DMA_MEMCPY, DMA_XOR,
DMA_XOR_VAL, DMA_PQ, and DMA_PQ_VAL.
We only support DMA_MEMCPY, DMA_XOR, and
DMA_PQ capabilities in BCM-SBA-RAID driver so
DMA_ASYNC_TX capability is never set for the
DMA device registered by BCM-SBA-RAID driver.
Due to above, if ASYNC_TX_ENABLE_CHANNEL_SWITCH
is not selected then Async Tx APIs fail to find DMA
channel provided by BCM-SBA-RAID hence the
option ASYNC_TX_ENABLE_CHANNEL_SWITCH is
required for BCM-SBA-RAID.
The DMA mappings are violated by channel switching
only if we switch form DMA channel A to DMA channel
B and both these DMA channels have different underlying
"struct device". In most of the cases DMA mappings
are not violated because DMA channels having
Async Tx capabilities are provided using same
underlying "struct device".
Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 3/4] dmaengine: Add Broadcom SBA RAID driver
From: Dan Williams @ 2017-02-15 6:43 UTC (permalink / raw)
To: Anup Patel
Cc: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar, Ray Jui, Scott Branden, Jon Mason,
Rob Rice, BCM Kernel Feedback,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Device Tree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, linux-raid
In-Reply-To: <CAALAos_=TN_ZfeJbRQEwuc+t5zaxKVgrgEMNPQQu8K8Q8+8F6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Feb 14, 2017 at 10:25 PM, Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On Tue, Feb 14, 2017 at 10:04 PM, Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> On Mon, Feb 13, 2017 at 10:51 PM, Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>> The Broadcom stream buffer accelerator (SBA) provides offloading
>>> capabilities for RAID operations. This SBA offload engine is
>>> accessible via Broadcom SoC specific ring manager.
>>>
>>> This patch adds Broadcom SBA RAID driver which provides one
>>> DMA device with RAID capabilities using one or more Broadcom
>>> SoC specific ring manager channels. The SBA RAID driver in its
>>> current shape implements memcpy, xor, and pq operations.
>>>
>>> Signed-off-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>> Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>> ---
>>> drivers/dma/Kconfig | 13 +
>>> drivers/dma/Makefile | 1 +
>>> drivers/dma/bcm-sba-raid.c | 1694 ++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 1708 insertions(+)
>>> create mode 100644 drivers/dma/bcm-sba-raid.c
>>>
>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>> index 263495d..bf8fb84 100644
>>> --- a/drivers/dma/Kconfig
>>> +++ b/drivers/dma/Kconfig
>>> @@ -99,6 +99,19 @@ config AXI_DMAC
>>> controller is often used in Analog Device's reference designs for FPGA
>>> platforms.
>>>
>>> +config BCM_SBA_RAID
>>> + tristate "Broadcom SBA RAID engine support"
>>> + depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
>>> + select DMA_ENGINE
>>> + select DMA_ENGINE_RAID
>>> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>
>> I thought you agreed to drop this. Its usage is broken.
>
> If ASYNC_TX_ENABLE_CHANNEL_SWITCH is not selected
> then async_dma_find_channel() will only try to find channel
> with DMA_ASYNC_TX capability.
>
> The DMA_ASYNC_TX capability is set by
> dma_async_device_register() when all Async Tx
> capabilities are supported by a DMA devices namely
> DMA_INTERRUPT, DMA_MEMCPY, DMA_XOR,
> DMA_XOR_VAL, DMA_PQ, and DMA_PQ_VAL.
>
> We only support DMA_MEMCPY, DMA_XOR, and
> DMA_PQ capabilities in BCM-SBA-RAID driver so
> DMA_ASYNC_TX capability is never set for the
> DMA device registered by BCM-SBA-RAID driver.
>
> Due to above, if ASYNC_TX_ENABLE_CHANNEL_SWITCH
> is not selected then Async Tx APIs fail to find DMA
> channel provided by BCM-SBA-RAID hence the
> option ASYNC_TX_ENABLE_CHANNEL_SWITCH is
> required for BCM-SBA-RAID.
>
> The DMA mappings are violated by channel switching
> only if we switch form DMA channel A to DMA channel
> B and both these DMA channels have different underlying
> "struct device". In most of the cases DMA mappings
> are not violated because DMA channels having
> Async Tx capabilities are provided using same
> underlying "struct device".
No, fix the infrastructure. Do not put local hack in your driver for
this global problem [1].
[1]: https://lwn.net/Articles/443531/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 3/4] dmaengine: Add Broadcom SBA RAID driver
From: Anup Patel @ 2017-02-15 7:03 UTC (permalink / raw)
To: Dan Williams
Cc: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar, Ray Jui, Scott Branden, Jon Mason,
Rob Rice, BCM Kernel Feedback, dmaengine@vger.kernel.org,
Device Tree, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-crypto, linux-raid
In-Reply-To: <CAPcyv4jckb=sbocr3W43NZ2YyUVLbDdhbCAhLfgQwh-bRuvjYQ@mail.gmail.com>
On Wed, Feb 15, 2017 at 12:13 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Feb 14, 2017 at 10:25 PM, Anup Patel <anup.patel@broadcom.com> wrote:
>> On Tue, Feb 14, 2017 at 10:04 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>>> On Mon, Feb 13, 2017 at 10:51 PM, Anup Patel <anup.patel@broadcom.com> wrote:
>>>> The Broadcom stream buffer accelerator (SBA) provides offloading
>>>> capabilities for RAID operations. This SBA offload engine is
>>>> accessible via Broadcom SoC specific ring manager.
>>>>
>>>> This patch adds Broadcom SBA RAID driver which provides one
>>>> DMA device with RAID capabilities using one or more Broadcom
>>>> SoC specific ring manager channels. The SBA RAID driver in its
>>>> current shape implements memcpy, xor, and pq operations.
>>>>
>>>> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
>>>> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
>>>> ---
>>>> drivers/dma/Kconfig | 13 +
>>>> drivers/dma/Makefile | 1 +
>>>> drivers/dma/bcm-sba-raid.c | 1694 ++++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 1708 insertions(+)
>>>> create mode 100644 drivers/dma/bcm-sba-raid.c
>>>>
>>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>>> index 263495d..bf8fb84 100644
>>>> --- a/drivers/dma/Kconfig
>>>> +++ b/drivers/dma/Kconfig
>>>> @@ -99,6 +99,19 @@ config AXI_DMAC
>>>> controller is often used in Analog Device's reference designs for FPGA
>>>> platforms.
>>>>
>>>> +config BCM_SBA_RAID
>>>> + tristate "Broadcom SBA RAID engine support"
>>>> + depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
>>>> + select DMA_ENGINE
>>>> + select DMA_ENGINE_RAID
>>>> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>>
>>> I thought you agreed to drop this. Its usage is broken.
>>
>> If ASYNC_TX_ENABLE_CHANNEL_SWITCH is not selected
>> then async_dma_find_channel() will only try to find channel
>> with DMA_ASYNC_TX capability.
>>
>> The DMA_ASYNC_TX capability is set by
>> dma_async_device_register() when all Async Tx
>> capabilities are supported by a DMA devices namely
>> DMA_INTERRUPT, DMA_MEMCPY, DMA_XOR,
>> DMA_XOR_VAL, DMA_PQ, and DMA_PQ_VAL.
>>
>> We only support DMA_MEMCPY, DMA_XOR, and
>> DMA_PQ capabilities in BCM-SBA-RAID driver so
>> DMA_ASYNC_TX capability is never set for the
>> DMA device registered by BCM-SBA-RAID driver.
>>
>> Due to above, if ASYNC_TX_ENABLE_CHANNEL_SWITCH
>> is not selected then Async Tx APIs fail to find DMA
>> channel provided by BCM-SBA-RAID hence the
>> option ASYNC_TX_ENABLE_CHANNEL_SWITCH is
>> required for BCM-SBA-RAID.
>>
>> The DMA mappings are violated by channel switching
>> only if we switch form DMA channel A to DMA channel
>> B and both these DMA channels have different underlying
>> "struct device". In most of the cases DMA mappings
>> are not violated because DMA channels having
>> Async Tx capabilities are provided using same
>> underlying "struct device".
>
> No, fix the infrastructure. Do not put local hack in your driver for
> this global problem [1].
There is no hack in the driver. We need
ASYNC_TX_ENABLE_CHANNEL_SWITCH
based on current state of dmaengine framework.
The framework should be fixed as separate patchset.
We have other RAID drivers such as xgene-dma and
mv_xor_v2 who also require
ASYNC_TX_ENABLE_CHANNEL_SWITCH due
to same reason.
Fixing the framework and improving framework is
a ongoing process. I don't see why that should
stop this patchset.
Regards,
Anup
^ permalink raw reply
* [PATCH 1/3] crypto: cavium: remove dead MSI-X related define
From: Christoph Hellwig @ 2017-02-15 7:18 UTC (permalink / raw)
To: George Cherian; +Cc: David Daney, Herbert Xu, linux-crypto, linux-kernel
In-Reply-To: <20170215071843.30108-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/crypto/cavium/cpt/cpt_common.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/crypto/cavium/cpt/cpt_common.h b/drivers/crypto/cavium/cpt/cpt_common.h
index ede612f306d3..225078d03773 100644
--- a/drivers/crypto/cavium/cpt/cpt_common.h
+++ b/drivers/crypto/cavium/cpt/cpt_common.h
@@ -20,12 +20,10 @@
#define CPT_81XX_PCI_VF_DEVICE_ID 0xa041
/* flags to indicate the features supported */
-#define CPT_FLAG_MSIX_ENABLED BIT(0)
#define CPT_FLAG_SRIOV_ENABLED BIT(1)
#define CPT_FLAG_VF_DRIVER BIT(2)
#define CPT_FLAG_DEVICE_READY BIT(3)
-#define cpt_msix_enabled(cpt) ((cpt)->flags & CPT_FLAG_MSIX_ENABLED)
#define cpt_sriov_enabled(cpt) ((cpt)->flags & CPT_FLAG_SRIOV_ENABLED)
#define cpt_vf_driver(cpt) ((cpt)->flags & CPT_FLAG_VF_DRIVER)
#define cpt_device_ready(cpt) ((cpt)->flags & CPT_FLAG_DEVICE_READY)
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] crypto: cavium/cptpf: switch to pci_alloc_irq_vectors
From: Christoph Hellwig @ 2017-02-15 7:18 UTC (permalink / raw)
To: George Cherian; +Cc: David Daney, Herbert Xu, linux-crypto, linux-kernel
In-Reply-To: <20170215071843.30108-1-hch@lst.de>
pci_enable_msix has been long deprecated, but this driver adds a new
instance. Convert it to pci_alloc_irq_vectors and greatly simplify
the code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/crypto/cavium/cpt/cptpf.h | 5 ---
drivers/crypto/cavium/cpt/cptpf_main.c | 58 ++++++----------------------------
2 files changed, 10 insertions(+), 53 deletions(-)
diff --git a/drivers/crypto/cavium/cpt/cptpf.h b/drivers/crypto/cavium/cpt/cptpf.h
index 8a2a8e538da4..c0556c5f63c9 100644
--- a/drivers/crypto/cavium/cpt/cptpf.h
+++ b/drivers/crypto/cavium/cpt/cptpf.h
@@ -51,11 +51,6 @@ struct cpt_device {
struct cpt_vf_info vfinfo[CPT_MAX_VF_NUM]; /* Per VF info */
void __iomem *reg_base; /* Register start address */
- /* MSI-X */
- u8 num_vec;
- bool msix_enabled;
- struct msix_entry msix_entries[CPT_PF_MSIX_VECTORS];
- bool irq_allocated[CPT_PF_MSIX_VECTORS];
struct pci_dev *pdev; /* pci device handle */
struct microcode mcode[CPT_MAX_CORE_GROUPS];
diff --git a/drivers/crypto/cavium/cpt/cptpf_main.c b/drivers/crypto/cavium/cpt/cptpf_main.c
index 682d57a11a75..4119c40e7c4b 100644
--- a/drivers/crypto/cavium/cpt/cptpf_main.c
+++ b/drivers/crypto/cavium/cpt/cptpf_main.c
@@ -332,26 +332,6 @@ static int cpt_ucode_load(struct cpt_device *cpt)
return ret;
}
-static int cpt_enable_msix(struct cpt_device *cpt)
-{
- int i, ret;
-
- cpt->num_vec = CPT_PF_MSIX_VECTORS;
-
- for (i = 0; i < cpt->num_vec; i++)
- cpt->msix_entries[i].entry = i;
-
- ret = pci_enable_msix(cpt->pdev, cpt->msix_entries, cpt->num_vec);
- if (ret) {
- dev_err(&cpt->pdev->dev, "Request for #%d msix vectors failed\n",
- cpt->num_vec);
- return ret;
- }
-
- cpt->msix_enabled = 1;
- return 0;
-}
-
static irqreturn_t cpt_mbx0_intr_handler(int irq, void *cpt_irq)
{
struct cpt_device *cpt = (struct cpt_device *)cpt_irq;
@@ -361,26 +341,6 @@ static irqreturn_t cpt_mbx0_intr_handler(int irq, void *cpt_irq)
return IRQ_HANDLED;
}
-static void cpt_disable_msix(struct cpt_device *cpt)
-{
- if (cpt->msix_enabled) {
- pci_disable_msix(cpt->pdev);
- cpt->msix_enabled = 0;
- cpt->num_vec = 0;
- }
-}
-
-static void cpt_free_all_interrupts(struct cpt_device *cpt)
-{
- int irq;
-
- for (irq = 0; irq < cpt->num_vec; irq++) {
- if (cpt->irq_allocated[irq])
- free_irq(cpt->msix_entries[irq].vector, cpt);
- cpt->irq_allocated[irq] = false;
- }
-}
-
static void cpt_reset(struct cpt_device *cpt)
{
cpt_write_csr64(cpt->reg_base, CPTX_PF_RESET(0), 1);
@@ -506,32 +466,34 @@ static int cpt_register_interrupts(struct cpt_device *cpt)
struct device *dev = &cpt->pdev->dev;
/* Enable MSI-X */
- ret = cpt_enable_msix(cpt);
- if (ret)
+ ret = pci_alloc_irq_vectors(cpt->pdev, CPT_PF_MSIX_VECTORS,
+ CPT_PF_MSIX_VECTORS, PCI_IRQ_MSIX);
+ if (ret < 0) {
+ dev_err(&cpt->pdev->dev, "Request for #%d msix vectors failed\n",
+ CPT_PF_MSIX_VECTORS);
return ret;
+ }
/* Register mailbox interrupt handlers */
- ret = request_irq(cpt->msix_entries[CPT_PF_INT_VEC_E_MBOXX(0)].vector,
+ ret = request_irq(pci_irq_vector(cpt->pdev, CPT_PF_INT_VEC_E_MBOXX(0)),
cpt_mbx0_intr_handler, 0, "CPT Mbox0", cpt);
if (ret)
goto fail;
- cpt->irq_allocated[CPT_PF_INT_VEC_E_MBOXX(0)] = true;
-
/* Enable mailbox interrupt */
cpt_enable_mbox_interrupts(cpt);
return 0;
fail:
dev_err(dev, "Request irq failed\n");
- cpt_free_all_interrupts(cpt);
+ pci_disable_msix(cpt->pdev);
return ret;
}
static void cpt_unregister_interrupts(struct cpt_device *cpt)
{
- cpt_free_all_interrupts(cpt);
- cpt_disable_msix(cpt);
+ free_irq(pci_irq_vector(cpt->pdev, CPT_PF_INT_VEC_E_MBOXX(0)), cpt);
+ pci_disable_msix(cpt->pdev);
}
static int cpt_sriov_init(struct cpt_device *cpt, int num_vfs)
--
2.11.0
^ permalink raw reply related
* [PATCH 3/3] crypto: cavium/cptvf: switch to pci_alloc_irq_vectors
From: Christoph Hellwig @ 2017-02-15 7:18 UTC (permalink / raw)
To: George Cherian; +Cc: David Daney, Herbert Xu, linux-crypto, linux-kernel
In-Reply-To: <20170215071843.30108-1-hch@lst.de>
pci_enable_msix has been long deprecated, but this driver adds a new
instance. Convert it to pci_alloc_irq_vectors and greatly simplify
the code, and make sure the prope code properly unwinds.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/crypto/cavium/cpt/cptvf.h | 3 -
drivers/crypto/cavium/cpt/cptvf_main.c | 203 +++++++++++----------------------
2 files changed, 65 insertions(+), 141 deletions(-)
diff --git a/drivers/crypto/cavium/cpt/cptvf.h b/drivers/crypto/cavium/cpt/cptvf.h
index 1cc04aa611e4..0a835a07d4f2 100644
--- a/drivers/crypto/cavium/cpt/cptvf.h
+++ b/drivers/crypto/cavium/cpt/cptvf.h
@@ -107,9 +107,6 @@ struct cpt_vf {
void __iomem *reg_base; /* Register start address */
void *wqe_info; /* BH worker info */
/* MSI-X */
- bool msix_enabled;
- struct msix_entry msix_entries[CPT_VF_MSIX_VECTORS];
- bool irq_allocated[CPT_VF_MSIX_VECTORS];
cpumask_var_t affinity_mask[CPT_VF_MSIX_VECTORS];
/* Command and Pending queues */
u32 qsize;
diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c b/drivers/crypto/cavium/cpt/cptvf_main.c
index 527bdc3c2969..aac2966ff8d9 100644
--- a/drivers/crypto/cavium/cpt/cptvf_main.c
+++ b/drivers/crypto/cavium/cpt/cptvf_main.c
@@ -357,48 +357,10 @@ static int cptvf_sw_init(struct cpt_vf *cptvf, u32 qlen, u32 nr_queues)
return ret;
}
-static void cptvf_disable_msix(struct cpt_vf *cptvf)
+static void cptvf_free_irq_affinity(struct cpt_vf *cptvf, int vec)
{
- if (cptvf->msix_enabled) {
- pci_disable_msix(cptvf->pdev);
- cptvf->msix_enabled = 0;
- }
-}
-
-static int cptvf_enable_msix(struct cpt_vf *cptvf)
-{
- int i, ret;
-
- for (i = 0; i < CPT_VF_MSIX_VECTORS; i++)
- cptvf->msix_entries[i].entry = i;
-
- ret = pci_enable_msix(cptvf->pdev, cptvf->msix_entries,
- CPT_VF_MSIX_VECTORS);
- if (ret) {
- dev_err(&cptvf->pdev->dev, "Request for #%d msix vectors failed\n",
- CPT_VF_MSIX_VECTORS);
- return ret;
- }
-
- cptvf->msix_enabled = 1;
- /* Mark MSIX enabled */
- cptvf->flags |= CPT_FLAG_MSIX_ENABLED;
-
- return 0;
-}
-
-static void cptvf_free_all_interrupts(struct cpt_vf *cptvf)
-{
- int irq;
-
- for (irq = 0; irq < CPT_VF_MSIX_VECTORS; irq++) {
- if (cptvf->irq_allocated[irq])
- irq_set_affinity_hint(cptvf->msix_entries[irq].vector,
- NULL);
- free_cpumask_var(cptvf->affinity_mask[irq]);
- free_irq(cptvf->msix_entries[irq].vector, cptvf);
- cptvf->irq_allocated[irq] = false;
- }
+ irq_set_affinity_hint(pci_irq_vector(cptvf->pdev, vec), NULL);
+ free_cpumask_var(cptvf->affinity_mask[vec]);
}
static void cptvf_write_vq_ctl(struct cpt_vf *cptvf, bool val)
@@ -650,85 +612,23 @@ static irqreturn_t cptvf_done_intr_handler(int irq, void *cptvf_irq)
return IRQ_HANDLED;
}
-static int cptvf_register_misc_intr(struct cpt_vf *cptvf)
-{
- struct pci_dev *pdev = cptvf->pdev;
- int ret;
-
- /* Register misc interrupt handlers */
- ret = request_irq(cptvf->msix_entries[CPT_VF_INT_VEC_E_MISC].vector,
- cptvf_misc_intr_handler, 0, "CPT VF misc intr",
- cptvf);
- if (ret)
- goto fail;
-
- cptvf->irq_allocated[CPT_VF_INT_VEC_E_MISC] = true;
-
- /* Enable mailbox interrupt */
- cptvf_enable_mbox_interrupts(cptvf);
- cptvf_enable_swerr_interrupts(cptvf);
-
- return 0;
-
-fail:
- dev_err(&pdev->dev, "Request misc irq failed");
- cptvf_free_all_interrupts(cptvf);
- return ret;
-}
-
-static int cptvf_register_done_intr(struct cpt_vf *cptvf)
-{
- struct pci_dev *pdev = cptvf->pdev;
- int ret;
-
- /* Register DONE interrupt handlers */
- ret = request_irq(cptvf->msix_entries[CPT_VF_INT_VEC_E_DONE].vector,
- cptvf_done_intr_handler, 0, "CPT VF done intr",
- cptvf);
- if (ret)
- goto fail;
-
- cptvf->irq_allocated[CPT_VF_INT_VEC_E_DONE] = true;
-
- /* Enable mailbox interrupt */
- cptvf_enable_done_interrupts(cptvf);
- return 0;
-
-fail:
- dev_err(&pdev->dev, "Request done irq failed\n");
- cptvf_free_all_interrupts(cptvf);
- return ret;
-}
-
-static void cptvf_unregister_interrupts(struct cpt_vf *cptvf)
-{
- cptvf_free_all_interrupts(cptvf);
- cptvf_disable_msix(cptvf);
-}
-
-static void cptvf_set_irq_affinity(struct cpt_vf *cptvf)
+static void cptvf_set_irq_affinity(struct cpt_vf *cptvf, int vec)
{
struct pci_dev *pdev = cptvf->pdev;
- int vec, cpu;
- int irqnum;
-
- for (vec = 0; vec < CPT_VF_MSIX_VECTORS; vec++) {
- if (!cptvf->irq_allocated[vec])
- continue;
-
- if (!zalloc_cpumask_var(&cptvf->affinity_mask[vec],
- GFP_KERNEL)) {
- dev_err(&pdev->dev, "Allocation failed for affinity_mask for VF %d",
- cptvf->vfid);
- return;
- }
+ int cpu;
- cpu = cptvf->vfid % num_online_cpus();
- cpumask_set_cpu(cpumask_local_spread(cpu, cptvf->node),
- cptvf->affinity_mask[vec]);
- irqnum = cptvf->msix_entries[vec].vector;
- irq_set_affinity_hint(irqnum, cptvf->affinity_mask[vec]);
+ if (!zalloc_cpumask_var(&cptvf->affinity_mask[vec],
+ GFP_KERNEL)) {
+ dev_err(&pdev->dev, "Allocation failed for affinity_mask for VF %d",
+ cptvf->vfid);
+ return;
}
+
+ cpu = cptvf->vfid % num_online_cpus();
+ cpumask_set_cpu(cpumask_local_spread(cpu, cptvf->node),
+ cptvf->affinity_mask[vec]);
+ irq_set_affinity_hint(pci_irq_vector(pdev, vec),
+ cptvf->affinity_mask[vec]);
}
static void cptvf_write_vq_saddr(struct cpt_vf *cptvf, u64 val)
@@ -809,22 +709,32 @@ static int cptvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
}
cptvf->node = dev_to_node(&pdev->dev);
- /* Enable MSI-X */
- err = cptvf_enable_msix(cptvf);
- if (err) {
- dev_err(dev, "cptvf_enable_msix() failed");
+ err = pci_alloc_irq_vectors(pdev, CPT_VF_MSIX_VECTORS,
+ CPT_VF_MSIX_VECTORS, PCI_IRQ_MSIX);
+ if (err < 0) {
+ dev_err(dev, "Request for #%d msix vectors failed\n",
+ CPT_VF_MSIX_VECTORS);
goto cptvf_err_release_regions;
}
- /* Register mailbox interrupts */
- cptvf_register_misc_intr(cptvf);
+ err = request_irq(pci_irq_vector(pdev, CPT_VF_INT_VEC_E_MISC),
+ cptvf_misc_intr_handler, 0, "CPT VF misc intr",
+ cptvf);
+ if (err) {
+ dev_err(dev, "Request misc irq failed");
+ goto cptvf_free_vectors;
+ }
+
+ /* Enable mailbox interrupt */
+ cptvf_enable_mbox_interrupts(cptvf);
+ cptvf_enable_swerr_interrupts(cptvf);
/* Check ready with PF */
/* Gets chip ID / device Id from PF if ready */
err = cptvf_check_pf_ready(cptvf);
if (err) {
dev_err(dev, "PF not responding to READY msg");
- goto cptvf_err_release_regions;
+ goto cptvf_free_misc_irq;
}
/* CPT VF software resources initialization */
@@ -832,13 +742,13 @@ static int cptvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = cptvf_sw_init(cptvf, CPT_CMD_QLEN, CPT_NUM_QS_PER_VF);
if (err) {
dev_err(dev, "cptvf_sw_init() failed");
- goto cptvf_err_release_regions;
+ goto cptvf_free_misc_irq;
}
/* Convey VQ LEN to PF */
err = cptvf_send_vq_size_msg(cptvf);
if (err) {
dev_err(dev, "PF not responding to QLEN msg");
- goto cptvf_err_release_regions;
+ goto cptvf_free_misc_irq;
}
/* CPT VF device initialization */
@@ -848,37 +758,50 @@ static int cptvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = cptvf_send_vf_to_grp_msg(cptvf);
if (err) {
dev_err(dev, "PF not responding to VF_GRP msg");
- goto cptvf_err_release_regions;
+ goto cptvf_free_misc_irq;
}
cptvf->priority = 1;
err = cptvf_send_vf_priority_msg(cptvf);
if (err) {
dev_err(dev, "PF not responding to VF_PRIO msg");
- goto cptvf_err_release_regions;
+ goto cptvf_free_misc_irq;
+ }
+
+ err = request_irq(pci_irq_vector(pdev, CPT_VF_INT_VEC_E_DONE),
+ cptvf_done_intr_handler, 0, "CPT VF done intr",
+ cptvf);
+ if (err) {
+ dev_err(dev, "Request done irq failed\n");
+ goto cptvf_free_misc_irq;
}
- /* Register DONE interrupts */
- err = cptvf_register_done_intr(cptvf);
- if (err)
- goto cptvf_err_release_regions;
+
+ /* Enable mailbox interrupt */
+ cptvf_enable_done_interrupts(cptvf);
/* Set irq affinity masks */
- cptvf_set_irq_affinity(cptvf);
- /* Convey UP to PF */
+ cptvf_set_irq_affinity(cptvf, CPT_VF_INT_VEC_E_MISC);
+ cptvf_set_irq_affinity(cptvf, CPT_VF_INT_VEC_E_DONE);
+
err = cptvf_send_vf_up(cptvf);
if (err) {
dev_err(dev, "PF not responding to UP msg");
- goto cptvf_up_fail;
+ goto cptvf_free_irq_affinity;
}
err = cvm_crypto_init(cptvf);
if (err) {
dev_err(dev, "Algorithm register failed\n");
- goto cptvf_up_fail;
+ goto cptvf_free_irq_affinity;
}
return 0;
-cptvf_up_fail:
- cptvf_unregister_interrupts(cptvf);
+cptvf_free_irq_affinity:
+ cptvf_free_irq_affinity(cptvf, CPT_VF_INT_VEC_E_DONE);
+ cptvf_free_irq_affinity(cptvf, CPT_VF_INT_VEC_E_MISC);
+cptvf_free_misc_irq:
+ free_irq(pci_irq_vector(pdev, CPT_VF_INT_VEC_E_MISC), cptvf);
+cptvf_free_vectors:
+ pci_free_irq_vectors(cptvf->pdev);
cptvf_err_release_regions:
pci_release_regions(pdev);
cptvf_err_disable_device:
@@ -899,7 +822,11 @@ static void cptvf_remove(struct pci_dev *pdev)
if (cptvf_send_vf_down(cptvf)) {
dev_err(&pdev->dev, "PF not responding to DOWN msg");
} else {
- cptvf_unregister_interrupts(cptvf);
+ cptvf_free_irq_affinity(cptvf, CPT_VF_INT_VEC_E_DONE);
+ cptvf_free_irq_affinity(cptvf, CPT_VF_INT_VEC_E_MISC);
+ free_irq(pci_irq_vector(pdev, CPT_VF_INT_VEC_E_DONE), cptvf);
+ free_irq(pci_irq_vector(pdev, CPT_VF_INT_VEC_E_MISC), cptvf);
+ pci_free_irq_vectors(cptvf->pdev);
cptvf_sw_cleanup(cptvf);
pci_set_drvdata(pdev, NULL);
pci_release_regions(pdev);
--
2.11.0
^ permalink raw reply related
* crypto/cavium MSI-X fixups
From: Christoph Hellwig @ 2017-02-15 7:18 UTC (permalink / raw)
To: George Cherian; +Cc: David Daney, Herbert Xu, linux-crypto, linux-kernel
Hi George,
your commit "crypto: cavium - Add Support for Octeon-tx CPT Engine"
add a new caller to pci_enable_msix. This API has long been deprecated
so this series switches it to use pci_alloc_irq_vectors instead.
Can you please test it and make sure it goes in before the end of the
merge window so that no more users of the old API hit mainline?
^ permalink raw reply
* Re: [PATCH v4 3/4] dmaengine: Add Broadcom SBA RAID driver
From: Dan Williams @ 2017-02-15 7:25 UTC (permalink / raw)
To: Anup Patel
Cc: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar, Ray Jui, Scott Branden, Jon Mason,
Rob Rice, BCM Kernel Feedback,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Device Tree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, linux-raid
In-Reply-To: <CAALAos-txDCs3QZ4HGBNicOD8t49NPT6E8RpjVMccMn1D-UTgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Feb 14, 2017 at 11:03 PM, Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On Wed, Feb 15, 2017 at 12:13 PM, Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> On Tue, Feb 14, 2017 at 10:25 PM, Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>> On Tue, Feb 14, 2017 at 10:04 PM, Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>>>> On Mon, Feb 13, 2017 at 10:51 PM, Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>>>> The Broadcom stream buffer accelerator (SBA) provides offloading
>>>>> capabilities for RAID operations. This SBA offload engine is
>>>>> accessible via Broadcom SoC specific ring manager.
>>>>>
>>>>> This patch adds Broadcom SBA RAID driver which provides one
>>>>> DMA device with RAID capabilities using one or more Broadcom
>>>>> SoC specific ring manager channels. The SBA RAID driver in its
>>>>> current shape implements memcpy, xor, and pq operations.
>>>>>
>>>>> Signed-off-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>>>> Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>>>> ---
>>>>> drivers/dma/Kconfig | 13 +
>>>>> drivers/dma/Makefile | 1 +
>>>>> drivers/dma/bcm-sba-raid.c | 1694 ++++++++++++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 1708 insertions(+)
>>>>> create mode 100644 drivers/dma/bcm-sba-raid.c
>>>>>
>>>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>>>> index 263495d..bf8fb84 100644
>>>>> --- a/drivers/dma/Kconfig
>>>>> +++ b/drivers/dma/Kconfig
>>>>> @@ -99,6 +99,19 @@ config AXI_DMAC
>>>>> controller is often used in Analog Device's reference designs for FPGA
>>>>> platforms.
>>>>>
>>>>> +config BCM_SBA_RAID
>>>>> + tristate "Broadcom SBA RAID engine support"
>>>>> + depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
>>>>> + select DMA_ENGINE
>>>>> + select DMA_ENGINE_RAID
>>>>> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>>>
>>>> I thought you agreed to drop this. Its usage is broken.
>>>
>>> If ASYNC_TX_ENABLE_CHANNEL_SWITCH is not selected
>>> then async_dma_find_channel() will only try to find channel
>>> with DMA_ASYNC_TX capability.
>>>
>>> The DMA_ASYNC_TX capability is set by
>>> dma_async_device_register() when all Async Tx
>>> capabilities are supported by a DMA devices namely
>>> DMA_INTERRUPT, DMA_MEMCPY, DMA_XOR,
>>> DMA_XOR_VAL, DMA_PQ, and DMA_PQ_VAL.
>>>
>>> We only support DMA_MEMCPY, DMA_XOR, and
>>> DMA_PQ capabilities in BCM-SBA-RAID driver so
>>> DMA_ASYNC_TX capability is never set for the
>>> DMA device registered by BCM-SBA-RAID driver.
>>>
>>> Due to above, if ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>> is not selected then Async Tx APIs fail to find DMA
>>> channel provided by BCM-SBA-RAID hence the
>>> option ASYNC_TX_ENABLE_CHANNEL_SWITCH is
>>> required for BCM-SBA-RAID.
>>>
>>> The DMA mappings are violated by channel switching
>>> only if we switch form DMA channel A to DMA channel
>>> B and both these DMA channels have different underlying
>>> "struct device". In most of the cases DMA mappings
>>> are not violated because DMA channels having
>>> Async Tx capabilities are provided using same
>>> underlying "struct device".
>>
>> No, fix the infrastructure. Do not put local hack in your driver for
>> this global problem [1].
>
> There is no hack in the driver. We need
> ASYNC_TX_ENABLE_CHANNEL_SWITCH
> based on current state of dmaengine framework.
>
> The framework should be fixed as separate patchset.
>
> We have other RAID drivers such as xgene-dma and
> mv_xor_v2 who also require
> ASYNC_TX_ENABLE_CHANNEL_SWITCH due
> to same reason.
>
> Fixing the framework and improving framework is
> a ongoing process. I don't see why that should
> stop this patchset.
>
Because this driver is turning on a dangerous compile time option and
is not using the functionality. If this silicon IP block appears in
another product in the future paired with another DMA engine then the
assumptions about a safe/single dma-device is violated.
The realization of how async_tx was breaking DMA mapping api
assumptions came after some of these dma-drivers were added to the
kernel. We should stop making the problem worse.
I should have submitted a patch like the below at the time we
discovered this problem, but unfortunately it languished when I
stopped maintaining the iop-adma and ioat drivers.
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 263495d0adbd..6b30eb9ad125 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -35,6 +35,7 @@ comment "DMA Devices"
#core
config ASYNC_TX_ENABLE_CHANNEL_SWITCH
+ depends on BROKEN
bool
config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Qualcomm QCE driver: XTS setkey only allows 128 bit AES
From: Stephan Müller @ 2017-02-15 7:28 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170215040243.GA13703@gondor.apana.org.au>
Am Mittwoch, 15. Februar 2017, 12:02:43 CET schrieb Herbert Xu:
Hi Herbert,
> Stephan Müller <smueller@chronox.de> wrote:
> > Hi,
> >
> > The Qualcomm QCE driver implementation defines:
> > .flags = QCE_ALG_AES | QCE_MODE_XTS,
> > .name = "xts(aes)",
> > .drv_name = "xts-aes-qce",
> > .blocksize = AES_BLOCK_SIZE,
> > .ivsize = AES_BLOCK_SIZE,
> > .min_keysize = AES_MIN_KEY_SIZE,
> > .max_keysize = AES_MAX_KEY_SIZE,
> >
> > and
> >
> > alg->cra_ablkcipher.min_keysize = def->min_keysize;
> > alg->cra_ablkcipher.max_keysize = def->max_keysize;
> > alg->cra_ablkcipher.setkey = qce_ablkcipher_setkey;
> >
> > Thus, this driver has the limits of 128 to 256 bits for the key.
> > Furthermore, the common setkey function is used.
> >
> > May I ask how the key for AES XTS is supposed to be handled here
> > considering that the kernel crypto API expects that the AES key and the
> > tweak key is set via one setkey call. I.e. the setkey should expect 256
> > through 512 bits.
> If the hardware doesn't support it then it needs to be handled with
> a fallback. Shouldn't testmgr catch this though?
It should be caught there because there are test vectors with a klen of 64
bytes. Thus, the setkey should fail.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v7 0/5] Update LZ4 compressor module
From: Minchan Kim @ 2017-02-15 7:29 UTC (permalink / raw)
To: Sven Schmidt
Cc: ebiggers3, akpm, bongkyu.kim, rsalvaterra, sergey.senozhatsky,
gregkh, linux-kernel, herbert, davem, linux-crypto, anton, ccross,
keescook, tony.luck
In-Reply-To: <20170213120841.GB22510@bierbaron.springfield.local>
Hi Sven,
On Mon, Feb 13, 2017 at 01:08:41PM +0100, Sven Schmidt wrote:
> On Mon, Feb 13, 2017 at 09:03:24AM +0900, Minchan Kim wrote:
> > Hi Sven,
> >
> > On Sun, Feb 12, 2017 at 12:16:17PM +0100, Sven Schmidt wrote:
> > >
> > >
> > >
> > > On 02/10/2017 01:13 AM, Minchan Kim wrote:
> > > > Hello Sven,
> > > >
> > > > On Thu, Feb 09, 2017 at 11:56:17AM +0100, Sven Schmidt wrote:
> > > >> Hey Minchan,
> > > >>
> > > >> On Thu, Feb 09, 2017 at 08:31:21AM +0900, Minchan Kim wrote:
> > > >>> Hello Sven,
> > > >>>
> > > >>> On Sun, Feb 05, 2017 at 08:09:03PM +0100, Sven Schmidt wrote:
> > > >>>>
> > > >>>> This patchset is for updating the LZ4 compression module to a version based
> > > >>>> on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast
> > > >>>> which provides an "acceleration" parameter as a tradeoff between
> > > >>>> high compression ratio and high compression speed.
> > > >>>>
> > > >>>> We want to use LZ4 fast in order to support compression in lustre
> > > >>>> and (mostly, based on that) investigate data reduction techniques in behalf of
> > > >>>> storage systems.
> > > >>>>
> > > >>>> Also, it will be useful for other users of LZ4 compression, as with LZ4 fast
> > > >>>> it is possible to enable applications to use fast and/or high compression
> > > >>>> depending on the usecase.
> > > >>>> For instance, ZRAM is offering a LZ4 backend and could benefit from an updated
> > > >>>> LZ4 in the kernel.
> > > >>>>
> > > >>>> LZ4 homepage: http://www.lz4.org/
> > > >>>> LZ4 source repository: https://github.com/lz4/lz4
> > > >>>> Source version: 1.7.3
> > > >>>>
> > > >>>> Benchmark (taken from [1], Core i5-4300U @1.9GHz):
> > > >>>> ----------------|--------------|----------------|----------
> > > >>>> Compressor | Compression | Decompression | Ratio
> > > >>>> ----------------|--------------|----------------|----------
> > > >>>> memcpy | 4200 MB/s | 4200 MB/s | 1.000
> > > >>>> LZ4 fast 50 | 1080 MB/s | 2650 MB/s | 1.375
> > > >>>> LZ4 fast 17 | 680 MB/s | 2220 MB/s | 1.607
> > > >>>> LZ4 fast 5 | 475 MB/s | 1920 MB/s | 1.886
> > > >>>> LZ4 default | 385 MB/s | 1850 MB/s | 2.101
> > > >>>>
> > > >>>> [1] http://fastcompression.blogspot.de/2015/04/sampling-or-faster-lz4.html
> > > >>>>
> > > >>>> [PATCH 1/5] lib: Update LZ4 compressor module
> > > >>>> [PATCH 2/5] lib/decompress_unlz4: Change module to work with new LZ4 module version
> > > >>>> [PATCH 3/5] crypto: Change LZ4 modules to work with new LZ4 module version
> > > >>>> [PATCH 4/5] fs/pstore: fs/squashfs: Change usage of LZ4 to work with new LZ4 version
> > > >>>> [PATCH 5/5] lib/lz4: Remove back-compat wrappers
> > > >>>
> > > >>> Today, I did zram-lz4 performance test with fio in current mmotm and
> > > >>> found it makes regression about 20%.
> > > >>>
> > > >>> "lz4-update" means current mmots(git://git.cmpxchg.org/linux-mmots.git) so
> > > >>> applied your 5 patches. (But now sure current mmots has recent uptodate
> > > >>> patches)
> > > >>> "revert" means I reverted your 5 patches in current mmots.
> > > >>>
> > > >>> revert lz4-update
> > > >>>
> > > >>> seq-write 1547 1339 86.55%
> > > >>> rand-write 22775 19381 85.10%
> > > >>> seq-read 7035 5589 79.45%
> > > >>> rand-read 78556 68479 87.17%
> > > >>> mixed-seq(R) 1305 1066 81.69%
> > > >>> mixed-seq(W) 1205 984 81.66%
> > > >>> mixed-rand(R) 17421 14993 86.06%
> > > >>> mixed-rand(W) 17391 14968 86.07%
> > > >>
> > > >> which parts of the output (as well as units) are these values exactly?
> > > >> I did not work with fio until now, so I think I might ask before misinterpreting my results.
> > > >
> > > > It is IOPS.
> > > >
> > > >>
> > > >>> My fio description file
> > > >>>
> > > >>> [global]
> > > >>> bs=4k
> > > >>> ioengine=sync
> > > >>> size=100m
> > > >>> numjobs=1
> > > >>> group_reporting
> > > >>> buffer_compress_percentage=30
> > > >>> scramble_buffers=0
> > > >>> filename=/dev/zram0
> > > >>> loops=10
> > > >>> fsync_on_close=1
> > > >>>
> > > >>> [seq-write]
> > > >>> bs=64k
> > > >>> rw=write
> > > >>> stonewall
> > > >>>
> > > >>> [rand-write]
> > > >>> rw=randwrite
> > > >>> stonewall
> > > >>>
> > > >>> [seq-read]
> > > >>> bs=64k
> > > >>> rw=read
> > > >>> stonewall
> > > >>>
> > > >>> [rand-read]
> > > >>> rw=randread
> > > >>> stonewall
> > > >>>
> > > >>> [mixed-seq]
> > > >>> bs=64k
> > > >>> rw=rw
> > > >>> stonewall
> > > >>>
> > > >>> [mixed-rand]
> > > >>> rw=randrw
> > > >>> stonewall
> > > >>>
> > > >>
> > > >> Great, this makes it easy for me to reproduce your test.
> > > >
> > > > If you have trouble to reproduce, feel free to ask me. I'm happy to test it. :)
> > > >
> > > > Thanks!
> > > >
> > >
> > > Hi Minchan,
> > >
> > > I will send an updated patch as a reply to this E-Mail. Would be really grateful If you'd test it and provide feedback!
> > > The patch should be applied to the current mmots tree.
> > >
> > > In fact, the updated LZ4 _is_ slower than the current one in kernel. But I was not able to reproduce such large regressions
> > > as you did. I now tried to define FORCE_INLINE as Eric suggested. I also inlined some functions which weren't in upstream LZ4,
> > > but are defined as macros in the current kernel LZ4. The approach to replace LZ4_ARCH64 with the function call _seemed_ to behave
> > > worse than the macro, so I withdrew the change.
> > >
> > > The main difference is, that I replaced the read32/read16/write... etc. functions using memcpy with the other ones defined
> > > in upstream LZ4 (which can be switched using a macro).
> > > The comment of the author stated, that they're as fast as the memcpy variants (or faster), but not as portable
> > > (which does not matter since we're not dependent for multiple compilers).
> > >
> > > In my tests, this version is mostly as fast as the current kernel LZ4.
> >
> > With a patch you sent, I cannot see enhancement so I wanted to dig in and
> > found how I was really careless.
> >
> > I have tested both test with CONFIG_KASAN. OMG. With disabling it, I don't
> > see any regression any more. So, I'm really really *sorry* about noise and
> > wasting your time. However, I am curious why KASAN makes such difference.
> >
>
> Hey Minchan,
>
> I'm glad to hear that! Nevertheless, the changes discussed here made some differences in my own tests (I believe it got a bit
> faster now) and we have the functions properly inlined, where this makes sense. Also, I added the '-O3' C-flag as Eric suggested.
> So, this was not really a waste of time, I think.
>
> > The reason I tested new updated lz4 is description says lz4 fast and
> > want to use it in zram. How can I do that? and How faster it is compared
> > to old?
> >
>
> Unfortunately, in the current implementation (in crypto/lz4.c, which is used by zram) I'm setting the acceleration parameter
> (which is the paramer making the compression 'fast', see LZ4_compress_fast) to 1 (which is the default) since I did not know how this
> patchset is accepted and this equals the behaviour currently available in kernel.
Fair enough.
>
> Basically, the logic is 'higher acceleration = faster compression = lower compression ratio' and vice versa.
> I included some benchmarks in my patch 0/5 E-Mail taken from the official LZ4:
>
> > > >>>> ----------------|--------------|----------------|----------
> > > >>>> Compressor | Compression | Decompression | Ratio
> > > >>>> ----------------|--------------|----------------|----------
> > > >>>> memcpy | 4200 MB/s | 4200 MB/s | 1.000
> > > >>>> LZ4 fast 50 | 1080 MB/s | 2650 MB/s | 1.375
> > > >>>> LZ4 fast 17 | 680 MB/s | 2220 MB/s | 1.607
> > > >>>> LZ4 fast 5 | 475 MB/s | 1920 MB/s | 1.886
> > > >>>> LZ4 default | 385 MB/s | 1850 MB/s | 2.101
> > > >>>>
>
> fast 50 means: acceleration=50, default: acceleration=1.
I understood now. Thanks for the explanation!
>
> Besides the proposed patchset, I tried to implement a module parameter in crypto/lz4.c to set the acceleration factor.
> In my tests, the module parameter works out great.
If it works with module parameter, it means every guest of lz4 via crypto
should use same acceleration level? Hmm, some system might want different
acceleration level among different subsystems.
Anyway, if it works, it would be great for user of zram to test/select
right choice for their system workload.
Thanks for the great work!
> But I think this is subject to a future, separate patch. Especially since I had to 'work around' the crypto/testmgr.c,
> which only tests acceleration=1 and there's no limit for acceleration.
>
> Thanks for your help,
>
> Sven
^ permalink raw reply
* Re: [PATCH v4 3/4] dmaengine: Add Broadcom SBA RAID driver
From: Anup Patel @ 2017-02-15 8:33 UTC (permalink / raw)
To: Dan Williams
Cc: Vinod Koul, Rob Herring, Mark Rutland, Herbert Xu,
David S . Miller, Jassi Brar, Ray Jui, Scott Branden, Jon Mason,
Rob Rice, BCM Kernel Feedback, dmaengine@vger.kernel.org,
Device Tree, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-crypto, linux-raid
In-Reply-To: <CAPcyv4h83vgeB82KmEEFV196MsWdteRqypY5_tcSyaMM_QwYMA@mail.gmail.com>
On Wed, Feb 15, 2017 at 12:55 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Feb 14, 2017 at 11:03 PM, Anup Patel <anup.patel@broadcom.com> wrote:
>> On Wed, Feb 15, 2017 at 12:13 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>>> On Tue, Feb 14, 2017 at 10:25 PM, Anup Patel <anup.patel@broadcom.com> wrote:
>>>> On Tue, Feb 14, 2017 at 10:04 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>>>>> On Mon, Feb 13, 2017 at 10:51 PM, Anup Patel <anup.patel@broadcom.com> wrote:
>>>>>> The Broadcom stream buffer accelerator (SBA) provides offloading
>>>>>> capabilities for RAID operations. This SBA offload engine is
>>>>>> accessible via Broadcom SoC specific ring manager.
>>>>>>
>>>>>> This patch adds Broadcom SBA RAID driver which provides one
>>>>>> DMA device with RAID capabilities using one or more Broadcom
>>>>>> SoC specific ring manager channels. The SBA RAID driver in its
>>>>>> current shape implements memcpy, xor, and pq operations.
>>>>>>
>>>>>> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
>>>>>> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
>>>>>> ---
>>>>>> drivers/dma/Kconfig | 13 +
>>>>>> drivers/dma/Makefile | 1 +
>>>>>> drivers/dma/bcm-sba-raid.c | 1694 ++++++++++++++++++++++++++++++++++++++++++++
>>>>>> 3 files changed, 1708 insertions(+)
>>>>>> create mode 100644 drivers/dma/bcm-sba-raid.c
>>>>>>
>>>>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>>>>> index 263495d..bf8fb84 100644
>>>>>> --- a/drivers/dma/Kconfig
>>>>>> +++ b/drivers/dma/Kconfig
>>>>>> @@ -99,6 +99,19 @@ config AXI_DMAC
>>>>>> controller is often used in Analog Device's reference designs for FPGA
>>>>>> platforms.
>>>>>>
>>>>>> +config BCM_SBA_RAID
>>>>>> + tristate "Broadcom SBA RAID engine support"
>>>>>> + depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
>>>>>> + select DMA_ENGINE
>>>>>> + select DMA_ENGINE_RAID
>>>>>> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>>>>
>>>>> I thought you agreed to drop this. Its usage is broken.
>>>>
>>>> If ASYNC_TX_ENABLE_CHANNEL_SWITCH is not selected
>>>> then async_dma_find_channel() will only try to find channel
>>>> with DMA_ASYNC_TX capability.
>>>>
>>>> The DMA_ASYNC_TX capability is set by
>>>> dma_async_device_register() when all Async Tx
>>>> capabilities are supported by a DMA devices namely
>>>> DMA_INTERRUPT, DMA_MEMCPY, DMA_XOR,
>>>> DMA_XOR_VAL, DMA_PQ, and DMA_PQ_VAL.
>>>>
>>>> We only support DMA_MEMCPY, DMA_XOR, and
>>>> DMA_PQ capabilities in BCM-SBA-RAID driver so
>>>> DMA_ASYNC_TX capability is never set for the
>>>> DMA device registered by BCM-SBA-RAID driver.
>>>>
>>>> Due to above, if ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>>> is not selected then Async Tx APIs fail to find DMA
>>>> channel provided by BCM-SBA-RAID hence the
>>>> option ASYNC_TX_ENABLE_CHANNEL_SWITCH is
>>>> required for BCM-SBA-RAID.
>>>>
>>>> The DMA mappings are violated by channel switching
>>>> only if we switch form DMA channel A to DMA channel
>>>> B and both these DMA channels have different underlying
>>>> "struct device". In most of the cases DMA mappings
>>>> are not violated because DMA channels having
>>>> Async Tx capabilities are provided using same
>>>> underlying "struct device".
>>>
>>> No, fix the infrastructure. Do not put local hack in your driver for
>>> this global problem [1].
>>
>> There is no hack in the driver. We need
>> ASYNC_TX_ENABLE_CHANNEL_SWITCH
>> based on current state of dmaengine framework.
>>
>> The framework should be fixed as separate patchset.
>>
>> We have other RAID drivers such as xgene-dma and
>> mv_xor_v2 who also require
>> ASYNC_TX_ENABLE_CHANNEL_SWITCH due
>> to same reason.
>>
>> Fixing the framework and improving framework is
>> a ongoing process. I don't see why that should
>> stop this patchset.
>>
>
> Because this driver is turning on a dangerous compile time option and
> is not using the functionality. If this silicon IP block appears in
> another product in the future paired with another DMA engine then the
> assumptions about a safe/single dma-device is violated.
>
> The realization of how async_tx was breaking DMA mapping api
> assumptions came after some of these dma-drivers were added to the
> kernel. We should stop making the problem worse.
>
> I should have submitted a patch like the below at the time we
> discovered this problem, but unfortunately it languished when I
> stopped maintaining the iop-adma and ioat drivers.
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 263495d0adbd..6b30eb9ad125 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -35,6 +35,7 @@ comment "DMA Devices"
>
> #core
> config ASYNC_TX_ENABLE_CHANNEL_SWITCH
> + depends on BROKEN
> bool
>
> config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
Instead of selecting
ASYNC_TX_ENABLE_CHANNEL_SWITCH,
we can select the following in BCM_SBA_RAID config
option:
1. ASYNC_TX_DISABLE_XOR_VAL
2. ASYNC_TX_DISABLE_PQ_VAL
This will satisfy the needs of
dma_async_device_register() when
ASYNC_TX_ENABLE_CHANNEL_SWITCH is
not selected.
Will this be acceptable ??
Regards,
Anup
^ permalink raw reply
* [bug report] crypto: cavium - Add the Virtual Function driver for CPT
From: Dan Carpenter @ 2017-02-15 8:39 UTC (permalink / raw)
To: george.cherian; +Cc: linux-crypto
Hello George Cherian,
This is a semi-automatic email about new static checker warnings.
The patch c694b233295b: "crypto: cavium - Add the Virtual Function
driver for CPT" from Feb 7, 2017, leads to the following Smatch
complaint:
drivers/crypto/cavium/cpt/cptvf_reqmanager.c:333 do_post_process()
warn: variable dereferenced before check 'cptvf' (see line 331)
drivers/crypto/cavium/cpt/cptvf_reqmanager.c
330 {
331 struct pci_dev *pdev = cptvf->pdev;
^^^^^^^^^^^
Dereference.
332
333 if (!info || !cptvf) {
^^^^^
Check is too late.
334 dev_err(&pdev->dev, "Input params are incorrect for post processing\n");
335 return;
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v3 0/2] crypto: AF_ALG memory management fix
From: Stephan Müller @ 2017-02-15 8:47 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
In-Reply-To: <1652737.cgCBfDoNyd@positron.chronox.de>
Am Montag, 13. Februar 2017, 11:04:50 CET schrieb Stephan Müller:
Hi Herbert,
as I just saw that you marked my patch with changes requested in patchwork,
may I ask which changes should be applied?
Ciao
Stephan
^ permalink raw reply
* Re: crypto/cavium MSI-X fixups
From: George Cherian @ 2017-02-15 9:17 UTC (permalink / raw)
To: Christoph Hellwig, George Cherian
Cc: David Daney, Herbert Xu, linux-crypto, linux-kernel
In-Reply-To: <20170215071843.30108-1-hch@lst.de>
Hi Christoph,
On 02/15/2017 12:48 PM, Christoph Hellwig wrote:
> Hi George,
>
> your commit "crypto: cavium - Add Support for Octeon-tx CPT Engine"
> add a new caller to pci_enable_msix. This API has long been deprecated
> so this series switches it to use pci_alloc_irq_vectors instead.
>
> Can you please test it and make sure it goes in before the end of the
> merge window so that no more users of the old API hit mainline?
Yes the changes works well.
Acked-by: George Cherian <george.cherian@cavium.com>
for the series.
>
^ permalink raw reply
* Assalamu`Alaikum.
From: mohammad ouattara @ 2017-02-15 9:29 UTC (permalink / raw)
In-Reply-To: <271924984.4723599.1487150996135.ref@mail.yahoo.com>
Dear Sir/Madam.
Assalamu`Alaikum.
I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account,
I will send you more details about this deal and the procedures to follow when I receive a positive response from you,
Have a great day,
Dr mohammad ouattara.
^ permalink raw reply
* Assalamu`Alaikum.
From: mohammad ouattara @ 2017-02-15 9:31 UTC (permalink / raw)
In-Reply-To: <785167166.4756680.1487151117044.ref@mail.yahoo.com>
Dear Sir/Madam.
Assalamu`Alaikum.
I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account,
I will send you more details about this deal and the procedures to follow when I receive a positive response from you,
Have a great day,
Dr mohammad ouattara.
^ permalink raw reply
* [PATCH] crypto: cavium/cpt: Fix couple of static checker errors
From: George Cherian @ 2017-02-15 12:42 UTC (permalink / raw)
To: herbert, davem, dan.carpenter; +Cc: linux-kernel, linux-crypto, George Cherian
Fix the following smatch errors
cptvf_reqmanager.c:333 do_post_process() warn: variable dereferenced
before check 'cptvf'
cptvf_main.c:825 cptvf_remove() error: we previously assumed 'cptvf'
could be null
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: George Cherian <george.cherian@cavium.com>
---
drivers/crypto/cavium/cpt/cptvf_main.c | 4 +++-
drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c b/drivers/crypto/cavium/cpt/cptvf_main.c
index aac2966..e50872e 100644
--- a/drivers/crypto/cavium/cpt/cptvf_main.c
+++ b/drivers/crypto/cavium/cpt/cptvf_main.c
@@ -815,8 +815,10 @@ static void cptvf_remove(struct pci_dev *pdev)
{
struct cpt_vf *cptvf = pci_get_drvdata(pdev);
- if (!cptvf)
+ if (!cptvf) {
dev_err(&pdev->dev, "Invalid CPT-VF device\n");
+ return;
+ }
/* Convey DOWN to PF */
if (cptvf_send_vf_down(cptvf)) {
diff --git a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
index 7f57f30..169e662 100644
--- a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
+++ b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
@@ -330,8 +330,8 @@ void do_post_process(struct cpt_vf *cptvf, struct cpt_info_buffer *info)
{
struct pci_dev *pdev = cptvf->pdev;
- if (!info || !cptvf) {
- dev_err(&pdev->dev, "Input params are incorrect for post processing\n");
+ if (!info) {
+ dev_err(&pdev->dev, "incorrect cpt_info_buffer for post processing\n");
return;
}
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox