* Re: [next-queue PATCH v4 3/4] net/sched: Introduce Credit Based Shaper (CBS) qdisc
From: Jiri Pirko @ 2017-10-04 6:36 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: netdev, intel-wired-lan, jhs, xiyou.wangcong, andre.guedes,
ivan.briano, jesus.sanchez-palencia, boon.leong.ong,
richardcochran, henrik, levipearson, rodney.cummings
In-Reply-To: <20171004002831.18371-4-vinicius.gomes@intel.com>
Wed, Oct 04, 2017 at 02:28:30AM CEST, vinicius.gomes@intel.com wrote:
>This queueing discipline implements the shaper algorithm defined by
>the 802.1Q-2014 Section 8.6.8.2 and detailed in Annex L.
>
>It's primary usage is to apply some bandwidth reservation to user
>defined traffic classes, which are mapped to different queues via the
>mqprio qdisc.
>
>Initially, it only supports offloading the traffic shaping work to
>supporting controllers.
>
>Later, when a software implementation is added, the current dependency
>on being installed "under" mqprio can be lifted.
>
>Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
>---
> include/linux/netdevice.h | 1 +
> include/net/pkt_sched.h | 9 ++
> include/uapi/linux/pkt_sched.h | 17 ++++
> net/sched/Kconfig | 11 ++
> net/sched/Makefile | 1 +
> net/sched/sch_cbs.c | 225 +++++++++++++++++++++++++++++++++++++++++
> 6 files changed, 264 insertions(+)
> create mode 100644 net/sched/sch_cbs.c
>
>diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>index e1d6ef130611..b8798adc214f 100644
>--- a/include/linux/netdevice.h
>+++ b/include/linux/netdevice.h
>@@ -775,6 +775,7 @@ enum tc_setup_type {
> TC_SETUP_CLSFLOWER,
> TC_SETUP_CLSMATCHALL,
> TC_SETUP_CLSBPF,
>+ TC_SETUP_CBS,
Please split this into 2 patches. One will introduce the new qdisc,
second will add offload capabilities.
[...]
>+static struct Qdisc_ops cbs_qdisc_ops __read_mostly = {
>+ .next = NULL,
>+ .id = "cbs",
>+ .priv_size = sizeof(struct cbs_sched_data),
>+ .enqueue = cbs_enqueue,
>+ .dequeue = qdisc_dequeue_head,
>+ .peek = qdisc_peek_dequeued,
>+ .init = cbs_init,
>+ .reset = qdisc_reset_queue,
>+ .destroy = cbs_destroy,
>+ .change = cbs_change,
>+ .dump = cbs_dump,
>+ .owner = THIS_MODULE,
>+};
I don't see a software implementation for this. Looks like you are
trying abuse tc subsystem to bypass kernel. Could you please explain
this? The golden rule is: implement in kernel, then offload.
^ permalink raw reply
* Re: [PATCH net-next 5/7] net: bonding: Add extack messages for some enslave failures
From: Jiri Pirko @ 2017-10-04 6:38 UTC (permalink / raw)
To: David Ahern
Cc: netdev, j.vosburgh, vfalico, andy, jiri, idosch, davem, bridge
In-Reply-To: <1507093134-20406-6-git-send-email-dsahern@gmail.com>
Wed, Oct 04, 2017 at 06:58:52AM CEST, dsahern@gmail.com wrote:
>A number of bond_enslave errors are logged using the netdev_err API.
>Return those messages to userspace via the extack facility.
>
>Signed-off-by: David Ahern <dsahern@gmail.com>
>---
> drivers/net/bonding/bond_main.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index bc92307c2082..6688dc9154e0 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -1348,12 +1348,15 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
>
> /* already in-use? */
> if (netdev_is_rx_handler_busy(slave_dev)) {
>+ NL_SET_ERR_MSG(extack,
>+ "Device is in use and cannot be enslaved");
Please don't do this kind of wrapping. Just let the string be on the
same line.
^ permalink raw reply
* Re: [PATCH v4 net-next 0/8] flow_dissector: Protocol specific flow dissector offload
From: Jiri Pirko @ 2017-10-04 6:45 UTC (permalink / raw)
To: Tom Herbert
Cc: Tom Herbert, David Miller, Hannes Frederic Sowa,
Linux Kernel Network Developers, Rohit Seth
In-Reply-To: <CAPDqMeq3er9=P9AUFKf4-FcSgthpv2hUz+WTb78DRHGEJ0TTWA@mail.gmail.com>
Tue, Oct 03, 2017 at 08:35:54PM CEST, tom@quantonium.net wrote:
>On Tue, Oct 3, 2017 at 12:46 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Fri, Sep 29, 2017 at 07:59:35PM CEST, tom@herbertland.com wrote:
>>>On Fri, Sep 29, 2017 at 10:42 AM, David Miller <davem@davemloft.net> wrote:
>>>> From: Tom Herbert <tom@herbertland.com>
>>>> Date: Fri, 29 Sep 2017 08:48:55 -0700
>>>>
>>>>> The flow_dissector interface is not a uAPI.
>>>>
>>>> That's not true, insofar as cls_flower.c uses the flow_dissector
>>>> therefore if you change the flow_dissector in certain ways then
>>>> cls_flower.c might have it's behavior changed and that is in fact UAPI
>>>> facing.
>>>
>>>Then I would suggest adding another flag like FLOW_DISSECTOR_F_FLOWER
>>>and when anyone puts new code into flow_dissector they can wrap it
>>>with "if !(flags & FLOW_DISSECTOR_F_FLOWER)". If the flower uAPI is
>>>subsequently update then the conditional can be removed. This way
>>>flower can support maintain its APIs, but we can still still extend
>>>and improve flow_dissector for othersuse cases.
>>
>> This is not flower-specific problem. Flow_dissector is a servant of many.
>
>Besides flower, what other use cases of flow_dissector have made
>flow_dissector interface a uAPI? Any use of hashing does not do this.
>Maybe OVS does?
It may be that currently it affects only flower. That does not mean you
should add flower-specific quirk. All I say is this should be handled in
a generic way, independent on the caller.
>
>> As such, it is instructed what should it do. If you want to
>> change the way inner headers are parsed, you should either:
>
>Why would that only affect the way inner headers are parsed? Wouldn't
>we need to consider any change to flow_dissector that might affect the
>output in any way. For instance, the depth limits I added would change
>to output for someone that was parsing thirty-five layers of
>encapsulation so it it looks like that feature needs a flag. What if
>someone adds a new Ethernet protocol or a new encap protocol?
Sure, what I ment was any change of behaviour.
>
>> 1) change the callers so they are behaving the same as before
>> 2) make the flow_dissection change optional so the caller can say if he
>> wants original or new behaviour.
>
>I guess we can do that, but am concerned about the overhead this will
>generate if were adding a flag each time anyone modifies the function.
>There are performance critical use cases of flow_dissector that will
>be impacted by such changes.
I don't think that the overhead would be much different from what you
proposed.
>
>Tom
>
>
>>
^ permalink raw reply
* etsec2 attached to sgmii phy
From: Jörg Willmann @ 2017-10-04 5:56 UTC (permalink / raw)
To: netdev
Hi,
we use a QorIQ P1011 connected via SGMII to a switch (Marvell 88E6352).
Currently we still use a really old linux kernel (2.6.33) successfully.
For configuration of the MDIO Bus attached to the corresponding eTSEC/TBI
Phy we use the following settings in the device tree:
mdio@25000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "fsl,etsec2-tbi";
reg = <0x25000 0x1000 0xb1030 0x4>;
tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
linux,phandle = <0x5>;
phandle = <0x5>;
};
};
First resource in the mdio config is the base address of the MDIO bus, the
second resource defines the address of TBIPA.
Doing tests with a newer kernel (4.4.71) I was faced with problems
communicating with the TBIPHY.
Debugging this I found out that TBIPA is no longer parameterized correctly
and I found out why:
In commit afae5ad78b342f401c28b0bb1adb3cd494cb125a initialization of TIBPA
has been changed:
In former versions in get_gfar_tbipa(...) for compatible "etsec2-tbi" the
second resource of the reg entry has been used. But now only first
resource is mapped and get_etsec_tbipa(...) which is now
responsible to return the proper address does not (and has no way due to
missing *np as function argument) do so but returns the first resource
(which is the base address of mdio controller).
What do you think would be the correct way to solve this issue? Re-add *np
to the get_*_tba() functions to be able to return the proper address?
Thank's for reading,
Best regards,
Joerg
^ permalink raw reply
* Re: [PATCH net-next v4 1/3] bridge: add new BR_NEIGH_SUPPRESS port flag to suppress arp and nd flood
From: Toshiaki Makita @ 2017-10-04 7:21 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: nikolay, netdev, bridge, davem
In-Reply-To: <1507093953-59929-2-git-send-email-roopa@cumulusnetworks.com>
On 2017/10/04 14:12, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch adds a new bridge port flag BR_NEIGH_SUPPRESS to
> suppress arp and nd flood on bridge ports. It implements
> rfc7432, section 10.
> https://tools.ietf.org/html/rfc7432#section-10
> for ethernet VPN deployments. It is similar to the existing
> BR_ARP_PROXY flag but has a few semantic differences to conform
> to EVPN standard. In case of EVPN, it is mainly used to
> avoid flooding to tunnel ports like vxlan. Unlike the existing
> flags it suppresses flood of all neigh discovery packets
> (arp, nd) to tunnel ports.
>
> This patch adds netlink and sysfs support to set this bridge port
> flag.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
...
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index dea88a2..d8c2706 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -138,6 +138,7 @@ static inline size_t br_port_info_size(void)
> + nla_total_size(1) /* IFLA_BRPORT_PROXYARP */
> + nla_total_size(1) /* IFLA_BRPORT_PROXYARP_WIFI */
> + nla_total_size(1) /* IFLA_BRPORT_VLAN_TUNNEL */
> + + nla_total_size(1) /* IFLA_BRPORT_NEIGH_SUPPRESS */
> + nla_total_size(sizeof(struct ifla_bridge_id)) /* IFLA_BRPORT_ROOT_ID */
> + nla_total_size(sizeof(struct ifla_bridge_id)) /* IFLA_BRPORT_BRIDGE_ID */
> + nla_total_size(sizeof(u16)) /* IFLA_BRPORT_DESIGNATED_PORT */
> @@ -210,7 +211,9 @@ static int br_port_fill_attrs(struct sk_buff *skb,
> nla_put_u8(skb, IFLA_BRPORT_CONFIG_PENDING, p->config_pending) ||
> nla_put_u8(skb, IFLA_BRPORT_VLAN_TUNNEL, !!(p->flags &
> BR_VLAN_TUNNEL)) ||
> - nla_put_u16(skb, IFLA_BRPORT_GROUP_FWD_MASK, p->group_fwd_mask))
> + nla_put_u16(skb, IFLA_BRPORT_GROUP_FWD_MASK, p->group_fwd_mask) ||
> + nla_put_u8(skb, IFLA_BRPORT_NEIGH_SUPPRESS, !!(p->flags &
> + BR_NEIGH_SUPPRESS)))
Wouldn't it be better to make the indentation like this?
... !!(p->flags &
BR_NEIGH_SUPPRESS)))
> return -EMSGSIZE;
>
> timerval = br_timer_value(&p->message_age_timer);
> @@ -692,6 +695,7 @@ static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
> {
> unsigned long old_flags = p->flags;
> bool br_vlan_tunnel_old = false;
> + int neigh_suppress_old = 0;
> int err;
>
> err = br_set_port_flag(p, tb, IFLA_BRPORT_MODE, BR_HAIRPIN_MODE);
> @@ -785,6 +789,12 @@ static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
> p->group_fwd_mask = fwd_mask;
> }
>
> + neigh_suppress_old = (p->flags & BR_NEIGH_SUPPRESS);
> + br_set_port_flag(p, tb, IFLA_BRPORT_NEIGH_SUPPRESS,
> + BR_NEIGH_SUPPRESS);
> + if (neigh_suppress_old != (p->flags & BR_NEIGH_SUPPRESS))
> + br_recalculate_neigh_suppress_enabled(p->br);
> +
You are calling br_recalculate_neigh_suppress_enabled() from within
br_port_flags_change() immediately after this.
I think you can just call br_set_port_flag() here.
> br_port_flags_change(p, old_flags ^ p->flags);
> return 0;
> }
--
Toshiaki Makita
^ permalink raw reply
* Re: [Bridge] [PATCH net-next v4 2/3] bridge: suppress arp pkts on BR_NEIGH_SUPPRESS ports
From: Toshiaki Makita @ 2017-10-04 7:35 UTC (permalink / raw)
To: Roopa Prabhu, davem; +Cc: nikolay, netdev, bridge
In-Reply-To: <1507093953-59929-3-git-send-email-roopa@cumulusnetworks.com>
On 2017/10/04 14:12, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> This patch avoids flooding and proxies arp packets
> for BR_NEIGH_SUPPRESS ports.
>
> Moves existing br_do_proxy_arp to br_do_proxy_suppress_arp
> to support both proxy arp and neigh suppress.
>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> ---
...
> +static void br_arp_send(struct net_bridge_port *p, int type, int ptype,
type and ptype are always the same so seems unnecessary.
> + __be32 dest_ip, struct net_device *dev,
> + __be32 src_ip, const unsigned char *dest_hw,
> + const unsigned char *src_hw,
> + const unsigned char *target_hw,
> + __be16 vlan_proto, u16 vlan_tci)
> +{
> + struct sk_buff *skb;
> +
> + netdev_dbg(dev, "arp send dev %s dst %pI4 dst_hw %pM src %pI4 src_hw %pM\n",
> + dev->name, &dest_ip, dest_hw, &src_ip, src_hw);
> +
> + if (!vlan_tci) {
> + arp_send(type, ptype, dest_ip, dev, src_ip,
> + dest_hw, src_hw, target_hw);
I may be missing something, but wouldn't it send arp reply from the
bridge device, while it should be received to the bridge device, when p
== NULL?
> + return;
> + }
> +
> + skb = arp_create(type, ptype, dest_ip, dev, src_ip,
> + dest_hw, src_hw, target_hw);
> + if (!skb)
> + return;
> +
> + if (p) {
Why doesn't bridge device consider pvid?
> + struct net_bridge_vlan_group *vg;
> + u16 pvid;
> +
> + vg = nbp_vlan_group_rcu(p);
> + pvid = br_get_pvid(vg);
> + if (pvid == vlan_tci)
Need vlan_tci & VLAN_VID_MASK
Or use skb_vlan_tag_get_id() in caller side.
> + vlan_tci = 0;
> + }
> +
> + if (vlan_tci) {
> + skb = vlan_insert_tag_set_proto(skb, vlan_proto,
> + vlan_tci);
Should be __vlan_hwaccel_put_tag()
> + if (!skb) {
> + net_err_ratelimited("%s: failed to insert VLAN tag\n",
> + __func__);
> + return;
> + }
> + }
> +
> + arp_xmit(skb);
> +}
...
> +void br_do_proxy_suppress_arp(struct sk_buff *skb, struct net_bridge *br,
> + u16 vid, struct net_bridge_port *p)
> +{
...
> + if (br->neigh_suppress_enabled) {
> + if (p && (p->flags & BR_NEIGH_SUPPRESS))
> + return;
> + if (ipv4_is_zeronet(sip) || sip == tip) {
> + /* prevent flooding to neigh suppress ports */
> + BR_INPUT_SKB_CB(skb)->proxyarp_replied = true;
> + return;
> + }
> + }
> +
> + if (parp->ar_op != htons(ARPOP_REQUEST))
> + return;
> +
> + if (vid != 0) {
vid should be 0 if untagged is set on the bridge device?
> + vlandev = __vlan_find_dev_deep_rcu(br->dev, skb->vlan_proto,
> + vid);
> + if (!vlandev)
> + return;
> + }
> +
> + if (br->neigh_suppress_enabled && br_is_local_ip(vlandev, tip)) {
> + /* its our local ip, so don't proxy reply
> + * and don't forward to neigh suppress ports
> + */
> + BR_INPUT_SKB_CB(skb)->proxyarp_replied = true;
> + return;
> + }
--
Toshiaki Makita
^ permalink raw reply
* Re: Fw: [Bug 197099] New: Kernel panic in interrupt [l2tp_ppp]
From: James Chapman @ 2017-10-04 7:49 UTC (permalink / raw)
To: SviMik; +Cc: netdev, Guillaume Nault
In-Reply-To: <CAEwTi7S3-B81bNxyWq8j4hUpXyqNnTADReYoKoGF-V4wC5OBkQ@mail.gmail.com>
On 3 October 2017 at 08:27, James Chapman <jchapman@katalix.com> wrote:
> On 2 October 2017 at 19:35, SviMik <svimik@gmail.com> wrote:
>> Hi, James!
>>
>> No, I'm suffering from kernel panics since I started using 4.x
>> kernels.
> It's interesting that you are seeing l2tp issues since switching to
> 4.x kernels. Are you able to try earlier kernels to find the latest
> version that works? I'm curious whether things broke at v3.15.
It's possible that this may be fixed by a patch that is already
upstream and merged for v4.14. The fix is from Guillaume Nault:
f3c66d4 l2tp: prevent creation of sessions on terminated tunnels
If it's possible that the L2TP server may try to create a session in a
tunnel that is being closed, this bug would be exposed.
Guillaume's fix isn't yet pushed to stable releases. Are you able to
try a v4.14-rc build?
^ permalink raw reply
* [PATCH v2 net-next] ravb: RX checksum offload
From: Simon Horman @ 2017-10-04 7:54 UTC (permalink / raw)
To: David Miller, Sergei Shtylyov
Cc: Magnus Damm, netdev, linux-renesas-soc, Simon Horman
Add support for RX checksum offload. This is enabled by default and
may be disabled and re-enabled using ethtool:
# ethtool -K eth0 rx off
# ethtool -K eth0 rx on
The RAVB provides a simple checksumming scheme which appears to be
completely compatible with CHECKSUM_COMPLETE: sum of all packet data after
the L2 header is appended to packet data; this may be trivially read by the
driver and used to update the skb accordingly.
In terms of performance throughput is close to gigabit line-rate both with
and without RX checksum offload enabled. Perf output, however, appears to
indicate that significantly less time is spent in do_csum(). This is as
expected.
Test results with RX checksum offload enabled:
# /usr/bin/perf_3.16 record -o /run/perf.data -a netperf -t TCP_MAERTS -H 10.4.3.162
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.4.3.162 () port 0 AF_INET : demo
enable_enobufs failed: getprotobyname
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 937.54
Summary of output of perf report:
18.28% ksoftirqd/0 [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
10.34% ksoftirqd/0 [kernel.kallsyms] [k] __pi_memcpy
9.83% ksoftirqd/0 [kernel.kallsyms] [k] ravb_poll
7.89% ksoftirqd/0 [kernel.kallsyms] [k] skb_put
4.01% ksoftirqd/0 [kernel.kallsyms] [k] dev_gro_receive
3.37% netperf [kernel.kallsyms] [k] __arch_copy_to_user
3.17% swapper [kernel.kallsyms] [k] arch_cpu_idle
2.55% swapper [kernel.kallsyms] [k] tick_nohz_idle_enter
2.04% ksoftirqd/0 [kernel.kallsyms] [k] __pi___inval_dcache_area
2.03% swapper [kernel.kallsyms] [k] _raw_spin_unlock_irq
1.96% ksoftirqd/0 [kernel.kallsyms] [k] __netdev_alloc_skb
1.59% ksoftirqd/0 [kernel.kallsyms] [k] __slab_alloc.isra.83
Test results without RX checksum offload enabled:
# /usr/bin/perf_3.16 record -o /run/perf.data -a netperf -t TCP_MAERTS -H 10.4.3.162
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.4.3.162 () port 0 AF_INET : demo
enable_enobufs failed: getprotobyname
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 940.20
Summary of output of perf report:
17.10% ksoftirqd/0 [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
10.99% ksoftirqd/0 [kernel.kallsyms] [k] __pi_memcpy
8.87% ksoftirqd/0 [kernel.kallsyms] [k] ravb_poll
8.16% ksoftirqd/0 [kernel.kallsyms] [k] skb_put
7.42% ksoftirqd/0 [kernel.kallsyms] [k] do_csum
3.91% ksoftirqd/0 [kernel.kallsyms] [k] dev_gro_receive
2.31% swapper [kernel.kallsyms] [k] arch_cpu_idle
2.16% ksoftirqd/0 [kernel.kallsyms] [k] __pi___inval_dcache_area
2.14% ksoftirqd/0 [kernel.kallsyms] [k] __netdev_alloc_skb
1.93% netperf [kernel.kallsyms] [k] __arch_copy_to_user
1.79% swapper [kernel.kallsyms] [k] tick_nohz_idle_enter
1.63% ksoftirqd/0 [kernel.kallsyms] [k] __slab_alloc.isra.83
Above results collected on an R-Car Gen 3 Salvator-X/r8a7796 ES1.0.
Also tested on a R-Car Gen 3 Salvator-X/r8a7795 ES1.0.
By inspection this also appears to be compatible with the ravb found
on R-Car Gen 2 SoCs, however, this patch is currently untested on such
hardware.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v2
Address review of v1 by Sergei Shtylyov
* set features rather than oring them with (zero) existing values:
* Set/unset using a single call to ravb_modify()
---
drivers/net/ethernet/renesas/ravb_main.c | 55 +++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index fdf30bfa403b..a8822a756e08 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -403,8 +403,9 @@ static void ravb_emac_init(struct net_device *ndev)
/* Receive frame limit set register */
ravb_write(ndev, ndev->mtu + ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN, RFLR);
- /* PAUSE prohibition */
+ /* EMAC Mode: PAUSE prohibition; Duplex; RX Checksum; TX; RX */
ravb_write(ndev, ECMR_ZPF | (priv->duplex ? ECMR_DM : 0) |
+ (ndev->features & NETIF_F_RXCSUM ? ECMR_RCSC : 0) |
ECMR_TE | ECMR_RE, ECMR);
ravb_set_rate(ndev);
@@ -520,6 +521,19 @@ static void ravb_get_tx_tstamp(struct net_device *ndev)
}
}
+static void ravb_rx_csum(struct sk_buff *skb)
+{
+ u8 *hw_csum;
+
+ /* The hardware checksum is 2 bytes appended to packet data */
+ if (unlikely(skb->len < 2))
+ return;
+ hw_csum = skb_tail_pointer(skb) - 2;
+ skb->csum = csum_unfold((__force __sum16)get_unaligned_le16(hw_csum));
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ skb_trim(skb, skb->len - 2);
+}
+
/* Packet receive function for Ethernet AVB */
static bool ravb_rx(struct net_device *ndev, int *quota, int q)
{
@@ -587,8 +601,11 @@ static bool ravb_rx(struct net_device *ndev, int *quota, int q)
ts.tv_nsec = le32_to_cpu(desc->ts_n);
shhwtstamps->hwtstamp = timespec64_to_ktime(ts);
}
+
skb_put(skb, pkt_len);
skb->protocol = eth_type_trans(skb, ndev);
+ if (ndev->features & NETIF_F_RXCSUM)
+ ravb_rx_csum(skb);
napi_gro_receive(&priv->napi[q], skb);
stats->rx_packets++;
stats->rx_bytes += pkt_len;
@@ -1842,6 +1859,38 @@ static int ravb_do_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
return phy_mii_ioctl(phydev, req, cmd);
}
+static void ravb_set_rx_csum(struct net_device *ndev, bool enable)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->lock, flags);
+
+ /* Disable TX and RX */
+ ravb_rcv_snd_disable(ndev);
+
+ /* Modify RX Checksum setting */
+ ravb_modify(ndev, ECMR, ECMR_RCSC, enable ? ECMR_RCSC : 0);
+
+ /* Enable TX and RX */
+ ravb_rcv_snd_enable(ndev);
+
+ spin_unlock_irqrestore(&priv->lock, flags);
+}
+
+static int ravb_set_features(struct net_device *ndev,
+ netdev_features_t features)
+{
+ netdev_features_t changed = ndev->features ^ features;
+
+ if (changed & NETIF_F_RXCSUM)
+ ravb_set_rx_csum(ndev, features & NETIF_F_RXCSUM);
+
+ ndev->features = features;
+
+ return 0;
+}
+
static const struct net_device_ops ravb_netdev_ops = {
.ndo_open = ravb_open,
.ndo_stop = ravb_close,
@@ -1853,6 +1902,7 @@ static const struct net_device_ops ravb_netdev_ops = {
.ndo_do_ioctl = ravb_do_ioctl,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,
+ .ndo_set_features = ravb_set_features,
};
/* MDIO bus init function */
@@ -2004,6 +2054,9 @@ static int ravb_probe(struct platform_device *pdev)
if (!ndev)
return -ENOMEM;
+ ndev->features = NETIF_F_RXCSUM;
+ ndev->hw_features = NETIF_F_RXCSUM;
+
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info
From: Simon Horman @ 2017-10-04 8:08 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, Jiri Pirko, Jamal Hadi Salim, Cong Wang,
Linux Kernel Network Developers, oss-drivers
In-Reply-To: <CALx6S37K3Gif=AGk48CXs9JgrcDbdpfqMZWK+0j95UHG0hvpZg@mail.gmail.com>
On Tue, Oct 03, 2017 at 11:17:46AM -0700, Tom Herbert wrote:
> On Tue, Oct 3, 2017 at 2:40 AM, Simon Horman <simon.horman@netronome.com> wrote:
> > On Mon, Oct 02, 2017 at 01:37:55PM -0700, Tom Herbert wrote:
> >> On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman <simon.horman@netronome.com> wrote:
> >> > Move dissection of tunnel info from the flower classifier to the flow
> >> > dissector where all other dissection occurs. This should not have any
> >> > behavioural affect on other users of the flow dissector.
> >
> > ...
>
> > I feel that we are circling back the perennial issue of flower using the
> > flow dissector in a somewhat broader/different way than many/all other
> > users of the flow dissector.
> >
> Simon,
>
> It's more like __skb_flow_dissect is already an incredibly complex
> function and because of that it's difficult to maintain. We need to
> measure changes against that fact. For this patch, there is precisely
> one user (cls_flower.c) and it's not at all clear to me if there will
> be ever any more (e.g. for hashing we don't need tunnel info). IMO, it
> should be just as easy and less convolution for everyone to have
> flower call __skb_flow_dissect_tunnel_info directly and not call if
> from __skb_flow_dissect.
Hi Tom,
my original suggestion was just that, but Jiri indicated a strong preference
for the approach taken by this patch. I think we need to widen the
participants in this discussion.
^ permalink raw reply
* Re: [PATCH net-next 2/2] flow_dissector: dissect tunnel info
From: Jiri Pirko @ 2017-10-04 8:15 UTC (permalink / raw)
To: Simon Horman
Cc: Tom Herbert, David Miller, Jiri Pirko, Jamal Hadi Salim,
Cong Wang, Linux Kernel Network Developers, oss-drivers
In-Reply-To: <20171004080856.GB6378@netronome.com>
Wed, Oct 04, 2017 at 10:08:57AM CEST, simon.horman@netronome.com wrote:
>On Tue, Oct 03, 2017 at 11:17:46AM -0700, Tom Herbert wrote:
>> On Tue, Oct 3, 2017 at 2:40 AM, Simon Horman <simon.horman@netronome.com> wrote:
>> > On Mon, Oct 02, 2017 at 01:37:55PM -0700, Tom Herbert wrote:
>> >> On Mon, Oct 2, 2017 at 1:41 AM, Simon Horman <simon.horman@netronome.com> wrote:
>> >> > Move dissection of tunnel info from the flower classifier to the flow
>> >> > dissector where all other dissection occurs. This should not have any
>> >> > behavioural affect on other users of the flow dissector.
>> >
>> > ...
>>
>> > I feel that we are circling back the perennial issue of flower using the
>> > flow dissector in a somewhat broader/different way than many/all other
>> > users of the flow dissector.
>> >
>> Simon,
>>
>> It's more like __skb_flow_dissect is already an incredibly complex
>> function and because of that it's difficult to maintain. We need to
>> measure changes against that fact. For this patch, there is precisely
>> one user (cls_flower.c) and it's not at all clear to me if there will
>> be ever any more (e.g. for hashing we don't need tunnel info). IMO, it
>> should be just as easy and less convolution for everyone to have
>> flower call __skb_flow_dissect_tunnel_info directly and not call if
>> from __skb_flow_dissect.
>
>Hi Tom,
>
>my original suggestion was just that, but Jiri indicated a strong preference
>for the approach taken by this patch. I think we need to widen the
>participants in this discussion.
I like the __skb_flow_dissect to be the function to call and it will do
the job according to the configuration. I don't like to split in
multiple calls. Does not make sense in the most of the cases as the
dissection state would have to be carried in between calls.
^ permalink raw reply
* Re: [PATCH net-next 3/3] Move shared tcp code to net/ipv4v6shared
From: Richard Siegfried @ 2017-10-04 8:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, David Miller, yoshfuji, kuznet
In-Reply-To: <CAOaVG14r2Uwm+r17Oa9jwKj50vRr8=SqwXEmmGAeW8rHj3FgXg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 428 bytes --]
On 04/10/17 03:32, Stephen Hemminger wrote:
> The name ipv4v6_shared is longer than it needs to be maybe ip or ip_common
Well ip_common sounds nice.
But I don't fully understand what this means for the current situation.
I could do a v2, but would that make any sense since Dave and Eric
already said "no" to the whole concept.
Would it change anything to keep the tcp directory in net/ipv4/ (only
1/3 and 2/3)?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 529 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: Kalle Valo @ 2017-10-04 9:02 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Maxime Ripard, Chen-Yu Tsai,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171003165944.13056-2-icenowy-h8G6r0blFSE@public.gmane.org>
Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> writes:
> Allwinner XR819 is a SDIO Wi-Fi chip, which has the functionality to use
> an out-of-band interrupt pin instead of SDIO in-band interrupt.
>
> Add the device tree binding of this chip, in order to make it possible
> to add this interrupt pin to device trees.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Changes in v3:
> - Renames the node name.
> - Adds ACK from Rob.
> Changes in v2:
> - Removed status property in example.
> - Added required property reg.
>
> .../bindings/net/wireless/allwinner,xr819.txt | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
Like I asked already last time, AFAICS there is no upstream xr819
wireless driver in drivers/net/wireless directory. Do we still accept
bindings like this for out-of-tree drivers?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: Icenowy Zheng @ 2017-10-04 9:03 UTC (permalink / raw)
To: Kalle Valo
Cc: Rob Herring, Maxime Ripard, Chen-Yu Tsai,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <871smjxp46.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
于 2017年10月4日 GMT+08:00 下午5:02:17, Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 写到:
>Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> writes:
>
>> Allwinner XR819 is a SDIO Wi-Fi chip, which has the functionality to
>use
>> an out-of-band interrupt pin instead of SDIO in-band interrupt.
>>
>> Add the device tree binding of this chip, in order to make it
>possible
>> to add this interrupt pin to device trees.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> Changes in v3:
>> - Renames the node name.
>> - Adds ACK from Rob.
>> Changes in v2:
>> - Removed status property in example.
>> - Added required property reg.
>>
>> .../bindings/net/wireless/allwinner,xr819.txt | 38
>++++++++++++++++++++++
>> 1 file changed, 38 insertions(+)
>> create mode 100644
>Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
>
>Like I asked already last time, AFAICS there is no upstream xr819
>wireless driver in drivers/net/wireless directory. Do we still accept
>bindings like this for out-of-tree drivers?
See esp8089.
There's also no in-tree driver for it.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: ath9k: make const array reg_hole_list static, reduces object code size
From: Kalle Valo @ 2017-10-04 9:09 UTC (permalink / raw)
To: Colin Ian King
Cc: QCA ath9k Development, Kalle Valo, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20170919204019.30804-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> Don't populate the read-only array reg_hole_list on the stack, instead make
> it static. Makes the object code smaller by over 200 bytes:
>
> Before:
> text data bss dec hex filename
> 57518 15248 0 72766 11c3e debug.o
>
> After:
> text data bss dec hex filename
> 57218 15344 0 72562 11b72 debug.o
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
eba0f28473b2 ath9k: make const array reg_hole_list static, reduces object code size
--
https://patchwork.kernel.org/patch/9960183/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* RE: [PATCH] fsl/fman: remove of_node
From: Madalin-cristian Bucur @ 2017-10-04 9:53 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, andrew@lunn.ch, f.fainelli@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20171003.214357.2276688669726195045.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, October 04, 2017 7:44 AM
> To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
> Cc: netdev@vger.kernel.org; andrew@lunn.ch; f.fainelli@gmail.com; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] fsl/fman: remove of_node
>
> From: Madalin-cristian Bucur <madalin.bucur@nxp.com>
> Date: Tue, 3 Oct 2017 08:49:31 +0000
>
> > My patch removes the of_node that was set to a device that was not an
> > of_device, preventing duplicated probing of both the real of_device
> > and the "fake" one created through this assignment.
> >
> > I understand that the DSA issue that triggered the initial change
> > was related to DSA finding the network devices using
> > of_find_net_device_by_node(), something that will not work for the
> > DPAA case where the netdevice does not have an of_node. I do not know
> > enough about DSA to come up with a solution for this problem now.
> > Andrew, Florian, can you please comment on this?
>
> It sounds like you're knowingly breaking DSA.
It never worked, even with the change I'm reverting.
^ permalink raw reply
* RE: [PATCH] fsl/fman: remove of_node
From: Madalin-cristian Bucur @ 2017-10-04 9:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, netdev@vger.kernel.org, f.fainelli@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20171003130032.GI13548@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Tuesday, October 03, 2017 4:01 PM
> To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
> Cc: David Miller <davem@davemloft.net>; netdev@vger.kernel.org;
> f.fainelli@gmail.com; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] fsl/fman: remove of_node
>
> On Tue, Oct 03, 2017 at 08:49:31AM +0000, Madalin-cristian Bucur wrote:
> > > -----Original Message-----
> > > From: David Miller [mailto:davem@davemloft.net]
> > > Sent: Tuesday, October 03, 2017 2:05 AM
> > > To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
> > > Subject: Re: [PATCH] fsl/fman: remove of_node
> > >
> > > From: Madalin Bucur <madalin.bucur@nxp.com>
> > > Date: Mon, 2 Oct 2017 13:31:37 +0300
> > >
> > > > The FMan MAC driver allocates a platform device for the Ethernet
> > > > driver to probe on. Setting pdev->dev.of_node with the MAC node
> > > > triggers the MAC driver probing of the new platform device. While
> > > > this fails quickly and does not affect the functionality of the
> > > > drivers, it is incorrect and must be removed. This was added to
> > > > address a report that DSA code using of_find_net_device_by_node()
> > > > is unable to use the DPAA interfaces. Error message seen before
> > > > this fix:
> > > >
> > > > fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> > > > fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> > > >
> > > > Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
> > >
> > > Is the DSA issue no longer something we need to be concerned
> > > about? If not, why? You have to explain this.
> >
> > My patch removes the of_node that was set to a device that was not an
> > of_device, preventing duplicated probing of both the real of_device
> > and the "fake" one created through this assignment.
> >
> > I understand that the DSA issue that triggered the initial change
> > was related to DSA finding the network devices using
> > of_find_net_device_by_node(), something that will not work for the
> > DPAA case where the netdevice does not have an of_node. I do not know
> > enough about DSA to come up with a solution for this problem now.
> > Andrew, Florian, can you please comment on this?
> >
> > Thanks,
>
> Hi Madalin
>
> I guess the real fix is to throw away the platform device. But that is
> a big change.
>
> I've not looked at the code in detail. Why is the platform device
> needed?
>
> Andrew
There are multiple components that are aggregated by the DPAA Ethernet
netdevice, the FMan MAC is one of them. There is no entry in the device
tree for the Ethernet device as this is just a software construct that
binds together multiple pieces from the DPAA FMan, QMan, BMan. The probing
of the Ethernet driver is performed against a platform device that is created
in the FMan MAC. Setting the of_node in the new platform device makes it
look like an of_device without being one, thus the errors at the MAC driver
probing against the platform device.
Does DSA work for systems that do not use a device tree to boot, i.e. ACPI?
Madalin
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: 'Arend van Spriel' via linux-sunxi @ 2017-10-04 10:02 UTC (permalink / raw)
To: Icenowy Zheng, Kalle Valo
Cc: Rob Herring, Maxime Ripard, Chen-Yu Tsai,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <E46F3A20-294A-497E-AF71-C77A67AFDB8C-h8G6r0blFSE@public.gmane.org>
On 10/4/2017 11:03 AM, Icenowy Zheng wrote:
>
>
> 于 2017年10月4日 GMT+08:00 下午5:02:17, Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 写到:
>> Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> writes:
>>
>>> Allwinner XR819 is a SDIO Wi-Fi chip, which has the functionality to
>> use
>>> an out-of-band interrupt pin instead of SDIO in-band interrupt.
>>>
>>> Add the device tree binding of this chip, in order to make it
>> possible
>>> to add this interrupt pin to device trees.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> ---
>>> Changes in v3:
>>> - Renames the node name.
>>> - Adds ACK from Rob.
>>> Changes in v2:
>>> - Removed status property in example.
>>> - Added required property reg.
>>>
>>> .../bindings/net/wireless/allwinner,xr819.txt | 38
>> ++++++++++++++++++++++
>>> 1 file changed, 38 insertions(+)
>>> create mode 100644
>> Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
>>
>> Like I asked already last time, AFAICS there is no upstream xr819
>> wireless driver in drivers/net/wireless directory. Do we still accept
>> bindings like this for out-of-tree drivers?
>
> See esp8089.
>
> There's also no in-tree driver for it.
The question is whether we should. The above might be a precedent, but
it may not necessarily be the way to go. The commit message for esp8089
seems to hint that there is intent to have an in-tree driver:
"""
Note that at this point there only is an out of tree driver for this
hardware, there is no clear timeline / path for merging this. Still
I believe it would be good to specify the binding for this in tree
now, so that any future migration to an in tree driver will not cause
compatiblity issues.
Cc: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
"""
Regardless the bindings are in principle independent of the kernel and
just describing hardware. I think there have been discussions to move
the bindings to their own repository, but apparently it was decided
otherwise.
Regards,
Arend
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: Maxime Ripard @ 2017-10-04 10:11 UTC (permalink / raw)
To: Arend van Spriel
Cc: Icenowy Zheng, Kalle Valo, Rob Herring, Chen-Yu Tsai,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <59D4B1C8.8020105-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]
On Wed, Oct 04, 2017 at 10:02:48AM +0000, Arend van Spriel wrote:
> On 10/4/2017 11:03 AM, Icenowy Zheng wrote:
> >
> >
> > 于 2017年10月4日 GMT+08:00 下午5:02:17, Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 写到:
> > > Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> writes:
> > >
> > > > Allwinner XR819 is a SDIO Wi-Fi chip, which has the functionality to
> > > use
> > > > an out-of-band interrupt pin instead of SDIO in-band interrupt.
> > > >
> > > > Add the device tree binding of this chip, in order to make it
> > > possible
> > > > to add this interrupt pin to device trees.
> > > >
> > > > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> > > > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > ---
> > > > Changes in v3:
> > > > - Renames the node name.
> > > > - Adds ACK from Rob.
> > > > Changes in v2:
> > > > - Removed status property in example.
> > > > - Added required property reg.
> > > >
> > > > .../bindings/net/wireless/allwinner,xr819.txt | 38
> > > ++++++++++++++++++++++
> > > > 1 file changed, 38 insertions(+)
> > > > create mode 100644
> > > Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
> > >
> > > Like I asked already last time, AFAICS there is no upstream xr819
> > > wireless driver in drivers/net/wireless directory. Do we still accept
> > > bindings like this for out-of-tree drivers?
> >
> > See esp8089.
> >
> > There's also no in-tree driver for it.
>
> The question is whether we should. The above might be a precedent, but it
> may not necessarily be the way to go. The commit message for esp8089 seems
> to hint that there is intent to have an in-tree driver:
>
> """
> Note that at this point there only is an out of tree driver for this
> hardware, there is no clear timeline / path for merging this. Still
> I believe it would be good to specify the binding for this in tree
> now, so that any future migration to an in tree driver will not cause
> compatiblity issues.
>
> Cc: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> """
>
> Regardless the bindings are in principle independent of the kernel and just
> describing hardware. I think there have been discussions to move the
> bindings to their own repository, but apparently it was decided otherwise.
Yeah, I guess especially how it could be merged with the cw1200 driver
would be very relevant to that commit log.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: Icenowy Zheng @ 2017-10-04 10:15 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Arend van Spriel
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai, Rob Herring,
Kalle Valo
In-Reply-To: <20171004101145.kgjufpcktodppuy3@flea>
于 2017年10月4日 GMT+08:00 下午6:11:45, Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 写到:
>On Wed, Oct 04, 2017 at 10:02:48AM +0000, Arend van Spriel wrote:
>> On 10/4/2017 11:03 AM, Icenowy Zheng wrote:
>> >
>> >
>> > 于 2017年10月4日 GMT+08:00 下午5:02:17, Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>写到:
>> > > Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> writes:
>> > >
>> > > > Allwinner XR819 is a SDIO Wi-Fi chip, which has the
>functionality to
>> > > use
>> > > > an out-of-band interrupt pin instead of SDIO in-band interrupt.
>> > > >
>> > > > Add the device tree binding of this chip, in order to make it
>> > > possible
>> > > > to add this interrupt pin to device trees.
>> > > >
>> > > > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> > > > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> > > > ---
>> > > > Changes in v3:
>> > > > - Renames the node name.
>> > > > - Adds ACK from Rob.
>> > > > Changes in v2:
>> > > > - Removed status property in example.
>> > > > - Added required property reg.
>> > > >
>> > > > .../bindings/net/wireless/allwinner,xr819.txt | 38
>> > > ++++++++++++++++++++++
>> > > > 1 file changed, 38 insertions(+)
>> > > > create mode 100644
>> > >
>Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
>> > >
>> > > Like I asked already last time, AFAICS there is no upstream xr819
>> > > wireless driver in drivers/net/wireless directory. Do we still
>accept
>> > > bindings like this for out-of-tree drivers?
>> >
>> > See esp8089.
>> >
>> > There's also no in-tree driver for it.
>>
>> The question is whether we should. The above might be a precedent,
>but it
>> may not necessarily be the way to go. The commit message for esp8089
>seems
>> to hint that there is intent to have an in-tree driver:
>>
>> """
>> Note that at this point there only is an out of tree driver for
>this
>> hardware, there is no clear timeline / path for merging this.
>Still
>> I believe it would be good to specify the binding for this in
>tree
>> now, so that any future migration to an in tree driver will not
>cause
>> compatiblity issues.
>>
>> Cc: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> """
>>
>> Regardless the bindings are in principle independent of the kernel
>and just
>> describing hardware. I think there have been discussions to move the
>> bindings to their own repository, but apparently it was decided
>otherwise.
>
>Yeah, I guess especially how it could be merged with the cw1200 driver
>would be very relevant to that commit log.
The cw1200 driver seems to still have some legacy platform
data. Maybe they should also be convert to DT.
(Or maybe compatible = "allwinner,xr819" is enough, as
xr819 is a specified variant of cw1200 family)
>
>Maxime
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: Fw: [Bug 197099] New: Kernel panic in interrupt [l2tp_ppp]
From: Guillaume Nault @ 2017-10-04 10:33 UTC (permalink / raw)
To: James Chapman; +Cc: SviMik, netdev
In-Reply-To: <CAEwTi7SS7qsbV19NsPGwdiwTcejxygUEqQi-_MJ07uMec0CY9A@mail.gmail.com>
On Wed, Oct 04, 2017 at 08:49:51AM +0100, James Chapman wrote:
> On 3 October 2017 at 08:27, James Chapman <jchapman@katalix.com> wrote:
> > On 2 October 2017 at 19:35, SviMik <svimik@gmail.com> wrote:
> >> Hi, James!
> >>
> >> No, I'm suffering from kernel panics since I started using 4.x
> >> kernels.
> > It's interesting that you are seeing l2tp issues since switching to
> > 4.x kernels. Are you able to try earlier kernels to find the latest
> > version that works? I'm curious whether things broke at v3.15.
>
> It's possible that this may be fixed by a patch that is already
> upstream and merged for v4.14. The fix is from Guillaume Nault:
>
> f3c66d4 l2tp: prevent creation of sessions on terminated tunnels
>
> If it's possible that the L2TP server may try to create a session in a
> tunnel that is being closed, this bug would be exposed.
>
Yes, I think this patch is worth a try. In the case of sessions created
on a dead tunnel, I wouldn't have expected the xmit path to even reach
l2tp_xmit_skb() though (that's certainly possible, but the timing
constraints look a bit hard to reach).
BTW, I started working on this issue a few days ago and came to the
same conclusions as the ones you posted in your previous replies. Given
that we were in line with the analysis, I've switched to the PPP bug
reported by Beniamino (https://www.spinics.net/lists/netdev/msg458002.html).
I'll move back to L2TP as soon as possible.
^ permalink raw reply
* Re: [PATCH] rndis_host: support Novatel Verizon USB730L
From: Oliver Neukum @ 2017-10-04 10:44 UTC (permalink / raw)
To: Bjørn Mork, David Miller; +Cc: aleksander, linux-usb, netdev
In-Reply-To: <87k20cmitw.fsf@miraculix.mork.no>
Am Dienstag, den 03.10.2017, 16:01 +0200 schrieb Bjørn Mork:
> Adding anything else, e.g. based on the table at
> http://www.usb.org/developers/defined_class/#BaseClassEFh , is a bit
> more risky. We don't know if a driver will work with *any* such device
> until we've actually seen one.
>
> This is just my opinion, and probably full of bogus assumptions as
> usual. I was sort of hoping that some expert would speak up so I didn't
> have to :-)
Outside the vendors, there is nobody.
Regards
Oliver
^ permalink raw reply
* multi producer / multi consumer lock-free queue with ptr_ring
From: Jason A. Donenfeld @ 2017-10-04 11:18 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: LKML, Netdev, Samuel Holland, WireGuard mailing list
Hey Michael,
Thanks for your work on ptr_ring.h. I'm interested in using it, but in
a multi-producer, multi-consumer context. I realize it's been designed
for a single-producer, single-consumer context, and thus uses a
spinlock. I'm wondering if you'd be happy to receive patches that
implement things in a lock-free way, in order to make the data
structure more broadly usable.
In case you're curious, this would be used for the multi-core
algorithms in WireGuard.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] tools: add bpftool
From: Arnaldo Carvalho de Melo @ 2017-10-04 11:40 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, daniel, alexei.starovoitov, oss-drivers
In-Reply-To: <20171003174822.214e4337@cakuba>
Em Tue, Oct 03, 2017 at 05:48:22PM -0700, Jakub Kicinski escreveu:
> On Tue, 3 Oct 2017 17:19:42 -0300, Arnaldo Carvalho de Melo wrote:
> > Why not call it just 'bpf'?
> bpftool was suggested as a better name, I don't really mind either way.
I just thought that 'bpf' isn't used as a command, shorter, less typing,
but yeah, if people think having 'tool' in the tool name helps somewhat,
so be it.
- Arnaldo
^ permalink raw reply
* [PATCH net-next] selftests: rtnetlink: try concurrent change of ifalias
From: Florian Westphal @ 2017-10-04 11:52 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
to make sure this is serialized correctly.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
tools/testing/selftests/net/rtnetlink.sh | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/selftests/net/rtnetlink.sh
index 62c87da92770..13c29beb5769 100755
--- a/tools/testing/selftests/net/rtnetlink.sh
+++ b/tools/testing/selftests/net/rtnetlink.sh
@@ -278,6 +278,14 @@ kci_test_ifalias()
ip link show "$devdummy" | grep -q "alias $namewant"
check_fail $?
+ for i in $(seq 1 100); do
+ uuidgen > "$syspathname" &
+ done
+
+ for i in $(seq 1 100); do
+ wait
+ done
+
# re-add the alias -- kernel should free mem when dummy dev is removed
ip link set dev "$devdummy" alias "$namewant"
check_err $?
--
2.13.6
^ permalink raw reply related
* [PATCH net-next] net: core: fix kerneldoc comment
From: Florian Westphal @ 2017-10-04 11:56 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
net/core/dev.c:1306: warning: No description found for parameter 'name'
net/core/dev.c:1306: warning: Excess function parameter 'alias' description in 'dev_get_alias'
Fixes: 6c5570016b97 ("net: core: decouple ifalias get/set from rtnl lock")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 1770097cfd86..454f05441546 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1295,7 +1295,7 @@ int dev_set_alias(struct net_device *dev, const char *alias, size_t len)
/**
* dev_get_alias - get ifalias of a device
* @dev: device
- * @alias: buffer to store name of ifalias
+ * @name: buffer to store name of ifalias
* @len: size of buffer
*
* get ifalias for a device. Caller must make sure dev cannot go
--
2.13.6
^ 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