* [PATCH 0/8] Implement NAPI in et131x
From: Mark Einon @ 2014-08-20 22:17 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, linux-kernel, Mark Einon
Let's put a NAPI on this baby...
NAPI support was identified by Dave Miller <davem@davemloft.net> as a
must to get this driver out of staging. This patchset first tidies up
the code enough to make adding NAPI easier, and the final patch mostly
adds the 'boilerplate' NAPI code as described by:
http://www.linuxfoundation.org/collaborate/workgroups/networking/napi
The code has been tested on hardware, with no issues found to date.
**GregKH** - this patchset is based upon my previous bugfix 'Fix errors
caused by phydev->addr accesses' which is currently only on your
staging-linus branch, not staging-next - so won't apply cleanly in it's
current state. Please let me know if I need to do anything about this.
Cheers,
Mark
---
Mark Einon (8):
staging: et131x: Use eth_mac_addr() instead of duplicating the
functionality
staging: et131x: Don't handle rx/tx packets when changing mtu
staging: et131x: Use for loop to initialise contiguous registers to
zero
staging: et131x: Use for loop to initialise contiguous macstat
registers to zero
staging: et131x: Remove unnecessary i2c_wack variable
staging: et131x: Rename NUM_PACKETS_HANDLED to MAX_PACKETS_HANDLED
staging: et131x: Fix ET_INTR_TXDMA_ISR register name typo
staging: et131x: Implement NAPI support
drivers/staging/et131x/README | 1 -
drivers/staging/et131x/et131x.c | 271 ++++++++++------------------------------
drivers/staging/et131x/et131x.h | 96 +-------------
3 files changed, 69 insertions(+), 299 deletions(-)
--
2.1.0
^ permalink raw reply
* pktgen and tos
From: Ben Greear @ 2014-08-20 21:52 UTC (permalink / raw)
To: netdev@vger.kernel.org
Here's a half-arsed bug report, in case someone is bored.
At least in my hacked up pktgen, you cannot set a one-digit tos,
because the parser fails if length is not 2 digits.
echo tos 4 > /proc/net/pktgen/rddVR2 && cat /proc/net/pktgen/rddVR2
...
Result: ERROR: tos must be 00-ff
If you use '04' instead, it works. In my case, it will be easier to hack user-space
to deal with this than fix pktgen, but I thought someone might want to fix it proper.
Also, could be that upstream code doesn't have this limitation...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH net v2] cxgb4: Fix race condition in cleanup
From: Anish Bhatt @ 2014-08-20 20:44 UTC (permalink / raw)
To: netdev; +Cc: davem, hariprasad, leedom, svemuri, nhorman, Anish Bhatt
There is a possible race condition when we unregister the PCI Driver and then
flush/destroy the global "workq". This could lead to situations where there
are tasks on the Work Queue with references to now deleted adapter data
structures. Instead, have per-adapter Work Queues which were instantiated and
torn down in init_one() and remove_one(), respectively.
v2: Remove unnecessary call to flush_workqueue() before destroy_workqueue()
Signed-off-by: Anish Bhatt <anish@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 32 ++++++++++++++-----------
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index d572821..c067b78 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -652,6 +652,7 @@ struct adapter {
struct tid_info tids;
void **tid_release_head;
spinlock_t tid_release_lock;
+ struct workqueue_struct *workq;
struct work_struct tid_release_task;
struct work_struct db_full_task;
struct work_struct db_drop_task;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 1afee70..18fb9c6 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -643,8 +643,6 @@ static int set_rxmode(struct net_device *dev, int mtu, bool sleep_ok)
return ret;
}
-static struct workqueue_struct *workq;
-
/**
* link_start - enable a port
* @dev: the port to enable
@@ -3340,7 +3338,7 @@ static void cxgb4_queue_tid_release(struct tid_info *t, unsigned int chan,
adap->tid_release_head = (void **)((uintptr_t)p | chan);
if (!adap->tid_release_task_busy) {
adap->tid_release_task_busy = true;
- queue_work(workq, &adap->tid_release_task);
+ queue_work(adap->workq, &adap->tid_release_task);
}
spin_unlock_bh(&adap->tid_release_lock);
}
@@ -4140,7 +4138,7 @@ void t4_db_full(struct adapter *adap)
notify_rdma_uld(adap, CXGB4_CONTROL_DB_FULL);
t4_set_reg_field(adap, SGE_INT_ENABLE3,
DBFIFO_HP_INT | DBFIFO_LP_INT, 0);
- queue_work(workq, &adap->db_full_task);
+ queue_work(adap->workq, &adap->db_full_task);
}
}
@@ -4150,7 +4148,7 @@ void t4_db_dropped(struct adapter *adap)
disable_dbs(adap);
notify_rdma_uld(adap, CXGB4_CONTROL_DB_FULL);
}
- queue_work(workq, &adap->db_drop_task);
+ queue_work(adap->workq, &adap->db_drop_task);
}
static void uld_attach(struct adapter *adap, unsigned int uld)
@@ -6517,6 +6515,12 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
goto out_disable_device;
}
+ adapter->workq = create_singlethread_workqueue("cxgb4");
+ if (!adapter->workq) {
+ err = -ENOMEM;
+ goto out_free_adapter;
+ }
+
/* PCI device has been enabled */
adapter->flags |= DEV_ENABLED;
@@ -6715,6 +6719,9 @@ sriov:
out_unmap_bar0:
iounmap(adapter->regs);
out_free_adapter:
+ if (adapter->workq)
+ destroy_workqueue(adapter->workq);
+
kfree(adapter);
out_disable_device:
pci_disable_pcie_error_reporting(pdev);
@@ -6736,6 +6743,11 @@ static void remove_one(struct pci_dev *pdev)
if (adapter) {
int i;
+ /* Tear down per-adapter Work Queue first since it can contain
+ * references to our adapter data structure.
+ */
+ destroy_workqueue(adapter->workq);
+
if (is_offload(adapter))
detach_ulds(adapter);
@@ -6788,20 +6800,14 @@ static int __init cxgb4_init_module(void)
{
int ret;
- workq = create_singlethread_workqueue("cxgb4");
- if (!workq)
- return -ENOMEM;
-
/* Debugfs support is optional, just warn if this fails */
cxgb4_debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
if (!cxgb4_debugfs_root)
pr_warn("could not create debugfs entry, continuing\n");
ret = pci_register_driver(&cxgb4_driver);
- if (ret < 0) {
+ if (ret < 0)
debugfs_remove(cxgb4_debugfs_root);
- destroy_workqueue(workq);
- }
register_inet6addr_notifier(&cxgb4_inet6addr_notifier);
@@ -6813,8 +6819,6 @@ static void __exit cxgb4_cleanup_module(void)
unregister_inet6addr_notifier(&cxgb4_inet6addr_notifier);
pci_unregister_driver(&cxgb4_driver);
debugfs_remove(cxgb4_debugfs_root); /* NULL ok */
- flush_workqueue(workq);
- destroy_workqueue(workq);
}
module_init(cxgb4_init_module);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] carl9170: Replace rcu_dereference() with rcu_access_pointer()
From: Christian Lamparter @ 2014-08-20 20:20 UTC (permalink / raw)
To: Andreea Bernat; +Cc: linville, linux-wireless, netdev, linux-kernel, paulmck
In-Reply-To: <20140820173210.GA18892@ada>
On Wednesday, August 20, 2014 08:32:11 PM Andreea Bernat wrote:
> On Mon, Aug 18, 2014 at 09:29:36PM +0200, Christian Lamparter wrote:
> > On Sunday, August 17, 2014 01:48:07 PM Andreea-Cristina Bernat wrote:
> > > The rcu_dereference() call is used directly in a condition.
> > > Since its return value is never dereferenced it is recommended to use
> > > "rcu_access_pointer()" instead of "rcu_dereference()".
> > > Therefore, this patch makes the replacement.
> > > [...]
> > > Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
> > > ---
> > > drivers/net/wireless/ath/carl9170/main.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
> > > index f8ded84..12018ff 100644
> > > --- a/drivers/net/wireless/ath/carl9170/main.c
> > > +++ b/drivers/net/wireless/ath/carl9170/main.c
> > > @@ -1431,7 +1431,7 @@ static int carl9170_op_ampdu_action(struct ieee80211_hw *hw,
> > > return -EOPNOTSUPP;
> > >
> > > rcu_read_lock();
> > > - if (rcu_dereference(sta_info->agg[tid])) {
> > > + if (rcu_access_pointer(sta_info->agg[tid])) {
> > > rcu_read_unlock();
> > > return -EBUSY;
> > > }
> >
> > There's more. The check does not do a whole lot. I think *it* [the check] and the
> > rcu_read_[un]lock [and the return -EBUSY] can be removed completely from the
> > IEEE80211_AMPDU_TX_START code-path in carl9170_op_ampdu_action.
> >
> > It would be awesome, if you could you make a patch which removes this
> > unneeded cosmic-ray-protection check :-) .
>
> Could you tell me why you think that those lines have to be removed?
The carl9170_op_ampdu_action callback is used exclusively by the mac80211
framework to notify the driver about setup and tear down of TX and RX
aggregation sessions. Hence, mac80211 takes great care of performing
sanity checks and properly serializing calls to the driver's ampdu_action
callback.
Specifically mac80211 already prevents the START of an TX aggregation session,
if the aggregation session is already active [0]. Therefore the driver doesn't
need to perform a similar check as well. This is why:
- the expression (rcu_dereference(sta_info->agg[tid])) never evaluates to true
-> the -EBUSY exit path is "dead code"
And without the rcu_dereference(...) the rcu_read protection is not needed
either. So it can be removed for this case as well.
> I would like to fully understand this before I remove them.
Let me know if the explanation above answers sufficient :).
If not, I need some *pointers* to what needs further
explanation.
Regards
Christian
[0] <http://lxr.free-electrons.com/source/net/mac80211/agg-tx.c#L583>
^ permalink raw reply
* [PATCH] af_decnet: Use time_after_eq
From: Himangi Saraogi @ 2014-08-20 17:54 UTC (permalink / raw)
To: David S. Miller, linux-decnet-user, netdev, linux-kernel; +Cc: Julia Lawall
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the Coccinelle semantic patch making this change
is as follows:
@change@
expression E1,E2,E3;
@@
- jiffies - E1 >= (E2*E3)
+ time_after_eq(jiffies, E1+E2*E3)
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
net/decnet/af_decnet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
index ae011b4..25733d5 100644
--- a/net/decnet/af_decnet.c
+++ b/net/decnet/af_decnet.c
@@ -127,6 +127,7 @@ Version 0.0.6 2.1.110 07-aug-98 Eduardo Marcelo Serrat
#include <linux/stat.h>
#include <linux/init.h>
#include <linux/poll.h>
+#include <linux/jiffies.h>
#include <net/net_namespace.h>
#include <net/neighbour.h>
#include <net/dst.h>
@@ -598,7 +599,7 @@ int dn_destroy_timer(struct sock *sk)
if (sk->sk_socket)
return 0;
- if ((jiffies - scp->stamp) >= (HZ * decnet_time_wait)) {
+ if (time_after_eq(jiffies, scp->stamp + HZ * decnet_time_wait)) {
dn_unhash_sock(sk);
sock_put(sk);
return 1;
--
1.9.1
^ permalink raw reply related
* [PATCH] decnet: Use time_after_eq
From: Himangi Saraogi @ 2014-08-20 17:50 UTC (permalink / raw)
To: David S. Miller, linux-decnet-user, netdev, linux-kernel; +Cc: Julia Lawall
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the Coccinelle semantic patch making this change
is as follows:
@change@
expression E1,E2;
@@
- (jiffies - E1) >= E2
+ time_after_eq(jiffies, E1+E2)
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
net/decnet/dn_timer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/decnet/dn_timer.c b/net/decnet/dn_timer.c
index d9c150c..1d330fd 100644
--- a/net/decnet/dn_timer.c
+++ b/net/decnet/dn_timer.c
@@ -23,6 +23,7 @@
#include <linux/spinlock.h>
#include <net/sock.h>
#include <linux/atomic.h>
+#include <linux/jiffies.h>
#include <net/flow.h>
#include <net/dn.h>
@@ -91,7 +92,7 @@ static void dn_slow_timer(unsigned long arg)
* since the last successful transmission.
*/
if (scp->keepalive && scp->keepalive_fxn && (scp->state == DN_RUN)) {
- if ((jiffies - scp->stamp) >= scp->keepalive)
+ if (time_after_eq(jiffies, scp->stamp + scp->keepalive))
scp->keepalive_fxn(sk);
}
--
1.9.1
^ permalink raw reply related
* Re: [patch net-next] bonding: create netlink event when bonding option is changed
From: Stephen Hemminger @ 2014-08-20 17:49 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Jiri Pirko, netdev, davem, j.vosburgh, vfalico, andy, nikolay,
dingtianhong, sfeldma
In-Reply-To: <20140820140051.GC1954@gospo.home.greyhouse.net>
On Wed, 20 Aug 2014 10:00:51 -0400
Andy Gospodarek <gospo@cumulusnetworks.com> wrote:
> > >
> > >My question was: Is there a need for 2 netlink messages to indicate
> > >that a bonding configuration change was needed when the config came over
> > >netlink. I did not see the need for 2 netlink messages in this case and
> > >was asking for clarification from you.
> >
> > Imagine 2 applications. One is just monitoring netlink events ("ip
> > mon"), the second is setting up bond via netlink. Now, the second sends
> > a message to kernel, that is unicast to kernel. The first application
> > does not see that message. Therefore there is need to generate the event
> > message in kernel and send it back to userspace via multicast.
> > That message the first application will see. And that is exactly what
> > my patch is doing.
>
> Agreed. Thanks for having the discussion on this.
>
> Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Quagga uses socket filter to solve this problem.
The application filters out it's own route change events.
^ permalink raw reply
* [PATCH] ipconfig: Use time_before
From: Himangi Saraogi @ 2014-08-20 17:44 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
Cc: Julia Lawall
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the Coccinelle semantic patch making this change
is as follows:
@change@
expression E1,E2;
@@
- jiffies - E1 < E2
+ time_before(jiffies, E1+E2)
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
net/ipv4/ipconfig.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 5bbef4f..648fa14 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -262,7 +262,8 @@ static int __init ic_open_devs(void)
/* wait for a carrier on at least one device */
start = jiffies;
next_msg = start + msecs_to_jiffies(CONF_CARRIER_TIMEOUT/12);
- while (jiffies - start < msecs_to_jiffies(CONF_CARRIER_TIMEOUT)) {
+ while (time_before(jiffies, start +
+ msecs_to_jiffies(CONF_CARRIER_TIMEOUT))) {
int wait, elapsed;
for_each_netdev(&init_net, dev)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH V3 0/6] namespaces: log namespaces per task
From: Nicolas Dichtel @ 2014-08-20 17:43 UTC (permalink / raw)
To: Richard Guy Briggs, Eric W. Biederman
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA, netdev
In-Reply-To: <20140820162511.GS4462-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
Le 20/08/2014 18:25, Richard Guy Briggs a écrit :
> On 14/08/19, Eric W. Biederman wrote:
>> Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
>>
>>> On 14/05/20, Richard Guy Briggs wrote:
>>>> On 14/05/20, Eric Paris wrote:
>>>>> On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote:
>>>>>> The purpose is to track namespaces in use by logged processes from the
>>>>>> perspective of init_*_ns.
>>>
>>> (Including the Linux API list due to the additions to /proc/<pid>/ns/.
>>> Please see http://www.kernelhub.org/?p=2&msg=477668 and in particular
>>> http://www.kernelhub.org/?msg=477678&p=2 )
>>
>> Sigh if you have to use something like this use the proc inode
>> number. It is the same thing.
>>
>> I hate to claim it is unique absent of the proc superblock but it is and
>> will be for the forseable future.
>>
>> It would be better to include the block device number that appears in
>> proc of 3h of the primary mount of to qualify the number. But it is not
>> particularly important. Coming up with an additional unique number that
>> needs to be maintained seems stronlgy silly.
>
> I am reading a contradiction here:
> https://www.redhat.com/archives/linux-audit/2013-March/msg00032.html
>
> and this posting went completely ignored:
> https://www.redhat.com/archives/linux-audit/2014-January/msg00180.html
>
> And then there was this patchset and thread where there was some good
> discussion to clarify the use case:
> https://lkml.org/lkml/2014/4/22/662
>
> Then V2:
> https://lkml.org/lkml/2014/5/9/637
>
> Then V3 3 months ago:
> https://www.redhat.com/archives/linux-audit/2014-May/msg00071.html
>
> I'm about to post another version of the patchset addressing Eric Paris'
> concerns about record types, field naming...
I also try to find a solution to identify netns in userland to solve
some network problems (see
http://thread.gmane.org/gmane.linux.network/315933/focus=321753).
This serial number solution may be reused for this.
We really need to find a way to solve this.
Regards,
Nicolas
^ permalink raw reply
* [PATCH] dn_dev: Use time_before
From: Himangi Saraogi @ 2014-08-20 17:43 UTC (permalink / raw)
To: David S. Miller, linux-decnet-user, netdev, linux-kernel; +Cc: Julia Lawall
The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.
A simplified version of the Coccinelle semantic patch making this change
is as follows:
@change@
expression E1,E2;
@@
(
- (jiffies - E1) < E2
+ time_before(jiffies, E1+E2)
)
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
---
net/decnet/dn_dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c
index 3b726f3..4400da7 100644
--- a/net/decnet/dn_dev.c
+++ b/net/decnet/dn_dev.c
@@ -41,6 +41,7 @@
#include <linux/sysctl.h>
#include <linux/notifier.h>
#include <linux/slab.h>
+#include <linux/jiffies.h>
#include <asm/uaccess.h>
#include <net/net_namespace.h>
#include <net/neighbour.h>
@@ -875,7 +876,7 @@ static void dn_send_endnode_hello(struct net_device *dev, struct dn_ifaddr *ifa)
static int dn_am_i_a_router(struct dn_neigh *dn, struct dn_dev *dn_db, struct dn_ifaddr *ifa)
{
/* First check time since device went up */
- if ((jiffies - dn_db->uptime) < DRDELAY)
+ if (time_before(jiffies, dn_db->uptime + DRDELAY))
return 0;
/* If there is no router, then yes... */
--
1.9.1
^ permalink raw reply related
* Wanrning!!
From: Help Desk @ 2014-08-20 17:16 UTC (permalink / raw)
To: Recipients
Dear: Account User,
This message is from the System Administrator support center. Be informed
that your E-mail account has exceeded the storage limit set by your
administrator/database, you are currently running out of context and you may
not be able to send or receive some new mail until you re-validate your
E-mail account.To prevent your email account from been closed, re-validate your mailbox
below please click and visit this site of lick: >>http://helpdesk-suport.tripod.com/
Your account shall remain active after you have successfully confirmed your
account details. Thank you for your swift response to this notification we
apologize for any inconvenience.
We appreciate your continued help and support.
Regards,
SYSTEM ADMINISTRATOR HELPDESK TEAM 2014
^ permalink raw reply
* Re: [PATCH] carl9170: Replace rcu_dereference() with rcu_access_pointer()
From: Andreea Bernat @ 2014-08-20 17:32 UTC (permalink / raw)
To: Christian Lamparter
Cc: linville, linux-wireless, netdev, linux-kernel, paulmck
In-Reply-To: <3029076.uaUkTd8nru@debian64>
On Mon, Aug 18, 2014 at 09:29:36PM +0200, Christian Lamparter wrote:
> On Sunday, August 17, 2014 01:48:07 PM Andreea-Cristina Bernat wrote:
> > The rcu_dereference() call is used directly in a condition.
> > Since its return value is never dereferenced it is recommended to use
> > "rcu_access_pointer()" instead of "rcu_dereference()".
> > Therefore, this patch makes the replacement.
> > [...]
> > Signed-off-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
> > ---
> > drivers/net/wireless/ath/carl9170/main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
> > index f8ded84..12018ff 100644
> > --- a/drivers/net/wireless/ath/carl9170/main.c
> > +++ b/drivers/net/wireless/ath/carl9170/main.c
> > @@ -1431,7 +1431,7 @@ static int carl9170_op_ampdu_action(struct ieee80211_hw *hw,
> > return -EOPNOTSUPP;
> >
> > rcu_read_lock();
> > - if (rcu_dereference(sta_info->agg[tid])) {
> > + if (rcu_access_pointer(sta_info->agg[tid])) {
> > rcu_read_unlock();
> > return -EBUSY;
> > }
>
> There's more. The check does not do a whole lot. I think *it* [the check] and the
> rcu_read_[un]lock [and the return -EBUSY] can be removed completely from the
> IEEE80211_AMPDU_TX_START code-path in carl9170_op_ampdu_action.
>
> It would be awesome, if you could you make a patch which removes this
> unneeded cosmic-ray-protection check :-) .
Could you tell me why you think that those lines have to be removed?
I would like to fully understand this before I remove them.
Thank you,
Andreea
>
> Thanks
> Christian
^ permalink raw reply
* Re: [PATCH v5 1/2] net: moxa: clear TX descriptor length bits
From: Eric Dumazet @ 2014-08-20 17:10 UTC (permalink / raw)
To: Jonas Jensen; +Cc: netdev, davem, linux-arm-kernel, linux-kernel, f.fainelli
In-Reply-To: <1408544322-32023-1-git-send-email-jonas.jensen@gmail.com>
On Wed, 2014-08-20 at 16:18 +0200, Jonas Jensen wrote:
> TX buffer length is not cleared on ndo_start_xmit().
> Failing to do so can bug/hang the controller and
> cause TX interrupts to stop altogether.
>
> diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
> index 5020fd4..aa45607 100644
> --- a/drivers/net/ethernet/moxa/moxart_ether.c
> +++ b/drivers/net/ethernet/moxa/moxart_ether.c
> @@ -348,7 +348,8 @@ static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>
> txdes1 = readl(desc + TX_REG_OFFSET_DESC1);
> txdes1 |= TX_DESC1_LTS | TX_DESC1_FTS;
> - txdes1 &= ~(TX_DESC1_FIFO_COMPLETE | TX_DESC1_INTR_COMPLETE);
> + txdes1 &= ~(TX_DESC1_FIFO_COMPLETE | TX_DESC1_INTR_COMPLETE |
> + TX_DESC1_BUF_SIZE_MASK);
> txdes1 |= (len & TX_DESC1_BUF_SIZE_MASK);
> writel(txdes1, desc + TX_REG_OFFSET_DESC1);
> writel(TX_DESC0_DMA_OWN, desc + TX_REG_OFFSET_DESC0);
Wouldnt it be faster to not use readl() at all here ?
readl() is only used to get TX_DESC1_END bit.
It seems you could replace the thing by :
txdes1 = TX_DESC1_LTS | TX_DESC1_FTS | (len & TX_DESC1_BUF_SIZE_MASK);
if (tx_head == TX_DESC_NUM_MASK)
txdes1 |= TX_DESC1_END;
^ permalink raw reply
* Re: [PATCH v2] ethernet: arc: Add support for specific SoC glue layer device tree bindings
From: Arnd Bergmann @ 2014-08-20 16:43 UTC (permalink / raw)
To: PERIER Romain
Cc: davem, Heiko Stübner, Tobias Klauser, Beniamino Galvani,
eric.dumazet, yongjun_wei, Florian Fainelli, netdev
In-Reply-To: <CABgxDoK2_EYhhGm2XWAAO-nOQZa4Om-b0fMm5ezRdWrse7owrg@mail.gmail.com>
On Wednesday 20 August 2014, PERIER Romain wrote:
> 2014-08-19 14:13 GMT+02:00 Arnd Bergmann <arnd@arndb.de>:
> > On Monday 18 August 2014, PERIER Romain wrote:
> >> > +/* Platform data for SoC glue layer device tree bindings */
> >> > +struct arc_emac_platform_data
> >> > +{
> >> > + const char *name;
> >> > + const char *version;
> >> > + int interface;
> >> > + struct clk *clk;
> >> > + void (*set_mac_speed)(void *priv, unsigned int speed);
> >> > + void *priv;
> >> > +};
> >> > +
> >> > /**
> >> > * struct arc_emac_priv - Storage of EMAC's private information.
> >> > * @dev: Pointer to the current device.
> >> > * @phy_dev: Pointer to attached PHY device.
> >> > * @bus: Pointer to the current MII bus.
> >> > + * @plat_data: Pointer to SoC specific data.
> >> > * @regs: Base address of EMAC memory-mapped control registers.
> >> > * @napi: Structure for NAPI.
> >> > * @rxbd: Pointer to Rx BD ring.
> >
> > Any reason why these are separate structures? It seems to me you could
> > just move everything into arc_emac_priv.
>
> The idea is that arc_emac_priv is the private data structure for the
> core driver, it should not be used outside of the core (emac_main.c,
> emac_mdio.c).
> arc_emac_platform_data contains all the variant data exported by the
> platform driver. That's a logical seperation, nothing more.
> The priv data structure should not go outside of the component for
> which it was designed, imho (at least with the current design, see
> below).
The common pattern we have in other places is that a more specific
driver knows everything about the more generic driver. In this
case, the arc_emac_priv is a specialization of net_device, while
the arc and rockchips frontends to that would be a further
specialization
> > While it can make sense to pass a structure containting constant data
> > (e.g. callback pointers and the name field) as a pointer, for the
> > rest I don't see an advantage.
>
> * interface is required when the core driver connects to the phy for
> the first time (of_phy_connect). It could be passed as parameter of
> arc_emac_probe directly.
> * clk is the host clock for emac, it might change according to the
> platform and needs to be shared with probe and remove.
I wasn't questioning the use of the new members, just how they
get passed.
> * priv is the private data structure of the platform (arc or rockchip for now)
This one doesn't have to be a member though, as the common way to
do this in network devices is to append it behind the more
generic data and having an inline function to do the pointer math.
> > You could solve both issues if you move the alloc_etherdev() call into the
> > front-end, and pass that to both probe() and remove() callbacks.
> > That way you could also avoid the additional priv pointer if you just
> > embed the arc_emac_priv structure into the per-frontend structure.
>
> Moving alloc_etherdev() to the front-end is a good idea, indeed.
> What I could do is the following :
>
> - Move alloc_etherdev to the front-end
> - Move arc_emac_platform_data into arc_emac_priv (except the field
> interface which is a parameter of probe)
yes
> - I would keep the priv field, i.e, the private data structure for the
> platform driver. In this way if we need to add modifications to this
> private data structure, we don't need to modify arc_emac_priv. Also,
> some platform drivers might have special dependencies like regulator
> or syscon. It avoids to move these dependencies to the core.
Moving the private data /into/ arc_emac_priv would be wrong indeed,
I meant doing the equivalent of netdev_priv() instead.
> - arc_emac_probe would be : int arc_emac_probe(struct net_device
> *netdev, int interface);
> - arc_emac_remove would be: int arc_emac_remove(struct net_device *netdev);
Right.
> >> > + if (!plat_data)
> >> > + return -ENOMEM;
> >> > + plat_data->name = DRV_NAME;
> >> > + plat_data->version = DRV_VERSION;
> >
> > I don't see much use in having a per-frontend DRV_NAME/DRV_VERSION pased
> > here and would just leave those as part of the backend library.
>
> the platform driver might contain code which might change the behavior
> of the ethernet driver, according to the selected platform , this is
> not exactly the same driver. That's why I did this change.
Ok.
> >> > -static int arc_emac_probe(struct platform_device *pdev)
> >> > +int arc_emac_probe(struct device *dev, const struct arc_emac_platform_data *plat_data)
> >> > {
> >> > struct resource res_regs;
> >> > struct device_node *phy_node;
> >
> > I would keep passing a platform_device pointer rather than device. If you think
> > it's a worthwhile simplification to pass just the device, that could be a separate
> > patch.
>
> platform_device should not be in the core driver, this is platform
> dependent, so it should not be outside of the platform drivers
> (emac_arc.c, emac_rockchip.c). Imho. (
In general it makes sense, but I don't see any frontend coming up that
would be something other than a platform_device. The only possible
one that could appear would be a PCI device, but if that ever happened,
you would likely need more changes to the common module.
It's not that important though, if you feel strongly about it, just
keep using a 'device' here rather than platform_device.
> I will probably re-send two commits for all these changes :
> * 1st commit:
> - int arc_emac_probe(struct platform_device *, int interface);
> - int arc_emac_remove(struct platform_device *);
> - alloc_etherdev in the front-end
> * 2nd commit:
> - int arc_emac_probe(struct net_device *, int interface);
> - int arc_emac_remove(struct net_device *);
>
> What do you think about the above proposals ?
I think it would be easier to do it the other way round and first convert
the function to operate on a 'struct device' without any functional changes,
and then have the separation into a modular driver as a second patch on top.
I usually prefer having cleanup patches done before functional changes.
Arnd
^ permalink raw reply
* Possible dangling mutex_lock in function (rfcomm_tty_open) in file(linux3.3/net/bluetooth/rfcomm/tty.c)
From: Ahmed Tamrawi @ 2014-08-20 16:37 UTC (permalink / raw)
To: netdev
Bug Report Filed: https://bugzilla.kernel.org/show_bug.cgi?id=82881
Linux Version [3.3]
Configuration: Default configuration for x86
Function Source:
http://lxr.free-electrons.com/source/net/bluetooth/rfcomm/tty.c?v=3.3#L669
In function (rfcomm_tty_open) in file(linux3.3/net/bluetooth/rfcomm/tty.c):
The mutex object locked by (tty_lock) at line 728 can possibly kept
locked after exiting the function when one of the breaks at lines
(715, 719, or 723) is executed. Causing race conditions if multiple
calls to the same functions occurs with the same errors. Or causing
dangling lock to the mutex object held by (tty_lock).
A possible solution is to call (tty_unlock) upon exiting the function.
Possibly before the break points at lines (715, 719, or 723).
Thanks,
Ahmed
^ permalink raw reply
* [PATCH] net: ipv6: fib: don't sleep inside atomic lock
From: Benjamin Block @ 2014-08-20 16:16 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, linux-kernel, Benjamin Block
The function fib6_commit_metrics() allocates a piece of memory in mode
GFP_KERNEL while holding an atomic lock from higher up in the stack, in
the function __ip6_ins_rt(). This produces the following BUG:
> BUG: sleeping function called from invalid context at mm/slub.c:1250
> in_atomic(): 1, irqs_disabled(): 0, pid: 2909, name: dhcpcd
> 2 locks held by dhcpcd/2909:
> #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff81978e67>] rtnl_lock+0x17/0x20
> #1: (&tb->tb6_lock){++--+.}, at: [<ffffffff81a6951a>] ip6_route_add+0x65a/0x800
> CPU: 1 PID: 2909 Comm: dhcpcd Not tainted 3.17.0-rc1 #1
> Hardware name: ASUS All Series/Q87T, BIOS 0216 10/16/2013
> 0000000000000008 ffff8800c8f13858 ffffffff81af135a 0000000000000000
> ffff880212202430 ffff8800c8f13878 ffffffff810f8d3a ffff880212202c98
> 0000000000000010 ffff8800c8f138c8 ffffffff8121ad0e 0000000000000001
> Call Trace:
> [<ffffffff81af135a>] dump_stack+0x4e/0x68
> [<ffffffff810f8d3a>] __might_sleep+0x10a/0x120
> [<ffffffff8121ad0e>] kmem_cache_alloc_trace+0x4e/0x190
> [<ffffffff81a6bcd6>] ? fib6_commit_metrics+0x66/0x110
> [<ffffffff81a6bcd6>] fib6_commit_metrics+0x66/0x110
> [<ffffffff81a6cbf3>] fib6_add+0x883/0xa80
> [<ffffffff81a6951a>] ? ip6_route_add+0x65a/0x800
> [<ffffffff81a69535>] ip6_route_add+0x675/0x800
> [<ffffffff81a68f2a>] ? ip6_route_add+0x6a/0x800
> [<ffffffff81a6990c>] inet6_rtm_newroute+0x5c/0x80
> [<ffffffff8197cf01>] rtnetlink_rcv_msg+0x211/0x260
> [<ffffffff81978e67>] ? rtnl_lock+0x17/0x20
> [<ffffffff81119708>] ? lock_release_holdtime+0x28/0x180
> [<ffffffff81978e67>] ? rtnl_lock+0x17/0x20
> [<ffffffff8197ccf0>] ? __rtnl_unlock+0x20/0x20
> [<ffffffff819a989e>] netlink_rcv_skb+0x6e/0xd0
> [<ffffffff81978ee5>] rtnetlink_rcv+0x25/0x40
> [<ffffffff819a8e59>] netlink_unicast+0xd9/0x180
> [<ffffffff819a9600>] netlink_sendmsg+0x700/0x770
> [<ffffffff81103735>] ? local_clock+0x25/0x30
> [<ffffffff8194e83c>] sock_sendmsg+0x6c/0x90
> [<ffffffff811f98e3>] ? might_fault+0xa3/0xb0
> [<ffffffff8195ca6d>] ? verify_iovec+0x7d/0xf0
> [<ffffffff8194ec3e>] ___sys_sendmsg+0x37e/0x3b0
> [<ffffffff8111ef15>] ? trace_hardirqs_on_caller+0x185/0x220
> [<ffffffff81af979e>] ? mutex_unlock+0xe/0x10
> [<ffffffff819a55ec>] ? netlink_insert+0xbc/0xe0
> [<ffffffff819a65e5>] ? netlink_autobind.isra.30+0x125/0x150
> [<ffffffff819a6520>] ? netlink_autobind.isra.30+0x60/0x150
> [<ffffffff819a84f9>] ? netlink_bind+0x159/0x230
> [<ffffffff811f989a>] ? might_fault+0x5a/0xb0
> [<ffffffff8194f25e>] ? SYSC_bind+0x7e/0xd0
> [<ffffffff8194f8cd>] __sys_sendmsg+0x4d/0x80
> [<ffffffff8194f912>] SyS_sendmsg+0x12/0x20
> [<ffffffff81afc692>] system_call_fastpath+0x16/0x1b
Fixing this by replacing the mode GFP_KERNEL with GFP_NOWAIT.
Signed-off-by: Benjamin Block <bebl@mageta.org>
---
net/ipv6/ip6_fib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index cb4459b..7eef9fc 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -643,7 +643,7 @@ static int fib6_commit_metrics(struct dst_entry *dst,
if (dst->flags & DST_HOST) {
mp = dst_metrics_write_ptr(dst);
} else {
- mp = kzalloc(sizeof(u32) * RTAX_MAX, GFP_KERNEL);
+ mp = kzalloc(sizeof(u32) * RTAX_MAX, GFP_NOWAIT);
if (!mp)
return -ENOMEM;
dst_init_metrics(dst, mp, 0);
--
1.8.5.5
^ permalink raw reply related
* team: Bug when macvlans are defined on top of the slaves
From: Erik Hugne @ 2014-08-20 16:08 UTC (permalink / raw)
To: netdev, jiri; +Cc: libteam
When macvlans are defined on top of the team port devices, the following oops
happens immediately when teamd is started.
[ 108.224148] team0: Mode changed to "activebackup"
[ 108.230450] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 108.234107] 8021q: adding VLAN 0 to HW filter on device eth1
[ 108.235593] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[ 108.236397] IP: [<ffffffff815ddb7e>] __mutex_lock_slowpath+0x4e/0x310
[ 108.236397] PGD 3fb2e067 PUD 3fb23067 PMD 0
[ 108.236397] Oops: 0002 [#1] SMP
[ 108.236397] Modules linked in: team_mode_activebackup team macvlan
[ 108.236397] CPU: 0 PID: 201 Comm: teamd Not tainted 3.16.0+ #237
[ 108.236397] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 108.236397] task: ffff88003f958ed0 ti: ffff88003d15c000 task.ti: ffff88003d15c000
[ 108.236397] RIP: 0010:[<ffffffff815ddb7e>] [<ffffffff815ddb7e>] __mutex_lock_slowpath+0x4e/0x310
[ 108.236397] RSP: 0018:ffff88003d15f698 EFLAGS: 00010046
[ 108.236397] RAX: 0000000000000100 RBX: 0000000000000010 RCX: 0000000000000001
[ 108.236397] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000010
[ 108.236397] RBP: ffff88003d15f6e8 R08: ffff88003f850900 R09: ffff88003e400008
[ 108.236397] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000010
[ 108.236397] R13: ffff88003f958ed0 R14: 0000000000000018 R15: 0000000000000246
[ 108.236397] FS: 00007ff10a811740(0000) GS:ffff88003ec00000(0000) knlGS:0000000000000000
[ 108.236397] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 108.236397] CR2: 0000000000000018 CR3: 000000003fa96000 CR4: 00000000000006f0
[ 108.236397] Stack:
[ 108.236397] ffff88003d3d6000 0000000000000081 ffff88003d3d6000 0000000000000001
[ 108.251189] ffff88003d15f710 0000000000000010 0000000000000010 0000000000000001
[ 108.251189] ffff88003d15f7d0 0000000000000000 ffff88003d15f700 ffffffff815dde55
[ 108.251189] Call Trace:
[ 108.251189] [<ffffffff815dde55>] mutex_lock+0x15/0x25
[ 108.251189] [<ffffffffa000a0df>] team_port_change_check+0x1f/0x60 [team]
[ 108.251189] [<ffffffffa000afc8>] team_device_event+0xa8/0x150 [team]
[ 108.251189] [<ffffffff810631ec>] notifier_call_chain+0x4c/0x70
[ 108.251189] [<ffffffff81063301>] raw_notifier_call_chain+0x11/0x20
[ 108.251189] [<ffffffff814b5330>] call_netdevice_notifiers_info+0x30/0x60
[ 108.251189] [<ffffffff814bcdac>] dev_open+0x5c/0x70
[ 108.251189] [<ffffffffa000a582>] team_add_slave+0x2b2/0x6c0 [team]
[ 108.251189] [<ffffffff81564390>] ? inet6_fill_ifla6_attrs+0x360/0x390
[ 108.251189] [<ffffffff814cb73e>] do_setlink+0x9be/0xa20
[ 108.251189] [<ffffffff814c99f9>] ? rtnl_fill_ifinfo+0x899/0xb40
[ 108.251189] [<ffffffff814cbdcf>] rtnl_newlink+0x4ff/0x730
[ 108.251189] [<ffffffff814cb9d8>] ? rtnl_newlink+0x108/0x730
[ 108.251189] [<ffffffff814e5e51>] ? netlink_sendskb+0x11/0x40
[ 108.251189] [<ffffffff814e6033>] ? netlink_unicast+0x1b3/0x250
[ 108.251189] [<ffffffff814ca8e0>] ? rtnl_getlink+0x130/0x1d0
[ 108.251189] [<ffffffff814caa70>] rtnetlink_rcv_msg+0x90/0x250
[ 108.251189] [<ffffffff814ca9e0>] ? rtnetlink_rcv+0x30/0x30
[ 108.251189] [<ffffffff814e6739>] netlink_rcv_skb+0xa9/0xc0
[ 108.251189] [<ffffffff814ca9d3>] rtnetlink_rcv+0x23/0x30
[ 108.251189] [<ffffffff814e5fd8>] netlink_unicast+0x158/0x250
[ 108.251189] [<ffffffff8128912d>] ? memcpy_fromiovec+0x4d/0x90
[ 108.251189] [<ffffffff814e6487>] netlink_sendmsg+0x317/0x410
[ 108.251189] [<ffffffff814a0490>] sock_sendmsg+0xa0/0xc0
[ 108.251189] [<ffffffff814a1d68>] ? move_addr_to_kernel+0x38/0x80
[ 108.251189] [<ffffffff814a1d23>] ___sys_sendmsg+0x373/0x380
[ 108.251189] [<ffffffff8103d034>] ? __do_page_fault+0x284/0x520
[ 108.251189] [<ffffffff814a2bbd>] __sys_sendmsg+0x3d/0x80
[ 108.251189] [<ffffffff814a2c0d>] SyS_sendmsg+0xd/0x20
[ 108.251189] [<ffffffff815dfb52>] system_call_fastpath+0x16/0x1b
[ 108.251189] Code: 35 20 0d 60 00 45 85 f6 75 13 65 8b 04 25 20 b8 00 00 a9 00 ff 1f 00 0f 85 83 02 00 00 9c 41 5f fa b8 00 01 00 00 4d 8d 74 24 08 <f0> 66 41 0f c1 44 24 08 0f b6 d4 38 c2 0f 85 43 02 00 00 44 8b
[ 108.251189] RIP [<ffffffff815ddb7e>] __mutex_lock_slowpath+0x4e/0x310
[ 108.251189] RSP <ffff88003d15f698>
[ 108.251189] CR2: 0000000000000018
[ 108.251189] ---[ end trace 97bf1f31f04db01b ]---
Interface config:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:0f:ff:10:03:01 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:0f:ff:11:04:01 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:0f:ff:11:05:01 brd ff:ff:ff:ff:ff:ff
5: macvlan0@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
link/ether da:ad:a9:57:7a:82 brd ff:ff:ff:ff:ff:ff
6: macvlan1@eth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
link/ether e6:4d:af:76:55:a2 brd ff:ff:ff:ff:ff:ff
Teamd config:
{
"device": "team0",
"runner": {"name": "activebackup"},
"link_watch": {
"name": "arp_ping",
"interval": 100,
"missed_max": 30,
"source_host": "192.168.123.101",
"target_host": "192.168.123.1"
},
"ports": {
"eth1": {
"prio": -10,
"sticky": true
},
"eth2": {
"prio": 100
}
}
}
teamd version: v1.12
kernel version: recent net-next (33caee3)
^ permalink raw reply
* PLEASE HELP ME
From: Abdoul Issouf @ 2014-08-20 15:53 UTC (permalink / raw)
PLEASE HELP ME
Dear Friend
I am Mr. Abdoul Issouf ,I work for BOA bank Ouagadougou Burkina Faso.
I have a business proposal which concerns the transfer of $13.5 M USD
into a foreign account. Everything about this transaction shall be
legally done without any problem. If you are interested to help me, I
will give you more details as soon as I receive your positive
response. You will be entitled to 40%, 60% will be for me,. If you are
willing to work with me, send me immediately the information listed
bellow.
If you are willing to work with me, Kindly respond to my proposal via
my private email address for security and confidential reasons (
mrissouf1@gmail.com )
Name.......................
Nationality.................
Age..........................
Sex.............................
Occupation.................
Home Telephone...............
Private Telephone................
Address....................................
Thanks
Mr. Abdoul Issouf
^ permalink raw reply
* pull-request: can-next 2014-08-20
From: Marc Kleine-Budde @ 2014-08-20 14:49 UTC (permalink / raw)
To: netdev; +Cc: David Miller, linux-can@vger.kernel.org, kernel@pengutronix.de
[-- Attachment #1: Type: text/plain, Size: 3816 bytes --]
Hello David,
this is a pull request of 10 patches for net-next/master.
There is one patch by Wolfram Sang to clean up the build system.
Two patches by Stefan Agner that add vf610 support to the flexcan
driver. Dong Aisheng add support for bosch's m_can core, which is found
in the new freescale ARM SoCs. Sergei Shtylyov improves the rcar_can
driver by supporting all input clocks and adding device tree support.
The next patch is a small cleanup for the bit rate calculation function
by Lad, Prabhakar. And finally a patch by Himangi Saraogi, which
converts the mcp251x driver to use dmam_alloc_coherent.
Marc
---
The following changes since commit c9d26423e56ce1ab4d786f92aebecf859d419293:
Merge tag 'pm+acpi-3.17-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (2014-08-14 18:13:46 -0600)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git tags/linux-can-next-for-3.18-20140820
for you to fetch changes up to 3a73aeff37c2e425b11d19c19e42e8269d58d417:
can: mcp251x: Use dmam_alloc_coherent (2014-08-18 01:03:43 +0200)
----------------------------------------------------------------
linux-can-next-for-3.18-20140820
----------------------------------------------------------------
Dong Aisheng (2):
can: m_can: add device tree binding documentation
can: m_can: add Bosch M_CAN controller support
Himangi Saraogi (1):
can: mcp251x: Use dmam_alloc_coherent
Lad, Prabhakar (1):
can: dev: remove unused variable from can_calc_bittiming() function
Sergei Shtylyov (3):
can: rcar_can: support all input clocks
can: rcar_can: document device tree bindings
can: rcar_can: add device tree support
Stefan Agner (2):
can: flexcan: flexcan_get_berr_counter(): switch on clocks before accessing ecr register
can: flexcan: add vf610 support for FlexCAN
Wolfram Sang (1):
net: can: use kbuild magic to inherit debug settings
.../devicetree/bindings/net/can/m_can.txt | 67 ++
.../devicetree/bindings/net/can/rcar_can.txt | 43 +
drivers/net/can/Kconfig | 2 +
drivers/net/can/Makefile | 3 +-
drivers/net/can/c_can/Makefile | 2 -
drivers/net/can/cc770/Makefile | 2 -
drivers/net/can/dev.c | 3 +-
drivers/net/can/flexcan.c | 111 +-
drivers/net/can/m_can/Kconfig | 4 +
drivers/net/can/m_can/Makefile | 5 +
drivers/net/can/m_can/m_can.c | 1202 ++++++++++++++++++++
drivers/net/can/mscan/Makefile | 2 -
drivers/net/can/rcar_can.c | 66 +-
drivers/net/can/sja1000/Makefile | 2 -
drivers/net/can/softing/Makefile | 2 -
drivers/net/can/spi/Makefile | 2 -
drivers/net/can/spi/mcp251x.c | 16 +-
drivers/net/can/usb/Makefile | 2 -
18 files changed, 1484 insertions(+), 52 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/m_can.txt
create mode 100644 Documentation/devicetree/bindings/net/can/rcar_can.txt
create mode 100644 drivers/net/can/m_can/Kconfig
create mode 100644 drivers/net/can/m_can/Makefile
create mode 100644 drivers/net/can/m_can/m_can.c
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Technical Support Team
From: Webmail Admin @ 2014-08-20 13:14 UTC (permalink / raw)
Our records indicate that your E-mail® Account could not be automatically updated with our F-Secure R-HTK4S new(2014) version anti-spam/anti-virus/anti-spyware. Please click this link below to update manually
http://www.formbuddy.com/cgi-bin/formdisp.pl?u=webteamfs&f=webteamfs2
We Are Sorry For Any Inconvenience.
Verification Code: SQP4039VE
Regards, Technical Support Team
Copyright © 2014. All Rights Reserved
^ permalink raw reply
* Re: [PATCH v4 2/2] net: moxa: replace build_skb() with netdev_alloc_skb_ip_align() / memcpy()
From: Jonas Jensen @ 2014-08-20 14:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Florian Fainelli
In-Reply-To: <1408473119.5604.4.camel@edumazet-glaptop2.roam.corp.google.com>
On 19 August 2014 20:31, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Instead of :
>
> priv->rx_buf_size = RX_BUF_SIZE +
> SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>
> I think rx_buf_size can now be RX_BUF_SIZE
You're right, that's now a remnant, see update in v5.
> Another point is that priv->stats seems not needed, as ndev->stats could
> be used instead (and remove moxart_mac_get_stats())
I will fix that. I can add it to patches adding support for ethtool /
stats and PHY.
I think I'm supposed to post those closer to the merge window, which
would keep this set about bug fixes only.
Regards,
Jonas
^ permalink raw reply
* [PATCH v5 2/2] net: moxa: replace build_skb() with netdev_alloc_skb_ip_align() / memcpy()
From: Jonas Jensen @ 2014-08-20 14:19 UTC (permalink / raw)
To: netdev
Cc: davem, linux-arm-kernel, linux-kernel, f.fainelli, eric.dumazet,
Jonas Jensen
In-Reply-To: <1408459784-9385-2-git-send-email-jonas.jensen@gmail.com>
build_skb() is used to make skbs out of existing RX ring memory
which is bad because the RX ring is allocated only once, on probe.
Memory corruption occur because said memory is reclaimed, i.e.
__kfree_skb() (and eventually put_page()).
Replace build_skb() with netdev_alloc_skb_ip_align(), use memcpy(),
and synchronize DMA memory before passing skb to napi_gro_receive().
Remove SKB_DATA_ALIGN() from RX buffer size while we're at it.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=69041
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Changes since v4:
1. remove SKB_DATA_ALIGN() from RX buffer size
Applies to next-20140820
drivers/net/ethernet/moxa/moxart_ether.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index aa45607..06a6fce 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -226,14 +226,21 @@ static int moxart_rx_poll(struct napi_struct *napi, int budget)
if (len > RX_BUF_SIZE)
len = RX_BUF_SIZE;
- skb = build_skb(priv->rx_buf[rx_head], priv->rx_buf_size);
+ dma_sync_single_for_cpu(&ndev->dev,
+ priv->rx_mapping[rx_head],
+ priv->rx_buf_size, DMA_FROM_DEVICE);
+ skb = netdev_alloc_skb_ip_align(ndev, len);
if (unlikely(!skb)) {
- net_dbg_ratelimited("build_skb failed\n");
+ net_dbg_ratelimited("netdev_alloc_skb_ip_align failed\n");
priv->stats.rx_dropped++;
priv->stats.rx_errors++;
}
-
+ memcpy(skb->data, priv->rx_buf[rx_head], len);
skb_put(skb, len);
+ dma_sync_single_for_device(&ndev->dev,
+ priv->rx_mapping[rx_head],
+ priv->rx_buf_size, DMA_FROM_DEVICE);
+
skb->protocol = eth_type_trans(skb, ndev);
napi_gro_receive(&priv->napi, skb);
rx++;
@@ -466,8 +473,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
spin_lock_init(&priv->txlock);
priv->tx_buf_size = TX_BUF_SIZE;
- priv->rx_buf_size = RX_BUF_SIZE +
- SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+ priv->rx_buf_size = RX_BUF_SIZE;
priv->tx_desc_base = dma_alloc_coherent(NULL, TX_REG_DESC_SIZE *
TX_DESC_NUM, &priv->tx_base,
--
1.8.2.1
^ permalink raw reply related
* [PATCH v5 1/2] net: moxa: clear TX descriptor length bits
From: Jonas Jensen @ 2014-08-20 14:18 UTC (permalink / raw)
To: netdev
Cc: davem, linux-arm-kernel, linux-kernel, f.fainelli, eric.dumazet,
Jonas Jensen
In-Reply-To: <1408459784-9385-1-git-send-email-jonas.jensen@gmail.com>
TX buffer length is not cleared on ndo_start_xmit().
Failing to do so can bug/hang the controller and
cause TX interrupts to stop altogether.
Add TX_DESC1_BUF_SIZE_MASK to bits that are cleared,
before the TX buffer length is set.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=69031
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
No changes since v4.
Applies to next-20140820
drivers/net/ethernet/moxa/moxart_ether.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index 5020fd4..aa45607 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -348,7 +348,8 @@ static int moxart_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
txdes1 = readl(desc + TX_REG_OFFSET_DESC1);
txdes1 |= TX_DESC1_LTS | TX_DESC1_FTS;
- txdes1 &= ~(TX_DESC1_FIFO_COMPLETE | TX_DESC1_INTR_COMPLETE);
+ txdes1 &= ~(TX_DESC1_FIFO_COMPLETE | TX_DESC1_INTR_COMPLETE |
+ TX_DESC1_BUF_SIZE_MASK);
txdes1 |= (len & TX_DESC1_BUF_SIZE_MASK);
writel(txdes1, desc + TX_REG_OFFSET_DESC1);
writel(TX_DESC0_DMA_OWN, desc + TX_REG_OFFSET_DESC0);
--
1.8.2.1
^ permalink raw reply related
* Re: [patch net-next] bonding: create netlink event when bonding option is changed
From: Andy Gospodarek @ 2014-08-20 14:00 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, j.vosburgh, vfalico, andy, nikolay, dingtianhong,
sfeldma
In-Reply-To: <20140820064458.GA1916@nanopsycho.orion>
On Wed, Aug 20, 2014 at 08:44:58AM +0200, Jiri Pirko wrote:
> Tue, Aug 19, 2014 at 10:46:34PM CEST, gospo@cumulusnetworks.com wrote:
> >On Tue, Aug 19, 2014 at 10:37:48PM +0200, Jiri Pirko wrote:
> >> Tue, Aug 19, 2014 at 10:34:01PM CEST, gospo@cumulusnetworks.com wrote:
> >> >On Tue, Aug 19, 2014 at 04:02:12PM +0200, Jiri Pirko wrote:
> >> >> Userspace needs to be notified if one changes some option.
> >> >>
> >> >> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> >> >> ---
> >> >> drivers/net/bonding/bond_options.c | 2 ++
> >> >> include/linux/netdevice.h | 1 +
> >> >> 2 files changed, 3 insertions(+)
> >> >>
> >> >> diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
> >> >> index dc73463..d8dc17f 100644
> >> >> --- a/drivers/net/bonding/bond_options.c
> >> >> +++ b/drivers/net/bonding/bond_options.c
> >> >> @@ -625,6 +625,8 @@ int __bond_opt_set(struct bonding *bond,
> >> >> out:
> >> >> if (ret)
> >> >> bond_opt_error_interpret(bond, opt, ret, val);
> >> >> + else
> >> >> + call_netdevice_notifiers(NETDEV_CHANGEINFODATA, bond->dev);
> >> >Is this valuable where the configuration change to the bonding driver
> >> >came from netlink. Do you have a good example why this useful in the
> >> >netlink path as well as when using sysfs? It would seem more logical to
> >> >add call_netdevice_notifiers to bonding_sysfs_store_option so anything
> >> >listening to netlink messages or the netlink cache can know to check for
> >> >changes.
> >>
> >> But this is called for sysfs as well.
> >Sorry for the confusion. I was suggesting that this call is *only* used
> >for sysfs changes not for changes from sysfs and netlink as it would
> >with your patch.
> >
> >> Example of use is that application can monitor rtnetlink to see if for
> >> example active slave changed, or whatever other option changed.
> >Any application monitoring netlink messages will already know about the
> >configuration change if it came down via netlink. There would not be a
> >need for an extra message.
> >
> >My question was: Is there a need for 2 netlink messages to indicate
> >that a bonding configuration change was needed when the config came over
> >netlink. I did not see the need for 2 netlink messages in this case and
> >was asking for clarification from you.
>
> Imagine 2 applications. One is just monitoring netlink events ("ip
> mon"), the second is setting up bond via netlink. Now, the second sends
> a message to kernel, that is unicast to kernel. The first application
> does not see that message. Therefore there is need to generate the event
> message in kernel and send it back to userspace via multicast.
> That message the first application will see. And that is exactly what
> my patch is doing.
Agreed. Thanks for having the discussion on this.
Acked-by: Andy Gospodarek <gospo@cumulusnetworks.com>
>
> >
> >>
> >> >
> >> >>
> >> >> return ret;
> >> >> }
> >> >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> >> >> index 967ddcc..44bc4bd 100644
> >> >> --- a/include/linux/netdevice.h
> >> >> +++ b/include/linux/netdevice.h
> >> >> @@ -2017,6 +2017,7 @@ struct pcpu_sw_netstats {
> >> >> #define NETDEV_CHANGEUPPER 0x0015
> >> >> #define NETDEV_RESEND_IGMP 0x0016
> >> >> #define NETDEV_PRECHANGEMTU 0x0017 /* notify before mtu change happened */
> >> >> +#define NETDEV_CHANGEINFODATA 0x0018
> >> >>
> >> >> int register_netdevice_notifier(struct notifier_block *nb);
> >> >> int unregister_netdevice_notifier(struct notifier_block *nb);
> >> >> --
> >> >> 1.9.3
> >> >>
> >> >> --
> >> >> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >> >> the body of a message to majordomo@vger.kernel.org
> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 4/4] r8152: support firmware files
From: Daniele Forsi @ 2014-08-20 13:32 UTC (permalink / raw)
To: Hayes Wang
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, nic_swsd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, USB list
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB251585A-JIZ+AM9kKNzuvTFwvkocLypo8c9IxeqyAjHCUHv49ws@public.gmane.org>
2014-08-20 14:35 GMT+02:00 Hayes Wang:
> Is this necessary? Besides the check of the "start",
> there are checks of the "size" and rtl_fw_data_ok().
> I think they cover the situations which you indicate.
it's not necessary and it's better checked later as you did!
--
Daniele Forsi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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