Re: [PATCH] drivers/crypto/Kconfig: Let 'DEV_QCE' depend on both HAS_DMA and HAS_IOMEM
Oh, sorry, this patch can still be alive, after a long discussion, we need keep current status no touch -- still let individual modules to depends on HAS_IOMEM and/or HAS_DMA, if they need them. So please help check the patch, when you have time. Thanks. On 07/14/2014 08:12 PM, Chen Gang wrote: > Hello all: > > This patch is obsoleted according to the other discussion thread about > IOMEM and COMPILE_TEST. > > I shall fix it, and maybe not need touch drivers/crypto again, so maybe > not need send patch v2 for it. > > Thanks. > > On 07/13/2014 11:01 AM, Chen Gang wrote: >> 'DEV_QCE' needs both HAS_DMA and HAS_IOMEM, so let it depend on them. >> >> The related error (with allmodconfig under score): >> >> MODPOST 1365 modules >> ERROR: "devm_ioremap_resource" [drivers/crypto/qce/qcrypto.ko] undefined! >> ERROR: "dma_map_sg" [drivers/crypto/qce/qcrypto.ko] undefined! >> ERROR: "dma_set_mask" [drivers/crypto/qce/qcrypto.ko] undefined! >> ERROR: "dma_supported" [drivers/crypto/qce/qcrypto.ko] undefined! >> ERROR: "dma_unmap_sg" [drivers/crypto/qce/qcrypto.ko] undefined! >> >> Signed-off-by: Chen Gang >> --- >> drivers/crypto/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig >> index 5ef9ec9..2fb0fdf 100644 >> --- a/drivers/crypto/Kconfig >> +++ b/drivers/crypto/Kconfig >> @@ -422,7 +422,7 @@ source "drivers/crypto/qat/Kconfig" >> >> config CRYPTO_DEV_QCE >> tristate "Qualcomm crypto engine accelerator" >> -depends on ARCH_QCOM || COMPILE_TEST >> +depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM >> select CRYPTO_AES >> select CRYPTO_DES >> select CRYPTO_ECB >> > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/crypto/Kconfig: Let 'DEV_QCE' depend on both HAS_DMA and HAS_IOMEM
Hello all: This patch is obsoleted according to the other discussion thread about IOMEM and COMPILE_TEST. I shall fix it, and maybe not need touch drivers/crypto again, so maybe not need send patch v2 for it. Thanks. On 07/13/2014 11:01 AM, Chen Gang wrote: > 'DEV_QCE' needs both HAS_DMA and HAS_IOMEM, so let it depend on them. > > The related error (with allmodconfig under score): > > MODPOST 1365 modules > ERROR: "devm_ioremap_resource" [drivers/crypto/qce/qcrypto.ko] undefined! > ERROR: "dma_map_sg" [drivers/crypto/qce/qcrypto.ko] undefined! > ERROR: "dma_set_mask" [drivers/crypto/qce/qcrypto.ko] undefined! > ERROR: "dma_supported" [drivers/crypto/qce/qcrypto.ko] undefined! > ERROR: "dma_unmap_sg" [drivers/crypto/qce/qcrypto.ko] undefined! > > Signed-off-by: Chen Gang > --- > drivers/crypto/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig > index 5ef9ec9..2fb0fdf 100644 > --- a/drivers/crypto/Kconfig > +++ b/drivers/crypto/Kconfig > @@ -422,7 +422,7 @@ source "drivers/crypto/qat/Kconfig" > > config CRYPTO_DEV_QCE > tristate "Qualcomm crypto engine accelerator" > - depends on ARCH_QCOM || COMPILE_TEST > + depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM > select CRYPTO_AES > select CRYPTO_DES > select CRYPTO_ECB > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/crypto/Kconfig: Let 'DEV_QCE' depend on both HAS_DMA and HAS_IOMEM
'DEV_QCE' needs both HAS_DMA and HAS_IOMEM, so let it depend on them. The related error (with allmodconfig under score): MODPOST 1365 modules ERROR: "devm_ioremap_resource" [drivers/crypto/qce/qcrypto.ko] undefined! ERROR: "dma_map_sg" [drivers/crypto/qce/qcrypto.ko] undefined! ERROR: "dma_set_mask" [drivers/crypto/qce/qcrypto.ko] undefined! ERROR: "dma_supported" [drivers/crypto/qce/qcrypto.ko] undefined! ERROR: "dma_unmap_sg" [drivers/crypto/qce/qcrypto.ko] undefined! Signed-off-by: Chen Gang --- drivers/crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 5ef9ec9..2fb0fdf 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -422,7 +422,7 @@ source "drivers/crypto/qat/Kconfig" config CRYPTO_DEV_QCE tristate "Qualcomm crypto engine accelerator" - depends on ARCH_QCOM || COMPILE_TEST + depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM select CRYPTO_AES select CRYPTO_DES select CRYPTO_ECB -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kernel/padata.c: share code between CPU_ONLINE and CPU_DOWN_FAILED, same to CPU_DOWN_PREPARE and CPU_UP_CANCELED
On 08/29/2013 12:42 PM, Herbert Xu wrote: > On Fri, Aug 23, 2013 at 12:44:48PM +0200, Steffen Klassert wrote: >> On Thu, Aug 22, 2013 at 02:43:37PM +0800, Chen Gang wrote: >>> Share code between CPU_ONLINE and CPU_DOWN_FAILED, same to >>> CPU_DOWN_PREPARE and CPU_UP_CANCELED. >>> >>> It will fix 2 bugs: >>> >>> "not check the return value of __padata_remove_cpu() and >>> __padata_add_cpu()". >>> "need add 'break' between CPU_UP_CANCELED and CPU_DOWN_FAILED". >>> >>> >>> Signed-off-by: Chen Gang >> >> This looks ok to me, Herbert can you take this one? >> >> Acked-by: Steffen Klassert > > Patch applied. Thanks! > Thank you too. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kernel/padata.c: share code between CPU_ONLINE and CPU_DOWN_FAILED, same to CPU_DOWN_PREPARE and CPU_UP_CANCELED
On 08/23/2013 06:47 PM, Herbert Xu wrote: > On Fri, Aug 23, 2013 at 12:44:48PM +0200, Steffen Klassert wrote: >> On Thu, Aug 22, 2013 at 02:43:37PM +0800, Chen Gang wrote: >>> Share code between CPU_ONLINE and CPU_DOWN_FAILED, same to >>> CPU_DOWN_PREPARE and CPU_UP_CANCELED. >>> >>> It will fix 2 bugs: >>> >>> "not check the return value of __padata_remove_cpu() and >>> __padata_add_cpu()". >>> "need add 'break' between CPU_UP_CANCELED and CPU_DOWN_FAILED". >>> >>> >>> Signed-off-by: Chen Gang >> >> This looks ok to me, Herbert can you take this one? > > Sure. > Thank you all. > Thanks, > Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] kernel/padata.c: share code between CPU_ONLINE and CPU_DOWN_FAILED, same to CPU_DOWN_PREPARE and CPU_UP_CANCELED
On 08/22/2013 02:43 PM, Chen Gang wrote:
> Share code between CPU_ONLINE and CPU_DOWN_FAILED, same to
> CPU_DOWN_PREPARE and CPU_UP_CANCELED.
>
> It will fix 2 bugs:
>
> "not check the return value of __padata_remove_cpu() and
> __padata_add_cpu()".
> "need add 'break' between CPU_UP_CANCELED and CPU_DOWN_FAILED".
>
Do we need more details descriptions ?
If so, could Steffen give more expert details information ?
Thanks.
>
> Signed-off-by: Chen Gang
> ---
> kernel/padata.c | 20
> 1 files changed, 4 insertions(+), 16 deletions(-)
>
> diff --git a/kernel/padata.c b/kernel/padata.c
> index 072f4ee..2f0037a 100644
> --- a/kernel/padata.c
> +++ b/kernel/padata.c
> @@ -846,6 +846,8 @@ static int padata_cpu_callback(struct notifier_block *nfb,
> switch (action) {
> case CPU_ONLINE:
> case CPU_ONLINE_FROZEN:
> + case CPU_DOWN_FAILED:
> + case CPU_DOWN_FAILED_FROZEN:
> if (!pinst_has_cpu(pinst, cpu))
> break;
> mutex_lock(&pinst->lock);
> @@ -857,6 +859,8 @@ static int padata_cpu_callback(struct notifier_block *nfb,
>
> case CPU_DOWN_PREPARE:
> case CPU_DOWN_PREPARE_FROZEN:
> + case CPU_UP_CANCELED:
> + case CPU_UP_CANCELED_FROZEN:
> if (!pinst_has_cpu(pinst, cpu))
> break;
> mutex_lock(&pinst->lock);
> @@ -865,22 +869,6 @@ static int padata_cpu_callback(struct notifier_block
> *nfb,
> if (err)
> return notifier_from_errno(err);
> break;
> -
> - case CPU_UP_CANCELED:
> - case CPU_UP_CANCELED_FROZEN:
> - if (!pinst_has_cpu(pinst, cpu))
> - break;
> - mutex_lock(&pinst->lock);
> - __padata_remove_cpu(pinst, cpu);
> - mutex_unlock(&pinst->lock);
> -
> - case CPU_DOWN_FAILED:
> - case CPU_DOWN_FAILED_FROZEN:
> - if (!pinst_has_cpu(pinst, cpu))
> - break;
> - mutex_lock(&pinst->lock);
> - __padata_add_cpu(pinst, cpu);
> - mutex_unlock(&pinst->lock);
> }
>
> return NOTIFY_OK;
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] kernel/padata.c: share code between CPU_ONLINE and CPU_DOWN_FAILED, same to CPU_DOWN_PREPARE and CPU_UP_CANCELED
Share code between CPU_ONLINE and CPU_DOWN_FAILED, same to
CPU_DOWN_PREPARE and CPU_UP_CANCELED.
It will fix 2 bugs:
"not check the return value of __padata_remove_cpu() and __padata_add_cpu()".
"need add 'break' between CPU_UP_CANCELED and CPU_DOWN_FAILED".
Signed-off-by: Chen Gang
---
kernel/padata.c | 20
1 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 072f4ee..2f0037a 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -846,6 +846,8 @@ static int padata_cpu_callback(struct notifier_block *nfb,
switch (action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
+ case CPU_DOWN_FAILED:
+ case CPU_DOWN_FAILED_FROZEN:
if (!pinst_has_cpu(pinst, cpu))
break;
mutex_lock(&pinst->lock);
@@ -857,6 +859,8 @@ static int padata_cpu_callback(struct notifier_block *nfb,
case CPU_DOWN_PREPARE:
case CPU_DOWN_PREPARE_FROZEN:
+ case CPU_UP_CANCELED:
+ case CPU_UP_CANCELED_FROZEN:
if (!pinst_has_cpu(pinst, cpu))
break;
mutex_lock(&pinst->lock);
@@ -865,22 +869,6 @@ static int padata_cpu_callback(struct notifier_block *nfb,
if (err)
return notifier_from_errno(err);
break;
-
- case CPU_UP_CANCELED:
- case CPU_UP_CANCELED_FROZEN:
- if (!pinst_has_cpu(pinst, cpu))
- break;
- mutex_lock(&pinst->lock);
- __padata_remove_cpu(pinst, cpu);
- mutex_unlock(&pinst->lock);
-
- case CPU_DOWN_FAILED:
- case CPU_DOWN_FAILED_FROZEN:
- if (!pinst_has_cpu(pinst, cpu))
- break;
- mutex_lock(&pinst->lock);
- __padata_add_cpu(pinst, cpu);
- mutex_unlock(&pinst->lock);
}
return NOTIFY_OK;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kernel/padata.c: always check the return value of __padata_remove_cpu() and __padata_add_cpu()
On 08/22/2013 02:05 PM, Steffen Klassert wrote: > On Thu, Aug 22, 2013 at 01:27:16PM +0800, Chen Gang wrote: >> On 08/22/2013 01:11 PM, Steffen Klassert wrote: >>> On Tue, Aug 20, 2013 at 11:44:31AM +0800, Chen Gang wrote: >>>> >>>> If this patch is correct, better to let CPU_ONLINE and CPU_DOWN_FAILED >>>> share the same code. >>>> >>>> And do we need a comment "/* fall through */" between CPU_UP_CANCELED >>>> and CPU_DOWN_FAILED (or it is another bug, need a 'break' statement) ? >>>> >>>> At last, also better to let CPU_DOWN_PREPARE and CPU_UP_CANCELED share >>>> the same code (if need a 'break'), or share the most of code (if "fall >>>> through"). >>>> >>> >>> CPU_ONLINE and CPU_DOWN_FAILED can share the code. Same is true for >>> CPU_DOWN_PREPARE and CPU_UP_CANCELED. >>> >>> Thanks! >>> >>> >> >> Thank you too. >> >> And need I send another patch for it ? >> >> Or just make by yourself (and better to mark me as Reported-by). :-) >> > > You found the problem, feel free to send a patch. > > Thanks, I will send patch v2 for it. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kernel/padata.c: always check the return value of __padata_remove_cpu() and __padata_add_cpu()
On 08/22/2013 01:11 PM, Steffen Klassert wrote: > On Tue, Aug 20, 2013 at 11:44:31AM +0800, Chen Gang wrote: >> >> If this patch is correct, better to let CPU_ONLINE and CPU_DOWN_FAILED >> share the same code. >> >> And do we need a comment "/* fall through */" between CPU_UP_CANCELED >> and CPU_DOWN_FAILED (or it is another bug, need a 'break' statement) ? >> >> At last, also better to let CPU_DOWN_PREPARE and CPU_UP_CANCELED share >> the same code (if need a 'break'), or share the most of code (if "fall >> through"). >> > > CPU_ONLINE and CPU_DOWN_FAILED can share the code. Same is true for > CPU_DOWN_PREPARE and CPU_UP_CANCELED. > > Thanks! > > Thank you too. And need I send another patch for it ? Or just make by yourself (and better to mark me as Reported-by). :-) Thanks. -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kernel/padata.c: always check the return value of __padata_remove_cpu() and __padata_add_cpu()
If this patch is correct, better to let CPU_ONLINE and CPU_DOWN_FAILED share the same code. And do we need a comment "/* fall through */" between CPU_UP_CANCELED and CPU_DOWN_FAILED (or it is another bug, need a 'break' statement) ? At last, also better to let CPU_DOWN_PREPARE and CPU_UP_CANCELED share the same code (if need a 'break'), or share the most of code (if "fall through"). Thanks. On 08/20/2013 11:43 AM, Chen Gang wrote: > When failure occures, __padata_add_cpu() and __padata_remove_cpu() will > return -ENOMEM, which need be noticed in any cases (even in cleaning up > cases). > > Signed-off-by: Chen Gang > --- > kernel/padata.c |8 ++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/kernel/padata.c b/kernel/padata.c > index 072f4ee..6a124cd 100644 > --- a/kernel/padata.c > +++ b/kernel/padata.c > @@ -871,16 +871,20 @@ static int padata_cpu_callback(struct notifier_block > *nfb, > if (!pinst_has_cpu(pinst, cpu)) > break; > mutex_lock(&pinst->lock); > - __padata_remove_cpu(pinst, cpu); > + err = __padata_remove_cpu(pinst, cpu); > mutex_unlock(&pinst->lock); > + if (err) > + return notifier_from_errno(err); > > case CPU_DOWN_FAILED: > case CPU_DOWN_FAILED_FROZEN: > if (!pinst_has_cpu(pinst, cpu)) > break; > mutex_lock(&pinst->lock); > - __padata_add_cpu(pinst, cpu); > + err = __padata_add_cpu(pinst, cpu); > mutex_unlock(&pinst->lock); > + if (err) > + return notifier_from_errno(err); > } > > return NOTIFY_OK; > -- Chen Gang -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kernel/padata.c: always check the return value of __padata_remove_cpu() and __padata_add_cpu()
When failure occures, __padata_add_cpu() and __padata_remove_cpu() will return -ENOMEM, which need be noticed in any cases (even in cleaning up cases). Signed-off-by: Chen Gang --- kernel/padata.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/padata.c b/kernel/padata.c index 072f4ee..6a124cd 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -871,16 +871,20 @@ static int padata_cpu_callback(struct notifier_block *nfb, if (!pinst_has_cpu(pinst, cpu)) break; mutex_lock(&pinst->lock); - __padata_remove_cpu(pinst, cpu); + err = __padata_remove_cpu(pinst, cpu); mutex_unlock(&pinst->lock); + if (err) + return notifier_from_errno(err); case CPU_DOWN_FAILED: case CPU_DOWN_FAILED_FROZEN: if (!pinst_has_cpu(pinst, cpu)) break; mutex_lock(&pinst->lock); - __padata_add_cpu(pinst, cpu); + err = __padata_add_cpu(pinst, cpu); mutex_unlock(&pinst->lock); + if (err) + return notifier_from_errno(err); } return NOTIFY_OK; -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
