All of lore.kernel.org
 help / color / mirror / Atom feed
From: Claire Chang <tientzu@chromium.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Qian Cai <quic_qiancai@quicinc.com>,
	Will Deacon <will@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	mpe@ellerman.id.au, Joerg Roedel <joro@8bytes.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	boris.ostrovsky@oracle.com, jgross@suse.com,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	heikki.krogerus@linux.intel.com,
	thomas.hellstrom@linux.intel.com, peterz@infradead.org,
	benh@kernel.crashing.org, joonas.lahtinen@linux.intel.com,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	grant.likely@arm.com, paulus@samba.org, mingo@kernel.org,
	Jianxiong Gao <jxgao@google.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	xypron.glpk@gmx.de,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	bskeggs@redhat.com, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Thierry Reding <treding@nvidia.com>,
	intel-gfx@lists.freedesktop.org, matthew.auld@intel.com,
	linux-devicetree <devicetree@vger.kernel.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	airlied@linux.ie, maarten.lankhorst@linux.intel.com,
	linuxppc-dev@lists.ozlabs.org, jani.nikula@linux.intel.com,
	Nicolas Boichat <drinkcat@chromium.org>,
	rodrigo.vivi@intel.com, Bjorn Helgaas <bhelgaas@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Robin Murphy <robin.murphy@arm.com>,
	bauerman@linux.ibm.com
Subject: Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Thu, 24 Jun 2021 14:05:39 +0800	[thread overview]
Message-ID: <CALiNf288ZLMhY3E8E3N+z9rkwi1viWNLm1wwMEwT4rNwh3FfwQ@mail.gmail.com> (raw)
In-Reply-To: <20210624054315.GA25381@lst.de>

On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
> >
> > is_swiotlb_force_bounce() was the new function introduced in this patch here.
> >
> > +static inline bool is_swiotlb_force_bounce(struct device *dev)
> > +{
> > +     return dev->dma_io_tlb_mem->force_bounce;
> > +}
>
> To me the crash looks like dev->dma_io_tlb_mem is NULL.  Can you
> turn this into :
>
>         return dev->dma_io_tlb_mem && dev->dma_io_tlb_mem->force_bounce;
>
> for a quick debug check?

I just realized that dma_io_tlb_mem might be NULL like Christoph
pointed out since swiotlb might not get initialized.
However,  `Unable to handle kernel paging request at virtual address
dfff80000000000e` looks more like the address is garbage rather than
NULL?
I wonder if that's because dev->dma_io_tlb_mem is not assigned
properly (which means device_initialize is not called?).

WARNING: multiple messages have this Message-ID (diff)
From: Claire Chang <tientzu@chromium.org>
To: Christoph Hellwig <hch@lst.de>
Cc: heikki.krogerus@linux.intel.com,
	linux-devicetree <devicetree@vger.kernel.org>,
	peterz@infradead.org, joonas.lahtinen@linux.intel.com,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	grant.likely@arm.com, paulus@samba.org,
	Frank Rowand <frowand.list@gmail.com>,
	mingo@kernel.org, Jianxiong Gao <jxgao@google.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	Joerg Roedel <joro@8bytes.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	bskeggs@redhat.com, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Dan Williams <dan.j.williams@intel.com>,
	matthew.auld@intel.com, Nicolas Boichat <drinkcat@chromium.org>,
	thomas.hellstrom@linux.intel.com,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Will Deacon <will@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	intel-gfx@lists.freedesktop.org,
	maarten.lankhorst@linux.intel.com,
	Robin Murphy <robin.murphy@arm.com>,
	jani.nikula@linux.intel.com, Rob Herring <robh+dt@kernel.org>,
	rodrigo.vivi@intel.com, Bjorn Helgaas <bhelgaas@google.com>,
	boris.ostrovsky@oracle.com,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	jgross@suse.com, airlied@linux.ie,
	Thierry Reding <treding@nvidia.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Qian Cai <quic_qiancai@quicinc.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	xypron.glpk@gmx.de, Tom Lendacky <thomas.lendacky@amd.com>,
	linuxppc-dev@lists.ozlabs.org, bauerman@linux.ibm.com
