* Re: [PATCH 0/2] sh_eth: E-MAC interrupt handler cleanups
From: David Miller @ 2017-01-04 18:48 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <64514012.uUvlhX0YRQ@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Wed, 04 Jan 2017 15:09:36 +0300
> Here's a set of 3 patches against DaveM's 'net-next.git' repo. I'm cleaning
> up the E-MAC interrupt handling with the main goal of factoring out the E-MAC
> interrupt handler into a separate function.
>
> [1/3] sh_eth: handle only enabled E-MAC interrupts
> [2/3] sh_eth: no need for *else* after *goto*
> [3/3] sh_eth: factor out sh_eth_emac_interrupt()
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: add extension of phy-mode for XLGMII
From: Florian Fainelli @ 2017-01-04 18:46 UTC (permalink / raw)
To: David Miller, Jie.Deng1; +Cc: netdev, linux-kernel
In-Reply-To: <20170104.134207.1106369954702793597.davem@davemloft.net>
On 01/04/2017 10:42 AM, David Miller wrote:
> From: Jie Deng <Jie.Deng1@synopsys.com>
> Date: Wed, 4 Jan 2017 13:04:04 +0800
>
>> The Synopsys DWC_xlgmac core provides a multiplexed 40-Gigabit
>> Media-Independent Interface (XLGMII, an IEEE 802.3 Clause 81
>> compliant reconciliation sub-layer) for communication with
>> the 100/50/40/25-Gigabit PHY and 10-Gigabit Media-Independent
>> Interface (XGMII, an IEEE 802.3 Clause 46 compliant reconciliation
>> sub-layer) for communication with the 10-Gigabit PHY.
>>
>> Currently, There are only interface mode definitions for "xgmii".
>> This patch adds the definitions for the PHY layer to recognize
>> "xlgmii" as a valid PHY interface.
>>
>> Signed-off-by: Jie Deng <jiedeng@synopsys.com>
>
> It makes no sense to add these definitions unless you also submit
> uses of them alongside at the same time.
Correct, also, this is incomplete, you must include a change to
Documentation/devicetree/bindings/net/ethernet.txt to reflect this new mode.
Thank you
--
Florian
^ permalink raw reply
* [PATCH repost net-next] dsa: mv88e6xxx: Optimise atu_get
From: Andrew Lunn @ 2017-01-04 18:56 UTC (permalink / raw)
To: David Miller
Cc: volodymyr.bendiuga, Vivien Didelot, Florian Fainelli, netdev,
Andrew Lunn
Lookup in the ATU can be performed starting from a given MAC
address. This is faster than starting with the first possible MAC
address and iterating all entries.
Entries are returned in numeric order. So if the MAC address returned
is bigger than what we are searching for, we know it is not in the
ATU.
Using the benchmark provided by Volodymyr Bendiuga
<volodymyr.bendiuga@gmail.com>,
https://www.spinics.net/lists/netdev/msg411550.html
on an Marvell Armada 370 RD, the test to add a number of static fdb
entries went from 1.616531 seconds to 0.312052 seconds.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
Cc: netdev this time.
drivers/net/dsa/mv88e6xxx/chip.c | 5 ++--
include/linux/etherdevice.h | 60 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f7222dc6581d..4cdb0f09788b 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2023,7 +2023,8 @@ static int mv88e6xxx_atu_get(struct mv88e6xxx_chip *chip, int fid,
struct mv88e6xxx_atu_entry next;
int err;
- eth_broadcast_addr(next.mac);
+ memcpy(next.mac, addr, ETH_ALEN);
+ eth_addr_dec(next.mac);
err = _mv88e6xxx_atu_mac_write(chip, next.mac);
if (err)
@@ -2041,7 +2042,7 @@ static int mv88e6xxx_atu_get(struct mv88e6xxx_chip *chip, int fid,
*entry = next;
return 0;
}
- } while (!is_broadcast_ether_addr(next.mac));
+ } while (ether_addr_greater(addr, next.mac));
memset(entry, 0, sizeof(*entry));
entry->fid = fid;
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 6fec9e81bd70..42add77ae47d 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -397,6 +397,66 @@ static inline bool ether_addr_equal_masked(const u8 *addr1, const u8 *addr2,
}
/**
+ * ether_addr_to_u64 - Convert an Ethernet address into a u64 value.
+ * @addr: Pointer to a six-byte array containing the Ethernet address
+ *
+ * Return a u64 value of the address
+ */
+static inline u64 ether_addr_to_u64(const u8 *addr)
+{
+ u64 u = 0;
+ int i;
+
+ for (i = 0; i < ETH_ALEN; i++)
+ u = u << 8 | addr[i];
+
+ return u;
+}
+
+/**
+ * u64_to_ether_addr - Convert a u64 to an Ethernet address.
+ * @u: u64 to convert to an Ethernet MAC address
+ * @addr: Pointer to a six-byte array to contain the Ethernet address
+ */
+static inline void u64_to_ether_addr(u64 u, u8 *addr)
+{
+ int i;
+
+ for (i = ETH_ALEN - 1; i >= 0; i--) {
+ addr[i] = u & 0xff;
+ u = u >> 8;
+ }
+}
+
+/**
+ * eth_addr_dec - Decrement the given MAC address
+ *
+ * @addr: Pointer to a six-byte array containing Ethernet address to decrement
+ */
+static inline void eth_addr_dec(u8 *addr)
+{
+ u64 u = ether_addr_to_u64(addr);
+
+ u--;
+ u64_to_ether_addr(u, addr);
+}
+
+/**
+ * ether_addr_greater - Compare two Ethernet addresses
+ * @addr1: Pointer to a six-byte array containing the Ethernet address
+ * @addr2: Pointer other six-byte array containing the Ethernet address
+ *
+ * Compare two Ethernet addresses, returns true addr1 is greater than addr2
+ */
+static inline bool ether_addr_greater(const u8 *addr1, const u8 *addr2)
+{
+ u64 u1 = ether_addr_to_u64(addr1);
+ u64 u2 = ether_addr_to_u64(addr2);
+
+ return u1 > u2;
+}
+
+/**
* is_etherdev_addr - Tell if given Ethernet address belongs to the device.
* @dev: Pointer to a device structure
* @addr: Pointer to a six-byte array containing the Ethernet address
--
2.11.0
^ permalink raw reply related
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: John Fastabend @ 2017-01-04 18:57 UTC (permalink / raw)
To: Jason Wang, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <1caf1ffc-0f46-067e-0f0d-a93b408b4ffd@redhat.com>
[...]
> On 2017年01月04日 00:48, John Fastabend wrote:
>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>
>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>> program load and does not block MTU changes after the program
>>>> has loaded.
>>>>
>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>
>>>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>>>> ---
[...]
>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>> needs to read the mtu via
>>
>> virtio_cread16(vdev, ...)
>>
>> or we may break the negotiated mtu.
>
> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
> the device about the mtu in this case which is not supported by virtio now.
Note this is not really a XDP specific problem. The guest can change the MTU
after init time even without XDP which I assume should ideally result in a
notification if the MTU is negotiated.
>>
>> As for capping it at GOOD_PACKET_LEN this has the nice benefit of avoiding any
>> underestimates in EWMA predictions because it appears min estimates are capped
>> at GOOD_PACKET_LEN via get_mergeable_buf_len().
>
> This seems something misunderstanding here, I meant only use GOOD_PACKET_LEN for
> small buffer (which does not use EWMA).
>
Yep I think its all cleared up now.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] virtio_net: XDP support for adjust_head
From: John Fastabend @ 2017-01-04 18:58 UTC (permalink / raw)
To: Jason Wang, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <73715f7a-eeeb-679f-a7b8-7b1fefe1757e@redhat.com>
[...]
>> @@ -393,34 +397,39 @@ static u32 do_xdp_prog(struct virtnet_info *vi,
>> struct bpf_prog *xdp_prog,
>> void *data, int len)
>> {
>> - int hdr_padded_len;
>> struct xdp_buff xdp;
>> - void *buf;
>> unsigned int qp;
>> u32 act;
>> +
>> if (vi->mergeable_rx_bufs) {
>> - hdr_padded_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
>> - xdp.data = data + hdr_padded_len;
>> + int desc_room = sizeof(struct virtio_net_hdr_mrg_rxbuf);
>> +
>> + /* Allow consuming headroom but reserve enough space to push
>> + * the descriptor on if we get an XDP_TX return code.
>> + */
>> + xdp.data_hard_start = data - vi->headroom + desc_room;
>> + xdp.data = data + desc_room;
>> xdp.data_end = xdp.data + (len - vi->hdr_len);
>> - buf = data;
>> } else { /* small buffers */
>> struct sk_buff *skb = data;
>> - xdp.data = skb->data;
>> + xdp.data_hard_start = skb->data;
>> + xdp.data = skb->data + vi->headroom;
>> xdp.data_end = xdp.data + len;
>> - buf = skb->data;
>> }
>> act = bpf_prog_run_xdp(xdp_prog, &xdp);
>> switch (act) {
>> case XDP_PASS:
>> + if (!vi->mergeable_rx_bufs)
>> + __skb_pull((struct sk_buff *) data,
>> + xdp.data - xdp.data_hard_start);
>
> Instead of doing things here and virtnet_xdp_xmit(). How about always making
> skb->data point to the buffer head like:
>
> 1) reserve headroom in add_recvbuf_small()
> 2) skb_push(xdp->data - xdp_data_hard_start, skb) if we detect xdp->data was
> modified afer bpf_prog_run_xdp()
>
> Then there's no special code in either XDP_PASS or XDP_TX?
>
Alternatively moving the pull into the receive_small XDP handler also
removes the special case. I'll submit a patch shortly let me know what
you think.
>> return XDP_PASS;
>> case XDP_TX:
>> qp = vi->curr_queue_pairs -
>> vi->xdp_queue_pairs +
>> smp_processor_id();
>
> [...]
>
.John
^ permalink raw reply
* Re: [PATCH v2 net-next] cxgb4: Support compressed error vector for T6
From: David Miller @ 2017-01-04 19:02 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, arjun, santosh, hariprasad
In-Reply-To: <1483536860-2672-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 4 Jan 2017 19:04:20 +0530
> From: Arjun V <arjun@chelsio.com>
>
> t6fw-1.15.15.0 enabled compressed error vector in cpl_rx_pkt for T6.
> Updating driver to take care of these changes.
>
> Signed-off-by: Santosh Rastapur <santosh@chelsio.com>
> Signed-off-by: Arjun V <arjun@chelsio.com>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> v2: Fixed kbuild errors
Applied, thanks.
^ permalink raw reply
* Re: [RESEND net-next PATCH v5] net: dummy: Introduce dummy virtual functions
From: David Miller @ 2017-01-04 19:09 UTC (permalink / raw)
To: phil; +Cc: netdev, sd
In-Reply-To: <20170104134406.2720-1-phil@nwl.cc>
From: Phil Sutter <phil@nwl.cc>
Date: Wed, 4 Jan 2017 14:44:06 +0100
> The idea for this was born when testing VF support in iproute2 which was
> impeded by hardware requirements. In fact, not every VF-capable hardware
> driver implements all netdev ops, so testing the interface is still hard
> to do even with a well-sorted hardware shelf.
>
> To overcome this and allow for testing the user-kernel interface, this
> patch allows to turn dummy into a PF with a configurable amount of VFs.
>
> Due to the assumption that all PFs are PCI devices, this implementation
> is not completely straightforward: In order to allow for
> rtnl_fill_ifinfo() to see the dummy VFs, a fake PCI parent device is
> attached to the dummy netdev. This has to happen at the right spot so
> register_netdevice() does not get confused. This patch abuses
> ndo_fix_features callback for that. In ndo_uninit callback, the fake
> parent is removed again for the same purpose.
>
> Joint work with Sabrina Dubroca.
>
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
First of all I really applaud any effort to make the kernel interfaces
more testable, and less dependent upon having specific pieces of hardware.
That being said, all of this seems to be fighting the problem from the
wrong direction.
The device layer is really kidding itself by having what seems like a
generic method in the form of dev_num_vf(), which actually just tests
the bus type and calls a bus specific function on a match.
There is no reason in the world that this cannot be done via proper
device method call, that any bus type or whatever can implement.
Then you don't need any of this stuff, you just hook up the proper
device method to the dummy device and you're good.
^ permalink raw reply
* Re: [PATCH] stmmac: Enable Clause 45 PHYs in GAMC4
From: David Miller @ 2017-01-04 19:11 UTC (permalink / raw)
To: Joao.Pinto; +Cc: hock.leong.kweh, netdev
In-Reply-To: <14201d58c172f7a65b03510d36d55170f4d16cd5.1483540094.git.jpinto@synopsys.com>
From: Joao Pinto <Joao.Pinto@synopsys.com>
Date: Wed, 4 Jan 2017 14:35:26 +0000
> The eQOS IP Core (best known in stmmac as gmac4) has a register that must be
> set if using a Clause 45 PHY. If this register is not set, the PHY won't work.
> This patch will have no impact in setups using Clause 22 PHYs.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Why don't you set this bit for MDIO reads as well?
If it isn't necessary for reads, you have to explain this in your commit
message otherwise people will wonder the same thing I did when they see
that only writes are handled.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next rfc 5/6] net-tc: convert tc_at to tc_at_ingress
From: Daniel Borkmann @ 2017-01-04 19:18 UTC (permalink / raw)
To: Willem de Bruijn, netdev
Cc: davem, fw, dborkman, jhs, alexei.starovoitov, Willem de Bruijn
In-Reply-To: <1482952410-50003-6-git-send-email-willemdebruijn.kernel@gmail.com>
Hi Willem,
overall I think the series looks great, thanks for working on it!
On 12/28/2016 08:13 PM, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> Field tc_at is used only within tc actions to distinguish ingress from
> egress processing. A single bit is sufficient for this purpose. Set it
> within tc_classify to make the scope clear and to avoid the need to
> clear it in skb_reset_tc.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> ---
> include/linux/skbuff.h | 3 ++-
> include/net/sch_generic.h | 3 +--
> net/core/dev.c | 6 +-----
> net/sched/act_mirred.c | 12 ++++++------
> net/sched/sch_api.c | 1 +
> 5 files changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index f738d09..fab3f87 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -590,6 +590,7 @@ static inline bool skb_mstamp_after(const struct skb_mstamp *t1,
> * @fclone: skbuff clone status
> * @ipvs_property: skbuff is owned by ipvs
> * @tc_skip_classify: do not classify packet. set by IFB device
> + * @tc_at_ingress: used within tc_classify to distinguish in/egress
> * @peeked: this packet has been seen already, so stats have been
> * done for it, don't do them again
> * @nf_trace: netfilter packet trace flag
> @@ -751,7 +752,7 @@ struct sk_buff {
> #endif
> #ifdef CONFIG_NET_CLS_ACT
> __u8 tc_skip_classify:1;
> - __u8 tc_at:2;
> + __u8 tc_at_ingress:1;
> __u8 tc_from:2;
> #endif
>
> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> index f80dba5..4bd6d53 100644
> --- a/include/net/sch_generic.h
> +++ b/include/net/sch_generic.h
> @@ -412,7 +412,6 @@ int skb_do_redirect(struct sk_buff *);
> static inline void skb_reset_tc(struct sk_buff *skb)
> {
> #ifdef CONFIG_NET_CLS_ACT
> - skb->tc_at = 0;
> skb->tc_from = 0;
> #endif
> }
> @@ -420,7 +419,7 @@ static inline void skb_reset_tc(struct sk_buff *skb)
> static inline bool skb_at_tc_ingress(const struct sk_buff *skb)
> {
> #ifdef CONFIG_NET_CLS_ACT
> - return skb->tc_at & AT_INGRESS;
> + return skb->tc_at_ingress;
> #else
> return false;
> #endif
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 25620cf..90833fdf 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3153,9 +3153,7 @@ sch_handle_egress(struct sk_buff *skb, int *ret, struct net_device *dev)
> if (!cl)
> return skb;
>
> - /* skb->tc_at and qdisc_skb_cb(skb)->pkt_len were already set
> - * earlier by the caller.
> - */
> + /* qdisc_skb_cb(skb)->pkt_len was already set by the caller. */
> qdisc_bstats_cpu_update(cl->q, skb);
>
> switch (tc_classify(skb, cl, &cl_res, false)) {
> @@ -3320,7 +3318,6 @@ static int __dev_queue_xmit(struct sk_buff *skb, void *accel_priv)
>
> qdisc_pkt_len_init(skb);
> #ifdef CONFIG_NET_CLS_ACT
> - skb->tc_at = AT_EGRESS;
> # ifdef CONFIG_NET_EGRESS
> if (static_key_false(&egress_needed)) {
> skb = sch_handle_egress(skb, &rc, dev);
> @@ -3916,7 +3913,6 @@ sch_handle_ingress(struct sk_buff *skb, struct packet_type **pt_prev, int *ret,
> }
>
> qdisc_skb_cb(skb)->pkt_len = skb->len;
> - skb->tc_at = AT_INGRESS;
> qdisc_bstats_cpu_update(cl->q, skb);
>
> switch (tc_classify(skb, cl, &cl_res, false)) {
> diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
> index 8543279..e832c62 100644
> --- a/net/sched/act_mirred.c
> +++ b/net/sched/act_mirred.c
> @@ -39,15 +39,15 @@ static bool tcf_mirred_is_act_redirect(int action)
> return action == TCA_EGRESS_REDIR || action == TCA_INGRESS_REDIR;
> }
>
> -static u32 tcf_mirred_act_direction(int action)
> +static bool tcf_mirred_act_wants_ingress(int action)
> {
> switch (action) {
> case TCA_EGRESS_REDIR:
> case TCA_EGRESS_MIRROR:
> - return AT_EGRESS;
> + return false;
> case TCA_INGRESS_REDIR:
> case TCA_INGRESS_MIRROR:
> - return AT_INGRESS;
> + return true;
> default:
> BUG();
> }
> @@ -198,7 +198,7 @@ static int tcf_mirred(struct sk_buff *skb, const struct tc_action *a,
> * and devices expect a mac header on xmit, then mac push/pull is
> * needed.
> */
> - if (skb->tc_at != tcf_mirred_act_direction(m_eaction) &&
> + if (skb_at_tc_ingress(skb) != tcf_mirred_act_wants_ingress(m_eaction) &&
> m_mac_header_xmit) {
> if (!skb_at_tc_ingress(skb)) {
> /* caught at egress, act ingress: pull mac */
> @@ -212,11 +212,11 @@ static int tcf_mirred(struct sk_buff *skb, const struct tc_action *a,
>
> /* mirror is always swallowed */
> if (tcf_mirred_is_act_redirect(m_eaction))
> - skb2->tc_from = skb2->tc_at;
> + skb2->tc_from = skb_at_tc_ingress(skb) ? AT_INGRESS : AT_EGRESS;
>
> skb2->skb_iif = skb->dev->ifindex;
> skb2->dev = dev;
> - if (tcf_mirred_act_direction(m_eaction) & AT_EGRESS)
> + if (!tcf_mirred_act_wants_ingress(m_eaction))
> err = dev_queue_xmit(skb2);
> else
> err = netif_receive_skb(skb2);
> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
> index ef53ede..be4e18d 100644
> --- a/net/sched/sch_api.c
> +++ b/net/sched/sch_api.c
> @@ -1865,6 +1865,7 @@ int tc_classify(struct sk_buff *skb, const struct tcf_proto *tp,
> const struct tcf_proto *old_tp = tp;
> int limit = 0;
>
> + skb->tc_at_ingress = !!(tp && tp->q->flags & TCQ_F_INGRESS);
I'd prefer if skb->tc_at_ingress is set directly to 0/1 in sch_handle_ingress()
and __dev_queue_xmit() as we do right now, this would avoid above tests in fast
path and it would also avoid to set the same thing in tc_classify() multiple
times f.e. on egress path walking through multiple qdiscs. I don't see anything
in layers above tc that would read it and expect an AT_STACK-like equivalent.
skb_reset_tc() could thus still remain as you have above in fast-path like
__netif_receive_skb_core().
> reclassify:
> #endif
> for (; tp; tp = rcu_dereference_bh(tp->next)) {
>
Thanks,
Daniel
^ permalink raw reply
* [PATCH] sh_eth: fix EESIPR values for SH77{34|63}
From: Sergei Shtylyov @ 2017-01-04 19:18 UTC (permalink / raw)
To: netdev, linux-renesas-soc
As the SH77{34|63} manuals are freely available, I've checked the EESIPR
values written against the manuals, and they appeared to set the reserved
bits 11-15 (which should be 0 on write). Fix those EESIPR values.
Fixes: 380af9e390ec ("net: sh_eth: CPU dependency code collect to "struct sh_eth_cpu_data"")
Fixes: f5d12767c8fd ("sh_eth: get SH77{34|63} support out of #ifdef")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
This patch is against DaveM's 'net.git' repo.
drivers/net/ethernet/renesas/sh_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: net/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -802,7 +802,7 @@ static struct sh_eth_cpu_data sh7734_dat
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
- .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
+ .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003f07ff,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
@@ -831,7 +831,7 @@ static struct sh_eth_cpu_data sh7763_dat
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
- .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
+ .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003f07ff,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
^ permalink raw reply
* Re: [PATCH net] sfc: don't report RX hash keys to ethtool when RSS wasn't enabled
From: David Miller @ 2017-01-04 19:18 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, bkenward, netdev
In-Reply-To: <5a4ac10d-3b4b-bf48-e4ca-c435eed29dc3@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Wed, 4 Jan 2017 15:10:56 +0000
> If we failed to set up RSS on EF10 (e.g. because firmware declared
> RX_RSS_LIMITED), ethtool --show-nfc $dev rx-flow-hash ... should report
> no fields, rather than confusingly reporting what fields we _would_ be
> hashing on if RSS was working.
>
> Fixes: dcb4123cbec0 ("sfc: disable RSS when unsupported")
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next rfc 5/6] net-tc: convert tc_at to tc_at_ingress
From: Willem de Bruijn @ 2017-01-04 19:26 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Network Development, David Miller, Florian Westphal, dborkman,
Jamal Hadi Salim, Alexei Starovoitov, Willem de Bruijn
In-Reply-To: <586D4A6F.7020009@iogearbox.net>
>> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>> index ef53ede..be4e18d 100644
>> --- a/net/sched/sch_api.c
>> +++ b/net/sched/sch_api.c
>> @@ -1865,6 +1865,7 @@ int tc_classify(struct sk_buff *skb, const struct
>> tcf_proto *tp,
>> const struct tcf_proto *old_tp = tp;
>> int limit = 0;
>>
>> + skb->tc_at_ingress = !!(tp && tp->q->flags & TCQ_F_INGRESS);
>
>
> I'd prefer if skb->tc_at_ingress is set directly to 0/1 in
> sch_handle_ingress()
> and __dev_queue_xmit() as we do right now, this would avoid above tests in
> fast
> path and it would also avoid to set the same thing in tc_classify() multiple
> times f.e. on egress path walking through multiple qdiscs. I don't see
> anything
> in layers above tc that would read it and expect an AT_STACK-like
> equivalent.
> skb_reset_tc() could thus still remain as you have above in fast-path like
> __netif_receive_skb_core().
I had been thinking about that. After submitting this I noticed that Florian's
patchset had an elegant solution to avoid the branch: set tc_at_ingress in
handle_ing before tc_classify and clear it on the return path.
Then we only set + clear it once on ingress regardless of the depth
of classifiers and do not touch it at all in other code.
https://patchwork.ozlabs.org/patch/472698/
What do you think of that approach?
^ permalink raw reply
* Re: [PATCH] sh_eth: fix EESIPR values for SH77{34|63}
From: Sergei Shtylyov @ 2017-01-04 19:27 UTC (permalink / raw)
To: netdev, linux-renesas-soc
In-Reply-To: <1819012.0ROIJmx7mp@wasted.cogentembedded.com>
On 01/04/2017 10:18 PM, Sergei Shtylyov wrote:
> As the SH77{34|63} manuals are freely available, I've checked the EESIPR
> values written against the manuals, and they appeared to set the reserved
> bits 11-15 (which should be 0 on write). Fix those EESIPR values.
>
> Fixes: 380af9e390ec ("net: sh_eth: CPU dependency code collect to "struct sh_eth_cpu_data"")
For SH7763 the bug is older than this commit but the code was common for
all SH SoCs supported back then and so couldn't be fixed w/o affecting other
SoCs. However, I suspect that the mask was incorrect even for the other SoCs...
> Fixes: f5d12767c8fd ("sh_eth: get SH77{34|63} support out of #ifdef")
That's the point where SH7734/63 data were split...
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] liquidio VF: fix incorrect struct being used
From: Felix Manlunas @ 2017-01-04 19:31 UTC (permalink / raw)
To: davem; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
From: Prasad Kanneganti <prasad.kanneganti@cavium.com>
The VF driver is using the wrong struct when sending commands to the NIC
firmware, sometimes causing adverse effects in the firmware. The right
struct is the one that the PF is using, so make the VF use that as well.
Signed-off-by: Prasad Kanneganti <prasad.kanneganti@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
---
drivers/net/ethernet/cavium/liquidio/octeon_nic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_nic.c b/drivers/net/ethernet/cavium/liquidio/octeon_nic.c
index c3d6a82..0243be8 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_nic.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_nic.c
@@ -49,7 +49,7 @@ octeon_alloc_soft_command_resp(struct octeon_device *oct,
/* Add in the response related fields. Opcode and Param are already
* there.
*/
- if (OCTEON_CN23XX_PF(oct)) {
+ if (OCTEON_CN23XX_PF(oct) || OCTEON_CN23XX_VF(oct)) {
ih3 = (struct octeon_instr_ih3 *)&sc->cmd.cmd3.ih3;
rdp = (struct octeon_instr_rdp *)&sc->cmd.cmd3.rdp;
irh = (struct octeon_instr_irh *)&sc->cmd.cmd3.irh;
@@ -70,7 +70,7 @@ octeon_alloc_soft_command_resp(struct octeon_device *oct,
*sc->status_word = COMPLETION_WORD_INIT;
- if (OCTEON_CN23XX_PF(oct))
+ if (OCTEON_CN23XX_PF(oct) || OCTEON_CN23XX_VF(oct))
sc->cmd.cmd3.rptr = sc->dmarptr;
else
sc->cmd.cmd2.rptr = sc->dmarptr;
^ permalink raw reply related
* Re: [PATCH net-next rfc 5/6] net-tc: convert tc_at to tc_at_ingress
From: Daniel Borkmann @ 2017-01-04 19:51 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Network Development, David Miller, Florian Westphal, dborkman,
Jamal Hadi Salim, Alexei Starovoitov, Willem de Bruijn
In-Reply-To: <CAF=yD-+x7zP2Z5Ctsn9-_uYz7sfdZMf4n414CE1-bzVQcN3nBA@mail.gmail.com>
On 01/04/2017 08:26 PM, Willem de Bruijn wrote:
>>> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>>> index ef53ede..be4e18d 100644
>>> --- a/net/sched/sch_api.c
>>> +++ b/net/sched/sch_api.c
>>> @@ -1865,6 +1865,7 @@ int tc_classify(struct sk_buff *skb, const struct
>>> tcf_proto *tp,
>>> const struct tcf_proto *old_tp = tp;
>>> int limit = 0;
>>>
>>> + skb->tc_at_ingress = !!(tp && tp->q->flags & TCQ_F_INGRESS);
>>
>> I'd prefer if skb->tc_at_ingress is set directly to 0/1 in
>> sch_handle_ingress()
>> and __dev_queue_xmit() as we do right now, this would avoid above tests in
>> fast
>> path and it would also avoid to set the same thing in tc_classify() multiple
>> times f.e. on egress path walking through multiple qdiscs. I don't see
>> anything
>> in layers above tc that would read it and expect an AT_STACK-like
>> equivalent.
>> skb_reset_tc() could thus still remain as you have above in fast-path like
>> __netif_receive_skb_core().
>
> I had been thinking about that. After submitting this I noticed that Florian's
> patchset had an elegant solution to avoid the branch: set tc_at_ingress in
> handle_ing before tc_classify and clear it on the return path.
>
> Then we only set + clear it once on ingress regardless of the depth
> of classifiers and do not touch it at all in other code.
>
> https://patchwork.ozlabs.org/patch/472698/
>
> What do you think of that approach?
I think this approach might not work, it would certainly change semantics
since right now *before* going into tc_classify() we always update skb->tc_verd's
"at" location. After the patch we'd set TC_AT_INGRESS in ingress and could
redirect within tc_classify() [and we'd skip that skb->tc_verd = 0 we have in
__netif_receive_skb_core() for these] to xmit from there where next call into
classifier from __dev_queue_xmit() call-site misses that we're not at ingress
anymore but already at egress, so it would do wrong pull/push of headers in
some cls, for example. I mentioned above that I think your skb_reset_tc() for
the __netif_receive_skb_core() fast-path could stay as you have it in that patch
as afaik there's no user that reads out this value in above layers, so if we
keep the "at" info always correct before going into tc_classify(), we should
be good.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] phy state machine: failsafe leave invalid RUNNING state
From: kbuild test robot @ 2017-01-04 20:07 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: kbuild-all, netdev, f.fainelli, andrew
In-Reply-To: <1483542298-9747-1-git-send-email-zefir.kurtisi@neratec.com>
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
Hi Zefir,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc2 next-20170104]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Zefir-Kurtisi/phy-state-machine-failsafe-leave-invalid-RUNNING-state/20170105-033018
config: x86_64-kexec (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/phy/phy.c: In function 'phy_state_machine':
>> drivers/net/phy/phy.c:1075:20: error: 'struct phy_device' has no member named 'dev'; did you mean 'drv'?
dev_warn(&phydev->dev, "no link in PHY_RUNNING\n");
^~
vim +1075 drivers/net/phy/phy.c
1069 * Failsafe: check that nobody set phydev->link=0 between two
1070 * poll cycles, otherwise we won't leave RUNNING state as long
1071 * as link remains down.
1072 */
1073 if (!phydev->link && phydev->state == PHY_RUNNING) {
1074 phydev->state = PHY_CHANGELINK;
> 1075 dev_warn(&phydev->dev, "no link in PHY_RUNNING\n");
1076 }
1077 break;
1078 case PHY_CHANGELINK:
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24448 bytes --]
^ permalink raw reply
* [PATCH] sh_eth: enable RX descriptor word 0 shift on SH7734
From: Sergei Shtylyov @ 2017-01-04 20:10 UTC (permalink / raw)
To: netdev, linux-renesas-soc
The RX descriptor word 0 on SH7734 has the RFS[9:0] field in bits 16-25
(bits 0-15 usually used for that are occupied by the packet checksum).
Thus we need to set the 'shift_rd0' field in the SH7734 SoC data...
Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against DaveM's 'net.git' repo.
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
Index: net/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -819,6 +819,7 @@ static struct sh_eth_cpu_data sh7734_dat
.tsu = 1,
.hw_crc = 1,
.select_mii = 1,
+ .shift_rd0 = 1,
};
/* SH7763 */
^ permalink raw reply
* Re: [PATCH net-next 0/6] Prepare BPF for VLAN_TAG_PRESENT cleanup
From: Daniel Borkmann @ 2017-01-04 20:11 UTC (permalink / raw)
To: Michał Mirosław, netdev; +Cc: alexei.starovoitov
In-Reply-To: <cover.1483492355.git.mirq-linux@rere.qmqm.pl>
On 01/04/2017 02:18 AM, Michał Mirosław wrote:
> Those patches prepare BPF ant its JITs for removal of VLAN_TAG_PRESENT.
> The set depends on "Preparation for VLAN_TAG_PRESENT cleanup" patchset.
>
> The series is supposed to be bisect-friendly and that requires temporary
> insertion of #define VLAN_TAG_PRESENT in BPF code to be able to split
> JIT changes per architecture.
>
> Michał Mirosław (6):
> net/skbuff: add macros for VLAN_PRESENT bit
> net/bpf_jit: ARM: split VLAN_PRESENT bit handling from VLAN_TCI
> net/bpf_jit: MIPS: split VLAN_PRESENT bit handling from VLAN_TCI
> net/bpf_jit: PPC: split VLAN_PRESENT bit handling from VLAN_TCI
> net/bpf_jit: SPARC: split VLAN_PRESENT bit handling from VLAN_TCI
> net/bpf: split VLAN_PRESENT bit handling from VLAN_TCI
Please add a proper changelog to all the individual patches, right now
they have none. Also, how was this runtime tested? Did you run BPF selftest
suite with them? Seems like they weren't even compile tested properly
given the kbuild bot barking on sparc ...
> arch/arm/net/bpf_jit_32.c | 16 ++++++++++------
> arch/mips/net/bpf_jit.c | 18 ++++++++++--------
> arch/powerpc/net/bpf_jit_comp.c | 17 +++++++++--------
> arch/sparc/net/bpf_jit_comp.c | 18 ++++++++++--------
> include/linux/skbuff.h | 6 ++++++
> net/core/filter.c | 19 +++++++++----------
> 6 files changed, 54 insertions(+), 40 deletions(-)
>
^ permalink raw reply
* Re: [RESEND net-next PATCH v5] net: dummy: Introduce dummy virtual functions
From: Phil Sutter @ 2017-01-04 20:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sd
In-Reply-To: <20170104.140914.1059886799372716512.davem@davemloft.net>
On Wed, Jan 04, 2017 at 02:09:14PM -0500, David Miller wrote:
> From: Phil Sutter <phil@nwl.cc>
> Date: Wed, 4 Jan 2017 14:44:06 +0100
>
> > The idea for this was born when testing VF support in iproute2 which was
> > impeded by hardware requirements. In fact, not every VF-capable hardware
> > driver implements all netdev ops, so testing the interface is still hard
> > to do even with a well-sorted hardware shelf.
> >
> > To overcome this and allow for testing the user-kernel interface, this
> > patch allows to turn dummy into a PF with a configurable amount of VFs.
> >
> > Due to the assumption that all PFs are PCI devices, this implementation
> > is not completely straightforward: In order to allow for
> > rtnl_fill_ifinfo() to see the dummy VFs, a fake PCI parent device is
> > attached to the dummy netdev. This has to happen at the right spot so
> > register_netdevice() does not get confused. This patch abuses
> > ndo_fix_features callback for that. In ndo_uninit callback, the fake
> > parent is removed again for the same purpose.
> >
> > Joint work with Sabrina Dubroca.
> >
> > Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
>
> First of all I really applaud any effort to make the kernel interfaces
> more testable, and less dependent upon having specific pieces of hardware.
>
> That being said, all of this seems to be fighting the problem from the
> wrong direction.
>
> The device layer is really kidding itself by having what seems like a
> generic method in the form of dev_num_vf(), which actually just tests
> the bus type and calls a bus specific function on a match.
>
> There is no reason in the world that this cannot be done via proper
> device method call, that any bus type or whatever can implement.
Yes, this is certainly the proper way to do this. Thanks for your
confirmation!
> Then you don't need any of this stuff, you just hook up the proper
> device method to the dummy device and you're good.
My goal with this (admittedly fugly) hack was to be least intrusive as
possible, allowing people to use the module solely for testing purposes
in case the patch was rejected for other reasons.
I'm glad to see you're not against this practically useless enhancement
of dummy.c per se and so will try to come up with a proper fix for
dev_num_vf() paving the way for a hack-free version of it.
Thanks, Phil
^ permalink raw reply
* Re: [PATCH net-next rfc 5/6] net-tc: convert tc_at to tc_at_ingress
From: Willem de Bruijn @ 2017-01-04 20:20 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Network Development, David Miller, Florian Westphal, dborkman,
Jamal Hadi Salim, Alexei Starovoitov, Willem de Bruijn
In-Reply-To: <586D5231.5080706@iogearbox.net>
On Wed, Jan 4, 2017 at 2:51 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 01/04/2017 08:26 PM, Willem de Bruijn wrote:
>>>>
>>>> diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
>>>> index ef53ede..be4e18d 100644
>>>> --- a/net/sched/sch_api.c
>>>> +++ b/net/sched/sch_api.c
>>>> @@ -1865,6 +1865,7 @@ int tc_classify(struct sk_buff *skb, const struct
>>>> tcf_proto *tp,
>>>> const struct tcf_proto *old_tp = tp;
>>>> int limit = 0;
>>>>
>>>> + skb->tc_at_ingress = !!(tp && tp->q->flags & TCQ_F_INGRESS);
>>>
>>>
>>> I'd prefer if skb->tc_at_ingress is set directly to 0/1 in
>>> sch_handle_ingress()
>>> and __dev_queue_xmit() as we do right now, this would avoid above tests
>>> in
>>> fast
>>> path and it would also avoid to set the same thing in tc_classify()
>>> multiple
>>> times f.e. on egress path walking through multiple qdiscs. I don't see
>>> anything
>>> in layers above tc that would read it and expect an AT_STACK-like
>>> equivalent.
>>> skb_reset_tc() could thus still remain as you have above in fast-path
>>> like
>>> __netif_receive_skb_core().
>>
>>
>> I had been thinking about that. After submitting this I noticed that
>> Florian's
>> patchset had an elegant solution to avoid the branch: set tc_at_ingress in
>> handle_ing before tc_classify and clear it on the return path.
>>
>> Then we only set + clear it once on ingress regardless of the depth
>> of classifiers and do not touch it at all in other code.
>>
>> https://patchwork.ozlabs.org/patch/472698/
>>
>> What do you think of that approach?
>
>
> I think this approach might not work, it would certainly change semantics
> since right now *before* going into tc_classify() we always update
> skb->tc_verd's
> "at" location. After the patch we'd set TC_AT_INGRESS in ingress and could
> redirect within tc_classify() [and we'd skip that skb->tc_verd = 0 we have
> in
> __netif_receive_skb_core() for these] to xmit from there where next call
> into
> classifier from __dev_queue_xmit() call-site misses that we're not at
> ingress
> anymore but already at egress, so it would do wrong pull/push of headers in
> some cls, for example.
Oh, yes, of course. Okay, I will follow the existing code in v1. Thanks, Daniel.
^ permalink raw reply
* Re: [PATCH] phy state machine: failsafe leave invalid RUNNING state
From: kbuild test robot @ 2017-01-04 20:23 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: kbuild-all, netdev, f.fainelli, andrew
In-Reply-To: <1483542298-9747-1-git-send-email-zefir.kurtisi@neratec.com>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
Hi Zefir,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc2 next-20170104]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Zefir-Kurtisi/phy-state-machine-failsafe-leave-invalid-RUNNING-state/20170105-033018
config: i386-randconfig-i1-201701 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/phy/phy.c: In function 'phy_state_machine':
>> drivers/net/phy/phy.c:1075:20: error: 'struct phy_device' has no member named 'dev'
dev_warn(&phydev->dev, "no link in PHY_RUNNING\n");
^
vim +1075 drivers/net/phy/phy.c
1069 * Failsafe: check that nobody set phydev->link=0 between two
1070 * poll cycles, otherwise we won't leave RUNNING state as long
1071 * as link remains down.
1072 */
1073 if (!phydev->link && phydev->state == PHY_RUNNING) {
1074 phydev->state = PHY_CHANGELINK;
> 1075 dev_warn(&phydev->dev, "no link in PHY_RUNNING\n");
1076 }
1077 break;
1078 case PHY_CHANGELINK:
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29567 bytes --]
^ permalink raw reply
* [PATCH net] amd-xgbe: Fix IRQ processing when running in single IRQ mode
From: Tom Lendacky @ 2017-01-04 21:07 UTC (permalink / raw)
To: netdev; +Cc: David Miller
When running in single IRQ mode, the additional IRQ routines were being
skipped because only the XGMAC interrupt status was being checked.
Update the code so that the additional IRQ routines are checked whenever
an interrupt is received.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index 155190d..9943629 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -539,6 +539,7 @@ static irqreturn_t xgbe_isr(int irq, void *data)
}
}
+isr_done:
/* If there is not a separate AN irq, handle it here */
if (pdata->dev_irq == pdata->an_irq)
pdata->phy_if.an_isr(irq, pdata);
@@ -551,7 +552,6 @@ static irqreturn_t xgbe_isr(int irq, void *data)
if (pdata->vdata->i2c_support && (pdata->dev_irq == pdata->i2c_irq))
pdata->i2c_if.i2c_isr(irq, pdata);
-isr_done:
return IRQ_HANDLED;
}
^ permalink raw reply related
* Re: [PATCH repost net-next] dsa: mv88e6xxx: Optimise atu_get
From: David Miller @ 2017-01-04 21:11 UTC (permalink / raw)
To: andrew; +Cc: volodymyr.bendiuga, vivien.didelot, f.fainelli, netdev
In-Reply-To: <1483556184-4176-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 4 Jan 2017 19:56:24 +0100
> +static inline u64 ether_addr_to_u64(const u8 *addr)
> +{
> + u64 u = 0;
> + int i;
> +
> + for (i = 0; i < ETH_ALEN; i++)
> + u = u << 8 | addr[i];
> +
> + return u;
> +}
...
> +static inline void u64_to_ether_addr(u64 u, u8 *addr)
> +{
> + int i;
> +
> + for (i = ETH_ALEN - 1; i >= 0; i--) {
> + addr[i] = u & 0xff;
> + u = u >> 8;
> + }
> +}
I think these two routines behave differently on big vs little
endian. And I doubt this was your intention.
^ permalink raw reply
* Re: [PATCH] sh_eth: enable RX descriptor word 0 shift on SH7734
From: David Miller @ 2017-01-04 21:12 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <1893574.OD9Leu8Ck8@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Wed, 04 Jan 2017 23:10:23 +0300
> The RX descriptor word 0 on SH7734 has the RFS[9:0] field in bits 16-25
> (bits 0-15 usually used for that are occupied by the packet checksum).
> Thus we need to set the 'shift_rd0' field in the SH7734 SoC data...
>
> Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH repost net-next] dsa: mv88e6xxx: Optimise atu_get
From: Andrew Lunn @ 2017-01-04 21:19 UTC (permalink / raw)
To: David Miller; +Cc: volodymyr.bendiuga, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20170104.161103.175830630875484681.davem@davemloft.net>
On Wed, Jan 04, 2017 at 04:11:03PM -0500, David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Wed, 4 Jan 2017 19:56:24 +0100
>
> > +static inline u64 ether_addr_to_u64(const u8 *addr)
> > +{
> > + u64 u = 0;
> > + int i;
> > +
> > + for (i = 0; i < ETH_ALEN; i++)
> > + u = u << 8 | addr[i];
> > +
> > + return u;
> > +}
> ...
> > +static inline void u64_to_ether_addr(u64 u, u8 *addr)
> > +{
> > + int i;
> > +
> > + for (i = ETH_ALEN - 1; i >= 0; i--) {
> > + addr[i] = u & 0xff;
> > + u = u >> 8;
> > + }
> > +}
>
> I think these two routines behave differently on big vs little
> endian. And I doubt this was your intention.
I don't have a big endian system to test on.
I tried to avoid the usual pitfalls. I don't cast a collection of
bytes to a u64, which i know has no chance of working. Accessing a MAC
address as a byte array should be endian safe. The shift operation
should also be endian safe.
What exactly do you think will behave differently?
Andrew
^ 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