[PATCH net-next 0/8] Adds support for Chelsio T5 40G adapter and Misc. fixes

[PATCH net-next 0/8] Adds support for Chelsio T5 40G adapter and Misc. fixes

[Hariprasad Shenai]

Hi All,

This patch series adds support for Chelsio T5 40G adapters and provides
miscelleneous fixes for cxgb4 driver.

It also adds device ids of two new T5 adapters.

We would like to request this patch series to get merged via David Miller's
'net-next' tree.

We have included all the maintainers of respective drivers. Kindly review the
change and let us know in case of any review comments.

Thanks,
Hari 

Hariprasad Shenai (1):
  cxgb4: Add more PCI device ids.

Kumar Sanghvi (7):
  cxgb4: Add support to recognize 40G links
  cxgb4: Print adapter VPD Part Number instead of Engineering Change
    field
  cxgb4: Allow >10G ports to have multiple queues
  cxgb4: LE-Workaround is not atomic in firmware
  cxgb4: Query firmware for T5 ULPTX MEMWRITE DSGL capabilities
  cxgb4: Remove unused registers and add missing ones
  cxgb4: Don't assume LSO only uses SGL path in t4_eth_xmit()

 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h      |  5 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 61 ++++++++++++++++++-------
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h  |  1 +
 drivers/net/ethernet/chelsio/cxgb4/sge.c        | 38 ++++++++++-----
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c      | 40 +++++++++++++++-
 drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h   |  4 ++
 6 files changed, 119 insertions(+), 30 deletions(-)

-- 
1.8.0

[PATCH net-next 1/8] cxgb4: Add support to recognize 40G links

[Hariprasad Shenai]

From: Kumar Sanghvi <kumaras@chelsio.com>

Also, create a new Common Code interface to translate Firmware Port Technology
Type values (enum fw_port_type) to string descriptions.  This will allow us
to maintain the description translation table in one place rather than in
every driver.

Based on original work by Scott Bardone and Casey Leedom <leedom@chelsio.com>

Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h      |  2 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 24 +++++++++++------
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c      | 35 ++++++++++++++++++++++++-
 drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h   |  3 +++
 4 files changed, 54 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 1f4b9b3..0c4edd1 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -957,7 +957,7 @@ int t4_mc_read(struct adapter *adap, int idx, u32 addr, __be32 *data,
 	       u64 *parity);
 int t4_edc_read(struct adapter *adap, int idx, u32 addr, __be32 *data,
 		u64 *parity);
-
+const char *t4_get_port_type_description(enum fw_port_type port_type);
 void t4_get_port_stats(struct adapter *adap, int idx, struct port_stats *p);
 void t4_read_mtu_tbl(struct adapter *adap, u16 *mtus, u8 *mtu_log);
 void t4_tp_wr_bits_indirect(struct adapter *adap, unsigned int addr,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 43ab35f..ee2f123 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -432,6 +432,9 @@ static void link_report(struct net_device *dev)
 		case SPEED_100:
 			s = "100Mbps";
 			break;
+		case 40000: /* Need a SPEED_40000 in ethtool.h */
+			s = "40Gbps";
+			break;
 		}
 
 		netdev_info(dev, "link up, %s, full-duplex, %s PAUSE\n", s,
@@ -2199,6 +2202,8 @@ static unsigned int from_fw_linkcaps(unsigned int type, unsigned int caps)
 	else if (type == FW_PORT_TYPE_FIBER_XFI ||
 		 type == FW_PORT_TYPE_FIBER_XAUI || type == FW_PORT_TYPE_SFP)
 		v |= SUPPORTED_FIBRE;
+	else if (type == FW_PORT_TYPE_BP40_BA)
+		v |= SUPPORTED_40000baseSR4_Full;
 
 	if (caps & FW_PORT_CAP_ANEG)
 		v |= SUPPORTED_Autoneg;
@@ -2215,6 +2220,8 @@ static unsigned int to_fw_linkcaps(unsigned int caps)
 		v |= FW_PORT_CAP_SPEED_1G;
 	if (caps & ADVERTISED_10000baseT_Full)
 		v |= FW_PORT_CAP_SPEED_10G;
+	if (caps & ADVERTISED_40000baseSR4_Full)
+		v |= FW_PORT_CAP_SPEED_40G;
 	return v;
 }
 
@@ -2269,6 +2276,8 @@ static unsigned int speed_to_caps(int speed)
 		return FW_PORT_CAP_SPEED_1G;
 	if (speed == SPEED_10000)
 		return FW_PORT_CAP_SPEED_10G;
