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
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
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
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.
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
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
> >>> +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);
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
Fixes: c295f504fb5a38ab ("iommu/ipmmu-vmsa: Allow two bit SL0")
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
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
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
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
Mail list logo