Subject: Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Thu, 24 Jun 2021 14:05:39 +0800	[thread overview]
Message-ID: <CALiNf288ZLMhY3E8E3N+z9rkwi1viWNLm1wwMEwT4rNwh3FfwQ@mail.gmail.com> (raw)
In-Reply-To: <20210624054315.GA25381@lst.de>

On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
> >
> > is_swiotlb_force_bounce() was the new function introduced in this patch here.
> >
> > +static inline bool is_swiotlb_force_bounce(struct device *dev)
> > +{
> > +     return dev->dma_io_tlb_mem->force_bounce;
> > +}
>
> To me the crash looks like dev->dma_io_tlb_mem is NULL.  Can you
> turn this into :
>
>         return dev->dma_io_tlb_mem && dev->dma_io_tlb_mem->force_bounce;
>
> for a quick debug check?

I just realized that dma_io_tlb_mem might be NULL like Christoph
pointed out since swiotlb might not get initialized.
However,  `Unable to handle kernel paging request at virtual address
dfff80000000000e` looks more like the address is garbage rather than
NULL?
I wonder if that's because dev->dma_io_tlb_mem is not assigned
properly (which means device_initialize is not called?).

WARNING: multiple messages have this Message-ID (diff)
From: Claire Chang <tientzu@chromium.org>
To: Christoph Hellwig <hch@lst.de>
Cc: heikki.krogerus@linux.intel.com,
	linux-devicetree <devicetree@vger.kernel.org>,
	peterz@infradead.org, benh@kernel.crashing.org,
	joonas.lahtinen@linux.intel.com, dri-devel@lists.freedesktop.org,
	chris@chris-wilson.co.uk, grant.likely@arm.com, paulus@samba.org,
	Frank Rowand <frowand.list@gmail.com>,
	mingo@kernel.org, Jianxiong Gao <jxgao@google.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	mpe@ellerman.id.au,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	bskeggs@redhat.com, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Dan Williams <dan.j.williams@intel.com>,
	matthew.auld@intel.com, Nicolas Boichat <drinkcat@chromium.org>,
	thomas.hellstrom@linux.intel.com,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Will Deacon <will@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	intel-gfx@lists.freedesktop.org,
	maarten.lankhorst@linux.intel.com,
	Robin Murphy <robin.murphy@arm.com>,
	jani.nikula@linux.intel.com, Rob Herring <robh+dt@kernel.org>,
	rodrigo.vivi@intel.com, Bjorn Helgaas <bhelgaas@google.com>,
	boris.ostrovsky@oracle.com,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	jgross@suse.com, airlied@linux.ie,
	Thierry Reding <treding@nvidia.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Qian Cai <quic_qiancai@quicinc.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	xypron.glpk@gmx.de, Tom Lendacky <thomas.lendacky@amd.com>,
	linuxppc-dev@lists.ozlabs.org, bauerman@linux.ibm.com
Subject: Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Thu, 24 Jun 2021 14:05:39 +0800	[thread overview]
Message-ID: <CALiNf288ZLMhY3E8E3N+z9rkwi1viWNLm1wwMEwT4rNwh3FfwQ@mail.gmail.com> (raw)
In-Reply-To: <20210624054315.GA25381@lst.de>

On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
> >
> > is_swiotlb_force_bounce() was the new function introduced in this patch here.
> >
> > +static inline bool is_swiotlb_force_bounce(struct device *dev)
> > +{
> > +     return dev->dma_io_tlb_mem->force_bounce;
> > +}
>
> To me the crash looks like dev->dma_io_tlb_mem is NULL.  Can you
> turn this into :
>
>         return dev->dma_io_tlb_mem && dev->dma_io_tlb_mem->force_bounce;
>
> for a quick debug check?

