[PATCH] mlx4_en: use net_device dev_id to indicate port number
Today, there are no means to know which port of a hardware device a netdev interface uses. struct net_device conatins a field, dev_id, that can be used for that. Use this field to save the port number in ConnectX that is being used by the net device; port numbers are zero based. Signed-off-by: Eli Cohen --- drivers/net/mlx4/en_netdev.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/mlx4/en_netdev.c b/drivers/net/mlx4/en_netdev.c index 6c2b15b..ab1d480 100644 --- a/drivers/net/mlx4/en_netdev.c +++ b/drivers/net/mlx4/en_netdev.c @@ -978,6 +978,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port, } SET_NETDEV_DEV(dev, &mdev->dev->pdev->dev); + dev->dev_id = port - 1; /* * Initialize driver private data -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IB/qib: use a single txselect module parameter for serdes tuning
sorry about that... somehow I messed this up. Anyway, I applied this patch. -- Roland Dreier || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IB/qib: use a single txselect module parameter for serdes tuning
As part of the earlier patches submitted and reviewed, it was agreed
to change the way serdes tuning parameters were specified to the
driver. The updated patch got dropped by the linux-rdma email list
so the earlier version of qib_iba7322.c was integrated.
This patch updates qib_iab7322.c with the simpler, single parameter
method of setting the serdes parameters.
Signed-off-by: Ralph Campbell
---
drivers/infiniband/hw/qib/qib_iba7322.c | 582 ++-
1 files changed, 179 insertions(+), 403 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_iba7322.c
b/drivers/infiniband/hw/qib/qib_iba7322.c
index 2c24eab..23fb9ef 100644
--- a/drivers/infiniband/hw/qib/qib_iba7322.c
+++ b/drivers/infiniband/hw/qib/qib_iba7322.c
@@ -114,40 +114,18 @@ static ushort qib_singleport;
module_param_named(singleport, qib_singleport, ushort, S_IRUGO);
MODULE_PARM_DESC(singleport, "Use only IB port 1; more per-port buffer space");
-
-/*
- * Setup QMH7342 receive and transmit parameters, necessary because
- * each bay, Mez connector, and IB port need different tuning, beyond
- * what the switch and HCA can do automatically.
- * It's expected to be done by cat'ing files to the modules file,
- * rather than setting up as a module parameter.
- * It's a "write-only" file, returns 0 when read back.
- * The unit, port, bay (if given), and values MUST be done as a single write.
- * The unit, port, and bay must precede the values to be effective.
- */
-static int setup_qmh_params(const char *, struct kernel_param *);
-static unsigned dummy_qmh_params;
-module_param_call(qmh_serdes_setup, setup_qmh_params, param_get_uint,
- &dummy_qmh_params, S_IWUSR | S_IRUGO);
-
-/* similarly for QME7342, but it's simpler */
-static int setup_qme_params(const char *, struct kernel_param *);
-static unsigned dummy_qme_params;
-module_param_call(qme_serdes_setup, setup_qme_params, param_get_uint,
- &dummy_qme_params, S_IWUSR | S_IRUGO);
-
#define MAX_ATTEN_LEN 64 /* plenty for any real system */
/* for read back, default index is ~5m copper cable */
-static char cable_atten_list[MAX_ATTEN_LEN] = "10";
-static struct kparam_string kp_cable_atten = {
- .string = cable_atten_list,
+static char txselect_list[MAX_ATTEN_LEN] = "10";
+static struct kparam_string kp_txselect = {
+ .string = txselect_list,
.maxlen = MAX_ATTEN_LEN
};
-static int setup_cable_atten(const char *, struct kernel_param *);
-module_param_call(cable_atten, setup_cable_atten, param_get_string,
- &kp_cable_atten, S_IWUSR | S_IRUGO);
-MODULE_PARM_DESC(cable_atten, \
-"cable attenuation indices for cables with invalid EEPROM");
+static int setup_txselect(const char *, struct kernel_param *);
+module_param_call(txselect, setup_txselect, param_get_string,
+ &kp_txselect, S_IWUSR | S_IRUGO);
+MODULE_PARM_DESC(txselect, \
+"Tx serdes indices (for no QSFP or invalid QSFP data)");
#define BOARD_QME7342 5
#define BOARD_QMH7342 6
@@ -574,11 +552,12 @@ struct vendor_txdds_ent {
static void write_tx_serdes_param(struct qib_pportdata *, struct txdds_ent *);
#define TXDDS_TABLE_SZ 16 /* number of entries per speed in onchip table */
+#define TXDDS_EXTRA_SZ 11 /* number of extra tx settings entries */
#define SERDES_CHANS 4 /* yes, it's obvious, but one less magic number */
#define H1_FORCE_VAL 8
-#define H1_FORCE_QME 1 /* may be overridden via setup_qme_params() */
-#define H1_FORCE_QMH 7 /* may be overridden via setup_qmh_params() */
+#define H1_FORCE_QME 1 /* may be overridden via setup_txselect() */
+#define H1_FORCE_QMH 7 /* may be overridden via setup_txselect() */
/* The static and dynamic registers are paired, and the pairs indexed by spd */
#define krp_static_adapt_dis(spd) (KREG_IBPORT_IDX(ADAPT_DISABLE_STATIC_SDR) \
@@ -590,15 +569,6 @@ static void write_tx_serdes_param(struct qib_pportdata *,
struct txdds_ent *);
#define QDR_STATIC_ADAPT_INIT 0xffULL /* up, disable H0,H1-8, LE */
#define QDR_STATIC_ADAPT_INIT_R1 0xf0ULL /* r1 up, disable H0,H1-8 */
-static const struct txdds_ent qmh_sdr_txdds = { 11, 0, 5, 6 };
-static const struct txdds_ent qmh_ddr_txdds = { 7, 0, 2, 8 };
-static const struct txdds_ent qmh_qdr_txdds = { 0, 1, 3, 10 };
-
-/* this is used for unknown mez cards also */
-static const struct txdds_ent qme_sdr_txdds = { 11, 0, 4, 4 };
-static const struct txdds_ent qme_ddr_txdds = { 7, 0, 2, 7 };
-static const struct txdds_ent qme_qdr_txdds = { 0, 1, 12, 11 };
-
struct qib_chippport_specific {
u64 __iomem *kpregbase;
u64 __iomem *cpregbase;
@@ -637,12 +607,8 @@ struct qib_chippport_specific {
* Per-bay per-channel rcv QMH H1 values and Tx values for QDR.
* entry zero is unused, to simplify indexing
*/
- u16 h1_val;
- u8 amp[SERDES_CHANS];
- u8 pre[SERDES_CHANS];
- u8 mainv[SERDES_CHANS];
- u8 post[
RE: [ANNOUNCE] librdmacm 1.0.12
> I'm not an expert of code, but I read this thread and I understand that > new librdmacm version will be easier for users. New APIs were added to the librdmacm that make it easier for a developer to establish a connection over an RDMA device. Additionally, wrappers were added around several of the verbs calls to make it easier to post work requests. Man pages were added for the newer connection related interfaces, and two additional sample applications were added to demonstrate their use. See: rdma_create_ep, rdma_getaddrinfo, rdma_destroy_ep calls, and rdma_server, rdma_client apps The wrapper calls are in rdma/rdma_verbs.h Most of the concepts were based on feedback from MPI developers and students who needed easier interfaces to use and understand, with some specific ideas pulled in from an libiwarp helper library developed by Philip Frey. For the most part, you can mix new interfaces calls with lower level verbs calls as needed by your application. I'm still 1-2 weeks away from writing up the release notes. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IB/qib: fix powerpc compile warnings
> Fix the compile warnings for uninitialized variables in qib_fs.c
> when compiling for powerpc.
> -u64 *counters;
> +u64 *counters = NULL;
I do not believe this is the correct fix. The problem is the code like:
return simple_read_from_buffer(buf, count, ppos, counters,
dd->f_read_cntrs(dd, *ppos, NULL, &counters));
which passes the pointer counters as a parameter to simple_read_from_buffer()
but relies on the call to dd->f_read_cntrs() to initialize the parameter.
However the order of evaluation of function parameters is undefined in C.
So just initializing counters to NULL as you do means that you might be
passing in NULL instead of an uninitialized value -- not much improvement.
The reason this code works for you I think is that gcc on x86 evaluates
function parameters from right to left, and apparently powerpc does the
opposite (hence the warning). You can see that by compiling the code
below -- with gcc -O2 -Wall, I see:
a.c: In function ‘b’:
a.c:14: warning: ‘ap’ is used uninitialized in this function
so the warning comes from the particular order:
extern int x(int **xp);
extern int y(int *yp, int ypp);
extern int z(int zpp, int *zp);
int a(void)
{
int *ap;
return y(ap, x(&ap));
}
int b(void)
{
int *ap;
return z(x(&ap), ap);
}
So I think the correct fix (which I queued up) is the following:
commit f27ec1d6db4aa3348ca7be896f1466599aecea3e
Author: Roland Dreier
Date: Wed May 26 13:15:06 2010 -0700
IB/qib: Don't rely on (undefined) order of function parameter evaluation
Some of the qib sysfs code passes a buffer pointer into
simple_read_from_buffer() but relies on a function call in another
parameter of the same call to initialize that pointer. Since the order
of evaluation of function parameters is undefined, this will break if
gcc chooses the wrong order.
Fix this by splitting the code into two separate function calls.
This was noticed because of warnings like the following on ppc:
drivers/infiniband/hw/qib/qib_fs.c: In function 'portcntrs_2_read':
drivers/infiniband/hw/qib/qib_fs.c:203: warning: 'counters' is used
uninitialized in this function
Reported-by: Stephen Rothwell
Signed-off-by: Roland Dreier
diff --git a/drivers/infiniband/hw/qib/qib_fs.c
b/drivers/infiniband/hw/qib/qib_fs.c
index 7554704..edef852 100644
--- a/drivers/infiniband/hw/qib/qib_fs.c
+++ b/drivers/infiniband/hw/qib/qib_fs.c
@@ -144,10 +144,11 @@ static ssize_t dev_counters_read(struct file *file, char
__user *buf,
size_t count, loff_t *ppos)
{
u64 *counters;
+ size_t avail;
struct qib_devdata *dd = private2dd(file);
- return simple_read_from_buffer(buf, count, ppos, counters,
- dd->f_read_cntrs(dd, *ppos, NULL, &counters));
+ avail = dd->f_read_cntrs(dd, *ppos, NULL, &counters);
+ return simple_read_from_buffer(buf, count, ppos, counters, avail);
}
/* read the per-device counters */
@@ -155,10 +156,11 @@ static ssize_t dev_names_read(struct file *file, char
__user *buf,
size_t count, loff_t *ppos)
{
char *names;
+ size_t avail;
struct qib_devdata *dd = private2dd(file);
- return simple_read_from_buffer(buf, count, ppos, names,
- dd->f_read_cntrs(dd, *ppos, &names, NULL));
+ avail = dd->f_read_cntrs(dd, *ppos, &names, NULL);
+ return simple_read_from_buffer(buf, count, ppos, names, avail);
}
static const struct file_operations cntr_ops[] = {
@@ -176,10 +178,11 @@ static ssize_t portnames_read(struct file *file, char
__user *buf,
size_t count, loff_t *ppos)
{
char *names;
+ size_t avail;
struct qib_devdata *dd = private2dd(file);
- return simple_read_from_buffer(buf, count, ppos, names,
- dd->f_read_portcntrs(dd, *ppos, 0, &names, NULL));
+ avail = dd->f_read_portcntrs(dd, *ppos, 0, &names, NULL);
+ return simple_read_from_buffer(buf, count, ppos, names, avail);
}
/* read the per-port counters for port 1 (pidx 0) */
@@ -187,10 +190,11 @@ static ssize_t portcntrs_1_read(struct file *file, char
__user *buf,
size_t count, loff_t *ppos)
{
u64 *counters;
+ size_t avail;
struct qib_devdata *dd = private2dd(file);
- return simple_read_from_buffer(buf, count, ppos, counters,
- dd->f_read_portcntrs(dd, *ppos, 0, NULL, &counters));
+ avail = dd->f_read_portcntrs(dd, *ppos, 0, NULL, &counters);
+ return simple_read_from_buffer(buf, count, ppos, counters, avail);
}
/* read the per-port counters for port 2 (pidx 1) */
@@ -198,10 +202,11 @@ static ssize_t portcntrs_2_read(struct file
[PATCH] IB/core User RMPP patch
Currently, if a user application calls umad_register() or umad_register_oui()
with an rmpp_version of zero, incoming rmpp messages are discarded.
This patch changes this behavior so that rmpp_version of zero causes incoming
rmpp packets to be passed through without alteration, instead.
Signed-off-by: Michael Heinz
diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index 80282f1..b3457ae 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -1830,25 +1830,39 @@ static void ib_mad_complete_recv(struct
ib_mad_agent_private *mad_agent_priv,
if (ib_response_mad(mad_recv_wc->recv_buf.mad)) {
spin_lock_irqsave(&mad_agent_priv->lock, flags);
mad_send_wr = ib_find_send_mad(mad_agent_priv, mad_recv_wc);
- if (!mad_send_wr) {
+ if (mad_send_wr) {
+ ib_mark_mad_done(mad_send_wr);
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
- ib_free_recv_mad(mad_recv_wc);
- deref_mad_agent(mad_agent_priv);
- return;
- }
- ib_mark_mad_done(mad_send_wr);
- spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
- /* Defined behavior is to complete response before request */
- mad_recv_wc->wc->wr_id = (unsigned long) &mad_send_wr->send_buf;
- mad_agent_priv->agent.recv_handler(&mad_agent_priv->agent,
- mad_recv_wc);
- atomic_dec(&mad_agent_priv->refcount);
+ /* Defined behavior is to complete response before
request */
+ mad_recv_wc->wc->wr_id = (unsigned long)
&mad_send_wr->send_buf;
+
mad_agent_priv->agent.recv_handler(&mad_agent_priv->agent,
+ mad_recv_wc);
+ atomic_dec(&mad_agent_priv->refcount);
- mad_send_wc.status = IB_WC_SUCCESS;
- mad_send_wc.vendor_err = 0;
- mad_send_wc.send_buf = &mad_send_wr->send_buf;
- ib_mad_complete_send_wr(mad_send_wr, &mad_send_wc);
+ mad_send_wc.status = IB_WC_SUCCESS;
+ mad_send_wc.vendor_err = 0;
+ mad_send_wc.send_buf = &mad_send_wr->send_buf;
+ ib_mad_complete_send_wr(mad_send_wr, &mad_send_wc);
+ } else {
+ if ( !mad_agent_priv->agent.rmpp_version
+ &&
ib_is_mad_class_rmpp(mad_recv_wc->recv_buf.mad->mad_hdr.mgmt_class)
+ && (ib_get_rmpp_flags(&((struct ib_rmpp_mad
*)mad_recv_wc->recv_buf.mad)->rmpp_hdr) & IB_MGMT_RMPP_FLAG_ACTIVE)) {
+ // user rmpp is in effect
+ spin_unlock_irqrestore(&mad_agent_priv->lock,
flags);
+
+ mad_recv_wc->wc->wr_id = 0;
+
mad_agent_priv->agent.recv_handler(&mad_agent_priv->agent,
+ mad_recv_wc);
+ atomic_dec(&mad_agent_priv->refcount);
+ } else {
+ // not user rmpp, revert to normal behavior and
drop the mad
+ spin_unlock_irqrestore(&mad_agent_priv->lock,
flags);
+ ib_free_recv_mad(mad_recv_wc);
+ deref_mad_agent(mad_agent_priv);
+ return;
+ }
+ }
} else {
mad_agent_priv->agent.recv_handler(&mad_agent_priv->agent,
mad_recv_wc);
diff --git a/drivers/infiniband/core/user_mad.c
b/drivers/infiniband/core/user_mad.c
index 36f815c..f9cacbc 100644
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -508,7 +508,7 @@ static ssize_t ib_umad_write(struct file *filp, const char
__user *buf,
rmpp_mad = (struct ib_rmpp_mad *) packet->mad.data;
hdr_len = ib_get_mad_data_offset(rmpp_mad->mad_hdr.mgmt_class);
- if (!ib_is_mad_class_rmpp(rmpp_mad->mad_hdr.mgmt_class)) {
+ if (!agent->rmpp_version ||
!ib_is_mad_class_rmpp(rmpp_mad->mad_hdr.mgmt_class)) {
copy_offset = IB_MGMT_MAD_HDR;
rmpp_active = 0;
} else {
@@ -560,14 +560,22 @@ static ssize_t ib_umad_write(struct file *filp, const
char __user *buf,
rmpp_mad->mad_hdr.tid = *tid;
}
- spin_lock_irq(&file->send_lock);
- ret = is_duplicate(file, packet);
- if (!ret)
+ if ( !agent->rmpp_version
+ && ib_is_mad_class_rmpp(rmpp_mad->mad_hdr.mgmt_class)
+ && (ib_get_rmpp_flags(&rmpp_mad->rmpp_hdr) &
IB_MGMT_
[PATCH] IB/qib: fix powerpc compile warnings
Fix the compile warnings for uninitialized variables in qib_fs.c
when compiling for powerpc.
Signed-off-by: Ralph Campbell
---
drivers/infiniband/hw/qib/qib_fs.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_fs.c
b/drivers/infiniband/hw/qib/qib_fs.c
index 7554704..8a354f7 100644
--- a/drivers/infiniband/hw/qib/qib_fs.c
+++ b/drivers/infiniband/hw/qib/qib_fs.c
@@ -143,7 +143,7 @@ static const struct file_operations driver_ops[] = {
static ssize_t dev_counters_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
- u64 *counters;
+ u64 *counters = NULL;
struct qib_devdata *dd = private2dd(file);
return simple_read_from_buffer(buf, count, ppos, counters,
@@ -154,7 +154,7 @@ static ssize_t dev_counters_read(struct file *file, char
__user *buf,
static ssize_t dev_names_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
- char *names;
+ char *names = NULL;
struct qib_devdata *dd = private2dd(file);
return simple_read_from_buffer(buf, count, ppos, names,
@@ -175,7 +175,7 @@ static const struct file_operations cntr_ops[] = {
static ssize_t portnames_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
- char *names;
+ char *names = NULL;
struct qib_devdata *dd = private2dd(file);
return simple_read_from_buffer(buf, count, ppos, names,
@@ -186,7 +186,7 @@ static ssize_t portnames_read(struct file *file, char
__user *buf,
static ssize_t portcntrs_1_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
- u64 *counters;
+ u64 *counters = NULL;
struct qib_devdata *dd = private2dd(file);
return simple_read_from_buffer(buf, count, ppos, counters,
@@ -197,7 +197,7 @@ static ssize_t portcntrs_1_read(struct file *file, char
__user *buf,
static ssize_t portcntrs_2_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
- u64 *counters;
+ u64 *counters = NULL;
struct qib_devdata *dd = private2dd(file);
return simple_read_from_buffer(buf, count, ppos, counters,
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: use net_device dev_id to indicate port number
On Wed, May 26, 2010 at 08:33:18AM -0700, Stephen Hemminger wrote: > > SET_NETDEV_DEV macro exists because at the time 2.5 kernel was being developed > it was important to be able to maintain source compatibility between 2.4 and > 2.6 (nee 2.5) drivers. Since 2.4 did not have sysfs, the macro was a mechanism > to allow the same code to run on both kernel versions. > > Your situation is different, just use dev_id and update documentation if > you need to. > OK, great. Things get much much simpler :-) I'll send another patch for mlx4_en only. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: use net_device dev_id to indicate port number
On Wed, 26 May 2010 18:27:30 +0300 Eli Cohen wrote: > On Wed, May 26, 2010 at 08:23:06AM -0700, Stephen Hemminger wrote: > > On Wed, 26 May 2010 12:52:00 +0300 > > Eli Cohen wrote: > > > > > Today, there are no means to know which port of a hardware device a netdev > > > interface uses. struct net_device conatins a field, dev_id, that can be > > > used > > > for that. This patch adds a new macro, SET_NETDEV_DEV_ID(), to provide a > > > standard way to set the value of this field. > > > Also also make use of this feature in the mlx4_en driver to set the port > > > number; port numbers are zero based. > > > > Why is a macro wrapper needed? > > > > I guess for the same reason we use SET_NETDEV_DEV - to provide a > consistent interface for setting this value... SET_NETDEV_DEV macro exists because at the time 2.5 kernel was being developed it was important to be able to maintain source compatibility between 2.4 and 2.6 (nee 2.5) drivers. Since 2.4 did not have sysfs, the macro was a mechanism to allow the same code to run on both kernel versions. Your situation is different, just use dev_id and update documentation if you need to. -- -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: use net_device dev_id to indicate port number
On Wed, May 26, 2010 at 08:23:06AM -0700, Stephen Hemminger wrote: > On Wed, 26 May 2010 12:52:00 +0300 > Eli Cohen wrote: > > > Today, there are no means to know which port of a hardware device a netdev > > interface uses. struct net_device conatins a field, dev_id, that can be used > > for that. This patch adds a new macro, SET_NETDEV_DEV_ID(), to provide a > > standard way to set the value of this field. > > Also also make use of this feature in the mlx4_en driver to set the port > > number; port numbers are zero based. > > Why is a macro wrapper needed? > I guess for the same reason we use SET_NETDEV_DEV - to provide a consistent interface for setting this value... -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: use net_device dev_id to indicate port number
On Wed, 26 May 2010 12:52:00 +0300 Eli Cohen wrote: > Today, there are no means to know which port of a hardware device a netdev > interface uses. struct net_device conatins a field, dev_id, that can be used > for that. This patch adds a new macro, SET_NETDEV_DEV_ID(), to provide a > standard way to set the value of this field. > Also also make use of this feature in the mlx4_en driver to set the port > number; port numbers are zero based. Why is a macro wrapper needed? -- -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ofa_kernel/util madeye.c
On Wed, May 26, 2010 at 8:42 AM, Mike Heinz wrote:
> I'm resending this - I sent it yesterday, but it doesn't seem to have
> appeared in the list.
>
> --
>
> This is a simple fix. Several of the attribute filters in
> ./drivers/infiniband/util/madeye.c don't switch the attribute id to host byte
> order before checking it.
AFAIR there was discussion on this but the work to push madeye
upstream was never done so it is just an EWG patch right now. If there
are no objections (there weren't when the discussion last occurred),
it could also be pushed upstream.
-- Hal
>
> Signed-off-by: Michael Heinz
>
> diff --git a/drivers/infiniband/util/madeye.c
> b/drivers/infiniband/util/madeye.c
> index 0cda06c..2c650a3 100644
> --- a/drivers/infiniband/util/madeye.c
> +++ b/drivers/infiniband/util/madeye.c
> @@ -401,7 +401,7 @@ static void snoop_smi_handler(struct ib_mad_agent
> *mad_agent,
>
> if (!smp && hdr->mgmt_class != mgmt_class)
> return;
> - if (attr_id && hdr->attr_id != attr_id)
> + if (attr_id && be16_to_cpu(hdr->attr_id) != attr_id)
> return;
>
> printk("Madeye:sent SMP\n");
> @@ -413,7 +413,7 @@ static void recv_smi_handler(struct ib_mad_agent
> *mad_agent, {
> if (!smp && mad_recv_wc->recv_buf.mad->mad_hdr.mgmt_class !=
> mgmt_class)
> return;
> - if (attr_id && mad_recv_wc->recv_buf.mad->mad_hdr.attr_id != attr_id)
> + if (attr_id && be16_to_cpu(mad_recv_wc->recv_buf.mad->mad_hdr.attr_id)
> +!= attr_id)
> return;
>
> printk("Madeye:recv SMP\n");
> @@ -446,7 +446,7 @@ static void snoop_gsi_handler(struct ib_mad_agent
> *mad_agent,
>
> if (!gmp && hdr->mgmt_class != mgmt_class)
> return;
> - if (attr_id && hdr->attr_id != attr_id)
> + if (attr_id && be16_to_cpu(hdr->attr_id) != attr_id)
> return;
>
> printk("Madeye:sent GMP\n");
> @@ -468,7 +468,7 @@ static void recv_gsi_handler(struct ib_mad_agent
> *mad_agent,
>
> if (!gmp && hdr->mgmt_class != mgmt_class)
> return;
> - if (attr_id && mad_recv_wc->recv_buf.mad->mad_hdr.attr_id != attr_id)
> + if (attr_id && be16_to_cpu(mad_recv_wc->recv_buf.mad->mad_hdr.attr_id)
> +!= attr_id)
> return;
>
> printk("Madeye:recv GMP\n");
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ofa_kernel/util madeye.c
I'm resending this - I sent it yesterday, but it doesn't seem to have appeared
in the list.
--
This is a simple fix. Several of the attribute filters in
./drivers/infiniband/util/madeye.c don't switch the attribute id to host byte
order before checking it.
Signed-off-by: Michael Heinz
diff --git a/drivers/infiniband/util/madeye.c b/drivers/infiniband/util/madeye.c
index 0cda06c..2c650a3 100644
--- a/drivers/infiniband/util/madeye.c
+++ b/drivers/infiniband/util/madeye.c
@@ -401,7 +401,7 @@ static void snoop_smi_handler(struct ib_mad_agent
*mad_agent,
if (!smp && hdr->mgmt_class != mgmt_class)
return;
- if (attr_id && hdr->attr_id != attr_id)
+ if (attr_id && be16_to_cpu(hdr->attr_id) != attr_id)
return;
printk("Madeye:sent SMP\n");
@@ -413,7 +413,7 @@ static void recv_smi_handler(struct ib_mad_agent
*mad_agent, {
if (!smp && mad_recv_wc->recv_buf.mad->mad_hdr.mgmt_class != mgmt_class)
return;
- if (attr_id && mad_recv_wc->recv_buf.mad->mad_hdr.attr_id != attr_id)
+ if (attr_id && be16_to_cpu(mad_recv_wc->recv_buf.mad->mad_hdr.attr_id)
+!= attr_id)
return;
printk("Madeye:recv SMP\n");
@@ -446,7 +446,7 @@ static void snoop_gsi_handler(struct ib_mad_agent
*mad_agent,
if (!gmp && hdr->mgmt_class != mgmt_class)
return;
- if (attr_id && hdr->attr_id != attr_id)
+ if (attr_id && be16_to_cpu(hdr->attr_id) != attr_id)
return;
printk("Madeye:sent GMP\n");
@@ -468,7 +468,7 @@ static void recv_gsi_handler(struct ib_mad_agent *mad_agent,
if (!gmp && hdr->mgmt_class != mgmt_class)
return;
- if (attr_id && mad_recv_wc->recv_buf.mad->mad_hdr.attr_id != attr_id)
+ if (attr_id && be16_to_cpu(mad_recv_wc->recv_buf.mad->mad_hdr.attr_id)
+!= attr_id)
return;
printk("Madeye:recv GMP\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mlx4_en: show device's port used
On 5/26/2010 12:32 AM, Roland Dreier wrote: > I don't think there are many devices out there which have more than > one port. ?? http://developer.intel.com/network/connectivity/solutions/gigabit.htm http://www.broadcom.com/products/Ethernet-Controllers/Enterprise-Server/BCM5704C etc But they have different PCI function for each port and we have 2 ports on same PCI device Tziporet -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net/core: use net_device dev_id to indicate port number
Today, there are no means to know which port of a hardware device a netdev interface uses. struct net_device conatins a field, dev_id, that can be used for that. This patch adds a new macro, SET_NETDEV_DEV_ID(), to provide a standard way to set the value of this field. Also also make use of this feature in the mlx4_en driver to set the port number; port numbers are zero based. Signed-off-by: Eli Cohen --- drivers/net/mlx4/en_netdev.c |1 + include/linux/netdevice.h|5 + 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/net/mlx4/en_netdev.c b/drivers/net/mlx4/en_netdev.c index 6c2b15b..612df1e 100644 --- a/drivers/net/mlx4/en_netdev.c +++ b/drivers/net/mlx4/en_netdev.c @@ -978,6 +978,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port, } SET_NETDEV_DEV(dev, &mdev->dev->pdev->dev); + SET_NETDEV_DEV_ID(dev, port - 1); /* * Initialize driver private data diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 3857517..8d5f2c7 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -1080,6 +1080,11 @@ static inline void *netdev_priv(const struct net_device *dev) */ #define SET_NETDEV_DEVTYPE(net, devtype) ((net)->dev.type = (devtype)) +/* + * Set the port number of the physical device that this port net device uses + */ +#define SET_NETDEV_DEV_ID(net, devid) ((net)->dev_id = (devid)) + /** * netif_napi_add - initialize a napi context * @dev: network device -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: Save the port number a netdevice uses
On Wed, May 26, 2010 at 02:16:35AM -0700, David Miller wrote: > > I actually mean that the value "0" should mean the first port, > the value "1" should mean the second port, etc. OK, thanks for clarifying. I'll send a new patch soon. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: Save the port number a netdevice uses
From: Eli Cohen Date: Wed, 26 May 2010 12:08:52 +0300 > So if I understand you correctly, you think that I should not bother > to set a default value of 1. Each driver that cares about the value > of this field, will set it however they want. I actually mean that the value "0" should mean the first port, the value "1" should mean the second port, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: Save the port number a netdevice uses
On Wed, May 26, 2010 at 01:55:26AM -0700, David Miller wrote: > From: Eli Cohen > Date: Wed, 26 May 2010 11:45:23 +0300 > > > What's wrong with using the existing dev_id sysfs file name and saying > that it means the port number of the card? > > Nobody, and I really mean nobody, uses this thing any more. > > It used to be a way for devices like the qeth driver to get it's > IPV6 EUI48 value set properly for local IPV6 addresses assigned > to the device, but that got fixed in a different way. > > So we can use this value however we wish now, and it defaults to zero > for every single device now, and is propagated across VLAN devices, > which is perfect. OK. So if I understand you correctly, you think that I should not bother to set a default value of 1. Each driver that cares about the value of this field, will set it however they want. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: Save the port number a netdevice uses
From: Eli Cohen Date: Wed, 26 May 2010 11:45:23 +0300 > Do you think we should use dev_id also for the sysfs file name so > every driver can choose to interpret this field as it chooses to, or > should I keep the sysfs file name as "port_number"? What's wrong with using the existing dev_id sysfs file name and saying that it means the port number of the card? Nobody, and I really mean nobody, uses this thing any more. It used to be a way for devices like the qeth driver to get it's IPV6 EUI48 value set properly for local IPV6 addresses assigned to the device, but that got fixed in a different way. So we can use this value however we wish now, and it defaults to zero for every single device now, and is propagated across VLAN devices, which is perfect. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: Save the port number a netdevice uses
On Wed, May 26, 2010 at 01:39:26AM -0700, David Miller wrote: > From: Eli Cohen > Date: Wed, 26 May 2010 11:17:02 +0300 > > > Today, there are no means to know which port of a hardware device a netdev > > interface uses. This patch adds a new field to struct net_device that is > > used > > to store this value. The network driver should use the SET_NETDEV_PORT_NUM() > > macro to set the port number for the device it manages. For drivers that do > > not > > set a value, a default value of 1 is set at alloc_netdev_mq(). > > This patch also makes use of this feature in the mlx4_en driver. > > > > Signed-off-by: Eli Cohen > > We have an existing dev_id, use it. Do you think we should use dev_id also for the sysfs file name so every driver can choose to interpret this field as it chooses to, or should I keep the sysfs file name as "port_number"? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core: Save the port number a netdevice uses
From: Eli Cohen Date: Wed, 26 May 2010 11:17:02 +0300 > Today, there are no means to know which port of a hardware device a netdev > interface uses. This patch adds a new field to struct net_device that is used > to store this value. The network driver should use the SET_NETDEV_PORT_NUM() > macro to set the port number for the device it manages. For drivers that do > not > set a value, a default value of 1 is set at alloc_netdev_mq(). > This patch also makes use of this feature in the mlx4_en driver. > > Signed-off-by: Eli Cohen We have an existing dev_id, use it. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net/core: Save the port number a netdevice uses
Today, there are no means to know which port of a hardware device a netdev
interface uses. This patch adds a new field to struct net_device that is used
to store this value. The network driver should use the SET_NETDEV_PORT_NUM()
macro to set the port number for the device it manages. For drivers that do not
set a value, a default value of 1 is set at alloc_netdev_mq().
This patch also makes use of this feature in the mlx4_en driver.
Signed-off-by: Eli Cohen
---
drivers/net/mlx4/en_netdev.c |1 +
include/linux/netdevice.h|6 ++
net/core/dev.c |1 +
net/core/net-sysfs.c |2 ++
4 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/mlx4/en_netdev.c b/drivers/net/mlx4/en_netdev.c
index 6c2b15b..d3df609 100644
--- a/drivers/net/mlx4/en_netdev.c
+++ b/drivers/net/mlx4/en_netdev.c
@@ -978,6 +978,7 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
}
SET_NETDEV_DEV(dev, &mdev->dev->pdev->dev);
+ SET_NETDEV_PORT_NUM(dev, port);
/*
* Initialize driver private data
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 3857517..2a52a6a 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -843,6 +843,7 @@ struct net_device {
unsigned char perm_addr[MAX_ADDR_LEN]; /* permanent hw
address */
unsigned char addr_len; /* hardware address length
*/
unsigned short dev_id; /* for shared network cards */
+ unsigned short port_num; /* for multiport devices */
struct netdev_hw_addr_list uc; /* Secondary unicast
mac addresses */
@@ -1080,6 +1081,11 @@ static inline void *netdev_priv(const struct net_device
*dev)
*/
#define SET_NETDEV_DEVTYPE(net, devtype) ((net)->dev.type = (devtype))
+/*
+ * Set the port number of the physical device that this port net device uses
+ */
+#define SET_NETDEV_PORT_NUM(net, portnum) ((net)->port_num = (portnum))
+
/**
* netif_napi_add - initialize a napi context
* @dev: network device
diff --git a/net/core/dev.c b/net/core/dev.c
index 264137f..8e2f5df 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5471,6 +5471,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const
char *name,
dev->_tx = tx;
dev->num_tx_queues = queue_count;
dev->real_num_tx_queues = queue_count;
+ dev->port_num = 1;
dev->gso_max_size = GSO_MAX_SIZE;
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 59cfc7d..c3d9b39 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -97,6 +97,7 @@ NETDEVICE_SHOW(ifindex, fmt_dec);
NETDEVICE_SHOW(features, fmt_long_hex);
NETDEVICE_SHOW(type, fmt_dec);
NETDEVICE_SHOW(link_mode, fmt_dec);
+NETDEVICE_SHOW(port_num, fmt_dec);
/* use same locking rules as GIFHWADDR ioctl's */
static ssize_t show_address(struct device *dev, struct device_attribute *attr,
@@ -299,6 +300,7 @@ static struct device_attribute net_class_attributes[] = {
__ATTR(features, S_IRUGO, show_features, NULL),
__ATTR(type, S_IRUGO, show_type, NULL),
__ATTR(link_mode, S_IRUGO, show_link_mode, NULL),
+ __ATTR(port_num, S_IRUGO, show_port_num, NULL),
__ATTR(address, S_IRUGO, show_address, NULL),
__ATTR(broadcast, S_IRUGO, show_broadcast, NULL),
__ATTR(carrier, S_IRUGO, show_carrier, NULL),
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
