| Message ID | 20151207204322.8144.60452.stgit@phlsvslse11.ph.intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
PiArc3RhdGljIGludCBydnRfcXVlcnlfZGV2aWNlKHN0cnVjdCBpYl9kZXZpY2UgKmliZGV2LA0K PiArCQkJICAgIHN0cnVjdCBpYl9kZXZpY2VfYXR0ciAqcHJvcHMsDQo+ICsJCQkgICAgc3RydWN0 IGliX3VkYXRhICp1aHcpDQo+ICt7DQo+ICsJLyoNCj4gKwkgKiBSZXR1cm4gcnZ0X2Rldl9pbmZv LnByb3BzIGNvbnRlbnRzDQo+ICsJICovDQo+ICsJcmV0dXJuIC1FSU5WQUw7DQoNCkVOT1NZUyBv biBhbGwgb2YgdGhlIGZ1bmN0aW9uIHRlbXBsYXRlcy4gIFRoaXMgYW5kIHN1YnNlcXVlbnQgcGF0 Y2hlcy4NCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 07, 2015 at 09:26:11PM +0000, Hefty, Sean wrote: > > +static int rvt_query_device(struct ib_device *ibdev, > > + struct ib_device_attr *props, > > + struct ib_udata *uhw) > > +{ > > + /* > > + * Return rvt_dev_info.props contents > > + */ > > + return -EINVAL; > > ENOSYS on all of the function templates. This and subsequent patches. We recently had a long discussion about what the correct answer here is. ENOSYS and EINVAL are both wrong for different reasons.. Can't recall if something else was settled on? I think I was suggesting one of the ENOTSUP varients? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 07, 2015 at 02:39:04PM -0700, Jason Gunthorpe wrote: > On Mon, Dec 07, 2015 at 09:26:11PM +0000, Hefty, Sean wrote: > > > +static int rvt_query_device(struct ib_device *ibdev, > > > + struct ib_device_attr *props, > > > + struct ib_udata *uhw) > > > +{ > > > + /* > > > + * Return rvt_dev_info.props contents > > > + */ > > > + return -EINVAL; > > > > ENOSYS on all of the function templates. This and subsequent patches. > > We recently had a long discussion about what the correct answer here > is. > > ENOSYS and EINVAL are both wrong for different reasons.. Can't recall > if something else was settled on? I think I was suggesting one of the > ENOTSUP varients? You suggested EOPNOTSUPP [1] [1] http://www.spinics.net/lists/linux-rdma/msg30176.html > > Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/infiniband/sw/rdmavt/vt.c b/drivers/infiniband/sw/rdmavt/vt.c index aaf10e7..b807ee8 100644 --- a/drivers/infiniband/sw/rdmavt/vt.c +++ b/drivers/infiniband/sw/rdmavt/vt.c @@ -70,6 +70,33 @@ static void rvt_cleanup(void) } module_exit(rvt_cleanup); +static int rvt_query_device(struct ib_device *ibdev, + struct ib_device_attr *props, + struct ib_udata *uhw) +{ + /* + * Return rvt_dev_info.props contents + */ + return -EINVAL; +} + +static int rvt_modify_device(struct ib_device *device, + int device_modify_mask, + struct ib_device_modify *device_modify) +{ + /* + * Change dev props. Planned support is for node desc change and sys + * guid change only. This matches hfi1 and qib behavior. Other drivers + * that support existing modifications will need to add their support. + */ + + /* + * VT-DRIVER-API: node_desc_change() + * VT-DRIVER-API: sys_guid_change() + */ + return -EINVAL; +} + /* * Check driver override. If driver passes a value use it, otherwise we use our * own value. @@ -82,6 +109,10 @@ int rvt_register_device(struct rvt_dev_info *rdi) if (!rdi) return -EINVAL; + /* Dev Ops */ + CDR(rdi, query_device); + CDR(rdi, modify_device); + /* DMA Operations */ rdi->ibdev.dma_ops = rdi->ibdev.dma_ops ? : &rvt_default_dma_mapping_ops;