li
> Cc: Ray Jui
> Cc: Scott Branden
> Cc: Pavel Machek
> Cc: Ulf Hansson
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: Geert Uytterhoeven
> Cc: Linus Walleij
> Cc: Daniel Lezcano
> Cc: linux-crypto@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
| 3 +--
> drivers/dma/pl330.c | 3 +--
For dmaengine:
Acked-By: Vinod Koul
--
~Vinod
turn true;
> > > -}
> > > #define TXX9_DMA_USE_SIMPLE_CHAIN
> > > #else
> > > static inline bool txx9_dma_have_SMPCHN(void)
> >
> > This doesn't look like it compiles as there's now an #else
> > without an #if
>
> you are ri
On 05-01-21, 15:02, Thomas Bogendoerfer wrote:
> Signed-off-by: Thomas Bogendoerfer
Applied after fixing subsystem name, thanks
--
~Vinod
t; +}
> +#endif
> +
> +static const struct dev_pm_ops npcm_rng_pm_ops = {
> + SET_RUNTIME_PM_OPS(npcm_rng_runtime_suspend,
> +npcm_rng_runtime_resume, NULL)
> + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> + pm_runtime_force_resume)
> +};
> +
> +static const struct of_device_id rng_dt_id[] = {
> + { .compatible = "nuvoton,npcm750-rng", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, rng_dt_id);
> +
> +static struct platform_driver npcm_rng_driver = {
> + .driver = {
> + .name = "npcm-rng",
> + .pm = &npcm_rng_pm_ops,
> + .of_match_table = of_match_ptr(rng_dt_id),
> + },
> + .probe = npcm_rng_probe,
> + .remove = npcm_rng_remove,
> +};
> +
> +module_platform_driver(npcm_rng_driver);
> +
> +MODULE_DESCRIPTION("Nuvoton NPCM Random Number Generator Driver");
> +MODULE_AUTHOR("Tomer Maimon ");
> +MODULE_LICENSE("GPL v2");
> --
> 2.18.0
--
~Vinod
On 16-07-18, 11:20, Vinod Koul wrote:
> This series removes the hwrng qcom driver and replaces it with crypto qcom
> driver and then adds support for Execution Environment (EE) found in v2
> version of the hardware and ACPI support for these
Stephan, Herbert
Any chance this could ma
This driver is for a psedo-rng so should not be added in hwrng.
Remove it so that it's replacement can be added.
Signed-off-by: Vinod Koul
---
drivers/char/hw_random/Kconfig | 13 ---
drivers/char/hw_random/Makefile | 1 -
drivers/char/hw_random/msm-rng.c
Later qcom chips support v2 of the prng, which exposes an EE
(Execution Environment) for OS to use so add new compatible
qcom,prng-ee for this.
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/crypto/qcom,prng.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
Qcom 8996 and later chips features multiple Execution Environments
(EE) and secure world is typically responsible for configuring the
prng.
Add driver data for qcom,prng as 0 and qcom,prng-ee as 1 and use
that to skip initialization routine.
Signed-off-by: Vinod Koul
---
drivers/crypto/qcom
This ports the Qcom prng from older hw_random driver.
No change of functionality and move from hw_random to crypto
APIs is done.
Reviewed-by: Linus Walleij
Signed-off-by: Vinod Koul
---
drivers/crypto/Kconfig| 11 +++
drivers/crypto/Makefile | 1 +
drivers/crypto/qcom-rng.c | 208
configure it.
Signed-off-by: Timur Tabi
Tested-by: Jeffrey Hugo
[port to crypto API]
Signed-off-by: Vinod Koul
---
drivers/crypto/qcom-rng.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/qcom-rng.c b/drivers/crypto/qcom-rng.c
index
tested tags
Changes in v5:
- Update ACPI check and use generic driver data API
Changes in v4:
- Use memcpy for data copy
- Fix trailing bytes copy
- Fix ACPI ID table name
Timur Tabi (1):
crypto: qcom: Add ACPI support
Vinod Koul (5):
hwrng: remove msm hw_random driver
dt-bindings
Now that we are adding new driver for prng in crypto, move the
binding as well.
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/{rng => crypto}/qcom,prng.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{rng => crypto
On 16-07-18, 09:45, Vinod wrote:
> On 14-07-18, 12:16, Linus Walleij wrote:
> > On Mon, Jul 9, 2018 at 8:20 AM Vinod Koul wrote:
>
> > > +#include
> >
> > Do you need this? It seems like a platform device fair and square.
>
> It was required for of_devi
On 14-07-18, 12:16, Linus Walleij wrote:
> On Mon, Jul 9, 2018 at 8:20 AM Vinod Koul wrote:
>
> > This ports the Qcom prng from older hw_random driver.
> >
> > No change of functionality and move from hw_random to crypto
> > APIs is done.
> >
> > Signed
On 10-07-18, 11:27, Jeffrey Hugo wrote:
> On 7/9/2018 12:19 AM, Vinod Koul wrote:
> > From: Timur Tabi
> >
> > Add support for probing on ACPI systems, with ACPI HID QCOM8160.
> >
> > On ACPI systems, clocks are always enabled, the PRNG should
> > already
Later qcom chips support v2 of the prng, which exposes an EE
(Execution Environment) for OS to use so add new compatible
qcom,prng-ee for this.
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/crypto/qcom,prng.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
This ports the Qcom prng from older hw_random driver.
No change of functionality and move from hw_random to crypto
APIs is done.
Signed-off-by: Vinod Koul
---
drivers/crypto/Kconfig| 11 +++
drivers/crypto/Makefile | 1 +
drivers/crypto/qcom-rng.c | 208
Qcom 8996 and later chips features multiple Execution Environments
(EE) and secure world is typically responsible for configuring the
prng.
Add driver data for qcom,prng as 0 and qcom,prng-ee as 1 and use
that to skip initialization routine.
Signed-off-by: Vinod Koul
---
drivers/crypto/qcom
configure it.
Signed-off-by: Timur Tabi
[port to crypto API]
Signed-off-by: Vinod Koul
---
drivers/crypto/qcom-rng.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/qcom-rng.c b/drivers/crypto/qcom-rng.c
index f1bd86acaf9d..8118d4cd93b2 100644
Now that we are adding new driver for prng in crypto, move the
binding as well.
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/{rng => crypto}/qcom,prng.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{rng => crypto
This driver is for a psedo-rng so should not be added in hwrng.
Remove it so that it's replacement can be added.
Signed-off-by: Vinod Koul
---
drivers/char/hw_random/Kconfig | 13 ---
drivers/char/hw_random/Makefile | 1 -
drivers/char/hw_random/msm-rng.c
for data copy
- Fix trailing bytes copy
- Fix ACPI ID table name
Timur Tabi (1):
crypto: qcom: Add ACPI support
Vinod Koul (5):
hwrng: remove msm hw_random driver
dt-bindings: crypto: Move prng binding to crypto
crypto: Add Qcom prng driver
dt-bindings: crypto: Add new compatible qcom
On 07-07-18, 13:05, Timur Tabi wrote:
> On 7/5/18 1:07 AM, Vinod wrote:
> > Yes we can add driver data in ACPI ID as well so code can be:
> >
> > if (!has_acpi_companion(&pdev->dev)) {
> > rng->clk = devm_clk_get(&pdev->dev,
On 05-07-18, 07:23, Timur Tabi wrote:
> On 7/5/18 1:07 AM, Vinod wrote:
> > Meanwhile any word from testing on ACPI systems?
>
> Jeff Hugo is handling that for me. Since it's a whole new API, he's had to
> start over.
Okay great, I have already been thru the hoops,
On 04-07-18, 09:46, Timur Tabi wrote:
> On 7/4/18 6:44 AM, Vinod Koul wrote:
> > + if (has_acpi_companion(&pdev->dev)) {
> > + rng->skip_init = 1;
> > + } else {
> > + rng->clk = devm_clk_get(&pdev->de
Hi Stephan,
On 04-07-18, 18:02, Stephan Mueller wrote:
> Am Dienstag, 3. Juli 2018, 08:04:31 CEST schrieb Vinod Koul:
> > +static int qcom_rng_seed(struct crypto_rng *tfm, const u8 *seed,
> > +unsigned int slen)
> > +{
> > + return 0;
> > +}
This ports the Qcom prng from older hw_random driver.
No change of functionality and move from hw_random to crypto
APIs is done.
Signed-off-by: Vinod Koul
---
drivers/crypto/Kconfig| 11 +++
drivers/crypto/Makefile | 1 +
drivers/crypto/qcom-rng.c | 208
Later qcom chips support v2 of the prng, which exposes an EE
(Execution Environment) for OS to use so add new compatible
qcom,prng-ee for this.
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/crypto/qcom,prng.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
Timur Tabi (1):
crypto: qcom: Add ACPI support
Vinod Koul (5):
hwrng: remove msm hw_random driver
dt-bindings: crypto: Move prng binding to crypto
crypto: Add Qcom prng driver
dt-bindings: crypto: Add new compatible qcom,prng-ee
crypto: qcom: Add support for prng-ee
.../bindings/{rng
Now that we are adding new driver for prng in crypto, move the
binding as well.
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/{rng => crypto}/qcom,prng.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{rng => crypto
This driver is for a pseudo-rng so should not be added in hwrng.
Remove it so that it's replacement can be added.
Signed-off-by: Vinod Koul
---
drivers/char/hw_random/Kconfig | 13 ---
drivers/char/hw_random/Makefile | 1 -
drivers/char/hw_random/msm-rng.c
Qcom 8996 and later chips features multiple Execution Environments
(EE) and secure world is typically responsible for configuring the
prng.
Add driver data for qcom,prng as 0 and qcom,prng-ee as 1 and use
that to skip initialization routine.
Signed-off-by: Vinod Koul
---
drivers/crypto/qcom
configure it.
Signed-off-by: Timur Tabi
[port to crypto API]
Signed-off-by: Vinod Koul
---
drivers/crypto/qcom-rng.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/qcom-rng.c b/drivers/crypto/qcom-rng.c
index f1bd86acaf9d..385352e200db
On 04-07-18, 09:40, Vinod wrote:
> Hi Stephan,
>
> On 03-07-18, 15:28, Stephan Mueller wrote:
> > Am Dienstag, 3. Juli 2018, 08:04:31 CEST schrieb Vinod Koul:
> > > +static int qcom_rng_read(struct qcom_rng *rng, void *data, size_t max)
> > > +{
> > > +
On 03-07-18, 11:08, Jeffrey Hugo wrote:
> On 7/3/2018 12:04 AM, Vinod Koul wrote:
> > +#if IS_ENABLED(CONFIG_ACPI)
> > +static const struct acpi_device_id qcom_rng_acpi_match[] = {
> > + {
> > + .id = "QCOM8160",
> > + },
>
On 03-07-18, 09:10, Timur Tabi wrote:
> On 7/3/18 1:04 AM, Vinod Koul wrote:
> > Add support for probing on ACPI systems, with ACPI HID QCOM8160.
> >
> > On ACPI systems, clocks are always enabled, the PRNG should
> > already be enabled, and the register region is rea
Hi Stephan,
On 03-07-18, 15:28, Stephan Mueller wrote:
> Am Dienstag, 3. Juli 2018, 08:04:31 CEST schrieb Vinod Koul:
> > +static int qcom_rng_read(struct qcom_rng *rng, void *data, size_t max)
> > +{
> > + size_t currsize = 0;
> > + u32 *retdata = data;
>
&
Now that we are adding new driver for prng in crypto, move the
binding as well.
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/{rng => crypto}/qcom,prng.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{rng => crypto
Later qcom chips support v2 of the prng, which exposes an EE
(Execution Enviornment) for OS to use so add new compatible
qcom,prng-ee for this.
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/crypto/qcom,prng.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
This ports the Qcom prng from older hw_random driver.
No change of functionality and move from hw_random to crypto
APIs is done.
Signed-off-by: Vinod Koul
---
drivers/crypto/Kconfig| 11 +++
drivers/crypto/Makefile | 1 +
drivers/crypto/qcom-rng.c | 208
This series removes the hwrng qcom driver and replaces it with crypto qcom
driver and then adds support for Execution Environment (EE) found in v2
version of the hardware and ACPI support for these
Timur Tabi (1):
crypto: qcom: Add ACPI support
Vinod Koul (5):
hwrng: remove msm hw_random
configure it.
Signed-off-by: Timur Tabi
[port to crypto API]
Signed-off-by: Vinod Koul
---
drivers/crypto/qcom-rng.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/qcom-rng.c b/drivers/crypto/qcom-rng.c
index fdbbcac7bcb8
Qcom 8996 and later chips features multiple Execution Environments
(EE) and secure world is typically responsible for configuring the
prng.
Add driver data for qcom,prng as 0 and qcom,prng-ee as 1 and use
that to skip initialization routine.
Signed-off-by: Vinod Koul
---
drivers/crypto/qcom
This driver is for a psedo-rng so should not be added in hwrng.
Remove it so that it's replacement can be added.
Signed-off-by: Vinod Koul
---
drivers/char/hw_random/Kconfig | 13 ---
drivers/char/hw_random/Makefile | 1 -
drivers/char/hw_random/msm-rng.c
I think Stan did bring this point earlier that PRNG is compliant to
FIPS-140-2. So it can be used by rng clients for various purposes but
should not be fed to dev/random as the hw_random does.
Herbert, can you please confirm..
--
~Vinod
t will be
> allocated and deallocated frequently.
Right, that is how I visualized it.
Is there a way where we can tweak the register API to pass hw_resource
pointer and get that back? Would that work with the security model in
crypto.
I do not like globals and somehow don't feel that we should do it that
way
Thanks for the quick look on the code.
~Vinod
7;t have pdev to read hw_resource etc.. so would still
need to get that.
FWIW here is the code I wrote:
https://git.linaro.org/people/vinod.koul/kernel.git/commit/?h=topic/rng_v2&id=feb23a41afb0d4cf42a2825b84a43dbc9a49e8b9
--
~Vinod
On 22-06-18, 19:57, Stephan Mueller wrote:
> Hi
>
>
> > Am 22.06.2018 um 16:50 schrieb Herbert Xu :
> >
> >> On Fri, Jun 22, 2018 at 08:18:09PM +0530, Vinod wrote:
> >>
> >> Okay I am doing the port taking the exynos-rng as a ref.
> &g
On 25-06-18, 13:06, Rob Herring wrote:
> On Tue, Jun 19, 2018 at 03:24:29PM +0530, Vinod Koul wrote:
> > Later qcom chips support v2 of the prng, so add new compatible
> > qcom,prng-v2 for this.
> >
> > Signed-off-by: Vinod Koul
> > ---
> >
ardware-
> > > generated seed to power a PRNG?
> >
> > I believe it is the second one. Isn't the second one SP 800-90A?
>
> In that case it should switch over to algif_rng.
Okay I am doing the port taking the exynos-rng as a ref.
Question is how to test it, how is one supposed to exercise the rng, any
test utils/apps for that? Sorry for noob question, new to crypto
interfaces.
--
~Vinod
7;s
> only a couple lines that are really ACPI-specific.
Sure I will add/port you patch on top.
--
~Vinod
On 21-06-18, 23:46, Timur Tabi wrote:
> On 6/21/18 11:44 PM, Vinod wrote:
> > So this make me think you should do 2 level support for ACPI, one ACPI
> > support and one V2 support where we dont touch CONFIG register. That way
> > both regions will work
>
> The ACPI sys
On 21-06-18, 23:26, Timur Tabi wrote:
> On 6/21/18 11:23 PM, Vinod wrote:
> > On 21-06-18, 10:17, Timur Tabi wrote:
> > > Add support for probing on ACPI systems, with ACPI HID QCOM8160.
> > >
> > > On ACPI systems, clocks are always enabled, the PRNG shou
On 21-06-18, 10:17, Timur Tabi wrote:
> On Tue, Jun 19, 2018 at 4:54 AM, Vinod Koul wrote:
> > This series adds support for newer version of hwrng as found in
> > Qualcomm SoCs. To do that add new v2 compatible string and driver_data
> > values for v2.
>
> It's
On 21-06-18, 23:18, Timur Tabi wrote:
> On 6/21/18 11:17 PM, Vinod wrote:
> > this should be a separate patch
>
> What exactly should be a separate patch? This part?
>
> - rng->hwrng.name = KBUILD_MODNAME,
> - rng->hwrng.init = msm_rng_init,
> - rng
rng_driver = {
> .probe = msm_rng_probe,
> .driver = {
> .name = KBUILD_MODNAME,
> .of_match_table = of_match_ptr(msm_rng_of_match),
> + .acpi_match_table = ACPI_PTR(msm_rng_acpi_match),
> }
> };
> module_platform_driver(msm_rng_driver);
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.
--
~Vinod
> @@ -148,10 +190,11 @@ static int msm_rng_probe(struct platform_device *pdev)
> if (IS_ERR(rng->clk))
> return PTR_ERR(rng->clk);
>
> - rng->hwrng.name = KBUILD_MODNAME,
> - rng->hwrng.init = msm_rng_init,
> - rng->hwrng.cleanup = msm_rng_cleanup,
> - rng->hwrng.read = msm_rng_read,
> + rng->hwrng.name = KBUILD_MODNAME;
> + rng->hwrng.init = msm_rng_init;
> + rng->hwrng.cleanup = msm_rng_cleanup;
> + rng->hwrng.read = msm_rng_read;
this should be a separate patch
--
~Vinod
Hi PrasannaKumar,
On 20-06-18, 23:15, PrasannaKumar Muralidharan wrote:
> Hi Vinod,
>
> On 20 June 2018 at 11:02, Vinod wrote:
> > On 19-06-18, 22:28, Herbert Xu wrote:
> >> On Mon, Jun 18, 2018 at 07:42:59PM +0530, Vinod Koul wrote:
> >> > Qcom 8996 and
qce/dma.c
drivers/crypto/stm32/stm32-hash.c
drivers/crypto/ux500/cryp/cryp_core.c
drivers/crypto/ux500/hash/hash_core.c
>
> I also don't see how that complicates things much further.
>
> What is the rationale for using the crypto h/w as a dma engine anyway?
> Are there supporting performance figures?
that is a very good question, perf does matter. Given that we have many
folks using it, I think it would help, but yes nothing better than numbers
speak for themselves.
--
~Vinod
on for the reader of an
> already complex driver.
>
> 2. I wanted this driver to be tracked by the dma engine team. They have
> the right expertise to provide adequate feedback. If all the code was in
> the crypto directory they wouldn't know about this driver or any
> subsequent changes to it.
These are very good reasons.
We already have one DMA implementation drivers/crypto/ccp/ccp-dmaengine.c
which was sneaked past us and put into kernel with proper review!
On the other hand we have *bunch* of dmaengine users in crypto subsystem
which use dmaengine drivers and APIs and are good citizens. It allows folks
to share code with other usages of dmaengine and the usual arguments for
common code and frameworks...
If there are enough users we can add up a crypto-dmaengine lib which
programs dma controller for crypto users and avoid open coding for everyone.
for example sound-dmaengine layers does that...
HTH
--
~Vinod
On Wed, Nov 08, 2017 at 02:36:31PM +, Radu Andrei Alexe wrote:
> On 10/31/2017 2:01 PM, Vinod Koul wrote:
> > On Mon, Oct 30, 2017 at 03:46:54PM +0200, Horia Geantă wrote:
> >> +/*
> >> + * caam support for SG DMA
> >> + *
> >> + * Copyright 2016 Fr
;device_prep_dma_memcpy = caam_dma_prep_memcpy;
> + dma_dev->device_free_chan_resources = caam_dma_free_chan_resources;
> +
> + err = dma_async_device_register(dma_dev);
> + if (err) {
> + dev_err(dev, "Failed to register CAAM DMA engine\n");
> + goto jr_bind_err;
> + }
> +
> + dev_info(dev, "caam dma support with %d job rings\n", bonds);
that is very noisy
> +MODULE_LICENSE("Dual BSD/GPL");
> +MODULE_DESCRIPTION("NXP CAAM support for SG DMA");
> +MODULE_AUTHOR("NXP Semiconductors");
No MODULE_ALIAS, how did you load the driver
--
~Vinod
On Fri, Oct 27, 2017 at 12:20:32PM +, Horia Geantă wrote:
> On 10/27/2017 2:36 PM, Koul, Vinod wrote:
> >> On 10/26/2017 1:01 PM, Radu Alexe wrote:
> >>> This patch-set introduces a new DMA memcpy driver based on the DMA
> >>> capabilities of the CAAM crypt
the CAAM DMA driver.
> >
> > Patch 4.
> > Adds the CAAM DMA memcpy driver.
> >
> > Patch 1 and 3 should be merged by the crypto maintainers, patch 2 by
> > devicetree maintainers and patch 4 by the DMA maintainers.
> I would go with all the patches through the dmaengine tree.
Good call, but no one CCed dmaengine folks on this series!
--
~Vinod
tead
> of PQ disk coefficient. To address this, we have added raid_gflog
> table which will help driver to convert PQ disk coefficient to PQ
> disk position.
Applied, now
--
~Vinod
On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote:
> Hi Vinod,
>
> The Broadcom FlexRM patchset have been
> merged in v4.11.
>
> I think you now can take this patchset in next
> merge window. Right??
Sure, please rebase and resend after -rc1 is out
--
~Vinod
On Wed, Mar 29, 2017 at 11:35:43AM +0530, Anup Patel wrote:
> On Tue, Mar 21, 2017 at 2:48 PM, Vinod Koul wrote:
> > On Tue, Mar 21, 2017 at 02:17:21PM +0530, Anup Patel wrote:
> >> On Tue, Mar 21, 2017 at 2:00 PM, Vinod Koul wrote:
> >> > On Mon, Mar 06, 2017 a
On Tue, Mar 21, 2017 at 02:17:21PM +0530, Anup Patel wrote:
> On Tue, Mar 21, 2017 at 2:00 PM, Vinod Koul wrote:
> > On Mon, Mar 06, 2017 at 03:13:24PM +0530, Anup Patel wrote:
> >> The Broadcom SBA RAID is a stream-based device which provides
> >> RAID5/6 offload.
rt"
Okay I applied and was about to push when I noticed this :(
So what is the status of this..?
--
~Vinod
o as done
for dma_get_slave_caps(). you can add dma_get_pq_caps() so that clients (md)
in this case would know the HW capability.
> I agree capability checks should be done once in Linux MD but I don't
> see why this has to be part of BCM-SBA-RAID driver patches. We need
> separate patchsets to address limitations of async_tx framework.
>
> Regards,
> Anup
--
~Vinod
dma_tx_state *txstate)
> >> +{
> >> + int mchan_idx;
> >> + enum dma_status ret;
> >> + struct sba_device *sba = to_sba_device(dchan);
> >> +
> >> + ret = dma_cookie_status(dchan, cookie, txstate);
> >> + if (ret == DMA_COMPLETE)
> >> + return ret;
> >> +
> >> + for (mchan_idx = 0; mchan_idx < sba->mchans_count; mchan_idx++)
> >> + mbox_client_peek_data(sba->mchans[mchan_idx]);
> >
> > what is this achieving?
>
> The mbox_client_peek_data() is a hint to mailbox controller driver
> to check for available messages.
>
> This gives good performance improvement when some DMA client
> code is polling using tx_status() callback.
Then why do it before and then check status.
--
~Vinod
dev->cap_mask);
> + dma_cap_set(DMA_XOR, dma_dev->cap_mask);
> + dma_cap_set(DMA_PQ, dma_dev->cap_mask);
> +
> + /*
> + * Set mailbox channel device as the base device of
> + * our dma_device because the actual memory accesses
> + * will be done by mailbox controller
> + */
> + dma_dev->dev = sba->mbox_dev;
> +
> + /* Set base prep routines */
> + dma_dev->device_alloc_chan_resources = sba_alloc_chan_resources;
> + dma_dev->device_free_chan_resources = sba_free_chan_resources;
> + dma_dev->device_issue_pending = sba_issue_pending;
> + dma_dev->device_tx_status = sba_tx_status;
Please add terminate callback support, also add the capabilities, we need to
advertise that and use in clients
Also you can simplify bunch of code by using virt-chan support for managing
channels and descriptors
--
~Vinod
mple, it should have
been in dmaengine directory. Not sure why it was addded in crypto :(
Thanks
--
~Vinod
--
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
On Fri, Apr 29, 2016 at 10:09:07PM +0200, Julia Lawall wrote:
> Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch
> that makes this transformation is as follows: (http://coccinelle.lip6.fr/)
Applied all dmaengine patches
--
~Vinod
--
To unsubscribe from this list
page()'.
> >>
> >> With this patch, I no longer get any other build errors from the
> >> page_ref patch, so hopefully we can assume that it's always wrong
> >> to call any of those functions from __exit code, and that no other
> >> driver does i
eed slave parameters, knowing the hw and reason for this (firmware
download to DSP memory), this doesn't qualify for slave case.
In fact filter function doesn't need a channel, any channel in this
controller will be good
--
~Vinod
--
To unsubscribe from this list: send the line "unsu
On Thu, Aug 20, 2015 at 12:31:44PM +0530, Rameshwar Sahu wrote:
> Hi Vinod,
>
> On Thu, Aug 20, 2015 at 11:18 AM, Vinod Koul wrote:
> > On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
> >> + nents = sg_nents(req->src);
> >> +
On Thu, Aug 20, 2015 at 12:23:50PM +0530, Rameshwar Sahu wrote:
> Hi Vinod,
>
> On Thu, Aug 20, 2015 at 11:10 AM, Vinod Koul wrote:
> > On Thu, Jul 30, 2015 at 05:41:06PM +0530, Rameshwar Prasad Sahu wrote:
> >> + /* Invalidate unused source address field */
&g
On Thu, Aug 20, 2015 at 11:59:07AM +0530, Rameshwar Sahu wrote:
> Hi Vinod,
>
> On Thu, Aug 20, 2015 at 10:56 AM, Vinod Koul wrote:
> > On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
> >> This patch adds support for new feature CRC32C calcu
req->result,
> +flags);
We should add helper for this
--
~Vinod
--
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
ma->csr_ring + XGENE_DMA_RING_ID_BUF);
> + ring_id_buf = XGENE_DMA_RING_ID_BUF_SETUP(ring->num);
> +
> + if (ring->is_bufpool)
> + ring_id_buf |= XGENE_DMA_RING_IS_BUFPOOL;
> +
> + iowrite32(ring_id_buf, ring->pdma->csr_ring +
> +
On Thu, Jul 30, 2015 at 05:41:05PM +0530, Rameshwar Prasad Sahu wrote:
> This patch adds support for new feature CRC32C calculation in
> dmaengine framework.
Looks okay can you please update Documentation also
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe l
On Mon, Jun 22, 2015 at 02:31:00PM +0300, Peter Ujfalusi wrote:
> On 06/12/2015 03:58 PM, Vinod Koul wrote:
> > Sorry this slipped thru
>
> I was away for a week anyways ;)
>
> > Thinking about it again, I think we should coverge to two APIs and mark the
> >
On Thu, Jun 04, 2015 at 06:58:06PM +0300, Peter Ujfalusi wrote:
> Vinod,
>
> On 06/02/2015 03:55 PM, Vinod Koul wrote:
> > On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote:
> >> On 05/29/2015 01:18 PM, Vinod Koul wrote:
> >>> On Fri, May
On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote:
> On 05/29/2015 01:18 PM, Vinod Koul wrote:
> > On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
> >> On Fri, May 29, 2015 at 11:33 AM, Vinod Koul wrote:
> >>> On Tue, May 26, 2
On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
> On Fri, May 29, 2015 at 11:33 AM, Vinod Koul wrote:
> > On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote:
> >> dma_request_slave_channel_compat() 'eats' up the returned error codes
will return with error
> code in case of failure and will pass the -EPROBE_DEFER to the caller in
> case dma_request_slave_channel_reason() returned with it.
This is okay but am worried about one more warpper, how about fixing
dma_request_slave_channel_compat()
--
~Vinod
>
so add the necessary includes
> to fix ppc4xx builds.
>
> Signed-off-by: Rob Herring
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Tejun Heo
> Cc: Matt Mackall
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Vinod Koul
> Cc
()
> > > functions before doing any DMA mapping. Add this required call to
> > > the AMBA PL08x driver.
> > ^--- copy and paste error - should of course be PL330
>
> Fixed, thanks.
with fixed changelog...
Acked-by: Vinod Koul
~Vinod
--
this driver.
>
> Signed-off-by: Russell King
Acked-by: Vinod Koul
This also brings me question that should we force the driver to use the
dma_set_mask_and_coherent() API or they have below flexiblity too?
~Vinod
> ---
> drivers/dma/edma.c |6 ++
> 1 files changed, 2
On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
> The DMA API requires drivers to call the appropriate dma_set_mask()
> functions before doing any DMA mapping. Add this required call to
> the AMBA PL08x driver.
>
> Signed-off-by: Russell King
Acked-by: Vino
> of the statement OR:ing with 0.
> >
> > Cc: Vinod Koul
> > Cc: Dan Williams
> > Cc: Per Forlin
> > Cc: Rabin Vincent
> > Signed-off-by: Lee Jones
>
> Tentatively applied. Missing Vinod's ACK.
Acked-by: Vinod Koul
--
~Vinod
--
To unsu
On Thu, May 16, 2013 at 08:35:53AM +0100, Lee Jones wrote:
> On Thu, 16 May 2013, Vinod Koul wrote:
>
> > On Wed, May 15, 2013 at 10:51:57AM +0100, Lee Jones wrote:
> > > +u8 d40_width_to_bits(enum dma_slave_buswidth width)
> > > +{
> > > +
On Thu, May 16, 2013 at 08:25:57AM +0100, Lee Jones wrote:
> On Thu, 16 May 2013, Vinod Koul wrote:
>
> > On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote:
> > > All configuration left in d40_phy_cfg() is runtime configurable and
> > > there
On Thu, May 16, 2013 at 08:06:38AM +0100, Lee Jones wrote:
> On Thu, 16 May 2013, Vinod Koul wrote:
>
> > On Wed, May 15, 2013 at 10:51:54AM +0100, Lee Jones wrote:
> > > STEDMA40_*_TO_* direction definitions are identical in all but name to
> > > the pre-defined
On Wed, May 15, 2013 at 10:51:33AM +0100, Lee Jones wrote:
> 'struct stedma40_half_channel_info's header comment says that it's
> called 'struct stedma40_chan_cfg'. Let's straighten that out.
>
> Signed-off-by: Lee Jones
> ---
Acked-by: Vinod Koul
> elevates a large burden from platform data in the way of a look-up
> table.
>
> Signed-off-by: Lee Jones
> ---
Good code size reduction, always a good template for code improvements
Acked-by: Vinod Koul
--
~Vinod
> drivers/dma/ste_dma40.c | 51
> ++---
On Wed, May 15, 2013 at 10:51:31AM +0100, Lee Jones wrote:
> Addresses are now stored in local data structures and are easy to
> obtain, thus a specialist function used to fetch them is now surplus
> to requirement.
>
> Signed-off-by: Lee Jones
> ---
Acked-by: Vinod Koul
--
On Wed, May 15, 2013 at 10:51:26AM +0100, Lee Jones wrote:
> Using the dmaengine API, allocating and configuring a channel are two
> separate actions. Here we're removing logical channel configuration from
> the channel allocating routines.
>
> Cc: Vinod Koul
> Cc: Dan Wil
1 - 100 of 111 matches
Mail list logo
