On Thu, Aug 06, 2020 at 08:47:55PM +0200, Nicolas Saenz Julienne wrote:
> There is no guarantee to CMA's placement, so allocating a zone specific
> atomic pool from CMA might return memory from a completely different
> memory zone. To get around this double check CMA's placement before
> allocating
Hi baolu,
I understand what you mean is that you want to put the
following processing code in the acpi_device_create_direct_mappings() into the
probe_acpi_namespace_devices() ,right?
If you mean it , I think it's OK.
if (pn_dev == NULL) {
On Mon, 2020-07-27 at 16:49 +0800, chao hao wrote:
> On Sat, 2020-07-11 at 14:48 +0800, Yong Wu wrote:
> > In the previous SoC, the M4U HW is in the EMI power domain which is
> > always on. the latest M4U is in the display power domain which may be
> > turned on/off, thus we have to add pm_runtime
Hi Felix,
On 2020/8/6 14:51, FelixCui-oc wrote:
Hi baolu,
>Sure. Before that, let me sync my understanding with you. You
have an acpi namespace device in ANDD table, it also shows up in the device scope
of a RMRR.
>Current code doesn't enumerate that device for
Hi Nicolas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on iommu/next]
[also build test WARNING on linus/master v5.8]
[cannot apply to next-20200806]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
From: Christoph Hellwig
When allocating coherent pool memory for an IOMMU mapping we don't care
about the DMA mask. Move the guess for the initial GFP mask into the
dma_direct_alloc_pages and pass dma_coherent_ok as a function pointer
argument so that it doesn't get applied to the IOMMU case.
S
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. To get around this double check CMA's placement before
allocating from it.
Signed-off-by: Nicolas Saenz Julienne
[hch: rebased, added a fallbac
Now that we have an explanation to Amir's issue, we can re-spin this
series.
---
Changes since v2:
- Go back to v1's behavior for patch #2
Changes since v1:
- Make cma_in_zone() more strict, GFP_KERNEL doesn't default to true
now
- Check if phys_addr_ok() exists prior calling it
Christoph
From: Thierry Reding
Set the name of static IOMMU groups to help with debugging.
Signed-off-by: Thierry Reding
---
drivers/iommu/tegra-smmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 124c8848ab7e..1ffdafe892d9 100644
---
From: Thierry Reding
I was running into some use-after-free conditions after recent changes
to the host1x driver cause the child devices to be destroyed upon driver
unloading. This in turn caused the IOMMU groups associated with the
child devices to also get released and that uncovered a subtle r
From: Thierry Reding
For groups that are shared between multiple devices, care must be taken
to acquire a reference for each device, otherwise the IOMMU core ends up
dropping the last reference too early, which will cause the group to be
released while consumers may still be thinking that they're
From: Thierry Reding
In order to share groups between multiple devices we keep track of them
in a per-SMMU list. When an IOMMU group is released, a dangling pointer
to it stays around in that list. Fix this by implementing an IOMMU data
release callback for groups where the dangling pointer can b
On Thu, Aug 06, 2020 at 01:50:29PM +0200, Nicolas Saenz Julienne wrote:
> > The latter is pretty much what I expect, as we only support the default and
> > per-device DMA CMAs.
>
> Fair enough, should I send a v3 with everything cleaned-up/rebased, or you'd
> rather pick it up from your version?
Hello,
syzbot found the following issue on:
HEAD commit:47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16fe1dea90
kernel config: https://syzkaller.appspot.com/x/.config?x=7c06047f622c5724
das
On Thu, 2020-08-06 at 07:18 +0200, Christoph Hellwig wrote:
> On Tue, Aug 04, 2020 at 11:43:15AM +0200, Nicolas Saenz Julienne wrote:
> > > Second I don't see the need (and actually some harm) in preventing
> > > GFP_KERNEL
> > > allocations from dipping into lower CMA areas - something that we di
15 matches
Mail list logo
