All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: joro@8bytes.org, will@kernel.org, lorenzo.pieralisi@arm.com,
	robh+dt@kernel.org, guohanjun@huawei.com, sudeep.holla@arm.com,
	rjw@rjwysocki.net, lenb@kernel.org, robin.murphy@arm.com,
	Jonathan.Cameron@huawei.com, iommu@lists.linux-foundation.org,
	devicetree@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-accelerators@lists.ozlabs.org, baolu.lu@linux.intel.com,
	jacob.jun.pan@linux.intel.com, kevin.tian@intel.com,
	vdumpa@nvidia.com, zhangfei.gao@linaro.org,
	shameerali.kolothum.thodi@huawei.com, vivek.gautam@arm.com
Subject: Re: [PATCH v12 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Date: Mon, 1 Feb 2021 12:12:35 +0100	[thread overview]
Message-ID: <YBfiIwdVP1dXg7Yt@myrica> (raw)
In-Reply-To: <0c609eeb-00b0-7573-fed7-5bc1e6c0b0d1@redhat.com>

On Sun, Jan 31, 2021 at 07:29:09PM +0100, Auger Eric wrote:
> Hi Jean,
> 
> Some rather minor comments§questions below that may not justify a respin.
> 
> On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote:
> > -static bool arm_smmu_iopf_supported(struct arm_smmu_master *master)
> > +bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master)
> >  {
> > -	return false;
> > +	/* We're not keeping track of SIDs in fault events */
> shall we? [*] below

That would require storing the incoming SID into the iommu_fault_event
struct, and retrieve it in arm_smmu_page_response(). Easy enough, but I
don't think it's needed for existing devices.

> > +	if (master->num_streams != 1)
> > +		return false;
[...]
> > +static int arm_smmu_page_response(struct device *dev,
> > +				  struct iommu_fault_event *unused,
> > +				  struct iommu_page_response *resp)
> > +{
> > +	struct arm_smmu_cmdq_ent cmd = {0};
> > +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > +	int sid = master->streams[0].id;
> [*]
> > +
> > +	if (master->stall_enabled) {
> > +		cmd.opcode		= CMDQ_OP_RESUME;
> > +		cmd.resume.sid		= sid;
> > +		cmd.resume.stag		= resp->grpid;
> > +		switch (resp->code) {
> > +		case IOMMU_PAGE_RESP_INVALID:
> add fallthrough?

I think fallthrough is mainly useful to tell reader and compiler that a
break was omitted on purpose. When two cases are stuck together the intent
to merge the flow is clear enough in my opinion. GCC's
-Wimplicit-fallthrough doesn't warn in this case.

> > +		case IOMMU_PAGE_RESP_FAILURE:
> > +			cmd.resume.resp = CMDQ_RESUME_0_RESP_ABORT;
> > +			break;
[...]
> > +static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
> > +{
> > +	int ret;
> > +	u32 reason;
> > +	u32 perm = 0;
> > +	struct arm_smmu_master *master;
> > +	bool ssid_valid = evt[0] & EVTQ_0_SSV;
> > +	u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]);
> > +	struct iommu_fault_event fault_evt = { };
> > +	struct iommu_fault *flt = &fault_evt.fault;
> > +
> > +	/* Stage-2 is always pinned at the moment */
> > +	if (evt[1] & EVTQ_1_S2)
> > +		return -EFAULT;
> > +
> > +	master = arm_smmu_find_master(smmu, sid);
> > +	if (!master)
> > +		return -EINVAL;
> > +
> > +	if (evt[1] & EVTQ_1_RnW)
> > +		perm |= IOMMU_FAULT_PERM_READ;
> > +	else
> > +		perm |= IOMMU_FAULT_PERM_WRITE;
> > +
> > +	if (evt[1] & EVTQ_1_InD)
> > +		perm |= IOMMU_FAULT_PERM_EXEC;
> > +
> > +	if (evt[1] & EVTQ_1_PnU)
> > +		perm |= IOMMU_FAULT_PERM_PRIV;
> > +
> > +	switch (FIELD_GET(EVTQ_0_ID, evt[0])) {
> > +	case EVT_ID_TRANSLATION_FAULT:
> > +	case EVT_ID_ADDR_SIZE_FAULT:
> > +	case EVT_ID_ACCESS_FAULT:
> > +		reason = IOMMU_FAULT_REASON_PTE_FETCH;
> Doesn't it rather map to IOMMU_FAULT_REASON_ACCESS?
> /* access flag check failed */"

Good point, I guess it didn't exist when I wrote this. And ADDR_SIZE_FAULT
corresponds to IOMMU_FAULT_REASON_OOR_ADDRESS now, right?

By the way the wording on those two fault reasons, "access flag" and
"stage", seems arch-specific - x86 names are "accessed flag" and "level".

> > +		break;
> > +	case EVT_ID_PERMISSION_FAULT:
> > +		reason = IOMMU_FAULT_REASON_PERMISSION;
> > +		break;
> > +	default:
> > +		return -EOPNOTSUPP;
> > +	}
> > +
> > +	if (evt[1] & EVTQ_1_STALL) {
> > +		flt->type = IOMMU_FAULT_PAGE_REQ;
> > +		flt->prm = (struct iommu_fault_page_request) {
> > +			.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
> > +			.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
> > +			.perm = perm,
> > +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
> > +		};
> > +
> > +		if (ssid_valid) {
> > +			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
> > +			flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
> > +		}
> > +	} else {
> > +		flt->type = IOMMU_FAULT_DMA_UNRECOV;
> > +		flt->event = (struct iommu_fault_unrecoverable) {
> > +			.reason = reason,
> > +			.flags = IOMMU_FAULT_UNRECOV_ADDR_VALID |
> > +				 IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID,
> nit: shall IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID be set here? Supported
> unrecoverable faults feature the IPA field which is UNKNOWN for S1
> translations. fetch_addr rather was
> corresponding to WALK_EABT.Fetch_addr to me.

Right I should drop the IPA part entirely, since we don't report S2 faults
in this patch.

Thanks,
Jean

> > +			.perm = perm,
> > +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
> > +			.fetch_addr = FIELD_GET(EVTQ_3_IPA, evt[3]),
> > +		};


WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: vivek.gautam@arm.com, guohanjun@huawei.com, will@kernel.org,
	linux-acpi@vger.kernel.org, zhangfei.gao@linaro.org,
	lenb@kernel.org, devicetree@vger.kernel.org,
	kevin.tian@intel.com, robh+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
	iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
	robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org
Subject: Re: [PATCH v12 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Date: Mon, 1 Feb 2021 12:12:35 +0100	[thread overview]
Message-ID: <YBfiIwdVP1dXg7Yt@myrica> (raw)
In-Reply-To: <0c609eeb-00b0-7573-fed7-5bc1e6c0b0d1@redhat.com>

On Sun, Jan 31, 2021 at 07:29:09PM +0100, Auger Eric wrote:
> Hi Jean,
> 
> Some rather minor comments§questions below that may not justify a respin.
> 
> On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote:
> > -static bool arm_smmu_iopf_supported(struct arm_smmu_master *master)
> > +bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master)
> >  {
> > -	return false;
> > +	/* We're not keeping track of SIDs in fault events */
> shall we? [*] below

That would require storing the incoming SID into the iommu_fault_event
struct, and retrieve it in arm_smmu_page_response(). Easy enough, but I
don't think it's needed for existing devices.

> > +	if (master->num_streams != 1)
> > +		return false;
[...]
> > +static int arm_smmu_page_response(struct device *dev,
> > +				  struct iommu_fault_event *unused,
> > +				  struct iommu_page_response *resp)
> > +{
> > +	struct arm_smmu_cmdq_ent cmd = {0};
> > +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > +	int sid = master->streams[0].id;
> [*]
> > +
> > +	if (master->stall_enabled) {
> > +		cmd.opcode		= CMDQ_OP_RESUME;
> > +		cmd.resume.sid		= sid;
> > +		cmd.resume.stag		= resp->grpid;
> > +		switch (resp->code) {
> > +		case IOMMU_PAGE_RESP_INVALID:
> add fallthrough?

I think fallthrough is mainly useful to tell reader and compiler that a
break was omitted on purpose. When two cases are stuck together the intent
to merge the flow is clear enough in my opinion. GCC's
-Wimplicit-fallthrough doesn't warn in this case.

> > +		case IOMMU_PAGE_RESP_FAILURE:
> > +			cmd.resume.resp = CMDQ_RESUME_0_RESP_ABORT;
> > +			break;
[...]
> > +static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
> > +{
> > +	int ret;
> > +	u32 reason;
> > +	u32 perm = 0;
> > +	struct arm_smmu_master *master;
> > +	bool ssid_valid = evt[0] & EVTQ_0_SSV;
> > +	u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]);
> > +	struct iommu_fault_event fault_evt = { };
> > +	struct iommu_fault *flt = &fault_evt.fault;
> > +
> > +	/* Stage-2 is always pinned at the moment */
> > +	if (evt[1] & EVTQ_1_S2)
> > +		return -EFAULT;
> > +
> > +	master = arm_smmu_find_master(smmu, sid);
> > +	if (!master)
> > +		return -EINVAL;
> > +
> > +	if (evt[1] & EVTQ_1_RnW)
> > +		perm |= IOMMU_FAULT_PERM_READ;
> > +	else
> > +		perm |= IOMMU_FAULT_PERM_WRITE;
> > +
> > +	if (evt[1] & EVTQ_1_InD)
> > +		perm |= IOMMU_FAULT_PERM_EXEC;
> > +
> > +	if (evt[1] & EVTQ_1_PnU)
> > +		perm |= IOMMU_FAULT_PERM_PRIV;
> > +
> > +	switch (FIELD_GET(EVTQ_0_ID, evt[0])) {
> > +	case EVT_ID_TRANSLATION_FAULT:
> > +	case EVT_ID_ADDR_SIZE_FAULT:
> > +	case EVT_ID_ACCESS_FAULT:
> > +		reason = IOMMU_FAULT_REASON_PTE_FETCH;
> Doesn't it rather map to IOMMU_FAULT_REASON_ACCESS?
> /* access flag check failed */"

Good point, I guess it didn't exist when I wrote this. And ADDR_SIZE_FAULT
corresponds to IOMMU_FAULT_REASON_OOR_ADDRESS now, right?

By the way the wording on those two fault reasons, "access flag" and
"stage", seems arch-specific - x86 names are "accessed flag" and "level".

> > +		break;
> > +	case EVT_ID_PERMISSION_FAULT:
> > +		reason = IOMMU_FAULT_REASON_PERMISSION;
> > +		break;
> > +	default:
> > +		return -EOPNOTSUPP;
> > +	}
> > +
> > +	if (evt[1] & EVTQ_1_STALL) {
> > +		flt->type = IOMMU_FAULT_PAGE_REQ;
> > +		flt->prm = (struct iommu_fault_page_request) {
> > +			.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
> > +			.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
> > +			.perm = perm,
> > +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
> > +		};
> > +
> > +		if (ssid_valid) {
> > +			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
> > +			flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
> > +		}
> > +	} else {
> > +		flt->type = IOMMU_FAULT_DMA_UNRECOV;
> > +		flt->event = (struct iommu_fault_unrecoverable) {
> > +			.reason = reason,
> > +			.flags = IOMMU_FAULT_UNRECOV_ADDR_VALID |
> > +				 IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID,
> nit: shall IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID be set here? Supported
> unrecoverable faults feature the IPA field which is UNKNOWN for S1
> translations. fetch_addr rather was
> corresponding to WALK_EABT.Fetch_addr to me.

Right I should drop the IPA part entirely, since we don't report S2 faults
in this patch.

Thanks,
Jean

> > +			.perm = perm,
> > +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
> > +			.fetch_addr = FIELD_GET(EVTQ_3_IPA, evt[3]),
> > +		};

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: vivek.gautam@arm.com, guohanjun@huawei.com, will@kernel.org,
	lorenzo.pieralisi@arm.com, joro@8bytes.org,
	linux-acpi@vger.kernel.org, zhangfei.gao@linaro.org,
	lenb@kernel.org, devicetree@vger.kernel.org,
	kevin.tian@intel.com, jacob.jun.pan@linux.intel.com,
	robh+dt@kernel.org, Jonathan.Cameron@huawei.com,
	linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
	shameerali.kolothum.thodi@huawei.com,
	iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
	robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org,
	baolu.lu@linux.intel.com
Subject: Re: [PATCH v12 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Date: Mon, 1 Feb 2021 12:12:35 +0100	[thread overview]
Message-ID: <YBfiIwdVP1dXg7Yt@myrica> (raw)
In-Reply-To: <0c609eeb-00b0-7573-fed7-5bc1e6c0b0d1@redhat.com>

On Sun, Jan 31, 2021 at 07:29:09PM +0100, Auger Eric wrote:
> Hi Jean,
> 
> Some rather minor comments§questions below that may not justify a respin.
> 
> On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote:
> > -static bool arm_smmu_iopf_supported(struct arm_smmu_master *master)
> > +bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master)
> >  {
> > -	return false;
> > +	/* We're not keeping track of SIDs in fault events */
> shall we? [*] below

That would require storing the incoming SID into the iommu_fault_event
struct, and retrieve it in arm_smmu_page_response(). Easy enough, but I
don't think it's needed for existing devices.

> > +	if (master->num_streams != 1)
> > +		return false;
[...]
> > +static int arm_smmu_page_response(struct device *dev,
> > +				  struct iommu_fault_event *unused,
> > +				  struct iommu_page_response *resp)
> > +{
> > +	struct arm_smmu_cmdq_ent cmd = {0};
> > +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> > +	int sid = master->streams[0].id;
> [*]
> > +
> > +	if (master->stall_enabled) {
> > +		cmd.opcode		= CMDQ_OP_RESUME;
> > +		cmd.resume.sid		= sid;
> > +		cmd.resume.stag		= resp->grpid;
> > +		switch (resp->code) {
> > +		case IOMMU_PAGE_RESP_INVALID:
> add fallthrough?

I think fallthrough is mainly useful to tell reader and compiler that a
break was omitted on purpose. When two cases are stuck together the intent
to merge the flow is clear enough in my opinion. GCC's
-Wimplicit-fallthrough doesn't warn in this case.

> > +		case IOMMU_PAGE_RESP_FAILURE:
> > +			cmd.resume.resp = CMDQ_RESUME_0_RESP_ABORT;
> > +			break;
[...]
> > +static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
> > +{
> > +	int ret;
> > +	u32 reason;
> > +	u32 perm = 0;
> > +	struct arm_smmu_master *master;
> > +	bool ssid_valid = evt[0] & EVTQ_0_SSV;
> > +	u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]);
> > +	struct iommu_fault_event fault_evt = { };
> > +	struct iommu_fault *flt = &fault_evt.fault;
> > +
> > +	/* Stage-2 is always pinned at the moment */
> > +	if (evt[1] & EVTQ_1_S2)
> > +		return -EFAULT;
> > +
> > +	master = arm_smmu_find_master(smmu, sid);
> > +	if (!master)
> > +		return -EINVAL;
> > +
> > +	if (evt[1] & EVTQ_1_RnW)
> > +		perm |= IOMMU_FAULT_PERM_READ;
> > +	else
> > +		perm |= IOMMU_FAULT_PERM_WRITE;
> > +
> > +	if (evt[1] & EVTQ_1_InD)
> > +		perm |= IOMMU_FAULT_PERM_EXEC;
> > +
> > +	if (evt[1] & EVTQ_1_PnU)
> > +		perm |= IOMMU_FAULT_PERM_PRIV;
> > +
> > +	switch (FIELD_GET(EVTQ_0_ID, evt[0])) {
> > +	case EVT_ID_TRANSLATION_FAULT:
> > +	case EVT_ID_ADDR_SIZE_FAULT:
> > +	case EVT_ID_ACCESS_FAULT:
> > +		reason = IOMMU_FAULT_REASON_PTE_FETCH;
> Doesn't it rather map to IOMMU_FAULT_REASON_ACCESS?
> /* access flag check failed */"

Good point, I guess it didn't exist when I wrote this. And ADDR_SIZE_FAULT
corresponds to IOMMU_FAULT_REASON_OOR_ADDRESS now, right?

By the way the wording on those two fault reasons, "access flag" and
"stage", seems arch-specific - x86 names are "accessed flag" and "level".

> > +		break;
> > +	case EVT_ID_PERMISSION_FAULT:
> > +		reason = IOMMU_FAULT_REASON_PERMISSION;
> > +		break;
> > +	default:
> > +		return -EOPNOTSUPP;
> > +	}
> > +
> > +	if (evt[1] & EVTQ_1_STALL) {
> > +		flt->type = IOMMU_FAULT_PAGE_REQ;
> > +		flt->prm = (struct iommu_fault_page_request) {
> > +			.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
> > +			.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
> > +			.perm = perm,
> > +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
> > +		};
> > +
> > +		if (ssid_valid) {
> > +			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
> > +			flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
> > +		}
> > +	} else {
> > +		flt->type = IOMMU_FAULT_DMA_UNRECOV;
> > +		flt->event = (struct iommu_fault_unrecoverable) {
> > +			.reason = reason,
> > +			.flags = IOMMU_FAULT_UNRECOV_ADDR_VALID |
> > +				 IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID,
> nit: shall IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID be set here? Supported
> unrecoverable faults feature the IPA field which is UNKNOWN for S1
> translations. fetch_addr rather was
> corresponding to WALK_EABT.Fetch_addr to me.

Right I should drop the IPA part entirely, since we don't report S2 faults
in this patch.

Thanks,
Jean

> > +			.perm = perm,
> > +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
> > +			.fetch_addr = FIELD_GET(EVTQ_3_IPA, evt[3]),
> > +		};


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-02-01 11:13 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 15:43 [PATCH v12 00/10] iommu: I/O page faults for SMMUv3 Jean-Philippe Brucker
2021-01-27 15:43 ` Jean-Philippe Brucker
2021-01-27 15:43 ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 01/10] iommu: Fix comment for struct iommu_fwspec Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-02-01  7:30   ` Auger Eric
2021-02-01  7:30     ` Auger Eric
2021-02-01  7:30     ` Auger Eric
2021-01-27 15:43 ` [PATCH v12 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-02-01  7:35   ` Auger Eric
2021-02-01  7:35     ` Auger Eric
2021-02-01  7:35     ` Auger Eric
2021-01-27 15:43 ` [PATCH v12 04/10] iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 06/10] iommu: Add a page fault handler Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-31 18:29   ` Auger Eric
2021-01-31 18:29     ` Auger Eric
2021-01-31 18:29     ` Auger Eric
2021-02-02  5:51   ` Shenming Lu
2021-02-02  5:51     ` Shenming Lu
2021-02-02  5:51     ` Shenming Lu
2021-01-27 15:43 ` [PATCH v12 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 08/10] dt-bindings: document stall property for IOMMU masters Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-02-01  7:28   ` Auger Eric
2021-02-01  7:28     ` Auger Eric
2021-02-01  7:28     ` Auger Eric
2021-01-27 15:43 ` [PATCH v12 09/10] ACPI/IORT: Enable stall support for platform devices Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43 ` [PATCH v12 10/10] iommu/arm-smmu-v3: Add " Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-27 15:43   ` Jean-Philippe Brucker
2021-01-31 18:29   ` Auger Eric
2021-01-31 18:29     ` Auger Eric
2021-01-31 18:29     ` Auger Eric
2021-02-01 11:12     ` Jean-Philippe Brucker [this message]
2021-02-01 11:12       ` Jean-Philippe Brucker
2021-02-01 11:12       ` Jean-Philippe Brucker
2021-02-01 13:16       ` Auger Eric
2021-02-01 13:16         ` Auger Eric
2021-02-01 13:16         ` Auger Eric
2021-02-01 15:19         ` Jean-Philippe Brucker
2021-02-01 15:19           ` Jean-Philippe Brucker
2021-02-01 15:19           ` Jean-Philippe Brucker
2021-02-01  1:18   ` Zhou Wang
2021-02-01  1:18     ` Zhou Wang
2021-02-01  1:18     ` Zhou Wang
2021-02-01 11:14     ` Jean-Philippe Brucker
2021-02-01 11:14       ` Jean-Philippe Brucker
2021-02-01 11:14       ` Jean-Philippe Brucker
2021-02-01 12:53       ` Zhou Wang
2021-02-01 12:53         ` Zhou Wang
2021-02-01 12:53         ` Zhou Wang
2021-02-26  9:43       ` Zhou Wang
2021-02-26  9:43         ` Zhou Wang
2021-02-26  9:43         ` Zhou Wang
2021-02-26 16:29         ` Jean-Philippe Brucker
2021-02-26 16:29           ` Jean-Philippe Brucker
2021-02-26 16:29           ` Jean-Philippe Brucker
2021-02-27  3:40           ` Zhou Wang
2021-02-27  3:40             ` Zhou Wang
2021-02-27  3:40             ` Zhou Wang

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=YBfiIwdVP1dXg7Yt@myrica \
    --to=jean-philippe@linaro.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=eric.auger@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-accelerators@lists.ozlabs.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=sudeep.holla@arm.com \
    --cc=vdumpa@nvidia.com \
    --cc=vivek.gautam@arm.com \
    --cc=will@kernel.org \
    --cc=zhangfei.gao@linaro.org \
    /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.