On 19/09/16 18:36, Brent DeGraaf wrote:
> According to section 6.3.8 of the ARM Programmer's Guide, non-temporal
> loads and stores do not verify that address dependency is met between a
> load of an address to a register and a subsequent non-temporal load or
> store using that address on the execu
On 19/09/16 19:25, bdegr...@codeaurora.org wrote:
> On 2016-09-19 14:01, Robin Murphy wrote:
>> On 19/09/16 18:36, Brent DeGraaf wrote:
>>> According to section 6.3.8 of the ARM Programmer's Guide, non-temporal
>>> loads and stores do not verify that address depende
so results in a false positive warnings about
> previously mapped areas never being unmapped.
Makes sense, although I guess it might be even clearer to simply have
DMA_API_DEBUG select NEED_DMA_MAP_STATE. Either way, though,
Reviewed-by: Robin Murphy
>
> Signed-off-by: Andrey Smir
Hi Alison,
On 23/09/16 03:19, Alison Wang wrote:
> The ARMv8 architecture supports:
> 1. 64-bit execution state, AArch64.
> 2. 32-bit execution state, AArch32, that is compatible with previous
> versions of the ARM architecture.
>
> LayerScape platforms are compliant with ARMv8 architecture. This
On 23/09/16 14:13, Stuart Yoder wrote:
>
>
>> -Original Message-----
>> From: Robin Murphy [mailto:robin.mur...@arm.com]
>> Sent: Friday, September 23, 2016 7:17 AM
>> To: Alison Wang ; shawn...@kernel.org;
>> ker...@pengutronix.de; Fabio Esteva
On 23/09/16 15:01, Stuart Yoder wrote:
>
>
>> -Original Message-----
>> From: Robin Murphy [mailto:robin.mur...@arm.com]
>> Sent: Friday, September 23, 2016 8:19 AM
>> To: Stuart Yoder ; Alison Wang ;
>> shawn...@kernel.org;
>> ker...@peng
On 23/09/16 15:44, Arnd Bergmann wrote:
> On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
>> On 23/09/16 15:01, Stuart Yoder wrote:
>> Otherwise you can
>> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
>> need to trap and tr
On 27/09/16 13:16, Srinivas Ramana wrote:
> Hi Robin,
Sorry! This one had slipped my mind already...
> On 09/13/2016 08:22 PM, Srinivas Ramana wrote:
>> On 09/12/2016 11:21 PM, Robin Murphy wrote:
>>> On 12/09/16 07:57, Srinivas Ramana wrote:
>>>> If the bo
On 28/07/16 01:08, kwangwoo@sk.com wrote:
>> -Original Message-
>> From: Robin Murphy [mailto:robin.mur...@arm.com]
>> Sent: Wednesday, July 27, 2016 6:56 PM
>> To: 이광우(LEE KWANGWOO) MS SW; Russell King - ARM Linux; Catalin Marinas; Will
>> Deacon;
On 01/08/16 00:45, kwangwoo@sk.com wrote:
[...]
-8<-
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.h
index 10b017c4bdd8..1c005c90387e 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler
On 01/08/16 14:36, Robin Murphy wrote:
> On 01/08/16 00:45, kwangwoo@sk.com wrote:
> [...]
>>>>> -8<-
>>>>> diff --git a/arch/arm64/include/asm/assembler.h
>>>>> b/arch/arm64/include/asm/assembler.h
>>>>> index
Zyngier
CC: linux-kernel@vger.kernel.org
Signed-off-by: Robin Murphy
---
- Rework map_page() helper function plus insane lookup logic into
straightforward get_page() helper
- Use phys_addr_t to further simplify address matching
- Fix the bit where I neglected to actually round the doorbell
On 07/09/16 10:55, Peter Chen wrote:
[...]
>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
>> I think we should replace
>>
>> pdev->dev.dma_mask = dev->dma_mask;
>> pdev->dev.dma_parms = dev->dma_parms;
>> dma_set_coherent_mask(&pdev->dev, dev->
On 07/09/16 12:06, Srinivas Kandagatla wrote:
> This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
> Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
> legacy interrupts and it conforms to PCI Express Base 2.1 specification.
>
> This patch adds post_init callback to qc
the new iommu_fwspec API by simply converting
> the device_node to its fwnode_handle pointer.
>
> Signed-off-by: Lorenzo Pieralisi
> Cc: Will Deacon
> Cc: Hanjun Guo
> Cc: Robin Murphy
> Cc: Joerg Roedel
> ---
> drivers/iommu/Kconfig| 4 ++
> driver
d-off-by: Lorenzo Pieralisi
> Acked-by: Bjorn Helgaas [pci]
> Cc: Bjorn Helgaas
> Cc: Robin Murphy
> Cc: Tomasz Nowicki
> Cc: Joerg Roedel
> Cc: "Rafael J. Wysocki"
> ---
> drivers/acpi/glue.c | 4 ++--
> drivers/acpi/scan.c | 24 +++
On 09/09/16 15:23, Lorenzo Pieralisi wrote:
> In ARM ACPI systems, IOMMU components are specified through static
> IORT table entries. In order to create platform devices for the
> corresponding ARM SMMU components, IORT kernel code should be made
> able to parse IORT table entries and create platf
ng a corresponding ACPI device
> early probe section entry.
>
> Signed-off-by: Lorenzo Pieralisi
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Joerg Roedel
> ---
> drivers/acpi/arm64/iort.c | 103
>
ad simply fill in
the device's fwnode when binding the of_node, and let the drivers use
dev->fwnode either way. Let's give it a go and see what falls out.
Signed-off-by: Robin Murphy
---
drivers/of/platform.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/of/platfo
On 02/09/16 11:53, Felipe Balbi wrote:
>
> Hi,
>
> Arnd Bergmann writes:
>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>>
>>> Hi Felipe and Arnd,
>>>
>>> It has been a while since the last response to this discussion, but we
>>> haven't reached an agreement yet! Can we get to
Hi Julia,
On 05/08/16 09:56, Julia Lawall wrote:
> Use of_property_read_bool to check for the existence of a property.
This caught my eye since Rob told me off for doing the same recently[1].
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
Zyngier
CC: linux-kernel@vger.kernel.org
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c| 141 ++-
drivers/irqchip/irq-gic-v2m.c| 3 +
drivers/irqchip/irq-gic-v3-its.c | 3 +
include/linux/dma-iommu.h| 9 +++
4 files changed
On 24/08/16 09:16, Thomas Gleixner wrote:
> On Tue, 23 Aug 2016, Robin Murphy wrote:
>> +cookie = domain->iova_cookie;
>> +iovad = &cookie->iovad;
>> +
>> +spin_lock(&cookie->msi_lock);
>> +list_for_each_entry(msi_page, &coo
Hi Eric,
On Fri, 26 Aug 2016 00:25:34 +0200
Auger Eric wrote:
> Hi Robin,
>
> On 23/08/2016 21:05, Robin Murphy wrote:
> > When an MSI doorbell is located downstream of an IOMMU, attaching
> > devices to a DMA ops domain and switching on translation leads to a
> > ru
On 17/08/17 10:22, Marc Zyngier wrote:
> On 17/08/17 10:01, Shawn Lin wrote:
>> Hi Marc
>>
>> On 2017/8/17 16:52, Marc Zyngier wrote:
>>> On 17/08/17 09:28, Shawn Lin wrote:
If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't
have iommu support, we don't need to do iommu_dm
ices regardless.
Fixes: 05f80300dc8b ("iommu: Finish making iommu_group support mandatory")
Reported-by: Shawn Lin
Signed-off-by: Robin Murphy
---
As well as dma-iommu, there are at least the Cavium ThunderX and
Freescale DPAA2 ethernet drivers expecting this to work too.
drivers/iom
On 17/08/17 16:41, Joerg Roedel wrote:
> On Thu, Aug 17, 2017 at 11:40:08AM +0100, Robin Murphy wrote:
>> The recently-removed FIXME in iommu_get_domain_for_dev() turns out to
>> have been a little misleading, since that check is still worthwhile even
>> when groups *are* uni
On 19/06/17 22:52, Bjorn Helgaas wrote:
> [+cc David, Alex]
>
> On Wed, May 31, 2017 at 06:52:28PM +0100, Robin Murphy wrote:
>> Currently, we consider all DMA aliases when calculating MSI requester
>> IDs. This turns out to be the wrong thing to do in the face of pure DMA
&g
On 20/06/17 12:04, Zhen Lei wrote:
> This function is protected by spinlock, and the latter will do memory
> barrier implicitly. So that we can safely use writel_relaxed. In fact, the
> dmb operation will lengthen the time protected by lock, which indirectly
> increase the locking confliction in th
Hi Christoph,
On 20/06/17 13:41, Christoph Hellwig wrote:
> On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote:
>> I plan to create a new dma-mapping tree to collect all this work.
>> Any volunteers for co-maintainers, especially from the iommu gang?
>
> Ok, I've created the new tr
On 20/06/17 14:42, Christoph Hellwig wrote:
> Wouldn't the smal patch below solve the same issue in a simple way?
That assumes that all devices accessing a shared pool will have the same
dma_pfn_offset as the first one, which cannot strictly be relied upon
(even if it is highly likely in practice
On 20/06/17 14:49, Christoph Hellwig wrote:
> On Wed, May 24, 2017 at 11:24:29AM +0100, Vladimir Murzin wrote:
>> This patch introduces default coherent DMA pool similar to default CMA
>> area concept. To keep other users safe code kept under CONFIG_ARM.
>
> I don't see a CONFIG_ARM in the code, a
On 16/10/17 09:12, Vladimir Murzin wrote:
> + Robin and Christoph
>
> On 16/10/17 06:27, Marian Mihailescu wrote:
>> I am using 4.14-rc4 with a patch on top that includes
>> arch/arm/include/asm/dma-mapping.h in a module.
>>
>> I have MMU enabled, so
>> select DMA_NOOP_OPS if !MMU
>> does nothing
On 16/10/17 14:48, Mark Rutland wrote:
> Hi Leo,
>
> On Mon, Oct 16, 2017 at 09:17:23AM +0800, Leo Yan wrote:
>> On Tue, Oct 10, 2017 at 05:03:44PM +0100, Robin Murphy wrote:
>>> On 10/10/17 16:45, Mark Rutland wrote:
>>>> On Tue, Oct 10, 2017 at 10:27:25P
On 16/10/17 15:26, Mark Rutland wrote:
> On Mon, Oct 16, 2017 at 03:12:45PM +0100, Robin Murphy wrote:
>> On 16/10/17 14:48, Mark Rutland wrote:
>>> Hi Leo,
>>>
>>> On Mon, Oct 16, 2017 at 09:17:23AM +0800, Leo Yan wrote:
>>>> On Tue, Oct 10, 2017 a
On 26/05/17 08:07, Eddie Cai wrote:
> firefly reload board not support sd card yet. so support it.
I'm confused... According to pictures and the schematic the microSD
socket and vcc_sd supply are on the baseboard, not the core module, and
these nodes already exist in rk3288-firefly-reload.dts :/
On 30/05/17 17:49, Ray Jui wrote:
> Hi Will,
>
> On 5/30/17 8:14 AM, Will Deacon wrote:
>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote:
>>> I'm writing to check with you to see if the latest arm-smmu.c driver in
>>> v4.12-rc Linux for smmu-500 can support mapping that is only specific
On 01/11/17 19:14, Dongjiu Geng wrote:
> Some hardware platform can support RAS Extension, but not support IESB,
> such as Huawei's platform, so software need to insert Synchronization Barrier
> operations at exception handler entry.
>
> This series patches are based on James's series patches "SE
On 01/11/17 19:14, Dongjiu Geng wrote:
> ARMv8.2 adds a control bit to each SCTLR_ELx to insert implicit
> Error Synchronization Barrier(IESB) operations at exception handler entry
> and exit. But not all hardware platform which support RAS Extension
> can support IESB. So for this case, software n
On 01/11/17 07:46, Wei Hu (Xavier) wrote:
>
>
> On 2017/10/12 20:59, Robin Murphy wrote:
>> On 12/10/17 13:31, Wei Hu (Xavier) wrote:
>>>
>>> On 2017/10/1 0:10, Leon Romanovsky wrote:
>>>> On Sat, Sep 30, 2017 at 05:28:59PM +0800, Wei Hu (Xavier) wro
On 01/11/17 12:54, gengdongjiu wrote:
> Hi Robin,
>
> On 2017/11/1 19:24, Robin Murphy wrote:
>>> + esb
>>> +alternative_else_nop_endif
>>> +1:
>>> + .endm
>> Having a branch in here is pretty horrible, and furthermore using label
>>
On 01/11/17 16:58, Mark Salyzyn wrote:
> Cross compiling to aarch32 (for vdso32) using clang correctly
> identifies that (the unused) write_sysreg inline asm directive is
> illegal in that architectural context:
>
> arch/arm64/include/asm/arch_timer.h: error: invalid input constraint 'rZ' in
> as
On 13/11/17 10:32, Suzuki K Poulose wrote:
On 12/11/17 17:55, Jerome Glisse wrote:
On Fri, Nov 10, 2017 at 03:11:15PM +, Robin Murphy wrote:
On 09/11/17 22:58, Krishna Reddy wrote:
MAX_PHYSMEM_BITS greater than ARM64_VA_BITS is causing memory
access fault, when HMM_DMIRROR test is enabled
On 03/11/17 03:27, Shanker Donthineni wrote:
> The ARM architecture defines the memory locations that are permitted
> to be accessed as the result of a speculative instruction fetch from
> an exception level for which all stages of translation are disabled.
> Specifically, the core is permitted to
On 06/11/17 15:43, Alex Williamson wrote:
> [cc +robin]
>
> On Thu, 2 Nov 2017 18:33:50 +0100
> Sebastian Andrzej Siewior wrote:
>
>> On 2017-09-21 17:21:40 [+0200], Sebastian Andrzej Siewior wrote:
>>> get_cpu_ptr() disabled preemption and returns the ->fq object of the
>>> current CPU. raw_cpu
On 06/11/17 17:26, Sinan Kaya wrote:
> Add support for probing the newer HW.
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/dma/qcom/hidma.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index e366985..29d6aaa 100644
> --- a/
On 04/10/17 14:53, Ganapatrao Kulkarni wrote:
> Hi Robin,
>
>
> On Thu, Sep 21, 2017 at 5:28 PM, Robin Murphy wrote:
>> [+Christoph and Marek]
>>
>> On 21/09/17 09:59, Ganapatrao Kulkarni wrote:
>>> Introduce smmu_alloc_coherent and smmu_free_coherent func
On 29/09/15 22:27, Andrew Morton wrote:
[...]
If I'm understanding things correctly, some allocators zero the memory
by default and others do not. And we have an unknown number of drivers
which are assuming that the memory is zeroed.
Correct?
That's precisely the motivation here, yes.
If so
On 20/10/15 09:45, Chen Feng wrote:
iommu/hisilicon: Add hi6220-SoC smmu driver
A brief description of the smmu and what capabilities it provides
wouldn't go amiss here.
Signed-off-by: Chen Feng
Signed-off-by: Yu Dongbin
---
drivers/iommu/Kconfig| 8 +
drivers/iommu/Makefile
On 06/08/18 11:25, Mikulas Patocka wrote:
[...]
None of this explains why some transactions fail to make it across
entirely. The overlapping writes in question write the same data to
the memory locations that are covered by both, and so the ordering in
which the transactions are received should n
On 07/08/18 11:30, Dave Martin wrote:
On Tue, Aug 07, 2018 at 11:24:34AM +0100, Marc Zyngier wrote:
On 07/08/18 11:05, Dave Martin wrote:
On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote:
It recently came to light that userspace can execute WFI, and that
the arm64 kernel doesn trap
On 27/07/18 08:02, Vivek Gautam wrote:
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements. This smmu core is used with
multiple masters on msm8996, viz. mdss, video, etc.
Add bindings for the same.
Signed-off-by: Vivek Gautam
Reviewed-by: Rob Herring
Revie
Hi Jisheng,
On 26/07/18 08:14, Jisheng Zhang wrote:
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Out of interest, is the driver already setting its segment boundary mask
appropriately? This sound
ommit
ff33d1030a6ca87cea9a41e1a2ea7750a781ab3d as fault for my boot failures
with NFSv4 root on Toradex Colibri VF50 (Iris carrier board).
Author: Robin Murphy
Date: Mon Jul 23 23:16:12 2018 +0100
OF: Don't set default coherent DMA mask
Board: Toradex Colibri VF50 (NXP VF500, Cortex A5, serial confi
On 31/07/18 09:19, Stefan Agner wrote:
On 30.07.2018 16:38, Robin Murphy wrote:
On 28/07/18 17:58, Guenter Roeck wrote:
On Fri, Jul 27, 2018 at 04:04:48PM +0200, Christoph Hellwig wrote:
On Fri, Jul 27, 2018 at 03:18:14PM +0200, Krzysztof Kozlowski wrote:
On 27 July 2018 at 15:11, Krzysztof
On 31/07/18 14:26, Guenter Roeck wrote:
On 07/31/2018 05:32 AM, Robin Murphy wrote:
On 31/07/18 09:19, Stefan Agner wrote:
On 30.07.2018 16:38, Robin Murphy wrote:
On 28/07/18 17:58, Guenter Roeck wrote:
On Fri, Jul 27, 2018 at 04:04:48PM +0200, Christoph Hellwig wrote:
On Fri, Jul 27, 2018
On 31/07/18 16:43, Guenter Roeck wrote:
On Tue, Jul 31, 2018 at 03:09:34PM +0100, Robin Murphy wrote:
Please note that sparc images still generate the warning (next-20180731).
Ugh, OK, any ideas what sparc does to create these platform devices that
isn't of_platform_device_create_pdata(
On 31/07/18 16:53, Stefan Agner wrote:
On 31.07.2018 14:32, Robin Murphy wrote:
On 31/07/18 09:19, Stefan Agner wrote:
On 30.07.2018 16:38, Robin Murphy wrote:
On 28/07/18 17:58, Guenter Roeck wrote:
On Fri, Jul 27, 2018 at 04:04:48PM +0200, Christoph Hellwig wrote:
On Fri, Jul 27, 2018 at
Hi Shameer,
On 01/08/18 09:52, Shameerali Kolothum Thodi wrote:
Hi Lorenzo/Robin,
Just a gentle ping on this series. This is a v2 for smmu pmcg support
based on Neil Leeder's v1[1].
Thanks for picking this up - it's not gone unnoticed ;)
It'll take me a while to page all this stuff back in,
On 31/07/18 18:38, Guenter Roeck wrote:
On Tue, Jul 31, 2018 at 04:58:41PM +0100, Robin Murphy wrote:
On 31/07/18 16:43, Guenter Roeck wrote:
On Tue, Jul 31, 2018 at 03:09:34PM +0100, Robin Murphy wrote:
Please note that sparc images still generate the warning (next-20180731).
Ugh, OK, any
Hi Chris,
On 01/08/18 22:45, Chris Packham wrote:
GCC warns
arm_pmu_platform.c:234:5: error: 'err' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
This is because we rely on the for_each_cpu loop in armpmu_request_irqs
to initialise err. The warning is a little bog
On 09/07/18 12:18, Nipun Gupta wrote:
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
I guess this is about as neat as it can get;
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm
On 09/07/18 12:18, Nipun Gupta wrote:
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
R
On 09/07/18 12:18, Nipun Gupta wrote:
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
No more nits from me :)
Acked-by: Robin Murphy
, Ganapatrao Kulkarni
wrote:
On Mon, Apr 23, 2018 at 10:07 PM, Robin Murphy wrote:
On 19/04/18 18:12, Ganapatrao Kulkarni wrote:
The performance drop is observed with long hours iperf testing using 40G
cards. This is mainly due to long iterations in finding the free iova
range in 32bit address
On 11/07/18 15:40, Rob Herring wrote:
On Tue, Jul 10, 2018 at 12:43 PM Robin Murphy wrote:
Whilst the common firmware code invoked by dma_configure() initialises
devices' DMA masks according to limitations described by the respective
properties ("dma-ranges" for OF and _DM
iple
times, right?
I guess there could be other users who also want "just get whatever
clocks I have" functionality, so it might be worth proposing that for
the core API as a separate/follow-up patch, but it definitely doesn't
need to be part of this series.
I really
h, sorry for breaking it! Seems I managed to forget just how horrible
and fiddly all the arm_iommu_* stuff is :(
CC: Robin Murphy
CC: Honghui Zhang
Fixes: 05f80300dc8b ("iommu: Finish making iommu_group support mandatory")
Reported-by: Ryder Lee
Tested-by: Bibby Hsieh
Signed-off-by: Yo
issue.
CC: Robin Murphy
CC: Honghui Zhang
Fixes: 05f80300dc8b ('iommu: Finish making iommu_group support mandatory')
Reported-by: Ryder Lee
Signed-off-by: Yong Wu
---
changes notes:
v3: don't use the global variable and allocate a new iommu group before
arm_iommu_attach_devi
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
IORT revision C has been published with a number of new SMMU
implementation identifiers; define them.
CC: Rafael J. Wysocki
CC: Robert Moore
CC: Lv Zheng
Signed-off-by: Robin Murphy
---
include/acpi/actbl2.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/acpi/actbl2.h b
Revision C of IORT now allows us to identify ARM MMU-401 and the Cavium
ThunderX implementation; wire them up so that the appropriate quirks get
enabled when booting with ACPI.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 8
1 file changed, 8 insertions(+)
diff --git a
extra states.
FWIW,
Acked-by: Robin Murphy
> Signed-off-by: Thomas Gleixner
> Cc: Joerg Roedel
> Cc: io...@lists.linux-foundation.org
> ---
> drivers/iommu/of_iommu.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/iommu/of_iommu.c
> ++
On 10/01/18 15:30, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 12:06:22PM +, Robin Murphy wrote:
On 10/01/18 08:00, Christoph Hellwig wrote:
To preserve the x86 behavior.
And combined with patch 10/22 of the SWIOTLB refactoring, this means
SWIOTLB allocations will also end up NUMA
On 10/01/18 15:32, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 11:49:34AM +, Robin Murphy wrote:
+#ifdef CONFIG_ZONE_DMA
+ if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ return 0;
+#else
+ /*
+* Because 32-bit DMA masks are so common we expect ev
On 10/01/18 15:46, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 12:22:18PM +, Robin Murphy wrote:
+ if (phys_addr == SWIOTLB_MAP_ERROR)
+ goto out_warn;
-/* Confirm address can be DMA'd by device */
- if (dev_addr + size - 1 >
On 10/01/18 15:55, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 04:55:17PM +0100, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 12:58:14PM +, Robin Murphy wrote:
On 10/01/18 08:09, Christoph Hellwig wrote:
arm64 uses ZONE_DMA for allocations below 32-bits. These days we
name the
On 10/01/18 15:35, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 12:16:15PM +, Robin Murphy wrote:
On 10/01/18 08:09, Christoph Hellwig wrote:
To properly reject too small DMA masks based on the addressability of the
bounce buffer.
I reckon this is self-evident enough that it should
Hi Jeffy,
On 11/01/18 11:14, JeffyChen wrote:
Hi Marek,
Thanks for your reply.
On 01/11/2018 05:40 PM, Marek Szyprowski wrote:
Hi Jeffy,
On 2018-01-11 09:22, Jeffy Chen wrote:
With the probe-deferral mechanism, early initialisation hooks are no
longer needed.
Suggested-by: Robin Murphy
On 11/01/18 10:34, Arnd Bergmann wrote:
Building with CONFIG_OF disabled produces a compiler warning:
drivers/iio/adc/stm32-dfsdm-core.c: In function 'stm32_dfsdm_probe':
drivers/iio/adc/stm32-dfsdm-core.c:245:22: error: unused variable 'pnode'
[-Werror=unused-variable]
This removes the variab
On 11/01/18 08:22, Jeffy Chen wrote:
From: Tomasz Figa
Currently if the driver encounters an error while attaching device, it
will leave the IOMMU in an inconsistent state. Even though it shouldn't
really happen in reality, let's just add proper error path to keep
things consistent.
Signed-off
On 29/01/18 17:45, Marc Zyngier wrote:
A new feature of SMCCC 1.1 is that it offers firmware-based CPU
workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides
BP hardening for CVE-2017-5715.
If the host has some mitigation for this issue, report that
we deal with it using SMCCC_ARCH_WORKARO
On 29/01/18 17:45, Marc Zyngier wrote:
Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed,
let's do that at boot time, and expose the version of the calling
convention as part of the psci_ops structure.
Signed-off-by: Marc Zyngier
---
drivers/firmware/psci.c | 21 ++
On 29/01/18 17:45, Marc Zyngier wrote:
As we're about to trigger a PSCI version explosion, it doesn't
hurt to introduce a PSCI_VERSION helper that is going to be
used everywhere.
Signed-off-by: Marc Zyngier
---
include/kvm/arm_psci.h | 5 +++--
virt/kvm/arm/psci.c| 2 +-
2 files changed
On 19/01/18 11:43, Vivek Gautam wrote:
From: Sricharan R
The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using pm_runt
On 19/01/18 11:43, Vivek Gautam wrote:
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Signed-off-b
On 19/01/18 11:43, Vivek Gautam wrote:
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smm
Hi Suravee,
On 31/01/18 01:48, Suravee Suthikulpanit wrote:
Currently, iommu_unmap and iommu_unmap_fast return unmapped
pages with size_t. However, the actual value returned could
be error codes (< 0), which can be misinterpreted as large
number of unmapped pages. Therefore, change the return t
On 01/02/18 05:03, Suravee Suthikulpanit wrote:
Hi Robin,
On 2/1/18 1:02 AM, Robin Murphy wrote:
Hi Suravee,
On 31/01/18 01:48, Suravee Suthikulpanit wrote:
Currently, iommu_unmap and iommu_unmap_fast return unmapped
pages with size_t. However, the actual value returned could
be error codes
On 01/02/18 11:46, Marc Zyngier wrote:
In order to call into the firmware to apply workarounds, it is
useful to find out whether we're using HVC or SMC. Let's expose
this through the psci_ops.
Reviewed-by: Robin Murphy
Acked-by: Lorenzo Pieralisi
Signed-off-by: Marc Zyngier
---
h the condition flipped and the redundant else case removed (or an
explanation of why I'm wrong...)
Reviewed-by: Robin Murphy
+ else
+ psci_ops.smccc_version = SMCCC_VERSION_1_1;
+ }
+
+ pr_info("SMC Calling Convention v1.%d\n", psci_ops
possibly wrong.
Reviewed-by: Robin Murphy
Cc: sta...@vger.kernel.org
Reported-by: Ard Biesheuvel
Acked-by: Ard Biesheuvel
Tested-by: Ard Biesheuvel
Signed-off-by: Marc Zyngier
---
include/linux/arm-smccc.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linu
e whole sequence away. "volatile" is what
+ * makes it stick.
+ */
+#define __arm_smccc_1_1(inst, ...) \
+ do {\
+ __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \
+
On 01/02/18 13:54, Marc Zyngier wrote:
On 01/02/18 13:34, Robin Murphy wrote:
On 01/02/18 11:46, Marc Zyngier wrote:
One of the major improvement of SMCCC v1.1 is that it only clobbers
the first 4 registers, both on 32 and 64bit. This means that it
becomes very easy to provide an inline
On 01/02/18 11:00, Himanshu Jha wrote:
In scpsys_probe function, return value of of_match_device function which
returns null is dereferenced without checking. Therefore, add a check for
potential null dereference.
Detected by CoverityScan, CID#1424087 "Dereference null return value"
Fixes: comm
On 01/02/18 15:09, Geert Uytterhoeven wrote:
On Thu, Feb 1, 2018 at 4:02 PM, Robin Murphy wrote:
On 01/02/18 11:00, Himanshu Jha wrote:
In scpsys_probe function, return value of of_match_device function which
returns null is dereferenced without checking. Therefore, add a check for
potential
On 31/01/18 09:37, Arnd Bergmann wrote:
On Wed, Jan 31, 2018 at 8:29 AM, Maxime Ripard
wrote:
Hi Thierry,
On Tue, Jan 30, 2018 at 11:01:50AM +0100, Thierry Reding wrote:
On Tue, Jan 30, 2018 at 10:59:16AM +0100, Thierry Reding wrote:
On Tue, Jan 30, 2018 at 10:24:48AM +0100, Arnd Bergmann wr
On 20/01/18 14:36, SF Markus Elfring wrote:
From: Markus Elfring
Date: Sat, 20 Jan 2018 15:30:17 +0100
Omit extra messages for a memory allocation failure in these functions.
Why?
It's your job as patch author to convince reviewers and maintainers why
your change is a good thing and they sh
Hi Jeffy,
On 03/01/18 06:09, Jeffy Chen wrote:
The for_each_matching_node_and_match() would return every matching
nodes including unavailable ones.
It's pointless to init unavailable IOMMUs, so add a sanity check to
avoid that.
Even better would be to clean up the last remaining init_fn user
Hi Linus,
On 21/12/17 22:08, Linus Walleij wrote:
On Thu, Dec 21, 2017 at 10:31 PM, Arnd Bergmann wrote:
We get a dtc warning about the CLCD interrupt being invalid:
arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple o
1 - 100 of 1747 matches
Mail list logo
