* Re: [PATCH] ipvlan: flush arp table when mac address changed
From: Paolo Abeni @ 2018-05-14 7:39 UTC (permalink / raw)
To: liuqifa, davem, dsahern, maheshb, weiyongjun1, maowenan,
dingtianhong
Cc: netdev, linux-kernel
In-Reply-To: <20180512110037.9116-1-liuqifa@huawei.com>
Hi,
On Sat, 2018-05-12 at 19:00 +0800, liuqifa@huawei.com wrote:
> From: Keefe Liu <liuqifa@huawei.com>
>
> When master device's mac has been changed, the
> commit <32c10bbfe914> "ipvlan: always use the current L2
> addr of the master" makes the IPVlan devices's mac changed
> also, but it doesn't flush the IPVlan's arp table.
>
> Signed-off-by: Keefe Liu <liuqifa@huawei.com>
> ---
> drivers/net/ipvlan/ipvlan_main.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
> index 450eec2..a1edfe1 100644
> --- a/drivers/net/ipvlan/ipvlan_main.c
> +++ b/drivers/net/ipvlan/ipvlan_main.c
> @@ -7,6 +7,8 @@
> *
> */
>
> +#include <net/neighbour.h>
> +#include <net/arp.h>
> #include "ipvlan.h"
>
> static unsigned int ipvlan_netid __read_mostly;
> @@ -792,8 +794,10 @@ static int ipvlan_device_event(struct notifier_block *unused,
> break;
>
> case NETDEV_CHANGEADDR:
> - list_for_each_entry(ipvlan, &port->ipvlans, pnode)
> + list_for_each_entry(ipvlan, &port->ipvlans, pnode) {
> ether_addr_copy(ipvlan->dev->dev_addr, dev->dev_addr);
> + neigh_changeaddr(&arp_tbl, ipvlan->dev);
> + }
Why don't using:
call_netdevice_notifiers(NETDEV_CHANGEADDR, ipvlan->dev);
instead?
that is what other stacked device - bridge and vlans - are currently
doing in the same scenario.
Thanks,
Paolo
^ permalink raw reply
* Re: [kbuild-all] [PATCH net-next 2/2] sctp: add sctp_make_op_error_limited and reuse inner functions
From: Ye Xiaolong @ 2018-05-14 7:40 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: kbuild test robot, Xin Long, Neil Horman, netdev, Vlad Yasevich,
linux-sctp, kbuild-all
In-Reply-To: <20180430023421.GA4977@localhost.localdomain>
Sorry for the late response.
On 04/29, Marcelo Ricardo Leitner wrote:
>On Mon, Apr 30, 2018 at 10:14:06AM +0800, kbuild test robot wrote:
>> Hi Marcelo,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on net-next/master]
>>
>> url: https://github.com/0day-ci/linux/commits/Marcelo-Ricardo-Leitner/sctp-allow-sctp_init_cause-to-return-errors/20180430-073613
>
>This URL doesn't work, 404.
Our fault, 0day service failed to push related changes to github recently, we're
fixing it.
>
>> config: x86_64-randconfig-x006-201817 (attached as .config)
>> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64
>>
>> All errors (new ones prefixed by >>):
>>
>> net//sctp/sm_make_chunk.c: In function 'sctp_make_op_error_limited':
>> >> net//sctp/sm_make_chunk.c:1260:9: error: implicit declaration of function 'sctp_mtu_payload'; did you mean 'sctp_do_peeloff'? [-Werror=implicit-function-declaration]
>> size = sctp_mtu_payload(sp, size, sizeof(struct sctp_errhdr));
>> ^~~~~~~~~~~~~~~~
>> sctp_do_peeloff
>> cc1: some warnings being treated as errors
>
>Seems the test didn't pick up the MTU refactor patchset yet.
Do you mean your patchset require MTU refactor patchset as prerequisites?
Thanks,
Xiaolong
>
>$ grep sctp/sctp -- net/sctp/sm_make_chunk.c
>#include <net/sctp/sctp.h>
>
>$ git grep sctp_mtu_payload -- include/
>include/net/sctp/sctp.h:static inline __u32 sctp_mtu_payload(const
>struct sctp_sock *sp,
>
>it should be reachable.
>
> Marcelo
>_______________________________________________
>kbuild-all mailing list
>kbuild-all@lists.01.org
>https://lists.01.org/mailman/listinfo/kbuild-all
^ permalink raw reply
* Re: [PATCH] net: mvpp2: fix mvpp2_tx()'s return type
From: Antoine Tenart @ 2018-05-14 7:52 UTC (permalink / raw)
To: Luc Van Oostenryck
Cc: linux-kernel, David S. Miller, Antoine Tenart, Thomas Petazzoni,
Maxime Chevallier, Yan Markman, Stefan Chulski, Miquel Raynal,
Marcin Wojtas, netdev
In-Reply-To: <20180424131656.4054-1-luc.vanoostenryck@gmail.com>
Hi Luc,
On Tue, Apr 24, 2018 at 03:16:53PM +0200, Luc Van Oostenryck wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Fix this by returning 'netdev_tx_t' in this driver too.
>
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
I don't think this has been applied yet, so,
Acked-by: Antoine Tenart <antoine.tenart@bootlin.com>
Thanks!
Antoine
> ---
> drivers/net/ethernet/marvell/mvpp2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
> index 54a038943..355910345 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -6926,7 +6926,7 @@ static int mvpp2_tx_tso(struct sk_buff *skb, struct net_device *dev,
> }
>
> /* Main tx processing */
> -static int mvpp2_tx(struct sk_buff *skb, struct net_device *dev)
> +static netdev_tx_t mvpp2_tx(struct sk_buff *skb, struct net_device *dev)
> {
> struct mvpp2_port *port = netdev_priv(dev);
> struct mvpp2_tx_queue *txq, *aggr_txq;
> --
> 2.17.0
>
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH net-next] cxgb4: do not fail vf instatiation in slave mode
From: Ganesh Goudar @ 2018-05-14 7:54 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Arjun Vynipadath, Casey Leedom,
Ganesh Goudar
From: Arjun Vynipadath <arjun@chelsio.com>
We no longer require a check for cxgb4 to be MASTER
when configuring SRIOV, It was required when we had
module parameter to instantiate vf.
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c54fd18..4ca828c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5276,13 +5276,9 @@ static int cxgb4_iov_configure(struct pci_dev *pdev, int num_vfs)
u32 pcie_fw;
pcie_fw = readl(adap->regs + PCIE_FW_A);
- /* Check if cxgb4 is the MASTER and fw is initialized */
- if (num_vfs &&
- (!(pcie_fw & PCIE_FW_INIT_F) ||
- !(pcie_fw & PCIE_FW_MASTER_VLD_F) ||
- PCIE_FW_MASTER_G(pcie_fw) != CXGB4_UNIFIED_PF)) {
- dev_warn(&pdev->dev,
- "cxgb4 driver needs to be MASTER to support SRIOV\n");
+ /* Check if fw is initialized */
+ if (!(pcie_fw & PCIE_FW_INIT_F)) {
+ dev_warn(&pdev->dev, "Device not initialized\n");
return -EOPNOTSUPP;
}
--
2.1.0
^ permalink raw reply related
* [PATCH net-next 1/2] cxgb4: Add support for FW_ETH_TX_PKT_VM_WR
From: Ganesh Goudar @ 2018-05-14 7:55 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Arjun Vynipadath, Casey Leedom,
Ganesh Goudar
From: Arjun Vynipadath <arjun@chelsio.com>
The present TX workrequest(FW_ETH_TX_PKT_WR) cant be used for
host->vf communication, since it doesn't loopback the outgoing
packets to virtual interfaces on the same port. This can be done using
FW_ETH_TX_PKT_VM_WR.
This fix depends on ethtool_flags to determine what WR to use for
TX path. Support for setting this flags by user is added in next commit.
Based on the original work by : Casey Leedom <leedom@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 13 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/sge.c | 367 ++++++++++++++++++++++++
3 files changed, 381 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 688f954..d2a7777 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -517,6 +517,15 @@ enum {
MAX_INGQ = MAX_ETH_QSETS + INGQ_EXTRAS,
};
+enum {
+ PRIV_FLAG_PORT_TX_VM_BIT,
+};
+
+#define PRIV_FLAG_PORT_TX_VM BIT(PRIV_FLAG_PORT_TX_VM_BIT)
+
+#define PRIV_FLAGS_ADAP 0
+#define PRIV_FLAGS_PORT PRIV_FLAG_PORT_TX_VM
+
struct adapter;
struct sge_rspq;
@@ -553,6 +562,7 @@ struct port_info {
struct hwtstamp_config tstamp_config;
bool ptp_enable;
struct sched_table *sched_tbl;
+ u32 eth_flags;
};
struct dentry;
@@ -863,6 +873,7 @@ struct adapter {
unsigned int flags;
unsigned int adap_idx;
enum chip_type chip;
+ unsigned int eth_flags;
int msg_enable;
__be16 vxlan_port;
@@ -1324,6 +1335,8 @@ void t4_free_sge_resources(struct adapter *adap);
void t4_free_ofld_rxqs(struct adapter *adap, int n, struct sge_ofld_rxq *q);
irq_handler_t t4_intr_handler(struct adapter *adap);
netdev_tx_t t4_eth_xmit(struct sk_buff *skb, struct net_device *dev);
+netdev_tx_t t4vf_eth_xmit(struct sk_buff *skb, struct net_device *dev);
+netdev_tx_t t4_start_xmit(struct sk_buff *skb, struct net_device *dev);
int t4_ethrx_handler(struct sge_rspq *q, const __be64 *rsp,
const struct pkt_gl *gl);
int t4_mgmt_tx(struct adapter *adap, struct sk_buff *skb);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c54fd18..b329bd1 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3211,7 +3211,7 @@ static netdev_features_t cxgb_fix_features(struct net_device *dev,
static const struct net_device_ops cxgb4_netdev_ops = {
.ndo_open = cxgb_open,
.ndo_stop = cxgb_close,
- .ndo_start_xmit = t4_eth_xmit,
+ .ndo_start_xmit = t4_start_xmit,
.ndo_select_queue = cxgb_select_queue,
.ndo_get_stats64 = cxgb_get_stats,
.ndo_set_rx_mode = cxgb_set_rxmode,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 0f87e97..b914a5e 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -1549,6 +1549,373 @@ out_free: dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
+/* Constants ... */
+enum {
+ /* Egress Queue sizes, producer and consumer indices are all in units
+ * of Egress Context Units bytes. Note that as far as the hardware is
+ * concerned, the free list is an Egress Queue (the host produces free
+ * buffers which the hardware consumes) and free list entries are
+ * 64-bit PCI DMA addresses.
+ */
+ EQ_UNIT = SGE_EQ_IDXSIZE,
+ FL_PER_EQ_UNIT = EQ_UNIT / sizeof(__be64),
+ TXD_PER_EQ_UNIT = EQ_UNIT / sizeof(__be64),
+
+ T4VF_ETHTXQ_MAX_HDR = (sizeof(struct fw_eth_tx_pkt_vm_wr) +
+ sizeof(struct cpl_tx_pkt_lso_core) +
+ sizeof(struct cpl_tx_pkt_core)) / sizeof(__be64),
+};
+
+/**
+ * t4vf_is_eth_imm - can an Ethernet packet be sent as immediate data?
+ * @skb: the packet
+ *
+ * Returns whether an Ethernet packet is small enough to fit completely as
+ * immediate data.
+ */
+static inline int t4vf_is_eth_imm(const struct sk_buff *skb)
+{
+ /* The VF Driver uses the FW_ETH_TX_PKT_VM_WR firmware Work Request
+ * which does not accommodate immediate data. We could dike out all
+ * of the support code for immediate data but that would tie our hands
+ * too much if we ever want to enhace the firmware. It would also
+ * create more differences between the PF and VF Drivers.
+ */
+ return false;
+}
+
+/**
+ * t4vf_calc_tx_flits - calculate the number of flits for a packet TX WR
+ * @skb: the packet
+ *
+ * Returns the number of flits needed for a TX Work Request for the
+ * given Ethernet packet, including the needed WR and CPL headers.
+ */
+static inline unsigned int t4vf_calc_tx_flits(const struct sk_buff *skb)
+{
+ unsigned int flits;
+
+ /* If the skb is small enough, we can pump it out as a work request
+ * with only immediate data. In that case we just have to have the
+ * TX Packet header plus the skb data in the Work Request.
+ */
+ if (t4vf_is_eth_imm(skb))
+ return DIV_ROUND_UP(skb->len + sizeof(struct cpl_tx_pkt),
+ sizeof(__be64));
+
+ /* Otherwise, we're going to have to construct a Scatter gather list
+ * of the skb body and fragments. We also include the flits necessary
+ * for the TX Packet Work Request and CPL. We always have a firmware
+ * Write Header (incorporated as part of the cpl_tx_pkt_lso and
+ * cpl_tx_pkt structures), followed by either a TX Packet Write CPL
+ * message or, if we're doing a Large Send Offload, an LSO CPL message
+ * with an embedded TX Packet Write CPL message.
+ */
+ flits = sgl_len(skb_shinfo(skb)->nr_frags + 1);
+ if (skb_shinfo(skb)->gso_size)
+ flits += (sizeof(struct fw_eth_tx_pkt_vm_wr) +
+ sizeof(struct cpl_tx_pkt_lso_core) +
+ sizeof(struct cpl_tx_pkt_core)) / sizeof(__be64);
+ else
+ flits += (sizeof(struct fw_eth_tx_pkt_vm_wr) +
+ sizeof(struct cpl_tx_pkt_core)) / sizeof(__be64);
+ return flits;
+}
+
+/**
+ * t4vf_eth_xmit - add a packet to an Ethernet TX queue
+ * @skb: the packet
+ * @dev: the egress net device
+ *
+ * Add a packet to an SGE Ethernet TX queue. Runs with softirqs disabled.
+ */
+netdev_tx_t t4vf_eth_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ u32 wr_mid;
+ u64 cntrl, *end;
+ int qidx, credits, max_pkt_len;
+ unsigned int flits, ndesc;
+ struct adapter *adapter;
+ struct sge_eth_txq *txq;
+ const struct port_info *pi;
+ struct fw_eth_tx_pkt_vm_wr *wr;
+ struct cpl_tx_pkt_core *cpl;
+ const struct skb_shared_info *ssi;
+ dma_addr_t addr[MAX_SKB_FRAGS + 1];
+ const size_t fw_hdr_copy_len = (sizeof(wr->ethmacdst) +
+ sizeof(wr->ethmacsrc) +
+ sizeof(wr->ethtype) +
+ sizeof(wr->vlantci));
+
+ /* The chip minimum packet length is 10 octets but the firmware
+ * command that we are using requires that we copy the Ethernet header
+ * (including the VLAN tag) into the header so we reject anything
+ * smaller than that ...
+ */
+ if (unlikely(skb->len < fw_hdr_copy_len))
+ goto out_free;
+
+ /* Discard the packet if the length is greater than mtu */
+ max_pkt_len = ETH_HLEN + dev->mtu;
+ if (skb_vlan_tag_present(skb))
+ max_pkt_len += VLAN_HLEN;
+ if (!skb_shinfo(skb)->gso_size && (unlikely(skb->len > max_pkt_len)))
+ goto out_free;
+
+ /* Figure out which TX Queue we're going to use. */
+ pi = netdev_priv(dev);
+ adapter = pi->adapter;
+ qidx = skb_get_queue_mapping(skb);
+ WARN_ON(qidx >= pi->nqsets);
+ txq = &adapter->sge.ethtxq[pi->first_qset + qidx];
+
+ /* Take this opportunity to reclaim any TX Descriptors whose DMA
+ * transfers have completed.
+ */
+ cxgb4_reclaim_completed_tx(adapter, &txq->q, true);
+
+ /* Calculate the number of flits and TX Descriptors we're going to
+ * need along with how many TX Descriptors will be left over after
+ * we inject our Work Request.
+ */
+ flits = t4vf_calc_tx_flits(skb);
+ ndesc = flits_to_desc(flits);
+ credits = txq_avail(&txq->q) - ndesc;
+
+ if (unlikely(credits < 0)) {
+ /* Not enough room for this packet's Work Request. Stop the
+ * TX Queue and return a "busy" condition. The queue will get
+ * started later on when the firmware informs us that space
+ * has opened up.
+ */
+ eth_txq_stop(txq);
+ dev_err(adapter->pdev_dev,
+ "%s: TX ring %u full while queue awake!\n",
+ dev->name, qidx);
+ return NETDEV_TX_BUSY;
+ }
+
+ if (!t4vf_is_eth_imm(skb) &&
+ unlikely(cxgb4_map_skb(adapter->pdev_dev, skb, addr) < 0)) {
+ /* We need to map the skb into PCI DMA space (because it can't
+ * be in-lined directly into the Work Request) and the mapping
+ * operation failed. Record the error and drop the packet.
+ */
+ txq->mapping_err++;
+ goto out_free;
+ }
+
+ wr_mid = FW_WR_LEN16_V(DIV_ROUND_UP(flits, 2));
+ if (unlikely(credits < ETHTXQ_STOP_THRES)) {
+ /* After we're done injecting the Work Request for this
+ * packet, we'll be below our "stop threshold" so stop the TX
+ * Queue now and schedule a request for an SGE Egress Queue
+ * Update message. The queue will get started later on when
+ * the firmware processes this Work Request and sends us an
+ * Egress Queue Status Update message indicating that space
+ * has opened up.
+ */
+ eth_txq_stop(txq);
+ wr_mid |= FW_WR_EQUEQ_F | FW_WR_EQUIQ_F;
+ }
+
+ /* Start filling in our Work Request. Note that we do _not_ handle
+ * the WR Header wrapping around the TX Descriptor Ring. If our
+ * maximum header size ever exceeds one TX Descriptor, we'll need to
+ * do something else here.
+ */
+ WARN_ON(DIV_ROUND_UP(T4VF_ETHTXQ_MAX_HDR, TXD_PER_EQ_UNIT) > 1);
+ wr = (void *)&txq->q.desc[txq->q.pidx];
+ wr->equiq_to_len16 = cpu_to_be32(wr_mid);
+ wr->r3[0] = cpu_to_be32(0);
+ wr->r3[1] = cpu_to_be32(0);
+ skb_copy_from_linear_data(skb, (void *)wr->ethmacdst, fw_hdr_copy_len);
+ end = (u64 *)wr + flits;
+
+ /* If this is a Large Send Offload packet we'll put in an LSO CPL
+ * message with an encapsulated TX Packet CPL message. Otherwise we
+ * just use a TX Packet CPL message.
+ */
+ ssi = skb_shinfo(skb);
+ if (ssi->gso_size) {
+ struct cpl_tx_pkt_lso_core *lso = (void *)(wr + 1);
+ bool v6 = (ssi->gso_type & SKB_GSO_TCPV6) != 0;
+ int l3hdr_len = skb_network_header_len(skb);
+ int eth_xtra_len = skb_network_offset(skb) - ETH_HLEN;
+
+ wr->op_immdlen =
+ cpu_to_be32(FW_WR_OP_V(FW_ETH_TX_PKT_VM_WR) |
+ FW_WR_IMMDLEN_V(sizeof(*lso) +
+ sizeof(*cpl)));
+ /* Fill in the LSO CPL message. */
+ lso->lso_ctrl =
+ cpu_to_be32(LSO_OPCODE_V(CPL_TX_PKT_LSO) |
+ LSO_FIRST_SLICE_F |
+ LSO_LAST_SLICE_F |
+ LSO_IPV6_V(v6) |
+ LSO_ETHHDR_LEN_V(eth_xtra_len / 4) |
+ LSO_IPHDR_LEN_V(l3hdr_len / 4) |
+ LSO_TCPHDR_LEN_V(tcp_hdr(skb)->doff));
+ lso->ipid_ofst = cpu_to_be16(0);
+ lso->mss = cpu_to_be16(ssi->gso_size);
+ lso->seqno_offset = cpu_to_be32(0);
+ if (is_t4(adapter->params.chip))
+ lso->len = cpu_to_be32(skb->len);
+ else
+ lso->len = cpu_to_be32(LSO_T5_XFER_SIZE_V(skb->len));
+
+ /* Set up TX Packet CPL pointer, control word and perform
+ * accounting.
+ */
+ cpl = (void *)(lso + 1);
+
+ if (CHELSIO_CHIP_VERSION(adapter->params.chip) <= CHELSIO_T5)
+ cntrl = TXPKT_ETHHDR_LEN_V(eth_xtra_len);
+ else
+ cntrl = T6_TXPKT_ETHHDR_LEN_V(eth_xtra_len);
+
+ cntrl |= TXPKT_CSUM_TYPE_V(v6 ?
+ TX_CSUM_TCPIP6 : TX_CSUM_TCPIP) |
+ TXPKT_IPHDR_LEN_V(l3hdr_len);
+ txq->tso++;
+ txq->tx_cso += ssi->gso_segs;
+ } else {
+ int len;
+
+ len = (t4vf_is_eth_imm(skb)
+ ? skb->len + sizeof(*cpl)
+ : sizeof(*cpl));
+ wr->op_immdlen =
+ cpu_to_be32(FW_WR_OP_V(FW_ETH_TX_PKT_VM_WR) |
+ FW_WR_IMMDLEN_V(len));
+
+ /* Set up TX Packet CPL pointer, control word and perform
+ * accounting.
+ */
+ cpl = (void *)(wr + 1);
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ cntrl = hwcsum(adapter->params.chip, skb) |
+ TXPKT_IPCSUM_DIS_F;
+ txq->tx_cso++;
+ } else {
+ cntrl = TXPKT_L4CSUM_DIS_F | TXPKT_IPCSUM_DIS_F;
+ }
+ }
+
+ /* If there's a VLAN tag present, add that to the list of things to
+ * do in this Work Request.
+ */
+ if (skb_vlan_tag_present(skb)) {
+ txq->vlan_ins++;
+ cntrl |= TXPKT_VLAN_VLD_F | TXPKT_VLAN_V(skb_vlan_tag_get(skb));
+ }
+
+ /* Fill in the TX Packet CPL message header. */
+ cpl->ctrl0 = cpu_to_be32(TXPKT_OPCODE_V(CPL_TX_PKT_XT) |
+ TXPKT_INTF_V(pi->port_id) |
+ TXPKT_PF_V(0));
+ cpl->pack = cpu_to_be16(0);
+ cpl->len = cpu_to_be16(skb->len);
+ cpl->ctrl1 = cpu_to_be64(cntrl);
+
+ /* Fill in the body of the TX Packet CPL message with either in-lined
+ * data or a Scatter/Gather List.
+ */
+ if (t4vf_is_eth_imm(skb)) {
+ /* In-line the packet's data and free the skb since we don't
+ * need it any longer.
+ */
+ cxgb4_inline_tx_skb(skb, &txq->q, cpl + 1);
+ dev_consume_skb_any(skb);
+ } else {
+ /* Write the skb's Scatter/Gather list into the TX Packet CPL
+ * message and retain a pointer to the skb so we can free it
+ * later when its DMA completes. (We store the skb pointer
+ * in the Software Descriptor corresponding to the last TX
+ * Descriptor used by the Work Request.)
+ *
+ * The retained skb will be freed when the corresponding TX
+ * Descriptors are reclaimed after their DMAs complete.
+ * However, this could take quite a while since, in general,
+ * the hardware is set up to be lazy about sending DMA
+ * completion notifications to us and we mostly perform TX
+ * reclaims in the transmit routine.
+ *
+ * This is good for performamce but means that we rely on new
+ * TX packets arriving to run the destructors of completed
+ * packets, which open up space in their sockets' send queues.
+ * Sometimes we do not get such new packets causing TX to
+ * stall. A single UDP transmitter is a good example of this
+ * situation. We have a clean up timer that periodically
+ * reclaims completed packets but it doesn't run often enough
+ * (nor do we want it to) to prevent lengthy stalls. A
+ * solution to this problem is to run the destructor early,
+ * after the packet is queued but before it's DMAd. A con is
+ * that we lie to socket memory accounting, but the amount of
+ * extra memory is reasonable (limited by the number of TX
+ * descriptors), the packets do actually get freed quickly by
+ * new packets almost always, and for protocols like TCP that
+ * wait for acks to really free up the data the extra memory
+ * is even less. On the positive side we run the destructors
+ * on the sending CPU rather than on a potentially different
+ * completing CPU, usually a good thing.
+ *
+ * Run the destructor before telling the DMA engine about the
+ * packet to make sure it doesn't complete and get freed
+ * prematurely.
+ */
+ struct ulptx_sgl *sgl = (struct ulptx_sgl *)(cpl + 1);
+ struct sge_txq *tq = &txq->q;
+ int last_desc;
+
+ /* If the Work Request header was an exact multiple of our TX
+ * Descriptor length, then it's possible that the starting SGL
+ * pointer lines up exactly with the end of our TX Descriptor
+ * ring. If that's the case, wrap around to the beginning
+ * here ...
+ */
+ if (unlikely((void *)sgl == (void *)tq->stat)) {
+ sgl = (void *)tq->desc;
+ end = (void *)((void *)tq->desc +
+ ((void *)end - (void *)tq->stat));
+ }
+
+ cxgb4_write_sgl(skb, tq, sgl, end, 0, addr);
+ skb_orphan(skb);
+
+ last_desc = tq->pidx + ndesc - 1;
+ if (last_desc >= tq->size)
+ last_desc -= tq->size;
+ tq->sdesc[last_desc].skb = skb;
+ tq->sdesc[last_desc].sgl = sgl;
+ }
+
+ /* Advance our internal TX Queue state, tell the hardware about
+ * the new TX descriptors and return success.
+ */
+ txq_advance(&txq->q, ndesc);
+
+ cxgb4_ring_tx_db(adapter, &txq->q, ndesc);
+ return NETDEV_TX_OK;
+
+out_free:
+ /* An error of some sort happened. Free the TX skb and tell the
+ * OS that we've "dealt" with the packet ...
+ */
+ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
+}
+
+netdev_tx_t t4_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct port_info *pi = netdev_priv(dev);
+
+ if (unlikely(pi->eth_flags & PRIV_FLAG_PORT_TX_VM))
+ return t4vf_eth_xmit(skb, dev);
+
+ return t4_eth_xmit(skb, dev);
+}
+
/**
* reclaim_completed_tx_imm - reclaim completed control-queue Tx descs
* @q: the SGE control Tx queue
--
2.1.0
^ permalink raw reply related
* [PATCH net-next 2/2] cxgb4: Support ethtool private flags
From: Ganesh Goudar @ 2018-05-14 7:55 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Arjun Vynipadath, Casey Leedom,
Ganesh Goudar
From: Arjun Vynipadath <arjun@chelsio.com>
This is used to change TX workrequests, which helps in
host->vf communication.
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c | 42 ++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c
index 59d04d7..1d979a6 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c
@@ -177,6 +177,10 @@ static char loopback_stats_strings[][ETH_GSTRING_LEN] = {
"bg3_frames_trunc ",
};
+static const char cxgb4_priv_flags_strings[][ETH_GSTRING_LEN] = {
+ [PRIV_FLAG_PORT_TX_VM_BIT] = "port_tx_vm_wr",
+};
+
static int get_sset_count(struct net_device *dev, int sset)
{
switch (sset) {
@@ -185,6 +189,8 @@ static int get_sset_count(struct net_device *dev, int sset)
ARRAY_SIZE(adapter_stats_strings) +
ARRAY_SIZE(channel_stats_strings) +
ARRAY_SIZE(loopback_stats_strings);
+ case ETH_SS_PRIV_FLAGS:
+ return ARRAY_SIZE(cxgb4_priv_flags_strings);
default:
return -EOPNOTSUPP;
}
@@ -235,6 +241,7 @@ static void get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
FW_HDR_FW_VER_MINOR_G(exprom_vers),
FW_HDR_FW_VER_MICRO_G(exprom_vers),
FW_HDR_FW_VER_BUILD_G(exprom_vers));
+ info->n_priv_flags = ARRAY_SIZE(cxgb4_priv_flags_strings);
}
static void get_strings(struct net_device *dev, u32 stringset, u8 *data)
@@ -250,6 +257,9 @@ static void get_strings(struct net_device *dev, u32 stringset, u8 *data)
data += sizeof(channel_stats_strings);
memcpy(data, loopback_stats_strings,
sizeof(loopback_stats_strings));
+ } else if (stringset == ETH_SS_PRIV_FLAGS) {
+ memcpy(data, cxgb4_priv_flags_strings,
+ sizeof(cxgb4_priv_flags_strings));
}
}
@@ -1503,6 +1513,36 @@ static int cxgb4_get_module_eeprom(struct net_device *dev,
offset, len, &data[eprom->len - len]);
}
+static u32 cxgb4_get_priv_flags(struct net_device *netdev)
+{
+ struct port_info *pi = netdev_priv(netdev);
+ struct adapter *adapter = pi->adapter;
+
+ return (adapter->eth_flags | pi->eth_flags);
+}
+
+/**
+ * set_flags - set/unset specified flags if passed in new_flags
+ * @cur_flags: pointer to current flags
+ * @new_flags: new incoming flags
+ * @flags: set of flags to set/unset
+ */
+static inline void set_flags(u32 *cur_flags, u32 new_flags, u32 flags)
+{
+ *cur_flags = (*cur_flags & ~flags) | (new_flags & flags);
+}
+
+static int cxgb4_set_priv_flags(struct net_device *netdev, u32 flags)
+{
+ struct port_info *pi = netdev_priv(netdev);
+ struct adapter *adapter = pi->adapter;
+
+ set_flags(&adapter->eth_flags, flags, PRIV_FLAGS_ADAP);
+ set_flags(&pi->eth_flags, flags, PRIV_FLAGS_PORT);
+
+ return 0;
+}
+
static const struct ethtool_ops cxgb_ethtool_ops = {
.get_link_ksettings = get_link_ksettings,
.set_link_ksettings = set_link_ksettings,
@@ -1539,6 +1579,8 @@ static const struct ethtool_ops cxgb_ethtool_ops = {
.get_dump_data = get_dump_data,
.get_module_info = cxgb4_get_module_info,
.get_module_eeprom = cxgb4_get_module_eeprom,
+ .get_priv_flags = cxgb4_get_priv_flags,
+ .set_priv_flags = cxgb4_set_priv_flags,
};
void cxgb4_set_ethtool_ops(struct net_device *netdev)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
From: Maxime Ripard @ 2018-05-14 8:03 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
Stephen Boyd, netdev, Michael Turquette, Rob Herring,
Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk
In-Reply-To: <CAGb2v64xTNqQQSppw2NZoLn+ViQNQLytn1EukLqw+HJzf1=5ig@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3965 bytes --]
1;5201;0c
On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
> >> ><maxime.ripard@bootlin.com> wrote:
> >> >> Hi,
> >> >>
> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
> >> >>>
> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
> >> >currently
> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
> >> >>> register. As SRAM controller driver can now export regmap for this
> >> >>> register, replace the syscon node to the SRAM controller device
> >> >node,
> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
> >> >>>
> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> >>> ---
> >> >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
> >> >+++++++++++++++----
> >> >>> 1 file changed, 19 insertions(+), 4 deletions(-)
> >> >>>
> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> @@ -168,10 +168,25 @@
> >> >>> #size-cells = <1>;
> >> >>> ranges;
> >> >>>
> >> >>> - syscon: syscon@1c00000 {
> >> >>> - compatible =
> >> >"allwinner,sun50i-a64-system-controller",
> >> >>> - "syscon";
> >> >>> + sram_controller: sram-controller@1c00000 {
> >> >>> + compatible =
> >> >"allwinner,sun50i-a64-sram-controller";
> >> >>
> >> >> I don't think there's anything preventing us from keeping the
> >> >> -system-controller compatible. It's what was in the DT before, and
> >> >> it's how it's called in the datasheet.
> >> >
> >> >I actually meant to ask you about this. The -system-controller
> >> >compatible matches the datasheet better. Maybe we should just
> >> >switch to that one?
> >>
> >> No, if we do the switch the system-controller compatible,
> >> the device will be probed on the same memory region with
> >> a syscon on old DTs.
> >
> > The device hasn't magically changed either. Maybe we just need to add
> > a check to make sure we don't have the syscon compatible in the SRAM
> > driver probe so that the double driver issue doesn't happen?
>
> The syscon interface (which is not even a full blown device driver)
> only looks at the "syscon" compatible. Either way we're removing that
> part from the device tree so things should be ok for new device trees.
> As Maxime mentioned we can do a check for the syscon compatible and
> either give a warning to the user asking them to update their device
> tree, or not register our custom regmap, or not probe the SRAM driver.
> Personally I prefer the first option. The system controller block is
> probed before any syscon users, so we should be fine, given the dwmac
> driver goes the custom regmap path first.
>
> BTW, I still might end up changing the compatible. The manual uses
> "system control", not "system controller", which I think makes sense,
> since it is just a bunch of register files, kind of like the GRF
> (General Register Files) block found in Rockchip SoCs [1], and not an
> actual "controller".
I'm not really fond of that, but we should at least make it consistent
on the other patches Paul sent then.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given
From: Antoine Tenart @ 2018-05-14 8:11 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20180508123026.GJ16141@n2100.armlinux.org.uk>
Hi Russell,
On Tue, May 08, 2018 at 01:30:26PM +0100, Russell King - ARM Linux wrote:
>
> The electronic engineer in me says that using zero isn't really valid
> because there are coupling capacitors in the SFP module that block DC.
> These blocking capacitors are required by the SFP+ specs to have a high
> pass pole of between 20kHz and 100kHz - in other words, frequencies
> below this are attenuated by the coupling capacitors. The relationship
> between this and the bit rate will be a function of the encoding, so we
> can't come to a definitive figure without some math (and I want to be
> lazy about that!)
>
> Practically, we're talking about SerDes Ethernet, where the bit rate is
> no lower than 100Mbps [*], which will always have a frequency well above
> this cut-off. So, I don't have any problem with your approach to
> setting the minimum to zero. Therefore,
>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks for looking into it!
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* (unknown),
From: системы администратор @ 2018-05-14 6:33 UTC (permalink / raw)
пользователь веб-почты
Обратите внимание, что 95% ваших писем, полученных после обновления сервера веб-почты в последнее время в нашей базе данных, были отложены. Регулярно получать и отправлять свои сообщения. Техническая команда нашей веб-почты обновит вашу учетную запись в течение 3 рабочих дней. Если вы этого не сделаете, ваша учетная запись будет временно приостановлена нашими службами. Чтобы повторно подтвердить свой почтовый ящик, пришлите следующую информацию:
обычный:
Имя пользователя:
пароль:
Подтвердите Пароль:
Предупреждение!! Если это не позволит обновлять учетные записи в
течение двух дней после получения электронной почты, они будут
постоянно потерять учетные записи владельцев учетных записей
веб-почты.
Спасибо за ваше сотрудничество!
Copyright © 2017-2018 Служба технической поддержки WebMail, Inc.
^ permalink raw reply
* [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Marco Felsch @ 2018-05-14 8:22 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, Markus Niebel
From: Markus Niebel <Markus.Niebel@tqs.de>
handle errata #2 for KSZ9031: force 1000Base-T master
Attention: enabling the workaround will cause no link to
other GIGE master.
Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
[m.felsch@pengutronix.de: move dt binding to the KSZ9031 entry]
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
.../devicetree/bindings/net/micrel-ksz90x1.txt | 3 +++
drivers/net/phy/micrel.c | 18 ++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index 42a248301615..e2465fbbbcef 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -57,6 +57,9 @@ KSZ9031:
- txd2-skew-ps : Skew control of TX data 2 pad
- txd3-skew-ps : Skew control of TX data 3 pad
+ - force-master: Boolean, force phy to master mode. This is a
+ workaround at least for KSZ9031 errata #2.
+
Examples:
mdio {
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f41b224a9cdb..3e4243e4f7a7 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -528,6 +528,8 @@ static int ksz9031_enable_edpd(struct phy_device *phydev)
static int ksz9031_config_init(struct phy_device *phydev)
{
+ int rc;
+ u16 val;
const struct device *dev = &phydev->mdio.dev;
const struct device_node *of_node = dev->of_node;
static const char *clk_skews[2] = {"rxc-skew-ps", "txc-skew-ps"};
@@ -573,6 +575,22 @@ static int ksz9031_config_init(struct phy_device *phydev)
ksz9031_of_load_skew_values(phydev, of_node,
MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
tx_data_skews, 4);
+
+ /* force master mode -> errata #2
+ * attention: Master <-> Master will not work
+ */
+ if (of_property_read_bool(of_node, "force-master")) {
+ rc = phy_read(phydev, MII_CTRL1000);
+ if (rc >= 0) {
+ val = (u16)rc;
+ /* enable master mode, config &
+ * prefer master
+ */
+ val |= (CTL1000_ENABLE_MASTER |
+ CTL1000_AS_MASTER);
+ phy_write(phydev, MII_CTRL1000, val);
+ }
+ }
}
return ksz9031_center_flp_timing(phydev);
--
2.17.0
^ permalink raw reply related
* Re: [PATCH bpf-next] samples/bpf: xdp_monitor, accept short options
From: Prashant Bhole @ 2018-05-14 8:28 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Daniel Borkmann, Alexei Starovoitov, David S . Miller, netdev
In-Reply-To: <20180511183125.6b4f92e2@redhat.com>
On 5/12/2018 1:31 AM, Jesper Dangaard Brouer wrote:
> On Fri, 11 May 2018 10:37:51 +0900
> Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> wrote:
>
>> updated optstring accept short options
>>
>> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
>> ---
>> samples/bpf/xdp_monitor_user.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/samples/bpf/xdp_monitor_user.c b/samples/bpf/xdp_monitor_user.c
>> index 894bc64c2cac..668511c77aaf 100644
>> --- a/samples/bpf/xdp_monitor_user.c
>> +++ b/samples/bpf/xdp_monitor_user.c
>> @@ -594,7 +594,7 @@ int main(int argc, char **argv)
>> snprintf(bpf_obj_file, sizeof(bpf_obj_file), "%s_kern.o", argv[0]);
>>
>> /* Parse commands line args */
>> - while ((opt = getopt_long(argc, argv, "h",
>> + while ((opt = getopt_long(argc, argv, "hDSs:",
>> long_options, &longindex)) != -1) {
>> switch (opt) {
>> case 'D':
>
> It was actually on purpose that I didn't add the short options,
> in-order to force people use those "self-documenting" long-options when
> they show the usage on public mailing lists or in blog-posts.
Got it.
>
> If you want these short options, you also have to correct the "usage"
> function that state these are "internal" short-options.
I am submitting v2 with "usage" updated, because with usability point of
view it is nice to have short options. Thanks.
-Prashant
>
> Notice the long options parsing done by getopt_long() allow you to only
> specify part of the string. Al-through, I can see --s is ambiguous.
>
> $ sudo ./xdp_monitor --s
> ./xdp_monitor: option '--s' is ambiguous; possibilities: '--stats' '--sec'
^ permalink raw reply
* [PATCH bpf-next v2] samples/bpf: xdp_monitor, accept short options
From: Prashant Bhole @ 2018-05-14 8:29 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov
Cc: Prashant Bhole, Jesper Dangaard Brouer, David S . Miller, netdev
Updated optstring parameter for getopt_long() to accept short options.
Also updated usage() function.
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
samples/bpf/xdp_monitor_user.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/samples/bpf/xdp_monitor_user.c b/samples/bpf/xdp_monitor_user.c
index 894bc64c2cac..05ad3f590c91 100644
--- a/samples/bpf/xdp_monitor_user.c
+++ b/samples/bpf/xdp_monitor_user.c
@@ -58,7 +58,7 @@ static void usage(char *argv[])
printf(" flag (internal value:%d)",
*long_options[i].flag);
else
- printf("(internal short-option: -%c)",
+ printf("short-option: -%c",
long_options[i].val);
printf("\n");
}
@@ -594,7 +594,7 @@ int main(int argc, char **argv)
snprintf(bpf_obj_file, sizeof(bpf_obj_file), "%s_kern.o", argv[0]);
/* Parse commands line args */
- while ((opt = getopt_long(argc, argv, "h",
+ while ((opt = getopt_long(argc, argv, "hDSs:",
long_options, &longindex)) != -1) {
switch (opt) {
case 'D':
--
2.13.6
^ permalink raw reply related
* Re: [PATCH net-next v2 06/13] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2018-05-14 8:37 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180508123408.GK16141@n2100.armlinux.org.uk>
Hi Russell,
On Tue, May 08, 2018 at 01:34:08PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 04, 2018 at 03:56:36PM +0200, Antoine Tenart wrote:
> > This patch adds one more generic PHY mode to the phy_mode enum, to allow
> > configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
> > callback.
> >
> > Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> > Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> Would it be possible to get the 2.5G SGMII comphy support merged
> ahead of the rest of this series please - I don't think there's been
> any objections to it, and having it in mainline would then mean I can
> drop the Marvell Comphy code from my tree and transition to the bootlin
> Comphy code instead.
>
> Of course, the perfect solution would be to get the whole series merged,
> but I'm just thinking about the situation where we're still discussing
> points when the next merge window opens.
That would be great, and there are no dependency issue if patches 6 and
7 are taken ahead.
Kishon: since there are no objection to these two phy patches, could you
take them?
Thanks!
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net] xfrm6: avoid potential infinite loop in _decode_session6()
From: Steffen Klassert @ 2018-05-14 8:41 UTC (permalink / raw)
To: David Miller; +Cc: edumazet, netdev, eric.dumazet, nicolas.dichtel
In-Reply-To: <20180513.202349.1985276646648462963.davem@davemloft.net>
On Sun, May 13, 2018 at 08:23:49PM -0400, David Miller wrote:
> From: Eric Dumazet <edumazet@google.com>
> Date: Sat, 12 May 2018 02:49:30 -0700
>
> > syzbot found a way to trigger an infinitie loop by overflowing
> > @offset variable that has been forced to use u16 for some very
> > obscure reason in the past.
> >
> > We probably want to look at NEXTHDR_FRAGMENT handling which looks
> > wrong, in a separate patch.
> >
> > In net-next, we shall try to use skb_header_pointer() instead of
> > pskb_may_pull().
> ...
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Steffen Klassert <steffen.klassert@secunet.com>
> > Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > Reported-by: syzbot+0053c8...@syzkaller.appspotmail.com
>
> Steffen, I am assuming you will pick this up.
Yes, now applied to the ipsec tree.
Thanks a lot Eric!
^ permalink raw reply
* 答复: [PATCH] ipvlan: flush arp table when mac address changed
From: liuqifa @ 2018-05-14 8:49 UTC (permalink / raw)
To: Paolo Abeni, davem@davemloft.net, dsahern@gmail.com,
maheshb@google.com, weiyongjun (A), maowenan, Dingtianhong
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1526283581.4411.2.camel@redhat.com>
Hi,
>
> Hi,
>
> On Sat, 2018-05-12 at 19:00 +0800, liuqifa@huawei.com wrote:
> > From: Keefe Liu <liuqifa@huawei.com>
> >
> > When master device's mac has been changed, the commit <32c10bbfe914>
> > "ipvlan: always use the current L2 addr of the master" makes the
> > IPVlan devices's mac changed also, but it doesn't flush the IPVlan's
> > arp table.
> >
> > Signed-off-by: Keefe Liu <liuqifa@huawei.com>
> > ---
> > drivers/net/ipvlan/ipvlan_main.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ipvlan/ipvlan_main.c
> > b/drivers/net/ipvlan/ipvlan_main.c
> > index 450eec2..a1edfe1 100644
> > --- a/drivers/net/ipvlan/ipvlan_main.c
> > +++ b/drivers/net/ipvlan/ipvlan_main.c
> > @@ -7,6 +7,8 @@
> > *
> > */
> >
> > +#include <net/neighbour.h>
> > +#include <net/arp.h>
> > #include "ipvlan.h"
> >
> > static unsigned int ipvlan_netid __read_mostly; @@ -792,8 +794,10 @@
> > static int ipvlan_device_event(struct notifier_block *unused,
> > break;
> >
> > case NETDEV_CHANGEADDR:
> > - list_for_each_entry(ipvlan, &port->ipvlans, pnode)
> > + list_for_each_entry(ipvlan, &port->ipvlans, pnode) {
> > ether_addr_copy(ipvlan->dev->dev_addr, dev-
> >dev_addr);
> > + neigh_changeaddr(&arp_tbl, ipvlan->dev);
> > + }
>
> Why don't using:
>
> call_netdevice_notifiers(NETDEV_CHANGEADDR, ipvlan->dev);
>
> instead?
>
> that is what other stacked device - bridge and vlans - are currently doing in
> the same scenario.
>
> Thanks,
>
> Paolo
>
Yes, I agre with you, this is a better solution.
Thanks
Keefe
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Uwe Kleine-König @ 2018-05-14 9:05 UTC (permalink / raw)
To: Marco Felsch
Cc: robh+dt, mark.rutland, andrew, f.fainelli, netdev, Markus Niebel,
kernel, devicetree
In-Reply-To: <20180514082218.29158-1-m.felsch@pengutronix.de>
Hello,
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index f41b224a9cdb..3e4243e4f7a7 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -528,6 +528,8 @@ static int ksz9031_enable_edpd(struct phy_device *phydev)
>
> static int ksz9031_config_init(struct phy_device *phydev)
> {
> + int rc;
> + u16 val;
These could be declared in more local scope.
> const struct device *dev = &phydev->mdio.dev;
> const struct device_node *of_node = dev->of_node;
> static const char *clk_skews[2] = {"rxc-skew-ps", "txc-skew-ps"};
> @@ -573,6 +575,22 @@ static int ksz9031_config_init(struct phy_device *phydev)
> ksz9031_of_load_skew_values(phydev, of_node,
> MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
> tx_data_skews, 4);
> +
> + /* force master mode -> errata #2
> + * attention: Master <-> Master will not work
> + */
> + if (of_property_read_bool(of_node, "force-master")) {
> + rc = phy_read(phydev, MII_CTRL1000);
> + if (rc >= 0) {
> + val = (u16)rc;
> + /* enable master mode, config &
> + * prefer master
> + */
> + val |= (CTL1000_ENABLE_MASTER |
> + CTL1000_AS_MASTER);
> + phy_write(phydev, MII_CTRL1000, val);
There is no need for two variables, just use a single int variable that
on all Linux archs can hold the whole domain of u16 should be fine.
> + }
> + }
Maybe issue a warning if reading MII_CTRL1000 failed?
> }
>
> return ksz9031_center_flp_timing(phydev);
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH net-next v9 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-05-14 9:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, cake
In-Reply-To: <20180513.200948.1658763899383204062.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Toke Høiland-Jørgensen <toke@toke.dk>
> Date: Tue, 08 May 2018 16:34:19 +0200
>
>> +struct cake_flow {
>> + /* this stuff is all needed per-flow at dequeue time */
>> + struct sk_buff *head;
>> + struct sk_buff *tail;
>
> Please do not invent your own SKB list handling mechanism.
We didn't invent it, we inherited it from fq_codel. I was actually about
to fix that, but then I noticed it was still around in fq_codel, and so
let it be. I can certainly fix it anyway, but, erm, why is it acceptable
in fq_codel but not in cake? struct sk_buff_head is not that new, is it?
>> +static void cake_heapify(struct cake_sched_data *q, u16 i)
>> +{
>> + static const u32 a = CAKE_MAX_TINS * CAKE_QUEUES;
>> + u32 m = i;
>> + u32 mb = cake_heap_get_backlog(q, m);
>
> Please order local variables from longest to shortest line.
>
> The entire submissions has this problem all over the place, please
> correct it patch-series wide.
Right-oh, one plantation of reverse christmas trees coming right up :)
-Toke
^ permalink raw reply
* Re: [PATCH v2] net/mlx4_core: Fix error handling in mlx4_init_port_info.
From: Tariq Toukan @ 2018-05-14 9:08 UTC (permalink / raw)
To: Tarick Bedeir, tariqt, gthelen, netdev, linux-rdma, linux-kernel,
David Miller
In-Reply-To: <20180513233845.135290-1-tarick@google.com>
On 14/05/2018 2:38 AM, Tarick Bedeir wrote:
> Avoid exiting the function with a lingering sysfs file (if the first
> call to device_create_file() fails while the second succeeds), and avoid
> calling devlink_port_unregister() twice.
>
> In other words, either mlx4_init_port_info() succeeds and returns zero, or
> it fails, returns non-zero, and requires no cleanup.
>
> Fixes: 096335b3f983 ("mlx4_core: Allow dynamic MTU configuration for IB
> ports")
> Signed-off-by: Tarick Bedeir <tarick@google.com>
> ---
> v1 -> v2: Added "Fixes" tag.
> ---
> drivers/net/ethernet/mellanox/mlx4/main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
> index 4d84cab77105..e8a3a45d0b53 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/main.c
> @@ -3007,6 +3007,7 @@ static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
> mlx4_err(dev, "Failed to create file for port %d\n", port);
> devlink_port_unregister(&info->devlink_port);
> info->port = -1;
> + return err;
> }
>
> sprintf(info->dev_mtu_name, "mlx4_port%d_mtu", port);
> @@ -3028,9 +3029,10 @@ static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
> &info->port_attr);
> devlink_port_unregister(&info->devlink_port);
> info->port = -1;
> + return err;
> }
>
> - return err;
> + return 0;
> }
>
> static void mlx4_cleanup_port_info(struct mlx4_port_info *info)
>
Thanks for you patch.
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Dave, please queue for -stable.
Best,
Tariq
^ permalink raw reply
* [PATCH v2] ipvlan: flush arp table when mac address changed
From: liuqifa @ 2018-05-14 9:22 UTC (permalink / raw)
To: davem, dsahern, maheshb, weiyongjun1, maowenan, dingtianhong,
liuqifa
Cc: netdev, linux-kernel
From: Keefe Liu <liuqifa@huawei.com>
When master device's mac has been changed, the
commit <32c10bbfe914> "ipvlan: always use the current L2
addr of the master" makes the IPVlan devices's mac changed
also, but it doesn't flush the IPVlan's arp table.
Signed-off-by: Keefe Liu <liuqifa@huawei.com>
---
drivers/net/ipvlan/ipvlan_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index 450eec2..4377c26 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -792,8 +792,10 @@ static int ipvlan_device_event(struct notifier_block *unused,
break;
case NETDEV_CHANGEADDR:
- list_for_each_entry(ipvlan, &port->ipvlans, pnode)
+ list_for_each_entry(ipvlan, &port->ipvlans, pnode) {
ether_addr_copy(ipvlan->dev->dev_addr, dev->dev_addr);
+ call_netdevice_notifiers(NETDEV_CHANGEADDR, ipvlan->dev);
+ }
break;
case NETDEV_PRE_TYPE_CHANGE:
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next v2 02/13] net: phy: sfp: handle non-wired SFP connectors
From: Antoine Tenart @ 2018-05-14 9:26 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180508115247.GF16141@n2100.armlinux.org.uk>
Hi Russell,
On Tue, May 08, 2018 at 12:52:47PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote:
> > SFP connectors can be solder on a board without having any of their pins
> > (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> > and the overall link status reporting is left to other layers.
> >
> > In order to achieve this, a new SFP_DEV status is added, named UNKNOWN.
> > This mode is set when it is not possible for the SFP code to get the
> > link status and as a result the link status is reported to be always UP
> > from the SFP point of view.
>
> This looks weird to me. SFP_DEV_* states track the netdevice up/down
> state and have little to do with whether LOS or MODDEF0 are implemented.
That's right.
> I think it would be better to have a new SFP_MOD_* and to force
> sm_mod_state to that in this circumstance.
The idea was to avoid depending on the state machine, as this could be
difficult to maintain in the future (it's hard to tell exactly what are
all the possible paths). But I get your point about SFP_DEV_.
I can have a look at adding a new SFP_MOD_, or I could add a broken flag
into 'struct sfp', although having a SFP_MOD_ would be proper.
Before doing so, we should decide whether or not this approach is valid,
as there were comments from Florian and Andrew asking for a fixed-link
solution. I think fixed-link wouldn't be perfect from the user point of
view, but I understand the point. If we go with fixed-link, then this
patch can be dropped (the two others net: sfp: patches could be kept).
What do you think?
Thanks,
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH net-next] net: stmmac: Add Jose Abreu as co-maintainer
From: Jose Abreu @ 2018-05-14 9:29 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, David S. Miller, Joao Pinto, Alexandre Torgue,
Giuseppe Cavallaro
I'm offering to be a co-maintainer for stmmac driver.
As per discussion with Alexandre, I will arranje to get STM32 boards to
test patches in GMAC version 3.x and 4.1. I also have HW to test GMAC
version 5.
Looking forward to contribute to net-dev!
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
MAINTAINERS | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cecf461..c6989d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13385,6 +13385,7 @@ F: drivers/media/usb/stk1160/
STMMAC ETHERNET DRIVER
M: Giuseppe Cavallaro <peppe.cavallaro@st.com>
M: Alexandre Torgue <alexandre.torgue@st.com>
+M: Jose Abreu <joabreu@synopsys.com>
L: netdev@vger.kernel.org
W: http://www.stlinux.com
S: Supported
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next] net: stmmac: Add Jose Abreu as co-maintainer
From: Alexandre Torgue @ 2018-05-14 9:36 UTC (permalink / raw)
To: Jose Abreu, netdev; +Cc: David S. Miller, Joao Pinto, Giuseppe Cavallaro
In-Reply-To: <06350075c76ee1c13f84c94346444507e9770ed2.1526290012.git.joabreu@synopsys.com>
On 05/14/2018 11:29 AM, Jose Abreu wrote:
> I'm offering to be a co-maintainer for stmmac driver.
>
> As per discussion with Alexandre, I will arranje to get STM32 boards to
> test patches in GMAC version 3.x and 4.1. I also have HW to test GMAC
> version 5.
>
> Looking forward to contribute to net-dev!
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> MAINTAINERS | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cecf461..c6989d0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13385,6 +13385,7 @@ F: drivers/media/usb/stk1160/
> STMMAC ETHERNET DRIVER
> M: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> M: Alexandre Torgue <alexandre.torgue@st.com>
> +M: Jose Abreu <joabreu@synopsys.com>
> L: netdev@vger.kernel.org
> W: http://www.stlinux.com
> S: Supported
>
Thanks for this proposition.
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Sergei Shtylyov @ 2018-05-14 9:41 UTC (permalink / raw)
To: Marco Felsch, robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, Markus Niebel
In-Reply-To: <20180514082218.29158-1-m.felsch@pengutronix.de>
Hello!
On 5/14/2018 11:22 AM, Marco Felsch wrote:
> From: Markus Niebel <Markus.Niebel@tqs.de>
>
> handle errata #2 for KSZ9031: force 1000Base-T master
>
> Attention: enabling the workaround will cause no link to
> other GIGE master.
>
> Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
> [m.felsch@pengutronix.de: move dt binding to the KSZ9031 entry]
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
[...]
> @@ -573,6 +575,22 @@ static int ksz9031_config_init(struct phy_device *phydev)
> ksz9031_of_load_skew_values(phydev, of_node,
> MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
> tx_data_skews, 4);
> +
> + /* force master mode -> errata #2
> + * attention: Master <-> Master will not work
> + */
> + if (of_property_read_bool(of_node, "force-master")) {
> + rc = phy_read(phydev, MII_CTRL1000);
> + if (rc >= 0) {
> + val = (u16)rc;
> + /* enable master mode, config &
> + * prefer master
> + */
> + val |= (CTL1000_ENABLE_MASTER |
> + CTL1000_AS_MASTER);
Parens not needed.
> + phy_write(phydev, MII_CTRL1000, val);
> + }
> + }
> }
>
> return ksz9031_center_flp_timing(phydev);
>
MBR, Sergei
^ permalink raw reply
* Greetings
From: Ms Sophie Gabrielle @ 2018-05-14 9:42 UTC (permalink / raw)
My sincere greetings,
My Name is Ms Sophie Gabrielle, 19 years old single girl, the only child
and daughter of late Mr & Mrs Edward Anthony a Togolese by origin,
presently i am writing to you from Togo the capital of Togo. I was
impressed when i saw your contact. i have 5.5 million US dollars which
i inherited, i will like you to assist me in the claim and transfer of
the money into your bank account and as well establish a long lasting
investment partnership with you. Can you contact me back? Waiting to
hear from you soonest.
With love.
Ms Sophie Gabrielle
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Sergei Shtylyov @ 2018-05-14 9:42 UTC (permalink / raw)
To: Marco Felsch, robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, Markus Niebel
In-Reply-To: <20180514082218.29158-1-m.felsch@pengutronix.de>
On 5/14/2018 11:22 AM, Marco Felsch wrote:
> From: Markus Niebel <Markus.Niebel@tqs.de>
>
> handle errata #2 for KSZ9031: force 1000Base-T master
>
> Attention: enabling the workaround will cause no link to
> other GIGE master.
>
> Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
> [m.felsch@pengutronix.de: move dt binding to the KSZ9031 entry]
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
> .../devicetree/bindings/net/micrel-ksz90x1.txt | 3 +++
> drivers/net/phy/micrel.c | 18 ++++++++++++++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> index 42a248301615..e2465fbbbcef 100644
> --- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> +++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
> @@ -57,6 +57,9 @@ KSZ9031:
> - txd2-skew-ps : Skew control of TX data 2 pad
> - txd3-skew-ps : Skew control of TX data 3 pad
>
> + - force-master: Boolean, force phy to master mode. This is a
Not "micrel,force-master"?
> + workaround at least for KSZ9031 errata #2.
> +
> Examples:
>
> mdio {
[...]
MBR, Sergei
^ 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