On Wed, Nov 28, 2018 at 12:48 PM Russell King - ARM Linux
wrote:
>
> On Wed, Nov 28, 2018 at 11:27:17AM -0800, David Miller wrote:
> > From: Linus Torvalds
> > Date: Wed, 28 Nov 2018 10:00:06 -0800
> >
> > > Not all memory is accessible even to the kernel. If you have memory
> > > that shows up i
[Re: [PATCH 5/9] iommu: ipmmu-vmsa: make it explicitly non-modular] On
28/11/2018 (Wed 19:22) Laurent Pinchart wrote:
> Hi Paul,
>
> On Wednesday, 28 November 2018 17:32:05 EET Paul Gortmaker wrote:
> > [Re: [PATCH 5/9] iommu: ipmmu-vmsa: make it explicitly non-modular] On
> 28/11/2018 (Wed 12:
On Wed, 28 Nov 2018 16:55:30 +0100
Christian Zigotzky wrote:
> On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
> > Nothing specific yet.
> >
> > I'm a bit worried it might break one of the many old obscure platforms
> > we have that aren't well tested.
> >
> Please don't apply the new D
On Tue, Nov 27, 2018 at 10:54:26AM +0200, Mika Westerberg wrote:
> On Mon, Nov 26, 2018 at 06:17:11PM -0600, Bjorn Helgaas wrote:
> > Hi Mika,
>
> Hi,
>
> > On Mon, Nov 26, 2018 at 02:15:23PM +0300, Mika Westerberg wrote:
> > > Recent systems with Thunderbolt ports may support IOMMU natively.
> >
I will compile and test the kernel from the following Git on my PowerPC
machines.
http://git.infradead.org/users/hch/misc.git
On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
Nothing specific yet.
I'm a bit worried it might break one of the many old obscure platforms
we have that aren't
On Wed, Nov 28, 2018 at 11:27:17AM -0800, David Miller wrote:
> From: Linus Torvalds
> Date: Wed, 28 Nov 2018 10:00:06 -0800
>
> > Not all memory is accessible even to the kernel. If you have memory
> > that shows up in the last page of phys_addr_t, you just mark it
> > reserved at boot-time.
>
On Wed, Nov 28, 2018 at 11:19:15AM -0800, Linus Torvalds wrote:
> On Wed, Nov 28, 2018, 10:08 Russell King - ARM Linux wrote:
>
> > >
> > > You already cannot do that kmalloc(), exactly because of ERR_PTR().
> >
> > I'm very sorry, but I think you are confused.
> >
> > kmalloc() returns a _virtua
From: Linus Torvalds
Date: Wed, 28 Nov 2018 10:00:06 -0800
> Not all memory is accessible even to the kernel. If you have memory
> that shows up in the last page of phys_addr_t, you just mark it
> reserved at boot-time.
It's not the physical memory at the end that needs to be reserved.
It's the
On Wed, Nov 28, 2018 at 06:08:41PM +, Russell King - ARM Linux wrote:
> On Wed, Nov 28, 2018 at 10:00:06AM -0800, Linus Torvalds wrote:
> > On Wed, Nov 28, 2018 at 9:45 AM Russell King - ARM Linux
> > wrote:
> > >
> > > > I don't think this is a huge deal, but ERR_PTR() has been hugely
> > > >
On Wed, Nov 28, 2018, 10:08 Russell King - ARM Linux >
> > You already cannot do that kmalloc(), exactly because of ERR_PTR().
>
> I'm very sorry, but I think you are confused.
>
> kmalloc() returns a _virtual_ address, which quite rightly must not be
> in the top 4K of 4GB, exactly due to ERR_PTR
On Wed, Nov 28, 2018 at 10:00:06AM -0800, Linus Torvalds wrote:
> On Wed, Nov 28, 2018 at 9:45 AM Russell King - ARM Linux
> wrote:
> >
> > > I don't think this is a huge deal, but ERR_PTR() has been hugely
> > > successful elsewhere. And I'm not hugely convinced about all these
> > > "any address
On Wed, Nov 28, 2018 at 9:45 AM Russell King - ARM Linux
wrote:
>
> > I don't think this is a huge deal, but ERR_PTR() has been hugely
> > successful elsewhere. And I'm not hugely convinced about all these
> > "any address can be valid" arguments. How the hell do you generate a
> > random dma addr
On Wed, Nov 28, 2018 at 08:47:05AM -0800, Linus Torvalds wrote:
> On Tue, Nov 27, 2018 at 11:41 PM Christoph Hellwig wrote:
> >
> > On Fri, Nov 23, 2018 at 07:55:11AM +0100, Christoph Hellwig wrote:
> > > Well, I can tweak the last patch to return -EINVAL from dma_mapping_error
> > > instead of th
On 28/11/2018 15:24, Paul Gortmaker wrote:
[Re: [PATCH 8/9] iommu: arm-smmu: make it explicitly non-modular] On 28/11/2018
(Wed 12:42) Robin Murphy wrote:
Hi Paul,
On 26/11/2018 22:31, Paul Gortmaker wrote:
[...]
We add a moduleparam.h include since the file does actually declare
some mod
Hi Paul,
On Wednesday, 28 November 2018 17:32:05 EET Paul Gortmaker wrote:
> [Re: [PATCH 5/9] iommu: ipmmu-vmsa: make it explicitly non-modular] On
28/11/2018 (Wed 12:50) Robin Murphy wrote:
> > On 26/11/2018 22:31, Paul Gortmaker wrote:
> [...]
>
> >> diff --git a/drivers/iommu/ipmmu-vmsa.c b/d
On Tue, Nov 27, 2018 at 11:41 PM Christoph Hellwig wrote:
>
> On Fri, Nov 23, 2018 at 07:55:11AM +0100, Christoph Hellwig wrote:
> > Well, I can tweak the last patch to return -EINVAL from dma_mapping_error
> > instead of the old 1 is as bool true. The callers should all be fine,
> > although I'd
On 28/11/2018 16:24, Stephen Boyd wrote:
Quoting Vivek Gautam (2018-11-27 02:11:41)
@@ -1966,6 +1970,23 @@ static const struct of_device_id arm_smmu_of_match[] = {
};
MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
+static void arm_smmu_fill_clk_data(struct arm_smmu_device *smmu,
+
Quoting Vivek Gautam (2018-11-27 02:11:41)
> @@ -1966,6 +1970,23 @@ static const struct of_device_id arm_smmu_of_match[] =
> {
> };
> MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
>
> +static void arm_smmu_fill_clk_data(struct arm_smmu_device *smmu,
> + const cha
On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
Nothing specific yet.
I'm a bit worried it might break one of the many old obscure platforms
we have that aren't well tested.
Please don't apply the new DMA mapping code if you don't be sure if it
works on all supported PowerPC machines.
[Re: [PATCH 5/9] iommu: ipmmu-vmsa: make it explicitly non-modular] On
28/11/2018 (Wed 12:50) Robin Murphy wrote:
> On 26/11/2018 22:31, Paul Gortmaker wrote:
[...]
> >diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> >index 9e2655f1c1bf..de39ef992d8a 100644
> >--- a/driver
[Re: [PATCH 8/9] iommu: arm-smmu: make it explicitly non-modular] On 28/11/2018
(Wed 12:42) Robin Murphy wrote:
> Hi Paul,
>
> On 26/11/2018 22:31, Paul Gortmaker wrote:
[...]
> >We add a moduleparam.h include since the file does actually declare
> >some module parameters, and leaving them as
On Wed, 28 Nov 2018 20:21:02 +0530
gokul cg wrote:
> Hi Folks,
>
> Please excuse me , I just writing to you as i could see you had made
> changes regarding iommu and I thought you could give help me here.
>
> We are testing visualization with QEMU-2.7.0 + Linux-4.8+, we are facing
> issue while
Am Donnerstag, 15. November 2018, 16:45:30 CET schrieb Souptick Joarder:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> b
Hi Folks,
Please excuse me , I just writing to you as i could see you had made
changes regarding iommu and I thought you could give help me here.
We are testing visualization with QEMU-2.7.0 + Linux-4.8+, we are facing
issue while configuring pass through PCI devices in QEMU to pass it to
guest O
On 11/27/18 4:11 AM, 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_ru
On 26/11/2018 22:31, Paul Gortmaker wrote:
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config IPMMU_VMSA
drivers/iommu/Kconfig:bool "Renesas VMSA-compatible IPMMU"
...meaning that it currently is not being built as a module by anyone.
Lets remov
On 26/11/2018 22:31, Paul Gortmaker wrote:
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config ARM_SMMU_V3
drivers/iommu/Kconfig: bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
...meaning that it currently is not being built as a module by anyone.
Hi Paul,
On 26/11/2018 22:31, Paul Gortmaker wrote:
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config ARM_SMMU
drivers/iommu/Kconfig: bool "ARM Ltd. System MMU (SMMU) Support"
...meaning that it currently is not being built as a module by anyone.
Let
On 27/11/2018 07:37, Christoph Hellwig wrote:
On Thu, Nov 15, 2018 at 12:58:04PM -0800, Robin Murphy wrote:
On 2018-11-15 11:50 am, Will Deacon wrote:
On Fri, Nov 09, 2018 at 08:52:38AM +0100, Christoph Hellwig wrote:
Can I get a quick review from the arm64 folks? I think it should
be fine th
On Wed, Nov 28, 2018 at 12:24:27PM +0100, Rafael J. Wysocki wrote:
> I'm not sure if this is worth the extra complexity either, which is
> why I have no strong opinion here. :-)
>
> Maybe you can add a comment, next to the prp_guids[] definition, to
> explain that the GUIDs are made equivalent to
On Wed, Nov 28, 2018 at 11:54 AM Mika Westerberg
wrote:
>
> On Tue, Nov 27, 2018 at 06:14:43PM +0100, Rafael J. Wysocki wrote:
> > > diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> > > index 8c7c4583b52d..4bdad32f62c8 100644
> > > --- a/drivers/acpi/property.c
> > > +++ b/drivers/
Christoph Hellwig writes:
> Any comments? I'd like to at least get the ball moving on the easy
> bits.
Nothing specific yet.
I'm a bit worried it might break one of the many old obscure platforms
we have that aren't well tested.
There's not much we can do about that, but I'll just try and tes
On Tue, Nov 27, 2018 at 06:14:43PM +0100, Rafael J. Wysocki wrote:
> > diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> > index 8c7c4583b52d..4bdad32f62c8 100644
> > --- a/drivers/acpi/property.c
> > +++ b/drivers/acpi/property.c
> > @@ -31,6 +31,9 @@ static const guid_t prp_guids[]
To avoid adding copy and pasted strcmp codes in the future,
this patch adds an array "rcar_gen3_slave_whitelist" to check
whether the device can work with the IPMMU or not.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 13 -
1 file
Some R-Car Gen3 SoCs has hardware restrictions on the IPMMU. So,
to check whether this R-Car Gen3 SoC can use the IPMMU correctly,
this patch modifies the ipmmu_slave_whitelist().
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 34 ++
This patch set is based on iommu.git / latest next branch
(commit id = f262283c224537962cba0f41b8823e3be9f7b0ff)
I talked with Geert-san about this topic on below:
https://patchwork.kernel.org/patch/10651375/
Also Simon-san suggests we should keep the whitelist.
So, not to change behavior of R-C
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, November 28, 2018 5:48 PM
>
> Hi Shimoda-san,
>
> On Wed, Nov 28, 2018 at 7:10 AM Yoshihiro Shimoda
> wrote:
> > To avoid adding copy and pasted strcmp codes in the future,
> > this patch adds an array "rcar_gen3_slave_whitelist" to che
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, November 28, 2018 5:47 PM
>
> Hi Shimoda-san,
>
> On Wed, Nov 28, 2018 at 7:10 AM Yoshihiro Shimoda
> wrote:
> > Some R-Car Gen3 SoCs has hardware restrictions on the IPMMU. So,
> > to check whether this R-Car Gen3 SoC can use the IPMMU
On Mon, Nov 26, 2018 at 4:02 PM Christoph Hellwig wrote:
>
> On Fri, Nov 23, 2018 at 01:23:41PM +0100, Vlastimil Babka wrote:
> > Is this also true for caches created by kmem_cache_create(), that
> > debugging options can result in not respecting the alignment passed to
> > kmem_cache_create()? Th
Hi Shimoda-san,
On Wed, Nov 28, 2018 at 7:10 AM Yoshihiro Shimoda
wrote:
> To avoid adding copy and pasted strcmp codes in the future,
> this patch adds an array "rcar_gen3_slave_whitelist" to check
> whether the device can work with the IPMMU or not.
>
> Signed-off-by: Yoshihiro Shimoda
Review
Hi Shimoda-san,
On Wed, Nov 28, 2018 at 7:10 AM Yoshihiro Shimoda
wrote:
> Some R-Car Gen3 SoCs has hardware restrictions on the IPMMU. So,
> to check whether this R-Car Gen3 SoC can use the IPMMU correctly,
> this patch modifies the ipmmu_slave_whitelist().
>
> Signed-off-by: Yoshihiro Shimoda
From: Joerg Roedel
Make use of pr_fmt instead of having the 'AMD-Vi' prefix
added manually at every printk() call.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 38 ++--
drivers/iommu/amd_iommu_init.c | 64 ++
drivers/iommu/amd
From: Joerg Roedel
Remove the leading 0s in the address field of the error log
messages.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
in
Hi,
here are a couple of patches to clean up the message
printing in the AMD IOMMU driver a bit. The patches switch
the driver to use pr_fmt() instead of inconsistently open
coding the 'AMD-Vi' prefix in error messages. Furhter the
Event log messages are fixed and contain no newline anymore.
The a
From: Joerg Roedel
With the switch to dev_err for reporting errors from the
iommu log there was an unwanted newline introduced. The
reason was that the reporting was done in multiple dev_err()
calls, and dev_err adds a newline after every call.
Fix it by printing the log messages with only one d
45 matches
Mail list logo
