On 2021-03-03 16:40, Horia Geantă wrote:
On 3/3/2021 4:57 PM, Sascha Hauer wrote:
On Wed, Mar 03, 2021 at 12:26:32PM +0200, Horia Geantă wrote:
Adding some people in the loop, maybe they could help in understanding
why lack of "dma-coherent" property for a HW-coherent device could lead to
unexp
On 2021-03-03 10:26, Horia Geantă wrote:
Adding some people in the loop, maybe they could help in understanding
why lack of "dma-coherent" property for a HW-coherent device could lead to
unexpected / strange side effects.
On 3/1/2021 5:22 PM, Sascha Hauer wrote:
Hi All,
I am on a Layerscape LS
On 2020-11-16 18:54, Rob Herring wrote:
On Thu, Oct 22, 2020 at 1:18 AM Gilad Ben-Yossef wrote:
Hi again,
Any opinion on the suggested below?
Sorry, lost in the pile...
Thanks!
Gilad
On Tue, Sep 29, 2020 at 9:08 PM Gilad Ben-Yossef wrote:
On Wed, Sep 23, 2020 at 4:57 AM Rob Herring
On 2020-09-09 21:06, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep
On 2019-05-30 10:12 am, Peter Robinson wrote:
Hi Eric,
I'm seeing the crash below on ARMv7 devices, at least the Raspberry Pi
and UDoo Neo (i.MX6SX), with your "crypto: run initcalls for generic
implementations earlier" patch. It's causing the boot to fail very
early on across the ARMv7 devices
On 21/08/18 18:00, Ard Biesheuvel wrote:
On 21 August 2018 at 18:50, Nick Desaulniers wrote:
On Tue, Aug 21, 2018 at 5:23 AM Ard Biesheuvel
wrote:
Hi Nick,
On 21 August 2018 at 00:40, Nick Desaulniers wrote:
It seems that:
ldr q8, =0x300020001
is a GNU as convience notation for:
The inclusion of dma-direct.h was only needed temporarily to prevent
breakage from the DMA API rework, since the actual CESA fix making it
redundant was merged in parallel. Now that both have landed, it can go.
Signed-off-by: Robin Murphy
---
drivers/crypto/marvell/cesa.c | 1 -
1 file changed
On 25/01/18 11:38, Yury Norov wrote:
On Wed, Jan 24, 2018 at 11:28:55AM +0100, Arnd Bergmann wrote:
On Wed, Jan 24, 2018 at 10:05 AM, Yury Norov wrote:
This series adds API for 128-bit memory IO access and enables it for ARM64.
The original motivation for 128-bit API came from new Cavium netwo
igned-off-by: Robin Murphy
---
Found by inspection and compile-tested only
drivers/crypto/marvell/cesa.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 293832488cc9..f81fa4a3e66b 100644
On 03/10/17 23:16, David Woodhouse wrote:
> On Tue, 2017-10-03 at 19:05 +0100, Robin Murphy wrote:
>>
>> Now, there are indeed plenty of drivers and subsystems which do work on
>> lists of explicitly single pages - anything doing some variant of
>> "addr = kmap_
On 03/10/17 13:55, David Woodhouse wrote:
> On Thu, 2017-09-28 at 15:14 +0100, Robin Murphy wrote:
>> The intel-iommu DMA ops fail to correctly handle scatterlists where
>> sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed
>> appropriately based on the
On 28/09/17 14:29, Raj, Ashok wrote:
> Hi Casey
>
> On Thu, Sep 28, 2017 at 04:17:59PM +, Casey Leedom wrote:
>> Thanks Robin. Harsh can certainly test your latest patch as soon as he's
>> back in the office tomorrow morning India time. If your patch works and is
>> accepted, it sounds lik
es rather than VT-d pages to match the
aligned_nrpages() calculation) regardless of the offset, and use
sg_phys() consistently for clarity.
Reported-by: Harsh Jain
Signed-off-by: Robin Murphy
---
drivers/iommu/intel-iommu.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/iom
On Wed, 27 Sep 2017 16:31:04 +
Casey Leedom wrote:
> | From: Dan Williams
> | Sent: Tuesday, September 26, 2017 9:10 AM
> |
> | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom
> wrote: | > | From: Robin Murphy
> | > | Sent: Tuesday, Se
On 26/09/17 15:34, Raj, Ashok wrote:
> On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote:
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index 6784a05dd6b2..d7f7def81613 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/
On 26/09/17 13:21, Harsh Jain wrote:
> Find attached new set of log. After repeated tries it panics.
Thanks, that makes things a bit clearer - looks like fixing the physical
address/pteval calculation to not be off by a page in one direction wasn't
helping much because the returned DMA address is
On 20/09/17 09:01, Herbert Xu wrote:
> Harsh Jain wrote:
>>
>> While debugging DMA mapping error in chelsio crypto driver we observed that
>> when scatter/gather list received by driver has some entry with page->offset
>> > 4096 (PAGE_SIZE). It starts giving DMA error. Without IOMMU it works fi
On 24/04/17 09:57, Antoine Tenart wrote:
> Hi Igal,
>
> On Mon, Apr 24, 2017 at 08:50:32AM +, Igal Liberman wrote:
>> [...]
>>
>>> + priv->clk = of_clk_get(dev->of_node, 0);
>>> + if (!IS_ERR(priv->clk)) {
>>> + ret = clk_prepare_enable(priv->clk);
>>> + if (ret) {
>>>
Hi Antoine,
On 24/04/17 08:54, Antoine Tenart wrote:
> Add support for Inside Secure SafeXcel EIP197 cryptographic engine,
> which can be found on Marvell Armada 7k and 8k boards. This driver
> currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and
> hmac(sah1) algorithms.
>
> Two fir
Hi Antoine,
Bit of a drive-by, but since I have it in my head that crypto drivers
are a hotspot for dodgy DMA usage (in part due to the hardware often
being a bit esoteric with embedded RAMs and such), this caught my eye
and I thought I'd give this a quick once-over to check for anything
smelly. U
On 05/04/17 18:08, Ard Biesheuvel wrote:
> Hoi Matthias!
>
> On 5 April 2017 at 17:56, Matthias Kaehlcke wrote:
>> From: Greg Hackmann
>>
>> The current definition of ASM_EXPORT doesn't work properly with clang,
>> according to https://bugs.llvm.org//show_bug.cgi?id=27250#c3 it relies on
>> gcc
On 18/03/16 09:30, Boris Brezillon wrote:
On Thu, 17 Mar 2016 23:50:20 +
Russell King - ARM Linux wrote:
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
Hi Suravee,
On 05/05/15 16:12, Suravee Suthikulpanit wrote:
From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
object to be specified for DMA-cabpable devices. This patch introduces
ACPI_MUST_HAVE_CCA in arm64 Kco
23 matches
Mail list logo