+	if (speed == 40000) /* Need SPEED_40000 in ethtool.h */
+		return FW_PORT_CAP_SPEED_40G;
 	return 0;
 }
 
@@ -2296,8 +2305,10 @@ static int set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 	if (cmd->autoneg == AUTONEG_DISABLE) {
 		cap = speed_to_caps(speed);
 
-		if (!(lc->supported & cap) || (speed == SPEED_1000) ||
-		    (speed == SPEED_10000))
+		if (!(lc->supported & cap) ||
+		    (speed == SPEED_1000) ||
+		    (speed == SPEED_10000) ||
+		    (speed == 40000))
 			return -EINVAL;
 		lc->requested_speed = cap;
 		lc->advertising = 0;
@@ -5801,11 +5812,6 @@ static int init_rss(struct adapter *adap)
 
 static void print_port_info(const struct net_device *dev)
 {
-	static const char *base[] = {
-		"R XFI", "R XAUI", "T SGMII", "T XFI", "T XAUI", "KX4", "CX4",
-		"KX", "KR", "R SFP+", "KR/KX", "KR/KX/KX4"
-	};
-
 	char buf[80];
 	char *bufp = buf;
 	const char *spd = "";
@@ -5823,9 +5829,11 @@ static void print_port_info(const struct net_device *dev)
 		bufp += sprintf(bufp, "1000/");
 	if (pi->link_cfg.supported & FW_PORT_CAP_SPEED_10G)
 		bufp += sprintf(bufp, "10G/");
+	if (pi->link_cfg.supported & FW_PORT_CAP_SPEED_40G)
+		bufp += sprintf(bufp, "40G/");
 	if (bufp != buf)
 		--bufp;
-	sprintf(bufp, "BASE-%s", base[pi->port_type]);
+	sprintf(bufp, "BASE-%s", t4_get_port_type_description(pi->port_type));
 
 	netdev_info(dev, "Chelsio %s rev %d %s %sNIC PCIe x%d%s%s\n",
 		    adap->params.vpd.id,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 2c10934..514c525 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -1155,7 +1155,8 @@ out:
 }
 
 #define ADVERT_MASK (FW_PORT_CAP_SPEED_100M | FW_PORT_CAP_SPEED_1G |\
-		     FW_PORT_CAP_SPEED_10G | FW_PORT_CAP_ANEG)
+		     FW_PORT_CAP_SPEED_10G | FW_PORT_CAP_SPEED_40G | \
+		     FW_PORT_CAP_ANEG)
 
 /**
  *	t4_link_start - apply link configuration to MAC/PHY
@@ -2247,6 +2248,36 @@ static unsigned int get_mps_bg_map(struct adapter *adap, int idx)
 }
 
 /**
+ *      t4_get_port_type_description - return Port Type string description
+ *      @port_type: firmware Port Type enumeration
+ */
+const char *t4_get_port_type_description(enum fw_port_type port_type)
+{
+	static const char *const port_type_description[] = {
+		"R XFI",
+		"R XAUI",
+		"T SGMII",
+		"T XFI",
+		"T XAUI",
+		"KX4",
+		"CX4",
+		"KX",
+		"KR",
+		"R SFP+",
+		"KR/KX",
+		"KR/KX/KX4",
+		"R QSFP_10G",
+		"",
+		"R QSFP",
+		"R BP40_BA",
+	};
+
+	if (port_type < ARRAY_SIZE(port_type_description))
+		return port_type_description[port_type];
+	return "UNKNOWN";
+}
+
+/**
  *	t4_get_port_stats - collect port statistics
  *	@adap: the adapter
  *	@idx: the port index
@@ -3538,6 +3569,8 @@ int t4_handle_fw_rpl(struct adapter *adap, const __be64 *rpl)
 			speed = SPEED_1000;
 		else if (stat & FW_PORT_CMD_LSPEED(FW_PORT_CAP_SPEED_10G))
 			speed = SPEED_10000;
+		else if (stat & FW_PORT_CMD_LSPEED(FW_PORT_CAP_SPEED_40G))
+			speed = 40000; /* Need SPEED_40000 in ethtool.h */
 
 		if (link_ok != lc->link_ok || speed != lc->speed ||
 		    fc != lc->fc) {                    /* something changed */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 74fea74..af6e124 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -1742,6 +1742,9 @@ enum fw_port_type {
 	FW_PORT_TYPE_SFP,
 	FW_PORT_TYPE_BP_AP,
 	FW_PORT_TYPE_BP4_AP,
+	FW_PORT_TYPE_QSFP_10G,
+	FW_PORT_TYPE_QSFP,
+	FW_PORT_TYPE_BP40_BA,
 
 	FW_PORT_TYPE_NONE = FW_PORT_CMD_PTYPE_MASK
 };
-- 
1.8.0

Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links

[Steve Wise]

On 2/18/2014 6:26 AM, Hariprasad Shenai wrote:
> From: Kumar Sanghvi <kumaras@chelsio.com>
>
> Also, create a new Common Code interface to translate Firmware Port Technology
> Type values (enum fw_port_type) to string descriptions.  This will allow us
> to maintain the description translation table in one place rather than in
> every driver.
>
> Based on original work by Scott Bardone and Casey Leedom <leedom@chelsio.com>
>
> Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
> ---
>   drivers/net/ethernet/chelsio/cxgb4/cxgb4.h      |  2 +-
>   drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 24 +++++++++++------
>   drivers/net/ethernet/chelsio/cxgb4/t4_hw.c      | 35 ++++++++++++++++++++++++-
>   drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h   |  3 +++
>   4 files changed, 54 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
> index 1f4b9b3..0c4edd1 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
> @@ -957,7 +957,7 @@ int t4_mc_read(struct adapter *adap, int idx, u32 addr, __be32 *data,
>   	       u64 *parity);
>   int t4_edc_read(struct adapter *adap, int idx, u32 addr, __be32 *data,
>   		u64 *parity);
> -
> +const char *t4_get_port_type_description(enum fw_port_type port_type);
>   void t4_get_port_stats(struct adapter *adap, int idx, struct port_stats *p);
>   void t4_read_mtu_tbl(struct adapter *adap, u16 *mtus, u8 *mtu_log);
>   void t4_tp_wr_bits_indirect(struct adapter *adap, unsigned int addr,
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> index 43ab35f..ee2f123 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> @@ -432,6 +432,9 @@ static void link_report(struct net_device *dev)
>   		case SPEED_100:
>   			s = "100Mbps";
>   			break;
> +		case 40000: /* Need a SPEED_40000 in ethtool.h */
> +			s = "40Gbps";
> +			break;

You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as 
part of this series.

Steve.

Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links

[Casey Leedom]

On 02/19/14 13:12, Steve Wise wrote:
>
> You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as 
> part of this series.

   I'm ~pretty sure~ that the "word on the street" was that the 
community wanted to get away from the SPEED_XXX symbols since they 
simply represented the values XXX.  Thus they didn't offer any real 
symbolic isolation from weird constants, etc.  I believe that the old 
SPEED_XXX values were left in place in order to avoid making tons of 
changes everywhere ...

Casey

Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links

[Florian Fainelli]

2014-02-20 10:07 GMT-08:00 Casey Leedom <leedom@chelsio.com>:
>
> On 02/19/14 13:12, Steve Wise wrote:
>>
>>
>> You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as
>> part of this series.
>
>
>   I'm ~pretty sure~ that the "word on the street" was that the community
> wanted to get away from the SPEED_XXX symbols since they simply represented
> the values XXX.  Thus they didn't offer any real symbolic isolation from
> weird constants, etc.  I believe that the old SPEED_XXX values were left in
> place in order to avoid making tons of changes everywhere ...

Not quite sure where and when you heard that, it seems a little
disturbing to add a comment in this patch saying "this I how I should
fix things" and not do them, especially when this is a one-liner.
Having a well defined constant is easier to grep than having the
open-coded 40000 constant which will lead to false positives
throughout the tree.
--
Florian

Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links

[Casey Leedom]

On 02/20/14 11:00, Florian Fainelli wrote:
> 2014-02-20 10:07 GMT-08:00 Casey Leedom <leedom@chelsio.com>:
>> On 02/19/14 13:12, Steve Wise wrote:
>>>
>>> You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as
>>> part of this series.
>>
>>    I'm ~pretty sure~ that the "word on the street" was that the community
>> wanted to get away from the SPEED_XXX symbols since they simply represented
>> the values XXX.  Thus they didn't offer any real symbolic isolation from
>> weird constants, etc.  I believe that the old SPEED_XXX values were left in
>> place in order to avoid making tons of changes everywhere ...
> Not quite sure where and when you heard that, it seems a little
> disturbing to add a comment in this patch saying "this I how I should
> fix things" and not do them, especially when this is a one-liner.
> Having a well defined constant is easier to grep than having the
> open-coded 40000 constant which will lead to false positives
> throughout the tree.

   Like I said, it was a vague memory at best from over a year ago. I 
seem to remember someone on our team trying to push SPEED_40000 into the 
kernel and getting rebuffed.  Perhaps I didn't have enough coffee that day.

   In any case, I personally like the idea of SPEED_40000 for exactly 
the reason you offer: I can search for it meaningfully.  So If my vague 
memory is wrong, yeay!

Casey

> --
> Florian

Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links

[Kumar Sanghvi]

On Thursday, February 02/20/14, 2014 at 11:16:26 -0800, Casey Leedom wrote:
> 
> On 02/20/14 11:00, Florian Fainelli wrote:
> >2014-02-20 10:07 GMT-08:00 Casey Leedom <leedom@chelsio.com>:
> >>On 02/19/14 13:12, Steve Wise wrote:
> >>>
> >>>You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as
> >>>part of this series.
> >>
> >>   I'm ~pretty sure~ that the "word on the street" was that the community
> >>wanted to get away from the SPEED_XXX symbols since they simply represented
> >>the values XXX.  Thus they didn't offer any real symbolic isolation from
> >>weird constants, etc.  I believe that the old SPEED_XXX values were left in
> >>place in order to avoid making tons of changes everywhere ...
> >Not quite sure where and when you heard that, it seems a little
> >disturbing to add a comment in this patch saying "this I how I should
> >fix things" and not do them, especially when this is a one-liner.
> >Having a well defined constant is easier to grep than having the
> >open-coded 40000 constant which will lead to false positives
> >throughout the tree.
> 
>   Like I said, it was a vague memory at best from over a year ago. I
> seem to remember someone on our team trying to push SPEED_40000 into
> the kernel and getting rebuffed.  Perhaps I didn't have enough
> coffee that day.
> 
>   In any case, I personally like the idea of SPEED_40000 for exactly
> the reason you offer: I can search for it meaningfully.  So If my
> vague memory is wrong, yeay!


BTW, I just now found below thread and discussion related to SPEED_40000
http://www.spinics.net/lists/netdev/msg201449.html


> 
> Casey
> 
> >--
> >Florian
> 
> 

Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links

[Casey Leedom]

   Ah, thanks Kumar.  So I wasn't ~completely~ off my rocker remembering 
that.

   So it sounds like Ben and David are (or at least, were) in the 
anti-SPEED_40000 and Florian may be in the "pro" camp ...

Casey

On 02/20/14 20:37, Kumar Sanghvi wrote:
> On Thursday, February 02/20/14, 2014 at 11:16:26 -0800, Casey Leedom wrote:
>> On 02/20/14 11:00, Florian Fainelli wrote:
>>> 2014-02-20 10:07 GMT-08:00 Casey Leedom <leedom@chelsio.com>:
>>>> On 02/19/14 13:12, Steve Wise wrote:
>>>>> You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as
>>>>> part of this series.
>>>>    I'm ~pretty sure~ that the "word on the street" was that the community
>>>> wanted to get away from the SPEED_XXX symbols since they simply represented
>>>> the values XXX.  Thus they didn't offer any real symbolic isolation from
>>>> weird constants, etc.  I believe that the old SPEED_XXX values were left in
>>>> place in order to avoid making tons of changes everywhere ...
>>> Not quite sure where and when you heard that, it seems a little
>>> disturbing to add a comment in this patch saying "this I how I should
>>> fix things" and not do them, especially when this is a one-liner.
>>> Having a well defined constant is easier to grep than having the
>>> open-coded 40000 constant which will lead to false positives
>>> throughout the tree.
>>    Like I said, it was a vague memory at best from over a year ago. I
>> seem to remember someone on our team trying to push SPEED_40000 into
>> the kernel and getting rebuffed.  Perhaps I didn't have enough
>> coffee that day.
>>
>>    In any case, I personally like the idea of SPEED_40000 for exactly
>> the reason you offer: I can search for it meaningfully.  So If my
>> vague memory is wrong, yeay!
>
> BTW, I just now found below thread and discussion related to SPEED_40000
> http://www.spinics.net/lists/netdev/msg201449.html
>
>
>> Casey
>>
>>> --
>>> Florian
>>

Re: [PATCH net-next 1/8] cxgb4: Add support to recognize 40G links

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

On Thu, 2014-02-20 at 11:00 -0800, Florian Fainelli wrote:
> 2014-02-20 10:07 GMT-08:00 Casey Leedom <leedom@chelsio.com>:
> >
> > On 02/19/14 13:12, Steve Wise wrote:
> >>
> >>
> >> You probably should add SPEED_40000 to include/uapi/linux/ethtool.h as
> >> part of this series.
> >
> >
> >   I'm ~pretty sure~ that the "word on the street" was that the community
> > wanted to get away from the SPEED_XXX symbols since they simply represented
> > the values XXX.  Thus they didn't offer any real symbolic isolation from
> > weird constants, etc.  I believe that the old SPEED_XXX values were left in
> > place in order to avoid making tons of changes everywhere ...
> 
> Not quite sure where and when you heard that, it seems a little
> disturbing to add a comment in this patch saying "this I how I should
> fix things" and not do them, especially when this is a one-liner.
[...]

Yeah, the way to fix that is to remove the comments...

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

[PATCH net-next 2/8] cxgb4: Print adapter VPD Part Number instead of Engineering Change field

[Hariprasad Shenai]

From: Kumar Sanghvi <kumaras@chelsio.com>

When we attach to adapter, print VPD Part Number instead of Engineering Change field.
Based on original work by Casey Leedom <leedom@chelsio.com>

Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h      | 2 ++
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 ++--
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c      | 5 ++++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 0c4edd1..028b5e5 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -66,6 +66,7 @@ enum {
 	SERNUM_LEN = 24,    /* Serial # length */
 	EC_LEN     = 16,    /* E/C length */
 	ID_LEN     = 16,    /* ID length */
+	PN_LEN     = 16,    /* Part Number length */
 };
 
 enum {
@@ -254,6 +255,7 @@ struct vpd_params {
 	u8 ec[EC_LEN + 1];
 	u8 sn[SERNUM_LEN + 1];
 	u8 id[ID_LEN + 1];
+	u8 pn[PN_LEN + 1];
 };
 
 struct pci_params {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index ee2f123..5e345bc 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5841,8 +5841,8 @@ static void print_port_info(const struct net_device *dev)
 		    is_offload(adap) ? "R" : "", adap->params.pci.width, spd,
 		    (adap->flags & USING_MSIX) ? " MSI-X" :
 		    (adap->flags & USING_MSI) ? " MSI" : "");
-	netdev_info(dev, "S/N: %s, E/C: %s\n",
-		    adap->params.vpd.sn, adap->params.vpd.ec);
+	netdev_info(dev, "S/N: %s, P/N: %s\n",
+		    adap->params.vpd.sn, adap->params.vpd.pn);
 }
 
 static void enable_pcie_relaxed_ordering(struct pci_dev *dev)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 514c525..7ae756d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -573,7 +573,7 @@ int get_vpd_params(struct adapter *adapter, struct vpd_params *p)
 {
 	u32 cclk_param, cclk_val;
 	int i, ret, addr;
-	int ec, sn;
+	int ec, sn, pn;
 	u8 *vpd, csum;
 	unsigned int vpdr_len, kw_offset, id_len;
 
@@ -638,6 +638,7 @@ int get_vpd_params(struct adapter *adapter, struct vpd_params *p)
 
 	FIND_VPD_KW(ec, "EC");
 	FIND_VPD_KW(sn, "SN");
+	FIND_VPD_KW(pn, "PN");
 #undef FIND_VPD_KW
 
 	memcpy(p->id, vpd + PCI_VPD_LRDT_TAG_SIZE, id_len);
@@ -647,6 +648,8 @@ int get_vpd_params(struct adapter *adapter, struct vpd_params *p)
 	i = pci_vpd_info_field_size(vpd + sn - PCI_VPD_INFO_FLD_HDR_SIZE);
 	memcpy(p->sn, vpd + sn, min(i, SERNUM_LEN));
 	strim(p->sn);
+	memcpy(p->pn, vpd + pn, min(i, PN_LEN));
+	strim(p->pn);
 
 	/*
 	 * Ask firmware for the Core Clock since it knows how to translate the
-- 
1.8.0

[PATCH net-next 3/8] cxgb4: Allow >10G ports to have multiple queues

[Hariprasad Shenai]

From: Kumar Sanghvi <kumaras@chelsio.com>

Based on original work by Divy Le Ray.

Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 5e345bc..1cc9b4d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5614,9 +5614,10 @@ static const struct pci_error_handlers cxgb4_eeh = {
 	.resume         = eeh_resume,
 };
 
-static inline bool is_10g_port(const struct link_config *lc)
+static inline bool is_x_10g_port(const struct link_config *lc)
 {
-	return (lc->supported & FW_PORT_CAP_SPEED_10G) != 0;
+	return (lc->supported & FW_PORT_CAP_SPEED_10G) != 0 ||
+	       (lc->supported & FW_PORT_CAP_SPEED_40G) != 0;
 }
 
 static inline void init_rspq(struct sge_rspq *q, u8 timer_idx, u8 pkt_cnt_idx,
@@ -5640,7 +5641,7 @@ static void cfg_queues(struct adapter *adap)
 	int i, q10g = 0, n10g = 0, qidx = 0;
 
 	for_each_port(adap, i)
-		n10g += is_10g_port(&adap2pinfo(adap, i)->link_cfg);
+		n10g += is_x_10g_port(&adap2pinfo(adap, i)->link_cfg);
 
 	/*
 	 * We default to 1 queue per non-10G port and up to # of cores queues
@@ -5655,7 +5656,7 @@ static void cfg_queues(struct adapter *adap)
 		struct port_info *pi = adap2pinfo(adap, i);
 
 		pi->first_qset = qidx;
-		pi->nqsets = is_10g_port(&pi->link_cfg) ? q10g : 1;
+		pi->nqsets = is_x_10g_port(&pi->link_cfg) ? q10g : 1;
 		qidx += pi->nqsets;
 	}
 
-- 
1.8.0

[PATCH net-next 4/8] cxgb4: LE-Workaround is not atomic in firmware

[Hariprasad Shenai]

From: Kumar Sanghvi <kumaras@chelsio.com>

The LE workaround in firmware is not atomic and fw_ofld_connection_wrs must not interleave.
Therefore, when the workaround is enabled, we need to send all ctrlq WRs on a single ctrl queue.

Based on original work by Santosh Rastapur <santosh@chelsio.com>

Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb4/sge.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 47ffa64..23dbe28 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -1467,8 +1467,12 @@ static inline int ofld_send(struct adapter *adap, struct sk_buff *skb)
 {
 	unsigned int idx = skb_txq(skb);
 
-	if (unlikely(is_ctrl_pkt(skb)))
+	if (unlikely(is_ctrl_pkt(skb))) {
+		/* Single ctrl queue is a requirement for LE workaround path */
+		if (adap->tids.nsftids)
+			idx = 0;
 		return ctrl_xmit(&adap->sge.ctrlq[idx], skb);
+	}
 	return ofld_xmit(&adap->sge.ofldtxq[idx], skb);
 }
 
-- 
1.8.0

[PATCH net-next 5/8] cxgb4: Query firmware for T5 ULPTX MEMWRITE DSGL capabilities

[Hariprasad Shenai]

From: Kumar Sanghvi <kumaras@chelsio.com>

Query firmware to see whether we're allowed to use T5 ULPTX MEMWRITE DSGL
capabilities.  Also pass that information to Upper Layer Drivers via the
new (struct cxgb4_lld_info).ulptx_memwrite_dsgl boolean.

Based on original work by Casey Leedom <leedom@chelsio.com>

Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h      |  1 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 16 ++++++++++++++++
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h  |  1 +
 drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h   |  1 +
 4 files changed, 19 insertions(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 028b5e5..944f2cb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -308,6 +308,7 @@ struct adapter_params {
 	unsigned char bypass;
 
 	unsigned int ofldq_wr_cred;
+	bool ulptx_memwrite_dsgl;          /* use of T5 DSGL allowed */
 };
 
 #include "t4fw_api.h"
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 1cc9b4d..0e3e98e 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3776,6 +3776,7 @@ static void uld_attach(struct adapter *adap, unsigned int uld)
 	lli.dbfifo_int_thresh = dbfifo_int_thresh;
 	lli.sge_pktshift = adap->sge.pktshift;
 	lli.enable_fw_ofld_conn = adap->flags & FW_OFLD_CONN;
+	lli.ulptx_memwrite_dsgl = adap->params.ulptx_memwrite_dsgl;
 
 	handle = ulds[uld].add(&lli);
 	if (IS_ERR(handle)) {
@@ -5381,6 +5382,21 @@ static int adap_init0(struct adapter *adap)
 	(void) t4_set_params(adap, adap->mbox, adap->fn, 0, 1, params, val);
 
 	/*
+	 * Find out whether we're allowed to use the T5+ ULPTX MEMWRITE DSGL
+	 * capability.  Earlier versions of the firmware didn't have the
+	 * ULPTX_MEMWRITE_DSGL so we'll interpret a query failure as no
+	 * permission to use ULPTX MEMWRITE DSGL.
+	 */
+	if (is_t4(adap->params.chip)) {
+		adap->params.ulptx_memwrite_dsgl = false;
+	} else {
+		params[0] = FW_PARAM_DEV(ULPTX_MEMWRITE_DSGL);
+		ret = t4_query_params(adap, adap->mbox, adap->fn, 0,
+				      1, params, val);
+		adap->params.ulptx_memwrite_dsgl = (ret == 0 && val[0] != 0);
+	}
+
+	/*
 	 * Get device capabilities so we can determine what resources we need
 	 * to manage.
 	 */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
index 4dd0a82..e274a04 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h
@@ -253,6 +253,7 @@ struct cxgb4_lld_info {
 					     /*	packet data */
 	bool enable_fw_ofld_conn;            /* Enable connection through fw */
 					     /* WR */
+	bool ulptx_memwrite_dsgl;            /* use of T5 DSGL allowed */
 };
 
 struct cxgb4_uld_info {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index af6e124..9cc973f 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -932,6 +932,7 @@ enum fw_params_param_dev {
 	FW_PARAMS_PARAM_DEV_FWREV = 0x0B,
 	FW_PARAMS_PARAM_DEV_TPREV = 0x0C,
 	FW_PARAMS_PARAM_DEV_CF = 0x0D,
+	FW_PARAMS_PARAM_DEV_ULPTX_MEMWRITE_DSGL = 0x17,
 };
 
 /*
-- 
1.8.0

[PATCH net-next 6/8] cxgb4: Remove unused registers and add missing ones

[Hariprasad Shenai]

From: Kumar Sanghvi <kumaras@chelsio.com>

Remove unused registers for registers list, and add missing ones
Based on original work by Santosh Rastapur <santosh@chelsio.com>

Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 0e3e98e..654ff3a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -2064,7 +2064,7 @@ static void get_regs(struct net_device *dev, struct ethtool_regs *regs,
 		0x40200, 0x40298,
 		0x402ac, 0x4033c,
 		0x403f8, 0x403fc,
-		0x41300, 0x413c4,
+		0x41304, 0x413c4,
 		0x41400, 0x4141c,
 		0x41480, 0x414d0,
 		0x44000, 0x44078,
@@ -2092,7 +2092,7 @@ static void get_regs(struct net_device *dev, struct ethtool_regs *regs,
 		0x48200, 0x48298,
 		0x482ac, 0x4833c,
 		0x483f8, 0x483fc,
-		0x49300, 0x493c4,
+		0x49304, 0x493c4,
 		0x49400, 0x4941c,
 		0x49480, 0x494d0,
 		0x4c000, 0x4c078,
-- 
1.8.0

[PATCH net-next 7/8] cxgb4: Don't assume LSO only uses SGL path in t4_eth_xmit()

[Hariprasad Shenai]

From: Kumar Sanghvi <kumaras@chelsio.com>

Also, modify is_eth_imm() to return header length so it doesn't
have to be recomputed in calc_tx_flits().

Based on original work by Mike Werner <werner@chelsio.com>

Signed-off-by: Kumar Sanghvi <kumaras@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb4/sge.c | 32 ++++++++++++++++++++++----------
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 23dbe28..af76b25 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -706,11 +706,17 @@ static inline unsigned int flits_to_desc(unsigned int n)
  *	@skb: the packet
  *
  *	Returns whether an Ethernet packet is small enough to fit as
- *	immediate data.
+ *	immediate data. Return value corresponds to headroom required.
  */
 static inline int is_eth_imm(const struct sk_buff *skb)
 {
-	return skb->len <= MAX_IMM_TX_PKT_LEN - sizeof(struct cpl_tx_pkt);
+	int hdrlen = skb_shinfo(skb)->gso_size ?
+			sizeof(struct cpl_tx_pkt_lso_core) : 0;
+
+	hdrlen += sizeof(struct cpl_tx_pkt);
+	if (skb->len <= MAX_IMM_TX_PKT_LEN - hdrlen)
+		return hdrlen;
+	return 0;
 }
 
 /**
@@ -723,9 +729,10 @@ static inline int is_eth_imm(const struct sk_buff *skb)
 static inline unsigned int calc_tx_flits(const struct sk_buff *skb)
 {
 	unsigned int flits;
+	int hdrlen = is_eth_imm(skb);
 
-	if (is_eth_imm(skb))
-		return DIV_ROUND_UP(skb->len + sizeof(struct cpl_tx_pkt), 8);
+	if (hdrlen)
+		return DIV_ROUND_UP(skb->len + hdrlen, sizeof(__be64));
 
 	flits = sgl_len(skb_shinfo(skb)->nr_frags + 1) + 4;
 	if (skb_shinfo(skb)->gso_size)
@@ -971,6 +978,7 @@ static inline void txq_advance(struct sge_txq *q, unsigned int n)
  */
 netdev_tx_t t4_eth_xmit(struct sk_buff *skb, struct net_device *dev)
 {
+	int len;
 	u32 wr_mid;
 	u64 cntrl, *end;
 	int qidx, credits;
@@ -982,6 +990,7 @@ netdev_tx_t t4_eth_xmit(struct sk_buff *skb, struct net_device *dev)
 	struct cpl_tx_pkt_core *cpl;
 	const struct skb_shared_info *ssi;
 	dma_addr_t addr[MAX_SKB_FRAGS + 1];
+	bool immediate = false;
 
 	/*
 	 * The chip min packet length is 10 octets but play safe and reject
@@ -1011,7 +1020,10 @@ out_free:	dev_kfree_skb(skb);
 		return NETDEV_TX_BUSY;
 	}
 
-	if (!is_eth_imm(skb) &&
+	if (is_eth_imm(skb))
+		immediate = true;
+
+	if (!immediate &&
 	    unlikely(map_skb(adap->pdev_dev, skb, addr) < 0)) {
 		q->mapping_err++;
 		goto out_free;
@@ -1028,6 +1040,8 @@ out_free:	dev_kfree_skb(skb);
 	wr->r3 = cpu_to_be64(0);
 	end = (u64 *)wr + flits;
 
+	len = immediate ? skb->len : 0;
+	len += sizeof(*cpl);
 	ssi = skb_shinfo(skb);
 	if (ssi->gso_size) {
 		struct cpl_tx_pkt_lso *lso = (void *)wr;
@@ -1035,8 +1049,9 @@ out_free:	dev_kfree_skb(skb);
 		int l3hdr_len = skb_network_header_len(skb);
 		int eth_xtra_len = skb_network_offset(skb) - ETH_HLEN;
 
+		len += sizeof(*lso);
 		wr->op_immdlen = htonl(FW_WR_OP(FW_ETH_TX_PKT_WR) |
-				       FW_WR_IMMDLEN(sizeof(*lso)));
+				       FW_WR_IMMDLEN(len));
 		lso->c.lso_ctrl = htonl(LSO_OPCODE(CPL_TX_PKT_LSO) |
 					LSO_FIRST_SLICE | LSO_LAST_SLICE |
 					LSO_IPV6(v6) |
@@ -1054,9 +1069,6 @@ out_free:	dev_kfree_skb(skb);
 		q->tso++;
 		q->tx_cso += ssi->gso_segs;
 	} else {
-		int len;
-
-		len = is_eth_imm(skb) ? skb->len + sizeof(*cpl) : sizeof(*cpl);
 		wr->op_immdlen = htonl(FW_WR_OP(FW_ETH_TX_PKT_WR) |
 				       FW_WR_IMMDLEN(len));
 		cpl = (void *)(wr + 1);
@@ -1078,7 +1090,7 @@ out_free:	dev_kfree_skb(skb);
 	cpl->len = htons(skb->len);
 	cpl->ctrl1 = cpu_to_be64(cntrl);
 
-	if (is_eth_imm(skb)) {
+	if (immediate) {
 		inline_tx_skb(skb, &q->q, cpl + 1);
 		dev_kfree_skb(skb);
 	} else {
-- 
1.8.0

[PATCH net-next 8/8] cxgb4: Add more PCI device ids.

[Hariprasad Shenai]

Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 654ff3a..3c95288 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -254,6 +254,8 @@ static DEFINE_PCI_DEVICE_TABLE(cxgb4_pci_tbl) = {
 	CH_DEVICE(0x5011, 4),
 	CH_DEVICE(0x5012, 4),
 	CH_DEVICE(0x5013, 4),
+	CH_DEVICE(0x5014, 4),
+	CH_DEVICE(0x5015, 4),
 	CH_DEVICE(0x5401, 4),
 	CH_DEVICE(0x5402, 4),
 	CH_DEVICE(0x5403, 4),
@@ -273,6 +275,8 @@ static DEFINE_PCI_DEVICE_TABLE(cxgb4_pci_tbl) = {
 	CH_DEVICE(0x5411, 4),
 	CH_DEVICE(0x5412, 4),
 	CH_DEVICE(0x5413, 4),
+	CH_DEVICE(0x5414, 4),
+	CH_DEVICE(0x5415, 4),
 	{ 0, }
 };
 
-- 
1.8.0

Re: [PATCH net-next 0/8] Adds support for Chelsio T5 40G adapter and Misc. fixes

[David Miller]

From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue, 18 Feb 2014 17:56:07 +0530

> This patch series adds support for Chelsio T5 40G adapters and provides
> miscelleneous fixes for cxgb4 driver.
> 
> It also adds device ids of two new T5 adapters.
> 
> We would like to request this patch series to get merged via David Miller's
> 'net-next' tree.
> 
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.

Series applied, thanks.