* [PATCH] Add missing descriptions for fwmark_reflect for ipv4 and ipv6.
From: Loganaden Velvindron @ 2014-10-29 17:29 UTC (permalink / raw)
To: netdev
Hi guys,
It was initially sent by Lorenzo Colitti, but was subsequently
lost in the final diff he submitted.
(It's my first time sending a diff to netdev, please let me know if
I made a mistake)
Signed-off-by: Loganaden Velvindron <logan@elandsys.com>
---
Documentation/networking/ip-sysctl.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 0307e28..a476b08 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -56,6 +56,13 @@ ip_forward_use_pmtu - BOOLEAN
0 - disabled
1 - enabled
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv4 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMP echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
@@ -1201,6 +1208,13 @@ conf/all/forwarding - BOOLEAN
proxy_ndp - BOOLEAN
Do proxy ndp.
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv6 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMPv6 echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
conf/interface/*:
Change special settings per interface.
--
1.9.1
^ permalink raw reply related
* Re: e1000_netpoll(): disable_irq() triggers might_sleep() on linux-next
From: Peter Zijlstra @ 2014-10-29 18:07 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: netdev, linux-kernel, jeffrey.t.kirsher, Thomas Gleixner
In-Reply-To: <20141029155620.GA4886@kria>
On Wed, Oct 29, 2014 at 04:56:20PM +0100, Sabrina Dubroca wrote:
> commit e22b886a8a43b ("sched/wait: Add might_sleep() checks") included
> in today's linux-next added a check that fires on e1000 with netpoll:
>
>
> BUG: sleeping function called from invalid context at kernel/irq/manage.c:104
> in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd
> no locks held by systemd/1.
> irq event stamp: 10102965
> hardirqs last enabled at (10102965): [<ffffffff810cbafd>] vprintk_emit+0x2dd/0x6a0
> hardirqs last disabled at (10102964): [<ffffffff810cb897>] vprintk_emit+0x77/0x6a0
> softirqs last enabled at (10102342): [<ffffffff810666aa>] __do_softirq+0x27a/0x6f0
> softirqs last disabled at (10102337): [<ffffffff81066e86>] irq_exit+0x56/0xe0
> Preemption disabled at:[<ffffffff817de50d>] printk_emit+0x31/0x33
>
> CPU: 1 PID: 1 Comm: systemd Not tainted 3.18.0-rc2-next-20141029-dirty #222
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140617_173321-var-lib-archbuild-testing-x86_64-tobias 04/01/2014
> ffffffff81a82291 ffff88001e743978 ffffffff817df31d 0000000000000000
> 0000000000000000 ffff88001e7439a8 ffffffff8108dfa2 ffff88001e7439a8
> ffffffff81a82291 0000000000000068 0000000000000000 ffff88001e7439d8
> Call Trace:
> [<ffffffff817df31d>] dump_stack+0x4f/0x7c
> [<ffffffff8108dfa2>] ___might_sleep+0x182/0x2b0
> [<ffffffff8108e10a>] __might_sleep+0x3a/0xc0
> [<ffffffff810ce358>] synchronize_irq+0x38/0xa0
> [<ffffffff810ce690>] disable_irq+0x20/0x30
> [<ffffffff815d7253>] e1000_netpoll+0x23/0x60
> [<ffffffff81678d02>] netpoll_poll_dev+0x72/0x3a0
> [<ffffffff816791e7>] netpoll_send_skb_on_dev+0x1b7/0x2e0
> [<ffffffff816795f3>] netpoll_send_udp+0x2e3/0x490
Oh cute.. not entirely sure what to do there. This only works if you
_know_ desc->threads_active will never be !0.
The best I can come up with is something like this, which avoids the
might_sleep() in the one special case.
Thomas?
---
kernel/irq/manage.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 0a9104b4608b..b7cb736a8b32 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -100,8 +100,11 @@ void synchronize_irq(unsigned int irq)
* running. Now verify that no threaded handlers are
* active.
*/
- wait_event(desc->wait_for_threads,
- !atomic_read(&desc->threads_active));
+ if (atomic_read(&desc->threads_active)) {
+ might_sleep();
+ __wait_event(desc->wait_for_threads,
+ !atomic_read(&desc->threads_active));
+ }
}
}
EXPORT_SYMBOL(synchronize_irq);
^ permalink raw reply related
* Re: [PATCH v3 00/15] net: dsa: Fixes and enhancements
From: Florian Fainelli @ 2014-10-29 18:22 UTC (permalink / raw)
To: Guenter Roeck, netdev; +Cc: David S. Miller, Andrew Lunn, linux-kernel
In-Reply-To: <1414604707-22407-1-git-send-email-linux@roeck-us.net>
On 10/29/2014 10:44 AM, Guenter Roeck wrote:
> Patch 01/15 addresses a bug indicated by an an annoying and unhelpful
> log message.
>
> Patches 02/15 and 03/15 are minor enhancements, adding support for
> known switch revisions.
>
> Patches 04/15 and 05/15 add support for MV88E6352 and MV88E6176.
>
> Patch 06/15 adds support for hardware monitoring, specifically for
> reporting the chip temperature, to the dsa subsystem.
>
> Patches 07/15 and 08/15 implement hardware monitoring for MV88E6352,
> MV88E6176, MV88E6123, MV88E6161, and MV88E6165.
>
> Patch 09/15 and 10/15 add support for EEPROM access to the DSA subsystem.
>
> Patch 11/15 implements EEPROM access for MV88E6352 and MV88E6176.
>
> Patch 12/15 adds support for reading switch registers to the DSA
> subsystem.
>
> Patches 13/15 amd 14/15 implement support for reading switch registers
> to the drivers for MV88E6352, MV88E6176, MV88E6123, MV88E6161, and MV88E6165.
>
> Patch 15/15 adds support for reading additional RMON registers to the drivers
> for MV88E6352, MV88E6176, MV88E6123, MV88E6161, and MV88E6165.
>
> The series was tested on top of v3.18-rc2 in an x86 system with MV88E6352.
> Testing in systems with 88E6131, 88E6060 and MV88E6165 was done earlier
> (I don't have access to those systems right now). The series was also build
> tested using my build system at http://server.roeck-us.net:8010/builders.
> Look into the 'dsa' column for build results.
>
> The series merges cleanly into net-next as of today (10/29).
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks Guenter!
>
> v3:
> - Fix bug in eeprom patches seen if devicetree is enabled:
> eeprom-length property is attached to switch devicetree node,
> not to dsa node, and there was a compile error.
> v2:
> - Made reporting chip temperatures through the hwmon subsystem optional
> with new Kconfig option
> - Changed the hwmon chip name to <network device name>_dsa<index>
> - Made EEPROM presence and size configurable through platform and devicetree
> data
> - Various minor changes and fixes (see individual patches for details)
>
> ----------------------------------------------------------------
> The following changes since commit cac7f2429872d3733dc3f9915857b1691da2eb2f:
>
> Linux 3.18-rc2 (2014-10-26 16:48:41 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git dsa
>
> for you to fetch changes up to 245472a4f3ca2a68c5632f2c37da41aa2d3fb2f0:
>
> net: dsa: Provide additional RMON statistics (2014-10-29 08:55:37 -0700)
>
> ----------------------------------------------------------------
> Guenter Roeck (15):
> net: dsa: Don't set skb->protocol on outgoing tagged packets
> net: dsa: Report known silicon revisions for Marvell 88E6060
> net: dsa: Report known silicon revisions for Marvell 88E6131
> net: dsa: Add support for Marvell 88E6352
> net: dsa/mv88e6352: Add support for MV88E6176
> net: dsa: Add support for reporting switch chip temperatures
> net: dsa/mv88e6352: Report chip temperature
> net: dsa/mv88e6123_61_65: Report chip temperature
> net: dsa: Add support for switch EEPROM access
> dsa: Add new optional devicetree property to describe EEPROM size
> net: dsa/mv88e6352: Implement EEPROM access functions
> net: dsa: Add support for reading switch registers with ethtool
> net: dsa/mv88e6123_61_65: Add support for reading switch registers
> net: dsa/mv88e6352: Add support for reading switch registers
> net: dsa: Provide additional RMON statistics
>
> Documentation/devicetree/bindings/net/dsa/dsa.txt | 9 +-
> MAINTAINERS | 5 +
> drivers/net/dsa/Kconfig | 9 +
> drivers/net/dsa/Makefile | 3 +
> drivers/net/dsa/mv88e6060.c | 5 +-
> drivers/net/dsa/mv88e6123_61_65.c | 73 +-
> drivers/net/dsa/mv88e6131.c | 12 +-
> drivers/net/dsa/mv88e6352.c | 788 ++++++++++++++++++++++
> drivers/net/dsa/mv88e6xxx.c | 53 +-
> drivers/net/dsa/mv88e6xxx.h | 15 +
> include/net/dsa.h | 33 +
> net/dsa/Kconfig | 11 +
> net/dsa/dsa.c | 135 ++++
> net/dsa/slave.c | 64 ++
> net/dsa/tag_dsa.c | 2 -
> net/dsa/tag_edsa.c | 2 -
> net/dsa/tag_trailer.c | 2 -
> 17 files changed, 1202 insertions(+), 19 deletions(-)
> create mode 100644 drivers/net/dsa/mv88e6352.c
>
^ permalink raw reply
* Re: [Patch net 1/2] sch_pie: schedule the timer after all init succeed
From: David Miller @ 2014-10-29 18:28 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, vijaynsu
In-Reply-To: <1414194959-28006-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 24 Oct 2014 16:55:58 -0700
> Cc: Vijay Subramanian <vijaynsu@cisco.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [Patch net 2/2] net_sched: always call ->destroy when ->init() fails
From: David Miller @ 2014-10-29 18:29 UTC (permalink / raw)
To: xiyou.wangcong
Cc: netdev, wang.bo116, john.r.fastabend, edumazet, kaber, vtlam
In-Reply-To: <1414194959-28006-2-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 24 Oct 2014 16:55:59 -0700
> In qdisc_create(), when ->init() exists and it fails, we should
> call ->destroy() to clean up the potentially partially initialized
> qdisc's. This will also make the ->init() implementation easier.
>
> qdisc_create_dflt() already does that. Most callers of qdisc_create_dflt()
> simply use noop_qdisc when it fails.
>
> And, most of the ->destroy() implementations are already able to clean up
> partially initialization, we don't need to worry.
>
> The following ->init()'s need to catch up:
> fq_codel_init(), hhf_init(), multiq_init(), sfq_init(), mq_init(),
> mqprio_init().
>
> Reported-by: Wang Bo <wang.bo116@zte.com.cn>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
As discussed, I really want to see ->init() clean up it's own crap.
There are certain kinds of initializations that cannot be tested for,
such as setting up a workqueue etc.
Therefore, the mere idea that we can call ->destroy() to handle this
is a pure non-starter as far as I am concerned.
Thanks.
^ permalink raw reply
* [PATCH net-next] neigh: optimize neigh_parms_release()
From: Nicolas Dichtel @ 2014-10-29 18:29 UTC (permalink / raw)
To: netdev; +Cc: davem, Nicolas Dichtel
In neigh_parms_release() we loop over all entries to find the entry given in
argument and being able to remove it from the list. By using a double linked
list, we can avoid this loop.
Here are some numbers with 30 000 dummy interfaces configured:
Before the patch:
$ time rmmod dummy
real 2m0.118s
user 0m0.000s
sys 1m50.048s
After the patch:
$ time rmmod dummy
real 1m9.970s
user 0m0.000s
sys 0m47.976s
Suggested-by: Thierry Herbelot <thierry.herbelot@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/net/neighbour.h | 3 ++-
net/core/neighbour.c | 32 +++++++++++++-------------------
2 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index f60558d0254c..dedfb188b1a7 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -69,7 +69,7 @@ struct neigh_parms {
struct net *net;
#endif
struct net_device *dev;
- struct neigh_parms *next;
+ struct list_head list;
int (*neigh_setup)(struct neighbour *);
void (*neigh_cleanup)(struct neighbour *);
struct neigh_table *tbl;
@@ -203,6 +203,7 @@ struct neigh_table {
void (*proxy_redo)(struct sk_buff *skb);
char *id;
struct neigh_parms parms;
+ struct list_head parms_list;
int gc_interval;
int gc_thresh1;
int gc_thresh2;
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index ef31fef25e5a..edd04116ecb7 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -773,7 +773,7 @@ static void neigh_periodic_work(struct work_struct *work)
if (time_after(jiffies, tbl->last_rand + 300 * HZ)) {
struct neigh_parms *p;
tbl->last_rand = jiffies;
- for (p = &tbl->parms; p; p = p->next)
+ list_for_each_entry(p, &tbl->parms_list, list)
p->reachable_time =
neigh_rand_reach_time(NEIGH_VAR(p, BASE_REACHABLE_TIME));
}
@@ -1446,7 +1446,7 @@ static inline struct neigh_parms *lookup_neigh_parms(struct neigh_table *tbl,
{
struct neigh_parms *p;
- for (p = &tbl->parms; p; p = p->next) {
+ list_for_each_entry(p, &tbl->parms_list, list) {
if ((p->dev && p->dev->ifindex == ifindex && net_eq(neigh_parms_net(p), net)) ||
(!p->dev && !ifindex && net_eq(net, &init_net)))
return p;
@@ -1481,8 +1481,7 @@ struct neigh_parms *neigh_parms_alloc(struct net_device *dev,
}
write_lock_bh(&tbl->lock);
- p->next = tbl->parms.next;
- tbl->parms.next = p;
+ list_add(&p->list, &tbl->parms.list);
write_unlock_bh(&tbl->lock);
neigh_parms_data_state_cleanall(p);
@@ -1501,24 +1500,15 @@ static void neigh_rcu_free_parms(struct rcu_head *head)
void neigh_parms_release(struct neigh_table *tbl, struct neigh_parms *parms)
{
- struct neigh_parms **p;
-
if (!parms || parms == &tbl->parms)
return;
write_lock_bh(&tbl->lock);
- for (p = &tbl->parms.next; *p; p = &(*p)->next) {
- if (*p == parms) {
- *p = parms->next;
- parms->dead = 1;
- write_unlock_bh(&tbl->lock);
- if (parms->dev)
- dev_put(parms->dev);
- call_rcu(&parms->rcu_head, neigh_rcu_free_parms);
- return;
- }
- }
+ list_del(&parms->list);
+ parms->dead = 1;
write_unlock_bh(&tbl->lock);
- neigh_dbg(1, "%s: not found\n", __func__);
+ if (parms->dev)
+ dev_put(parms->dev);
+ call_rcu(&parms->rcu_head, neigh_rcu_free_parms);
}
EXPORT_SYMBOL(neigh_parms_release);
@@ -1535,6 +1525,8 @@ static void neigh_table_init_no_netlink(struct neigh_table *tbl)
unsigned long now = jiffies;
unsigned long phsize;
+ INIT_LIST_HEAD(&tbl->parms_list);
+ list_add(&tbl->parms.list, &tbl->parms_list);
write_pnet(&tbl->parms.net, &init_net);
atomic_set(&tbl->parms.refcnt, 1);
tbl->parms.reachable_time =
@@ -2154,7 +2146,9 @@ static int neightbl_dump_info(struct sk_buff *skb, struct netlink_callback *cb)
NLM_F_MULTI) <= 0)
break;
- for (nidx = 0, p = tbl->parms.next; p; p = p->next) {
+ nidx = 0;
+ p = list_next_entry(&tbl->parms, list);
+ list_for_each_entry_from(p, &tbl->parms_list, list) {
if (!net_eq(neigh_parms_net(p), net))
continue;
--
2.1.0
^ permalink raw reply related
* Re: e1000_netpoll(): disable_irq() triggers might_sleep() on linux-next
From: Thomas Gleixner @ 2014-10-29 18:33 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Sabrina Dubroca, netdev, linux-kernel, jeffrey.t.kirsher
In-Reply-To: <20141029180734.GQ12706@worktop.programming.kicks-ass.net>
On Wed, 29 Oct 2014, Peter Zijlstra wrote:
> On Wed, Oct 29, 2014 at 04:56:20PM +0100, Sabrina Dubroca wrote:
> > commit e22b886a8a43b ("sched/wait: Add might_sleep() checks") included
> > in today's linux-next added a check that fires on e1000 with netpoll:
> >
> >
> > BUG: sleeping function called from invalid context at kernel/irq/manage.c:104
> > in_atomic(): 1, irqs_disabled(): 1, pid: 1, name: systemd
> > no locks held by systemd/1.
> > irq event stamp: 10102965
> > hardirqs last enabled at (10102965): [<ffffffff810cbafd>] vprintk_emit+0x2dd/0x6a0
> > hardirqs last disabled at (10102964): [<ffffffff810cb897>] vprintk_emit+0x77/0x6a0
> > softirqs last enabled at (10102342): [<ffffffff810666aa>] __do_softirq+0x27a/0x6f0
> > softirqs last disabled at (10102337): [<ffffffff81066e86>] irq_exit+0x56/0xe0
> > Preemption disabled at:[<ffffffff817de50d>] printk_emit+0x31/0x33
> >
> > CPU: 1 PID: 1 Comm: systemd Not tainted 3.18.0-rc2-next-20141029-dirty #222
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140617_173321-var-lib-archbuild-testing-x86_64-tobias 04/01/2014
> > ffffffff81a82291 ffff88001e743978 ffffffff817df31d 0000000000000000
> > 0000000000000000 ffff88001e7439a8 ffffffff8108dfa2 ffff88001e7439a8
> > ffffffff81a82291 0000000000000068 0000000000000000 ffff88001e7439d8
> > Call Trace:
> > [<ffffffff817df31d>] dump_stack+0x4f/0x7c
> > [<ffffffff8108dfa2>] ___might_sleep+0x182/0x2b0
> > [<ffffffff8108e10a>] __might_sleep+0x3a/0xc0
> > [<ffffffff810ce358>] synchronize_irq+0x38/0xa0
> > [<ffffffff810ce690>] disable_irq+0x20/0x30
> > [<ffffffff815d7253>] e1000_netpoll+0x23/0x60
> > [<ffffffff81678d02>] netpoll_poll_dev+0x72/0x3a0
> > [<ffffffff816791e7>] netpoll_send_skb_on_dev+0x1b7/0x2e0
> > [<ffffffff816795f3>] netpoll_send_udp+0x2e3/0x490
>
> Oh cute.. not entirely sure what to do there. This only works if you
> _know_ desc->threads_active will never be !0.
>
> The best I can come up with is something like this, which avoids the
> might_sleep() in the one special case.
>
> Thomas?
Yuck. No. You are just papering over the problem.
What happens if you add 'threadirqs' to the kernel command line? Or if
the interrupt line is shared with a real threaded interrupt user?
The proper solution is to have a poll_lock for e1000 which serializes
the hardware interrupt against netpoll instead of using
disable/enable_irq().
In fact that's less expensive than the disable/enable_irq() dance and
the chance of contention is pretty low. If done right it will be a
NOOP for the CONFIG_NET_POLL_CONTROLLER=n case.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] Add flow control support flags to gianfar's capabilities
From: David Miller @ 2014-10-29 18:33 UTC (permalink / raw)
To: matei.pavaluca; +Cc: netdev, claudiu.manoil
In-Reply-To: <1414399364-22308-1-git-send-email-matei.pavaluca@freescale.com>
From: Matei Pavaluca <matei.pavaluca@freescale.com>
Date: Mon, 27 Oct 2014 10:42:42 +0200
> From: Pavaluca Matei-B46610 <matei.pavaluca@freescale.com>
>
> The phy device supports 802.3x flow control, but the specific flags are not set
> in the phy initialisation code. Flow control flags need to be added to the
> supported capabilities of the phydev by the driver.
>
> This is needed in order for ethtool to work ('ethtool -A' code checks for these
> flags)
>
> Signed-off-by: Pavaluca Matei <matei.pavaluca@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] Fix the way the local advertising flow options are determined
From: David Miller @ 2014-10-29 18:33 UTC (permalink / raw)
To: matei.pavaluca; +Cc: netdev, claudiu.manoil
In-Reply-To: <1414399364-22308-2-git-send-email-matei.pavaluca@freescale.com>
From: Matei Pavaluca <matei.pavaluca@freescale.com>
Date: Mon, 27 Oct 2014 10:42:43 +0200
> From: Pavaluca Matei-B46610 <matei.pavaluca@freescale.com>
>
> Local flow control options needed in order to resolve the negotiation
> are incorrectly calculated.
>
> Previously 'mii_advertise_flowctrl' was called to determine the local advertising
> options, but these were determined based on FLOW_CTRL_RX/TX flags which are
> never set through ethtool.
> The patch simply translates from ethtool flow options to mii flow options.
>
> Signed-off-by: Pavaluca Matei <matei.pavaluca@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] gianfar: Implement PAUSE frame generation support
From: David Miller @ 2014-10-29 18:34 UTC (permalink / raw)
To: matei.pavaluca; +Cc: netdev, claudiu.manoil
In-Reply-To: <1414399364-22308-3-git-send-email-matei.pavaluca@freescale.com>
From: Matei Pavaluca <matei.pavaluca@freescale.com>
Date: Mon, 27 Oct 2014 10:42:44 +0200
> The hardware can automatically generate pause frames when the number
> of free buffers drops under a certain threshold, but in order to do this,
> the address of the last free buffer needs to be written to a specific
> register for each RX queue.
>
> This has to be done in 'gfar_clean_rx_ring' which is called for each
> RX queue. In order not to impact performance, by adding a register write
> for each incoming packet, this operation is done only when the PAUSE frame
> transmission is enabled.
>
> Whenever the link is readjusted, this capability is turned on or off.
>
> Signed-off-by: Matei Pavaluca <matei.pavaluca@freescale.com>
Applied.
But I would turn pause frames on by default, and deal with the
"performance" issue by aggregating the register writes. Only
do it every N cleaned frames.
^ permalink raw reply
* Re: [PATCH v3] ipv6: notify userspace when we added or changed an ipv6 token
From: David Miller @ 2014-10-29 18:35 UTC (permalink / raw)
To: lkundrak; +Cc: netdev, hannes, dborkman
In-Reply-To: <1414427956-20056-1-git-send-email-lkundrak@v3.sk>
From: Lubomir Rintel <lkundrak@v3.sk>
Date: Mon, 27 Oct 2014 17:39:16 +0100
> NetworkManager might want to know that it changed when the router advertisement
> arrives.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 6/9] ARM: berlin: Add BG2 ethernet DT nodes
From: Sebastian Hesselbarth @ 2014-10-29 18:38 UTC (permalink / raw)
Cc: David S. Miller, Antoine Ténart, Florian Fainelli, Eric Miao,
Haojian Zhuang, linux-arm-kernel, netdev, devicetree,
linux-kernel
In-Reply-To: <1414002412-13615-7-git-send-email-sebastian.hesselbarth@gmail.com>
On 22.10.2014 20:26, Sebastian Hesselbarth wrote:
> Marvell BG2 has two fast ethernet controllers with internal PHY,
> add the corresponding nodes to SoC dtsi.
>
> Tested-by: Antoine Ténart <antoine.tenart@free-electrons.com>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Applied the four DT patches to berlin/dt.
Sebastian
> ---
> Changelog:
> v1->v2:
> - move phy-connection-type to controller node instead of PHY node
> (Reported by Sergei Shtylyov)
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: "Antoine Ténart" <antoine.tenart@free-electrons.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: netdev@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/berlin2.dtsi | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
> index 9d7c810ebd0b..dc0227dfc691 100644
> --- a/arch/arm/boot/dts/berlin2.dtsi
> +++ b/arch/arm/boot/dts/berlin2.dtsi
> @@ -79,11 +79,47 @@
> clocks = <&chip CLKID_TWD>;
> };
>
> + eth1: ethernet@b90000 {
> + compatible = "marvell,pxa168-eth";
> + reg = <0xb90000 0x10000>;
> + clocks = <&chip CLKID_GETH1>;
> + interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
> + /* set by bootloader */
> + local-mac-address = [00 00 00 00 00 00];
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy-connection-type = "mii";
> + phy-handle = <ðphy1>;
> + status = "disabled";
> +
> + ethphy1: ethernet-phy@0 {
> + reg = <0>;
> + };
> + };
> +
> cpu-ctrl@dd0000 {
> compatible = "marvell,berlin-cpu-ctrl";
> reg = <0xdd0000 0x10000>;
> };
>
> + eth0: ethernet@e50000 {
> + compatible = "marvell,pxa168-eth";
> + reg = <0xe50000 0x10000>;
> + clocks = <&chip CLKID_GETH0>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + /* set by bootloader */
> + local-mac-address = [00 00 00 00 00 00];
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy-connection-type = "mii";
> + phy-handle = <ðphy0>;
> + status = "disabled";
> +
> + ethphy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> + };
> +
> apb@e80000 {
> compatible = "simple-bus";
> #address-cells = <1>;
>
^ permalink raw reply
* Re: [PATCH net-next] net: skb_segment() should preserve backpressure
From: David Miller @ 2014-10-29 18:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: makita.toshiaki, netdev, herbert
In-Reply-To: <1414431051.16231.23.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 27 Oct 2014 10:30:51 -0700
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> This patch generalizes commit d6a4a1041176 ("tcp: GSO should be TSQ
> friendly") to protocols using skb_set_owner_w()
>
> TCP uses its own destructor (tcp_wfree) and needs a more complex scheme
> as explained in commit 6ff50cd55545 ("tcp: gso: do not generate out of
> order packets")
>
> This allows UDP sockets using UFO to get proper backpressure,
> thus avoiding qdisc drops and excessive cpu usage.
>
> Here are performance test results (macvlan on vlan):
...
> [edumazet] Rewrote patch and changelog.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net] cxgb4vf: Replace repetitive pci device ID's with right ones
From: David Miller @ 2014-10-29 18:48 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, kumaras, nirranjan, santosh, anish
In-Reply-To: <1414432330-12130-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Mon, 27 Oct 2014 23:22:10 +0530
> Replaced repetive Device ID's which got added in commit b961f9a48844ecf3
> ("cxgb4vf: Remove superfluous "idx" parameter of CH_DEVICE() macro")
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: smc91x: Fix gpios for device tree based booting
From: David Miller @ 2014-10-29 18:51 UTC (permalink / raw)
To: tony; +Cc: netdev, devicetree, linux-omap, khilman
In-Reply-To: <20141027202556.GT2560@atomide.com>
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 27 Oct 2014 13:25:56 -0700
> +/**
> + * of_try_set_control_gpio - configure a gpio if it exists
> + */
> +static int try_toggle_control_gpio(struct device *dev,
> + struct gpio_desc **desc,
> + const char *name, int index,
> + int value, unsigned int nsdelay)
This needs to be under CONFIG_OF cpp protection just like the code that
calls it.
^ permalink raw reply
* Re: [PATCH net-next] neigh: optimize neigh_parms_release()
From: Eric Dumazet @ 2014-10-29 19:01 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem
In-Reply-To: <1414607371-4246-1-git-send-email-nicolas.dichtel@6wind.com>
On Wed, 2014-10-29 at 19:29 +0100, Nicolas Dichtel wrote:
> In neigh_parms_release() we loop over all entries to find the entry given in
> argument and being able to remove it from the list. By using a double linked
> list, we can avoid this loop.
Acked-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [RFC] ipv4: Do not cache routing failures due to disabled forwarding.
From: David Miller @ 2014-10-29 19:03 UTC (permalink / raw)
To: nicolas.cavallari; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <1410531260-13794-2-git-send-email-nicolas.cavallari@green-communications.fr>
From: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Date: Fri, 12 Sep 2014 16:14:20 +0200
> If we cache them, the kernel will reuse them, independently of
> whether forwarding is enabled or not. Which means that if forwarding is
> disabled on the input interface where the first routing request comes
> from, then that unreachable result will be cached and reused for
> other interfaces, even if forwarding is enabled on them.
>
> This can be verified with two interfaces A and B and an output interface
> C, where B has forwarding enabled, but not A and trying
> ip route get $dst iif A from $src && ip route get $dst iif B from $src
>
> Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
> ---
> based on net-next, but not really tested on top of it.
Sorry Nicolas, this seems to have fallen on the floor. Could you please
resubmit your most uptodate version of this patch so I can apply it?
Thanks.
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: realtek: atp: checkpatch errors and warnings corrected
From: David Miller @ 2014-10-29 19:05 UTC (permalink / raw)
To: robertoxmed; +Cc: netdev, linux-kernel
In-Reply-To: <1414453916-27976-1-git-send-email-robertoxmed@gmail.com>
From: Roberto Medina <robertoxmed@gmail.com>
Date: Tue, 28 Oct 2014 00:51:56 +0100
> From: Roberto Medina <robertoxmed@gmail.com>
>
> Several warnings and errors of coding style rules corrected.
> Compile tested.
>
> Signed-off-by: Roberto Medina <robertoxmed@gmail.com>
Applied, thanks.
^ permalink raw reply
* PATCH: Add IFF_ALLMULTI support to cpsw (and fix IFF_PROMISC support too)
From: Lennart Sorensen @ 2014-10-29 19:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Len Sorensen, Mugunthan V N, David S. Miller, netdev
The cpsw driver did not support the IFF_ALLMULTI flag which makes dynamic
multicast routing rather hard to handle. Related to this, when enabling
IFF_PROMISC in non dual_emac mode, all registered vlans are flushed,
and only broadcast and unicast are allowed which isn't what you would
want from IFF_PROMISC.
A new cpsw_ale_set_allmulti function now scans through the ALE entry
table and adds or removes the host port from the unregistered multicast
port mask depending on the state of IFF_ALLMULTI. In promisc mode,
it is also called to enable reception of all multicast traffic.
With this change I am now able to run dynamic multicast routing and also
use tcpdump and actually see multicast traffic.
Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 952e1e4..96a61d1 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -638,12 +638,16 @@ static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
if (ndev->flags & IFF_PROMISC) {
/* Enable promiscuous mode */
cpsw_set_promiscious(ndev, true);
+ cpsw_ale_set_allmulti(priv->ale, IFF_ALLMULTI);
return;
} else {
/* Disable promiscuous mode */
cpsw_set_promiscious(ndev, false);
}
+ /* Restore allmulti on vlans if necessary */
+ cpsw_ale_set_allmulti(priv->ale, priv->ndev->flags & IFF_ALLMULTI);
+
/* Clear all mcast from ALE */
cpsw_ale_flush_multicast(priv->ale, ALE_ALL_PORTS << priv->host_port);
@@ -1149,6 +1153,7 @@ static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
const int port = priv->host_port;
u32 reg;
int i;
+ int unreg_mcast_mask;
reg = (priv->version == CPSW_VERSION_1) ? CPSW1_PORT_VLAN :
CPSW2_PORT_VLAN;
@@ -1158,9 +1163,14 @@ static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
for (i = 0; i < priv->data.slaves; i++)
slave_write(priv->slaves + i, vlan, reg);
+ if (priv->ndev->flags & IFF_ALLMULTI)
+ unreg_mcast_mask = ALE_ALL_PORTS;
+ else
+ unreg_mcast_mask = ALE_PORT_1 | ALE_PORT_2;
+
cpsw_ale_add_vlan(priv->ale, vlan, ALE_ALL_PORTS << port,
ALE_ALL_PORTS << port, ALE_ALL_PORTS << port,
- (ALE_PORT_1 | ALE_PORT_2) << port);
+ unreg_mcast_mask << port);
}
static void cpsw_init_host_port(struct cpsw_priv *priv)
@@ -1620,11 +1630,17 @@ static inline int cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
unsigned short vid)
{
int ret;
+ int unreg_mcast_mask;
+
+ if (priv->ndev->flags & IFF_ALLMULTI)
+ unreg_mcast_mask = ALE_ALL_PORTS;
+ else
+ unreg_mcast_mask = ALE_PORT_1 | ALE_PORT_2;
ret = cpsw_ale_add_vlan(priv->ale, vid,
ALE_ALL_PORTS << priv->host_port,
0, ALE_ALL_PORTS << priv->host_port,
- (ALE_PORT_1 | ALE_PORT_2) << priv->host_port);
+ unreg_mcast_mask << priv->host_port);
if (ret != 0)
return ret;
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
index 0579b22..3ae8387 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -443,6 +443,35 @@ int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port_mask)
return 0;
}
+void cpsw_ale_set_allmulti(struct cpsw_ale *ale, int allmulti)
+{
+ u32 ale_entry[ALE_ENTRY_WORDS];
+ int type, idx;
+ int unreg_mcast = 0;
+
+ /* Only bother doing the work if the setting is actually changing */
+ if (ale->allmulti == allmulti)
+ return;
+
+ /* Remember the new setting to check against next time */
+ ale->allmulti = allmulti;
+
+ for (idx = 0; idx < ale->params.ale_entries; idx++) {
+ cpsw_ale_read(ale, idx, ale_entry);
+ type = cpsw_ale_get_entry_type(ale_entry);
+ if (type != ALE_TYPE_VLAN)
+ continue;
+
+ unreg_mcast = cpsw_ale_get_vlan_unreg_mcast(ale_entry);
+ if (allmulti)
+ unreg_mcast |= 1;
+ else
+ unreg_mcast &= ~1;
+ cpsw_ale_set_vlan_unreg_mcast(ale_entry, unreg_mcast);
+ cpsw_ale_write(ale, idx, ale_entry);
+ }
+}
+
struct ale_control_info {
const char *name;
int offset, port_offset;
diff --git a/drivers/net/ethernet/ti/cpsw_ale.h b/drivers/net/ethernet/ti/cpsw_ale.h
index 31cf43c..c0d4127 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.h
+++ b/drivers/net/ethernet/ti/cpsw_ale.h
@@ -27,6 +27,7 @@ struct cpsw_ale {
struct cpsw_ale_params params;
struct timer_list timer;
unsigned long ageout;
+ int allmulti;
};
enum cpsw_ale_control {
@@ -103,6 +104,7 @@ int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
int reg_mcast, int unreg_mcast);
int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port);
+void cpsw_ale_set_allmulti(struct cpsw_ale *ale, int allmulti);
int cpsw_ale_control_get(struct cpsw_ale *ale, int port, int control);
int cpsw_ale_control_set(struct cpsw_ale *ale, int port,
--
Len Sorensen
^ permalink raw reply related
* Re: [PATCH net-next] tcp: allow for bigger reordering level
From: David Miller @ 2014-10-29 19:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, wygivan
In-Reply-To: <1414471524.13259.14.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 27 Oct 2014 21:45:24 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> While testing upcoming Yaogong patch (converting out of order queue
> into an RB tree), I hit the max reordering level of linux TCP stack.
>
> Reordering level was limited to 127 for no good reason, and some
> network setups [1] can easily reach this limit and get limited
> throughput.
>
> Allow a new max limit of 300, and add a sysctl to allow admins to even
> allow bigger (or lower) values if needed.
>
> [1] Aggregation of links, per packet load balancing, fabrics not doing
> deep packet inspections, alternative TCP congestion modules...
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
I'll apply this, thanks.
However in the longer term I'd say that this value, if it is to have a
limit, then such a limit should probably be scaled based upon the
window size.
^ permalink raw reply
* Re: [PATCH net 1/1] cnic: Update the rcu_access_pointer() usages
From: David Miller @ 2014-10-29 19:07 UTC (permalink / raw)
To: nilesh.javali
Cc: netdev, Dept-GELinuxNICDev, sudarsana.kalluru, vikas.chaudhary,
giridhar.malavali, tej.parkash
In-Reply-To: <1414473495-24790-2-git-send-email-nilesh.javali@qlogic.com>
From: Nilesh Javali <nilesh.javali@qlogic.com>
Date: Tue, 28 Oct 2014 01:18:15 -0400
> From: Tej Parkash <tej.parkash@qlogic.com>
>
> 1. Remove the rcu_read_lock/unlock around rcu_access_pointer
> 2. Replace the rcu_dereference with rcu_access_pointer
>
> Signed-off-by: Tej Parkash <tej.parkash@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] r8152: support nway_reset
From: David Miller @ 2014-10-29 19:10 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-66-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Tue, 28 Oct 2014 14:05:50 +0800
> Fix the CHECK from checkpatch.pl and support nway_reset.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: David Miller @ 2014-10-29 19:12 UTC (permalink / raw)
To: ek; +Cc: netdev, ben, lorenzo, hannes
In-Reply-To: <1414487474-18201-1-git-send-email-ek@google.com>
From: Erik Kline <ek@google.com>
Date: Tue, 28 Oct 2014 18:11:14 +0900
> Add a sysctl that causes an interface's optimistic addresses
> to be considered equivalent to other non-deprecated addresses
> for source address selection purposes. Preferred addresses
> will still take precedence over optimistic addresses, subject
> to other ranking in the source address selection algorithm.
>
> This is useful where different interfaces are connected to
> different networks from different ISPs (e.g., a cell network
> and a home wifi network).
>
> The current behaviour complies with RFC 3484/6724, and it
> makes sense if the host has only one interface, or has
> multiple interfaces on the same network (same or cooperating
> administrative domain(s), but not in the multiple distinct
> networks case.
>
> For example, if a mobile device has an IPv6 address on an LTE
> network and then connects to IPv6-enabled wifi, while the wifi
> IPv6 address is undergoing DAD, IPv6 connections will try use
> the wifi default route with the LTE IPv6 address, and will get
> stuck until they time out.
>
> Also, because optimistic nodes can receive frames, issue
> an RTM_NEWADDR as soon as DAD starts (with the IFA_F_OPTIMSTIC
> flag appropriately set). A second RTM_NEWADDR is sent if DAD
> completes (the address flags have changed), otherwise an
> RTM_DELADDR is sent.
>
> Also: add an entry in ip-sysctl.txt for optimistic_dad.
>
> Signed-off-by: Erik Kline <ek@google.com>
Applied, if the idev != NULL check proves to be unnecessary we can
kill it in a follow-on patch.
Thanks.
^ permalink raw reply
* Re: [net 1/2] sctp: add transport state in /proc/net/sctp/remaddr
From: David Miller @ 2014-10-29 19:18 UTC (permalink / raw)
To: nhorman; +Cc: michele, linux-sctp, vyasevich, netdev, dborkman
In-Reply-To: <20141028102741.GA18365@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 28 Oct 2014 06:27:41 -0400
> On Mon, Oct 27, 2014 at 06:55:45PM -0400, David Miller wrote:
>> From: Michele Baldessari <michele@acksyn.org>
>> Date: Thu, 23 Oct 2014 21:48:40 +0200
>>
>> > It is often quite helpful to be able to know the state of a transport
>> > outside of the application itself (for troubleshooting purposes or for
>> > monitoring purposes). Add it under /proc/net/sctp/remaddr.
>> >
>> > Signed-off-by: Michele Baldessari <michele@acksyn.org>
>>
>> You can't change the layout of procfs files, applications parse
>> these files and any modification can potentially break such tools.
>>
>> Secondly, even if this change were acceptable, targetting this
>> change at anything other than the net-next tree is not appropriate
>> because it is a new feature.
>>
>
> Agree on the net-next submission, though there is precident for extending this
> procfile, as we've done it a few times in the past to this, and other files in
> the sctp area (see commits f406c8b9693f2f71ef2caeb0b68521a7d22d00f0 and
> 58fbbed4fbc0094fc808a568fe99a915f85402ee)
Fair enough.
^ permalink raw reply
* Re: [PATCH 6/7] can: m_can: update to support CAN FD features
From: Oliver Hartkopp @ 2014-10-29 19:21 UTC (permalink / raw)
To: Dong Aisheng, linux-can; +Cc: mkl, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <1414579527-31100-6-git-send-email-b29396@freescale.com>
Hello Dong,
thanks for your update to support CAN FD with the 3.0.x M_CAN IP core.
AFAIK from the last CAN in Automation (CiA) Plugfest which took place in
Nuremberg yesterday, there are two more IP cores on the way:
v3.0.1 / v3.0.2 (the current spec from the Bosch website)
v3.1.0 which will support per-frame CAN/CANFD switching in the tx path
(the FDF/(former)EDL bit and the BRS bit appear in the TX buffer element at
the bit position you know from reading the RX FIFO element)
v3.2.0 which will support the final(?) ISO specification with a bitstuffing
counter before the CRC in the frame on the wire.
So first I would suggest to check the core release register (CREL) to be
version 3.0.x and quit the driver initialization if it doesn't fit this
version. I would suggest to provide a separate patch for that check. What
about printing the core release version into the kernel log at driver
initialization time?
Regarding the CAN FD support in this patch I have some remarks in the text ...
On 10/29/2014 11:45 AM, Dong Aisheng wrote:
> /* Rx Buffer Element */
> +/* R0 */
> #define RX_BUF_ESI BIT(31)
> #define RX_BUF_XTD BIT(30)
> #define RX_BUF_RTR BIT(29)
> +/* R1 */
> +#define RX_BUF_ANMF BIT(31)
> +#define RX_BUF_EDL BIT(21)
> +#define RX_BUF_BRS BIT(20)
>
> /* Tx Buffer Element */
> +/* R0 */
> #define TX_BUF_XTD BIT(30)
> #define TX_BUF_RTR BIT(29)
>
> @@ -327,11 +357,12 @@ static inline void m_can_disable_all_interrupts(const struct m_can_priv *priv)
> m_can_write(priv, M_CAN_ILE, 0x0);
> }
>
> -static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
> +static void m_can_read_fifo(const struct net_device *dev, struct canfd_frame *cf,
> u32 rxfs)
> {
> struct m_can_priv *priv = netdev_priv(dev);
> u32 id, fgi;
> + int i;
>
> /* calculate the fifo get index for where to read data */
> fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
> @@ -341,15 +372,23 @@ static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
> else
> cf->can_id = (id >> 18) & CAN_SFF_MASK;
>
> + if (id & RX_BUF_ESI) {
> + cf->flags |= CANFD_ESI;
> + netdev_dbg(dev, "ESI Error\n");
> + }
> +
> if (id & RX_BUF_RTR) {
> cf->can_id |= CAN_RTR_FLAG;
When RX_BUF_EDL is set you should not check for RX_BUF_RTR as RTR is not
allowed for CAN FD.
> } else {
> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
> - cf->can_dlc = get_can_dlc((id >> 16) & 0x0F);
> - *(u32 *)(cf->data + 0) = m_can_fifo_read(priv, fgi,
> - M_CAN_FIFO_DATA(0));
> - *(u32 *)(cf->data + 4) = m_can_fifo_read(priv, fgi,
> - M_CAN_FIFO_DATA(1));
> + cf->len = can_dlc2len(get_canfd_dlc((id >> 16) & 0x0F));
> +
> + if (id & RX_BUF_BRS)
> + cf->flags |= CANFD_BRS;
> +
> + for (i = 0; i < cf->len; i += 4)
> + *(u32 *)(cf->data + i) =
> + m_can_fifo_read(priv, fgi, M_CAN_FIFO_DATA(i / 4));
> }
>
> /* acknowledge rx fifo 0 */
> @@ -361,7 +400,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
> struct m_can_priv *priv = netdev_priv(dev);
> struct net_device_stats *stats = &dev->stats;
> struct sk_buff *skb;
> - struct can_frame *frame;
> + struct canfd_frame *frame;
> u32 pkts = 0;
> u32 rxfs;
>
> @@ -375,7 +414,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
> if (rxfs & RXFS_RFL)
> netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
>
> - skb = alloc_can_skb(dev, &frame);
> + skb = alloc_canfd_skb(dev, &frame);
You are *always* allocating CAN FD frames now?
Depending on RX_BUF_EDL in the RX FIFO message you should create a CAN or CAN
FD frame.
Of course you can use the struct canfd_frame in m_can_read_fifo() as the
layout of the struct can_frame is identical when filled with 'normal' CAN
frame content.
But you need to distinguish whether it is a CAN or CAN FD frame when
allocating the skb based on the RX_BUF_EDL value.
> if (!skb) {
> stats->rx_dropped++;
> return pkts;
> @@ -384,7 +423,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
> m_can_read_fifo(dev, frame, rxfs);
>
> stats->rx_packets++;
> - stats->rx_bytes += frame->can_dlc;
> + stats->rx_bytes += frame->len;
>
> netif_receive_skb(skb);
>
The rest of your entire patch set looks very good from my perspective.
Best regards,
Oliver
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox