* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: Jie Deng @ 2017-01-11 4:00 UTC (permalink / raw)
To: Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, alexandre.torgue, netdev,
CARLOS.PALMINHA
In-Reply-To: <c74e6665ca14a4ca03b38cd3442ef0644d9e250d.1484059674.git.jpinto@synopsys.com>
Hi Joao,
On 2017/1/10 22:52, Joao Pinto wrote:
> This patch renames stmicro/stmmac to synopsys/ since it is a standard
> ethernet software package regarding synopsys ethernet controllers, supporting
> the majority of Synopsys Ethernet IPs. The config IDs remain the same, for
> retro-compatibility, only the description was changed.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> ---
> changes v1->v2:
> - nothing changed. Just to keep up with patch set version
>
> @@ -1,5 +1,5 @@
> config STMMAC_ETH
> - tristate "STMicroelectronics 10/100/1000 Ethernet driver"
> + tristate "Synopsys Ethernet drivers"
> depends on HAS_IOMEM && HAS_DMA
> select MII
> select PHYLIB
> @@ -14,7 +14,7 @@ config STMMAC_ETH
> if STMMAC_ETH
>
"Synopsys Ethernet drivers" is too generic. The name should reflect the
controller. This driver is for Synopsys GMAC 10M/100M/1G IPs. We will submit a
driver for the new 25G/40G/50G/100G XLGMAC IP in the future.
> config STMMAC_PLATFORM
> - tristate "STMMAC Platform bus support"
> + tristate "Platform bus support"
> depends on STMMAC_ETH
> select MFD_SYSCON
> default y
> @@ -149,13 +149,13 @@ config DWMAC_SUNXI
> endif
>
> config STMMAC_PCI
> - tristate "STMMAC PCI bus support"
> + tristate "PCI bus support"
> depends on STMMAC_ETH && PCI
> ---help---
> This is to select the Synopsys DWMAC available on PCI devices,
> if you have a controller with this interface, say Y or M here.
>
> - This PCI support is tested on XLINX XC2V3000 FF1152AMT0221
> + This PCI support was tested on XLINX XC2V3000 FF1152AMT0221
> D1215994A VIRTEX FPGA board.
The name is also too generic. Please try to reflect the controller.
Thanks,
Jie
^ permalink raw reply
* Re: [RFC PATCH] tcp: accept RST for rcv_nxt - 1 after receiving a FIN
From: Christoph Paasch @ 2017-01-11 5:17 UTC (permalink / raw)
To: Jason Baron; +Cc: netdev
In-Reply-To: <1483652008-20255-1-git-send-email-jbaron@akamai.com>
Hello Jason,
(resending as Gmail sent out with HTML)
On 05/01/17 - 16:33:28, Jason Baron wrote:
> Using a Mac OSX box as a client connecting to a Linux server, we have found
> that when certain applications (such as 'ab'), are abruptly terminated
> (via ^C), a FIN is sent followed by a RST packet on tcp connections. The
> FIN is accepted by the Linux stack but the RST is sent with the same
> sequence number as the FIN, and Linux responds with a challenge ACK per
> RFC 5961. The OSX client then does not reply with any RST as would be
> expected on a closed socket.
do you see this behavior consistently, even in a controlled environment?
The problem seems rather to be that after the first RST, the NAT on the path
has dropped its mapping and is thus dropping all other traffic. So, Linux's
challenge-ack does not go through to the OSX-host to "re-synchronize" the
state (which would allow OSX to send a RST with the updated sequence numbers).
This is also documented in RFC5961:
9.3. Middleboxes That Drop the Challenge ACK
It also needs to be noted that, some middleboxes (Firewalls/NATs)
that don't have the fix recommended in the document, may drop the
challenge ACK. This can happen because, the original RST segment
that was in window had already cleared the flow state pertaining to
the TCP connection in the middlebox. In such cases, the end hosts
that have implemented the RST mitigation described in this document,
will have the TCP connection left open. This is a corner case and
can go away if the middlebox is conformant with the changes proposed
in this document.
Cheers,
Christoph
>
> This results in sockets accumulating on the Linux server left mostly in
> the CLOSE_WAIT state, although LAST_ACK and CLOSING are also possible.
> This sequence of events can tie up a lot of resources on the Linux server
> since there may be a lot of data in write buffers at the time of the RST.
> Accepting a RST equal to rcv_nxt - 1, after we have already successfully
> processed a FIN, has made a significant difference for us in practice, by
> freeing up unneeded resources in a more expedient fashion.
>
> I also found a posting that the iOS client behaves in a similar manner here
> (it will send a FIN followed by a RST for rcv_nxt - 1):
> https://www.snellman.net/blog/archive/2016-02-01-tcp-rst/
>
> A packetdrill test demonstrating the behavior.
>
> // testing mac osx rst behavior
>
> // Establish a connection
> 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> 0.000 bind(3, ..., ...) = 0
> 0.000 listen(3, 1) = 0
>
> 0.100 < S 0:0(0) win 32768 <mss 1460,nop,wscale 10>
> 0.100 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 5>
> 0.200 < . 1:1(0) ack 1 win 32768
> 0.200 accept(3, ..., ...) = 4
>
> // Client closes the connection
> 0.300 < F. 1:1(0) ack 1 win 32768
>
> // now send rst with same sequence
> 0.300 < R. 1:1(0) ack 1 win 32768
>
> // make sure we are in TCP_CLOSE
> 0.400 %{
> assert tcpi_state == 7
> }%
>
> Signed-off-by: Jason Baron <jbaron@akamai.com>
> ---
> net/ipv4/tcp_input.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index ec6d84363024..373bea05c93b 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -5249,6 +5249,24 @@ static int tcp_copy_to_iovec(struct sock *sk, struct sk_buff *skb, int hlen)
> return err;
> }
>
> +/* Accept RST for rcv_nxt - 1 after a FIN.
> + * When tcp connections are abruptly terminated from Mac OSX (via ^C), a
> + * FIN is sent followed by a RST packet. The RST is sent with the same
> + * sequence number as the FIN, and thus according to RFC 5961 a challenge
> + * ACK should be sent. However, Mac OSX does not reply to the challenge ACK
> + * with a RST on the closed socket, hence accept this class of RSTs.
> + */
> +static bool tcp_reset_check(struct sock *sk, struct sk_buff *skb)
> +{
> + struct tcp_sock *tp = tcp_sk(sk);
> +
> + return unlikely((TCP_SKB_CB(skb)->seq == (tp->rcv_nxt - 1)) &&
> + (TCP_SKB_CB(skb)->end_seq == (tp->rcv_nxt - 1)) &&
> + (sk->sk_state == TCP_CLOSE_WAIT ||
> + sk->sk_state == TCP_LAST_ACK ||
> + sk->sk_state == TCP_CLOSING));
> +}
> +
> /* Does PAWS and seqno based validation of an incoming segment, flags will
> * play significant role here.
> */
> @@ -5287,6 +5305,8 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
> LINUX_MIB_TCPACKSKIPPEDSEQ,
> &tp->last_oow_ack_time))
> tcp_send_dupack(sk, skb);
> + } else if (tcp_reset_check(sk, skb)) {
> + tcp_reset(sk);
> }
> goto discard;
> }
> @@ -5300,7 +5320,8 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
> * else
> * Send a challenge ACK
> */
> - if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt) {
> + if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt ||
> + tcp_reset_check(sk, skb)) {
> rst_seq_match = true;
> } else if (tcp_is_sack(tp) && tp->rx_opt.num_sacks > 0) {
> struct tcp_sack_block *sp = &tp->selective_acks[0];
> --
> 2.6.1
>
^ permalink raw reply
* Re: [PATCH net-next v3 10/27] benet: use __vlan_hwaccel helpers
From: Somnath Kotur @ 2017-01-11 5:29 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, Ajit Khaparde
In-Reply-To: <8a9f0d12b69ee4e25fefc4872575d5cf31441bb8.1483484748.git.mirq-linux@rere.qmqm.pl>
On Wed, Jan 4, 2017 at 4:41 AM, Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
> v3: fix adapter->pvid handling
>
> drivers/net/ethernet/emulex/benet/be_main.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 7e1633bf5a22..cd12c9a7664b 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -1035,30 +1035,35 @@ static struct sk_buff *be_insert_vlan_in_pkt(struct be_adapter *adapter,
> struct be_wrb_params
> *wrb_params)
> {
> + bool insert_vlan = false;
> u16 vlan_tag = 0;
>
> skb = skb_share_check(skb, GFP_ATOMIC);
> if (unlikely(!skb))
> return skb;
>
> - if (skb_vlan_tag_present(skb))
> + if (skb_vlan_tag_present(skb)) {
> vlan_tag = be_get_tx_vlan_tag(adapter, skb);
> + insert_vlan = true;
> + }
>
> if (qnq_async_evt_rcvd(adapter) && adapter->pvid) {
> - if (!vlan_tag)
> + if (!insert_vlan) {
> vlan_tag = adapter->pvid;
> + insert_vlan = true;
> + }
> /* f/w workaround to set skip_hw_vlan = 1, informs the F/W to
> * skip VLAN insertion
> */
> BE_WRB_F_SET(wrb_params->features, VLAN_SKIP_HW, 1);
> }
>
> - if (vlan_tag) {
> + if (insert_vlan) {
> skb = vlan_insert_tag_set_proto(skb, htons(ETH_P_8021Q),
> vlan_tag);
> if (unlikely(!skb))
> return skb;
> - skb->vlan_tci = 0;
> + __vlan_hwaccel_clear_tag(skb);
> }
>
> /* Insert the outer VLAN, if any */
> --
> 2.11.0
>
Thanks
Acked-by: Somnath Kotur <somnath.kotur@broadcom.com>
^ permalink raw reply
* Re: [RFC PATCH 2/4] page_pool: basic implementation of page_pool
From: Jesper Dangaard Brouer @ 2017-01-11 7:10 UTC (permalink / raw)
To: Mel Gorman
Cc: Vlastimil Babka, linux-mm, Alexander Duyck, willemdebruijn.kernel,
netdev, john.fastabend, Saeed Mahameed, bjorn.topel,
Alexei Starovoitov, Tariq Toukan, brouer
In-Reply-To: <20170109215825.k4grwyhffiv6wksp@techsingularity.net>
On Mon, 9 Jan 2017 21:58:26 +0000
Mel Gorman <mgorman@techsingularity.net> wrote:
> On Mon, Jan 09, 2017 at 09:45:24PM +0100, Jesper Dangaard Brouer wrote:
> > > I see. I guess if all page pool pages were order>0 compound pages, you
> > > could hook this to the existing compound_dtor functionality instead.
> >
> > The page_pool will support order>0 pages, but it is the order-0 case
> > that is optimized for.
> >
>
> The bulk allocator is currently not suitable for high-order pages. It would
> take more work to do that but is not necessarily even a good idea. FWIW,
> the high-order per-cpu page allocator posted some weeks ago would be the
> basis. I didn't push that series as the benefit to SLUB was too marginal
> given the complexity.
>
> > > Well typically the VMA mapped pages are those on the LRU list (anonymous
> > > or file). But I don't suppose you will want memory reclaim to free your
> > > pages, so seems lru field should be reusable for you.
> >
> > Thanks for the info.
> >
> > So, LRU-list area could be reusable, but I does not align so well with
> > the bulking API Mel just introduced/proposed, but still doable.
> >
>
> That's a relatively minor implementation detail. I needed something to
> hang the pages onto for returning. Using a list and page->lru is a standard
> approach but it does not mandate that the caller preserve page->lru or that
> it's related to the LRU. The caller simply needs to put the pages back onto
> a list if it's bulk freeing or call __free_pages() directly for each page.
> If any in-kernel user uses __free_pages() then the free_pages_bulk()
> API can be dropped entirely.
>
> I'm not intending to merge the bulk allocator due to a lack of in-kernel
> users and an inability to test in-kernel users. It was simply designed to
> illustrate how to call the core of the page allocator in a way that avoids
> the really expensive checks. If required, the pages could be returned on
> a caller-allocated array or something exotic like using one page to store
> pointers to the rest. Either of those alternatives are harder to use. A
> caller-allocated array must be sure the nr_pages parameter is correct and
> the exotic approach would require careful use by the caller. Using page->lru
> was more straight-forward when the requirements of the callers was unknown.
>
> It opens the question of what to do with that series. I was going to wait
> for feedback but my intent was to try merge patches 1-3 if there were no
> objections and preferably with your reviewed-by or ack. I would then hand
> patch 4 over to you for addition to a series that added in-kernel callers to
> alloc_pages_bulk() be that the generic pool recycle or modifying drivers.
> You are then free to modify the API to suit your needs without having to
> figure out the best way of calling the page allocator.
I think that sound like a good plan.
Your patches 1-3 is a significant performance improvement for the page
allocator, and I want to see those merged. Don't want to block it with
patch 4 (bulking).
I'm going to do some (more) testing on your patchset, and then ACK the
patches.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v2] net: dsa: make "label" property optional for dsa2
From: Jiri Pirko @ 2017-01-11 7:26 UTC (permalink / raw)
To: Florian Fainelli
Cc: Vivien Didelot, netdev, linux-kernel, kernel, David S. Miller,
Andrew Lunn, Uwe Kleine-König, Andrey Smirnov
In-Reply-To: <3c7e5102-cef7-c909-a192-6238103e444e@gmail.com>
Tue, Jan 10, 2017 at 06:58:18PM CET, f.fainelli@gmail.com wrote:
>On 01/10/2017 01:55 AM, Jiri Pirko wrote:
>> Mon, Jan 09, 2017 at 07:06:39PM CET, f.fainelli@gmail.com wrote:
>>> On 01/09/2017 09:58 AM, Jiri Pirko wrote:
>>>> Mon, Jan 09, 2017 at 06:42:07PM CET, f.fainelli@gmail.com wrote:
>>>>> On 01/09/2017 08:06 AM, Jiri Pirko wrote:
>>>>>> Mon, Jan 09, 2017 at 04:45:33PM CET, vivien.didelot@savoirfairelinux.com wrote:
>>>>>>> Hi Jiri,
>>>>>>>
>>>>>>> Jiri Pirko <jiri@resnulli.us> writes:
>>>>>>>
>>>>>>>>> Extra question: shouldn't phys_port_{id,name} be switchdev attributes in
>>>>>>>>
>>>>>>>> Again, phys_port_id has nothing to do with switches. Should be removed
>>>>>>>> from dsa because its use there is incorrect.
>>>>>>>
>>>>>>> Florian, since 3a543ef just got in, can it be reverted?
>>>>>>
>>>>>> Yes, please revert it. It is only in net-next.
>>>>>
>>>>> Maybe the use case can be understood before reverting the change. How do
>>>>> we actually the physical port number of an Ethernet switch per-port
>>>>> network device? The name is not enough, because there are plenty of
>>>>> cases where we need to manipulate a physical port number (be it just for
>>>>> informational purposes).
>>>>
>>>> Like what?
>>>
>>> Specifying the physical port number (and derive a queue number
>>> eventually) for some ethtool (e.g: rxnfc)/tc (queue mapping) operations
>>> where there is an action/queue/port destination argument that gets
>>> programmed into the hardware.
>>
>> Could you point me to a real example? User command?
>
>ethtool --config-nfc moca flow-type udp4 src-ip 192.168.1.20 dst-ip \
> 192.168.1.10 src-port 49884 dst-port 5001 action 2
>
>Where 2 here designates a port number, users need to be able to look up
>the physical port number corresponding to an interface to know which
>value to put in this command.
2 is not a port number but RX queue number. I believe you need to
ditinguish that and port_name. Not sure how are they related.
>
>Yes I know we can do the same thing with cls_flower, possibly by
>referencing network devices directly.
Yes, that is what you should do. I believe that using config-nfc is not
correct for this use-case.
>
>>
>>
>>>
>>> You already have the originating port number from the interface you call
>>> the method against, but you also need the destination port number since
>>> that is what the HW understands.
>>
>> This is internal to kernel? I fail to understand what you mean exactly.
>
>See the command above, from using the "moca" netdev here, we can access
>the DSA private network device (dsa_slave_priv) structure and get the
>port number from there, and pass this down to the switch driver. The
>switch driver also takes another port number (and eventually a queue
>number) to program classification filters.
>
>>
>>
>>>
>>> Aside from that, it is useful for allowing interface naming in user
>>> space if you don't want to use labels.
>>>
>>>>
>>>> Why the name is not enough? This is something propagated to userspace
>>>> and never used internally in kernel.
>>>
>>> Because the name is not reflective of the port number in some switches.
>>> In my case for instance, we have 5 ports that are named after the
>>> entities they connect to (an integrated Gigabit PHY, two RGMII pads, one
>>> MoCA interface, and the CPU)
>>>
>>
>> Again, I'm missing why you need a portnumber as a Integer to userspace.
>> From driver, you can expose phys_port_name:
>
>If we are exposing the port name here, we may as well expose the DSA
>"label" instead of the physical port number number?
Yeah, that makes sense.
>
>I don't deny my change may be misusing what phys_port_id was originally
>designed for, but providing "p0" instead of "0" to user-space, what
>value is there in adding the "p" in front really?
It's up to a driver. He knows how the front panel names look like.
>--
>Florian
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: Implement ndo_get_phys_port_name()
From: Jiri Pirko @ 2017-01-11 7:28 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, netdev, davem, vivien.didelot
In-Reply-To: <60d188ef-a080-1707-9ff2-0ebfa58b81d2@gmail.com>
Tue, Jan 10, 2017 at 09:58:53PM CET, f.fainelli@gmail.com wrote:
>On 01/10/2017 12:50 PM, Andrew Lunn wrote:
>> On Tue, Jan 10, 2017 at 12:32:36PM -0800, Florian Fainelli wrote:
>>> Return the physical port number of a DSA created network device using
>>> ndo_get_phys_port_name().
>>
>> At what level does this need to be unique?
>
>This needs to be unique to the switch I would say,
Yes.
>ndo_get_phys_switch_id would return the physical number of the switch
>device in the tree/cluster, so that number plus the port name should be
>an unique differentiator that is good enough for e.g: a persistent
>naming rule?
Yes.
>
>>
>> We can have multiple switches within one switch cluster. p->port will
>> be unique within one switch, but can be repeated in a cluster.
>>
>> We can also have multiple clusters, and again p->port will be re-used.
>
>
>--
>Florian
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: Implement ndo_get_phys_port_name()
From: Jiri Pirko @ 2017-01-11 7:29 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem, vivien.didelot, andrew
In-Reply-To: <20170110203237.23907-2-f.fainelli@gmail.com>
Tue, Jan 10, 2017 at 09:32:36PM CET, f.fainelli@gmail.com wrote:
>Return the physical port number of a DSA created network device using
>ndo_get_phys_port_name().
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>---
> net/dsa/slave.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
>diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>index 5cd5b8137c08..fed3fbd403cb 100644
>--- a/net/dsa/slave.c
>+++ b/net/dsa/slave.c
>@@ -990,6 +990,15 @@ static int dsa_slave_get_phys_port_id(struct net_device *dev,
>
> ppid->id_len = sizeof(p->port);
> memcpy(ppid->id, &p->port, ppid->id_len);
>+}
>+
>+static int dsa_slave_get_phys_port_name(struct net_device *dev,
>+ char *name, size_t len)
>+{
>+ struct dsa_slave_priv *p = netdev_priv(dev);
>+
>+ if (snprintf(name, len, "p%d", p->port) >= len)
>+ return -EINVAL;
>
> return 0;
> }
>@@ -1042,6 +1051,7 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
> .ndo_bridge_setlink = switchdev_port_bridge_setlink,
> .ndo_bridge_dellink = switchdev_port_bridge_dellink,
> .ndo_get_phys_port_id = dsa_slave_get_phys_port_id,
>+ .ndo_get_phys_port_name = dsa_slave_get_phys_port_name,
> };
>
> static const struct switchdev_ops dsa_slave_switchdev_ops = {
>--
>2.9.3
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] Revert "net: dsa: Implement ndo_get_phys_port_id"
From: Jiri Pirko @ 2017-01-11 7:29 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem, vivien.didelot, andrew
In-Reply-To: <20170110203237.23907-3-f.fainelli@gmail.com>
Tue, Jan 10, 2017 at 09:32:37PM CET, f.fainelli@gmail.com wrote:
>This reverts commit 3a543ef479868e36c95935de320608a7e41466ca ("net: dsa:
>Implement ndo_get_phys_port_id") since it misuses the purpose of
>ndo_get_phys_port_id(). We have ndo_get_phys_port_name() to do the
>correct thing for us now.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>---
> net/dsa/slave.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
>diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>index fed3fbd403cb..0cdcaf526987 100644
>--- a/net/dsa/slave.c
>+++ b/net/dsa/slave.c
>@@ -983,15 +983,6 @@ static void dsa_slave_poll_controller(struct net_device *dev)
> }
> #endif
>
>-static int dsa_slave_get_phys_port_id(struct net_device *dev,
>- struct netdev_phys_item_id *ppid)
>-{
>- struct dsa_slave_priv *p = netdev_priv(dev);
>-
>- ppid->id_len = sizeof(p->port);
>- memcpy(ppid->id, &p->port, ppid->id_len);
>-}
>-
> static int dsa_slave_get_phys_port_name(struct net_device *dev,
> char *name, size_t len)
> {
>@@ -1050,7 +1041,6 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
> .ndo_bridge_getlink = switchdev_port_bridge_getlink,
> .ndo_bridge_setlink = switchdev_port_bridge_setlink,
> .ndo_bridge_dellink = switchdev_port_bridge_dellink,
>- .ndo_get_phys_port_id = dsa_slave_get_phys_port_id,
> .ndo_get_phys_port_name = dsa_slave_get_phys_port_name,
> };
>
>--
>2.9.3
>
^ permalink raw reply
* net: ti: cpsw-phy-sel: RGMII is not working on AM335x
From: Teresa Remmet @ 2017-01-11 8:14 UTC (permalink / raw)
To: Alexandru Gagniuc, David S. Miller, Mugunthan V N,
Grygorii Strashko
Cc: linux-omap, netdev
Hello,
I met a issue with the gmii_sel register on the AM335x when using
RGMII. The patch,
commit 74685b08fbb26ff5b8448fabe0941a53269dd33e
Author: Alex <alex.g@adaptrum.com>
Date: Tue Dec 6 10:56:51 2016 -0800
drivers: net: cpsw-phy-sel: Clear RGMII_IDMODE on "rgmii" links
Support for setting the RGMII_IDMODE bit was added in the commit
referenced below. However, that commit did not add the symmetrical
clearing of the bit by way of setting it in "mask". Add it here.
Note that the documentation marks clearing this bit as "reserved",
however, according to TI, support for delaying the clock does exist in
the MAC, although it is not officially supported.
We tested this on a board with an RGMII to RGMII link that will not
work unless this bit is cleared.
Fixes: 0fb26c3063ea ("drivers: net: cpsw-phy-sel: add support to configure rgmii int
Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
is suppose to fix the RGMII mode with setting the RGMII0/1_ID_MODE
bit to 0: "Reserved". I use RMII1 and RGMII2 on our custom
AM335x board. The RMII1 is still working with the patch but
I do not get any data transfered on the RGMII2. When I revert
the patch, everything works again.
I tested this on 4.10-rc3.
The AM335x TRM Rev. O notes on Chapter 14.3.6.4:
"The RGMII0/1_ID_MODE bit value in the GMII_SEL register should
only be set to 1 for 'no internal delay'.
The device does not support internal delay mode for RGMII."
So I wonder what is correct now? As for me the patch makes RGMII unusable.
Has anyone an explanation?
Regards,
Teresa
^ permalink raw reply
* [PATCH net] r8152: fix the sw rx checksum is unavailable
From: Hayes Wang @ 2017-01-11 8:25 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Fix the hw rx checksum is always enabled, and the user couldn't switch
it to sw rx checksum.
Note that the RTL_VER_01 only support sw rx checksum only. Besides,
the hw rx checksum for RTL_VER_02 is disabled after
commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.
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 be41856..f3b48ad 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1730,7 +1730,7 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc *rx_desc)
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
- if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02)
+ if (!(tp->netdev->features & NETIF_F_RXCSUM))
goto return_result;
opts2 = le32_to_cpu(rx_desc->opts2);
@@ -4356,6 +4356,11 @@ static int rtl8152_probe(struct usb_interface *intf,
NETIF_F_HIGHDMA | NETIF_F_FRAGLIST |
NETIF_F_IPV6_CSUM | NETIF_F_TSO6;
+ if (tp->version == RTL_VER_01) {
+ netdev->features &= ~NETIF_F_RXCSUM;
+ netdev->hw_features &= ~NETIF_F_RXCSUM;
+ }
+
netdev->ethtool_ops = &ops;
netif_set_gso_max_size(netdev, RTL_LIMITED_TSO_SIZE);
--
2.7.4
^ permalink raw reply related
* Re: bad interaction between privacy extensions, prefix lifetimes and protocols that maintain long-term connections.
From: Bjørn Mork @ 2017-01-11 8:54 UTC (permalink / raw)
To: peter green; +Cc: debian-ipv6, netdev
In-Reply-To: <9769f6b7-946c-1279-110f-15de8ec40022@p10link.net>
peter green <plugwash@p10link.net> writes:
> Disabling privacy extensions solved the issue but obviously reveals
> the MAC address of my new machine to the world which is undesirable.
I have no solution to the problem with privacy extensions, but just
wanted to let you know there is a third alternative for IPv6
autoconfigured addresses: stable-privacy
This will give you addresses which are just as stable as the eui64
addresses, but derived from a configurable secret instead of the
mac. The kernel part is documented in under 'stable_secret' in
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
If you use NetworkManager, then this is very easy to set up: Just set
'addr-gen-mode' to 'stable-privacy'. See the docs in nm-settings(5).
Or if you use ifupdown and prefer to control it yourself, you can
e.g. save the secret (in IPv6 address format) in some file and write it
to /proc/sys/net/ipv6/conf/default/stable_secret on boot. This will set
a common secret for all interfaces. Note that the generated interface
ids still will be different, since the prefix is used as part of the
input to the generator.
Bjørn
^ permalink raw reply
* Re: [PATCH 2/3] xgbe: switch to pci_irq_alloc_vectors
From: Christoph Hellwig @ 2017-01-11 9:03 UTC (permalink / raw)
To: Tom Lendacky
Cc: Christoph Hellwig, linux-pci, Mauro Carvalho Chehab, netdev,
linux-media
In-Reply-To: <11ed330c-84e9-79e9-7945-ca17a497359c@amd.com>
On Tue, Jan 10, 2017 at 12:40:10PM -0600, Tom Lendacky wrote:
> On 1/9/2017 2:37 PM, Christoph Hellwig wrote:
> > The newly added xgbe drivers uses the deprecated pci_enable_msi_exact
> > and pci_enable_msix_range interfaces. Switch it to use
> > pci_irq_alloc_vectors instead.
>
> I was just working on switching over to this API with some additional
> changes / simplification. I'm ok with using this patch so that you get
> the API removal accomplished. Going through the PCI tree just means
> it will probably be easier for me to hold off on the additional changes
> I wanted to make until later.
Hi Tom,
if you have a better patch I'd be more than happy to use that one instead,
this one was intended as a stupid search and replace. The important
part for me is to get the two conversions and the interface removal
in together.
E.g. I've alreayd wondered why the driver requires the exact vector
number for MSI and a variable one for MSI-X, and there certainly is
all kinds of opportunity for cosmetic cleanup.
^ permalink raw reply
* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Vishwanathapura, Niranjana @ 2017-01-11 9:05 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, ira.weiny, Jeff Kirsher, David S. Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170110081402.GH7218-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
On Tue, Jan 10, 2017 at 10:14:02AM +0200, Leon Romanovsky wrote:
>On Mon, Jan 09, 2017 at 07:39:54PM -0800, Vishwanathapura, Niranjana wrote:
>> We are also looking into Jason’s suggestion to make hfi_vnic interface to
>> the bottom driver a generic interface. This will include moving some of the
>> netstack interfacing to the bottom hfi1 driver.
>
>Great, do you have rough estimation when will it be posted on the ML?
>
>Thanks
>
Hi Leon,
I am currently doing some prototype on this. I will respond with the interface
definition first once I have it solidified. RFC v3 with implemetion will be
later.
Niranjana
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256
From: Daniel Borkmann @ 2017-01-11 9:09 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andy Lutomirski, Netdev, LKML, Linux Crypto Mailing List,
Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Alexei Starovoitov
In-Reply-To: <CALCETrUHenMS1iomFr7+YEy_M3zaotrWbfMe93=BmzCbzJ0fLw@mail.gmail.com>
Hi Andy,
On 01/11/2017 04:11 AM, Andy Lutomirski wrote:
> On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 01/11/2017 12:24 AM, Andy Lutomirski wrote:
>>>
>>> This makes it easier to add another digest algorithm down the road if
>>> needed. It also serves to force any programs that might have been
>>> written against a kernel that had the old field name to notice the
>>> change and make any necessary changes.
>>>
>>> This shouldn't violate any stable API policies, as no released kernel
>>> has ever had TCA*BPF_DIGEST.
>>
>> Imho, this and patch 6/8 is not really needed. Should there ever
>> another digest alg be used (doubt it), then you'd need a new nl
>> attribute and fdinfo line anyway to keep existing stuff intact.
>> Nobody made the claim that you can just change this underneath
>> and not respecting abi for existing applications when I read from
>> above that such apps now will get "forced" to notice a change.
>
> Fair enough. I was more concerned about prerelease iproute2 versions,
> but maybe that's a nonissue. I'll drop these two patches.
Ok. Sleeping over this a bit, how about a general rename into
"prog_tag" for fdinfo and TCA_BPF_TAG resp. TCA_ACT_BPF_TAG for
the netlink attributes, fwiw, it might reduce any assumptions on
this being made? If this would be preferable, I could cook that
patch against -net for renaming it?
Thanks,
Daniel
^ permalink raw reply
* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Leon Romanovsky @ 2017-01-11 9:16 UTC (permalink / raw)
To: Vishwanathapura, Niranjana
Cc: Doug Ledford, ira.weiny, Jeff Kirsher, David S. Miller,
linux-rdma, netdev, dennis.dalessandro
In-Reply-To: <20170111090539.GA78804@knc-06.sc.intel.com>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Wed, Jan 11, 2017 at 01:05:39AM -0800, Vishwanathapura, Niranjana wrote:
> On Tue, Jan 10, 2017 at 10:14:02AM +0200, Leon Romanovsky wrote:
> > On Mon, Jan 09, 2017 at 07:39:54PM -0800, Vishwanathapura, Niranjana wrote:
> > > We are also looking into Jason’s suggestion to make hfi_vnic interface to
> > > the bottom driver a generic interface. This will include moving some of the
> > > netstack interfacing to the bottom hfi1 driver.
> >
> > Great, do you have rough estimation when will it be posted on the ML?
> >
> > Thanks
> >
>
> Hi Leon,
>
> I am currently doing some prototype on this. I will respond with the
> interface definition first once I have it solidified. RFC v3 with
> implemetion will be later.
It makes sense.
Thanks
>
> Niranjana
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net-next] net: thunderx: Make hfunc variable const type in nicvf_set_rxfh()
From: Robert Richter @ 2017-01-11 9:17 UTC (permalink / raw)
To: David Miller; +Cc: Sunil Goutham, Robert Richter, netdev, Robert Richter
>From struct ethtool_ops:
int (*set_rxfh)(struct net_device *, const u32 *indir,
const u8 *key, const u8 hfunc);
Change function arg of hfunc to const type.
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
index 2e74bbaa38e1..3a4761aa8efd 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
@@ -635,7 +635,7 @@ static int nicvf_get_rxfh(struct net_device *dev, u32 *indir, u8 *hkey,
}
static int nicvf_set_rxfh(struct net_device *dev, const u32 *indir,
- const u8 *hkey, u8 hfunc)
+ const u8 *hkey, const u8 hfunc)
{
struct nicvf *nic = netdev_priv(dev);
struct nicvf_rss_info *rss = &nic->rss_info;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next] bridge: multicast to unicast
From: Johannes Berg @ 2017-01-11 9:17 UTC (permalink / raw)
To: Linus Lüssing
Cc: netdev, bridge, linux-wireless, linux-kernel, Michael Braun,
David S . Miller, Felix Fietkau
In-Reply-To: <20170109231203.GC5513@otheros>
> > Exactly. My point is that this is breaking the expectation that
> > hosts are actually able to drop such packets.
>
> [readding CCs I removed earlier]
>
> Ah! Thanks. I was worried about creating packetloss :D.
Ah, well, no - at least not in this case.
> Hm, for this other other way round, I think it does not apply for
> the bridge multicast-to-unicast patch if I'm not misreading the
> bridge code:
>
> For a packet with a link-layer multicast address but a unicast IP
> destination, the bridge MDB lookup will fail.
> (http://lxr.free-electrons.com/source/net/bridge/br_multicast.c?v=4.8
> #L178
> returns NULL)
>
> Case A): No multicast router on port:
> -> bridge, br_multicast_flood(), will drop the packet already
> (no matter if multicast-to-unicast is enabled or not)
>
> Case B): Multicast router present on port:
> -> The new patch does not apply multicast-to-unicast but just floods
> packet unaltered
> ("else { port = rport; addr = NULL; }" branch)
Ah, interesting. This is different then - the mac80211 code is not L3
aware at all.
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] stmmac: rename it to synopsys
From: kbuild test robot @ 2017-01-11 10:00 UTC (permalink / raw)
To: Joao Pinto
Cc: kbuild-all, davem, lars.persson, niklass, peppe.cavallaro,
alexandre.torgue, netdev, Joao Pinto
In-Reply-To: <c74e6665ca14a4ca03b38cd3442ef0644d9e250d.1484059674.git.jpinto@synopsys.com>
[-- Attachment #1: Type: text/plain, Size: 22628 bytes --]
Hi Joao,
[auto build test WARNING on net-next/master]
[also build test WARNING on next-20170111]
[cannot apply to v4.10-rc3]
[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/Joao-Pinto/remove-dwc_eth_qos-and-rename-stmicro-stmmac/20170111-003912
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/asm-generic/bug.h:13,
from arch/m32r/include/asm/bug.h:3,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from drivers/net/ethernet/synopsys/dwmac1000_core.c:30:
drivers/net/ethernet/synopsys/dwmac1000_core.c: In function 'dwmac1000_dump_regs':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
>> drivers/net/ethernet/synopsys/dwmac1000_core.c:107:3: note: in expansion of macro 'pr_info'
pr_info("\tReg No. %d (offset 0x%x): 0x%08x\n", i,
^~~~~~~
--
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/synopsys/dwmac1000.h:25,
from drivers/net/ethernet/synopsys/dwmac1000_dma.c:30:
drivers/net/ethernet/synopsys/dwmac1000_dma.c: In function 'dwmac1000_dump_dma_regs':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~~~~~
include/linux/printk.h:292:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~
>> drivers/net/ethernet/synopsys/dwmac1000_dma.c:215:4: note: in expansion of macro 'pr_err'
pr_err("\t Reg No. %d (offset 0x%x): 0x%08x\n", i,
^~~~~~
--
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/synopsys/dwmac100.h:28,
from drivers/net/ethernet/synopsys/dwmac100_core.c:33:
drivers/net/ethernet/synopsys/dwmac100_core.c: In function 'dwmac100_dump_mac_regs':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
>> drivers/net/ethernet/synopsys/dwmac100_core.c:53:2: note: in expansion of macro 'pr_info'
pr_info("\tcontrol reg (offset 0x%x): 0x%08x\n", MAC_CONTROL,
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_core.c:55:2: note: in expansion of macro 'pr_info'
pr_info("\taddr HI (offset 0x%x): 0x%08x\n ", MAC_ADDR_HIGH,
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_core.c:57:2: note: in expansion of macro 'pr_info'
pr_info("\taddr LO (offset 0x%x): 0x%08x\n", MAC_ADDR_LOW,
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_core.c:59:2: note: in expansion of macro 'pr_info'
pr_info("\tmulticast hash HI (offset 0x%x): 0x%08x\n",
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_core.c:61:2: note: in expansion of macro 'pr_info'
pr_info("\tmulticast hash LO (offset 0x%x): 0x%08x\n",
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_core.c:63:2: note: in expansion of macro 'pr_info'
pr_info("\tflow control (offset 0x%x): 0x%08x\n",
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_core.c:65:2: note: in expansion of macro 'pr_info'
pr_info("\tVLAN1 tag (offset 0x%x): 0x%08x\n", MAC_VLAN1,
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_core.c:67:2: note: in expansion of macro 'pr_info'
pr_info("\tVLAN2 tag (offset 0x%x): 0x%08x\n", MAC_VLAN2,
^~~~~~~
--
In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/synopsys/dwmac100.h:28,
from drivers/net/ethernet/synopsys/dwmac100_dma.c:32:
drivers/net/ethernet/synopsys/dwmac100_dma.c: In function 'dwmac100_dump_dma_regs':
>> drivers/net/ethernet/synopsys/dwmac100_dma.c:79:12: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=]
pr_debug("\t CSR%d (offset 0x%x): 0x%08x\n", i,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
>> drivers/net/ethernet/synopsys/dwmac100_dma.c:79:3: note: in expansion of macro 'pr_debug'
pr_debug("\t CSR%d (offset 0x%x): 0x%08x\n", i,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_dma.c:83:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tCSR20 (0x%x): 0x%08x, CSR21 (0x%x): 0x%08x\n",
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_dma.c:83:2: note: in expansion of macro 'pr_debug'
pr_debug("\tCSR20 (0x%x): 0x%08x, CSR21 (0x%x): 0x%08x\n",
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_dma.c:83:11: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'long unsigned int' [-Wformat=]
pr_debug("\tCSR20 (0x%x): 0x%08x, CSR21 (0x%x): 0x%08x\n",
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac100_dma.c:83:2: note: in expansion of macro 'pr_debug'
pr_debug("\tCSR20 (0x%x): 0x%08x, CSR21 (0x%x): 0x%08x\n",
^~~~~~~~
--
In file included from include/linux/kernel.h:13:0,
from include/asm-generic/bug.h:13,
from arch/m32r/include/asm/bug.h:3,
from include/linux/bug.h:4,
from include/linux/io.h:23,
from drivers/net/ethernet/synopsys/dwmac4_dma.c:16:
drivers/net/ethernet/synopsys/dwmac4_dma.c: In function '_dwmac4_dump_dma_regs':
>> drivers/net/ethernet/synopsys/dwmac4_dma.c:133:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_CONTROL, offset: 0x%x, val: 0x%x\n", 0,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
>> drivers/net/ethernet/synopsys/dwmac4_dma.c:133:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_CONTROL, offset: 0x%x, val: 0x%x\n", 0,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:135:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_TX_CONTROL, offset: 0x%x, val: 0x%x\n", 0x4,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:135:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_TX_CONTROL, offset: 0x%x, val: 0x%x\n", 0x4,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:137:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_RX_CONTROL, offset: 0x%x, val: 0x%x\n", 0x8,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:137:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_RX_CONTROL, offset: 0x%x, val: 0x%x\n", 0x8,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:139:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_TX_BASE_ADDR, offset: 0x%x, val: 0x%x\n", 0x14,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:139:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_TX_BASE_ADDR, offset: 0x%x, val: 0x%x\n", 0x14,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:141:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_RX_BASE_ADDR, offset: 0x%x, val: 0x%x\n", 0x1c,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:141:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_RX_BASE_ADDR, offset: 0x%x, val: 0x%x\n", 0x1c,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:143:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_TX_END_ADDR, offset: 0x%x, val: 0x%x\n", 0x20,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:143:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_TX_END_ADDR, offset: 0x%x, val: 0x%x\n", 0x20,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:145:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_RX_END_ADDR, offset: 0x%x, val: 0x%x\n", 0x28,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:145:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_RX_END_ADDR, offset: 0x%x, val: 0x%x\n", 0x28,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:147:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_TX_RING_LEN, offset: 0x%x, val: 0x%x\n", 0x2c,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:147:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_TX_RING_LEN, offset: 0x%x, val: 0x%x\n", 0x2c,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:149:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_RX_RING_LEN, offset: 0x%x, val: 0x%x\n", 0x30,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:149:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_RX_RING_LEN, offset: 0x%x, val: 0x%x\n", 0x30,
^~~~~~~~
drivers/net/ethernet/synopsys/dwmac4_dma.c:151:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_INTR_ENA, offset: 0x%x, val: 0x%x\n", 0x34,
..
vim +/pr_info +107 drivers/net/ethernet/synopsys/dwmac1000_core.c
d2afb5bd drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2014-09-01 91
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 92 writel(value, ioaddr + GMAC_CONTROL);
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 93
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 94 value = readl(ioaddr + GMAC_CONTROL);
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 95
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 96 return !!(value & GMAC_CONTROL_IPC);
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 97 }
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 98
7ed24bbe drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Vince Bridgers 2014-07-31 99 static void dwmac1000_dump_regs(struct mac_device_info *hw)
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 100 {
7ed24bbe drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Vince Bridgers 2014-07-31 101 void __iomem *ioaddr = hw->pcsr;
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 102 int i;
1f0f6388 drivers/net/stmmac/dwmac1000_core.c David S. Miller 2010-08-30 103 pr_info("\tDWMAC1000 regs (base addr = 0x%p)\n", ioaddr);
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 104
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 105 for (i = 0; i < 55; i++) {
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 106 int offset = i * 4;
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 @107 pr_info("\tReg No. %d (offset 0x%x): 0x%08x\n", i,
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 108 offset, readl(ioaddr + offset));
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 109 }
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 110 }
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 111
7ed24bbe drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Vince Bridgers 2014-07-31 112 static void dwmac1000_set_umac_addr(struct mac_device_info *hw,
7ed24bbe drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Vince Bridgers 2014-07-31 113 unsigned char *addr,
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 114 unsigned int reg_n)
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 115 {
:::::: The code at line 107 was first introduced by commit
:::::: 21d437cc66dcfd0119a4905214fbbe19f3e276dc stmmac: rename the gmac as dwmac1000 and split core and dma parts
:::::: TO: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
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: 40621 bytes --]
^ permalink raw reply
* [PATCH/RFC net-next 0/2] net/sched: cls_flower: Support matching ARP
From: Simon Horman @ 2017-01-11 10:02 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Dinan Gunawardena, netdev, oss-drivers, Simon Horman
Add support for support matching on ARP operation, and hardware and
protocol addresses for Ethernet hardware and IPv4 protocol addresses.
Simon Horman (2):
flow disector: ARP support
net/sched: cls_flower: Support matching on ARP
include/net/flow_dissector.h | 19 +++++++++++++++
include/uapi/linux/pkt_cls.h | 11 +++++++++
net/core/flow_dissector.c | 57 ++++++++++++++++++++++++++++++++++++++++++++
net/sched/cls_flower.c | 51 +++++++++++++++++++++++++++++++++++++++
4 files changed, 138 insertions(+)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH/RFC net-next 1/2] flow disector: ARP support
From: Simon Horman @ 2017-01-11 10:02 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Dinan Gunawardena, netdev, oss-drivers, Simon Horman
In-Reply-To: <1484128942-11745-1-git-send-email-simon.horman@netronome.com>
Allow dissection of (R)ARP operation hardware and protocol addresses
for Ethernet hardware and IPv4 protocol addresses.
There are currently no users of FLOW_DISSECTOR_KEY_ARP.
A follow-up patch will allow FLOW_DISSECTOR_KEY_ARP to be used by the
flower classifier.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/net/flow_dissector.h | 19 +++++++++++++++
net/core/flow_dissector.c | 57 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+)
diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index d896a33e00d4..ac9703018a3a 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -89,6 +89,24 @@ struct flow_dissector_key_addrs {
};
/**
+ * flow_dissector_key_arp:
+ * @ports: Operation, source and target addresses for an ARP header
+ * for Ethernet hardware addresses and IPv4 protocol addresses
+ * sip: Sender IP address
+ * tip: Target IP address
+ * op: Operation
+ * sha: Sender hardware address
+ * tpa: Target hardware address
+ */
+struct flow_dissector_key_arp {
+ __u32 sip;
+ __u32 tip;
+ __u8 op;
+ unsigned char sha[ETH_ALEN];
+ unsigned char tha[ETH_ALEN];
+};
+
+/**
* flow_dissector_key_tp_ports:
* @ports: port numbers of Transport header
* src: source port number
@@ -141,6 +159,7 @@ enum flow_dissector_key_id {
FLOW_DISSECTOR_KEY_ICMP, /* struct flow_dissector_key_icmp */
FLOW_DISSECTOR_KEY_ETH_ADDRS, /* struct flow_dissector_key_eth_addrs */
FLOW_DISSECTOR_KEY_TIPC_ADDRS, /* struct flow_dissector_key_tipc_addrs */
+ FLOW_DISSECTOR_KEY_ARP, /* struct flow_dissector_key_arp */
FLOW_DISSECTOR_KEY_VLAN, /* struct flow_dissector_key_flow_vlan */
FLOW_DISSECTOR_KEY_FLOW_LABEL, /* struct flow_dissector_key_flow_tags */
FLOW_DISSECTOR_KEY_GRE_KEYID, /* struct flow_dissector_key_keyid */
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index fe4e1531976c..5b3800fe20f3 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -138,6 +138,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
struct flow_dissector_key_control *key_control;
struct flow_dissector_key_basic *key_basic;
struct flow_dissector_key_addrs *key_addrs;
+ struct flow_dissector_key_arp *key_arp;
struct flow_dissector_key_ports *key_ports;
struct flow_dissector_key_icmp *key_icmp;
struct flow_dissector_key_tags *key_tags;
@@ -379,6 +380,62 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
nhoff += FCOE_HEADER_LEN;
goto out_good;
+
+ case htons(ETH_P_ARP):
+ case htons(ETH_P_RARP): {
+ struct {
+ unsigned char ar_sha[ETH_ALEN];
+ unsigned char ar_sip[4];
+ unsigned char ar_tha[ETH_ALEN];
+ unsigned char ar_tip[4];
+ } *arp_eth, _arp_eth;
+ const struct arphdr *arp;
+ struct arphdr *_arp;
+
+ arp = __skb_header_pointer(skb, nhoff, sizeof(_arp), data,
+ hlen, &_arp);
+ if (!arp)
+ goto out_bad;
+
+ if (arp->ar_hrd != htons(ARPHRD_ETHER) ||
+ arp->ar_pro != htons(ETH_P_IP) ||
+ arp->ar_hln != ETH_ALEN ||
+ arp->ar_pln != 4 ||
+ (arp->ar_op != htons(ARPOP_REPLY) &&
+ arp->ar_op != htons(ARPOP_REQUEST)))
+ goto out_bad;
+
+ arp_eth = __skb_header_pointer(skb, nhoff + sizeof(_arp),
+ sizeof(_arp_eth), data,
+ hlen - sizeof(_arp),
+ &_arp_eth);
+ if (!arp)
+ goto out_bad;
+
+ if (dissector_uses_key(flow_dissector,
+ FLOW_DISSECTOR_KEY_ARP)) {
+
+ key_arp = skb_flow_dissector_target(flow_dissector,
+ FLOW_DISSECTOR_KEY_ARP,
+ target_container);
+
+ memcpy(&key_arp->sip, arp_eth->ar_sip,
+ sizeof(key_arp->sip));
+ memcpy(&key_arp->tip, arp_eth->ar_tip,
+ sizeof(key_arp->tip));
+
+ /* Only store the lower byte of the opcode;
+ * this covers ARPOP_REPLY and ARPOP_REQUEST.
+ */
+ key_arp->op = ntohs(arp->ar_op) & 0xff;
+
+ ether_addr_copy(key_arp->sha, arp_eth->ar_sha);
+ ether_addr_copy(key_arp->tha, arp_eth->ar_tha);
+ }
+
+ goto out_good;
+ }
+
default:
goto out_bad;
}
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH/RFC net-next 2/2] net/sched: cls_flower: Support matching on ARP
From: Simon Horman @ 2017-01-11 10:02 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Dinan Gunawardena, netdev, oss-drivers, Simon Horman
In-Reply-To: <1484128942-11745-1-git-send-email-simon.horman@netronome.com>
Support matching on ARP operation, and hardware and protocol addresses
for Ethernet hardware and IPv4 protocol addresses.
Example usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol arp parent ffff: flower indev eth0 \
arp_op request arp_sip 10.0.0.1 action drop
tc filter add dev eth0 protocol rarp parent ffff: flower indev eth0 \
arp_op reply arp_tha 52:54:3f:00:00:00/24 action drop
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/uapi/linux/pkt_cls.h | 11 ++++++++++
net/sched/cls_flower.c | 51 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index a081efbd61a2..1e5e1ddfdaca 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -416,6 +416,17 @@ enum {
TCA_FLOWER_KEY_ICMPV6_TYPE, /* u8 */
TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,/* u8 */
+ TCA_FLOWER_KEY_ARP_SIP, /* be32 */
+ TCA_FLOWER_KEY_ARP_SIP_MASK, /* be32 */
+ TCA_FLOWER_KEY_ARP_TIP, /* be32 */
+ TCA_FLOWER_KEY_ARP_TIP_MASK, /* be32 */
+ TCA_FLOWER_KEY_ARP_OP, /* u8 */
+ TCA_FLOWER_KEY_ARP_OP_MASK, /* u8 */
+ TCA_FLOWER_KEY_ARP_SHA, /* ETH_ALEN */
+ TCA_FLOWER_KEY_ARP_SHA_MASK, /* ETH_ALEN */
+ TCA_FLOWER_KEY_ARP_THA, /* ETH_ALEN */
+ TCA_FLOWER_KEY_ARP_THA_MASK, /* ETH_ALEN */
+
__TCA_FLOWER_MAX,
};
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 970db7a41684..a3bfda3091a4 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -40,6 +40,7 @@ struct fl_flow_key {
};
struct flow_dissector_key_ports tp;
struct flow_dissector_key_icmp icmp;
+ struct flow_dissector_key_arp arp;
struct flow_dissector_key_keyid enc_key_id;
union {
struct flow_dissector_key_ipv4_addrs enc_ipv4;
@@ -401,6 +402,16 @@ static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
[TCA_FLOWER_KEY_ICMPV6_TYPE_MASK] = { .type = NLA_U8 },
[TCA_FLOWER_KEY_ICMPV6_CODE] = { .type = NLA_U8 },
[TCA_FLOWER_KEY_ICMPV6_CODE_MASK] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ARP_SIP] = { .type = NLA_U32 },
+ [TCA_FLOWER_KEY_ARP_SIP_MASK] = { .type = NLA_U32 },
+ [TCA_FLOWER_KEY_ARP_TIP] = { .type = NLA_U32 },
+ [TCA_FLOWER_KEY_ARP_TIP_MASK] = { .type = NLA_U32 },
+ [TCA_FLOWER_KEY_ARP_OP] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ARP_OP_MASK] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ARP_SHA] = { .len = ETH_ALEN },
+ [TCA_FLOWER_KEY_ARP_SHA_MASK] = { .len = ETH_ALEN },
+ [TCA_FLOWER_KEY_ARP_THA] = { .len = ETH_ALEN },
+ [TCA_FLOWER_KEY_ARP_THA_MASK] = { .len = ETH_ALEN },
};
static void fl_set_key_val(struct nlattr **tb,
@@ -572,6 +583,23 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
&mask->icmp.code,
TCA_FLOWER_KEY_ICMPV4_CODE_MASK,
sizeof(key->icmp.code));
+ } else if (key->basic.n_proto == htons(ETH_P_ARP) ||
+ key->basic.n_proto == htons(ETH_P_RARP)) {
+ fl_set_key_val(tb, &key->arp.sip, TCA_FLOWER_KEY_ARP_SIP,
+ &mask->arp.sip, TCA_FLOWER_KEY_ARP_SIP_MASK,
+ sizeof(key->arp.sip));
+ fl_set_key_val(tb, &key->arp.tip, TCA_FLOWER_KEY_ARP_TIP,
+ &mask->arp.tip, TCA_FLOWER_KEY_ARP_TIP_MASK,
+ sizeof(key->arp.tip));
+ fl_set_key_val(tb, &key->arp.op, TCA_FLOWER_KEY_ARP_OP,
+ &mask->arp.op, TCA_FLOWER_KEY_ARP_OP_MASK,
+ sizeof(key->arp.op));
+ fl_set_key_val(tb, key->arp.sha, TCA_FLOWER_KEY_ARP_SHA,
+ mask->arp.sha, TCA_FLOWER_KEY_ARP_SHA_MASK,
+ sizeof(key->arp.sha));
+ fl_set_key_val(tb, key->arp.tha, TCA_FLOWER_KEY_ARP_THA,
+ mask->arp.tha, TCA_FLOWER_KEY_ARP_THA_MASK,
+ sizeof(key->arp.tha));
}
if (tb[TCA_FLOWER_KEY_ENC_IPV4_SRC] ||
@@ -689,6 +717,8 @@ static void fl_init_dissector(struct cls_fl_head *head,
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_ICMP, icmp);
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
+ FLOW_DISSECTOR_KEY_ARP, arp);
+ FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_VLAN, vlan);
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_ENC_KEYID, enc_key_id);
@@ -1112,6 +1142,27 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
TCA_FLOWER_KEY_ICMPV6_CODE_MASK,
sizeof(key->icmp.code))))
goto nla_put_failure;
+ else if ((key->basic.n_proto == htons(ETH_P_ARP) ||
+ key->basic.n_proto == htons(ETH_P_RARP)) &&
+ (fl_dump_key_val(skb, &key->arp.sip,
+ TCA_FLOWER_KEY_ARP_SIP, &mask->arp.sip,
+ TCA_FLOWER_KEY_ARP_SIP_MASK,
+ sizeof(key->arp.sip)) ||
+ fl_dump_key_val(skb, &key->arp.tip,
+ TCA_FLOWER_KEY_ARP_TIP, &mask->arp.tip,
+ TCA_FLOWER_KEY_ARP_TIP_MASK,
+ sizeof(key->arp.tip)) ||
+ fl_dump_key_val(skb, &key->arp.op,
+ TCA_FLOWER_KEY_ARP_OP, &mask->arp.op,
+ TCA_FLOWER_KEY_ARP_OP_MASK,
+ sizeof(key->arp.op)) ||
+ fl_dump_key_val(skb, key->arp.sha, TCA_FLOWER_KEY_ARP_SHA,
+ mask->arp.sha, TCA_FLOWER_KEY_ARP_SHA_MASK,
+ sizeof(key->arp.sha)) ||
+ fl_dump_key_val(skb, key->arp.tha, TCA_FLOWER_KEY_ARP_THA,
+ mask->arp.tha, TCA_FLOWER_KEY_ARP_THA_MASK,
+ sizeof(key->arp.tha))))
+ goto nla_put_failure;
if (key->enc_control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS &&
(fl_dump_key_val(skb, &key->enc_ipv4.src,
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH/RFC iproute2/net-next 0/2] net/sched: cls_flower: Support matching ARP
From: Simon Horman @ 2017-01-11 10:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Dinan Gunawardena, netdev, Simon Horman
Add support for support matching on ARP operation, and hardware and
protocol addresses for Ethernet hardware and IPv4 protocol addresses.
Simon Horman (2):
tc: flower: update headers for TCA_FLOWER_KEY_ARP*
tc: flower: Support matching ARP
include/linux/pkt_cls.h | 11 +++
man/man8/tc-flower.8 | 41 +++++++++-
tc/f_flower.c | 208 ++++++++++++++++++++++++++++++++++++++++++++----
3 files changed, 243 insertions(+), 17 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* [PATCH/RFC iproute2/net-next 1/2] tc: flower: update headers for TCA_FLOWER_KEY_ARP*
From: Simon Horman @ 2017-01-11 10:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Dinan Gunawardena, netdev, Simon Horman
In-Reply-To: <1484128984-11891-1-git-send-email-simon.horman@netronome.com>
These are proposed changes for net-next.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/linux/pkt_cls.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index a081efbd61a2..1e5e1ddfdaca 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -416,6 +416,17 @@ enum {
TCA_FLOWER_KEY_ICMPV6_TYPE, /* u8 */
TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,/* u8 */
+ TCA_FLOWER_KEY_ARP_SIP, /* be32 */
+ TCA_FLOWER_KEY_ARP_SIP_MASK, /* be32 */
+ TCA_FLOWER_KEY_ARP_TIP, /* be32 */
+ TCA_FLOWER_KEY_ARP_TIP_MASK, /* be32 */
+ TCA_FLOWER_KEY_ARP_OP, /* u8 */
+ TCA_FLOWER_KEY_ARP_OP_MASK, /* u8 */
+ TCA_FLOWER_KEY_ARP_SHA, /* ETH_ALEN */
+ TCA_FLOWER_KEY_ARP_SHA_MASK, /* ETH_ALEN */
+ TCA_FLOWER_KEY_ARP_THA, /* ETH_ALEN */
+ TCA_FLOWER_KEY_ARP_THA_MASK, /* ETH_ALEN */
+
__TCA_FLOWER_MAX,
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH/RFC iproute2/net-next 2/2] tc: flower: Support matching ARP
From: Simon Horman @ 2017-01-11 10:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Dinan Gunawardena, netdev, Simon Horman
In-Reply-To: <1484128984-11891-1-git-send-email-simon.horman@netronome.com>
Support matching on ARP operation, and hardware and protocol addresses
for Ethernet hardware and IPv4 protocol addresses.
Example usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol arp parent ffff: flower indev eth0 \ arp_op request arp_sip 10.0.0.1 action drop
tc filter add dev eth0 protocol rarp parent ffff: flower indev eth0 \ arp_op reply arp_tha 52:54:3f:00:00:00/24 action drop
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
man/man8/tc-flower.8 | 41 +++++++++-
tc/f_flower.c | 208 +++++++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 232 insertions(+), 17 deletions(-)
diff --git a/man/man8/tc-flower.8 b/man/man8/tc-flower.8
index 5904a9ecafdf..2dd2c5e6e4a5 100644
--- a/man/man8/tc-flower.8
+++ b/man/man8/tc-flower.8
@@ -34,7 +34,13 @@ flower \- flow based traffic control filter
.BR dst_ip " | " src_ip " } "
.IR PREFIX " | { "
.BR dst_port " | " src_port " } "
-.IR port_number " } | "
+.IR port_number " } | { "
+.BR arp_tip " | " arp_sip " } "
+.IR PREFIX " | "
+.BR arp_op " { " request " | " reply " | "
+.IR OP " } | { "
+.BR arp_tha " | " arp_sha " } "
+.IR MASKED_LLADDR " | "
.B enc_key_id
.IR KEY-ID " | {"
.BR enc_dst_ip " | " enc_src_ip " } { "
@@ -131,6 +137,36 @@ Match on ICMP type or code. Only available for
.BR ip_proto " values " icmp " and " icmpv6
which have to be specified in beforehand.
.TP
+.BI arp_tip " PREFIX"
+.TQ
+.BI arp_sip " PREFIX"
+Match on ARP or RARP sender or target IP address.
+.I PREFIX
+must be a valid IPv4 address optionally followed by a slash and the prefix
+length. If the prefix is missing, \fBtc\fR assumes a full-length host
+match.
+.TP
+.BI arp_op " ARP_OP"
+Match on ARP or RARP operation.
+.I ARP_OP
+may be
+.BR request ", " reply
+or an integer value 0, 1 or 2. A mask may be optionally provided to limit
+the bits of the operation which are matched. A mask is provided by
+following the address with a slash and then the mask. It may be provided as
+an unsigned 8 bit value representing a bitwise mask. If the mask is missing
+then a match on all bits is assumed.
+.TP
+.BI arp_sha " MASKED_LLADDR"
+.TQ
+.BI arp_tha " MASKED_LLADDR"
+Match on ARP or RARP sender or target MAC address. A mask may be optionally
+provided to limit the bits of the address which are matched. A mask is
+provided by following the address with a slash and then the mask. It may be
+provided in LLADDR format, in which case it is a bitwise mask, or as a
+number of high bits to match. If the mask is missing then a match on all
+bits is assumed.
+.TP
.BI enc_key_id " NUMBER"
.TQ
.BI enc_dst_ip " PREFIX"
@@ -152,7 +188,8 @@ As stated above where applicable, matches of a certain layer implicitly depend
on the matches of the next lower layer. Precisely, layer one and two matches
(\fBindev\fR, \fBdst_mac\fR and \fBsrc_mac\fR)
have no dependency, layer three matches
-(\fBip_proto\fR, \fBdst_ip\fR and \fBsrc_ip\fR)
+(\fBip_proto\fR, \fBdst_ip\fR, \fBsrc_ip\fR, \fBarp_tip\fR, \fBarp_sip\fR,
+\fBarp_op\fR, \fBarp_tha\fR and \fBarp_sha\fR)
depend on the
.B protocol
option of tc filter, layer four port matches
diff --git a/tc/f_flower.c b/tc/f_flower.c
index 99f5f8163ee0..d301db36a549 100644
--- a/tc/f_flower.c
+++ b/tc/f_flower.c
@@ -15,6 +15,7 @@
#include <syslog.h>
#include <string.h>
#include <net/if.h>
+#include <linux/if_arp.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tc_act/tc_vlan.h>
@@ -54,6 +55,11 @@ static void explain(void)
" src_port PORT-NUMBER |\n"
" type ICMP-TYPE |\n"
" code ICMP-CODE |\n"
+ " arp_tip PREFIX |\n"
+ " arp_sip PREFIX |\n"
+ " arp_op [ request | reply | OP ] |\n"
+ " arp_tha MASKED-LLADDR |\n"
+ " arp_sha MASKED-LLADDR |\n"
" enc_dst_ip [ IPV4-ADDR | IPV6-ADDR ] |\n"
" enc_src_ip [ IPV4-ADDR | IPV6-ADDR ] |\n"
" enc_key_id [ KEY-ID ] |\n"
@@ -192,27 +198,16 @@ err:
return -1;
}
-static int flower_parse_ip_addr(char *str, __be16 eth_type,
- int addr4_type, int mask4_type,
- int addr6_type, int mask6_type,
- struct nlmsghdr *n)
+static int __flower_parse_ip_addr(char *str, int family,
+ int addr4_type, int mask4_type,
+ int addr6_type, int mask6_type,
+ struct nlmsghdr *n)
{
int ret;
inet_prefix addr;
- int family;
int bits;
int i;
- if (eth_type == htons(ETH_P_IP)) {
- family = AF_INET;
- } else if (eth_type == htons(ETH_P_IPV6)) {
- family = AF_INET6;
- } else if (!eth_type) {
- family = AF_UNSPEC;
- } else {
- return -1;
- }
-
ret = get_prefix(&addr, str, family);
if (ret)
return -1;
@@ -245,6 +240,89 @@ static int flower_parse_ip_addr(char *str, __be16 eth_type,
return 0;
}
+static int flower_parse_ip_addr(char *str, __be16 eth_type,
+ int addr4_type, int mask4_type,
+ int addr6_type, int mask6_type,
+ struct nlmsghdr *n)
+{
+ int family;
+
+ if (eth_type == htons(ETH_P_IP)) {
+ family = AF_INET;
+ } else if (eth_type == htons(ETH_P_IPV6)) {
+ family = AF_INET6;
+ } else if (!eth_type) {
+ family = AF_UNSPEC;
+ } else {
+ return -1;
+ }
+
+ return __flower_parse_ip_addr(str, family, addr4_type, addr6_type,
+ mask4_type, mask6_type, n);
+}
+
+static bool flower_eth_type_arp(__be16 eth_type)
+{
+ return eth_type == htons(ETH_P_ARP) || eth_type == htons(ETH_P_RARP);
+}
+
+static int flower_parse_arp_ip_addr(char *str, __be16 eth_type,
+ int addr_type, int mask_type,
+ struct nlmsghdr *n)
+{
+ if (!flower_eth_type_arp(eth_type))
+ return -1;
+
+ return __flower_parse_ip_addr(str, AF_INET, addr_type, mask_type,
+ TCA_FLOWER_UNSPEC, TCA_FLOWER_UNSPEC, n);
+}
+
+static int flower_parse_arp_op(char *str, __be16 eth_type,
+ int op_type, int mask_type,
+ struct nlmsghdr *n)
+{
+ char *slash;
+ int ret, err = -1;
+ uint8_t value, mask;
+
+ slash = strchr(str, '/');
+ if (slash)
+ *slash = '\0';
+
+ if (!flower_eth_type_arp(eth_type))
+ goto err;
+
+ if (!strcmp(str, "request")) {
+ value = ARPOP_REQUEST;
+ } else if (!strcmp(str, "reply")) {
+ value = ARPOP_REPLY;
+ } else {
+ ret = get_u8(&value, str, 10);
+ if (ret)
+ goto err;
+ if (value && value != ARPOP_REQUEST && value != ARPOP_REPLY)
+ goto err;
+ }
+
+ if (slash) {
+ ret = get_u8(&mask, slash + 1, 10);
+ if (ret)
+ goto err;
+ }
+ else {
+ mask = UINT8_MAX;
+ }
+
+ addattr8(n, MAX_MSG, op_type, value);
+ addattr8(n, MAX_MSG, mask_type, mask);
+
+ err = 0;
+err:
+ if (slash)
+ *slash = '/';
+ return err;
+}
+
static int flower_icmp_attr_type(__be16 eth_type, __u8 ip_proto,
enum flower_icmp_field field)
{
@@ -530,6 +608,59 @@ static int flower_parse_opt(struct filter_util *qu, char *handle,
fprintf(stderr, "Illegal \"icmp code\"\n");
return -1;
}
+ } else if (matches(*argv, "arp_tip") == 0) {
+ NEXT_ARG();
+ ret = flower_parse_arp_ip_addr(*argv, vlan_ethtype ?
+ vlan_ethtype : eth_type,
+ TCA_FLOWER_KEY_ARP_TIP,
+ TCA_FLOWER_KEY_ARP_TIP_MASK,
+ n);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"arp_tip\"\n");
+ return -1;
+ }
+ } else if (matches(*argv, "arp_sip") == 0) {
+ NEXT_ARG();
+ ret = flower_parse_arp_ip_addr(*argv, vlan_ethtype ?
+ vlan_ethtype : eth_type,
+ TCA_FLOWER_KEY_ARP_SIP,
+ TCA_FLOWER_KEY_ARP_SIP_MASK,
+ n);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"arp_sip\"\n");
+ return -1;
+ }
+ } else if (matches(*argv, "arp_op") == 0) {
+ NEXT_ARG();
+ ret = flower_parse_arp_op(*argv, vlan_ethtype ?
+ vlan_ethtype : eth_type,
+ TCA_FLOWER_KEY_ARP_OP,
+ TCA_FLOWER_KEY_ARP_OP_MASK,
+ n);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"arp_op\"\n");
+ return -1;
+ }
+ } else if (matches(*argv, "arp_tha") == 0) {
+ NEXT_ARG();
+ ret = flower_parse_eth_addr(*argv,
+ TCA_FLOWER_KEY_ARP_THA,
+ TCA_FLOWER_KEY_ARP_THA_MASK,
+ n);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"arp_tha\"\n");
+ return -1;
+ }
+ } else if (matches(*argv, "arp_sha") == 0) {
+ NEXT_ARG();
+ ret = flower_parse_eth_addr(*argv,
+ TCA_FLOWER_KEY_ARP_SHA,
+ TCA_FLOWER_KEY_ARP_SHA_MASK,
+ n);
+ if (ret < 0) {
+ fprintf(stderr, "Illegal \"arp_sha\"\n");
+ return -1;
+ }
} else if (matches(*argv, "enc_dst_ip") == 0) {
NEXT_ARG();
ret = flower_parse_ip_addr(*argv, 0,
@@ -662,6 +793,10 @@ static void flower_print_eth_type(FILE *f, __be16 *p_eth_type,
fprintf(f, "ipv4");
else if (eth_type == htons(ETH_P_IPV6))
fprintf(f, "ipv6");
+ else if (eth_type == htons(ETH_P_ARP))
+ fprintf(f, "arp");
+ else if (eth_type == htons(ETH_P_RARP))
+ fprintf(f, "rarp");
else
fprintf(f, "%04x", ntohs(eth_type));
*p_eth_type = eth_type;
@@ -739,6 +874,13 @@ static void flower_print_ip_addr(FILE *f, char *name, __be16 eth_type,
else if (bits < len * 8)
fprintf(f, "/%d", bits);
}
+static void flower_print_ip4_addr(FILE *f, char *name,
+ struct rtattr *addr_attr,
+ struct rtattr *mask_attr)
+{
+ return flower_print_ip_addr(f, name, htons(ETH_P_IP),
+ addr_attr, mask_attr, 0, 0);
+}
static void flower_print_port(FILE *f, char *name, struct rtattr *attr)
{
@@ -759,6 +901,31 @@ static void flower_print_icmp(FILE *f, char *name, struct rtattr *attr)
fprintf(f, "\n %s %d", name, rta_getattr_u8(attr));
}
+static void flower_print_arp_op(FILE *f, char *name,
+ struct rtattr *op_attr,
+ struct rtattr *mask_attr)
+{
+ uint8_t op, mask;
+
+ if (!op_attr)
+ return;
+
+ op = rta_getattr_u8(op_attr);
+ mask = mask_attr ? rta_getattr_u8(mask_attr) : UINT8_MAX;
+
+ fprintf(f, "\n %s ", name);
+
+ if (mask == UINT8_MAX && op == ARPOP_REQUEST)
+ fprintf(f, "request");
+ else if (mask == UINT8_MAX && op == ARPOP_REPLY)
+ fprintf(f, "reply");
+ else
+ fprintf(f, "%d", op);
+
+ if (mask != UINT8_MAX)
+ fprintf(f, "/%d", mask);
+}
+
static int flower_print_opt(struct filter_util *qu, FILE *f,
struct rtattr *opt, __u32 handle)
{
@@ -834,6 +1001,17 @@ static int flower_print_opt(struct filter_util *qu, FILE *f,
if (nl_type >= 0)
flower_print_icmp(f, "icmp_code", tb[nl_type]);
+ flower_print_ip4_addr(f, "arp_sip", tb[TCA_FLOWER_KEY_ARP_SIP],
+ tb[TCA_FLOWER_KEY_ARP_SIP_MASK]);
+ flower_print_ip4_addr(f, "arp_tip", tb[TCA_FLOWER_KEY_ARP_TIP],
+ tb[TCA_FLOWER_KEY_ARP_TIP_MASK]);
+ flower_print_arp_op(f, "arp_op", tb[TCA_FLOWER_KEY_ARP_OP],
+ tb[TCA_FLOWER_KEY_ARP_OP_MASK]);
+ flower_print_eth_addr(f, "arp_sha", tb[TCA_FLOWER_KEY_ARP_SHA],
+ tb[TCA_FLOWER_KEY_ARP_SHA_MASK]);
+ flower_print_eth_addr(f, "arp_tha", tb[TCA_FLOWER_KEY_ARP_THA],
+ tb[TCA_FLOWER_KEY_ARP_THA_MASK]);
+
flower_print_ip_addr(f, "enc_dst_ip",
tb[TCA_FLOWER_KEY_ENC_IPV4_DST_MASK] ?
htons(ETH_P_IP) : htons(ETH_P_IPV6),
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: next-20170110 build: 1 failures 4 warnings (next-20170110)
From: Sekhar Nori @ 2017-01-11 10:09 UTC (permalink / raw)
To: Stephen Rothwell, Mark Brown
Cc: linaro-kernel, kernel-build-reports, netdev, stephen hemminger,
Michael Scherban, linux-next, Murali Karicheri, J, KEERTHY,
David S. Miller, linux-arm-kernel
In-Reply-To: <20170111072131.51449059@canb.auug.org.au>
On Wednesday 11 January 2017 01:51 AM, Stephen Rothwell wrote:
> Hi Mark,
>
> On Tue, 10 Jan 2017 18:16:07 +0000 Mark Brown <broonie@kernel.org> wrote:
>>
>> On Tue, Jan 10, 2017 at 07:21:32AM +0000, Build bot for Mark Brown wrote:
>>
>> Today's -next fails to build an arm allmodconfig due to:
>>
>>> arm-allmodconfig
>>> ../drivers/net/ethernet/ti/netcp_core.c:1951:28: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>
>> caused by 6a8162e99ef344 (net: netcp: store network statistics in 64
>> bits). It's assigning the function
>>
>> static struct rtnl_link_stats64 *
>> netcp_get_stats(struct net_device *ndev, struct rtnl_link_stats64 *stats)
>>
>> to ndo_get_stats64 which expects a function returning void.
>
> Yes, but only because commit bc1f44709cf2 ("net: make ndo_get_stats64 a
> void function") entered the net-next tree on the same day ... so it
> needs a followup fixup patch for this new usage.
Keerthy sent a patch fixing this yesterday. Looks like he will have to
spin another version though.
https://patchwork.ozlabs.org/patch/713224/
Thanks,
Sekhar
^ 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