I just realized that dma_io_tlb_mem might be NULL like Christoph
pointed out since swiotlb might not get initialized.
However,  `Unable to handle kernel paging request at virtual address
dfff80000000000e` looks more like the address is garbage rather than
NULL?
I wonder if that's because dev->dma_io_tlb_mem is not assigned
properly (which means device_initialize is not called?).
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Claire Chang <tientzu@chromium.org>
To: Christoph Hellwig <hch@lst.de>
Cc: heikki.krogerus@linux.intel.com,
	linux-devicetree <devicetree@vger.kernel.org>,
	peterz@infradead.org, dri-devel@lists.freedesktop.org,
	chris@chris-wilson.co.uk, grant.likely@arm.com, paulus@samba.org,
	Frank Rowand <frowand.list@gmail.com>,
	mingo@kernel.org, Jianxiong Gao <jxgao@google.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	mpe@ellerman.id.au, Joerg Roedel <joro@8bytes.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	bskeggs@redhat.com, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Dan Williams <dan.j.williams@intel.com>,
	matthew.auld@intel.com, Nicolas Boichat <drinkcat@chromium.org>,
	thomas.hellstrom@linux.intel.com,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Will Deacon <will@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	intel-gfx@lists.freedesktop.org,
	Robin Murphy <robin.murphy@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	rodrigo.vivi@intel.com, Bjorn Helgaas <bhelgaas@google.com>,
	boris.ostrovsky@oracle.com,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	jgross@suse.com, airlied@linux.ie,
	Thierry Reding <treding@nvidia.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Qian Cai <quic_qiancai@quicinc.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	xypron.glpk@gmx.de, Tom Lendacky <thomas.lendacky@amd.com>,
	linuxppc-dev@lists.ozlabs.org, bauerman@linux.ibm.com
Subject: Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Thu, 24 Jun 2021 14:05:39 +0800	[thread overview]
Message-ID: <CALiNf288ZLMhY3E8E3N+z9rkwi1viWNLm1wwMEwT4rNwh3FfwQ@mail.gmail.com> (raw)
In-Reply-To: <20210624054315.GA25381@lst.de>

On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
> >
> > is_swiotlb_force_bounce() was the new function introduced in this patch here.
> >
> > +static inline bool is_swiotlb_force_bounce(struct device *dev)
> > +{
> > +     return dev->dma_io_tlb_mem->force_bounce;
> > +}
>
> To me the crash looks like dev->dma_io_tlb_mem is NULL.  Can you
> turn this into :
>
>         return dev->dma_io_tlb_mem && dev->dma_io_tlb_mem->force_bounce;
>
> for a quick debug check?

I just realized that dma_io_tlb_mem might be NULL like Christoph
pointed out since swiotlb might not get initialized.
However,  `Unable to handle kernel paging request at virtual address
dfff80000000000e` looks more like the address is garbage rather than
NULL?
I wonder if that's because dev->dma_io_tlb_mem is not assigned
properly (which means device_initialize is not called?).

WARNING: multiple messages have this Message-ID (diff)
From: Claire Chang <tientzu@chromium.org>
To: Christoph Hellwig <hch@lst.de>
Cc: heikki.krogerus@linux.intel.com,
	linux-devicetree <devicetree@vger.kernel.org>,
	peterz@infradead.org, benh@kernel.crashing.org,
	dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk,
	grant.likely@arm.com, paulus@samba.org,
	Frank Rowand <frowand.list@gmail.com>,
	mingo@kernel.org, Jianxiong Gao <jxgao@google.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Saravana Kannan <saravanak@google.com>,
	mpe@ellerman.id.au, Joerg Roedel <joro@8bytes.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	bskeggs@redhat.com, linux-pci@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Dan Williams <dan.j.williams@intel.com>,
	matthew.auld@intel.com, Nicolas Boichat <drinkcat@chromium.org>,
	thomas.hellstrom@linux.intel.com,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Will Deacon <will@kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	intel-gfx@lists.freedesktop.org,
	Robin Murphy <robin.murphy@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	boris.ostrovsky@oracle.com,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	jgross@suse.com, airlied@linux.ie,
	Thierry Reding <treding@nvidia.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Qian Cai <quic_qiancai@quicinc.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	xypron.glpk@gmx.de, Tom Lendacky <thomas.lendacky@amd.com>,
	linuxppc-dev@lists.ozlabs.org, bauerman@linux.ibm.com
