On Sun, Jun 22, 2014 at 02:23:15PM +0200, Marek Vasut wrote:
> On Sunday, June 22, 2014 at 01:58:08 PM, Corentin LABBE wrote:
> [...]
> > >> + * This program is free software; you can redistribute it and/or modify
> > >> + * it under the terms of the GNU General Public License as published by
> > >
On Tue, Jun 10, 2014 at 02:43:14PM +0200, LABBE Corentin wrote:
> +int sunxi_aes_poll(struct ablkcipher_request *areq)
> +{
...
> + if (areq->src == NULL || areq->dst == NULL) {
> + dev_err(ss->dev, "ERROR: Some SGs are NULL %u\n", areq->nbytes);
> + return -1;
You retu
On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote:
> Russell King writes:
>
> > ARMv6 and greater introduced a new instruction ("bx") which can be used
> > to return from function calls. Recent CPUs perform better when the
> > "bx lr" instruction is used rather than the "mov pc, lr"
On Mon, Oct 17, 2016 at 01:28:00PM +0200, Marcus Folkesson wrote:
> i.MX6UL does only require three clocks to enable CAAM module.
>
> Signed-off-by: Marcus Folkesson
> Acked-by: Rob Herring
> Reviewed-by: Horia Geantă
> ---
> .../devicetree/bindings/crypto/fsl-sec4.txt| 20
On Sat, Oct 29, 2016 at 11:08:36AM +0100, Ard Biesheuvel wrote:
> On 18 October 2016 at 11:52, Ard Biesheuvel wrote:
> > Wire up the generic support for exposing CPU feature bits via the
> > modalias in /sys/device/system/cpu. This allows udev to automatically
> > load modules for things like cryp
Please include Thomas in this.
On Wed, Nov 09, 2016 at 10:46:21AM +0200, Horia Geantă wrote:
> This reverts commit 66d2e2028091a074aa1290d2eeda5ddb1a6c329c.
>
> Quoting from Russell's findings:
> https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg21136.html
>
> [quote]
> Okay, I've re-
On Mon, Jan 02, 2017 at 09:06:04PM +, Ard Biesheuvel wrote:
> On 31 October 2016 at 16:13, Russell King - ARM Linux
> wrote:
> > On Sat, Oct 29, 2016 at 11:08:36AM +0100, Ard Biesheuvel wrote:
> >> On 18 October 2016 at 11:52, Ard Biesheuvel
> >> wrote:
>
On Sat, Jan 14, 2017 at 04:24:35PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> allyesconfig and multi_v7_defconfig fail to build on recent linux-next
> on GCC 6.2.0.
>
> Errors:
> ../arch/arm/crypto/aes-cipher-core.S: Assembler messages:
> ../arch/arm/crypto/aes-cipher-core.S:21: Error: selected
On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote:
> Many users of kernel async. crypto services have a pattern of
> starting an async. crypto op and than using a completion
> to wait for it to end.
>
> This patch set simplifies this common use case in two ways:
>
> First, by separ
On Sat, Nov 04, 2017 at 08:37:31PM +0100, Andrew Lunn wrote:
> Hi Florian
>
> > > >> + /* Clock is optional on most platforms */
> > > >> + priv->clk = devm_clk_get(dev, NULL);
> > > >> + if (IS_ERR(priv->clk))
> > > >> + priv->clk = NULL;
> > > >
> > > > at least in c
On Wed, Nov 08, 2017 at 08:19:57PM +0100, Stefan Wahren wrote:
> Hi Florian,
> > + /* Clock is optional on most platforms */
> > + priv->clk = devm_clk_get(dev, NULL);
> > +
>
> At least EPROBE_DEFER should be handled here:
>
> if (IS_ERR(priv->clk) && PTR_ERR(priv->clk) == -EPROBE_DEFER)
>
On Thu, Mar 17, 2016 at 06:02:15PM -0400, Sinan Kaya wrote:
> Getting ready to remove dma_to_phys API. Drivers should not be
> using this API for DMA operations. Instead, they should go
> through the dma_map or dma_alloc APIs.
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/crypto/marvell/cesa.c |
On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote:
> What is the correct way? I don't want to write engine->sram_dma = sram
Well, what the driver _is_ wanting to do is to go from a CPU physical
address to a device DMA address. phys_to_dma() looks like the correct
thing there to
On Thu, Mar 31, 2016 at 02:29:42PM +0200, Boris Brezillon wrote:
> sg_alloc_table_from_buf() provides an easy solution to create an sg_table
> from a virtual address pointer. This function takes care of dealing with
> vmallocated buffers, buffer alignment, or DMA engine limitations (maximum
> DMA t
On Thu, Mar 31, 2016 at 04:45:57PM +0200, Boris Brezillon wrote:
> Hi Russell,
>
> On Thu, 31 Mar 2016 15:14:13 +0100
> Russell King - ARM Linux wrote:
>
> > On Thu, Mar 31, 2016 at 02:29:42PM +0200, Boris Brezillon wrote:
> > > sg_alloc_table_from_buf() provides
Hi,
When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
caam, I get this:
$ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5
http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedte
This is a re-post (with hopefully bugs fixed from December's review).
Untested, because AF_ALG appears to be broken in 4.8-rc1. Maybe
someone can provide some hints how to test using tcrypt please?
Here are further imx-caam updates that I've had since before the
previous merge window. Please rev
On Mon, Aug 08, 2016 at 01:47:33PM -0400, Jeffrey Walton wrote:
> > When trying to use the openssl AF_ALG module with 4.8-rc1 with imx
> > caam, I get this:
> >
> > $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5
> > > ...
> > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> >
On Mon, Aug 08, 2016 at 08:30:32PM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 20:18:32 CEST schrieb Stephan Mueller:
>
> Hi Stephan,
>
> > Am Montag, 8. August 2016, 17:44:27 CEST schrieb Russell King - ARM Linux:
> >
> > Hi Russell,
> >
&
On Tue, Aug 09, 2016 at 11:18:20AM +0800, Herbert Xu wrote:
> Russell King - ARM Linux wrote:
> > Testing that code on 4.8-rc (and 4.7 fwiw) gives:
> >
> > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3
> > bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\
On Tue, Aug 09, 2016 at 03:14:02PM +0800, Herbert Xu wrote:
> On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote:
> >
> > I thought I gave the commands and link to your example code. The
> > openssl case is md5, though sha* also gives the same result.
Hi,
While testing AF_ALG with openssl af-alg-rr, I've found that:
OPENSSL_CONF=/shared/crypto/openssl-imx.cnf openssl dgst -sha1 http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from t
On Fri, Sep 16, 2016 at 02:01:00PM +, Cata Vasile wrote:
> Hi,
>
> We've tried to test and benchmark your submitted work[1].
>
> Cryptographic offloading is also used in IPsec in the Linux Kernel. In
> heavy traffic scenarios, the NIC driver competes with the crypto device
> driver. Most NICs
Okay, I've re-tested, using a different way of measuring, because using
openssl speed is impractical for off-loaded engines. I've decided to
use this way to measure the performance:
dd if=/dev/zero bs=1048576 count=128 | /usr/bin/time openssl dgst -md5
For the threaded IRQs case gives:
0.05user
On Tue, Sep 20, 2016 at 10:10:20PM +0200, Thomas Gleixner wrote:
> On Tue, 20 Sep 2016, Russell King - ARM Linux wrote:
> > which corresponds to an 8% slowdown for the threaded IRQ case. So,
> > tasklets are indeed faster than threaded IRQs.
>
> Fair enough.
>
> &
On Wed, May 20, 2015 at 07:00:25AM -0500, Suravee Suthikulanit wrote:
> On 5/20/2015 4:34 AM, Catalin Marinas wrote:
> >We have a dummy of_dma_configure() already when !CONFIG_OF, otherwise
> >we would need #ifndef here. I already replied, I think for other
> >architectures we need this check to av
On Mon, Jun 15, 2015 at 05:59:07PM +0200, Steffen Trumtrar wrote:
> I'm working on CAAM support for the ARM-based i.MX6 SoCs. The current
> drivers/crypto/caam driver only works for PowerPC AFAIK.
> Actually, there isn't that much to do, to get support for the i.MX6 but
> one patch breaks the drive
On Mon, Jun 15, 2015 at 06:33:17PM +0200, Jon Nettleton wrote:
> Funny enough I tackled this problem over the weekend as well. My
> approach was to switch the driver over to use the *_relaxed() io
> functions and then special case the bits missing from the various
> ARCHs. Basically adding setbit
On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote:
> On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote:
> >
> > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > +DMA_TO_DEVICE);
> > + if (!ret)
> > + return -ENOMEM;
> > +
> >
On Thu, Jun 18, 2015 at 11:33:24AM +0200, Boris Brezillon wrote:
> Hi Russel,
>
> On Thu, 18 Jun 2015 10:04:00 +0100
> Russell King - ARM Linux wrote:
>
> > On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote:
> > > On Wed, Jun 17, 2015 at 09:45:33A
On Fri, Jul 03, 2015 at 11:43:05AM +0200, Boris Brezillon wrote:
> Which led us to think that this could be related to a non cache-line
> aligned buffer problem: if we share the cache line with someone
> modifying its data during the DMA transfer, we could experience data
> loss when the cpu decide
BTW, off-topic for this thread... but I notice from Mark Brown's builder
that mv_cesa is causing build errors in mainline now:
arm-allmodconfig
../drivers/crypto/mv_cesa.c:1037:2: error: implicit declaration of function
'of_get_named_gen_pool' [-Werror=implicit-function-declaration]
This small series of patches addresses oopses seen when trying to use
the AF_ALG interface via openssl with openssh. This series does not
address all problems, but merely stops the kernel from smashing its
kernel stack and oopsing.
With these fixes in place, the kernel no longer oopses. However,
On Fri, Oct 09, 2015 at 06:34:28PM +0800, Herbert Xu wrote:
> On Fri, Oct 09, 2015 at 11:29:44AM +0100, Russell King wrote:
> > If the algorithm passed a zero statesize, do not pass a valid pointer
> > into the export/import functions. Passing a valid pointer covers up
> > bugs in driver code whic
Fri, Oct 09, 2015 at 11:29:04AM +0100, Russell King - ARM Linux wrote:
> This small series of patches addresses oopses seen when trying to use
> the AF_ALG interface via openssl with openssh. This series does not
> address all problems, but merely stops the kernel from smashing its
>
On Fri, Oct 09, 2015 at 02:12:43PM +0200, Thomas Petazzoni wrote:
> Hello Russell,
>
> On Fri, 9 Oct 2015 11:29:05 +0100, Russell King - ARM Linux wrote:
> > This small series of patches addresses oopses seen when trying to use
> > the AF_ALG interface via openssl with opens
patches on the crypto list if you wish to review them.
Thanks.
On Fri, Oct 09, 2015 at 11:46:37AM +0100, Russell King - ARM Linux wrote:
> Version 2, same as version 1 but with a different patch 1, thanks to
> Herbert for an alternative approach on that one.
>
> crypto/ahas
On Fri, Oct 09, 2015 at 05:39:02PM +0200, Thomas Petazzoni wrote:
> A new crypto driver for Marvell ARM platforms was added in
> drivers/crypto/marvell/ as part of commit f63601fd616ab ("crypto:
> marvell/cesa - add a new driver for Marvell's CESA"). This commit adds
> the relevant developers to th
ash.c | 80 +--
3 files changed, 36 insertions(+), 50 deletions(-)
On Fri, Oct 09, 2015 at 11:46:37AM +0100, Russell King - ARM Linux wrote:
> Version 2, same as version 1 but with a different patch 1, thanks to
> Herbert for an alternative approach on that one.
>
> crypto/ahas
On Fri, Oct 09, 2015 at 09:50:18PM +0200, Boris Brezillon wrote:
> Hi Russel,
>
> On Fri, 09 Oct 2015 20:43:43 +0100
> Russell King wrote:
>
> > When a AF_ALG fd is accepted a second time (hence hash_accept() is
> > used), hash_accept_parent() allocates a new private context using
> > sock_kmall
On Sat, Oct 10, 2015 at 12:37:33AM +0200, Arnaud Ebalard wrote:
> Hi Russel,
>
> Russell King writes:
>
> > As all the import functions and export functions are virtually
> > identical, factor out their common parts into a generic
> > mv_cesa_ahash_import() and mv_cesa_ahash_export() respectivel
On Sat, Oct 10, 2015 at 12:31:29PM +0200, Arnaud Ebalard wrote:
> Hi Russel,
^
> Russell King - ARM Linux writes:
> > Software:
> > The 'numbers' are in 1000s of bytes per second processed.
> > type 16 bytes 64 bytes256 bytes 10
On Sat, Oct 10, 2015 at 12:29:25PM +0100, Russell King - ARM Linux wrote:
> On Sat, Oct 10, 2015 at 12:31:29PM +0200, Arnaud Ebalard wrote:
> > Russell King - ARM Linux writes:
> > > Software:
> > > The 'numbers' are in 1000s of bytes per second processed.
&
On Sat, Oct 10, 2015 at 06:46:07PM +0200, Boris Brezillon wrote:
> On Fri, 09 Oct 2015 20:43:33 +0100
> Russell King wrote:
>
> > If the algorithm passed a zero statesize, do not pass a valid pointer
> > into the export/import functions. Passing a valid pointer covers up
> > bugs in driver code
Herbert,
I wonder if you can clear something up about the hash export/import
functionality. In:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/344120.html
you seem to imply that the exported and imported state can't be defined
by the driver.
Boris tells me, "AFAIR, crypto users
On Sun, Oct 11, 2015 at 08:34:27PM +0100, Russell King - ARM Linux wrote:
> Herbert,
>
> I wonder if you can clear something up about the hash export/import
> functionality. In:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/344120.html
>
> yo
On Tue, Oct 13, 2015 at 09:00:48PM +0800, Herbert Xu wrote:
> On Sun, Oct 11, 2015 at 02:55:05PM +0800, Herbert Xu wrote:
> > On Sat, Oct 10, 2015 at 05:17:54PM +0100, Russell King - ARM Linux wrote:
> > >
> > > I _also_ notice that despite having the ARM assembly cry
On Tue, Oct 13, 2015 at 09:57:22PM +0800, Herbert Xu wrote:
> On Tue, Oct 13, 2015 at 02:55:18PM +0100, Russell King - ARM Linux wrote:
> >
> > Given it's size so far, I'm not sure it makes much sense to backport
> > any of these fixes to stable; I think maybe we sh
On Tue, Oct 13, 2015 at 10:33:12PM +0800, Herbert Xu wrote:
> On Fri, Oct 09, 2015 at 08:43:33PM +0100, Russell King wrote:
> > If the algorithm passed a zero statesize, do not pass a valid pointer
> > into the export/import functions. Passing a valid pointer covers up
> > bugs in driver code whic
On Thu, Oct 15, 2015 at 05:41:47PM +0800, Herbert Xu wrote:
> On Thu, Oct 15, 2015 at 10:39:30AM +0100, Russell King - ARM Linux wrote:
> >
> > The CAAM driver is similarly buggy - it has export/import functions in
> > its ahash drivers, but zero statesize.
> >
> &
On Fri, Oct 16, 2015 at 04:19:33PM -0700, Victoria Milhoan wrote:
> @@ -319,7 +319,7 @@ static int ahash_set_sh_desc(struct crypto_ahash *ahash)
> have_key = OP_ALG_AAI_HMAC_PRECOMP;
>
> /* ahash_update shared descriptor */
> - desc = ctx->sh_desc_update;
> + desc = km
On Fri, Oct 16, 2015 at 04:24:54PM -0700, Victoria Milhoan wrote:
> On Thu, 15 Oct 2015 21:13:38 +0800
> Herbert Xu wrote:
>
> > On Thu, Oct 15, 2015 at 01:59:44PM +0100, Russell King - ARM Linux wrote:
> > >
> > > I think the CAAM driver is pretty unfixable f
On Fri, Oct 16, 2015 at 04:19:33PM -0700, Victoria Milhoan wrote:
> @@ -1569,6 +1601,10 @@ static int ahash_import(struct ahash_request *req,
> const void *in)
> struct caam_hash_ctx *ctx = crypto_ahash_ctx(ahash);
> struct caam_hash_state *state = ahash_request_ctx(req);
>
> + /
On Fri, Oct 16, 2015 at 04:19:33PM -0700, Victoria Milhoan wrote:
> @@ -1557,6 +1575,20 @@ static int ahash_export(struct ahash_request *req,
> void *out)
> struct caam_hash_ctx *ctx = crypto_ahash_ctx(ahash);
> struct caam_hash_state *state = ahash_request_ctx(req);
>
> + /*
> +
On Sat, Oct 17, 2015 at 06:57:44AM -0700, Victoria Milhoan wrote:
> Correct - this was apparently the wrong patch I pushed out. The one I'm
> actively using has this fixed (this is the only difference). I will make
> this change in v2 after reviewing your other comments.
Thanks Victoria, but pleas
On Sat, Oct 17, 2015 at 11:52:54AM +0100, Russell King - ARM Linux wrote:
> Now, with that change, and with your change to buf_0/buf_1, I see
> (before the import/export functions are used) several of these errors:
>
> caam_jr 2101000.jr0: 4501: DECO: desc idx 5: SGT Lengt
On Fri, Oct 16, 2015 at 04:19:33PM -0700, Victoria Milhoan wrote:
> @@ -1569,6 +1601,10 @@ static int ahash_import(struct ahash_request *req,
> const void *in)
> struct caam_hash_ctx *ctx = crypto_ahash_ctx(ahash);
> struct caam_hash_state *state = ahash_request_ctx(req);
>
> + /
The following series fixes the CAAM hash driver, allowing it to work
with the previously merged "crypto: ahash - ensure statesize is non-
zero" patch.
This is non-trivial, because CAAM exports a huge 1600 bytes of data,
which, if we set .statesize to this, still results in the core code
rejecting
On Sat, Oct 17, 2015 at 07:50:55PM +0100, Russell King - ARM Linux wrote:
> The following series fixes the CAAM hash driver, allowing it to work
> with the previously merged "crypto: ahash - ensure statesize is non-
> zero" patch.
>
> This is non-trivial, because CAAM exp
Following on from the previous series, this series addresses further
problems with the Marvell CESA hash driver found while testing it my
openssl/ssh scenarios.
The first patch improves one from the previous series: we can get the
transform more directly using req->base.tfm rather than going round
The following series fixes the CAAM hash driver, allowing it to work
with the previously merged "crypto: ahash - ensure statesize is non-
zero" patch.
This is non-trivial, because CAAM exports a huge 1600 bytes of data,
which, if we set .statesize to this, still results in the core code
rejecting
Continuing on from the previous set of 18 patches, I also fixed a
number of sparse problems and other cleanups. I don't deem these
suitable for -rc merging, especially now that we're basically at
-rc6.
The first patch switches the driver over to appropriately using
the relaxed IO accessors - this
On Mon, Oct 19, 2015 at 03:04:51PM +, Jason Cooper wrote:
> Hey Russell,
>
> On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote:
> > static int mv_cesa_ahash_init(struct ahash_request *req,
> > - struct mv_cesa_op_ctx *tmpl)
> > + stru
On Tue, Oct 20, 2015 at 01:26:55AM +0200, Arnaud Ebalard wrote:
> Hi Russell,
>
> Russell King writes:
>
> > Use the IO memcpy() functions when copying from/to MMIO memory.
> > These locations were found via sparse.
>
> On recent MVEBU hardware, *_std_* function are not expected to be used
> be
Here are further imx-caam updates that I've had since before the
previous merge window. Please review and (I guess) if Freescale
folk can provide acks etc that would be nice. Thanks.
drivers/crypto/caam/caamhash.c | 415 +++--
drivers/crypto/caam/intern.h |
On Wed, Dec 09, 2015 at 05:06:03PM +0200, Horia Geantă wrote:
> On 12/7/2015 9:11 PM, Russell King - ARM Linux wrote:
> > Here are further imx-caam updates that I've had since before the
> > previous merge window. Please review and (I guess) if Freescale
> > folk can p
On Wed, Dec 09, 2015 at 05:08:41PM +0200, Horia Geantă wrote:
> On 12/7/2015 9:12 PM, Russell King wrote:
> > Ensure that we clean up allocations and DMA mappings after encountering
> > an error rather than just giving up and leaking memory and resources.
> >
> > Signed-off-by: Russell King
>
>
On Wed, Dec 09, 2015 at 05:20:45PM +0200, Horia Geantă wrote:
> On 12/7/2015 9:12 PM, Russell King wrote:
> > Strictly, dma_map_sg() may coalesce SG entries, but in practise on iMX
> > hardware, this will never happen. However, dma_map_sg() can fail, and
> > we completely fail to check its return
On Sun, May 06, 2012 at 12:49:30AM +0200, Simon Baatz wrote:
> Am 23.02.2012 19:34, schrieb Phil Sutter:
> > But you might suffer from another problem, which is only present on
> > ARM machines with VIVT cache and linux >= 2.6.37: due to commit
> > f8b63c1, "ARM: 6382/1: Remove superfluous flush_ke
On Fri, Apr 26, 2013 at 01:46:46PM +0530, Vinod Koul wrote:
> On Fri, Apr 26, 2013 at 10:28:39AM +0200, Linus Walleij wrote:
> > On Thu, Apr 25, 2013 at 4:11 PM, Arnd Bergmann wrote:
> >
> > > The dma engine driver must know the address in its dma space, while the
> > > slave driver has it availa
On Fri, Apr 26, 2013 at 11:39:20AM +0200, Arnd Bergmann wrote:
> On Friday 26 April 2013 13:46:46 Vinod Koul wrote:
> >
> > The mapping & unmapping of dma buffer (memcpy and memory buffer in this
> > txn) is
> > required to be performed by the client driver. The dmanegine or dmaengine
> > driver
On Sat, Sep 14, 2013 at 05:11:53PM +0300, Jussi Kivilinna wrote:
> On 14.09.2013 16:30, Ard Biesheuvel wrote:
> > On 14 September 2013 10:08, Jussi Kivilinna wrote:
> >> On 13.09.2013 18:08, Ard Biesheuvel wrote:
> >>> This adds ARMv8 Crypto Extensions based implemenations of
> >>> AES in CBC, CTR
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some cases
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > Use platform_device_register_full() for those drivers which can, to
> > avoid messing directly with DMA masks. This can only be done when
> > the driver does n
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only ar
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
> On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> [...]
> > -dma_set_coherent_mask() will always be able to set the same or a
> > -smaller mask as dma_set_mask(). However for the rare case that a
> > +The coherent coherent mask
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > 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
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> > make that be the case. This
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, Russell King wrote:
>
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code s
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 2013/9/19 Russell King - ARM Linux :
> > This email is only being sent to the mailing lists in question, not to
> > anyone personally. The list of individuals is far to great to do that.
> > I'm hoping n
On Fri, Oct 04, 2013 at 08:04:50PM +0200, Ard Biesheuvel wrote:
> First of all, please note that the whole point of working so closely
> with the OpenSSL maintainer on this is that the version I am
> presenting here is the verbatim output of the Perl script that lives
> in the OpenSSL tree. So just
On Fri, Oct 04, 2013 at 02:34:01PM -0400, Nicolas Pitre wrote:
> Do you have an example of something that does require perl to build the
> kernel on ARM? I was under the impression that people try to avoid it
> as much as possible in general.
>
> I'm personally sitting on the fence between effe
On Fri, Oct 04, 2013 at 08:41:35PM +0200, Ard Biesheuvel wrote:
> On 4 October 2013 20:34, Nicolas Pitre wrote:
> > On Fri, 4 Oct 2013, Will Deacon wrote:
> [...]
> >>
> >> Why do you consider it unsuitable to ship the perl script with the kernel?
> >> Perl 5 is already documented as a build depen
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
> Hi Russell,
>
> Em Mon, 30 Sep 2013 13:57:47 +0200
> Hans Verkuil escreveu:
>
> > On 09/19/2013 11:44 PM, Russell King wrote:
> > > Replace the following sequence:
> > >
> > > dma_set_mask(dev, mask);
> > > dma_set_coh
On Sun, Jan 05, 2014 at 08:51:05PM +0800, Herbert Xu wrote:
> On Thu, Jan 02, 2014 at 07:16:46PM +0100, Ard Biesheuvel wrote:
> > On 2 January 2014 18:17, Russell King wrote:
> > > Building a multi-arch kernel results in:
> > >
> > > arch/arm/crypto/built-in.o: In function `aesbs_xts_decrypt':
> >
On Wed, Feb 25, 2009 at 04:35:40PM +0100, Karl Hiramoto wrote:
> The attached patch fixes my issue, but am not sure if it is correct or
> will cause problems else where.
> diff -Naurp linux-2.6.28.7.a/arch/arm/include/asm/scatterlist.h
> linux-2.6.28.7.b/arch/arm/include/asm/scatterlist.h
> ---
On Thu, Feb 26, 2009 at 08:10:43PM +0800, Herbert Xu wrote:
> Russell King - ARM Linux wrote:
> >
> > We can't merge this until _all_ of ARM has been fixed for walking
> > scatterlist chains.
>
> Right, this is definitely not the way to fix this bug. Because
&g
On Mon, Mar 02, 2009 at 12:45:12PM +0100, Christian Hohnstaedt wrote:
>
> - keep dma functions away from chained scatterlists.
>Use the existing scatterlist iteration inside the driver
>to call dma_map_single() for each chunk and avoid dma_map_sg().
Hmm, interesting. So crypto has its o
On Thu, Jun 11, 2009 at 11:07:34PM +0200, Sebastian Andrzej Siewior wrote:
> If you thing it is too early I can keep hacking in my own git tree until
> I get the dmac_flush_range() hack out or so.
The problem that I percieve with these kinds of hacks is that they
tend to spread into other code, an
On Wed, Sep 16, 2009 at 07:58:12PM +0200, Sebastian Andrzej Siewior wrote:
> leads to a build error because the crypto/cast6.c defines a function
> which is named W.
W has nothing to do with the access size, so this change makes it _really_
confusing. What it's about is telling the compiler to us
On Wed, Jun 03, 2020 at 08:40:58AM +0100, Marc Zyngier wrote:
> On 2020-06-03 08:29, Neal Liu wrote:
> > On Tue, 2020-06-02 at 21:02 +0800, Marc Zyngier wrote:
> > > On 2020-06-02 13:14, Ard Biesheuvel wrote:
> > > > On Tue, 2 Jun 2020 at 10:15, Neal Liu wrote:
> > > >>
> > > >> These patch series
On Fri, Jun 05, 2020 at 03:19:03PM +0800, Neal Liu wrote:
> On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
> > This kind of thing is something that ARM have seems to shy away from
> > doing - it's a point I brought up many years ago when the whole
On Fri, Jun 05, 2020 at 04:59:42PM +0800, Neal Liu wrote:
> On Fri, 2020-06-05 at 09:09 +0100, Russell King - ARM Linux admin wrote:
> > On Fri, Jun 05, 2020 at 03:19:03PM +0800, Neal Liu wrote:
> > > On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
&g
On Tue, Jan 26, 2021 at 06:56:52PM +0100, Uwe Kleine-König wrote:
> I'm surprised to see that the remove callback introduced in 2952ecf5df33
> ("coresight: etm4x: Refactor probing routine") has an __exit annotation.
In general, remove callbacks should not have an __exit annotation.
__exit _can_ be
On Tue, Jan 26, 2021 at 05:58:30PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
> Hello,
>
> Changes since v2 sent with Message-Id:
> 20201124133139.3072124-1-...@kleine-koenig.org:
>
> - Rebase to v5.11-rc1 (which resulted in a few conflicts in
>drivers/hwtracing).
> - Add var
On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> I'm glad to take this through my char/misc tree, as that's where the
> other coresight changes flow through. So if no one else objects, I will
> do so...
Greg, did you end up pulling this after all? If not, Uwe produced a v2.
I
On Thu, Feb 04, 2021 at 05:56:50PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 04:52:24PM +0000, Russell King - ARM Linux admin
> wrote:
> > On Tue, Feb 02, 2021 at 03:06:05PM +0100, Greg Kroah-Hartman wrote:
> > > I'm glad to take this through my char/
97 matches
Mail list logo
