* Re: codel: split into multiple files
From: Jens Axboe @ 2016-04-26 14:37 UTC (permalink / raw)
To: Michal Kazior, sedat.dilek; +Cc: David S. Miller, netdev@vger.kernel.org
In-Reply-To: <CA+BoTQmovjcYFA4JQBDNQwJHmu=MjZg_HnDn4+KbTi6vYcVV7A@mail.gmail.com>
On 04/26/2016 06:36 AM, Michal Kazior wrote:
> On 26 April 2016 at 08:43, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> On 4/26/16, Michal Kazior <michal.kazior@tieto.com> wrote:
>>> On 26 April 2016 at 08:09, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I had a very quick view on net-next.git#master (up to commit
>>>> fab7b629a82da1b59620470d13152aff975239f6).
>>>>
>>>> Commit in [1] aka "codel: split into multiple files" removed codel.h
>>>> but [2] and [3] have relicts to it.
>>>> Forgot to remove?
>>>
>>> codel.h was not removed. diffstat for codel.h is all red which I
>>> presume is why you thought of it as removed, see:
>>>
>>> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/include/net/codel.h?id=d068ca2ae2e614b9a418fb3b5f1fd4cf996ff032
>>>
>>
>> [ CC Jens ]
>>
>> OK.
>> So what are the plans in the future?
>> Keep a "generic" codel.h (compatibility reasons?) for net or is it your split?
>
> I'm interested in re-using codel in mac80211 for wireless. cfg80211
> drivers may want to do that as well later. Even vendor drivers could
> start to use it (I can dream :).
>
> I plan to re-spin my patches soonish re-based on the new codel.h/fq.h
> approach. There's quite a few spins already[1].
>
>
>> AFAICS I have seen a codel-implementation in block.git#wb-buf-throttle.
>> Does it make sense to have a more "super-generic" codel.h for re-use
>> (not only for net and block)?
>> Just a thought.
>
> Oh, I'm not really familiar with block and problems around it but it
> sounds reasonable and interesting. It doesn't look like it blatantly
> copies codel though (I did that in my initial mac80211 patches with
> some adjustments, you can check that in the link[1] which you can
> lookup via my patchset's cover letter[2]; I've based off of codel5[3]
> back then).
The block version is an adaptation, I guess you can say it pays homage
to CoDel. But there are a sufficient amount of differences between
networking and storage that I don't think a fully generic version is
really feasible. My favorite thing to bring up is the fact that we don't
have the luxury of dropping packets on the storage side...
--
Jens Axboe
^ permalink raw reply
* Re: [net-next PATCH 6/8] mlx4: Add support for inner IPv6 checksum offloads and TSO
From: Saeed Mahameed @ 2016-04-26 14:37 UTC (permalink / raw)
To: Alexander Duyck, talal, netdev, davem, galp, ogerlitz, eranbe
In-Reply-To: <20160425183133.11331.54774.stgit@ahduyck-xeon-server>
On 4/25/2016 9:31 PM, Alexander Duyck wrote:
> >From what I can tell the ConnectX-3 will support an inner IPv6 checksum and
> segmentation offload, however it cannot support outer IPv6 headers. For
> this reason I am adding the feature to the hw_enc_features and adding an
> extra check to the features_check call that will disable GSO and checksum
> offload in the case that the encapsulated frame has an outer IP version of
> that is not 4.
Hi Alex,
Can you share the testing commands of running vxlan over IPv6 and what
exactly didn't work for you ?
we would like to test this in house and understand what went wrong,
theoretically there shouldn't be a difference between IPv6/IPv4 outer
checksum offloading in ConnectX-3.
Anyway, I suspect it might be related to a driver bug most likely in
get_real_size function @en_tx.c
specifically in : *lso_header_size = (skb_inner_transport_header(skb) -
skb->data) + inner_tcp_hdrlen(skb);
will check this and get back to you.
for the mlx5 patches I will also go through them later today.
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 25 +++++++++++++++++++-----
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 15 ++++++++++++--
> 2 files changed, 33 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index bce37cbfde24..6f28ac58251c 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -2357,8 +2357,10 @@ out:
> }
>
> /* set offloads */
> - priv->dev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
> - NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL |
> + priv->dev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> + NETIF_F_RXCSUM |
> + NETIF_F_TSO | NETIF_F_TSO6 |
> + NETIF_F_GSO_UDP_TUNNEL |
> NETIF_F_GSO_UDP_TUNNEL_CSUM |
> NETIF_F_GSO_PARTIAL;
> }
> @@ -2369,8 +2371,10 @@ static void mlx4_en_del_vxlan_offloads(struct work_struct *work)
> struct mlx4_en_priv *priv = container_of(work, struct mlx4_en_priv,
> vxlan_del_task);
> /* unset offloads */
> - priv->dev->hw_enc_features &= ~(NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
> - NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL |
> + priv->dev->hw_enc_features &= ~(NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> + NETIF_F_RXCSUM |
> + NETIF_F_TSO | NETIF_F_TSO6 |
> + NETIF_F_GSO_UDP_TUNNEL |
> NETIF_F_GSO_UDP_TUNNEL_CSUM |
> NETIF_F_GSO_PARTIAL);
>
> @@ -2431,7 +2435,18 @@ static netdev_features_t mlx4_en_features_check(struct sk_buff *skb,
> netdev_features_t features)
> {
> features = vlan_features_check(skb, features);
> - return vxlan_features_check(skb, features);
> + features = vxlan_features_check(skb, features);
> +
> + /* The ConnectX-3 doesn't support outer IPv6 checksums but it does
> + * support inner IPv6 checksums and segmentation so we need to
> + * strip that feature if this is an IPv6 encapsulated frame.
> + */
> + if (skb->encapsulation &&
> + (skb->ip_summed == CHECKSUM_PARTIAL) &&
> + (ip_hdr(skb)->version != 4))
> + features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
Dejavu, didn't you fix this already in harmonize_features, in
i.e, it is enough to do here:
if (skb->encapsulation && (skb->ip_summed == CHECKSUM_PARTIAL))
features &= ~NETIF_F_IPV6_CSUM;
> +
> + return features;
> }
> #endif
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> index c0d7b7296236..c9f5388ea22a 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> @@ -41,6 +41,7 @@
> #include <linux/vmalloc.h>
> #include <linux/tcp.h>
> #include <linux/ip.h>
> +#include <linux/ipv6.h>
> #include <linux/moduleparam.h>
>
> #include "mlx4_en.h"
> @@ -918,8 +919,18 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
> tx_ind, fragptr);
>
> if (skb->encapsulation) {
> - struct iphdr *ipv4 = (struct iphdr *)skb_inner_network_header(skb);
> - if (ipv4->protocol == IPPROTO_TCP || ipv4->protocol == IPPROTO_UDP)
> + union {
> + struct iphdr *v4;
> + struct ipv6hdr *v6;
> + unsigned char *hdr;
> + } ip;
> + u8 proto;
> +
> + ip.hdr = skb_inner_network_header(skb);
> + proto = (ip.v4->version == 4) ? ip.v4->protocol :
> + ip.v6->nexthdr;
> +
> + if (proto == IPPROTO_TCP || proto == IPPROTO_UDP)
> op_own |= cpu_to_be32(MLX4_WQE_CTRL_IIP | MLX4_WQE_CTRL_ILP);
> else
> op_own |= cpu_to_be32(MLX4_WQE_CTRL_IIP);
basically this is a bug fix, I don't know why the original author
assumed it will be ipv4 !
^ permalink raw reply
* [PATCH net-next 6/8] cxgb4: DCB message handler needs to use correct portid to netdev mapping
From: Hariprasad Shenai @ 2016-04-26 14:40 UTC (permalink / raw)
To: davem; +Cc: netdev, leedom, swise, nirranjan, santosh, Hariprasad Shenai
In-Reply-To: <1461681629-28275-1-git-send-email-hariprasad@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
index 052c660aca80..6ee2ed30626b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
@@ -253,7 +253,7 @@ void cxgb4_dcb_handle_fw_update(struct adapter *adap,
{
const union fw_port_dcb *fwdcb = &pcmd->u.dcb;
int port = FW_PORT_CMD_PORTID_G(be32_to_cpu(pcmd->op_to_portid));
- struct net_device *dev = adap->port[port];
+ struct net_device *dev = adap->port[adap->chan_map[port]];
struct port_info *pi = netdev_priv(dev);
struct port_dcb_info *dcb = &pi->dcb;
int dcb_type = pcmd->u.dcb.pgid.type;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index abc425bfc744..4f627f3edb98 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -515,7 +515,7 @@ EXPORT_SYMBOL(cxgb4_dcb_enabled);
static void dcb_rpl(struct adapter *adap, const struct fw_port_cmd *pcmd)
{
int port = FW_PORT_CMD_PORTID_G(ntohl(pcmd->op_to_portid));
- struct net_device *dev = adap->port[port];
+ struct net_device *dev = adap->port[adap->chan_map[port]];
int old_dcb_enabled = cxgb4_dcb_enabled(dev);
int new_dcb_enabled;
@@ -645,7 +645,8 @@ static int fwevtq_handler(struct sge_rspq *q, const __be64 *rsp,
action == FW_PORT_ACTION_GET_PORT_INFO) {
int port = FW_PORT_CMD_PORTID_G(
be32_to_cpu(pcmd->op_to_portid));
- struct net_device *dev = q->adap->port[port];
+ struct net_device *dev =
+ q->adap->port[q->adap->chan_map[port]];
int state_input = ((pcmd->u.info.dcbxdis_pkd &
FW_PORT_CMD_DCBXDIS_F)
? CXGB4_DCB_INPUT_FW_DISABLED
--
2.3.4
^ permalink raw reply related
* [PATCH net-next 7/8] cxgb4: Don't assume FW_PORT_CMD reply is always port info msg
From: Hariprasad Shenai @ 2016-04-26 14:40 UTC (permalink / raw)
To: davem; +Cc: netdev, leedom, swise, nirranjan, santosh, Hariprasad Shenai
In-Reply-To: <1461681629-28275-1-git-send-email-hariprasad@chelsio.com>
The firmware can send a set of asynchronous replies through FW_PORT_CMD
with DCBX information when that's negotiated with the Link Peer. The old
code always assumed that a FW_PORT_CMD reply was always a Get Port
Information message. This change conditionalizes the code to only handle
the Get Port Information messages and throws a warning if we don't
understand what we've been given.
Also refactor t4_handle_fw_rpl() so that core functionality performed by
t4_handle_get_port_info() for a specified port.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 110 +++++++++++++++++++----------
2 files changed, 74 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index f69119bc5990..911fe11d32c6 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1470,6 +1470,7 @@ int t4_ctrl_eq_free(struct adapter *adap, unsigned int mbox, unsigned int pf,
int t4_ofld_eq_free(struct adapter *adap, unsigned int mbox, unsigned int pf,
unsigned int vf, unsigned int eqid);
int t4_sge_ctxt_flush(struct adapter *adap, unsigned int mbox);
+void t4_handle_get_port_info(struct port_info *pi, const __be64 *rpl);
int t4_handle_fw_rpl(struct adapter *adap, const __be64 *rpl);
void t4_db_full(struct adapter *adapter);
void t4_db_dropped(struct adapter *adapter);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 1ebbbb9323e3..cf3efbf4a37a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -7103,52 +7103,88 @@ int t4_ofld_eq_free(struct adapter *adap, unsigned int mbox, unsigned int pf,
}
/**
- * t4_handle_fw_rpl - process a FW reply message
- * @adap: the adapter
+ * t4_handle_get_port_info - process a FW reply message
+ * @pi: the port info
* @rpl: start of the FW message
*
- * Processes a FW message, such as link state change messages.
+ * Processes a GET_PORT_INFO FW reply message.
+ */
+void t4_handle_get_port_info(struct port_info *pi, const __be64 *rpl)
+{
+ const struct fw_port_cmd *p = (const void *)rpl;
+ struct adapter *adap = pi->adapter;
+
+ /* link/module state change message */
+ int speed = 0, fc = 0;
+ struct link_config *lc;
+ u32 stat = be32_to_cpu(p->u.info.lstatus_to_modtype);
+ int link_ok = (stat & FW_PORT_CMD_LSTATUS_F) != 0;
+ u32 mod = FW_PORT_CMD_MODTYPE_G(stat);
+
+ if (stat & FW_PORT_CMD_RXPAUSE_F)
+ fc |= PAUSE_RX;
+ if (stat & FW_PORT_CMD_TXPAUSE_F)
+ fc |= PAUSE_TX;
+ if (stat & FW_PORT_CMD_LSPEED_V(FW_PORT_CAP_SPEED_100M))
+ speed = 100;
+ else if (stat & FW_PORT_CMD_LSPEED_V(FW_PORT_CAP_SPEED_1G))
+ speed = 1000;
+ else if (stat & FW_PORT_CMD_LSPEED_V(FW_PORT_CAP_SPEED_10G))
+ speed = 10000;
+ else if (stat & FW_PORT_CMD_LSPEED_V(FW_PORT_CAP_SPEED_40G))
+ speed = 40000;
+
+ lc = &pi->link_cfg;
+
+ if (mod != pi->mod_type) {
+ pi->mod_type = mod;
+ t4_os_portmod_changed(adap, pi->port_id);
+ }
+ if (link_ok != lc->link_ok || speed != lc->speed ||
+ fc != lc->fc) { /* something changed */
+ lc->link_ok = link_ok;
+ lc->speed = speed;
+ lc->fc = fc;
+ lc->supported = be16_to_cpu(p->u.info.pcap);
+ t4_os_link_changed(adap, pi->port_id, link_ok);
+ }
+}
+
+/**
+ * t4_handle_fw_rpl - process a FW reply message
+ * @adap: the adapter
+ * @rpl: start of the FW message
+ *
+ * Processes a FW message, such as link state change messages.
*/
int t4_handle_fw_rpl(struct adapter *adap, const __be64 *rpl)
{
u8 opcode = *(const u8 *)rpl;
- if (opcode == FW_PORT_CMD) { /* link/module state change message */
- int speed = 0, fc = 0;
- const struct fw_port_cmd *p = (void *)rpl;
+ /* This might be a port command ... this simplifies the following
+ * conditionals ... We can get away with pre-dereferencing
+ * action_to_len16 because it's in the first 16 bytes and all messages
+ * will be at least that long.
+ */
+ const struct fw_port_cmd *p = (const void *)rpl;
+ unsigned int action =
+ FW_PORT_CMD_ACTION_G(be32_to_cpu(p->action_to_len16));
+
+ if (opcode == FW_PORT_CMD && action == FW_PORT_ACTION_GET_PORT_INFO) {
+ int i;
int chan = FW_PORT_CMD_PORTID_G(be32_to_cpu(p->op_to_portid));
- int port = adap->chan_map[chan];
- struct port_info *pi = adap2pinfo(adap, port);
- struct link_config *lc = &pi->link_cfg;
- u32 stat = be32_to_cpu(p->u.info.lstatus_to_modtype);
- int link_ok = (stat & FW_PORT_CMD_LSTATUS_F) != 0;
- u32 mod = FW_PORT_CMD_MODTYPE_G(stat);
-
- if (stat & FW_PORT_CMD_RXPAUSE_F)
- fc |= PAUSE_RX;
- if (stat & FW_PORT_CMD_TXPAUSE_F)
- fc |= PAUSE_TX;
- if (stat & FW_PORT_CMD_LSPEED_V(FW_PORT_CAP_SPEED_100M))
- speed = 100;
- else if (stat & FW_PORT_CMD_LSPEED_V(FW_PORT_CAP_SPEED_1G))
- speed = 1000;
- else if (stat & FW_PORT_CMD_LSPEED_V(FW_PORT_CAP_SPEED_10G))
- speed = 10000;
- else if (stat & FW_PORT_CMD_LSPEED_V(FW_PORT_CAP_SPEED_40G))
- speed = 40000;
-
- if (link_ok != lc->link_ok || speed != lc->speed ||
- fc != lc->fc) { /* something changed */
- lc->link_ok = link_ok;
- lc->speed = speed;
- lc->fc = fc;
- lc->supported = be16_to_cpu(p->u.info.pcap);
- t4_os_link_changed(adap, port, link_ok);
- }
- if (mod != pi->mod_type) {
- pi->mod_type = mod;
- t4_os_portmod_changed(adap, port);
+ struct port_info *pi = NULL;
+
+ for_each_port(adap, i) {
+ pi = adap2pinfo(adap, i);
+ if (pi->tx_chan == chan)
+ break;
}
+
+ t4_handle_get_port_info(pi, rpl);
+ } else {
+ dev_warn(adap->pdev_dev, "Unknown firmware reply %d\n", opcode);
+ return -EINVAL;
}
return 0;
}
--
2.3.4
^ permalink raw reply related
* [PATCH net-next 8/8] cxgb4: Decode link down reason code obtained from firmware
From: Hariprasad Shenai @ 2016-04-26 14:40 UTC (permalink / raw)
To: davem; +Cc: netdev, leedom, swise, nirranjan, santosh, Hariprasad Shenai
In-Reply-To: <1461681629-28275-1-git-send-email-hariprasad@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 34 +++++++++++++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 5 ++++
3 files changed, 40 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 911fe11d32c6..6af5242e6d21 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -396,6 +396,7 @@ struct link_config {
unsigned char fc; /* actual link flow control */
unsigned char autoneg; /* autonegotiating? */
unsigned char link_ok; /* link up? */
+ unsigned char link_down_rc; /* link down reason */
};
#define FW_LEN16(fw_struct) FW_CMD_LEN16_V(sizeof(fw_struct) / 16)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index cf3efbf4a37a..7907d85efa4c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -7103,6 +7103,32 @@ int t4_ofld_eq_free(struct adapter *adap, unsigned int mbox, unsigned int pf,
}
/**
+ * t4_link_down_rc_str - return a string for a Link Down Reason Code
+ * @adap: the adapter
+ * @link_down_rc: Link Down Reason Code
+ *
+ * Returns a string representation of the Link Down Reason Code.
+ */
+static const char *t4_link_down_rc_str(unsigned char link_down_rc)
+{
+ static const char * const reason[] = {
+ "Link Down",
+ "Remote Fault",
+ "Auto-negotiation Failure",
+ "Reserved",
+ "Insufficient Airflow",
+ "Unable To Determine Reason",
+ "No RX Signal Detected",
+ "Reserved",
+ };
+
+ if (link_down_rc >= ARRAY_SIZE(reason))
+ return "Bad Reason Code";
+
+ return reason[link_down_rc];
+}
+
+/**
* t4_handle_get_port_info - process a FW reply message
* @pi: the port info
* @rpl: start of the FW message
@@ -7142,6 +7168,14 @@ void t4_handle_get_port_info(struct port_info *pi, const __be64 *rpl)
}
if (link_ok != lc->link_ok || speed != lc->speed ||
fc != lc->fc) { /* something changed */
+ if (!link_ok && lc->link_ok) {
+ unsigned char rc = FW_PORT_CMD_LINKDNRC_G(stat);
+
+ lc->link_down_rc = rc;
+ dev_warn(adap->pdev_dev,
+ "Port %d link down, reason: %s\n",
+ pi->port_id, t4_link_down_rc_str(rc));
+ }
lc->link_ok = link_ok;
lc->speed = speed;
lc->fc = fc;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 7ad6d4e75b2a..392d6644fdd8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -2510,6 +2510,11 @@ struct fw_port_cmd {
#define FW_PORT_CMD_PTYPE_G(x) \
(((x) >> FW_PORT_CMD_PTYPE_S) & FW_PORT_CMD_PTYPE_M)
+#define FW_PORT_CMD_LINKDNRC_S 5
+#define FW_PORT_CMD_LINKDNRC_M 0x7
+#define FW_PORT_CMD_LINKDNRC_G(x) \
+ (((x) >> FW_PORT_CMD_LINKDNRC_S) & FW_PORT_CMD_LINKDNRC_M)
+
#define FW_PORT_CMD_MODTYPE_S 0
#define FW_PORT_CMD_MODTYPE_M 0x1f
#define FW_PORT_CMD_MODTYPE_V(x) ((x) << FW_PORT_CMD_MODTYPE_S)
--
2.3.4
^ permalink raw reply related
* [PATCH net-next 5/8] cxgb4: Refactor t4_port_init function
From: Hariprasad Shenai @ 2016-04-26 14:40 UTC (permalink / raw)
To: davem; +Cc: netdev, leedom, swise, nirranjan, santosh, Hariprasad Shenai
In-Reply-To: <1461681629-28275-1-git-send-email-hariprasad@chelsio.com>
Refactor t4_port_init() so that the core functionality is done by
t4_init_portinfo() for a particular port. Also rename variables to
sensible ones.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 2 +
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 93 +++++++++++++++++-------------
2 files changed, 55 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 459775884cad..f69119bc5990 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1333,6 +1333,8 @@ int t4_init_sge_params(struct adapter *adapter);
int t4_init_tp_params(struct adapter *adap);
int t4_filter_field_shift(const struct adapter *adap, int filter_sel);
int t4_init_rss_mode(struct adapter *adap, int mbox);
+int t4_init_portinfo(struct port_info *pi, int mbox,
+ int port, int pf, int vf, u8 mac[]);
int t4_port_init(struct adapter *adap, int mbox, int pf, int vf);
void t4_fatal_err(struct adapter *adapter);
int t4_config_rss_range(struct adapter *adapter, int mbox, unsigned int viid,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 2ced24fc569d..1ebbbb9323e3 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -7668,61 +7668,74 @@ int t4_init_rss_mode(struct adapter *adap, int mbox)
return 0;
}
-int t4_port_init(struct adapter *adap, int mbox, int pf, int vf)
+/**
+ * t4_init_portinfo - allocate a virtual interface amd initialize port_info
+ * @pi: the port_info
+ * @mbox: mailbox to use for the FW command
+ * @port: physical port associated with the VI
+ * @pf: the PF owning the VI
+ * @vf: the VF owning the VI
+ * @mac: the MAC address of the VI
+ *
+ * Allocates a virtual interface for the given physical port. If @mac is
+ * not %NULL it contains the MAC address of the VI as assigned by FW.
+ * @mac should be large enough to hold an Ethernet address.
+ * Returns < 0 on error.
+ */
+int t4_init_portinfo(struct port_info *pi, int mbox,
+ int port, int pf, int vf, u8 mac[])
{
- u8 addr[6];
- int ret, i, j = 0;
+ int ret;
struct fw_port_cmd c;
- struct fw_rss_vi_config_cmd rvc;
+ unsigned int rss_size;
memset(&c, 0, sizeof(c));
- memset(&rvc, 0, sizeof(rvc));
+ c.op_to_portid = cpu_to_be32(FW_CMD_OP_V(FW_PORT_CMD) |
+ FW_CMD_REQUEST_F | FW_CMD_READ_F |
+ FW_PORT_CMD_PORTID_V(port));
+ c.action_to_len16 = cpu_to_be32(
+ FW_PORT_CMD_ACTION_V(FW_PORT_ACTION_GET_PORT_INFO) |
+ FW_LEN16(c));
+ ret = t4_wr_mbox(pi->adapter, mbox, &c, sizeof(c), &c);
+ if (ret)
+ return ret;
+
+ ret = t4_alloc_vi(pi->adapter, mbox, port, pf, vf, 1, mac, &rss_size);
+ if (ret < 0)
+ return ret;
+
+ pi->viid = ret;
+ pi->tx_chan = port;
+ pi->lport = port;
+ pi->rss_size = rss_size;
+
+ ret = be32_to_cpu(c.u.info.lstatus_to_modtype);
+ pi->mdio_addr = (ret & FW_PORT_CMD_MDIOCAP_F) ?
+ FW_PORT_CMD_MDIOADDR_G(ret) : -1;
+ pi->port_type = FW_PORT_CMD_PTYPE_G(ret);
+ pi->mod_type = FW_PORT_MOD_TYPE_NA;
+
+ init_link_config(&pi->link_cfg, be16_to_cpu(c.u.info.pcap));
+ return 0;
+}
+
+int t4_port_init(struct adapter *adap, int mbox, int pf, int vf)
+{
+ u8 addr[6];
+ int ret, i, j = 0;
for_each_port(adap, i) {
- unsigned int rss_size;
- struct port_info *p = adap2pinfo(adap, i);
+ struct port_info *pi = adap2pinfo(adap, i);
while ((adap->params.portvec & (1 << j)) == 0)
j++;
- c.op_to_portid = cpu_to_be32(FW_CMD_OP_V(FW_PORT_CMD) |
- FW_CMD_REQUEST_F | FW_CMD_READ_F |
- FW_PORT_CMD_PORTID_V(j));
- c.action_to_len16 = cpu_to_be32(
- FW_PORT_CMD_ACTION_V(FW_PORT_ACTION_GET_PORT_INFO) |
- FW_LEN16(c));
- ret = t4_wr_mbox(adap, mbox, &c, sizeof(c), &c);
+ ret = t4_init_portinfo(pi, mbox, j, pf, vf, addr);
if (ret)
return ret;
- ret = t4_alloc_vi(adap, mbox, j, pf, vf, 1, addr, &rss_size);
- if (ret < 0)
- return ret;
-
- p->viid = ret;
- p->tx_chan = j;
- p->lport = j;
- p->rss_size = rss_size;
memcpy(adap->port[i]->dev_addr, addr, ETH_ALEN);
adap->port[i]->dev_port = j;
-
- ret = be32_to_cpu(c.u.info.lstatus_to_modtype);
- p->mdio_addr = (ret & FW_PORT_CMD_MDIOCAP_F) ?
- FW_PORT_CMD_MDIOADDR_G(ret) : -1;
- p->port_type = FW_PORT_CMD_PTYPE_G(ret);
- p->mod_type = FW_PORT_MOD_TYPE_NA;
-
- rvc.op_to_viid =
- cpu_to_be32(FW_CMD_OP_V(FW_RSS_VI_CONFIG_CMD) |
- FW_CMD_REQUEST_F | FW_CMD_READ_F |
- FW_RSS_VI_CONFIG_CMD_VIID(p->viid));
- rvc.retval_len16 = cpu_to_be32(FW_LEN16(rvc));
- ret = t4_wr_mbox(adap, mbox, &rvc, sizeof(rvc), &rvc);
- if (ret)
- return ret;
- p->rss_mode = be32_to_cpu(rvc.u.basicvirtual.defaultq_to_udpen);
-
- init_link_config(&p->link_cfg, be16_to_cpu(c.u.info.pcap));
j++;
}
return 0;
--
2.3.4
^ permalink raw reply related
* [PATCH net-next 4/8] cxgb4: Properly decode port module type
From: Hariprasad Shenai @ 2016-04-26 14:40 UTC (permalink / raw)
To: davem; +Cc: netdev, leedom, swise, nirranjan, santosh, Hariprasad Shenai
In-Reply-To: <1461681629-28275-1-git-send-email-hariprasad@chelsio.com>
Decode and log port module error, unknown modules and unsupported
modules.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index b8dc7921b258..abc425bfc744 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -337,6 +337,17 @@ void t4_os_portmod_changed(const struct adapter *adap, int port_id)
netdev_info(dev, "port module unplugged\n");
else if (pi->mod_type < ARRAY_SIZE(mod_str))
netdev_info(dev, "%s module inserted\n", mod_str[pi->mod_type]);
+ else if (pi->mod_type == FW_PORT_MOD_TYPE_NOTSUPPORTED)
+ netdev_info(dev, "%s: unsupported port module inserted\n",
+ dev->name);
+ else if (pi->mod_type == FW_PORT_MOD_TYPE_UNKNOWN)
+ netdev_info(dev, "%s: unknown port module inserted\n",
+ dev->name);
+ else if (pi->mod_type == FW_PORT_MOD_TYPE_ERROR)
+ netdev_info(dev, "%s: transceiver module error\n", dev->name);
+ else
+ netdev_info(dev, "%s: unknown module type %d inserted\n",
+ dev->name, pi->mod_type);
}
int dbfifo_int_thresh = 10; /* 10 == 640 entry threshold */
--
2.3.4
^ permalink raw reply related
* [PATCH net-next 3/8] cxgb4: Avoids race and deadlock while freeing tx descriptor
From: Hariprasad Shenai @ 2016-04-26 14:40 UTC (permalink / raw)
To: davem; +Cc: netdev, leedom, swise, nirranjan, santosh, Hariprasad Shenai
In-Reply-To: <1461681629-28275-1-git-send-email-hariprasad@chelsio.com>
There could be race between t4_eth_xmit() and t4_free_sge_resources() while
freeing tx descriptors, take txq lock in t4_free_sge_resources(). We need
to stop the xmit frame path which runs in bottom half context while
unloading the driver using _bh variant of the lock. This is to prevent
the deadlock between xmit and driver unload.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 6278e5a74b74..bad253beb8c8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -3006,7 +3006,9 @@ void t4_free_sge_resources(struct adapter *adap)
if (etq->q.desc) {
t4_eth_eq_free(adap, adap->mbox, adap->pf, 0,
etq->q.cntxt_id);
+ __netif_tx_lock_bh(etq->txq);
free_tx_desc(adap, &etq->q, etq->q.in_use, true);
+ __netif_tx_unlock_bh(etq->txq);
kfree(etq->q.sdesc);
free_txq(adap, &etq->q);
}
--
2.3.4
^ permalink raw reply related
* [PATCH net-next 2/8] cxgb4: Add llseek operation for flash debugfs entry
From: Hariprasad Shenai @ 2016-04-26 14:40 UTC (permalink / raw)
To: davem; +Cc: netdev, leedom, swise, nirranjan, santosh, Hariprasad Shenai
In-Reply-To: <1461681629-28275-1-git-send-email-hariprasad@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 0bb41e9b9b1c..9506c5cd11b9 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -1572,6 +1572,7 @@ static const struct file_operations flash_debugfs_fops = {
.owner = THIS_MODULE,
.open = mem_open,
.read = flash_read,
+ .llseek = default_llseek,
};
static inline void tcamxy2valmask(u64 x, u64 y, u8 *addr, u64 *mask)
--
2.3.4
^ permalink raw reply related
* [PATCH net-next 1/8] cxgb4: add new routine to get adapter info
From: Hariprasad Shenai @ 2016-04-26 14:40 UTC (permalink / raw)
To: davem; +Cc: netdev, leedom, swise, nirranjan, santosh, Hariprasad Shenai
In-Reply-To: <1461681629-28275-1-git-send-email-hariprasad@chelsio.com>
Add new routine to print out general adapter information (various version
numbers, adapter name, part number, serial number, etc.) and remove
redundant information dumped in the Port Information.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 4 ++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 78 ++++++++++++++++++++++---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 14 +++++
drivers/net/ethernet/chelsio/cxgb4/t4_hw.h | 7 +++
4 files changed, 95 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 326d4009525e..459775884cad 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -324,7 +324,9 @@ struct adapter_params {
unsigned int sf_fw_start; /* start of FW image in flash */
unsigned int fw_vers;
+ unsigned int bs_vers; /* bootstrap version */
unsigned int tp_vers;
+ unsigned int er_vers; /* expansion ROM version */
u8 api_vers[7];
unsigned short mtus[NMTUS];
@@ -731,6 +733,7 @@ struct adapter {
u32 t4_bar0;
struct pci_dev *pdev;
struct device *pdev_dev;
+ const char *name;
unsigned int mbox;
unsigned int pf;
unsigned int flags;
@@ -1306,6 +1309,7 @@ int t4_fl_pkt_align(struct adapter *adap);
unsigned int t4_flash_cfg_addr(struct adapter *adapter);
int t4_check_fw_version(struct adapter *adap);
int t4_get_fw_version(struct adapter *adapter, u32 *vers);
+int t4_get_bs_version(struct adapter *adapter, u32 *vers);
int t4_get_tp_version(struct adapter *adapter, u32 *vers);
int t4_get_exprom_version(struct adapter *adapter, u32 *vers);
int t4_prep_fw(struct adapter *adap, struct fw_info *fw_info,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index a1e329ec24cd..b8dc7921b258 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3738,7 +3738,10 @@ static int adap_init0(struct adapter *adap)
* is excessively mismatched relative to the driver.)
*/
t4_get_fw_version(adap, &adap->params.fw_vers);
+ t4_get_bs_version(adap, &adap->params.bs_vers);
t4_get_tp_version(adap, &adap->params.tp_vers);
+ t4_get_exprom_version(adap, &adap->params.er_vers);
+
ret = t4_check_fw_version(adap);
/* If firmware is too old (not supported by driver) force an update. */
if (ret)
@@ -4652,6 +4655,68 @@ static void cxgb4_check_pcie_caps(struct adapter *adap)
"suggested for optimal performance.\n");
}
+/* Dump basic information about the adapter */
+static void print_adapter_info(struct adapter *adapter)
+{
+ /* Device information */
+ dev_info(adapter->pdev_dev, "Chelsio %s rev %d\n",
+ adapter->params.vpd.id,
+ CHELSIO_CHIP_RELEASE(adapter->params.chip));
+ dev_info(adapter->pdev_dev, "S/N: %s, P/N: %s\n",
+ adapter->params.vpd.sn, adapter->params.vpd.pn);
+
+ /* Firmware Version */
+ if (!adapter->params.fw_vers)
+ dev_warn(adapter->pdev_dev, "No firmware loaded\n");
+ else
+ dev_info(adapter->pdev_dev, "Firmware version: %u.%u.%u.%u\n",
+ FW_HDR_FW_VER_MAJOR_G(adapter->params.fw_vers),
+ FW_HDR_FW_VER_MINOR_G(adapter->params.fw_vers),
+ FW_HDR_FW_VER_MICRO_G(adapter->params.fw_vers),
+ FW_HDR_FW_VER_BUILD_G(adapter->params.fw_vers));
+
+ /* Bootstrap Firmware Version. (Some adapters don't have Bootstrap
+ * Firmware, so dev_info() is more appropriate here.)
+ */
+ if (!adapter->params.bs_vers)
+ dev_info(adapter->pdev_dev, "No bootstrap loaded\n");
+ else
+ dev_info(adapter->pdev_dev, "Bootstrap version: %u.%u.%u.%u\n",
+ FW_HDR_FW_VER_MAJOR_G(adapter->params.bs_vers),
+ FW_HDR_FW_VER_MINOR_G(adapter->params.bs_vers),
+ FW_HDR_FW_VER_MICRO_G(adapter->params.bs_vers),
+ FW_HDR_FW_VER_BUILD_G(adapter->params.bs_vers));
+
+ /* TP Microcode Version */
+ if (!adapter->params.tp_vers)
+ dev_warn(adapter->pdev_dev, "No TP Microcode loaded\n");
+ else
+ dev_info(adapter->pdev_dev,
+ "TP Microcode version: %u.%u.%u.%u\n",
+ FW_HDR_FW_VER_MAJOR_G(adapter->params.tp_vers),
+ FW_HDR_FW_VER_MINOR_G(adapter->params.tp_vers),
+ FW_HDR_FW_VER_MICRO_G(adapter->params.tp_vers),
+ FW_HDR_FW_VER_BUILD_G(adapter->params.tp_vers));
+
+ /* Expansion ROM version */
+ if (!adapter->params.er_vers)
+ dev_info(adapter->pdev_dev, "No Expansion ROM loaded\n");
+ else
+ dev_info(adapter->pdev_dev,
+ "Expansion ROM version: %u.%u.%u.%u\n",
+ FW_HDR_FW_VER_MAJOR_G(adapter->params.er_vers),
+ FW_HDR_FW_VER_MINOR_G(adapter->params.er_vers),
+ FW_HDR_FW_VER_MICRO_G(adapter->params.er_vers),
+ FW_HDR_FW_VER_BUILD_G(adapter->params.er_vers));
+
+ /* Software/Hardware configuration */
+ dev_info(adapter->pdev_dev, "Configuration: %sNIC %s, %s capable\n",
+ is_offload(adapter) ? "R" : "",
+ ((adapter->flags & USING_MSIX) ? "MSI-X" :
+ (adapter->flags & USING_MSI) ? "MSI" : ""),
+ is_offload(adapter) ? "Offload" : "non-Offload");
+}
+
static void print_port_info(const struct net_device *dev)
{
char buf[80];
@@ -4679,14 +4744,8 @@ static void print_port_info(const struct net_device *dev)
--bufp;
sprintf(bufp, "BASE-%s", t4_get_port_type_description(pi->port_type));
- netdev_info(dev, "Chelsio %s rev %d %s %sNIC %s\n",
- adap->params.vpd.id,
- CHELSIO_CHIP_RELEASE(adap->params.chip), buf,
- is_offload(adap) ? "R" : "",
- (adap->flags & USING_MSIX) ? " MSI-X" :
- (adap->flags & USING_MSI) ? " MSI" : "");
- netdev_info(dev, "S/N: %s, P/N: %s\n",
- adap->params.vpd.sn, adap->params.vpd.pn);
+ netdev_info(dev, "%s: Chelsio %s (%s) %s\n",
+ dev->name, adap->params.vpd.id, adap->name, buf);
}
static void enable_pcie_relaxed_ordering(struct pci_dev *dev)
@@ -4844,6 +4903,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
adapter->regs = regs;
adapter->pdev = pdev;
adapter->pdev_dev = &pdev->dev;
+ adapter->name = pci_name(pdev);
adapter->mbox = func;
adapter->pf = func;
adapter->msg_enable = dflt_msg_enable;
@@ -5074,6 +5134,8 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (is_offload(adapter))
attach_ulds(adapter);
+ print_adapter_info(adapter);
+
sriov:
#ifdef CONFIG_PCI_IOV
if (func < ARRAY_SIZE(num_vf) && num_vf[func] > 0)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 71586a3e0f61..2ced24fc569d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -2937,6 +2937,20 @@ int t4_get_fw_version(struct adapter *adapter, u32 *vers)
}
/**
+ * t4_get_bs_version - read the firmware bootstrap version
+ * @adapter: the adapter
+ * @vers: where to place the version
+ *
+ * Reads the FW Bootstrap version from flash.
+ */
+int t4_get_bs_version(struct adapter *adapter, u32 *vers)
+{
+ return t4_read_flash(adapter, FLASH_FWBOOTSTRAP_START +
+ offsetof(struct fw_hdr, fw_ver), 1,
+ vers, 0);
+}
+
+/**
* t4_get_tp_version - read the TP microcode version
* @adapter: the adapter
* @vers: where to place the version
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.h b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.h
index 2fc60e83a7a1..7f59ca458431 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.h
@@ -220,6 +220,13 @@ enum {
FLASH_FW_START = FLASH_START(FLASH_FW_START_SEC),
FLASH_FW_MAX_SIZE = FLASH_MAX_SIZE(FLASH_FW_NSECS),
+ /* Location of bootstrap firmware image in FLASH.
+ */
+ FLASH_FWBOOTSTRAP_START_SEC = 27,
+ FLASH_FWBOOTSTRAP_NSECS = 1,
+ FLASH_FWBOOTSTRAP_START = FLASH_START(FLASH_FWBOOTSTRAP_START_SEC),
+ FLASH_FWBOOTSTRAP_MAX_SIZE = FLASH_MAX_SIZE(FLASH_FWBOOTSTRAP_NSECS),
+
/*
* iSCSI persistent/crash information.
*/
--
2.3.4
^ permalink raw reply related
* [PATCH net-next 0/8] cxgb4: minor fixes, decode msgs and code refactor for few functions
From: Hariprasad Shenai @ 2016-04-26 14:40 UTC (permalink / raw)
To: davem; +Cc: netdev, leedom, swise, nirranjan, santosh, Hariprasad Shenai
Hi
This patch series adds new routine to get adapter information and removes
some redundant messages logged in dmesg. Fixes race while freeing tx
descriptors. Decodes module type and link down reason codes obtained from
firmware. Refactor port initialization and FW_PORT_CMD handling. Pass
correct port id in DCB message handler to obtain netdev associated.
This patch series has been created against net-next tree and includes
patches on cxgb4 driver.
We have included all the maintainers of respective drivers. Kindly review
the change and let us know in case of any review comments.
Thanks
Hariprasad Shenai (8):
cxgb4: add new routine to get adapter info
cxgb4: Add llseek operation for flash debugfs entry
cxgb4: Avoids race and deadlock while freeing tx descriptor
cxgb4: Properly decode port module type
cxgb4: Refactor t4_port_init function
cxgb4: DCB message handler needs to use correct portid to netdev
mapping
cxgb4: Don't assume FW_PORT_CMD reply is always port info msg
cxgb4: Decode link down reason code obtained from firmware
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 8 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 94 +++++++-
drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 249 ++++++++++++++-------
drivers/net/ethernet/chelsio/cxgb4/t4_hw.h | 7 +
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 5 +
8 files changed, 281 insertions(+), 87 deletions(-)
--
2.3.4
^ permalink raw reply
* Re: [net-next PATCH 4/4] samples/bpf: allow make to be run from samples/bpf/ directory
From: Alexei Starovoitov @ 2016-04-26 14:35 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, bblanco, borkmann, linux-kbuild
In-Reply-To: <20160426110932.20716.51360.stgit@firesoul>
On Tue, Apr 26, 2016 at 01:09:32PM +0200, Jesper Dangaard Brouer wrote:
> It is not intuitive that 'make' must be run from the top level
> directory with argument "samples/bpf/" to compile these eBPF samples.
>
> Introduce a kbuild make file trick that allow make to be run from the
> "samples/bpf/" directory itself. It basically change to the top level
> directory and call "make samples/bpf/" with the "/" slash after the
> directory name.
>
> Also add a clean target that only cleans this directory, by taking
> advantage of the kbuild external module setting M=$PWD.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> samples/bpf/Makefile | 8 ++++++++
> samples/bpf/README.rst | 3 +++
> 2 files changed, 11 insertions(+)
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 7ac66f5bbbf5..7370dfee482f 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -85,6 +85,14 @@ HOSTLOADLIBES_test_overhead += -lelf -lrt
> # make samples/bpf/ LLC=~/git/llvm/build/bin/llc
> LLC ?= llc
>
> +# Trick to allow make to be run from this directory
> +all:
> + $(MAKE) -C ../../ $$PWD/
> +
> +clean:
> + $(MAKE) -C ../../ M=$$PWD clean
> + @rm -f *~
> +
nice trick!
^ permalink raw reply
* Re: [net-next PATCH 3/4] samples/bpf: add a README file to get users started
From: Alexei Starovoitov @ 2016-04-26 14:34 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jesper Dangaard Brouer, netdev, bblanco, borkmann, linux-kbuild
In-Reply-To: <571F61D6.50101@iogearbox.net>
On Tue, Apr 26, 2016 at 02:40:54PM +0200, Daniel Borkmann wrote:
> On 04/26/2016 01:56 PM, Jesper Dangaard Brouer wrote:
> >>>+Compiling requires having installed:
> >>>+ * clang
> >>>+ * llvm >= version 3.7.0
please change it to 3.7.1, since 3.7.0 had several bugs.
They're rare, but better to avoid the issue.
> >>>+
> >>>+Note that LLVM's tool 'llc' must support target 'bpf', list with command::
> >>>+
> >>>+ $ llc --version
> >>>+ LLVM (http://llvm.org/):
> >>>+ LLVM version 3.x.y
> >>>+ [...]
> >>>+ Host CPU: xxx
> >>>+
> >>>+ Registered Targets:
> >>>+ [...]
> >>>+ bpf - BPF (host endian)
> >>>+ bpfeb - BPF (big endian)
> >>>+ bpfel - BPF (little endian)
there always be 3 targets for bpf, since some folks need to cross-compile.
> >>>+Manually compiling LLVM with 'bpf' support
> >>>+------------------------------------------
> >>>+
> >>>+In some LLVM versions the BPF target were marked experimental. To
> >>>+compile LLVM manually and enable BPF target run (build dependencies
> >>>+are cmake and gcc-c++)::
> >>>+
> >>>+ $ git clone http://llvm.org/git/llvm.git
> >>>+ $ cd llvm
> >>>+ $ mkdir build; cd build
> >>>+ $ cmake .. -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF
> >>>+ $ make
> >>
> >>That's perhaps a bit misleading in the sense that when you clone the
> >>tree from git, you'd nowadays invoke cmake normally with LLVM_TARGETS_TO_BUILD
> >>instead of LLVM_EXPERIMENTAL_TARGETS_TO_BUILD for BPF, as BPF is not an
> >>experimental target anymore. It's probably also recommended to clone
> >>clang into tools/ dir as well under your llvm/ repo when you compile
> >>from scratch anyways.
yes. LLVM_EXPERIMENTAL_TARGETS_TO_BUILD is the thing of the past
when bpf was just merged into llvm < 3.7
By default llvm will build all non-experimental backends including bpf.
If you need to make llc binary smaller you can use:
-DLLVM_TARGETS_TO_BUILD="BPF;X86"
Also fedora and ubuntu ship with llvm that has bpf support.
> >Can you come up with a formulation/desc I can use instead then?
>
> You mean how to build with clang? There are various docs/snippets out
> there, for example, see the 'Build LLVM and Clang development libs'
> part of [1], that you can tweak for your README with.
>
> [1] https://gist.github.com/brendangregg/cfa482acb71aa577789c
yep. +1 for the link.
^ permalink raw reply
* Re: [PATCH v5 09/21] IB/hns: Add hca support
From: Jiri Pirko @ 2016-04-26 14:25 UTC (permalink / raw)
To: Leon Romanovsky
Cc: oulijun, dledford, sean.hefty, hal.rosenstock, davem,
jeffrey.t.kirsher, jiri, ogerlitz, linuxarm, linux-rdma,
linux-kernel, netdev, gongyangming, xiaokun, tangchaofei,
haifeng.wei, yisen.zhuang, yankejian, lisheng011, charles.chenxin
In-Reply-To: <20160426141821.GJ7974@leon.nu>
Tue, Apr 26, 2016 at 04:18:21PM CEST, leon@kernel.org wrote:
>On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote:
>> On 2016/4/24 15:54, Leon Romanovsky wrote:
<snip>
>> >> +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
>> >> +{
>> >> + int ret = 0;
>> >> +
>> >> + spin_lock(&bitmap->lock);
>> >> + *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
>> >> + if (*obj >= bitmap->max) {
>> >> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
>> >> + & bitmap->mask;
>> >> + *obj = find_first_zero_bit(bitmap->table, bitmap->max);
>> >
>> > find_first_zero_bit function returns "unsigned long" which may or may
>> > not be equal to u32 on some architectures.
>> >
>> Hi Leon,
>> I appreciate your keen eye. this code is meant for ARM64bit therefore should run corretly for 64-bit AARCH64.
The driver should run correctly on any arch.
>> I will consider changing it as part of good partice and better portability "
>> I will give a primary plan to modified it.
>> for example:
>> *obj = (u32)find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
>> Beause the max size of bitmap->table is u32 in current version.
>>
>> int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num, u32 mask,
>> u32 reserved_bot, u32 reserved_top)
>> {
>> u32 i;
>>
>> if (num != roundup_pow_of_two(num))
>> return -EINVAL;
>>
>> bitmap->last = 0;
>> bitmap->top = 0;
>> bitmap->max = num - reserved_top;
>> bitmap->mask = mask;
>> bitmap->reserved_top = reserved_top;
>> spin_lock_init(&bitmap->lock);
>> bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
>> GFP_KERNEL);
>>
>> Is this plan ok?
>
>No,
>You are submitting new driver, please do it properly (without casting)
>from the beginning.
>
>>
>> Thanks
>> Lijun Ou
>>
>> --
>> 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
^ permalink raw reply
* Re: [PATCH v5 09/21] IB/hns: Add hca support
From: Leon Romanovsky @ 2016-04-26 14:18 UTC (permalink / raw)
To: oulijun
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w,
jiri-VPRAkNaXOzVWk0Htik3J/w, ogerlitz-VPRAkNaXOzVWk0Htik3J/w,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
gongyangming-hv44wF8Li93QT0dZR+AlfA,
xiaokun-hv44wF8Li93QT0dZR+AlfA,
tangchaofei-hv44wF8Li93QT0dZR+AlfA,
haifeng.wei-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
lisheng011-hv44wF8Li93QT0dZR+AlfA,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <571F0C04.2010005-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4292 bytes --]
On Tue, Apr 26, 2016 at 02:34:44PM +0800, oulijun wrote:
> On 2016/4/24 15:54, Leon Romanovsky wrote:
> > On Sat, Apr 23, 2016 at 06:26:47PM +0800, Lijun Ou wrote:
> >> This patch mainly setup hca for RoCE. it will do a series of
> >> initial works as follows:
> >> 1. init uar table, allocate uar resource
> >> 2. init pd table
> >> 3. init cq table
> >> 4. init mr table
> >> 5. init qp table
> >>
> >> Signed-off-by: Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >> Signed-off-by: Wei Hu(Xavier) <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >> ---
> >> drivers/infiniband/hw/hns/hns_roce_alloc.c | 104 ++++++++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_cq.c | 25 ++++
> >> drivers/infiniband/hw/hns/hns_roce_device.h | 69 ++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_eq.c | 1 -
> >> drivers/infiniband/hw/hns/hns_roce_icm.c | 88 +++++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_icm.h | 9 ++
> >> drivers/infiniband/hw/hns/hns_roce_main.c | 79 ++++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_mr.c | 187 ++++++++++++++++++++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_pd.c | 65 ++++++++++
> >> drivers/infiniband/hw/hns/hns_roce_qp.c | 30 +++++
> >> 10 files changed, 656 insertions(+), 1 deletion(-)
> >> create mode 100644 drivers/infiniband/hw/hns/hns_roce_alloc.c
> >> create mode 100644 drivers/infiniband/hw/hns/hns_roce_mr.c
> >> create mode 100644 drivers/infiniband/hw/hns/hns_roce_pd.c
> >>
> >> diff --git a/drivers/infiniband/hw/hns/hns_roce_alloc.c b/drivers/infiniband/hw/hns/hns_roce_alloc.c
> >> new file mode 100644
> >> index 0000000..0c76f1b
> >> --- /dev/null
> >> +++ b/drivers/infiniband/hw/hns/hns_roce_alloc.c
> >> @@ -0,0 +1,104 @@
> >> +/*
> >> + * Copyright (c) 2016 Hisilicon Limited.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License as published by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + */
> >> +
> >> +#include <linux/bitmap.h>
> >> +#include <linux/dma-mapping.h>
> >> +#include <linux/errno.h>
> >> +#include <linux/mm.h>
> >> +#include <linux/slab.h>
> >> +#include <linux/vmalloc.h>
> >> +#include "hns_roce_device.h"
> >> +
> >> +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
> >> +{
> >> + int ret = 0;
> >> +
> >> + spin_lock(&bitmap->lock);
> >> + *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
> >> + if (*obj >= bitmap->max) {
> >> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> >> + & bitmap->mask;
> >> + *obj = find_first_zero_bit(bitmap->table, bitmap->max);
> >
> > find_first_zero_bit function returns "unsigned long" which may or may
> > not be equal to u32 on some architectures.
> >
> Hi Leon,
> I appreciate your keen eye. this code is meant for ARM64bit therefore should run corretly for 64-bit AARCH64.
> I will consider changing it as part of good partice and better portability "
> I will give a primary plan to modified it.
> for example:
> *obj = (u32)find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
> Beause the max size of bitmap->table is u32 in current version.
>
> int hns_roce_bitmap_init(struct hns_roce_bitmap *bitmap, u32 num, u32 mask,
> u32 reserved_bot, u32 reserved_top)
> {
> u32 i;
>
> if (num != roundup_pow_of_two(num))
> return -EINVAL;
>
> bitmap->last = 0;
> bitmap->top = 0;
> bitmap->max = num - reserved_top;
> bitmap->mask = mask;
> bitmap->reserved_top = reserved_top;
> spin_lock_init(&bitmap->lock);
> bitmap->table = kcalloc(BITS_TO_LONGS(bitmap->max), sizeof(long),
> GFP_KERNEL);
>
> Is this plan ok?
No,
You are submitting new driver, please do it properly (without casting)
from the beginning.
>
> Thanks
> Lijun Ou
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] ip: add udp_csum, udp6_csum_tx, udp6_csum_rx control flags to ip l2tp add tunnel
From: Wang Shanker @ 2016-04-26 14:15 UTC (permalink / raw)
To: netdev
Hi, all
It’s my first time to contribute to such an important open source project. Things began when I upgraded my server, called "Server A", form ubuntu 14.04 to 16.04, which is shipped with new kernel version, 4.4. After upgrade, I soon found a l2tp tunnel between this server and another linux server, called "Server B", via ipv6 broke down. Here is the network topology:
+----------+ +----------+
| Server A | -- IPV6 Network -- | Server B |
+----------+ +----------+
The l2tp tunnel was encapsulated in udp datagrams. All the configuration was normal and could work after I reverted the kernel on Server A to original version.
Here is what i did to create the tunnel:
```
on Server A:
ip l2tp add tunnel tunnel_id 86 peer_tunnel_id 86 remote 2001:db8::aaaa local 2001:db8::bbbb udp_sport 1086 udp_dport 1086
ip l2tp add session name l2tpeth0 tunnel_id 86 session_id 86 peer_session_id 86
ip l s l2tpeth0 up
on Server B:
ip l2tp add tunnel tunnel_id 86 peer_tunnel_id 86 local 2001:db8::aaaa remote 2001:db8::bbbb udp_sport 1086 udp_dport 1086
ip l2tp add session name l2tpeth0 tunnel_id 86 session_id 86 peer_session_id 86
ip l s l2tpeth0 up
```
When I used tcpdump to diagnose the problem, I got such result:
```
on Server A:
arping -i l2tpeth0 -0 1.2.3.4
on Server B:
tcpdump -i eth0 -n port 1086 -v
21:35:57.818810 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [bad udp cksum 0x0000 -> 0x1140!] UDP, length 54
21:35:58.820572 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [bad udp cksum 0x0000 -> 0x1140!] UDP, length 54
21:35:59.822216 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [bad udp cksum 0x0000 -> 0x1140!] UDP, length 54
```
After looking into kernel source, I found out that in this commit a new feature to set udp6 checksum to zero in commit 6b649fe, which added `L2TP_ATTR_UDP_ZERO_CSUM6_TX` and `L2TP_ATTR_UDP_ZERO_CSUM6_TX`.
As a result, I added `udp_csum`, `udp6_csum_tx`, `udp6_csum_rx` control flags to `ip l2tp add tunnel` to control those attributes about checksum.
Using this to create the tunnel instead on Server A:
```
ip l2tp add tunnel tunnel_id 86 peer_tunnel_id 86 remote 2001:db8::aaaa local 2001:db8::bbbb udp_sport 1086 udp_dport 1086 udp6_csum_tx on udp6_csum_rx on
```
I finally got:
```
on Server A:
arping -i l2tpeth0 -0 1.2.3.4
on Server B:
tcpdump -i eth0 -n port 1086 -v
22:07:03.844297 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [udp sum ok] UDP, length 54
22:07:04.845717 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [udp sum ok] UDP, length 54
22:07:05.847965 IP6 (flowlabel 0x8f028, hlim 64, next-header UDP (17) payload length: 62) 2001:db8::aaaa.1086 > 2001:db8::bbbb.1086: [udp sum ok] UDP, length 54
tcpdump -i l2tpeth0 -v
22:10:35.691326 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.2.3.4 tell 0.0.0.0, length 28
22:10:36.693627 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.2.3.4 tell 0.0.0.0, length 28
22:10:37.695010 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.2.3.4 tell 0.0.0.0, length 28
22:10:38.697121 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 1.2.3.4 tell 0.0.0.0, length 28
```
It seems to work. However, is it the real point that should be fixed and does my patch fix it well? I need your suggestion.
---
ip/ipl2tp.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/ip/ipl2tp.c b/ip/ipl2tp.c
index 3c8ee93..67a6482 100644
--- a/ip/ipl2tp.c
+++ b/ip/ipl2tp.c
@@ -56,6 +56,8 @@ struct l2tp_parm {
uint16_t pw_type;
uint16_t mtu;
+ int udp6_csum_tx:1;
+ int udp6_csum_rx:1;
int udp_csum:1;
int recv_seq:1;
int send_seq:1;
@@ -117,6 +119,9 @@ static int create_tunnel(struct l2tp_parm *p)
if (p->encap == L2TP_ENCAPTYPE_UDP) {
addattr16(&req.n, 1024, L2TP_ATTR_UDP_SPORT, p->local_udp_port);
addattr16(&req.n, 1024, L2TP_ATTR_UDP_DPORT, p->peer_udp_port);
+ addattr8 (&req.n, 1024, L2TP_ATTR_UDP_CSUM, p->udp_csum);
+ addattr8 (&req.n, 1024, L2TP_ATTR_UDP_ZERO_CSUM6_TX, p->udp6_csum_tx);
+ addattr8 (&req.n, 1024, L2TP_ATTR_UDP_ZERO_CSUM6_RX, p->udp6_csum_rx);
}
if (rtnl_talk(&genl_rth, &req.n, NULL, 0) < 0)
@@ -282,6 +287,14 @@ static int get_response(struct nlmsghdr *n, void *arg)
p->l2spec_len = rta_getattr_u8(attrs[L2TP_ATTR_L2SPEC_LEN]);
p->udp_csum = !!attrs[L2TP_ATTR_UDP_CSUM];
+ if (attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX])
+ p->udp6_csum_tx = rta_getattr_u8(attrs[L2TP_ATTR_UDP_ZERO_CSUM6_TX]);
+ else
+ p->udp6_csum_tx = 1;
+ if (attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX])
+ p->udp6_csum_rx = rta_getattr_u8(attrs[L2TP_ATTR_UDP_ZERO_CSUM6_RX]);
+ else
+ p->udp6_csum_rx = 1;
if (attrs[L2TP_ATTR_COOKIE])
memcpy(p->cookie, RTA_DATA(attrs[L2TP_ATTR_COOKIE]),
p->cookie_len = RTA_PAYLOAD(attrs[L2TP_ATTR_COOKIE]));
@@ -470,6 +483,9 @@ static void usage(void)
fprintf(stderr, " tunnel_id ID peer_tunnel_id ID\n");
fprintf(stderr, " [ encap { ip | udp } ]\n");
fprintf(stderr, " [ udp_sport PORT ] [ udp_dport PORT ]\n");
+ fprintf(stderr, " [ udp_csum { on | off } ]\n");
+ fprintf(stderr, " [ udp6_csum_tx { on | off } ]\n");
+ fprintf(stderr, " [ udp6_csum_rx { on | off } ]\n");
fprintf(stderr, "Usage: ip l2tp add session [ name NAME ]\n");
fprintf(stderr, " tunnel_id ID\n");
fprintf(stderr, " session_id ID peer_session_id ID\n");
@@ -500,6 +516,8 @@ static int parse_args(int argc, char **argv, int cmd, struct l2tp_parm *p)
/* Defaults */
p->l2spec_type = L2TP_L2SPECTYPE_DEFAULT;
p->l2spec_len = 4;
+ p->udp6_csum_rx = 1;
+ p->udp6_csum_tx = 1;
while (argc > 0) {
if (strcmp(*argv, "encap") == 0) {
@@ -569,6 +587,33 @@ static int parse_args(int argc, char **argv, int cmd, struct l2tp_parm *p)
if (get_u16(&uval, *argv, 0))
invarg("invalid port\n", *argv);
p->peer_udp_port = uval;
+ } else if (strcmp(*argv, "udp_csum") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "on") == 0) {
+ p->udp_csum = 1;
+ } else if (strcmp(*argv, "off") == 0) {
+ p->udp_csum = 0;
+ } else {
+ invarg("invalid option for udp_csum\n", *argv);
+ }
+ } else if (strcmp(*argv, "udp6_csum_rx") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "on") == 0) {
+ p->udp6_csum_rx = 1;
+ } else if (strcmp(*argv, "off") == 0) {
+ p->udp6_csum_rx = 0;
+ } else {
+ invarg("invalid option for udp6_csum_rx\n", *argv);
+ }
+ } else if (strcmp(*argv, "udp6_csum_tx") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "on") == 0) {
+ p->udp6_csum_tx = 1;
+ } else if (strcmp(*argv, "off") == 0) {
+ p->udp6_csum_tx = 0;
+ } else {
+ invarg("invalid option for udp6_csum_tx\n", *argv);
+ }
} else if (strcmp(*argv, "offset") == 0) {
__u8 uval;
--
2.5.2
^ permalink raw reply related
* Re: [PATCH] net/mlx5e: avoid stack overflow in mlx5e_open_channels
From: Arnd Bergmann @ 2016-04-26 13:53 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, Matan Barak, Leon Romanovsky, David S. Miller,
Achiad Shochat, Or Gerlitz, Amir Vadai, Tariq Toukan,
Linux Netdev List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CALzJLG98swFRKAZUcoXMWMyzX3z_h-HhTNZD_unh43VHByZY0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tuesday 26 April 2016 16:48:33 Saeed Mahameed wrote:
> > }
> >
> > -static void mlx5e_build_channel_param(struct mlx5e_priv *priv,
> > - struct mlx5e_channel_param *cparam)
> > +static struct mlx5e_channel_param *mlx5e_build_channel_param(struct mlx5e_priv *priv)
>
> I prefer to keep the function prototype as before and move the dynamic
> allocation to mlx5e_open_channels,
> to keep alloc/free symmetric in mlx5e_open_channels.
>
>
Sure, do you want to just edit this when you forward the patch, or
do you need me to do it?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net/mlx5e: avoid stack overflow in mlx5e_open_channels
From: Saeed Mahameed @ 2016-04-26 13:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Saeed Mahameed, Matan Barak, Leon Romanovsky, David S. Miller,
Achiad Shochat, Or Gerlitz, Amir Vadai, Tariq Toukan,
Linux Netdev List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1461590139-1396745-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
On Mon, Apr 25, 2016 at 4:15 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> struct mlx5e_channel_param is a large structure that is allocated
> on the stack of mlx5e_open_channels, and with a recent change
> it has grown beyond the warning size for the maximum stack
> that a single function should use:
>
> mellanox/mlx5/core/en_main.c: In function 'mlx5e_open_channels':
> mellanox/mlx5/core/en_main.c:1325:1: error: the frame size of 1072 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> The function is already using dynamic allocation and is not in
> a fast path, so the easiest workaround is to use another kzalloc
> for allocating the channel parameters.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Fixes: d3c9bc2743dc ("net/mlx5e: Added ICO SQs")
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 22742e1fbcb9..2ec547a80886 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -1266,12 +1266,14 @@ static void mlx5e_build_icosq_param(struct mlx5e_priv *priv,
> param->icosq = true;
> }
>
> -static void mlx5e_build_channel_param(struct mlx5e_priv *priv,
> - struct mlx5e_channel_param *cparam)
> +static struct mlx5e_channel_param *mlx5e_build_channel_param(struct mlx5e_priv *priv)
I prefer to keep the function prototype as before and move the dynamic
allocation to mlx5e_open_channels,
to keep alloc/free symmetric in mlx5e_open_channels.
> {
> + struct mlx5e_channel_param *cparam;
> u8 icosq_log_wq_sz = MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE;
>
> - memset(cparam, 0, sizeof(*cparam));
> + cparam = kzalloc(sizeof(struct mlx5e_channel_param), GFP_KERNEL);
> + if (!cparam)
> + return NULL;
>
> mlx5e_build_rq_param(priv, &cparam->rq);
> mlx5e_build_sq_param(priv, &cparam->sq);
> @@ -1279,11 +1281,13 @@ static void mlx5e_build_channel_param(struct mlx5e_priv *priv,
> mlx5e_build_rx_cq_param(priv, &cparam->rx_cq);
> mlx5e_build_tx_cq_param(priv, &cparam->tx_cq);
> mlx5e_build_ico_cq_param(priv, &cparam->icosq_cq, icosq_log_wq_sz);
> +
> + return cparam;
> }
>
> static int mlx5e_open_channels(struct mlx5e_priv *priv)
> {
> - struct mlx5e_channel_param cparam;
> + struct mlx5e_channel_param *cparam;
> int nch = priv->params.num_channels;
> int err = -ENOMEM;
> int i;
> @@ -1298,9 +1302,12 @@ static int mlx5e_open_channels(struct mlx5e_priv *priv)
You can do the allocation here, then you can benefit from the next
allocation check to test the 3 allocations altogether.
i.e:
if (!cparam || !priv->channel || !priv->txq_to_sq_map)
goto err_free_txq_to_sq_map;
> if (!priv->channel || !priv->txq_to_sq_map)
> goto err_free_txq_to_sq_map;
>
> - mlx5e_build_channel_param(priv, &cparam);
> + cparam = mlx5e_build_channel_param(priv);
> + if (!cparam)
> + goto err_free_txq_to_sq_map;
> +
> for (i = 0; i < nch; i++) {
> - err = mlx5e_open_channel(priv, i, &cparam, &priv->channel[i]);
> + err = mlx5e_open_channel(priv, i, cparam, &priv->channel[i]);
> if (err)
> goto err_close_channels;
> }
> @@ -1311,11 +1318,13 @@ static int mlx5e_open_channels(struct mlx5e_priv *priv)
> goto err_close_channels;
> }
>
> + kfree(cparam);
> return 0;
>
> err_close_channels:
> for (i--; i >= 0; i--)
> mlx5e_close_channel(priv->channel[i]);
> + kfree(cparam);
>
> err_free_txq_to_sq_map:
> kfree(priv->txq_to_sq_map);
> --
> 2.7.0
>
Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] can: m_can: fix bitrate setup on latest silicon
From: Florian Vallee @ 2016-04-26 13:46 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can, netdev, linux-kernel, ebenard, Florian Vallee
According to the m_can user manual changelog the BTP register layout was
updated with core revision 3.1.0
This change is not backward-compatible and using the current driver along
with a recent IP results in an incorrect bitrate on the wire.
Tested with a SAMA5D2 SoC (CREL = 0x31040730)
Signed-off-by: Florian Vallee <fvallee@eukrea.fr>
---
drivers/net/can/m_can/m_can.c | 38 +++++++++++++++++++++++++++++++++++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index ef65517..d12b8f2 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -105,6 +105,10 @@ enum m_can_mram_cfg {
MRAM_CFG_NUM,
};
+/* Core Release Register (CREL) */
+#define CRR_REL_MASK 0xfff
+#define CRR_REL_SHIFT 20
+
/* Fast Bit Timing & Prescaler Register (FBTP) */
#define FBTR_FBRP_MASK 0x1f
#define FBTR_FBRP_SHIFT 16
@@ -136,7 +140,7 @@ enum m_can_mram_cfg {
#define CCCR_INIT BIT(0)
#define CCCR_CANFD 0x10
-/* Bit Timing & Prescaler Register (BTP) */
+/* Bit Timing & Prescaler Register (BTP) (M_CAN IP < 3.1.0) */
#define BTR_BRP_MASK 0x3ff
#define BTR_BRP_SHIFT 16
#define BTR_TSEG1_SHIFT 8
@@ -146,6 +150,16 @@ enum m_can_mram_cfg {
#define BTR_SJW_SHIFT 0
#define BTR_SJW_MASK 0xf
+/* Nominal Bit Timing & Prescaler Register (NBTP) (M_CAN IP >= 3.1.0) */
+#define NBTR_SJW_SHIFT 25
+#define NBTR_SJW_MASK (0x7f << NBTR_SJW_SHIFT)
+#define NBTR_BRP_SHIFT 16
+#define NBTR_BRP_MASK (0x3ff << NBTR_BRP_SHIFT)
+#define NBTR_TSEG1_SHIFT 8
+#define NBTR_TSEG1_MASK (0xff << NBTR_TSEG1_SHIFT)
+#define NBTR_TSEG2_SHIFT 0
+#define NBTR_TSEG2_MASK (0x7f << NBTR_TSEG2_SHIFT)
+
/* Error Counter Register(ECR) */
#define ECR_RP BIT(15)
#define ECR_REC_SHIFT 8
@@ -200,6 +214,9 @@ enum m_can_mram_cfg {
IR_RF1L | IR_RF0L)
#define IR_ERR_ALL (IR_ERR_STATE | IR_ERR_BUS)
+/* Core Version */
+#define M_CAN_COREREL_3_1_0 0x310
+
/* Interrupt Line Select (ILS) */
#define ILS_ALL_INT0 0x0
#define ILS_ALL_INT1 0xFFFFFFFF
@@ -357,6 +374,13 @@ static inline void m_can_disable_all_interrupts(const struct m_can_priv *priv)
m_can_write(priv, M_CAN_ILE, 0x0);
}
+static inline int m_can_read_core_rev(const struct m_can_priv *priv)
+{
+ u32 reg = m_can_read(priv, M_CAN_CREL);
+
+ return ((reg >> CRR_REL_SHIFT) & CRR_REL_MASK);
+}
+
static void m_can_read_fifo(struct net_device *dev, u32 rxfs)
{
struct net_device_stats *stats = &dev->stats;
@@ -814,8 +838,16 @@ static int m_can_set_bittiming(struct net_device *dev)
sjw = bt->sjw - 1;
tseg1 = bt->prop_seg + bt->phase_seg1 - 1;
tseg2 = bt->phase_seg2 - 1;
- reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
- (tseg1 << BTR_TSEG1_SHIFT) | (tseg2 << BTR_TSEG2_SHIFT);
+
+ if (m_can_read_core_rev(priv) < M_CAN_COREREL_3_1_0)
+ reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
+ (tseg1 << BTR_TSEG1_SHIFT) |
+ (tseg2 << BTR_TSEG2_SHIFT);
+ else
+ reg_btp = (brp << NBTR_BRP_SHIFT) | (sjw << NBTR_SJW_SHIFT) |
+ (tseg1 << NBTR_TSEG1_SHIFT) |
+ (tseg2 << NBTR_TSEG2_SHIFT);
+
m_can_write(priv, M_CAN_BTP, reg_btp);
if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 net-next 11/13] Documentation: Bindings: Update DT binding for separating dsaf dev support
From: Rob Herring @ 2016-04-26 12:48 UTC (permalink / raw)
To: Yisen Zhuang
Cc: devicetree, netdev, linux-arm-kernel, pawel.moll, mark.rutland,
ijc+devicetree, galak, davem, will.deacon, catalin.marinas,
yankejian, huangdaode, salil.mehta, lipeng321, liguozhu,
xieqianqian, xuwei5, linuxarm
In-Reply-To: <1461402317-136499-12-git-send-email-Yisen.Zhuang@huawei.com>
On Sat, Apr 23, 2016 at 05:05:15PM +0800, Yisen Zhuang wrote:
> Because debug dsaf port was separated from service dsaf port, this patch
> updates the related information of DT binding.
Separated when? New version of the h/w? If so, where's the new
compatible string? This is quite a big binding change.
> Signed-off-by: Yisen Zhuang <yisen.zhuang@huawei.com>
>
> ---
> .../devicetree/bindings/net/hisilicon-hns-dsaf.txt | 59 ++++++++++++++++++----
> 1 file changed, 49 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> index ecacfa4..5ccd4f0 100644
> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> @@ -7,19 +7,47 @@ Required properties:
> - mode: dsa fabric mode string. only support one of dsaf modes like these:
> "2port-64vf",
> "6port-16rss",
> - "6port-16vf".
> + "6port-16vf",
> + "single-port".
> - interrupt-parent: the interrupt parent of this device.
> - interrupts: should contain the DSA Fabric and rcb interrupt.
> - reg: specifies base physical address(es) and size of the device registers.
> - The first region is external interface control register base and size.
> - The second region is SerDes base register and size.
> + The first region is external interface control register base and size(optional,
> + only be used when subctrl-syscon is not exists). It is recommended using
only used when subctrl-syscon does not exist
> + subctrl-syscon rather than this address.
> + The second region is SerDes base register and size(optional, only be used when
> + serdes-syscon in port node is not exists. It is recommended using
similar rewording needed here.
> + serdes-syscon rather than this address.
> The third region is the PPE register base and size.
> - The fourth region is dsa fabric base register and size.
> - The fifth region is cpld base register and size, it is not required if do not use cpld.
> -- phy-handle: phy handle of physicl port, 0 if not any phy device. see ethernet.txt [1].
> + The fourth region is dsa fabric base register and size. It is not required for
> + single-port mode.
> +- reg-names: may be ppe-base and(or) dsaf-base. It is used to find the
> + corresponding reg's index.
But you have up to 5 regions.
The variable nature of what regions you have tells me you need more
specific compatible strings for each chip.
> +
> +- phy-handle: phy handle of physicl port, 0 if not any phy device. It is optional
s/physicl/physical/
> + attribute. If port node is exists, phy-handle in each port node will be used.
> + see ethernet.txt [1].
> +- subctrl-syscon: is syscon handle for external interface control register.
> +- reset-field-offset: is offset of reset field. Its value depends on the hardware
> + user manual.
> - buf-size: rx buffer size, should be 16-1024.
> - desc-num: number of description in TX and RX queue, should be 512, 1024, 2048 or 4096.
>
> +- port: subnodes of dsaf. A dsaf node may contain several port nodes(Depending
> + on mode of dsaf). Port node contain some attributes listed below:
> +- port-id: is physical port index in one dsaf.
Indexes should generally be avoided. What does the number correspond
to in h/w (if anything)?
> +- phy-handle: phy handle of physicl port. It is not required if there isn't
> + phy device. see ethernet.txt [1].
> +- serdes-syscon: is syscon handle for SerDes register.
> +- cpld-syscon: is syscon handle for cpld register. It is not required if there
> + isn't cpld device.
> +- cpld-ctrl-reg: is cpld register offset. It is not required if there isn't
> + cpld-syscon.
This would usually be a cell in the cpld-syscon property.
> +- port-rst-offset: is offset of reset field for each port in dsaf. Its value
> + depends on the hardware user manual.
> +- port-mode-offset: is offset of port mode field for each port in dsaf. Its
> + value depends on the hardware user manual.
Again, sounds like you need more specific compatible strings that imply
this information.
> +
> [1] Documentation/devicetree/bindings/net/phy.txt
>
> Example:
> @@ -28,11 +56,11 @@ dsaf0: dsa@c7000000 {
> compatible = "hisilicon,hns-dsaf-v1";
> mode = "6port-16rss";
> interrupt-parent = <&mbigen_dsa>;
> - reg = <0x0 0xC0000000 0x0 0x420000
> - 0x0 0xC2000000 0x0 0x300000
> - 0x0 0xc5000000 0x0 0x890000
> + reg = <0x0 0xc5000000 0x0 0x890000
> 0x0 0xc7000000 0x0 0x60000>;
> - phy-handle = <0 0 0 0 &soc0_phy4 &soc0_phy5 0 0>;
> + reg-names = "ppe-base", "dsaf-base";
> + subctrl-syscon = <&subctrl>;
> + reset-field-offset = 0;
> interrupts = <131 4>,<132 4>, <133 4>,<134 4>,
> <135 4>,<136 4>, <137 4>,<138 4>,
> <139 4>,<140 4>, <141 4>,<142 4>,
> @@ -43,4 +71,15 @@ dsaf0: dsa@c7000000 {
> buf-size = <4096>;
> desc-num = <1024>;
> dma-coherent;
> +
> + prot@0 {
port?
> + port-id = 0;
> + phy-handle = <&phy0>;
> + serdes-syscon = <&serdes>;
> + };
> +
> + prot@1 {
> + port-id = 1;
> + serdes-syscon = <&serdes>;
> + };
> };
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH V3] net: stmmac: socfpga: Remove re-registration of reset controller
From: Marek Vasut @ 2016-04-26 12:47 UTC (permalink / raw)
To: Joachim Eastwood
Cc: netdev, peppe.cavallaro, alexandre.torgue, Matthew Gerlach,
Dinh Nguyen, David S . Miller
In-Reply-To: <CAGhQ9Vz568hdSk+HWGHXuSNn4DU7HZkUBfVbajQyRkq+rBYY7Q@mail.gmail.com>
On 04/26/2016 02:26 PM, Joachim Eastwood wrote:
> On 26 April 2016 at 00:55, Marek Vasut <marex@denx.de> wrote:
>> On 04/25/2016 08:11 PM, Joachim Eastwood wrote:
>>> On 21 April 2016 at 14:11, Marek Vasut <marex@denx.de> wrote:
>>>>
>>>> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
>>>> since the functionality is already performed by the stmmac core.
>>>
>>> I am trying to rebase my changes on top of your two patches and
>>> noticed a couple of things.
>>>
>>>> static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>>> {
>>>> - struct socfpga_dwmac *dwmac = priv;
>>>> + struct socfpga_dwmac *dwmac = priv;
>>>> struct net_device *ndev = platform_get_drvdata(pdev);
>>>> struct stmmac_priv *stpriv = NULL;
>>>> int ret = 0;
>>>>
>>>> - if (ndev)
>>>> - stpriv = netdev_priv(ndev);
>>>> + if (!ndev)
>>>> + return -EINVAL;
>>>
>>> ndev can never be NULL here. socfpga_dwmac_init() is only called if
>>> stmmac_dvr_probe() succeeds or we are running the resume callback. So
>>> I don't see how this could ever be NULL.
>>
>> That's a good point, this check can indeed be removed. While you're at
>> the patching, can you remove this one ?
>
> Yes, my patch will refactor the init() function so this will go away.
Thanks!
>>>> +
>>>> + stpriv = netdev_priv(ndev);
>>>
>>> It's not really nice to access 'stmmac_priv' as it should be private
>>> to the core driver, but I don't see any other good solution right now.
>>
>> I guess some stmmac_reset_assert() wrapper would be nicer, yes. What do
>> you think ?
>>
>>>> + if (!stpriv)
>>>> + return -EINVAL;
>>>>
>>>> /* Assert reset to the enet controller before changing the phy mode */
>>>> - if (dwmac->stmmac_rst)
>>>> - reset_control_assert(dwmac->stmmac_rst);
>>>> + if (stpriv->stmmac_rst)
>>>> + reset_control_assert(stpriv->stmmac_rst);
>>>>
>>>> /* Setup the phy mode in the system manager registers according to
>>>> * devicetree configuration
>>>> @@ -227,8 +210,8 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>>> /* Deassert reset for the phy configuration to be sampled by
>>>> * the enet controller, and operation to start in requested mode
>>>> */
>>>> - if (dwmac->stmmac_rst)
>>>> - reset_control_deassert(dwmac->stmmac_rst);
>>>> + if (stpriv->stmmac_rst)
>>>> + reset_control_deassert(stpriv->stmmac_rst);
>>>>
>>>> /* Before the enet controller is suspended, the phy is suspended.
>>>> * This causes the phy clock to be gated. The enet controller is
>>>> @@ -245,7 +228,7 @@ static int socfpga_dwmac_init(struct platform_device *pdev, void *priv)
>>>> * control register 0, and can be modified by the phy driver
>>>> * framework.
>>>> */
>>>> - if (stpriv && stpriv->phydev)
>>>> + if (stpriv->phydev)
>>>> phy_resume(stpriv->phydev);
>>>
>>> Before this change phy_resume() was only called during driver resume
>>> when , but your patches cause phy_resume() to called at probe time as
>>> well. Is this okey?
>>
>> I _hope_ it's OK. The cryptic comment above is not very helpful in this
>> aspect. Dinh ? :)
>
> My patches will move phy_resume() to the resume callback so it
> preserves the previous behavior. But if someone knows more about this
> that would be useful.
>
>
>> btw I wish you reviewed my patch a bit earlier to catch these bits.
>
> Sorry, about that. I have been really busy with other things lately.
Oh I'm real happy someone is doing the refactoring :) I appreciate your
work, sorry if that was unclear.
> My patches based on next from Friday can be found here now:
> https://github.com/manabian/linux-lpc/tree/net-socfpga-dwmac-on-next
>
> I had to add your latest patch as well since the next version I used
> didn't have it. I'll post the patches on netdev later today or
> tomorrow.
Looks like next wasn't synced for a few days, yeah.
You can add my:
On SoCFPGA Cyclone V SoC (DENX MCVEVK):
Tested-by: Marek Vasut <marex@denx.de>
to those patches
> regards,
> Joachim Eastwood
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [net-next PATCH 3/4] samples/bpf: add a README file to get users started
From: Daniel Borkmann @ 2016-04-26 12:40 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, bblanco, borkmann, alexei.starovoitov, linux-kbuild
In-Reply-To: <20160426135647.7faf9a87@redhat.com>
On 04/26/2016 01:56 PM, Jesper Dangaard Brouer wrote:
> On Tue, 26 Apr 2016 13:44:06 +0200
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>
>> On 04/26/2016 01:09 PM, Jesper Dangaard Brouer wrote:
>>> Getting started with using examples in samples/bpf/ is not
>>> straightforward. There are several dependencies, and specific
>>> versions of these dependencies.
>>>
>>> Just compiling the example tool is also slightly obscure, e.g. one
>>> need to call make like:
>>>
>>> make samples/bpf/
>>>
>>> Do notice the "/" slash after the directory name.
>>>
>>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>>> ---
>>> samples/bpf/README.rst | 67 ++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 67 insertions(+)
>>> create mode 100644 samples/bpf/README.rst
>>>
>>> diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
>>> new file mode 100644
>>> index 000000000000..3e1ac05d8e7c
>>> --- /dev/null
>>> +++ b/samples/bpf/README.rst
>>> @@ -0,0 +1,67 @@
>>> +eBPF sample programs
>>> +====================
>>> +
>>> +This kernel samples/bpf directory contains a mini eBPF library, test
>>> +stubs, verifier test-suite and examples for using eBPF.
>>> +
>>> +Build dependencies
>>> +==================
>>> +
>>> +Compiling requires having installed:
>>> + * clang
>>> + * llvm >= version 3.7.0
>>> +
>>> +Note that LLVM's tool 'llc' must support target 'bpf', list with command::
>>> +
>>> + $ llc --version
>>> + LLVM (http://llvm.org/):
>>> + LLVM version 3.x.y
>>> + [...]
>>> + Host CPU: xxx
>>> +
>>> + Registered Targets:
>>> + [...]
>>> + bpf - BPF (host endian)
>>> + bpfeb - BPF (big endian)
>>> + bpfel - BPF (little endian)
>>> + [...]
>>> +
>>> +Kernel headers
>>> +--------------
>>> +
>>> +There are usually dependencies to header files of the current kernel.
>>> +To avoid installing devel kernel headers system wide, as a normal
>>> +user, simply call::
>>> +
>>> + make headers_install
>>> +
>>> +This will creates a local "usr/include" directory in the git/build top
>>> +level directory, that the make system automatically pickup first.
>>> +
>>> +Compiling
>>> +=========
>>> +
>>> +For compiling goto kernel top level build directory and run make like::
>>> +
>>> + make samples/bpf/
>>> +
>>> +Do notice the "/" slash after the directory name.
>>> +
>>> +Manually compiling LLVM with 'bpf' support
>>> +------------------------------------------
>>> +
>>> +In some LLVM versions the BPF target were marked experimental. To
>>> +compile LLVM manually and enable BPF target run (build dependencies
>>> +are cmake and gcc-c++)::
>>> +
>>> + $ git clone http://llvm.org/git/llvm.git
>>> + $ cd llvm
>>> + $ mkdir build; cd build
>>> + $ cmake .. -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=BPF
>>> + $ make
>>
>> That's perhaps a bit misleading in the sense that when you clone the
>> tree from git, you'd nowadays invoke cmake normally with LLVM_TARGETS_TO_BUILD
>> instead of LLVM_EXPERIMENTAL_TARGETS_TO_BUILD for BPF, as BPF is not an
>> experimental target anymore. It's probably also recommended to clone
>> clang into tools/ dir as well under your llvm/ repo when you compile
>> from scratch anyways.
>
> Can you come up with a formulation/desc I can use instead then?
You mean how to build with clang? There are various docs/snippets out
there, for example, see the 'Build LLVM and Clang development libs'
part of [1], that you can tweak for your README with.
[1] https://gist.github.com/brendangregg/cfa482acb71aa577789c
^ permalink raw reply
* Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()
From: Jan Kara @ 2016-04-26 12:37 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Jan Kara, sd-y1jBWg8GRStKuXlAQpz2QA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA, jack-IBi9RG/b67k,
johannes-cdvu00un1VgdHxzADdlk8Q,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <571F5FBE.8050900-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Tue 26-04-16 14:31:58, Nicolas Dichtel wrote:
> Le 26/04/2016 13:08, Jan Kara a écrit :
> > On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote:
> >> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >
> > OK, so I somewhat miss a description of what will this do to the netlink
> > message so that I can judge whether the change is fine for the userspace
> > counterpart parsing these messages. AFAIU this changes the message format
> > by adding a QUOTA_NL_A_PAD field before each 64-bit field which needs an
> > alignment, am I guessing right? Thus when the userspace counterpart uses
> > genlmsg_parse() it should just silently ignore these attributes if I read
> > the documentation right. Did I understand this correctly?
> Yes, that's it.
OK, then feel free to add:
Acked-by: Jan Kara <jack@suse.cz>
to the quota patch.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: codel: split into multiple files
From: Michal Kazior @ 2016-04-26 12:36 UTC (permalink / raw)
To: sedat.dilek; +Cc: David S. Miller, netdev@vger.kernel.org, Jens Axboe
In-Reply-To: <CA+icZUVinohrHUNpKti-QA52eeSztmRTH1sFHpK+YSm98yGrAA@mail.gmail.com>
On 26 April 2016 at 08:43, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On 4/26/16, Michal Kazior <michal.kazior@tieto.com> wrote:
>> On 26 April 2016 at 08:09, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>> Hi,
>>>
>>> I had a very quick view on net-next.git#master (up to commit
>>> fab7b629a82da1b59620470d13152aff975239f6).
>>>
>>> Commit in [1] aka "codel: split into multiple files" removed codel.h
>>> but [2] and [3] have relicts to it.
>>> Forgot to remove?
>>
>> codel.h was not removed. diffstat for codel.h is all red which I
>> presume is why you thought of it as removed, see:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/include/net/codel.h?id=d068ca2ae2e614b9a418fb3b5f1fd4cf996ff032
>>
>
> [ CC Jens ]
>
> OK.
> So what are the plans in the future?
> Keep a "generic" codel.h (compatibility reasons?) for net or is it your split?
I'm interested in re-using codel in mac80211 for wireless. cfg80211
drivers may want to do that as well later. Even vendor drivers could
start to use it (I can dream :).
I plan to re-spin my patches soonish re-based on the new codel.h/fq.h
approach. There's quite a few spins already[1].
> AFAICS I have seen a codel-implementation in block.git#wb-buf-throttle.
> Does it make sense to have a more "super-generic" codel.h for re-use
> (not only for net and block)?
> Just a thought.
Oh, I'm not really familiar with block and problems around it but it
sounds reasonable and interesting. It doesn't look like it blatantly
copies codel though (I did that in my initial mac80211 patches with
some adjustments, you can check that in the link[1] which you can
lookup via my patchset's cover letter[2]; I've based off of codel5[3]
back then).
[1]: https://www.spinics.net/lists/linux-wireless/msg148714.html
[2]: https://www.spinics.net/lists/netdev/msg374308.html
[3]: https://github.com/dtaht/bcake/blob/master/codel5.h
Michał
^ permalink raw reply
* Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()
From: Nicolas Dichtel @ 2016-04-26 12:31 UTC (permalink / raw)
To: Jan Kara
Cc: dev-yBygre7rU0TnMu66kgdUjQ, sd-y1jBWg8GRStKuXlAQpz2QA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA, jack-IBi9RG/b67k,
johannes-cdvu00un1VgdHxzADdlk8Q,
philipp.reisner-63ez5xqkn6DQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <20160426110848.GD27612-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
Le 26/04/2016 13:08, Jan Kara a écrit :
> On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote:
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> OK, so I somewhat miss a description of what will this do to the netlink
> message so that I can judge whether the change is fine for the userspace
> counterpart parsing these messages. AFAIU this changes the message format
> by adding a QUOTA_NL_A_PAD field before each 64-bit field which needs an
> alignment, am I guessing right? Thus when the userspace counterpart uses
> genlmsg_parse() it should just silently ignore these attributes if I read
> the documentation right. Did I understand this correctly?
Yes, that's it.
Regards,
Nicolas
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox