On Tue, Sep 03, 2019 at 06:25:54PM -0400, Boris Ostrovsky wrote:
> > If I am reading __dma_direct_alloc_pages() correctly there is a path
> > that will force us to use GFP_DMA32 and as Juergen pointed out in
> > another message that may not be desirable.
Yes, it will add GFP_DMA32. So I guess for
On Wed, Sep 04, 2019 at 11:01:18AM +0800, zhong jiang wrote:
> Use kzfree instead of memset() + kfree().
>
> Signed-off-by: zhong jiang
> ---
> drivers/iommu/fsl_pamu.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pa
On Tue, Sep 03, 2019 at 02:07:39PM -0700, Bjorn Andersson wrote:
> Reviewed-by: Bjorn Andersson
>
> Please pick this together with the other patches.
Thanks, I've applied the series to the dma-mapping tree for 5.4.
On 2019/9/4 16:15, Joerg Roedel wrote:
> On Wed, Sep 04, 2019 at 11:01:18AM +0800, zhong jiang wrote:
>> Use kzfree instead of memset() + kfree().
>>
>> Signed-off-by: zhong jiang
>> ---
>> drivers/iommu/fsl_pamu.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/
Use kzfree instead of memset() + kfree().
Signed-off-by: zhong jiang
---
drivers/iommu/fsl_pamu.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index cde281b..e924368 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/driver
Dear Dave,
Thank you for your replies.
On 2019-08-13 04:54, Dave Young wrote:
> On 08/13/19 at 10:46am, Dave Young wrote:
>> On 08/13/19 at 10:43am, Dave Young wrote:
>>> On 08/12/19 at 11:50am, Michal Hocko wrote:
On Mon 12-08-19 11:42:33, Paul Menzel wrote:
> On a Dell PowerEdge R
Move the recently added IMTTBCR_SL0_TWOBIT_* definitions up, to make
sure all IMTTBCR register bit definitions are sorted by decreasing bit
index. Add comments to make it clear that they exist on R-Car Gen3
only.
Fixes: c295f504fb5a38ab ("iommu/ipmmu-vmsa: Allow two bit SL0")
Signed-off-by: Geert
From: Hai Nguyen Pham
According to the Hardware Manual Errata for Rev. 1.50 of April 10, 2019,
cache snoop transactions for page table walk requests are not supported
on R-Car Gen3.
Hence, this patch removes setting these fields in the IMTTBCR register,
since it will have no effect, and adds com
Hi Jörg,
According to recent errata, the IOMMU in R-Car Gen3 SoCs does not
support cache snoop transactions for page table walk requests.
Hence this patch series skips the related setup when running on R-Car
Gen3, after doing a customary cleanup of related definitions.
Tested on R-Car H3
> >>> +free_prev_domain:
> >>> + /*
> >>> + * Free the existing default domain and replace it with the newly
> >>> + * created default domain. No need to set group->domain because
> >>> + * __iommu_attach_group() already does it on success.
> >>> + */
> >>> + iommu_domain_free(prev_domain);
> >
When the system is under some memory pressure, it could cause disks on
the "smartpqi" driver going offline below. From the UBSAN report, it
indicates that "domain->mode" becomes 7. Further investigation indicates
that the only place that would increase "domain->mode" is
increase_address_space() but
On Wed, 2019-09-04 at 12:07 +0800, houlong wei wrote:
> Hi, Yong,
>
> I have inline comment below.
Thanks for your review.
>
> > MediaTek IOMMU has already added the device_link between the consumer
> > and smi-larb device. If the mdp device call the pm_runtime_get_sync,
> > the smi-larb's pm_r
On Wed, Sep 04, 2019 at 02:40:44PM -0700, David Rientjes wrote:
> Hi Christoph, Jens, and Ming,
>
> While booting a 5.2 SEV-enabled guest we have encountered the following
> WARNING that is followed up by a BUG because we are in atomic context
> while trying to call set_memory_decrypted:
Well,
Dave, Joerg, Robin:
is there any chance we could at least pick up patches 2 and 4 ASAP
as they are clearly fixes for current deficits, even without the
amd conversion?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.
14 matches
Mail list logo