* Re: [PATCH] cxgbit: use T6 specific macro to set force bit
From: Varun Prakash @ 2017-01-25 6:21 UTC (permalink / raw)
To: David Miller
Cc: bart.vanassche@sandisk.com, target-devel@vger.kernel.org,
netdev@vger.kernel.org, Indranil Choudhury
In-Reply-To: <20170124.152616.964714349603826115.davem@davemloft.net>
On Wed, Jan 25, 2017 at 01:56:16AM +0530, David Miller wrote:
> From: Varun Prakash <varun@chelsio.com>
> Date: Tue, 24 Jan 2017 17:07:02 +0530
>
> > For T6 adapters use T6 specific macro to set
> > force bit.
> >
> > Signed-off-by: Varun Prakash <varun@chelsio.com>
>
> What tree is this for?
>
> You must always indicate this in your PATCH subject text.
Sorry, I missed it. This patch is for Bart's target tree.
^ permalink raw reply
* Re: [PATCH] cxgbit: use T6 specific macro to set force bit
From: Varun Prakash @ 2017-01-25 6:38 UTC (permalink / raw)
To: Joe Perches
Cc: bart.vanassche@sandisk.com, target-devel@vger.kernel.org,
netdev@vger.kernel.org, Indranil Choudhury
In-Reply-To: <1485292300.12563.41.camel@perches.com>
On Wed, Jan 25, 2017 at 02:41:40AM +0530, Joe Perches wrote:
> On Tue, 2017-01-24 at 17:07 +0530, Varun Prakash wrote:
> > For T6 adapters use T6 specific macro to set
> > force bit.
> []
> > diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h b/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
> []
> > @@ -1349,6 +1349,10 @@ struct cpl_tx_data {
> > #define TX_FORCE_S 13
> > #define TX_FORCE_V(x) ((x) << TX_FORCE_S)
> >
> > +#define T6_TX_FORCE_S 20
> > +#define T6_TX_FORCE_V(x) ((x) << T6_TX_FORCE_S)
> > +#define T6_TX_FORCE_F T6_TX_FORCE_V(1U)
> > +
> > enum {
> > ULP_TX_MEM_READ = 2,
> > ULP_TX_MEM_WRITE = 3,
> > diff --git a/drivers/target/iscsi/cxgbit/cxgbit_target.c b/drivers/target/iscsi/cxgbit/cxgbit_target.c
> []
> > @@ -162,12 +162,14 @@ cxgbit_tx_data_wr(struct cxgbit_sock *csk, struct sk_buff *skb, u32 dlen,
> > u32 len, u32 credits, u32 compl)
> > {
> > struct fw_ofld_tx_data_wr *req;
> > + const struct cxgb4_lld_info *lldi = &csk->com.cdev->lldi;
> > u32 submode = cxgbit_skcb_submode(skb);
> > u32 wr_ulp_mode = 0;
> > u32 hdr_size = sizeof(*req);
> > u32 opcode = FW_OFLD_TX_DATA_WR;
> > u32 immlen = 0;
> > - u32 force = TX_FORCE_V(!submode);
> > + u32 force = is_t5(lldi->adapter_type) ? TX_FORCE_V(!submode) :
> > + T6_TX_FORCE_F;
>
> Perhaps it'd be better to add a is_t6() mechanism so this
> is written in the positive rather than the negative.
>
At present cxgbit driver supports only T5 and T6 adapters so
if a adapter is not T5 then it is T6.
^ permalink raw reply
* A PMTU auto-discovery error for large SCTP packets
From: YUAN Jia @ 2017-01-25 6:40 UTC (permalink / raw)
To: 'linux-sctp@vger.kernel.org', 'network dev'
[-- Attachment #1: Type: text/plain, Size: 3007 bytes --]
Hi All,
Recently, I met a problem of SCTP association broken which was resulted from large SCTP packets as attached in this mail.
Because the 1st packet’s length is 1626 that exceeds the next hop’s MTU of 1500, an ICMP packet of code 4 (Fragmentation needed) reflects back and carries the correct MTU value 1500. However, the mechanism of auto-adjusting PMTU doesn’t work. Having debugged the kernel, I find the ICMP packet is dropped at a pre-routing net filter called ‘nft_chain_nat_ipv4’ due to ‘CONFIG_NFT_CHAIN_NAT_IPV4’ being enabled. Below is the calling sequence:
PATH1: NF_INET_PRE_ROUTING → nft_nat_ipv4_in → nf_nat_ipv4_in → nf_nat_ipv4_fn → nf_nat_icmp_reply_translation → nf_nat_ipv4_manip_pkt
PATH2: NF_INET_PRE_ROUTING → nft_nat_ipv4_in → nf_nat_ipv4_in → nf_nat_ipv4_fn → nf_nat_packet → l3proto->manip_pkt(nf_nat_ipv4_manip_pkt)
COMMON: nf_nat_ipv4_manip_pkt → l4proto->manip_pkt(sctp_manip_pkt) → skb_make_writable
To reach the final function ‘skb_make_writable’ in this calling chain, the ICMP packet and various header pointers can be depicted as below:
MAC(l2) + [VLAN(l2)] + IP(l3) + ICMP(l4) + { payload ⇒ IP + SCTP } And the input parameter ‘hdroff’ now equals to the length from ‘skb->data’ to the SCTP header in the ICMP payload.
So, the statement ‘skb_make_writable(skb, hdroff + sizeof(*hdr))’ assumes that the SCTP header is intact and whole. However, certain network elements (routes, gateways, or something like that) probably send ICMP only containing extra 8 bytes (64 bits) after the IP header of original packet. Just as the attachment shown, the ICMP only contained the source port, destination port and SCTP verification tag of the partial (8 bytes) SCTP header in the previous SCTP packet. Such the case can make ‘skb_make_writable’ return false. And then, the ICMP packet will be dropped. Finally, the upper layer’s ‘err_handler’ would not be triggered to notify SCTP for updating the PMTU.
I compare it with how the TCP protocol is handled. In the file ‘net/netfilter/nf_nat_proto_tcp.c’, there’s also a similar function called ‘tcp_manip_pkt’, and a paragraph of commence describing as below:
int hdrsize = 8; /* TCP connection tracking guarantees this much */
/* this could be a inner header returned in icmp packet; in such
cases we cannot update the checksum field since it is outside of
the 8 bytes of transport layer headers we are guaranteed */
if (skb->len >= hdroff + sizeof(struct tcphdr))
hdrsize = sizeof(struct tcphdr);
if (!skb_make_writable(skb, hdroff + hdrsize))
return false;
……………………… and later …………………………
if (hdrsize < sizeof(*hdr))
return true;
I think that ‘sctp_manip_pkt’ should also behave like this. Isn’t it?
Best regards,
Richard
[-- Attachment #2: icmp_pmtu.pcap --]
[-- Type: application/octet-stream, Size: 1902 bytes --]
[-- Attachment #3: icmp_pmtu.rar --]
[-- Type: application/octet-stream, Size: 1098 bytes --]
^ permalink raw reply
* TT PAYMENT CONFIRMATION - FW: OT16229ZA0620339 - OTT Payment Advice
From: Donna @ 2017-01-25 7:10 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
Attention,
Attached is the payment transferred to your bank account for INV-*****
as directed by our customer to you, we are sorry for the delay.
Please review for your reference PDF id is INVOICEPAYMENT1.
Thanks & Best Regards,
Donna
---------- Forwarded message ----------
From: WELLS FARGO BANK N.A<Ebanking@wellsfargo.net>
Date: Tuesday, Jan 24, 2017 at 4:51 PM
Subject: REMITTANCE
To: Sales Manager
SWIFT Text :- US$ . - Message copy
Instance Type and Transmission -------------- -----------------
Notification (Transmission) of Original sent to SWIFT (ACK)
Network Delivery Status : Network Ack
Priority/Delivery : Normal
--------------------------- Message Header --------------------
[-- Attachment #2: TT-Invoice-payment.pdf --]
[-- Type: application/octet-stream, Size: 31437 bytes --]
^ permalink raw reply
* Re: [PATCH net 1/3] qed: Release CQ resource under lock on failure
From: Yuval Shaia @ 2017-01-25 7:24 UTC (permalink / raw)
To: Yuval Mintz
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Ram.Amrani-YGCgFSpz5w/QT0dZR+AlfA
In-Reply-To: <1485292523-8821-2-git-send-email-Yuval.Mintz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
On Tue, Jan 24, 2017 at 11:15:21PM +0200, Yuval Mintz wrote:
> From: Ram Amrani <Ram.Amrani-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>
> The CQ resource pool is protected by a spin lock. When a CQ creation
> fails it now deallocates under that lock as well.
>
> Signed-off-by: Ram Amrani <Ram.Amrani-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Yuval Mintz <Yuval.Mintz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> ---
> drivers/net/ethernet/qlogic/qed/qed_roce.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_roce.c b/drivers/net/ethernet/qlogic/qed/qed_roce.c
> index bd4cad2..7ab6d4e 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_roce.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_roce.c
> @@ -948,7 +948,9 @@ static int qed_rdma_create_cq(void *rdma_cxt,
>
> err:
> /* release allocated icid */
> + spin_lock_bh(&p_info->lock);
> qed_bmap_release_id(p_hwfn, &p_info->cq_map, returned_id);
> + spin_unlock_bh(&p_info->lock);
> DP_NOTICE(p_hwfn, "Create CQ failed, rc = %d\n", rc);
Minor suggestion.
Can you consider embedding the lock and unlock inside qed_bmap_release_id?
There are two places where this is bad idea as driver needs to release two
IDs but still one is in error flow and second is when destroying QP so for
most cases code may look a bit better.
>
> return rc;
> --
> 1.8.3.1
>
> --
> 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
--
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: [net PATCH v5 1/6] virtio_net: use dev_kfree_skb for small buffer XDP receive
From: Alexei Starovoitov @ 2017-01-25 7:33 UTC (permalink / raw)
To: John Fastabend
Cc: Michael S. Tsirkin, Jason Wang, David Miller, John Fastabend,
netdev@vger.kernel.org, Daniel Borkmann
On Tue, Jan 24, 2017 at 8:02 PM, John Fastabend
<john.fastabend@gmail.com> wrote:
>
> Finally just to point out here are the drivers with XDP support on latest
> net tree,
>
> mlx/mlx5
> mlx/mlx4
> qlogic/qede
> netronome/nfp
> virtio_net
>
> And here is the list of adjust header support,
>
> mlx/mlx4
>
in net-next it's actually:
yes: mlx4, mlx5
no: qede, nfp, virtio
while nfp and virtio are working on it.
xdp_adjust_head() is must have for load balancer,
so the sooner it lands for virtio the easier it will be
to develop xdp programs. Initially I expected
e1k+xdp to be the base line for debugging and
development of xdp programs, but since not everyone
agreed on e1k the virtio+xdp filled in the gap.
So without adjust_head in virtio I see very little use for it
in our environment.
It is a must have feature regardless of timing.
I will backport whatever is necessary, but distros
will stick with official releases and imo it's not great
from xdp adoption point of view to have
virtio driver lacking key features.
^ permalink raw reply
* Re: linux-next: manual merge of the kselftest tree with the net-next tree
From: Daniel Borkmann @ 2017-01-25 7:39 UTC (permalink / raw)
To: Stephen Rothwell, Shuah Khan, David Miller, Networking
Cc: linux-next, linux-kernel, bamvor.zhangjian@huawei.com,
Bamvor Jian Zhang
In-Reply-To: <20170125150321.0b377f57@canb.auug.org.au>
On 01/25/2017 05:03 AM, Stephen Rothwell wrote:
> Hi Shuah,
>
> Today's linux-next merge of the kselftest tree got a conflict in:
>
> tools/testing/selftests/bpf/Makefile
>
> between commit:
>
> 62b64660262a ("bpf: add prog tag test case to bpf selftests")
>
> from the net-next tree and commit:
>
> 88baa78d1f31 ("selftests: remove duplicated all and clean target")
>
> from the kselftest tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Looks good to me, thanks!
^ permalink raw reply
* [PATCH net 0/3] bnxt_en: Fix RTNL lock usage in bnxt_sp_task().
From: Michael Chan @ 2017-01-25 7:55 UTC (permalink / raw)
To: davem; +Cc: netdev
There are 2 function calls from bnxt_sp_task() that have buggy RTNL
usage. These 2 functions take RTNL lock under some conditions, but
some callers (such as open, ethtool) have already taken RTNL. These
3 patches fix the issue by making it clear that callers must take
RTNL. If the caller is bnxt_sp_task() which does not automatically
take RTNL, we add a common scheme for bnxt_sp_task() to call these
functions properly under RTNL.
Michael Chan (3):
bnxt_en: Fix bnxt_reset() in the slow path task.
bnxt_en: Fix RTNL lock usage on bnxt_update_link().
bnxt_en: Fix RTNL lock usage on bnxt_get_port_module_status().
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 78 ++++++++++++++++++-------------
1 file changed, 46 insertions(+), 32 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net 1/3] bnxt_en: Fix bnxt_reset() in the slow path task.
From: Michael Chan @ 2017-01-25 7:55 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1485330909-12037-1-git-send-email-michael.chan@broadcom.com>
In bnxt_sp_task(), we set a bit BNXT_STATE_IN_SP_TASK so that bnxt_close()
will synchronize and wait for bnxt_sp_task() to finish. Some functions
in bnxt_sp_task() require us to clear BNXT_STATE_IN_SP_TASK and then
acquire rtnl_lock() to prevent race conditions.
There are some bugs related to this logic. This patch refactors the code
to have common bnxt_rtnl_lock_sp() and bnxt_rtnl_unlock_sp() to handle
the RTNL and the clearing/setting of the bit. Multiple functions will
need the same logic. We also need to move bnxt_reset() to the end of
bnxt_sp_task(). Functions that clear BNXT_STATE_IN_SP_TASK must be the
last functions to be called in bnxt_sp_task(). The common scheme will
handle the condition properly.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 38 ++++++++++++++++++++-----------
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 53e686f..30d7d64 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -6200,23 +6200,32 @@ static void bnxt_timer(unsigned long data)
mod_timer(&bp->timer, jiffies + bp->current_interval);
}
-/* Only called from bnxt_sp_task() */
-static void bnxt_reset(struct bnxt *bp, bool silent)
+static void bnxt_rtnl_lock_sp(struct bnxt *bp)
{
- /* bnxt_reset_task() calls bnxt_close_nic() which waits
- * for BNXT_STATE_IN_SP_TASK to clear.
- * If there is a parallel dev_close(), bnxt_close() may be holding
+ /* We are called from bnxt_sp_task which has BNXT_STATE_IN_SP_TASK
+ * set. If the device is being closed, bnxt_close() may be holding
* rtnl() and waiting for BNXT_STATE_IN_SP_TASK to clear. So we
* must clear BNXT_STATE_IN_SP_TASK before holding rtnl().
*/
clear_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
rtnl_lock();
- if (test_bit(BNXT_STATE_OPEN, &bp->state))
- bnxt_reset_task(bp, silent);
+}
+
+static void bnxt_rtnl_unlock_sp(struct bnxt *bp)
+{
set_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
rtnl_unlock();
}
+/* Only called from bnxt_sp_task() */
+static void bnxt_reset(struct bnxt *bp, bool silent)
+{
+ bnxt_rtnl_lock_sp(bp);
+ if (test_bit(BNXT_STATE_OPEN, &bp->state))
+ bnxt_reset_task(bp, silent);
+ bnxt_rtnl_unlock_sp(bp);
+}
+
static void bnxt_cfg_ntp_filters(struct bnxt *);
static void bnxt_sp_task(struct work_struct *work)
@@ -6266,18 +6275,21 @@ static void bnxt_sp_task(struct work_struct *work)
bnxt_hwrm_tunnel_dst_port_free(
bp, TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_GENEVE);
}
- if (test_and_clear_bit(BNXT_RESET_TASK_SP_EVENT, &bp->sp_event))
- bnxt_reset(bp, false);
-
- if (test_and_clear_bit(BNXT_RESET_TASK_SILENT_SP_EVENT, &bp->sp_event))
- bnxt_reset(bp, true);
-
if (test_and_clear_bit(BNXT_HWRM_PORT_MODULE_SP_EVENT, &bp->sp_event))
bnxt_get_port_module_status(bp);
if (test_and_clear_bit(BNXT_PERIODIC_STATS_SP_EVENT, &bp->sp_event))
bnxt_hwrm_port_qstats(bp);
+ /* These functions below will clear BNXT_STATE_IN_SP_TASK. They
+ * must be the last functions to be called before exiting.
+ */
+ if (test_and_clear_bit(BNXT_RESET_TASK_SP_EVENT, &bp->sp_event))
+ bnxt_reset(bp, false);
+
+ if (test_and_clear_bit(BNXT_RESET_TASK_SILENT_SP_EVENT, &bp->sp_event))
+ bnxt_reset(bp, true);
+
smp_mb__before_atomic();
clear_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/3] bnxt_en: Fix RTNL lock usage on bnxt_update_link().
From: Michael Chan @ 2017-01-25 7:55 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1485330909-12037-1-git-send-email-michael.chan@broadcom.com>
bnxt_update_link() is called from multiple code paths. Most callers,
such as open, ethtool, already hold RTNL. Only the caller bnxt_sp_task()
does not. So it is a bug to take RTNL inside bnxt_update_link().
Fix it by removing the RTNL inside bnxt_update_link(). The function
now expects the caller to always hold RTNL.
In bnxt_sp_task(), call bnxt_rtnl_lock_sp() before calling
bnxt_update_link(). We also need to move the call to the end of
bnxt_sp_task() since it will be clearing the BNXT_STATE_IN_SP_TASK bit.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 37 +++++++++++++++----------------
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 30d7d64..69b0fce 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5314,17 +5314,12 @@ static int bnxt_update_link(struct bnxt *bp, bool chng_link_state)
if ((link_info->support_auto_speeds | diff) !=
link_info->support_auto_speeds) {
/* An advertised speed is no longer supported, so we need to
- * update the advertisement settings. See bnxt_reset() for
- * comments about the rtnl_lock() sequence below.
+ * update the advertisement settings. Caller holds RTNL
+ * so we can modify link settings.
*/
- clear_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
- rtnl_lock();
link_info->advertising = link_info->support_auto_speeds;
- if (test_bit(BNXT_STATE_OPEN, &bp->state) &&
- (link_info->autoneg & BNXT_AUTONEG_SPEED))
+ if (link_info->autoneg & BNXT_AUTONEG_SPEED)
bnxt_hwrm_set_link_setting(bp, true, false);
- set_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
- rtnl_unlock();
}
return 0;
}
@@ -6231,7 +6226,6 @@ static void bnxt_reset(struct bnxt *bp, bool silent)
static void bnxt_sp_task(struct work_struct *work)
{
struct bnxt *bp = container_of(work, struct bnxt, sp_task);
- int rc;
set_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
smp_mb__after_atomic();
@@ -6245,16 +6239,6 @@ static void bnxt_sp_task(struct work_struct *work)
if (test_and_clear_bit(BNXT_RX_NTP_FLTR_SP_EVENT, &bp->sp_event))
bnxt_cfg_ntp_filters(bp);
- if (test_and_clear_bit(BNXT_LINK_CHNG_SP_EVENT, &bp->sp_event)) {
- if (test_and_clear_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT,
- &bp->sp_event))
- bnxt_hwrm_phy_qcaps(bp);
-
- rc = bnxt_update_link(bp, true);
- if (rc)
- netdev_err(bp->dev, "SP task can't update link (rc: %x)\n",
- rc);
- }
if (test_and_clear_bit(BNXT_HWRM_EXEC_FWD_REQ_SP_EVENT, &bp->sp_event))
bnxt_hwrm_exec_fwd_req(bp);
if (test_and_clear_bit(BNXT_VXLAN_ADD_PORT_SP_EVENT, &bp->sp_event)) {
@@ -6284,6 +6268,21 @@ static void bnxt_sp_task(struct work_struct *work)
/* These functions below will clear BNXT_STATE_IN_SP_TASK. They
* must be the last functions to be called before exiting.
*/
+ if (test_and_clear_bit(BNXT_LINK_CHNG_SP_EVENT, &bp->sp_event)) {
+ int rc = 0;
+
+ if (test_and_clear_bit(BNXT_LINK_SPEED_CHNG_SP_EVENT,
+ &bp->sp_event))
+ bnxt_hwrm_phy_qcaps(bp);
+
+ bnxt_rtnl_lock_sp(bp);
+ if (test_bit(BNXT_STATE_OPEN, &bp->state))
+ rc = bnxt_update_link(bp, true);
+ bnxt_rtnl_unlock_sp(bp);
+ if (rc)
+ netdev_err(bp->dev, "SP task can't update link (rc: %x)\n",
+ rc);
+ }
if (test_and_clear_bit(BNXT_RESET_TASK_SP_EVENT, &bp->sp_event))
bnxt_reset(bp, false);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 3/3] bnxt_en: Fix RTNL lock usage on bnxt_get_port_module_status().
From: Michael Chan @ 2017-01-25 7:55 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1485330909-12037-1-git-send-email-michael.chan@broadcom.com>
bnxt_get_port_module_status() calls bnxt_update_link() which expects
RTNL to be held. In bnxt_sp_task() that does not hold RTNL, we need to
call it with a prior call to bnxt_rtnl_lock_sp() and the call needs to
be moved to the end of bnxt_sp_task().
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 69b0fce..4fcc6a8 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -6259,9 +6259,6 @@ static void bnxt_sp_task(struct work_struct *work)
bnxt_hwrm_tunnel_dst_port_free(
bp, TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_GENEVE);
}
- if (test_and_clear_bit(BNXT_HWRM_PORT_MODULE_SP_EVENT, &bp->sp_event))
- bnxt_get_port_module_status(bp);
-
if (test_and_clear_bit(BNXT_PERIODIC_STATS_SP_EVENT, &bp->sp_event))
bnxt_hwrm_port_qstats(bp);
@@ -6283,6 +6280,12 @@ static void bnxt_sp_task(struct work_struct *work)
netdev_err(bp->dev, "SP task can't update link (rc: %x)\n",
rc);
}
+ if (test_and_clear_bit(BNXT_HWRM_PORT_MODULE_SP_EVENT, &bp->sp_event)) {
+ bnxt_rtnl_lock_sp(bp);
+ if (test_bit(BNXT_STATE_OPEN, &bp->state))
+ bnxt_get_port_module_status(bp);
+ bnxt_rtnl_unlock_sp(bp);
+ }
if (test_and_clear_bit(BNXT_RESET_TASK_SP_EVENT, &bp->sp_event))
bnxt_reset(bp, false);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341
From: Gregory CLEMENT @ 2017-01-25 7:55 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, netdev, linux-kernel,
David S. Miller, Jason Cooper, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, Nadav Haklai, Wilson Ding,
Kostya Porotchkin, Joe Zhou, Jon Pannell
In-Reply-To: <20170125020249.GB24034@lunn.ch>
Hi Andrew,
On mer., janv. 25 2017, Andrew Lunn <andrew@lunn.ch> wrote:
>> + [MV88E6341] = {
>> + .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
>> + .family = MV88E6XXX_FAMILY_6341,
>> + .name = "Marvell 88E6341",
>> + .num_databases = 4096,
>> + .num_ports = 6,
>> + .port_base_addr = 0x10,
>> + .global1_addr = 0x1b,
>> + .age_time_coeff = 15000,
>
> Hi Gregory
>
> Please could you check this timer in the datasheet. There is currently
> a bug in the mv88e6390 support code. I also set it to 15s. But in fact
> it is 3.75 seconds. The 6341 might also use 3.75 seconds.
When I read your series I also thought about it and indeed it is 3.75
seconds. I will fix it.
Thanks,
Gregory
>
> Thanks
> Andrew
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH net v2 0/4] r8152: fix scheduling napi
From: Hayes Wang @ 2017-01-25 8:13 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-236-Taiwan-albertk@realtek.com>
v2:
Add smp_mb__after_atomic() for patch #1.
v1:
Scheduling the napi during the following periods would let it be ignored.
And the events wouldn't be handled until next napi_schedule() is called.
1. after napi_disable and before napi_enable().
2. after all actions of napi function is completed and before calling
napi_complete().
If no next napi_schedule() is called, tx or rx would stop working.
In order to avoid these situations, the followings solutions are applied.
1. prevent start_xmit() from calling napi_schedule() during runtime suspend
or after napi_disable().
2. re-schedule the napi for tx if it is necessary.
3. check if any rx is finished or not after napi_enable().
Hayes Wang (4):
r8152: avoid start_xmit to call napi_schedule during autosuspend
r8152: avoid start_xmit to schedule napi when napi is disabled
r8152: re-schedule napi for tx
r8152: check rx after napi is enabled
drivers/net/usb/r8152.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: dsa: mv88e6xxx: Implement the 6390 external MDIO bus
From: Gregory CLEMENT @ 2017-01-25 8:13 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20170125013230.GB5043@lunn.ch>
Hi Andrew,
On mer., janv. 25 2017, Andrew Lunn <andrew@lunn.ch> wrote:
>> diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
>> index 7d24add45e74..572d585dc1e2 100644
>> --- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
>> +++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
>> @@ -387,6 +387,7 @@
>> #define GLOBAL2_PTP_AVB_DATA 0x17
>> #define GLOBAL2_SMI_PHY_CMD 0x18
>> #define GLOBAL2_SMI_PHY_CMD_BUSY BIT(15)
>> +#define GLOBAL2_SMI_PHY_CMD_EXTERNAL BIT(13)
>> #define GLOBAL2_SMI_PHY_CMD_MODE_22 BIT(12)
>> #define GLOBAL2_SMI_PHY_CMD_OP_22_WRITE_DATA ((0x1 << 10) | \
>
> Hi Gregory
>
> Please could you check if the 88E6341 has an external MDIO. Global 2,
> register 0x18, bit 13.
I confirm that 88E6341 has Global 2, register 0x18, bit 13 referred as
"External access"
Gregory
>
> Thanks
> Andrew
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH net v2 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend
From: Hayes Wang @ 2017-01-25 8:13 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-242-Taiwan-albertk@realtek.com>
Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit()
from calling napi_schedule() directly during runtime suspend.
After calling napi_disable() or clearing the flag of WORK_ENABLE,
scheduling the napi is useless.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e1466b4..23bef8e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3585,10 +3585,15 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
struct net_device *netdev = tp->netdev;
int ret = 0;
+ set_bit(SELECTIVE_SUSPEND, &tp->flags);
+ smp_mb__after_atomic();
+
if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
u32 rcr = 0;
if (delay_autosuspend(tp)) {
+ clear_bit(SELECTIVE_SUSPEND, &tp->flags);
+ smp_mb__after_atomic();
ret = -EBUSY;
goto out1;
}
@@ -3605,6 +3610,8 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
if (!(ocp_data & RXFIFO_EMPTY)) {
rxdy_gated_en(tp, false);
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
+ clear_bit(SELECTIVE_SUSPEND, &tp->flags);
+ smp_mb__after_atomic();
ret = -EBUSY;
goto out1;
}
@@ -3624,8 +3631,6 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
}
}
- set_bit(SELECTIVE_SUSPEND, &tp->flags);
-
out1:
return ret;
}
@@ -3681,12 +3686,13 @@ static int rtl8152_resume(struct usb_interface *intf)
if (netif_running(tp->netdev) && tp->netdev->flags & IFF_UP) {
if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
tp->rtl_ops.autosuspend_en(tp, false);
- clear_bit(SELECTIVE_SUSPEND, &tp->flags);
napi_disable(&tp->napi);
set_bit(WORK_ENABLE, &tp->flags);
if (netif_carrier_ok(tp->netdev))
rtl_start_rx(tp);
napi_enable(&tp->napi);
+ clear_bit(SELECTIVE_SUSPEND, &tp->flags);
+ smp_mb__after_atomic();
} else {
tp->rtl_ops.up(tp);
netif_carrier_off(tp->netdev);
--
2.7.4
^ permalink raw reply related
* [PATCH net v2 2/4] r8152: avoid start_xmit to schedule napi when napi is disabled
From: Hayes Wang @ 2017-01-25 8:13 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-242-Taiwan-albertk@realtek.com>
Stop the tx when the napi is disabled to prevent napi_schedule() is
called.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 23bef8e..ec882be 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3155,10 +3155,13 @@ static void set_carrier(struct r8152 *tp)
if (!netif_carrier_ok(netdev)) {
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, &tp->flags);
+ netif_stop_queue(netdev);
napi_disable(&tp->napi);
netif_carrier_on(netdev);
rtl_start_rx(tp);
napi_enable(&tp->napi);
+ netif_wake_queue(netdev);
+ netif_info(tp, link, netdev, "carrier on\n");
}
} else {
if (netif_carrier_ok(netdev)) {
@@ -3166,6 +3169,7 @@ static void set_carrier(struct r8152 *tp)
napi_disable(&tp->napi);
tp->rtl_ops.disable(tp);
napi_enable(&tp->napi);
+ netif_info(tp, link, netdev, "carrier off\n");
}
}
}
@@ -3515,12 +3519,12 @@ static int rtl8152_pre_reset(struct usb_interface *intf)
if (!netif_running(netdev))
return 0;
+ netif_stop_queue(netdev);
napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
if (netif_carrier_ok(netdev)) {
- netif_stop_queue(netdev);
mutex_lock(&tp->control);
tp->rtl_ops.disable(tp);
mutex_unlock(&tp->control);
@@ -3548,10 +3552,10 @@ static int rtl8152_post_reset(struct usb_interface *intf)
rtl_start_rx(tp);
rtl8152_set_rx_mode(netdev);
mutex_unlock(&tp->control);
- netif_wake_queue(netdev);
}
napi_enable(&tp->napi);
+ netif_wake_queue(netdev);
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH net v2 3/4] r8152: re-schedule napi for tx
From: Hayes Wang @ 2017-01-25 8:13 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Hayes Wang
In-Reply-To: <1394712342-15778-242-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Re-schedule napi after napi_complete() for tx, if it is necessay.
In r8152_poll(), if the tx is completed after tx_bottom() and before
napi_complete(), the scheduling of napi would be lost. Then, no
one handles the next tx until the next napi_schedule() is called.
Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/r8152.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ec882be..45d168e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1936,6 +1936,9 @@ static int r8152_poll(struct napi_struct *napi, int budget)
napi_complete(napi);
if (!list_empty(&tp->rx_done))
napi_schedule(napi);
+ else if (!skb_queue_empty(&tp->tx_queue) &&
+ !list_empty(&tp->tx_free))
+ napi_schedule(&tp->napi);
}
return work_done;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* [PATCH net v2 4/4] r8152: check rx after napi is enabled
From: Hayes Wang @ 2017-01-25 8:13 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-242-Taiwan-albertk@realtek.com>
Schedule the napi after napi_enable() for rx, if it is necessary.
If the rx is completed when napi is disabled, the sheduling of napi
would be lost. Then, no one handles the rx packet until next napi
is scheduled.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 45d168e..8924520 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -32,7 +32,7 @@
#define NETNEXT_VERSION "08"
/* Information for net */
-#define NET_VERSION "7"
+#define NET_VERSION "8"
#define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
#define DRIVER_AUTHOR "Realtek linux nic maintainers <nic_swsd@realtek.com>"
@@ -3561,6 +3561,9 @@ static int rtl8152_post_reset(struct usb_interface *intf)
netif_wake_queue(netdev);
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
+ if (!list_empty(&tp->rx_done))
+ napi_schedule(&tp->napi);
+
return 0;
}
@@ -3700,6 +3703,8 @@ static int rtl8152_resume(struct usb_interface *intf)
napi_enable(&tp->napi);
clear_bit(SELECTIVE_SUSPEND, &tp->flags);
smp_mb__after_atomic();
+ if (!list_empty(&tp->rx_done))
+ napi_schedule(&tp->napi);
} else {
tp->rtl_ops.up(tp);
netif_carrier_off(tp->netdev);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] mac80211: use accessor functions to set sta->_flags
From: Amadeusz Slawinski @ 2017-01-25 8:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, David S. Miller, netdev, linux-kernel
In-Reply-To: <1485272668.1236.5.camel@sipsolutions.net>
And yes I did. Somehow managed to ignore those warnings though, sorry
about that.
Rechecked with just first patch and it should still be good. Please
ignore this one ;)
On 24 January 2017 at 16:44, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2017-01-24 at 16:42 +0100, Amadeusz Sławiński wrote:
>> cleanup patch to make use of set_sta_flag()/clear_sta_flag() in
>> places
>> where we access sta->_flags
>>
>> Signed-off-by: Amadeusz Sławiński <amadeusz.slawinski@tieto.com>
>> ---
>> net/mac80211/sta_info.c | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
>> index b6cfcf0..6c9cc2f 100644
>> --- a/net/mac80211/sta_info.c
>> +++ b/net/mac80211/sta_info.c
>> @@ -1855,13 +1855,13 @@ int sta_info_move_state(struct sta_info *sta,
>> switch (new_state) {
>> case IEEE80211_STA_NONE:
>> if (sta->sta_state == IEEE80211_STA_AUTH)
>> - clear_bit(WLAN_STA_AUTH, &sta->_flags);
>> + clear_sta_flag(sta, WLAN_STA_AUTH);
>
> You should try to run this patch sometime :)
>
> johannes
^ permalink raw reply
* Re: [PATCH for bnxt_re V4 17/21] RDMA/bnxt_re: Handling dispatching of events to IB stack
From: Selvin Xavier @ 2017-01-25 9:03 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, linux-rdma, Linux Netdev List, Michael Chan,
Eddie Wai, Devesh Sharma, Somnath Kotur, Sriharsha Basavapatna
In-Reply-To: <20170124121801.GG6005@mtr-leonro.local>
On Tue, Jan 24, 2017 at 5:48 PM, Leon Romanovsky <leon@kernel.org> wrote:
> All callers to this function in this patch set qp_wait to be false.
> Do you have in following patches qp_wait == true?
> I'm curious because of your msleep below.
Thanks for pointing it out. Driver in our internal tree had one more
condition which has a qp_wait == true condition. I missed to remove
this before posting upstream. Will include this in V5
^ permalink raw reply
* Re: [PATCH for bnxt_re V4 20/21] RDMA/bnxt_re: Add QP event handling
From: Selvin Xavier @ 2017-01-25 9:04 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Linux Netdev List, Michael Chan, Eddie Wai, Devesh Sharma,
Somnath Kotur, Sriharsha Basavapatna
In-Reply-To: <20170124122008.GH6005-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
On Tue, Jan 24, 2017 at 5:50 PM, Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> it looks like if( ... ) return 0
Yes.. There is some code to be added on this area as a part of error
reporting. We will add this once the driver is accepted. Perhaps, i
will add a debug print here for now.
--
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 1/2] Documentation: devicetree: change the mediatek ethernet compatible string
From: John Crispin @ 2017-01-25 8:20 UTC (permalink / raw)
To: Rob Herring, Matthias Brugger, David S. Miller
Cc: netdev, Sean Wang, devicetree, linux-mediatek, John Crispin
When the binding was defined, I was not aware that mt2701 was an earlier
version of the SoC. For sake of consistency, the ethernet driver should
use mt2701 inside the compat string as this is the earliest SoC with the
ethernet core.
The ethernet driver is currently of no real use until we finish and
upstream the DSA driver. There are no users of this binding yet. It should
be safe to fix this now before it is too late and we need to provide
backward compatibility for the mt7623-eth compat string.
Reported-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: John Crispin <john@phrozen.org>
---
Documentation/devicetree/bindings/net/mediatek-net.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
index c010faf..c7194e8 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -7,7 +7,7 @@ have dual GMAC each represented by a child node..
* Ethernet controller node
Required properties:
-- compatible: Should be "mediatek,mt7623-eth"
+- compatible: Should be "mediatek,mt2701-eth"
- reg: Address and length of the register set for the device
- interrupts: Should contain the three frame engines interrupts in numeric
order. These are fe_int0, fe_int1 and fe_int2.
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] net-next: ethernet: mediatek: change the compatible string
From: John Crispin @ 2017-01-25 8:20 UTC (permalink / raw)
To: Rob Herring, Matthias Brugger, David S. Miller
Cc: netdev, Sean Wang, devicetree, linux-mediatek, John Crispin
In-Reply-To: <1485332455-34743-1-git-send-email-john@phrozen.org>
When the binding was defined, I was not aware that mt2701 was an earlier
version of the SoC. For sake of consistency, the ethernet driver should
use mt2701 inside the compat string as this is the earliest SoC with the
ethernet core.
The ethernet driver is currently of no real use until we finish and
upstream the DSA driver. There are no users of this binding yet. It should
be safe to fix this now before it is too late and we need to provide
backward compatibility for the mt7623-eth compat string.
Reported-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: John Crispin <john@phrozen.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 25ae0c5..9e75768 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2515,7 +2515,7 @@ static int mtk_remove(struct platform_device *pdev)
}
const struct of_device_id of_mtk_match[] = {
- { .compatible = "mediatek,mt7623-eth" },
+ { .compatible = "mediatek,mt2701-eth" },
{},
};
MODULE_DEVICE_TABLE(of, of_mtk_match);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/2] mac80211: use accessor functions to set sta->_flags
From: Johannes Berg @ 2017-01-25 9:17 UTC (permalink / raw)
To: Amadeusz Slawinski
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+db6Z1OtO4_93KN-YoEaVg79zY5BgX2u0S+8FGVdkWav0iB2g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2017-01-25 at 09:55 +0100, Amadeusz Slawinski wrote:
> And yes I did. Somehow managed to ignore those warnings though, sorry
> about that.
:)
That was intentional so nobody changing mac80211 in the future will
accidentally play with those flags through the normal accessors.
> Rechecked with just first patch and it should still be good. Please
> ignore this one ;)
Yeah, I still have that one pending, no worries :)
johannes
^ permalink raw reply
* Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
From: Nicolas Ferre @ 2017-01-25 9:26 UTC (permalink / raw)
To: Andrei Pistirica, netdev, linux-kernel, linux-arm-kernel, davem,
harinikatakamlinux, harini.katakam
Cc: punnaia, michals, anirudh, boris.brezillon, alexandre.belloni,
tbultel, richardcochran, rafalo
In-Reply-To: <9bc6b112-f79c-58e4-7d2b-718ee07ff3a1@atmel.com>
Le 19/01/2017 à 17:07, Nicolas Ferre a écrit :
> Le 19/01/2017 à 08:56, Andrei Pistirica a écrit :
>> This patch does the following:
>> - MACB/GEM-PTP interface
>> - registers and bitfields for TSU
>> - capability flags to enable PTP per platform basis
>>
>> Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Harini or Rafal, do you plan to review this patch and add your
"Reviewed-by" tags? It can be useful to make this support move forward.
Regards,
>> ---
>> Patch history:
>>
>> Version 1:
>> This is just the common code for MACB/GEM-PTP support.
>> Code is based on the comments related to the following patch series:
>> - [RFC PATCH net-next v1-to-4 1/2] macb: Add 1588 support in Cadence GEM
>> - [RFC PATCH net-next v1-to-4 2/2] macb: Enable 1588 support in SAMA5Dx platforms
>>
>> Version 2:
>> - Cosmetic changes and PTP capability flag changed doe to overlapping with JUMBO.
>>
>> Note: Patch on net-next: January 19.
>>
>> drivers/net/ethernet/cadence/macb.c | 32 +++++++++++++++-
>> drivers/net/ethernet/cadence/macb.h | 74 +++++++++++++++++++++++++++++++++++++
>> 2 files changed, 104 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
>> index c0fb80a..ff1e648 100644
>> --- a/drivers/net/ethernet/cadence/macb.c
>> +++ b/drivers/net/ethernet/cadence/macb.c
>> @@ -2085,6 +2085,9 @@ static int macb_open(struct net_device *dev)
>>
>> netif_tx_start_all_queues(dev);
>>
>> + if (bp->ptp_info)
>> + bp->ptp_info->ptp_init(dev);
>> +
>> return 0;
>> }
>>
>> @@ -2106,6 +2109,9 @@ static int macb_close(struct net_device *dev)
>>
>> macb_free_consistent(bp);
>>
>> + if (bp->ptp_info)
>> + bp->ptp_info->ptp_remove(dev);
>> +
>> return 0;
>> }
>>
>> @@ -2379,6 +2385,17 @@ static int macb_set_ringparam(struct net_device *netdev,
>> return 0;
>> }
>>
>> +static int macb_get_ts_info(struct net_device *netdev,
>> + struct ethtool_ts_info *info)
>> +{
>> + struct macb *bp = netdev_priv(netdev);
>> +
>> + if (bp->ptp_info)
>> + return bp->ptp_info->get_ts_info(netdev, info);
>> +
>> + return ethtool_op_get_ts_info(netdev, info);
>> +}
>> +
>> static const struct ethtool_ops macb_ethtool_ops = {
>> .get_regs_len = macb_get_regs_len,
>> .get_regs = macb_get_regs,
>> @@ -2396,7 +2413,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
>> .get_regs_len = macb_get_regs_len,
>> .get_regs = macb_get_regs,
>> .get_link = ethtool_op_get_link,
>> - .get_ts_info = ethtool_op_get_ts_info,
>> + .get_ts_info = macb_get_ts_info,
>> .get_ethtool_stats = gem_get_ethtool_stats,
>> .get_strings = gem_get_ethtool_strings,
>> .get_sset_count = gem_get_sset_count,
>> @@ -2409,6 +2426,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
>> static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
>> {
>> struct phy_device *phydev = dev->phydev;
>> + struct macb *bp = netdev_priv(dev);
>>
>> if (!netif_running(dev))
>> return -EINVAL;
>> @@ -2416,7 +2434,17 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
>> if (!phydev)
>> return -ENODEV;
>>
>> - return phy_mii_ioctl(phydev, rq, cmd);
>> + if (!bp->ptp_info)
>> + return phy_mii_ioctl(phydev, rq, cmd);
>> +
>> + switch (cmd) {
>> + case SIOCSHWTSTAMP:
>> + return bp->ptp_info->set_hwtst(dev, rq, cmd);
>> + case SIOCGHWTSTAMP:
>> + return bp->ptp_info->get_hwtst(dev, rq);
>> + default:
>> + return phy_mii_ioctl(phydev, rq, cmd);
>> + }
>> }
>>
>> static int macb_set_features(struct net_device *netdev,
>> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
>> index d67adad..94ddedd 100644
>> --- a/drivers/net/ethernet/cadence/macb.h
>> +++ b/drivers/net/ethernet/cadence/macb.h
>> @@ -131,6 +131,20 @@
>> #define GEM_RXIPCCNT 0x01a8 /* IP header Checksum Error Counter */
>> #define GEM_RXTCPCCNT 0x01ac /* TCP Checksum Error Counter */
>> #define GEM_RXUDPCCNT 0x01b0 /* UDP Checksum Error Counter */
>> +#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */
>> +#define GEM_TSH 0x01c0 /* 1588 Timer Seconds High */
>> +#define GEM_TSL 0x01d0 /* 1588 Timer Seconds Low */
>> +#define GEM_TN 0x01d4 /* 1588 Timer Nanoseconds */
>> +#define GEM_TA 0x01d8 /* 1588 Timer Adjust */
>> +#define GEM_TI 0x01dc /* 1588 Timer Increment */
>> +#define GEM_EFTSL 0x01e0 /* PTP Event Frame Tx Seconds Low */
>> +#define GEM_EFTN 0x01e4 /* PTP Event Frame Tx Nanoseconds */
>> +#define GEM_EFRSL 0x01e8 /* PTP Event Frame Rx Seconds Low */
>> +#define GEM_EFRN 0x01ec /* PTP Event Frame Rx Nanoseconds */
>> +#define GEM_PEFTSL 0x01f0 /* PTP Peer Event Frame Tx Secs Low */
>> +#define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
>> +#define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
>> +#define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
>> #define GEM_DCFG1 0x0280 /* Design Config 1 */
>> #define GEM_DCFG2 0x0284 /* Design Config 2 */
>> #define GEM_DCFG3 0x0288 /* Design Config 3 */
>> @@ -174,6 +188,7 @@
>> #define MACB_NCR_TPF_SIZE 1
>> #define MACB_TZQ_OFFSET 12 /* Transmit zero quantum pause frame */
>> #define MACB_TZQ_SIZE 1
>> +#define MACB_SRTSM_OFFSET 15
>>
>> /* Bitfields in NCFGR */
>> #define MACB_SPD_OFFSET 0 /* Speed */
>> @@ -319,6 +334,32 @@
>> #define MACB_PTZ_SIZE 1
>> #define MACB_WOL_OFFSET 14 /* Enable wake-on-lan interrupt */
>> #define MACB_WOL_SIZE 1
>> +#define MACB_DRQFR_OFFSET 18 /* PTP Delay Request Frame Received */
>> +#define MACB_DRQFR_SIZE 1
>> +#define MACB_SFR_OFFSET 19 /* PTP Sync Frame Received */
>> +#define MACB_SFR_SIZE 1
>> +#define MACB_DRQFT_OFFSET 20 /* PTP Delay Request Frame Transmitted */
>> +#define MACB_DRQFT_SIZE 1
>> +#define MACB_SFT_OFFSET 21 /* PTP Sync Frame Transmitted */
>> +#define MACB_SFT_SIZE 1
>> +#define MACB_PDRQFR_OFFSET 22 /* PDelay Request Frame Received */
>> +#define MACB_PDRQFR_SIZE 1
>> +#define MACB_PDRSFR_OFFSET 23 /* PDelay Response Frame Received */
>> +#define MACB_PDRSFR_SIZE 1
>> +#define MACB_PDRQFT_OFFSET 24 /* PDelay Request Frame Transmitted */
>> +#define MACB_PDRQFT_SIZE 1
>> +#define MACB_PDRSFT_OFFSET 25 /* PDelay Response Frame Transmitted */
>> +#define MACB_PDRSFT_SIZE 1
>> +#define MACB_SRI_OFFSET 26 /* TSU Seconds Register Increment */
>> +#define MACB_SRI_SIZE 1
>> +
>> +/* Timer increment fields */
>> +#define MACB_TI_CNS_OFFSET 0
>> +#define MACB_TI_CNS_SIZE 8
>> +#define MACB_TI_ACNS_OFFSET 8
>> +#define MACB_TI_ACNS_SIZE 8
>> +#define MACB_TI_NIT_OFFSET 16
>> +#define MACB_TI_NIT_SIZE 8
>>
>> /* Bitfields in MAN */
>> #define MACB_DATA_OFFSET 0 /* data */
>> @@ -386,6 +427,17 @@
>> #define GEM_PBUF_LSO_OFFSET 27
>> #define GEM_PBUF_LSO_SIZE 1
>>
>> +/* Bitfields in TISUBN */
>> +#define GEM_SUBNSINCR_OFFSET 0
>> +#define GEM_SUBNSINCR_SIZE 16
>> +
>> +/* Bitfields in TI */
>> +#define GEM_NSINCR_OFFSET 0
>> +#define GEM_NSINCR_SIZE 8
>> +
>> +/* Bitfields in ADJ */
>> +#define GEM_ADDSUB_OFFSET 31
>> +#define GEM_ADDSUB_SIZE 1
>> /* Constants for CLK */
>> #define MACB_CLK_DIV8 0
>> #define MACB_CLK_DIV16 1
>> @@ -413,6 +465,7 @@
>> #define MACB_CAPS_NO_GIGABIT_HALF 0x00000008
>> #define MACB_CAPS_USRIO_DISABLED 0x00000010
>> #define MACB_CAPS_JUMBO 0x00000020
>> +#define MACB_CAPS_GEM_HAS_PTP 0x00000040
>> #define MACB_CAPS_FIFO_MODE 0x10000000
>> #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x20000000
>> #define MACB_CAPS_SG_DISABLED 0x40000000
>> @@ -782,6 +835,20 @@ struct macb_or_gem_ops {
>> int (*mog_rx)(struct macb *bp, int budget);
>> };
>>
>> +/* MACB-PTP interface: adapt to platform needs. */
>> +struct macb_ptp_info {
>> + void (*ptp_init)(struct net_device *ndev);
>> + void (*ptp_remove)(struct net_device *ndev);
>> + s32 (*get_ptp_max_adj)(void);
>> + unsigned int (*get_tsu_rate)(struct macb *bp);
>> + int (*get_ts_info)(struct net_device *dev,
>> + struct ethtool_ts_info *info);
>> + int (*get_hwtst)(struct net_device *netdev,
>> + struct ifreq *ifr);
>> + int (*set_hwtst)(struct net_device *netdev,
>> + struct ifreq *ifr, int cmd);
>> +};
>> +
>> struct macb_config {
>> u32 caps;
>> unsigned int dma_burst_length;
>> @@ -874,6 +941,8 @@ struct macb {
>> unsigned int jumbo_max_len;
>>
>> u32 wol;
>> +
>> + struct macb_ptp_info *ptp_info; /* macb-ptp interface */
>> };
>>
>> static inline bool macb_is_gem(struct macb *bp)
>> @@ -881,4 +950,9 @@ static inline bool macb_is_gem(struct macb *bp)
>> return !!(bp->caps & MACB_CAPS_MACB_IS_GEM);
>> }
>>
>> +static inline bool gem_has_ptp(struct macb *bp)
>> +{
>> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
>> +}
>> +
>> #endif /* _MACB_H */
>>
>
>
--
Nicolas Ferre
^ 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