* Re: [PATCH net-next v10] openvswitch: enable NSH support
From: Jiri Benc @ 2017-09-26 11:05 UTC (permalink / raw)
To: Yi Yang
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA, e,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1506401236-5716-1-git-send-email-yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Tue, 26 Sep 2017 12:47:16 +0800, Yi Yang wrote:
> + return ((ret != 0) ? false : true);
I'm not going to review this version but this caught my eye - I pointed
out this silly construct in my review of v9. I can understand that
working late in the night and rewriting the code back and forth, one
could end up with such construct and overlook it at the final
self-review before submission. Happens to everyone.
But leaving this after a review pointed it out means you're not paying
enough attention to your work. Even the fact that you sent v10 so
shortly after v9 means you did not spend the needed time on reflecting
on the review and that you did not properly test the new version. And
I told you exactly this before.
Honestly, I'm starting to be tired with reviewing your patch again and
again and pointing out silly mistakes like this one and repeating basic
things to you again and again.
Jiri
^ permalink raw reply
* IMPORTANT,
From: UDO JOHN @ 2017-09-26 10:53 UTC (permalink / raw)
Dear Beloved Friend,
Sorry if this email came to you as a surprise,I am Dr.Udoukwu Johnson
and we are looking for a company or individual from your region to
help us receive investment fund and safekeeping. I will send you full
details As soon As I hear from you. For fast respond Please write me
through this Email: udo.john@iiiha.net
Yours Faithfully,
Dr.Udoukwu Johnson.
^ permalink raw reply
* Re: [PATCH net-next v10] openvswitch: enable NSH support
From: Jiri Benc @ 2017-09-26 10:50 UTC (permalink / raw)
To: Yi Yang; +Cc: netdev, dev, e, davem
In-Reply-To: <1506401236-5716-1-git-send-email-yi.y.yang@intel.com>
On Tue, 26 Sep 2017 12:47:16 +0800, Yi Yang wrote:
> v9->v10
> - Change struct ovs_key_nsh to
> struct ovs_nsh_key_base base;
> __be32 context[NSH_MD1_CONTEXT_SIZE];
> - Fix new comments for v9
NAK, we haven't finished the discussion for v9 yet. It's not
appropriate to send a new version until there's a conclusion (or at
least until the discussion dies).
Jiri
^ permalink raw reply
* Re: [PATCH net-next v9] openvswitch: enable NSH support
From: Jiri Benc @ 2017-09-26 10:49 UTC (permalink / raw)
To: Yang, Yi
Cc: netdev@vger.kernel.org, dev@openvswitch.org, e@erig.me,
davem@davemloft.net, Pravin Shelar
In-Reply-To: <20170926045538.GA5896@localhost.localdomain>
On Tue, 26 Sep 2017 12:55:39 +0800, Yang, Yi wrote:
> After push_nsh, the packet won't be recirculated to flow pipeline, so
> key->eth.type must be set explicitly here, but for pop_nsh, the packet
> will be recirculated to flow pipeline, it will be reparsed, so
> key->eth.type will be set in packet parse function, we needn't handle it
> in pop_nsh.
This seems to be a very different approach than what we currently have.
Looking at the code, the requirement after "destructive" actions such
as pushing or popping headers is to recirculate.
Setting key->eth.type to satisfy conditions in the output path without
updating the rest of the key looks very hacky and fragile to me. There
might be other conditions and dependencies that are not obvious.
I don't think the code was written with such code path in mind.
I'd like to hear what Pravin thinks about this.
Jiri
^ permalink raw reply
* Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when interacting with network stack
From: Yunsheng Lin @ 2017-09-26 10:49 UTC (permalink / raw)
To: Yuval Mintz
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net
In-Reply-To: <AM0PR0502MB3683C922A7D87D3E1F64B93EBF7B0@AM0PR0502MB3683.eurprd05.prod.outlook.com>
Hi, Yuval
On 2017/9/26 14:43, Yuval Mintz wrote:
>> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc
>> is used to tell hclge_dcb module to do the setup.
>
> While this might be a step in the right direction, this causes an inconsistency
> in user experience - Some [well, most] vendors didn't allow the mqprio
> priority mapping to affect DCB, instead relying on the dcbnl functionality
> to control that configuration.
>
> A couple of options to consider:
> - Perhaps said logic shouldn't be contained inside the driver but rather
> in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from
> within mqprio and try changing the configuration.
In net/dcb/dcbnl.c
dcbnl_ieee_set already call dcbnl_ieee_notify to notify the user space
configuration has changed, does this dcbnl_ieee_notify function do the
job for us? I am not sure if lldpad has registered for this notifition.
As you suggested below, can we add a new TC_MQPRIO_HW_OFFLOAD_ value to
reflect that the configuration is needed to be changed by dcbnl_ieee_set
(perhaps some other function) in dcbnl?
Do you think it is feasible?
> - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user
> request to allow this configuration to affect DCB.
>
>> When using lldptool to configure DCB parameter, hclge_dcb module
>> call the client_ops->setup_tc to tell network stack which queue
>> and priority is using for specific tc.
>
> You're basically bypassing the mqprio logic.
> Since you're configuring the prio->queue mapping from DCB flow,
> you'll get an mqprio-like behavior [meaning a transmitted packet
> would reach a transmission queue associated with its priority] even
> if device wasn't grated with an mqprio qdisc.
> Why should your user even use mqprio? What benefit does he get from it?
>
> ...
>
>> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)
>> +{
>> + struct hns3_nic_priv *priv = netdev_priv(netdev);
>> + struct hnae3_handle *h = priv->ae_handle;
>> + struct hnae3_knic_private_info *kinfo = &h->kinfo;
>> + unsigned int queue_size = kinfo->rss_size * kinfo->num_tc;
>> + int ret;
>> +
>> + ret = netif_set_real_num_tx_queues(netdev, queue_size);
>> + if (ret) {
>> + netdev_err(netdev,
>> + "netif_set_real_num_tx_queues fail, ret=%d!\n",
>> + ret);
>> + return ret;
>> + }
>> +
>> + ret = netif_set_real_num_rx_queues(netdev, queue_size);
>
> I don't think you're changing the driver behavior, but why are you setting
> the real number of rx queues based on the number of TCs?
> Do you actually open (TC x RSS) Rx queues?
>
> .
>
^ permalink raw reply
* [PATCH] net: stmmac: dwmac4: Re-enable MAC Rx before powering down
From: Ed Blake @ 2017-09-26 10:44 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue; +Cc: netdev, Ed Blake
Re-enable the MAC receiver by setting CONFIG_RE before powering down,
as instructed in section 6.3.5.1 of [1]. Without this the MAC fails
to receive WoL packets and never wakes up.
[1] DWC Ethernet QoS Databook 4.10a October 2014
Signed-off-by: Ed Blake <ed.blake@sondrel.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index c4407e8..2f7d7ec 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -296,6 +296,7 @@ static void dwmac4_pmt(struct mac_device_info *hw, unsigned long mode)
{
void __iomem *ioaddr = hw->pcsr;
unsigned int pmt = 0;
+ u32 config;
if (mode & WAKE_MAGIC) {
pr_debug("GMAC: WOL Magic frame\n");
@@ -306,6 +307,12 @@ static void dwmac4_pmt(struct mac_device_info *hw, unsigned long mode)
pmt |= power_down | global_unicast | wake_up_frame_en;
}
+ if (pmt) {
+ /* The receiver must be enabled for WOL before powering down */
+ config = readl(ioaddr + GMAC_CONFIG);
+ config |= GMAC_CONFIG_RE;
+ writel(config, ioaddr + GMAC_CONFIG);
+ }
writel(pmt, ioaddr + GMAC_PMT);
}
--
1.9.1
^ permalink raw reply related
* [PATCH] net: stmmac: dwc-qos: Add suspend / resume support
From: Ed Blake @ 2017-09-26 10:43 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue; +Cc: netdev, Ed Blake
Add hook to stmmac_pltfr_pm_ops for suspend / resume handling.
Signed-off-by: Ed Blake <ed.blake@sondrel.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
index dd6a2f9..5efef80 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
@@ -511,6 +511,7 @@ static int dwc_eth_dwmac_remove(struct platform_device *pdev)
.remove = dwc_eth_dwmac_remove,
.driver = {
.name = "dwc-eth-dwmac",
+ .pm = &stmmac_pltfr_pm_ops,
.of_match_table = dwc_eth_dwmac_match,
},
};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next 0/7] nfp: flower vxlan tunnel offload
From: Jiri Benc @ 2017-09-26 10:15 UTC (permalink / raw)
To: Simon Horman
Cc: Or Gerlitz, David Miller, Jakub Kicinski, Linux Netdev List,
oss-drivers, John Hurley, Paolo Abeni, Eli Cohen, Paul Blakey
In-Reply-To: <20170925170451.GD18763@vergenet.net>
On Mon, 25 Sep 2017 19:04:53 +0200, Simon Horman wrote:
> The MAC addresses are extracted from the netdevs already loaded in the
> kernel and are monitored for any changes. The IP addresses are slightly
> different in that they are extracted from the rules themselves. We make the
> assumption that, if a packet is decapsulated at the end point and a match
> is attempted on the IP address,
You lost me here, I'm afraid. What do you mean by "match"?
> that this IP address should be recognised
> in the kernel. That being the case, the same traffic pattern should be
> witnessed if the skip_hw flag is applied.
Just to be really sure that this works correctly, can you confirm that
this will match the packet:
ip link add vxlan0 type vxlan dstport 4789 dev eth0 external
ip link set dev vxlan0 up
tc qdisc add dev vxlan0 ingress
ethtool -K eth0 hw-tc-offload on
tc filter add dev vxlan0 protocol ip parent ffff: flower enc_key_id 102 \
enc_dst_port 4789 src_ip 3.4.5.6 skip_sw action [...]
while this one will NOT match:
ip link add vxlan0 type vxlan dstport 4789 dev eth0 external
ip link set dev vxlan0 up
tc qdisc add dev eth0 ingress
ethtool -K eth0 hw-tc-offload on
tc filter add dev eth0 protocol ip parent ffff: flower enc_key_id 102 \
enc_dst_port 4789 src_ip 3.4.5.6 skip_sw action [...]
We found that with mlx5, the second one actually matches, too. Which is
a very serious bug. (Adding Paolo who found this. And adding a few more
Mellanox guys to be aware of the bug.)
Jiri
^ permalink raw reply
* Re: [PATCH net-next 7/7] nfp: flower vxlan neighbour keep-alive
From: John Hurley @ 2017-09-26 9:37 UTC (permalink / raw)
To: Or Gerlitz
Cc: Simon Horman, David Miller, Jakub Kicinski, Linux Netdev List,
oss-drivers
In-Reply-To: <CAK+XE=mVKbAqYwSYvLb0y48O9D-Oq+B_bks7c9iwjsm0j7oYvw@mail.gmail.com>
[ Reposting in plantext only]
On Mon, Sep 25, 2017 at 7:32 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Mon, Sep 25, 2017 at 1:23 PM, Simon Horman
> <simon.horman@netronome.com> wrote:
> > From: John Hurley <john.hurley@netronome.com>
> >
> > Periodically receive messages containing the destination IPs of tunnels
> > that have recently forwarded traffic. Update the neighbour entries 'used'
> > value for these IPs next hop.
>
> Are you proactively sending keep alive messages from the driver or the
> fw? what's wrong with the probes sent by the kernel NUD subsystem?
>
Hi Or,
The messages are sent from the FW to the driver. They indicate which
offloaded tunnels are currently active.
>
> In our driver we also update the used value for neighs of offloaded
> tunnels, we do it based on flow counters for the offloaded tunnels
> which is an evidence for activity. Any reason for you not to apply a
> similar practice?
Yes, this would provide the same outcome. Because our firmware already
offered these messages, we chose to support this approach.
>
>
> Or.
^ permalink raw reply
* [PATCH v2 2/2] ip_tunnel: add mpls over gre encapsulation
From: Amine Kherbouche @ 2017-09-26 9:22 UTC (permalink / raw)
To: netdev, xeb, roopa; +Cc: amine.kherbouche, equinox
In-Reply-To: <cover.1506416988.git.amine.kherbouche@6wind.com>
This commit introduces the MPLSoGRE support (RFC 4023), using ip tunnel
API.
Encap:
- Add a new iptunnel type mpls.
- Share tx path: gre type mpls loaded from skb->protocol.
Decap:
- pull gre hdr and call mpls_forward().
Signed-off-by: Amine Kherbouche <amine.kherbouche@6wind.com>
---
include/net/gre.h | 3 +++
include/uapi/linux/if_tunnel.h | 1 +
net/ipv4/gre_demux.c | 22 ++++++++++++++++++++++
net/ipv4/ip_gre.c | 9 +++++++++
net/ipv6/ip6_gre.c | 7 +++++++
net/mpls/af_mpls.c | 40 ++++++++++++++++++++++++++++++++++++++++
6 files changed, 82 insertions(+)
diff --git a/include/net/gre.h b/include/net/gre.h
index d25d836..88a8343 100644
--- a/include/net/gre.h
+++ b/include/net/gre.h
@@ -35,6 +35,9 @@ struct net_device *gretap_fb_dev_create(struct net *net, const char *name,
u8 name_assign_type);
int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
bool *csum_err, __be16 proto, int nhs);
+#if IS_ENABLED(CONFIG_MPLS)
+int mpls_gre_rcv(struct sk_buff *skb, int gre_hdr_len);
+#endif
static inline int gre_calc_hlen(__be16 o_flags)
{
diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
index 2e52088..a2f48c0 100644
--- a/include/uapi/linux/if_tunnel.h
+++ b/include/uapi/linux/if_tunnel.h
@@ -84,6 +84,7 @@ enum tunnel_encap_types {
TUNNEL_ENCAP_NONE,
TUNNEL_ENCAP_FOU,
TUNNEL_ENCAP_GUE,
+ TUNNEL_ENCAP_MPLS,
};
#define TUNNEL_ENCAP_FLAG_CSUM (1<<0)
diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c
index b798862..a6a937e 100644
--- a/net/ipv4/gre_demux.c
+++ b/net/ipv4/gre_demux.c
@@ -23,6 +23,9 @@
#include <linux/netdevice.h>
#include <linux/if_tunnel.h>
#include <linux/spinlock.h>
+#if IS_ENABLED(CONFIG_MPLS)
+#include <linux/mpls.h>
+#endif
#include <net/protocol.h>
#include <net/gre.h>
@@ -122,6 +125,25 @@ int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
}
EXPORT_SYMBOL(gre_parse_header);
+#if IS_ENABLED(CONFIG_MPLS)
+int mpls_gre_rcv(struct sk_buff *skb, int gre_hdr_len)
+{
+ if (unlikely(!pskb_may_pull(skb, gre_hdr_len)))
+ goto drop;
+
+ /* Pop GRE hdr and reset the skb */
+ skb_pull(skb, gre_hdr_len);
+ skb_reset_network_header(skb);
+
+ mpls_forward(skb, skb->dev, NULL, NULL);
+
+ return 0;
+drop:
+ return NET_RX_DROP;
+}
+EXPORT_SYMBOL(mpls_gre_rcv);
+#endif
+
static int gre_rcv(struct sk_buff *skb)
{
const struct gre_protocol *proto;
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 9cee986..dd4431c 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -412,10 +412,19 @@ static int gre_rcv(struct sk_buff *skb)
return 0;
}
+#if IS_ENABLED(CONFIG_MPLS)
+ if (unlikely(tpi.proto == htons(ETH_P_MPLS_UC))) {
+ if (mpls_gre_rcv(skb, hdr_len))
+ goto drop;
+ return 0;
+ }
+#endif
+
if (ipgre_rcv(skb, &tpi, hdr_len) == PACKET_RCVD)
return 0;
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
+
drop:
kfree_skb(skb);
return 0;
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index c82d41e..e52396d 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -476,6 +476,13 @@ static int gre_rcv(struct sk_buff *skb)
if (hdr_len < 0)
goto drop;
+#if IS_ENABLED(CONFIG_MPLS)
+ if (unlikely(tpi.proto == htons(ETH_P_MPLS_UC))) {
+ if (mpls_gre_rcv(skb, hdr_len))
+ goto drop;
+ return 0;
+ }
+#endif
if (iptunnel_pull_header(skb, hdr_len, tpi.proto, false))
goto drop;
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 36ea2ad..5505074 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -16,6 +16,7 @@
#include <net/arp.h>
#include <net/ip_fib.h>
#include <net/netevent.h>
+#include <net/ip_tunnels.h>
#include <net/netns/generic.h>
#if IS_ENABLED(CONFIG_IPV6)
#include <net/ipv6.h>
@@ -39,6 +40,40 @@ static int one = 1;
static int label_limit = (1 << 20) - 1;
static int ttl_max = 255;
+size_t ipgre_mpls_encap_hlen(struct ip_tunnel_encap *e)
+{
+ return sizeof(struct mpls_shim_hdr);
+}
+
+int ipgre_mpls_build_header(struct sk_buff *skb, struct ip_tunnel_encap *e,
+ u8 *protocol, struct flowi4 *fl4)
+{
+ return 0;
+}
+
+static const struct ip_tunnel_encap_ops mpls_iptun_ops = {
+ .encap_hlen = ipgre_mpls_encap_hlen,
+ .build_header = ipgre_mpls_build_header,
+};
+
+static int ipgre_tunnel_encap_add_mpls_ops(void)
+{
+ int ret = -1;
+
+#if IS_ENABLED(CONFIG_NET_IP_TUNNEL)
+ ret = ip_tunnel_encap_add_ops(&mpls_iptun_ops, TUNNEL_ENCAP_MPLS);
+#endif
+
+ return ret;
+}
+
+static void ipgre_tunnel_encap_del_mpls_ops(void)
+{
+#if IS_ENABLED(CONFIG_NET_IP_TUNNEL)
+ ip_tunnel_encap_del_ops(&mpls_iptun_ops, TUNNEL_ENCAP_MPLS);
+#endif
+}
+
static void rtmsg_lfib(int event, u32 label, struct mpls_route *rt,
struct nlmsghdr *nlh, struct net *net, u32 portid,
unsigned int nlm_flags);
@@ -2486,6 +2521,10 @@ static int __init mpls_init(void)
0);
rtnl_register(PF_MPLS, RTM_GETNETCONF, mpls_netconf_get_devconf,
mpls_netconf_dump_devconf, 0);
+ err = ipgre_tunnel_encap_add_mpls_ops();
+ if (err)
+ pr_err("Can't add mpls over gre tunnel ops\n");
+
err = 0;
out:
return err;
@@ -2503,6 +2542,7 @@ static void __exit mpls_exit(void)
dev_remove_pack(&mpls_packet_type);
unregister_netdevice_notifier(&mpls_dev_notifier);
unregister_pernet_subsys(&mpls_net_ops);
+ ipgre_tunnel_encap_del_mpls_ops();
}
module_exit(mpls_exit);
--
2.1.4
^ permalink raw reply related
* [PATCH v2 0/2] Introduce MPLS over GRE
From: Amine Kherbouche @ 2017-09-26 9:22 UTC (permalink / raw)
To: netdev, xeb, roopa; +Cc: amine.kherbouche, equinox
This series introduces the MPLS over GRE encapsulation (RFC 4023).
Various applications of MPLS make use of label stacks with multiple
entries. In some cases, it is possible to replace the top label of
the stack with an IP-based encapsulation, thereby, it is possible for
two LSRs that are adjacent on an LSP to be separated by an IP network,
even if that IP network does not provide MPLS.
Changes in v2:
- wrap ip tunnel functions under ifdef in mpls file.
- fix indentation.
- check return code.
An example of configuration:
node1 LER1 LER2 node2
+-----+ +------+ +------+ +-----+
| | | | | | | |
| | | |p3 GRE tunnel p4| | | |
| |p1 p2| +-------------------+ |p5 p6| |
| +-------------+ +-------------------+ +------------+| |
| |10.100.0.0/24| | | |10.200.0.0/24| |
| |fd00:100::/64| | 10.125.0.0/24 | |fd00:200::/64| |
| | | | fd00:125::/64 | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
+-----+ +------+ +------+ +-----+
### node1 ###
ip link set p1 up
ip addr add 10.100.0.1/24 dev p1
### LER1 ###
ip link set p2 up
ip addr add 10.100.0.2/24 dev p2
ip link set p3 up
ip addr add 10.125.0.1/24 dev p3
modprobe mpls_router
sysctl -w net.mpls.conf.p2.input=1
sysctl -w net.mpls.conf.p3.input=1
sysctl -w net.mpls.platform_labels=1000
ip link add gre1 type gre ttl 64 local 10.125.0.1 remote 10.125.0.2 dev p3
ip link set dev gre1 up
ip -M route add 111 as 222 dev gre1
ip -M route add 555 as 666 via inet 10.100.0.1 dev p2
### LER2 ###
ip link set p5 up
ip addr add 10.200.0.2/24 dev p5
ip link set p4 up
ip addr add 10.125.0.2/24 dev p4
modprobe mpls_router
sysctl -w net.mpls.conf.p4.input=1
sysctl -w net.mpls.conf.p5.input=1
sysctl -w net.mpls.platform_labels=1000
ip link add gre1 type gre ttl 64 local 10.125.0.2 remote 10.125.0.1 dev p4
ip link set dev gre1 up
ip -M route add 444 as 555 dev gre1
ip -M route add 222 as 333 via inet 10.200.0.1 dev p5
### node2 ###
ip link set p6 up
ip addr add 10.200.0.1/24 dev p6
Now using this scapy to forge and send packets from the port p1 of node1:
p = Ether(src='de:ed:01:0c:41:09', dst='de:ed:01:2f:3b:ba')
p /= MPLS(s=1, ttl=64, label=111)/Raw(load='\xde')
sendp(p, iface="p1", count=20, inter=0.1)
Amine Kherbouche (2):
mpls: expose stack entry function
ip_tunnel: add mpls over gre encapsulation
include/linux/mpls.h | 3 +++
include/net/gre.h | 3 +++
include/uapi/linux/if_tunnel.h | 1 +
net/ipv4/gre_demux.c | 22 +++++++++++++++++++++
net/ipv4/ip_gre.c | 9 +++++++++
net/ipv6/ip6_gre.c | 7 +++++++
net/mpls/af_mpls.c | 45 ++++++++++++++++++++++++++++++++++++++++--
7 files changed, 88 insertions(+), 2 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v2 1/2] mpls: expose stack entry function
From: Amine Kherbouche @ 2017-09-26 9:22 UTC (permalink / raw)
To: netdev, xeb, roopa; +Cc: amine.kherbouche, equinox
In-Reply-To: <cover.1506416988.git.amine.kherbouche@6wind.com>
Exporting mpls_forward() function to be able to be called from elsewhere
such as MPLS over GRE in the next commit.
Signed-off-by: Amine Kherbouche <amine.kherbouche@6wind.com>
---
include/linux/mpls.h | 3 +++
net/mpls/af_mpls.c | 5 +++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/mpls.h b/include/linux/mpls.h
index 384fb22..d5c7599 100644
--- a/include/linux/mpls.h
+++ b/include/linux/mpls.h
@@ -2,10 +2,13 @@
#define _LINUX_MPLS_H
#include <uapi/linux/mpls.h>
+#include <linux/netdevice.h>
#define MPLS_TTL_MASK (MPLS_LS_TTL_MASK >> MPLS_LS_TTL_SHIFT)
#define MPLS_BOS_MASK (MPLS_LS_S_MASK >> MPLS_LS_S_SHIFT)
#define MPLS_TC_MASK (MPLS_LS_TC_MASK >> MPLS_LS_TC_SHIFT)
#define MPLS_LABEL_MASK (MPLS_LS_LABEL_MASK >> MPLS_LS_LABEL_SHIFT)
+int mpls_forward(struct sk_buff *skb, struct net_device *dev,
+ struct packet_type *pt, struct net_device *orig_dev);
#endif /* _LINUX_MPLS_H */
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index c5b9ce4..36ea2ad 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -307,8 +307,8 @@ static bool mpls_egress(struct net *net, struct mpls_route *rt,
return success;
}
-static int mpls_forward(struct sk_buff *skb, struct net_device *dev,
- struct packet_type *pt, struct net_device *orig_dev)
+int mpls_forward(struct sk_buff *skb, struct net_device *dev,
+ struct packet_type *pt, struct net_device *orig_dev)
{
struct net *net = dev_net(dev);
struct mpls_shim_hdr *hdr;
@@ -442,6 +442,7 @@ static int mpls_forward(struct sk_buff *skb, struct net_device *dev,
kfree_skb(skb);
return NET_RX_DROP;
}
+EXPORT_SYMBOL(mpls_forward);
static struct packet_type mpls_packet_type __read_mostly = {
.type = cpu_to_be16(ETH_P_MPLS_UC),
--
2.1.4
^ permalink raw reply related
* [PATCH net-next] kcm: Remove redundant unlikely()
From: Tobias Klauser @ 2017-09-26 9:22 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller
IS_ERR() already implies unlikely(), so it can be omitted.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/kcm/kcmsock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
index af4e76ac88ff..0b750a22c4b9 100644
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1650,7 +1650,7 @@ static int kcm_clone(struct socket *osock, struct kcm_clone *info,
}
newfile = sock_alloc_file(newsock, 0, osock->sk->sk_prot_creator->name);
- if (unlikely(IS_ERR(newfile))) {
+ if (IS_ERR(newfile)) {
err = PTR_ERR(newfile);
goto out_sock_alloc_fail;
}
--
2.13.0
^ permalink raw reply related
* [PATCH net-next] ipv6: Remove redundant unlikely()
From: Tobias Klauser @ 2017-09-26 9:22 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
IS_ERR() already implies unlikely(), so it can be omitted.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/ipv6/addrconf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 96861c702c06..13c3b697f8c0 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3297,7 +3297,7 @@ static int fixup_permanent_addr(struct inet6_dev *idev,
struct rt6_info *rt, *prev;
rt = addrconf_dst_alloc(idev, &ifp->addr, false);
- if (unlikely(IS_ERR(rt)))
+ if (IS_ERR(rt))
return PTR_ERR(rt);
/* ifp->rt can be accessed outside of rtnl */
--
2.13.0
^ permalink raw reply related
* [PATCH net-next] datagram: Remove redundant unlikely()
From: Tobias Klauser @ 2017-09-26 9:21 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller
IS_ERR() already implies unlikely(), so it can be omitted.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/core/datagram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/datagram.c b/net/core/datagram.c
index f7fb7e3f2acf..0b7b4c22719e 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -188,7 +188,7 @@ struct sk_buff *__skb_try_recv_from_queue(struct sock *sk,
}
if (!skb->len) {
skb = skb_set_peeked(skb);
- if (unlikely(IS_ERR(skb))) {
+ if (IS_ERR(skb)) {
*err = PTR_ERR(skb);
return NULL;
}
--
2.13.0
^ permalink raw reply related
* [PATCH net-next] net: ena: Remove redundant unlikely()
From: Tobias Klauser @ 2017-09-26 9:04 UTC (permalink / raw)
To: netdev; +Cc: Netanel Belgazal, Saeed Bishara, Zorik Machulsky, David S. Miller
IS_ERR() already implies unlikely(), so it can be omitted.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ethernet/amazon/ena/ena_com.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c b/drivers/net/ethernet/amazon/ena/ena_com.c
index 52beba8c7a39..ded29af648c9 100644
--- a/drivers/net/ethernet/amazon/ena/ena_com.c
+++ b/drivers/net/ethernet/amazon/ena/ena_com.c
@@ -315,7 +315,7 @@ static struct ena_comp_ctx *ena_com_submit_admin_cmd(struct ena_com_admin_queue
cmd_size_in_bytes,
comp,
comp_size_in_bytes);
- if (unlikely(IS_ERR(comp_ctx)))
+ if (IS_ERR(comp_ctx))
admin_queue->running_state = false;
spin_unlock_irqrestore(&admin_queue->q_lock, flags);
@@ -1130,7 +1130,7 @@ int ena_com_execute_admin_command(struct ena_com_admin_queue *admin_queue,
comp_ctx = ena_com_submit_admin_cmd(admin_queue, cmd, cmd_size,
comp, comp_size);
- if (unlikely(IS_ERR(comp_ctx))) {
+ if (IS_ERR(comp_ctx)) {
if (comp_ctx == ERR_PTR(-ENODEV))
pr_debug("Failed to submit command [%ld]\n",
PTR_ERR(comp_ctx));
--
2.13.0
^ permalink raw reply related
* Re: [PATCH] r8152: add Linksys USB3GIGV1 id
From: Greg KH @ 2017-09-26 7:35 UTC (permalink / raw)
To: Grant Grundler
Cc: Oliver Neukum, Hayes Wang, David S . Miller, LKML, linux-usb,
netdev
In-Reply-To: <CANEJEGtM+gFC9Ofmp=UmGn5pKys9NRbsC6+ks_VqaLKWkEBS8A@mail.gmail.com>
On Mon, Sep 25, 2017 at 01:17:32PM -0700, Grant Grundler wrote:
> Correct. r8152 happens to claim the device before cdc_ether does - I
> thought because cdc_ether is a class driver and only gets picked up
> after vendor specific drivers are probed. Is that correct?
Nope, there is not "priority" scheme of binding some drivers to devices
instead of others at all in Linux. The whole scheme is "first in the
list", and has always been that way.
And yes, people have talked about changing this for decades now, but no
one has come up with any working patch, for the obvious reasons[1].
thanks,
greg k-h
[1] exercise is left for the reader :)
^ permalink raw reply
* Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when interacting with network stack
From: Yunsheng Lin @ 2017-09-26 7:33 UTC (permalink / raw)
To: Yuval Mintz
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net
In-Reply-To: <AM0PR0502MB3683C922A7D87D3E1F64B93EBF7B0@AM0PR0502MB3683.eurprd05.prod.outlook.com>
Hi, Yuval
On 2017/9/26 14:43, Yuval Mintz wrote:
>> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc
>> is used to tell hclge_dcb module to do the setup.
>
> While this might be a step in the right direction, this causes an inconsistency
> in user experience - Some [well, most] vendors didn't allow the mqprio
> priority mapping to affect DCB, instead relying on the dcbnl functionality
> to control that configuration.
>
> A couple of options to consider:
> - Perhaps said logic shouldn't be contained inside the driver but rather
> in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from
> within mqprio and try changing the configuration.
> - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user
> request to allow this configuration to affect DCB.
>
>> When using lldptool to configure DCB parameter, hclge_dcb module
>> call the client_ops->setup_tc to tell network stack which queue
>> and priority is using for specific tc.
>
> You're basically bypassing the mqprio logic.
> Since you're configuring the prio->queue mapping from DCB flow,
> you'll get an mqprio-like behavior [meaning a transmitted packet
> would reach a transmission queue associated with its priority] even
> if device wasn't grated with an mqprio qdisc.
> Why should your user even use mqprio? What benefit does he get from it?
>
> ...
>
>> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)
>> +{
>> + struct hns3_nic_priv *priv = netdev_priv(netdev);
>> + struct hnae3_handle *h = priv->ae_handle;
>> + struct hnae3_knic_private_info *kinfo = &h->kinfo;
>> + unsigned int queue_size = kinfo->rss_size * kinfo->num_tc;
>> + int ret;
>> +
>> + ret = netif_set_real_num_tx_queues(netdev, queue_size);
>> + if (ret) {
>> + netdev_err(netdev,
>> + "netif_set_real_num_tx_queues fail, ret=%d!\n",
>> + ret);
>> + return ret;
>> + }
>> +
>> + ret = netif_set_real_num_rx_queues(netdev, queue_size);
>
> I don't think you're changing the driver behavior, but why are you setting
> the real number of rx queues based on the number of TCs?
> Do you actually open (TC x RSS) Rx queues?
Yes, our hardware can do the rss based on TC.
Sorry for almost forget to answer this question.
Thanks for your time reviewing again.
>
> .
>
^ permalink raw reply
* Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when interacting with network stack
From: Yunsheng Lin @ 2017-09-26 7:29 UTC (permalink / raw)
To: Yuval Mintz
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net
In-Reply-To: <AM0PR0502MB3683C922A7D87D3E1F64B93EBF7B0@AM0PR0502MB3683.eurprd05.prod.outlook.com>
Hi, Yuval
On 2017/9/26 14:43, Yuval Mintz wrote:
>> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc
>> is used to tell hclge_dcb module to do the setup.
>
> While this might be a step in the right direction, this causes an inconsistency
> in user experience - Some [well, most] vendors didn't allow the mqprio
> priority mapping to affect DCB, instead relying on the dcbnl functionality
> to control that configuration.
>
> A couple of options to consider:
> - Perhaps said logic shouldn't be contained inside the driver but rather
> in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from
> within mqprio and try changing the configuration.
> - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user
> request to allow this configuration to affect DCB.
>
>> When using lldptool to configure DCB parameter, hclge_dcb module
>> call the client_ops->setup_tc to tell network stack which queue
>> and priority is using for specific tc.
>
> You're basically bypassing the mqprio logic.
> Since you're configuring the prio->queue mapping from DCB flow,
> you'll get an mqprio-like behavior [meaning a transmitted packet
> would reach a transmission queue associated with its priority] even
> if device wasn't grated with an mqprio qdisc.
> Why should your user even use mqprio? What benefit does he get from it?
When adding mqprio and lldptool support, I was thinking user can use
tc qdisc or lldptool to do the configuration, giving user two option to
setup the DCB.
If user is only tc qdisc or lldptool, I think there is no problem here.
when user is using tc qdisc and lldptool, As you explained above, When
tc qdisc changes the configuration, there should be a way to notify dcbnl,
so that the dcbnl can response correctly(like tell the peer it's configuration
has changed).
I will try to find if there is a way to do notify the dcbnl when using tc qdisc
to setup the configuration.
If there is not a way to do it now, then I will drop the mqprio in this patch, and
will address this problem if there is need for the tc qdisc.
Please let me know if I was misunderstood.
And thanks for your time reviewing.
>
> ...
>
>> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)
>> +{
>> + struct hns3_nic_priv *priv = netdev_priv(netdev);
>> + struct hnae3_handle *h = priv->ae_handle;
>> + struct hnae3_knic_private_info *kinfo = &h->kinfo;
>> + unsigned int queue_size = kinfo->rss_size * kinfo->num_tc;
>> + int ret;
>> +
>> + ret = netif_set_real_num_tx_queues(netdev, queue_size);
>> + if (ret) {
>> + netdev_err(netdev,
>> + "netif_set_real_num_tx_queues fail, ret=%d!\n",
>> + ret);
>> + return ret;
>> + }
>> +
>> + ret = netif_set_real_num_rx_queues(netdev, queue_size);
>
> I don't think you're changing the driver behavior, but why are you setting
> the real number of rx queues based on the number of TCs?
> Do you actually open (TC x RSS) Rx queues?
>
> .
>
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: AceLan Kao @ 2017-09-26 7:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <20170926064456.GA28611@infradead.org>
Ath9k is an old driver for old chips, and they work fine with legacy INTx.
But some new platforms are using it, so I think we should list those
new platforms which blocks INTx in the driver.
BTW, new chips use ath10k driver.
2017-09-26 14:44 GMT+08:00 Christoph Hellwig <hch@infradead.org>:
> On Tue, Sep 26, 2017 at 02:41:35PM +0800, AceLan Kao wrote:
>> Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI
>> for WLAN device. So adding a quirk to list those machines and set
>> use_msi automatically.
>> Adding Dell Inspiron 24-3460 to the quirk.
>
> Huh? Using MSI should be the default, and skipping MSI should be
> a quirk if needed at all (usually it should be autodetected)
^ permalink raw reply
* Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
From: Arnd Bergmann @ 2017-09-26 6:47 UTC (permalink / raw)
To: David Laight
Cc: Mauro Carvalho Chehab, Jiri Pirko, Arend van Spriel, Kalle Valo,
David S. Miller, Andrey Ryabinin, Alexander Potapenko,
Dmitry Vyukov, Masahiro Yamada, Michal Marek, Andrew Morton,
Kees Cook, Geert Uytterhoeven, Greg Kroah-Hartman,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, "linux-wireles
In-Reply-To: <CAK8P3a1zxjMsQTBPijCo8FJjEU5aRVTr7n_NZ1YM2UnDPKoRLw@mail.gmail.com>
On Mon, Sep 25, 2017 at 11:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Sep 25, 2017 at 7:41 AM, David Laight <David.Laight@aculab.com> wrote:
>> From: Arnd Bergmann
>>> Sent: 22 September 2017 22:29
>> ...
>>> It seems that this is triggered in part by using strlcpy(), which the
>>> compiler doesn't recognize as copying at most 'len' bytes, since strlcpy
>>> is not part of the C standard.
>>
>> Neither is strncpy().
>>
>> It'll almost certainly be a marker in a header file somewhere,
>> so it should be possibly to teach it about other functions.
>
> I'm currently travelling and haven't investigated in detail, but from
> taking a closer look here, I found that the hardened 'strlcpy()'
> in include/linux/string.h triggers it. There is also a hardened
> (much shorted) 'strncpy()' that doesn't trigger it in the same file,
> and having only the extern declaration of strncpy also doesn't.
And a little more experimenting leads to this simple patch that fixes
the problem:
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -254,7 +254,7 @@ __FORTIFY_INLINE size_t strlcpy(char *p, const
char *q, size_t size)
size_t q_size = __builtin_object_size(q, 0);
if (p_size == (size_t)-1 && q_size == (size_t)-1)
return __real_strlcpy(p, q, size);
- ret = strlen(q);
+ ret = __builtin_strlen(q);
if (size) {
size_t len = (ret >= size) ? size - 1 : ret;
if (__builtin_constant_p(len) && len >= p_size)
The problem is apparently that the fortified strlcpy calls the fortified strlen,
which in turn calls strnlen and that ends up calling the extern '__real_strnlen'
that gcc cannot reduce to a constant expression for a constant input.
Not sure if that change is the best fix, but it seems to address the problem in
this driver and probably leads to better code in other places as well.
Arnd
^ permalink raw reply
* Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
From: Christoph Hellwig @ 2017-09-26 6:44 UTC (permalink / raw)
To: AceLan Kao
Cc: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1506408099-18488-2-git-send-email-acelan.kao@canonical.com>
On Tue, Sep 26, 2017 at 02:41:35PM +0800, AceLan Kao wrote:
> Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI
> for WLAN device. So adding a quirk to list those machines and set
> use_msi automatically.
> Adding Dell Inspiron 24-3460 to the quirk.
Huh? Using MSI should be the default, and skipping MSI should be
a quirk if needed at all (usually it should be autodetected)
^ permalink raw reply
* RE: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when interacting with network stack
From: Yuval Mintz @ 2017-09-26 6:43 UTC (permalink / raw)
To: Yunsheng Lin
Cc: huangdaode@hisilicon.com, xuwei5@hisilicon.com,
liguozhu@hisilicon.com, Yisen.Zhuang@huawei.com,
gabriele.paoloni@huawei.com, john.garry@huawei.com,
linuxarm@huawei.com, yisen.zhuang@huawei.com,
salil.mehta@huawei.com, lipeng321@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net
In-Reply-To: <1506392718-50463-11-git-send-email-linyunsheng@huawei.com>
> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc
> is used to tell hclge_dcb module to do the setup.
While this might be a step in the right direction, this causes an inconsistency
in user experience - Some [well, most] vendors didn't allow the mqprio
priority mapping to affect DCB, instead relying on the dcbnl functionality
to control that configuration.
A couple of options to consider:
- Perhaps said logic shouldn't be contained inside the driver but rather
in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from
within mqprio and try changing the configuration.
- Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user
request to allow this configuration to affect DCB.
> When using lldptool to configure DCB parameter, hclge_dcb module
> call the client_ops->setup_tc to tell network stack which queue
> and priority is using for specific tc.
You're basically bypassing the mqprio logic.
Since you're configuring the prio->queue mapping from DCB flow,
you'll get an mqprio-like behavior [meaning a transmitted packet
would reach a transmission queue associated with its priority] even
if device wasn't grated with an mqprio qdisc.
Why should your user even use mqprio? What benefit does he get from it?
...
> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)
> +{
> + struct hns3_nic_priv *priv = netdev_priv(netdev);
> + struct hnae3_handle *h = priv->ae_handle;
> + struct hnae3_knic_private_info *kinfo = &h->kinfo;
> + unsigned int queue_size = kinfo->rss_size * kinfo->num_tc;
> + int ret;
> +
> + ret = netif_set_real_num_tx_queues(netdev, queue_size);
> + if (ret) {
> + netdev_err(netdev,
> + "netif_set_real_num_tx_queues fail, ret=%d!\n",
> + ret);
> + return ret;
> + }
> +
> + ret = netif_set_real_num_rx_queues(netdev, queue_size);
I don't think you're changing the driver behavior, but why are you setting
the real number of rx queues based on the number of TCs?
Do you actually open (TC x RSS) Rx queues?
^ permalink raw reply
* [PATCH 6/6] ath9k: set use_msi=1 on Dell Inspiron 14-3473
From: AceLan Kao @ 2017-09-26 6:41 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1506408099-18488-1-git-send-email-acelan.kao@canonical.com>
BIOS on Dell Inspiron 14-3473 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
---
drivers/net/wireless/ath/ath9k/init.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index e1198e1..d03e1fc 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -136,6 +136,14 @@ static const struct dmi_system_id ath9k_quirks[] __initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 15-3572"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Inspiron 14-3473",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14-3473"),
+ },
+ },
{}
};
--
2.7.4
^ permalink raw reply related
* [PATCH 5/6] ath9k: set use_msi=1 on Dell Vostro 15-3572
From: AceLan Kao @ 2017-09-26 6:41 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1506408099-18488-1-git-send-email-acelan.kao@canonical.com>
BIOS on Dell Vostro 15-3572 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
---
drivers/net/wireless/ath/ath9k/init.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index fce9ac7..e1198e1 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -128,6 +128,14 @@ static const struct dmi_system_id ath9k_quirks[] __initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 3472"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Vostro 15-3572",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 15-3572"),
+ },
+ },
{}
};
--
2.7.4
^ permalink raw reply related
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