Subject: Re: [Intel-gfx] [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Date: Thu, 24 Jun 2021 14:05:39 +0800	[thread overview]
Message-ID: <CALiNf288ZLMhY3E8E3N+z9rkwi1viWNLm1wwMEwT4rNwh3FfwQ@mail.gmail.com> (raw)
In-Reply-To: <20210624054315.GA25381@lst.de>

On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
> >
> > is_swiotlb_force_bounce() was the new function introduced in this patch here.
> >
> > +static inline bool is_swiotlb_force_bounce(struct device *dev)
> > +{
> > +     return dev->dma_io_tlb_mem->force_bounce;
> > +}
>
> To me the crash looks like dev->dma_io_tlb_mem is NULL.  Can you
> turn this into :
>
>         return dev->dma_io_tlb_mem && dev->dma_io_tlb_mem->force_bounce;
>
> for a quick debug check?

I just realized that dma_io_tlb_mem might be NULL like Christoph
pointed out since swiotlb might not get initialized.
However,  `Unable to handle kernel paging request at virtual address
dfff80000000000e` looks more like the address is garbage rather than
NULL?
I wonder if that's because dev->dma_io_tlb_mem is not assigned
properly (which means device_initialize is not called?).
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-06-24  6:14 UTC|newest]

Thread overview: 150+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-19  3:40 [PATCH v14 00/12] Restricted DMA Claire Chang
2021-06-19  3:40 ` [Intel-gfx] " Claire Chang
2021-06-19  3:40 ` Claire Chang
2021-06-19  3:40 ` Claire Chang
2021-06-19  3:40 ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 01/12] swiotlb: Refactor swiotlb init functions Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-22 21:02   ` Stefano Stabellini
2021-06-22 21:02     ` Stefano Stabellini
2021-06-22 21:02     ` [Intel-gfx] " Stefano Stabellini
2021-06-22 21:02     ` Stefano Stabellini
2021-06-22 21:02     ` Stefano Stabellini
2021-06-22 21:02     ` Stefano Stabellini
2021-06-19  3:40 ` [PATCH v14 02/12] swiotlb: Refactor swiotlb_create_debugfs Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 03/12] swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 04/12] swiotlb: Update is_swiotlb_buffer to add a struct device argument Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 05/12] swiotlb: Update is_swiotlb_active " Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-23 16:39   ` Qian Cai
2021-06-23 16:39     ` [Intel-gfx] " Qian Cai
2021-06-23 16:39     ` Qian Cai
2021-06-23 16:39     ` Qian Cai
2021-06-23 16:39     ` Qian Cai
2021-06-23 18:37     ` Will Deacon
2021-06-23 18:37       ` [Intel-gfx] " Will Deacon
2021-06-23 18:37       ` Will Deacon
2021-06-23 18:37       ` Will Deacon
2021-06-23 18:37       ` Will Deacon
2021-06-23 18:44       ` Qian Cai
2021-06-23 18:44         ` [Intel-gfx] " Qian Cai
2021-06-23 18:44         ` Qian Cai
2021-06-23 18:44         ` Qian Cai
2021-06-23 18:44         ` Qian Cai
2021-06-24  5:43         ` Christoph Hellwig
2021-06-24  5:43           ` [Intel-gfx] " Christoph Hellwig
2021-06-24  5:43           ` Christoph Hellwig
2021-06-24  5:43           ` Christoph Hellwig
2021-06-24  6:05           ` Claire Chang [this message]
2021-06-24  6:05             ` Claire Chang
2021-06-24  6:05             ` [Intel-gfx] " Claire Chang
2021-06-24  6:05             ` Claire Chang
2021-06-24  6:05             ` Claire Chang
2021-06-24  6:05             ` Claire Chang
2021-06-24 11:14             ` Robin Murphy
2021-06-24 11:14               ` [Intel-gfx] " Robin Murphy
2021-06-24 11:14               ` Robin Murphy
2021-06-24 11:14               ` Robin Murphy
2021-06-24 11:14               ` Robin Murphy
2021-06-24 11:18               ` Will Deacon
2021-06-24 11:18                 ` [Intel-gfx] " Will Deacon
2021-06-24 11:18                 ` Will Deacon
2021-06-24 11:18                 ` Will Deacon
2021-06-24 11:18                 ` Will Deacon
2021-06-24 11:34                 ` Robin Murphy
2021-06-24 11:34                   ` [Intel-gfx] " Robin Murphy
2021-06-24 11:34                   ` Robin Murphy
2021-06-24 11:34                   ` Robin Murphy
2021-06-24 11:34                   ` Robin Murphy
2021-06-24 11:48                   ` Will Deacon
2021-06-24 11:48                     ` [Intel-gfx] " Will Deacon
2021-06-24 11:48                     ` Will Deacon
2021-06-24 11:48                     ` Will Deacon
2021-06-24 11:48                     ` Will Deacon
2021-06-24 14:10                     ` Qian Cai
2021-06-24 14:10                       ` [Intel-gfx] " Qian Cai
2021-06-24 14:10                       ` Qian Cai
2021-06-24 14:10                       ` Qian Cai
2021-06-24 14:10                       ` Qian Cai
2021-06-24 15:55                       ` Konrad Rzeszutek Wilk
2021-06-24 15:55                         ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-06-24 15:55                         ` Konrad Rzeszutek Wilk
2021-06-24 15:55                         ` Konrad Rzeszutek Wilk
2021-06-24 15:55                         ` Konrad Rzeszutek Wilk
2021-06-24 15:58                         ` Claire Chang
2021-06-24 15:58                           ` Claire Chang
2021-06-24 15:58                           ` [Intel-gfx] " Claire Chang
2021-06-24 15:58                           ` Claire Chang
2021-06-24 15:58                           ` Claire Chang
2021-06-24 15:58                           ` Claire Chang
2021-06-24 19:20                           ` Konrad Rzeszutek Wilk
2021-06-24 19:20                             ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-06-24 19:20                             ` Konrad Rzeszutek Wilk
2021-06-24 19:20                             ` Konrad Rzeszutek Wilk
2021-06-24 19:20                             ` Konrad Rzeszutek Wilk
2021-06-19  3:40 ` [PATCH v14 07/12] swiotlb: Move alloc_size to swiotlb_find_slots Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 08/12] swiotlb: Refactor swiotlb_tbl_unmap_single Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 09/12] swiotlb: Add restricted DMA alloc/free support Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 10/12] swiotlb: Add restricted DMA pool initialization Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 11/12] dt-bindings: of: Add restricted DMA pool Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40 ` [PATCH v14 12/12] of: Add plumbing for " Claire Chang
2021-06-19  3:40   ` [Intel-gfx] " Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  3:40   ` Claire Chang
2021-06-19  4:05 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA Patchwork
2021-06-23  8:38 ` [PATCH v14 00/12] " Konrad Rzeszutek Wilk
2021-06-23  8:38   ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-06-23  8:38   ` Konrad Rzeszutek Wilk
2021-06-23  8:38   ` Konrad Rzeszutek Wilk
2021-06-23  8:38   ` Konrad Rzeszutek Wilk
2021-06-23  9:01   ` Claire Chang
2021-06-23  9:01     ` Claire Chang
2021-06-23  9:01     ` [Intel-gfx] " Claire Chang
2021-06-23  9:01     ` Claire Chang
2021-06-23  9:01     ` Claire Chang
2021-06-23  9:01     ` Claire Chang
2021-06-28 16:46 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA (rev2) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALiNf288ZLMhY3E8E3N+z9rkwi1viWNLm1wwMEwT4rNwh3FfwQ@mail.gmail.com \
    --to=tientzu@chromium.org \
    --cc=airlied@linux.ie \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bauerman@linux.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=bhelgaas@google.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bskeggs@redhat.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dan.j.williams@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=drinkcat@chromium.org \
    --cc=frowand.list@gmail.com \
    --cc=grant.likely@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=james.quinlan@broadcom.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=jgross@suse.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=joro@8bytes.org \
    --cc=jxgao@google.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=quic_qiancai@quicinc.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=saravanak@google.com \
    --cc=sstabellini@kernel.org \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=thomas.lendacky@amd.com \
    --cc=treding@nvidia.com \
    --cc=will@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.