n CMA is available.
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/mm/dma-mapping.c | 4 ++--
drivers/iommu/dma-iommu.c | 44 ++--
include/linux/dma-iommu.h | 2 +-
3 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/m
Hi Robin,
On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy wrote:
> On 13/01/17 11:07, Geert Uytterhoeven wrote:
>> Add support for DMA_ATTR_FORCE_CONTIGUOUS to the generic IOMMU DMA code.
>> This allows to allocate physically contiguous DMA buffers on arm64
>> systems w
Hi Robin,
On Fri, Jan 13, 2017 at 1:17 PM, Robin Murphy wrote:
> On 13/01/17 11:59, Geert Uytterhoeven wrote:
>> On Fri, Jan 13, 2017 at 12:32 PM, Robin Murphy wrote:
>>> On 13/01/17 11:07, Geert Uytterhoeven wrote:
>>>> Add support for DMA_ATTR_FORCE_CONTIGUOUS
range for
> each particular SoC.
>
> If needed in the future SoC specific feature flags can be
> added to handle the maximum number of micro-TLBs without
> requiring DT changes, however at this point this does not
> seem necessary.
>
> Signed-off-by: Magnus Damm
Thanks f
nst
"ES1.*"), as (1) it marks more clearly support for old SoCs, and
(2) it makes it easier to remove the check later when these
old SoCs are deemed extinct later.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots o
Hi Magnus,
On Tue, Jan 24, 2017 at 10:38 AM, Magnus Damm wrote:
> On Mon, Jan 23, 2017 at 9:50 PM, Geert Uytterhoeven
> wrote:
>> On Mon, Jan 23, 2017 at 1:12 PM, Magnus Damm wrote:
>>> From: Magnus Damm
>>>
>>> Match on r8a7795 ES2 and enable a certain
ot allocated [device address=0x00067bab2ff8] [size=8 bytes]
__arm_lpae_map() added "ARM_LPAE_LVL_IDX(iova, lvl, data)" == 0xff8 to ptep
(the PGD base address), but the PGD has only 32 bytes, leading to the warning.
Does my analysis make sense?
Do you have a clue?
Thanks!
Gr{oetje,eet
Hi Robin,
On Wed, Jan 25, 2017 at 6:27 PM, Robin Murphy wrote:
> On 25/01/17 16:23, Geert Uytterhoeven wrote:
>> On Mon, May 9, 2016 at 11:37 AM, Robin Murphy wrote:
>>> On 08/05/16 11:59, Niklas Söderlund wrote:
>>>> While using CONFIG_DMA_API_DEBUG i ca
anded out a 40-bit IOVA, outside the 32-bit IOVA
space, leading to out-of-bounds accesses of the PGD when mapping the
IOVA.
Force a 32-bit IOMMU Domain Geometry to fix this.
Signed-off-by: Geert Uytterhoeven
---
Should the generic code restrict the geometry based on IAS instead?
---
drivers/
Hi Robin,
On Thu, Jan 26, 2017 at 12:23 PM, Robin Murphy wrote:
> On 26/01/17 09:53, Geert Uytterhoeven wrote:
>> Currently, the IPMMU/VMSA driver supports 32-bit I/O Virtual Addresses
>> only, and thus sets io_pgtable_cfg.ias = 32. However, it doesn't force
>> a 32-
dance, as the buffer is contiguous,
- Move CPU cache magement into the caller, which is much simpler with
a single contiguous buffer.
Thanks for your comments!
Geert Uytterhoeven (2):
iommu/dma: Add support for DMA_ATTR_FORCE_CONTIGUOUS
arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to
erent() already calls
dma_alloc_from_contiguous() when CMA is available.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New, handle dispatching in the arch (arm64) code, as requested by
Robin Murphy.
---
arch/arm64/mm/dma-mapping.c | 51 -
1 file change
,
iommu_dma_alloc_contiguous() has no callback to flush pages.
Ensuring the returned region is made visible to a non-coherent device is
the responsibility of the caller.
Signed-off-by: Geert Uytterhoeven
---
v2:
- Provide standalone iommu_dma_{alloc,free}_contiguous() functions, as
requested
Hi Robin,
On Fri, Jan 27, 2017 at 6:50 PM, Robin Murphy wrote:
> On 27/01/17 15:34, Geert Uytterhoeven wrote:
>> Add helpers for allocating physically contiguous DMA buffers to the
>> generic IOMMU DMA code. This can be useful when two or more devices
>> with different me
x27;s __dma_alloc_coherent() already calls
dma_alloc_from_contiguous() when CMA is available.
Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
---
v3:
- Add Acked-by,
- Update comment to "one of _4_ things",
- Call dma_alloc_from_contiguous() and iommu_dma_map_page() d
anded out a 40-bit IOVA, outside the 32-bit IOVA
space, leading to out-of-bounds accesses of the PGD when mapping the
IOVA.
Force a 32-bit IOMMU Domain Geometry to fix this.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Robin Murphy
---
v2:
- Add Reviewed-by.
---
drivers/iommu/ipmmu-vmsa.
Hi Robin,
On Thu, Feb 2, 2017 at 2:15 PM, Robin Murphy wrote:
> On 31/01/17 11:12, Geert Uytterhoeven wrote:
>> Add support for allocating physically contiguous DMA buffers on arm64
>> systems with an IOMMU. This can be useful when two or more devices
>> with different me
mmu_ops;
> +
> + ipmmu_init();
> +
> + of_iommu_set_ops(np, (struct iommu_ops *)ops);
As of commit 65e251a4634c5644 ("iommu: Drop the of_iommu_{set/get}_ops()
interface"), this should become:
iommu_register_instance(&np->fwnode, (struct iommu_ops *)ops);
x27;s __dma_alloc_coherent() already calls
dma_alloc_from_contiguous() when CMA is available.
Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
---
v4:
- Replace dma_to_phys()/phys_to_page() by vmalloc_to_page(), to pass
the correct page pointer to dma_release_from_contiguous().
Note
x27;s __dma_alloc_coherent() already calls
dma_alloc_from_contiguous() when CMA is available.
Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
Reviewed-by: Robin Murphy
---
v5:
- Add Reviewed-by,
- Pass GFP flags to dma_alloc_from_contiguous(), cfr. commit
712c604dcdf818629 ("m
erg Roedel
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to jour
On Tue, Mar 7, 2017 at 4:17 AM, Magnus Damm wrote:
> From: Magnus Damm
>
> Break out the domain allocation code into a separate function.
> This is preparation for future code sharing.
>
> Signed-off-by: Magnus Damm
> Reviewed-by: Joerg Roedel
Reviewed-by: Geert Uytterhoe
d-by: Joerg Roedel
Reviewed-by: Geert Uytterhoeven
> --- 0010/drivers/iommu/ipmmu-vmsa.c
> +++ work/drivers/iommu/ipmmu-vmsa.c 2017-03-06 19:26:26.070607110 +0900
> @@ -72,6 +72,25 @@ static struct ipmmu_vmsa_domain *to_vmsa
> return container_of(dom, struct ipmmu_vmsa_dom
devices_lock);
> +
> + list_for_each_entry(mmu, &ipmmu_devices, list) {
> + if (ipmmu_is_root(mmu)) {
> + found = true;
root = mmu;
> + break;
> + }
> + }
> +
> + spin_unlock(&ipmmu_devi
Hi Magnus,
On Wed, Mar 8, 2017 at 12:02 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> Hook up IOMMU_OF_DECLARE() support in case CONFIG_IOMMU_DMA
> is enabled. The only current supported case for 32-bit ARM
> is disabled, however for 64-bit ARM usage of OF is required.
>
> Signed-off-by: Magnus
there
> +*/
> + if (!__ipmmu_find_root()) {
> + dev_info(dev, "Unable to locate IPMMU root device\n");
dev_err?
> + return -ENODEV;
> + }
> +
> + /* For R-Car Gen3 use a white list to opt-in slave devices */
On Sun, Mar 12, 2017 at 6:38 AM, Magnus Damm wrote:
> From: Magnus Damm
>
> Support the r8a7796 IPMMU by sharing feature flags between
> r8a7795 and r8a7796. Also update IOMMU_OF_DECLARE to hook
> up the updated compat string.
>
> Signed-off-by: Magnus Damm
Reviewed-by: Ge
as-drivers-2017-03-21-v4.11-rc3
I expect them to apply cleanly to your next branch, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a
sg_set_page(sgt->sgl, vmalloc_to_page(cpu_addr),
> + PAGE_ALIGN(size), 0);
> +
> + return ret;
> + }
> +
> + if (WARN_ON(!area->pages))
> return -ENXIO;
>
> return sg_alloc_table_f
; // in
>>> __swiotlb_get_sgtable
>>> I guess it is similarly in __swiotlb_mmap.
>>>
>>> Are these translations equivalent?
>> Ah, my mistake, sorry - I managed to forget that cpu_addr is always
>> remapped for FORCE_CONTIGUOUS (*and* somehow overlook the us
gt; If you do want to go down that route, then I would much rather we fix
> dma_common_contiguous_remap() to leave a valid array in area->pages in
> the first place, than be temporarily faking them up around individual calls.
The only point of using the pages array here in the first place is t
ling.
That was actually the approach I took in my v1.
V2 changed that to provide standalone iommu_dma_{alloc,free}_contiguous()
functions.
V3 changed that to call everything directly from the arm64 code.
...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lot
onfigure(struct device *dev);
> #else /* CONFIG_OF */
>
> @@ -105,8 +105,11 @@ static inline struct device_node
> *of_cpu_device_node_get(int cpu)
> {
> return NULL;
> }
> -static inline void of_dma_configure(struct device *dev, struct device_node
> *np)
> -{}
> +
> +static
Hi Sricharan, Robin,
On Wed, May 3, 2017 at 12:24 PM, Sricharan R wrote:
> On 5/3/2017 3:24 PM, Robin Murphy wrote:
>> On 02/05/17 19:35, Geert Uytterhoeven wrote:
>>> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R
>>> wrote:
>>>> From: Laurent Pinchart
arch/arm64/mm/dma-mapping.c:dma_debug_do_init()
from fs_initcall() to arch_initcall().
However, then you loose the debugfs features. A proper fix would involve
splitting dma_debug_init() in two phases: an early one doing the real work,
and a late one registering the debugfs interface.
Gr{oetje,eet
On Wed, May 17, 2017 at 12:07 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> Fix comma-instead-of-semicolon typo error present
> in the latest version of the IPMMU driver.
>
> Signed-off-by: Magnus Damm
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
gt; arch/openrisc/include/asm/dma-mapping.h | 7 ---
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking t
734,6 +738,12 @@ error:
> return ret;
> }
>
> +static int ipmmu_of_xlate(struct device *dev,
> + struct of_phandle_args *spec)
> +{
... here
> + return ipmmu_init_platform_device(dev);
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytter
fwspec_add_ids(dev, spec->args, 1);
Does it hurt if iommu_fwspec_add_ids() is called multiple times, as this is
done before the "Initialize once - xlate() will call multiple times" check?
> +
> + return ipmmu_init_platform_device(dev, spec);
> }
Gr{oetje,eeting}s
ionnal interrupt flag
traditional
Sorry, only comments on the comments ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
w
oes it make sense to have a property for the number of micro-TLBs,
or is this handled transparently?
E.g. ipmmu_mx has 24 micro-TLBs, but ipmmu_mp has 30.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
> + if (ret < 0)
> + return -1;
> +
> + if (args.np != mmu->dev->of_node)
> + return -1;
> +
> + return args.args[0];
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux bey
quot;;
> + };
Same comment for the other nodes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I
Hi Laurent,
On Thu, Apr 17, 2014 at 12:33 PM, Laurent Pinchart
wrote:
> Cc: devicet...@vger.kernel.org
> Cc: Will Deacon
> Signed-off-by: Laurent Pinchart
How come your git-send-email didn't honor the two CC lines aboves?
Gr{oetje,eeting}s,
G
/iommu/arm-smmu-v3.c and drivers/iommu/arm-smmu.c
need similar fixes.
I didn't check all drivers, but e.g. drivers/iommu/amd_iommu.c has
a similar check.
Does the IOMMU work on other arm64 platforms in v4.20-rc1?
Thanks for your comments!
Gr{oetje,eeting}s,
Geert
-
("of/device: Set bus DMA mask as appropriate")
> Reported-by: Aaro Koskinen
> Reported-by: Jean-Philippe Brucker
> Signed-off-by: Robin Murphy
Thanks, this fixes the problem I saw with IPMMU on Salvator-X(S).
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Hi Robin,
On Tue, Nov 6, 2018 at 9:20 PM Robin Murphy wrote:
> On 2018-11-06 7:44 pm, Geert Uytterhoeven wrote:
> > On Tue, Oct 23, 2018 at 1:40 AM Linux Kernel Mailing List
> > wrote:
> >> Commit: b4ebe6063204da58e48600b810a9
kobject_put+0x60/0xe8
iommu_group_get_for_dev+0xa8/0x1f0
ipmmu_add_device+0x1c/0x40
of_iommu_configure+0x118/0x190
Fix this by checking if the domain's context already exists, before
trying to destroy it.
Signed-off-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.
Hi Jörg,
On Wed, Nov 7, 2018 at 4:34 PM Joerg Roedel wrote:
> On Wed, Nov 07, 2018 at 01:22:52PM +, Robin Murphy wrote:
> > On 2018-11-07 1:18 pm, Geert Uytterhoeven wrote:
> > > Fix this by checking if the domain's context already exists, before
> > > trying
shihiro Shimoda
Reviewed-by: Geert Uytterhoeven
One question below.
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -771,11 +765,35 @@ static bool ipmmu_slave_whitelist(struct device *dev)
> { /* sentinel */ }
> };
>
> +stat
off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
One small comment below.
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -773,8 +773,13 @@ static int ipmmu_init_platform_device(struct device *dev,
> { /* sentinel */ }
> };
>
> +stati
return NULL;
There's second implementation below, which calls __get_free_pages() and
does an explicit memset(). As __get_free_pages() calls alloc_pages(), perhaps
it makes sense to replace the memset() by GFP_ZERO, to increase consistency?
Gr{oetje,eeting}s,
On Fri, Dec 14, 2018 at 10:54 AM Geert Uytterhoeven
wrote:
> On Fri, Dec 14, 2018 at 9:26 AM Christoph Hellwig wrote:
> > If we want to map memory from the DMA allocator to userspace it must be
> > zeroed at allocation time to prevent stale data leaks. We already do
> >
On Thu, Dec 13, 2018 at 9:19 PM Fabrizio Castro
wrote:
> Document RZ/G2E (R8A774C0) SoC bindings.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32
On Thu, Dec 13, 2018 at 9:22 PM Fabrizio Castro
wrote:
> Support RZ/G2E (a.k.a. R8A774C0) IPMMU.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32
Hi Christoph,
On Fri, Dec 14, 2018 at 12:47 PM Christoph Hellwig wrote:
>
> On Fri, Dec 14, 2018 at 10:54:32AM +0100, Geert Uytterhoeven wrote:
> > > - page = alloc_pages(flag, order);
> > > + page = alloc_pages(flag | GFP_ZERO, order);
131751dcff..3ed4db334341 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -114,10 +114,14 @@ void iommu_device_unregister(struct iommu_device *iommu)
> int iommu_probe_device(struct device *dev)
> {
> const struct iommu_ops *ops = dev->bus-&g
A allocation API, the allocated
DMA memory will be freed using the direct DMA ops, while it may have
been allocated using a custom DMA ops (iommu_dma_ops in this case).
Fix this by reversing the order of the calls to devres_release_all() and
arch_teardown_dma_ops().
Signed-off-by: Geert Uytterhoeven
Hi Robin,
On Fri, Feb 8, 2019 at 6:55 PM Robin Murphy wrote:
> On 08/02/2019 16:40, Joerg Roedel wrote:
> > On Thu, Feb 07, 2019 at 08:36:53PM +0100, Geert Uytterhoeven wrote:
> >> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> >> index 8ac10af17c0043a3..d62487d
, and removing the reference to
and implementation of iommu_debugfs_new_driver_dir().
Fixes: bad614b24293ae46 ("iommu: Enable debugfs exposure of IOMMU driver
internals")
Signed-off-by: Geert Uytterhoeven
---
drivers/iommu/iommu-debugfs.c | 23 ---
1 file changed, 4
Add missing kerneldoc for iommu_ops.iotlb_sync_map().
Fixes: 1d7ae53b152dbc5b ("iommu: Introduce iotlb_sync_map callback")
Signed-off-by: Geert Uytterhoeven
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iom
While the API wrapper is called iommu_flush_tlb_all(), the actual
iommu_ops method is called .flush_iotlb_all(), not .flush_tlb_all().
Fixes: add02cfdc9bc2987 ("iommu: Introduce Interface for IOMMU TLB Flushing")
Signed-off-by: Geert Uytterhoeven
---
include/linux/iommu.h | 2 +-
1 fi
Hi Jörg,
This series contains a fix for an incorrect kerneldoc parameter, and
adds the missing kerneldoc for two recently added IOMMU methods.
Thanks!
Geert Uytterhoeven (3):
iommu: Fix kerneldoc for iommu_ops.flush_iotlb_all()
iommu: Document iommu_ops.iotlb_sync_map()
iommu
Add missing kerneldoc for iommu_ops.is_attach_deferred().
Fixes: e01d1913b0d08171 ("iommu: Add is_attach_deferred call-back to iommu-ops")
Signed-off-by: Geert Uytterhoeven
---
include/linux/iommu.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/iommu.h b/inc
Make the IPMMU_CTX_MAX constant unsigned, to match the type of
ipmmu_features.number_of_contexts.
This allows to use plain min() instead of type-casting min_t().
Signed-off-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff
ipmmu_domain_init_context() takes care of (1) initializing the software
domain, and (2) initializing the hardware context for the domain.
Extract the code to initialize the hardware context into a new subroutine
ipmmu_context_init(), to prepare for later reuse.
Signed-off-by: Geert Uytterhoeven
On R-Car Gen3, the faulting virtual address is a 40-bit address, and
comprised of two registers. Read the upper address part, and combine
both parts, when running on a 64-bit system.
Signed-off-by: Geert Uytterhoeven
---
Apart from this, the driver doesn't support 40-bit IOVA addresse
The maximum number of micro-TLBs per IPMMU instance is not fixed, but
depends on the SoC type. Hence move it from struct ipmmu_vmsa_device to
struct ipmmu_features, and set up the correct value for both R-Car Gen2
and Gen3 SoCs.
Note that currently no code uses this value.
Signed-off-by: Geert
There is a helper to write to the root IPMMU instance's registers, so
let's use it.
Signed-off-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vm
SATA enabled. To play safe, the resume operation has also
been tested on R-Car M2-W, where it is currently not enabled due to the
absence of PSCI in the firmware.
Thanks for your comments!
Geert Uytterhoeven (7):
iommu/ipmmu-vmsa: Link IOMMUs and devices in sysfs
iommu/ipmmu-vmsa: Call
resume.
To avoid overhead on platforms not needing it, the resume code has a
build time dependency on sleep and PSCI support, and a runtime
dependency on PSCI.
Signed-off-by: Geert Uytterhoeven
---
This patch takes a different approach than the BSP, which implements a
bulk save/restore of all
all links are created, on both arm32 and arm64.
Signed-off-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 9a380c10655e182d..9f2b781e20a0e
Hi Laurent,
On Wed, Feb 20, 2019 at 4:31 PM Laurent Pinchart
wrote:
> On Wed, Feb 20, 2019 at 04:05:27PM +0100, Geert Uytterhoeven wrote:
> > On R-Car Gen3, the faulting virtual address is a 40-bit address, and
> > comprised of two registers. Read the upper address part, and c
Hi Laurent,
On Wed, Feb 20, 2019 at 4:35 PM Laurent Pinchart
wrote:
> On Wed, Feb 20, 2019 at 04:05:30PM +0100, Geert Uytterhoeven wrote:
> > ipmmu_domain_init_context() takes care of (1) initializing the software
> > domain, and (2) initializing the hardware context
Hi Laurent,
On Wed, Feb 20, 2019 at 4:42 PM Laurent Pinchart
wrote:
> On Wed, Feb 20, 2019 at 04:05:31PM +0100, Geert Uytterhoeven wrote:
> > During PSCI system suspend, R-Car Gen3 SoCs are powered down, and all
> > IPMMU state is lost. Hence after s2ram, devices wired behind an
Hi Laurent,
On Wed, Feb 20, 2019 at 5:11 PM Laurent Pinchart
wrote:
> On Wed, Feb 20, 2019 at 05:05:49PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Feb 20, 2019 at 4:42 PM Laurent Pinchart wrote:
> > > On Wed, Feb 20, 2019 at 04:05:31PM +0100, Geert Uytterhoeven wrote:
t;((n)-1))-1)
> << 1))
The second "-1" should be done on the final result, not on the
intermediate value.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversa
to handle 0 instead.
>
> Yes, good idea.
>
> > FWIW I'd be very tempted to fold in the second shift as "2ULL<<((n)-1)",
> > but that may not be to everyone's taste.
>
> I like that. So shall we do this?
>
> /*
> * Shifting '2'
> devres_release_all(dev);
> driver_sysfs_remove(dev);
> dev->driver = NULL;
> dev_set_drvdata(dev, NULL);
>
> We seem to be able to call arch_teardown_dma_ops() prior to
> devres_release_all() if we reach probe_failed label.
Yes, this
Oops.
-Sending DHCP requests .., OK
-IP-Config: Got DHCP answer from ...
...
+VFS: Unable to mount root fs via NFS, trying floppy.
+VFS: Cannot open root device "nfs" or unknown-block(2,0): error -6
> Does booting with deferred_probe_timeout=0 work?
It does, as n
Hi John,
On Fri, Apr 3, 2020 at 1:47 PM Geert Uytterhoeven wrote:
> On Thu, Apr 2, 2020 at 7:27 PM John Stultz wrote:
> > On Thu, Apr 2, 2020 at 3:17 AM Yoshihiro Shimoda
> > wrote:
> > >
> > > I found an issue after applied the following patches:
> >
irect to ifb
via ingress")
Signed-off-by: Geert Uytterhoeven
---
net/netfilter/nft_fwd_netdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/netfilter/nft_fwd_netdev.c b/net/netfilter/nft_fwd_netdev.c
index 74f050ba6badc9dc..ebcaf5c325712f30 100644
--- a/net/netfilter/nft_
hile at it, remove the dependency on ARM || ARM64, as that is already
implied by the dependency on ARCH_MEDIATEK.
Fixes: e93a1695d7fb5513 ("iommu: Enable compile testing for some of drivers")
Signed-off-by: Geert Uytterhoeven
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+),
On Fri, Apr 10, 2020 at 4:26 PM Geert Uytterhoeven wrote:
> If CONFIG_NET_CLS_ACT=n:
>
> net/netfilter/nft_fwd_netdev.c: In function ‘nft_fwd_netdev_eval’:
> net/netfilter/nft_fwd_netdev.c:32:10: error: ‘struct sk_buff’ has no
> member named ‘tc_redirected’
&
needs to match the main IPMMU IMSSTR register. Only used by
> + cache IPMMU instances.
This property is not valid only on R-Car Gen2 and R-Mobile APE6.
(untested)
oneOf:
- properties:
contains:
const: renesas,ipmmu-vmsa
- properties:
renesas,ipmmu-main:
$ref: /sche
Hi Shimoda-san,
On Thu, Apr 16, 2020 at 11:56 AM Yoshihiro Shimoda
wrote:
> > From: Geert Uytterhoeven, Sent: Wednesday, April 15, 2020 11:21 PM
> > On Tue, Apr 14, 2020 at 2:26 AM Yoshihiro Shimoda
> > wrote:
> > > Convert Renesas VMSA-Compatible IOMMU bindings
> Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
> section.
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68
e interrupt bits at all.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I
.id.au/kisskb/buildresult/14213623/
>
> mm/nommu.c:158:25: error: 'flags' undeclared (first use in this function);
> did you mean 'class'?
"return __vmalloc(size, gfp_mask);", I assume?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- The
e:
> FAILED linux-next/m5272c3_defconfig/m68k-gcc8 Mon Apr 20, 18:38
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/14213623/
>
> mm/nommu.c:164:25: error: 'flags' undeclared (first use in this function);
> did you mean 'class'?
"return __vmalloc(size,
> Gen2. So, renesas,ipmmu-r8a73a4 belongs the renesas,ipmmu-vmsa
> section.
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68
ee '[PATCH v3 00/25] DRM: fix struct sg_table nents
> vs. orig_nents misuse' thread: https://lkml.org/lkml/2020/5/5/187
For the modern lore-users:
https://lore.kernel.org/r/20200505083926.28503-1-m.szyprow...@samsung.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterho
e the default DMA coherent pool size
with memory capacity")
Signed-off-by: Geert Uytterhoeven
---
kernel/dma/pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 35bb51c31fff370f..1c7eab2cc0498003 100644
--- a/kernel/dma/po
Hi Robin,
On Mon, Jun 8, 2020 at 2:04 PM Robin Murphy wrote:
> On 2020-06-08 09:52, Geert Uytterhoeven wrote:
> > On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
> > memory pools are much larger than intended (e.g. 2 MiB instead of 128
> > Ki
keep on
calculating in pages until the last step, which aids readability.
Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool size
with memory capacity")
Signed-off-by: Geert Uytterhoeven
---
v2:
- Improve readability:
- Divide by (SZ_1G / SZ_128K) instead
On Thu, Jun 11, 2020 at 1:11 PM Yoshihiro Shimoda
wrote:
> Add support for r8a77961 (R-Car M3-W+).
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32
le()?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer
ITE)))
> /* If no access create a faulting entry to avoid TLB fills. */
> pgprot &= ~ARM_VMSA_PTE_PAGE;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations wi
offset is still valid.
Shouldn't we have two register blocks, and let the driver use only the
second one?
If you ignore, feel free to add my
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- g
Hi Laurent,
On Mon, Dec 15, 2014 at 7:44 PM, Laurent Pinchart
wrote:
> On Monday 15 December 2014 14:07:52 Geert Uytterhoeven wrote:
>> On Mon, Dec 15, 2014 at 1:13 AM, Laurent Pinchart wrote:
>> > Add the seven IPMMU instances found in the r8a7791 to DT with a di
1 - 100 of 380 matches
Mail list logo
