* Re: [PATCH net-next 3/5] rhashtable: use future table size to make expansion decision
From: Thomas Graf @ 2015-01-06 10:06 UTC (permalink / raw)
To: Ying Xue
Cc: davem, netdev, jon.maloy, Paul.Gortmaker, erik.hugne,
tipc-discussion
In-Reply-To: <54ABB147.6020904@windriver.com>
On 01/06/15 at 05:56pm, Ying Xue wrote:
> Thank you for above nice explanation. Regarding my understanding, as
> rhashtable_expand() and rhashtable_shrink() are always under the
> protection of "ht->mutex", the "future_tbl" and "tbl" absolutely point
> to the same bucket array once rhashtable_expand() or rhashtable_shrink()
> returns. Therefore, if rht_deferred_worker() takes the "ht->mutex" lock,
> the both "future_tbl" and "tbl" should point to the same bucket array.
> So the change made in the patch is useless for us, right?
Correct.
> But as you pointed in above patch, there is a bug in
> rhashtable_wakeup_worker(). As long as ht->tbl == ht->future_tbl, we
> should wake up the work. OK, I will drop the patch and fix the error in
> patch #2.
Awesome, thanks!
^ permalink raw reply
* Payment
From: Finance Department @ 2015-01-06 8:32 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* IPsec workshop at netdev01?
From: Steffen Klassert @ 2015-01-06 10:19 UTC (permalink / raw)
To: netdev; +Cc: Jamal Hadi Salim, Herbert Xu, David Miller
Is there any interest in doing an IPsec workshop at netdev01?
This mail is to probe if we can gather enough discussion topics to run
such a workshop. So if someone is interested to attend and/or has a
related discussion topic, please let me know.
The idea to do this workshop came yesterday, so I'm still collecting
topics I'm interested in. Some things that came immediately to my mind
are:
- Our IPsec policy/state lookups are still hashlist based on slowpath with
a flowcache to do fast lookups for traffic flows we have already seen.
This flowcache has similar issues like the ipv4 routing chache had.
Is the flowcache an appropriate lookup method on the long run or should
we at least think about an additional alternative lookup method?
- We still lack a 32/64 bit compatibiltiy layer for IPsec, this issue
comes up from time to time. Some solutions were proposed in the past
but all had problems. The current behaviour is broken if someone tries
to configure IPsec with 32 bit tools on a 64 bit machine. Can we get
this right somehow or is it better to just return an error in this case?
- Changing the system time can lead to unexpected SA lifetime changes. The
discussion on the list did not lead to a conclusion on how to fix this.
What is the best way to get this fixed?
- The IPsec policy enforcement default is to allow all flows that don't
match a policy. On systems with a high security level it might be
intersting to configurable invert the default from allow to block. With
the default to block configured, we would need allow policies for all
packet flows we accept. Some people would be even interested in a knob
to enforce a certain default behaviour until the next reboot. Is this
reasonable? How far can we get here?
- A more general thing: How complete is our IPsec implementation? Are there
things that should be implemented but we don't have it?
^ permalink raw reply
* netdev01 conference hotel: Book your room
From: Jamal Hadi Salim @ 2015-01-06 10:38 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Richard Guy Briggs
Folks,
I am told the hotel rooms are going faster than we expected
and the hotel is holding only until Jan 23. Please book
your room now - the price is guaranteed to go up after
the group rate. More details:
https://www.netdev01.org/news/20
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next v3 0/5]: ixgbevf: Allow querying VFs RSS indirection table and key
From: Vlad Zolotarov @ 2015-01-06 10:58 UTC (permalink / raw)
To: Gleb Natapov, Greg Rose; +Cc: netdev, avi, jeffrey.t.kirsher
In-Reply-To: <20150106065535.GM29889@cloudius-systems.com>
On 01/06/15 08:55, Gleb Natapov wrote:
> On Mon, Jan 05, 2015 at 03:54:52PM -0800, Greg Rose wrote:
>> On Mon, Jan 5, 2015 at 6:15 AM, Vlad Zolotarov
>> <vladz@cloudius-systems.com> wrote:
>>> Add the ethtool ops to VF driver to allow querying the RSS indirection table
>>> and RSS Random Key.
>>>
>>> - PF driver: Add new VF-PF channel commands.
>>> - VF driver: Utilize these new commands and add the corresponding
>>> ethtool callbacks.
>>>
>>> New in v3:
>>> - Added a missing support for x550 devices.
>>> - Mask the indirection table values according to PSRTYPE[n].RQPL.
>>> - Minimized the number of added VF-PF commands.
>>>
>>> New in v2:
>>> - Added a detailed description to patches 4 and 5.
>>>
>>> New in v1 (compared to RFC):
>>> - Use "if-else" statement instead of a "switch-case" for a single option case.
>>> More specifically: in cases where the newly added API version is the only one
>>> allowed. We may consider using a "switch-case" back again when the list of
>>> allowed API versions in these specific places grows up.
>>>
>>> Vlad Zolotarov (5):
>>> ixgbe: Add a RETA query command to VF-PF channel API
>>> ixgbevf: Add a RETA query code
>>> ixgbe: Add GET_RSS_KEY command to VF-PF channel commands set
>>> ixgbevf: Add RSS Key query code
>>> ixgbevf: Add the appropriate ethtool ops to query RSS indirection
>>> table and key
>>>
>>> drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 10 ++
>>> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 91 +++++++++++++++
>>> drivers/net/ethernet/intel/ixgbevf/ethtool.c | 43 +++++++
>>> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 +-
>>> drivers/net/ethernet/intel/ixgbevf/mbx.h | 10 ++
>>> drivers/net/ethernet/intel/ixgbevf/vf.c | 132 ++++++++++++++++++++++
>>> drivers/net/ethernet/intel/ixgbevf/vf.h | 2 +
>>> 7 files changed, 291 insertions(+), 1 deletion(-)
>> I've given this code a review and I don't see a way to
>> set a policy in the PF driver as to whether this request should be
>> allowed or not. We cannot enable this query by default - it is a
>> security risk. To make this acceptable you need to do a
>> couple of things.
>>
> Can you please elaborate on the security risk this information poses?
> Is toeplitz hash function cryptographically strong enough so that VF
> cannot reconstruct the hash key from hash result provided in packet
> descriptor? The abstract of this paper [1] claims it is not, but I do
> not have access to the full article unfortunately hence the question.
>
> [1] http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5503170&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5503170
I agree with Gleb here: when we started with just thinking about the
idea of this patch the possible security issue was the first thing that
came into our minds.
But eventually we couldn't come up with any security risk or attack
example that is exclusively caused by the fact that VF knows the
indirection table and/or RSS hash key of the PF.
So, Greg, if we have missed anything and your have such an example could
you share it here, please?
Thanks,
vlad
>
> --
> Gleb.
^ permalink raw reply
* [PATCH 1/6] batman-adv: fix and simplify condition when bonding should be used
From: Antonio Quartulli @ 2015-01-06 11:10 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Simon Wunderlich, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1420542605-28865-1-git-send-email-antonio@meshcoding.com>
From: Simon Wunderlich <sw@simonwunderlich.de>
The current condition actually does NOT consider bonding when the
interface the packet came in from is the soft interface, which is the
opposite of what it should do (and the comment describes). Fix that and
slightly simplify the condition.
Reported-by: Ray Gibson <booray@gmail.com>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/routing.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 35f76f2..6648f32 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -443,11 +443,13 @@ batadv_find_router(struct batadv_priv *bat_priv,
router = batadv_orig_router_get(orig_node, recv_if);
+ if (!router)
+ return router;
+
/* only consider bonding for recv_if == BATADV_IF_DEFAULT (first hop)
* and if activated.
*/
- if (recv_if == BATADV_IF_DEFAULT || !atomic_read(&bat_priv->bonding) ||
- !router)
+ if (!(recv_if == BATADV_IF_DEFAULT && atomic_read(&bat_priv->bonding)))
return router;
/* bonding: loop through the list of possible routers found
--
2.2.1
^ permalink raw reply related
* pull request [net]: batman-adv 20150106
From: Antonio Quartulli @ 2015-01-06 11:09 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hello David,
here you have some small fixes for your 'net' tree.
Patch 1 fixes a regression in the "bonding" code introduced while
implementing the multi-interface optimization feature, by Simon
Wunderlich.
Patch 2 ensures that the "last-seen" timestamp for a newly created
originator object is properly initialised in order to avoid a non-critical
race condition, by Linus Lüssing.
Patch 3 avoids false positive splats when lockdep is enabled by assigning
the proper lock class to locks used by the network coding feature, by
Martin Hundebøll.
Patches 4 and 5 fix the code counting the amount of multicast-disabled
nodes in the network (used to avoid to enable the multicast optimisation
when not possible), by Linus Lüssing.
Patch 6 fixes a memory leak in the Translation Table code that can be
triggered by doubling the current originator interval, by Linus Lüssing.
Please pull or let me know of any problem!
Thanks a lot,
Antonio
The following changes since commit 7ce67a38f799d1fb332f672b117efbadedaa5352:
net: ethernet: cpsw: fix hangs with interrupts (2015-01-04 22:18:34 -0500)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
for you to fetch changes up to 9d31b3ce81683ce3c9fd10afa70892e373b21067:
batman-adv: fix potential TT client + orig-node memory leak (2015-01-06 11:07:01 +0100)
----------------------------------------------------------------
Included changes:
- ensure bonding is used (if enabled) for packets coming in the soft
interface
- fix race condition to avoid orig_nodes to be deleted right after
being added
- avoid false positive lockdep splats by assigning lockclass to
the proper hashtable lock objects
- avoid miscounting of multicast 'disabled' nodes in the network
- fix memory leak in the Global Translation Table in case of
originator interval change
----------------------------------------------------------------
Linus Lüssing (4):
batman-adv: fix delayed foreign originator recognition
batman-adv: fix counter for multicast supporting nodes
batman-adv: fix multicast counter when purging originators
batman-adv: fix potential TT client + orig-node memory leak
Martin Hundebøll (1):
batman-adv: fix lock class for decoding hash in network-coding.c
Simon Wunderlich (1):
batman-adv: fix and simplify condition when bonding should be used
net/batman-adv/multicast.c | 11 +++++++----
net/batman-adv/network-coding.c | 2 +-
net/batman-adv/originator.c | 7 ++++---
net/batman-adv/routing.c | 6 ++++--
4 files changed, 16 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 2/6] batman-adv: fix delayed foreign originator recognition
From: Antonio Quartulli @ 2015-01-06 11:10 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1420542605-28865-1-git-send-email-antonio@meshcoding.com>
From: Linus Lüssing <linus.luessing@c0d3.blue>
Currently it can happen that the reception of an OGM from a new
originator is not being accepted. More precisely it can happen that
an originator struct gets allocated and initialized
(batadv_orig_node_new()), even the TQ gets calculated and set correctly
(batadv_iv_ogm_calc_tq()) but still the periodic orig_node purging
thread will decide to delete it if it has a chance to jump between
these two function calls.
This is because batadv_orig_node_new() initializes the last_seen value
to zero and its caller (batadv_iv_ogm_orig_get()) makes it visible to
other threads by adding it to the hash table already.
batadv_iv_ogm_calc_tq() will set the last_seen variable to the correct,
current time a few lines later but if the purging thread jumps in between
that it will think that the orig_node timed out and will wrongly
schedule it for deletion already.
If the purging interval is the same as the originator interval (which is
the default: 1 second), then this game can continue for several rounds
until the random OGM jitter added enough difference between these
two (in tests, two to about four rounds seemed common).
Fixing this by initializing the last_seen variable of an orig_node
to the current time before adding it to the hash table.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/originator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c
index 6a48451..648bdba 100644
--- a/net/batman-adv/originator.c
+++ b/net/batman-adv/originator.c
@@ -678,6 +678,7 @@ struct batadv_orig_node *batadv_orig_node_new(struct batadv_priv *bat_priv,
atomic_set(&orig_node->last_ttvn, 0);
orig_node->tt_buff = NULL;
orig_node->tt_buff_len = 0;
+ orig_node->last_seen = jiffies;
reset_time = jiffies - 1 - msecs_to_jiffies(BATADV_RESET_PROTECTION_MS);
orig_node->bcast_seqno_reset = reset_time;
#ifdef CONFIG_BATMAN_ADV_MCAST
--
2.2.1
^ permalink raw reply related
* [PATCH 3/6] batman-adv: fix lock class for decoding hash in network-coding.c
From: Antonio Quartulli @ 2015-01-06 11:10 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Martin Hundebøll, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1420542605-28865-1-git-send-email-antonio@meshcoding.com>
From: Martin Hundebøll <martin@hundeboll.net>
batadv_has_set_lock_class() is called with the wrong hash table as first
argument (probably due to a copy-paste error), which leads to false
positives when running with lockdep.
Introduced-by: 612d2b4fe0a1ff2f8389462a6f8be34e54124c05
("batman-adv: network coding - save overheard and tx packets for decoding")
Signed-off-by: Martin Hundebøll <martin@hundeboll.net>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/network-coding.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/network-coding.c b/net/batman-adv/network-coding.c
index 8d04d17..fab47f1 100644
--- a/net/batman-adv/network-coding.c
+++ b/net/batman-adv/network-coding.c
@@ -133,7 +133,7 @@ int batadv_nc_mesh_init(struct batadv_priv *bat_priv)
if (!bat_priv->nc.decoding_hash)
goto err;
- batadv_hash_set_lock_class(bat_priv->nc.coding_hash,
+ batadv_hash_set_lock_class(bat_priv->nc.decoding_hash,
&batadv_nc_decoding_hash_lock_class_key);
INIT_DELAYED_WORK(&bat_priv->nc.work, batadv_nc_worker);
--
2.2.1
^ permalink raw reply related
* [PATCH 4/6] batman-adv: fix counter for multicast supporting nodes
From: Antonio Quartulli @ 2015-01-06 11:10 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1420542605-28865-1-git-send-email-antonio@meshcoding.com>
From: Linus Lüssing <linus.luessing@c0d3.blue>
A miscounting of nodes having multicast optimizations enabled can lead
to multicast packet loss in the following scenario:
If the first OGM a node receives from another one has no multicast
optimizations support (no multicast tvlv) then we are missing to
increase the counter. This potentially leads to the wrong assumption
that we could safely use multicast optimizations.
Fixings this by increasing the counter if the initial OGM has the
multicast TVLV unset, too.
Introduced by 60432d756cf06e597ef9da511402dd059b112447
("batman-adv: Announce new capability via multicast TVLV")
Reported-by: Tobias Hachmer <tobias@hachmer.de>
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/multicast.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/multicast.c b/net/batman-adv/multicast.c
index ab6bb2a..d3503fb 100644
--- a/net/batman-adv/multicast.c
+++ b/net/batman-adv/multicast.c
@@ -685,11 +685,13 @@ static void batadv_mcast_tvlv_ogm_handler_v1(struct batadv_priv *bat_priv,
if (orig_initialized)
atomic_dec(&bat_priv->mcast.num_disabled);
orig->capabilities |= BATADV_ORIG_CAPA_HAS_MCAST;
- /* If mcast support is being switched off increase the disabled
- * mcast node counter.
+ /* If mcast support is being switched off or if this is an initial
+ * OGM without mcast support then increase the disabled mcast
+ * node counter.
*/
} else if (!orig_mcast_enabled &&
- orig->capabilities & BATADV_ORIG_CAPA_HAS_MCAST) {
+ (orig->capabilities & BATADV_ORIG_CAPA_HAS_MCAST ||
+ !orig_initialized)) {
atomic_inc(&bat_priv->mcast.num_disabled);
orig->capabilities &= ~BATADV_ORIG_CAPA_HAS_MCAST;
}
--
2.2.1
^ permalink raw reply related
* [PATCH 5/6] batman-adv: fix multicast counter when purging originators
From: Antonio Quartulli @ 2015-01-06 11:10 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1420542605-28865-1-git-send-email-antonio@meshcoding.com>
From: Linus Lüssing <linus.luessing@c0d3.blue>
When purging an orig_node we should only decrease counter tracking the
number of nodes without multicast optimizations support if it was
increased through this orig_node before.
A not yet quite initialized orig_node (meaning it did not have its turn
in the mcast-tvlv handler so far) which gets purged would not adhere to
this and will lead to a counter imbalance.
Fixing this by adding a check whether the orig_node is mcast-initalized
before decreasing the counter in the mcast-orig_node-purging routine.
Introduced by 60432d756cf06e597ef9da511402dd059b112447
("batman-adv: Announce new capability via multicast TVLV")
Reported-by: Tobias Hachmer <tobias@hachmer.de>
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/multicast.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/batman-adv/multicast.c b/net/batman-adv/multicast.c
index d3503fb..b24e4bb 100644
--- a/net/batman-adv/multicast.c
+++ b/net/batman-adv/multicast.c
@@ -740,7 +740,8 @@ void batadv_mcast_purge_orig(struct batadv_orig_node *orig)
{
struct batadv_priv *bat_priv = orig->bat_priv;
- if (!(orig->capabilities & BATADV_ORIG_CAPA_HAS_MCAST))
+ if (!(orig->capabilities & BATADV_ORIG_CAPA_HAS_MCAST) &&
+ orig->capa_initialized & BATADV_ORIG_CAPA_HAS_MCAST)
atomic_dec(&bat_priv->mcast.num_disabled);
batadv_mcast_want_unsnoop_update(bat_priv, orig, BATADV_NO_FLAGS);
--
2.2.1
^ permalink raw reply related
* [PATCH 6/6] batman-adv: fix potential TT client + orig-node memory leak
From: Antonio Quartulli @ 2015-01-06 11:10 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1420542605-28865-1-git-send-email-antonio@meshcoding.com>
From: Linus Lüssing <linus.luessing@c0d3.blue>
This patch fixes a potential memory leak which can occur once an
originator times out. On timeout the according global translation table
entry might not get purged correctly. Furthermore, the non purged TT
entry will cause its orig-node to leak, too. Which additionally can lead
to the new multicast optimization feature not kicking in because of a
therefore bogus counter.
In detail: The batadv_tt_global_entry->orig_list holds the reference to
the orig-node. Usually this reference is released after
BATADV_PURGE_TIMEOUT through: _batadv_purge_orig()->
batadv_purge_orig_node()->batadv_update_route()->_batadv_update_route()->
batadv_tt_global_del_orig() which purges this global tt entry and
releases the reference to the orig-node.
However, if between two batadv_purge_orig_node() calls the orig-node
timeout grew to 2*BATADV_PURGE_TIMEOUT then this call path isn't
reached. Instead the according orig-node is removed from the
originator hash in _batadv_purge_orig(), the batadv_update_route()
part is skipped and won't be reached anymore.
Fixing the issue by moving batadv_tt_global_del_orig() out of the rcu
callback.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Acked-by: Antonio Quartulli <antonio@meshcoding.com>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
net/batman-adv/originator.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c
index 648bdba..bea8198 100644
--- a/net/batman-adv/originator.c
+++ b/net/batman-adv/originator.c
@@ -570,9 +570,6 @@ static void batadv_orig_node_free_rcu(struct rcu_head *rcu)
batadv_frag_purge_orig(orig_node, NULL);
- batadv_tt_global_del_orig(orig_node->bat_priv, orig_node, -1,
- "originator timed out");
-
if (orig_node->bat_priv->bat_algo_ops->bat_orig_free)
orig_node->bat_priv->bat_algo_ops->bat_orig_free(orig_node);
@@ -978,6 +975,9 @@ static void _batadv_purge_orig(struct batadv_priv *bat_priv)
if (batadv_purge_orig_node(bat_priv, orig_node)) {
batadv_gw_node_delete(bat_priv, orig_node);
hlist_del_rcu(&orig_node->hash_entry);
+ batadv_tt_global_del_orig(orig_node->bat_priv,
+ orig_node, -1,
+ "originator timed out");
batadv_orig_node_free_ref(orig_node);
continue;
}
--
2.2.1
^ permalink raw reply related
* [PATCH_V3] dm9000: Add regulator and reset support to dm9000
From: Zubair Lutfullah Kakakhel @ 2015-01-06 11:15 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ
In boards, the dm9000 chip's power and reset can be controlled by gpio.
It makes sense to add them to the dm9000 driver and let dt be used to
enable power and reset the phy.
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Paul Burton <paul.burton-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
---
V2 A few fixes and more error checks. Nothing major
V1 Minor blooper
---
.../devicetree/bindings/net/davicom-dm9000.txt | 4 +++
drivers/net/ethernet/davicom/dm9000.c | 41 ++++++++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
index 28767ed..5224bf0 100644
--- a/Documentation/devicetree/bindings/net/davicom-dm9000.txt
+++ b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
@@ -11,6 +11,8 @@ Required properties:
Optional properties:
- davicom,no-eeprom : Configuration EEPROM is not available
- davicom,ext-phy : Use external PHY
+- reset-gpios : phandle of gpio that will be used to reset chip during probe
+- vcc-supply : phandle of regulator that will be used to enable power to chip
Example:
@@ -21,4 +23,6 @@ Example:
interrupts = <7 4>;
local-mac-address = [00 00 de ad be ef];
davicom,no-eeprom;
+ reset-gpios = <&gpf 12 GPIO_ACTIVE_LOW>;
+ vcc-supply = <ð0_power>;
};
diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
index ef0bb58..246c89d 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -36,6 +36,9 @@
#include <linux/platform_device.h>
#include <linux/irq.h>
#include <linux/slab.h>
+#include <linux/regulator/consumer.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <asm/delay.h>
#include <asm/irq.h>
@@ -1426,11 +1429,49 @@ dm9000_probe(struct platform_device *pdev)
struct dm9000_plat_data *pdata = dev_get_platdata(&pdev->dev);
struct board_info *db; /* Point a board information structure */
struct net_device *ndev;
+ struct device *dev = &pdev->dev;
const unsigned char *mac_src;
int ret = 0;
int iosize;
int i;
u32 id_val;
+ int reset_gpios;
+ enum of_gpio_flags flags;
+ struct regulator *power;
+
+ power = devm_regulator_get(dev, "vcc");
+ if (PTR_ERR(power) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ if (IS_ERR(power)) {
+ dev_dbg(dev, "no regulator provided\n");
+ } else {
+ ret = regulator_enable(power);
+ if (ret != 0) {
+ dev_err(dev,
+ "Failed to enable power regulator: %d\n", ret);
+ return ret;
+ }
+ dev_dbg(dev, "regulator enabled\n");
+ }
+
+ reset_gpios = of_get_named_gpio_flags(dev->of_node, "reset-gpios", 0,
+ &flags);
+ if (gpio_is_valid(reset_gpios)) {
+ ret = devm_gpio_request_one(dev, reset_gpios, flags,
+ "dm9000_reset");
+ if (ret) {
+ dev_err(dev, "failed to request reset gpio %d: %d\n",
+ reset_gpios, ret);
+ return -ENODEV;
+ }
+
+ gpio_direction_output(reset_gpios, 0);
+ /* According to manual PWRST# Low Period Min 1ms */
+ msleep(2);
+ gpio_set_value(reset_gpios, 1);
+ /* Needs 3ms to read eeprom when PWRST is deasserted */
+ msleep(4);
+ }
if (!pdata) {
pdata = dm9000_parse_dt(&pdev->dev);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 related
* Re: IPsec workshop at netdev01?
From: Jamal Hadi Salim @ 2015-01-06 11:15 UTC (permalink / raw)
To: Steffen Klassert, netdev; +Cc: Herbert Xu, David Miller, Shrijeet Mukherjee
In-Reply-To: <20150106101936.GC31458@secunet.com>
On 01/06/15 05:19, Steffen Klassert wrote:
> Is there any interest in doing an IPsec workshop at netdev01?
>
> This mail is to probe if we can gather enough discussion topics to run
> such a workshop. So if someone is interested to attend and/or has a
> related discussion topic, please let me know.
>
For the record I would attend if you had it.
Additional topic that maybe of interest is:
on hardware offload of crypto as well as keying(RSA etc).
I know we have some stuff in place - but a lot of these new
devices are going on tangents doing their own thing. So perhaps
some guidance would help. That specific topic maybe overlapping
with the BOF Shrijeet is organizing - but there we are still
talking about L2/3 and ACLs and an ipsec discussion could
be, at the moment, off topic.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next v1 0/3] net: fec: add Wake-on-LAN support
From: Shawn Guo @ 2015-01-06 11:21 UTC (permalink / raw)
To: David Miller; +Cc: b38611, netdev, bhutchings, stephen
In-Reply-To: <20141231.130727.1660985956287926494.davem@davemloft.net>
On Wed, Dec 31, 2014 at 01:07:27PM -0500, David Miller wrote:
> From: Fugang Duan <b38611@freescale.com>
> Date: Wed, 24 Dec 2014 17:30:38 +0800
>
> > The patch series enable FEC Wake-on-LAN feature for i.MX6q/dl and i.MX6SX SOCs.
> > FEC HW support sleep mode, when system in suspend status with FEC all clock gate
> > off, magic packet can wake up system. For different SOCs, there have special SOC
> > GPR register to let FEC enter sleep mode or exit sleep mode, add these to platform
> > callback for driver' call.
> >
> > Patch#1: add WOL interface supports.
> > Patch#2: add SOC special sleep of/off operations for driver's sleep callback.
> > Patch#3: add magic pattern support for devicetree.
>
> Series applied, thanks.
I'm not sure you want to take the last two patches. Doing so will
likely causes merge conflict between net and arm-soc tree.
Shawn
^ permalink raw reply
* Re: [PATCH v4] can: Convert to runtime_pm
From: Marc Kleine-Budde @ 2015-01-06 11:25 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao, Soren Brinkmann
Cc: wg@grandegger.com, Michal Simek, grant.likely@linaro.org,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <7324bcf422d141f0b09f0cc0e8352479@BN1BFFO11FD005.protection.gbl>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
On 01/06/2015 07:23 AM, Appana Durga Kedareswara Rao wrote:
> Hi Marc,
>
> Could you please provide your feedback on this patch ?
>
> @Soren : Will update the driver with your comments during next version of the patch.
Sure, I'll return from my season holidays and will be in the office
tomorrow.
Marc
--
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: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v1 2/3] ARM: imx: add FEC sleep mode callback function
From: Shawn Guo @ 2015-01-06 11:48 UTC (permalink / raw)
To: Fugang Duan; +Cc: davem, netdev, bhutchings, stephen
In-Reply-To: <1419413441-3406-3-git-send-email-b38611@freescale.com>
On Wed, Dec 24, 2014 at 05:30:40PM +0800, Fugang Duan wrote:
> i.MX6q/dl, i.MX6SX SOCs enet support sleep mode that magic packet can
> wake up system in suspend status. For different SOCs, there have some
> SOC specifical GPR register to set sleep on/off mode. So add these to
> callback function for driver.
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
I do not like this patch. In the end, this is just a GRP register bit
setup per FEC driver need. Rather than messing up platform code for
each SoC with the same pattern, I do not see why this can not be done by
FEC driver itself.
You can take a look at LDB driver (drivers/gpu/drm/imx/imx-ldb.c) to see
how this can be done.
Shawn
> ---
> arch/arm/mach-imx/mach-imx6q.c | 41 +++++++++++++++++++++++++++++++-
> arch/arm/mach-imx/mach-imx6sx.c | 50 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 90 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index 5057d61..2f76168 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -31,6 +31,8 @@
> #include <linux/micrel_phy.h>
> #include <linux/mfd/syscon.h>
> #include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> +#include <linux/fec.h>
> +#include <linux/netdevice.h>
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
> #include <asm/system_misc.h>
> @@ -39,6 +41,35 @@
> #include "cpuidle.h"
> #include "hardware.h"
>
> +static struct fec_platform_data fec_pdata;
> +
> +static void imx6q_fec_sleep_enable(int enabled)
> +{
> + struct regmap *gpr;
> +
> + gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
> + if (!IS_ERR(gpr)) {
> + if (enabled)
> + regmap_update_bits(gpr, IOMUXC_GPR13,
> + IMX6Q_GPR13_ENET_STOP_REQ,
> + IMX6Q_GPR13_ENET_STOP_REQ);
> +
> + else
> + regmap_update_bits(gpr, IOMUXC_GPR13,
> + IMX6Q_GPR13_ENET_STOP_REQ, 0);
> + } else
> + pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n");
> +}
> +
> +static void __init imx6q_enet_plt_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_node_by_path("/soc/aips-bus@02100000/ethernet@02188000");
> + if (np && of_get_property(np, "fsl,magic-packet", NULL))
> + fec_pdata.sleep_mode_enable = imx6q_fec_sleep_enable;
> +}
> +
> /* For imx6q sabrelite board: set KSZ9021RN RGMII pad skew */
> static int ksz9021rn_phy_fixup(struct phy_device *phydev)
> {
> @@ -261,6 +292,12 @@ static void __init imx6q_axi_init(void)
> }
> }
>
> +/* Add auxdata to pass platform data */
> +static const struct of_dev_auxdata imx6q_auxdata_lookup[] __initconst = {
> + OF_DEV_AUXDATA("fsl,imx6q-fec", 0x02188000, NULL, &fec_pdata),
> + { /* sentinel */ }
> +};
> +
> static void __init imx6q_init_machine(void)
> {
> struct device *parent;
> @@ -274,11 +311,13 @@ static void __init imx6q_init_machine(void)
>
> imx6q_enet_phy_init();
>
> - of_platform_populate(NULL, of_default_bus_match_table, NULL, parent);
> + of_platform_populate(NULL, of_default_bus_match_table,
> + imx6q_auxdata_lookup, parent);
>
> imx_anatop_init();
> cpu_is_imx6q() ? imx6q_pm_init() : imx6dl_pm_init();
> imx6q_1588_init();
> + imx6q_enet_plt_init();
> imx6q_axi_init();
> }
>
> diff --git a/arch/arm/mach-imx/mach-imx6sx.c b/arch/arm/mach-imx/mach-imx6sx.c
> index 7a96c65..747b012 100644
> --- a/arch/arm/mach-imx/mach-imx6sx.c
> +++ b/arch/arm/mach-imx/mach-imx6sx.c
> @@ -12,12 +12,62 @@
> #include <linux/regmap.h>
> #include <linux/mfd/syscon.h>
> #include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
> +#include <linux/fec.h>
> +#include <linux/netdevice.h>
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
>
> #include "common.h"
> #include "cpuidle.h"
>
> +static struct fec_platform_data fec_pdata[2];
> +
> +static void imx6sx_fec1_sleep_enable(int enabled)
> +{
> + struct regmap *gpr;
> +
> + gpr = syscon_regmap_lookup_by_compatible("fsl,imx6sx-iomuxc-gpr");
> + if (!IS_ERR(gpr)) {
> + if (enabled)
> + regmap_update_bits(gpr, IOMUXC_GPR4,
> + IMX6SX_GPR4_FEC_ENET1_STOP_REQ,
> + IMX6SX_GPR4_FEC_ENET1_STOP_REQ);
> + else
> + regmap_update_bits(gpr, IOMUXC_GPR4,
> + IMX6SX_GPR4_FEC_ENET1_STOP_REQ, 0);
> + } else
> + pr_err("failed to find fsl,imx6sx-iomux-gpr regmap\n");
> +}
> +
> +static void imx6sx_fec2_sleep_enable(int enabled)
> +{
> + struct regmap *gpr;
> +
> + gpr = syscon_regmap_lookup_by_compatible("fsl,imx6sx-iomuxc-gpr");
> + if (!IS_ERR(gpr)) {
> + if (enabled)
> + regmap_update_bits(gpr, IOMUXC_GPR4,
> + IMX6SX_GPR4_FEC_ENET2_STOP_REQ,
> + IMX6SX_GPR4_FEC_ENET2_STOP_REQ);
> + else
> + regmap_update_bits(gpr, IOMUXC_GPR4,
> + IMX6SX_GPR4_FEC_ENET2_STOP_REQ, 0);
> + } else
> + pr_err("failed to find fsl,imx6sx-iomux-gpr regmap\n");
> +}
> +
> +static void __init imx6sx_enet_plt_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_node_by_path("/soc/aips-bus@02100000/ethernet@02188000");
> + if (np && of_get_property(np, "fsl,magic-packet", NULL))
> + fec_pdata[0].sleep_mode_enable = imx6sx_fec1_sleep_enable;
> + np = of_find_node_by_path("/soc/aips-bus@02100000/ethernet@021b4000");
> + if (np && of_get_property(np, "fsl,magic-packet", NULL))
> + fec_pdata[1].sleep_mode_enable = imx6sx_fec2_sleep_enable;
> +}
> +
> static int ar8031_phy_fixup(struct phy_device *dev)
> {
> u16 val;
> --
> 1.7.8
>
^ permalink raw reply
* [PATCH net-next] cxgb4: Add PCI device ID for new T5 adapter
From: Hariprasad Shenai @ 2015-01-06 12:01 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, nirranjan, Hariprasad Shenai
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
index 9e4f95a..ddfb5b8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
@@ -153,6 +153,7 @@ CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
CH_PCI_ID_TABLE_FENTRY(0x5086), /* Custom 2x T580-CR */
CH_PCI_ID_TABLE_FENTRY(0x5087), /* Custom T580-CR */
CH_PCI_ID_TABLE_FENTRY(0x5088), /* Custom T570-CR */
+ CH_PCI_ID_TABLE_FENTRY(0x5089), /* Custom T520-CR */
CH_PCI_DEVICE_ID_TABLE_DEFINE_END;
#endif /* CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN */
--
1.7.1
^ permalink raw reply related
* pull-request: mac80211 2015-01-06
From: Johannes Berg @ 2015-01-06 12:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Here's just a single fix - a revert of a patch that broke the
p54 and cw2100 drivers (arguably due to bad assumptions there.)
Since this affects kernels since 3.17, I decided to revert for
now and we'll revisit this optimisation properly for -next.
Also -- happy New Year, and sorry about the genl issue :(
I'm still a bit confused about whether you wanted the pull request with
the text in the email or in the tag, or branch, or something - I
interpreted what you said to Kalle differently to what you said to me.
I've duplicated it for now :)
Thanks,
johannes
The following changes since commit 28a9bc68124c319b2b3dc861e80828a8865fd1ba:
mac80211: free management frame keys when removing station (2014-12-17 14:00:17 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2015-01-06
for you to fetch changes up to 1e359a5de861a57aa04d92bb620f52a5c1d7f8b1:
Revert "mac80211: Fix accounting of the tailroom-needed counter" (2015-01-05 10:33:46 +0100)
----------------------------------------------------------------
Here's just a single fix - a revert of a patch that broke the
p54 and cw2100 drivers (arguably due to bad assumptions there.)
Since this affects kernels since 3.17, I decided to revert for
now and we'll revisit this optimisation properly for -next.
----------------------------------------------------------------
Johannes Berg (1):
Revert "mac80211: Fix accounting of the tailroom-needed counter"
include/net/mac80211.h | 7 ++-----
net/mac80211/key.c | 12 +++++++++---
2 files changed, 11 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next PATCH v1 00/11] A flow API
From: Jamal Hadi Salim @ 2015-01-06 12:23 UTC (permalink / raw)
To: John Fastabend, tgraf, sfeldma, jiri, simon.horman
Cc: netdev, davem, andy, Shrijeet Mukherjee
In-Reply-To: <20141231194057.31070.5244.stgit@nitbit.x32>
John,
There are a lot of things to digest in your posting - I am interested
in commenting on many things but feel need to pay attention to details
in general given the importance of this interface (and conference is
chewing my netdev time at the moment). I need to actually sit down
and stare at code and documentation.
I do think we need to have this discussion as part of the BOF
Shrijeet is running at netdev01.
General comments:
1) one of the things that i have learnt over time is that not
everything that sits or is abstracted from hardware is a table.
You could have structs or simple scalars for config or runtime
control. How does what you are proposing here allow to express that?
I dont think you'd need it for simple things but if you dont allow
for it you run into the square-hole-round-peg syndrome of "yeah
i can express that u32 variable as a single table with a single row
and a single column" ;-> or "you need another infrastructure for
that single scalr u32"
2) So i understood the sense of replacing ethtool for classifier
access with a direct interface mostly because thats what it was
already doing - but i am not sure why you need
it for a generic interface. Am i mistaken you are providing direct
access to hardware from user space? Would this make essentially
the Linux infrastructure a bypass (which vendors and their SDKs
love)? IMHO, a good example is to pick something like netfilter
or tc-filters and show how that is offloaded. This keeps it in
the same spirit as what we are shooting for in L2/3 at the moment.
Anyways I apologize i havent spent as much time (holiday period
wasnt good for me and netdev01 is picking up and consuming my time
but i will try my best to respond and comment with some latency)
cheers,
jamal
On 12/31/14 14:45, John Fastabend wrote:
> So... I could continue to mull over this and tweak bits and pieces
> here and there but I decided its best to get a wider group of folks
> looking at it and hopefulyl with any luck using it so here it is.
>
> This set creates a new netlink family and set of messages to configure
> flow tables in hardware. I tried to make the commit messages
> reasonably verbose at least in the flow_table patches.
>
> What we get at the end of this series is a working API to get device
> capabilities and program flows using the rocker switch.
>
> I created a user space tool 'flow' that I use to configure and query
> the devices it is posted here,
>
> https://github.com/jrfastab/iprotue2-flow-tool
>
> For now it is a stand-alone tool but once the kernel bits get sorted
> out (I'm guessing there will need to be a few versions of this series
> to get it right) I would like to port it into the iproute2 package.
> This way we can keep all of our tooling in one package see 'bridge'
> for example.
>
> As far as testing, I've tested various combinations of tables and
> rules on the rocker switch and it seems to work. I have not tested
> 100% of the rocker code paths though. It would be great to get some
> sort of automated framework around the API to do this. I don't
> think should gate the inclusion of the API though.
>
> I could use some help reviewing,
>
> (a) error paths and netlink validation code paths
>
> (b) Break down of structures vs netlink attributes. I
> am trying to balance flexibility given by having
> netlinnk TLV attributes vs conciseness. So some
> things are passed as structures.
>
> (c) are there any devices that have pipelines that we
> can't represent with this API? It would be good to
> know about these so we can design it in probably
> in a future series.
>
> For some examples and maybe a bit more illustrative description I
> posted a quickly typed up set of notes on github io pages. Here we
> can show the description along with images produced by the flow tool
> showing the pipeline. Once we settle a bit more on the API we should
> probably do a clean up of this and other threads happening and commit
> something to the Documentation directory.
>
> http://jrfastab.github.io/jekyll/update/2014/12/21/flow-api.html
>
> Finally I have more patches to add support for creating and destroying
> tables. This allows users to define the pipeline at runtime rather
> than statically as rocker does now. After this set gets some traction
> I'll look at pushing them in a next round. However it likely requires
> adding another "world" to rocker. Another piece that I want to add is
> a description of the actions and metadata. This way user space can
> "learn" what an action is and how metadata interacts with the system.
> This work is under development.
>
> Thanks! Any comments/feedback always welcome.
>
> And also thanks to everyone who helped with this flow API so far. All
> the folks at Dusseldorf LPC, OVS summit Santa Clara, P4 authors for
> some inspiration, the collection of IETF FoRCES documents I mulled
> over, Netfilter workshop where I started to realize fixing ethtool
> was most likely not going to work, etc.
>
> ---
>
> John Fastabend (11):
> net: flow_table: create interface for hw match/action tables
> net: flow_table: add flow, delete flow
> net: flow_table: add apply action argument to tables
> rocker: add pipeline model for rocker switch
> net: rocker: add set flow rules
> net: rocker: add group_id slices and drop explicit goto
> net: rocker: add multicast path to bridging
> net: rocker: add get flow API operation
> net: rocker: add cookie to group acls and use flow_id to set cookie
> net: rocker: have flow api calls set cookie value
> net: rocker: implement delete flow routine
>
>
> drivers/net/ethernet/rocker/rocker.c | 1641 +++++++++++++++++++++++++
> drivers/net/ethernet/rocker/rocker_pipeline.h | 793 ++++++++++++
> include/linux/if_flow.h | 115 ++
> include/linux/netdevice.h | 20
> include/uapi/linux/if_flow.h | 413 ++++++
> net/Kconfig | 7
> net/core/Makefile | 1
> net/core/flow_table.c | 1339 ++++++++++++++++++++
> 8 files changed, 4312 insertions(+), 17 deletions(-)
> create mode 100644 drivers/net/ethernet/rocker/rocker_pipeline.h
> create mode 100644 include/linux/if_flow.h
> create mode 100644 include/uapi/linux/if_flow.h
> create mode 100644 net/core/flow_table.c
>
^ permalink raw reply
* Re: route/max_size sysctl in ipv4
From: Pádraig Brady @ 2015-01-06 12:41 UTC (permalink / raw)
To: Ani Sinha, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <CAOxq_8OysjN8OrvhM13t3YUuyh5O=KM_mptR=NHieq146mqZ8g@mail.gmail.com>
On 06/01/15 00:56, Ani Sinha wrote:
> On Mon, Jan 5, 2015 at 4:51 PM, David Miller <davem@davemloft.net> wrote:
>> From: Ani Sinha <ani@arista.com>
>> Date: Mon, 5 Jan 2015 16:43:30 -0800
>>
>>> On Mon, Jan 5, 2015 at 4:36 PM, David Miller <davem@davemloft.net> wrote:
>>>> From: Ani Sinha <ani@arista.com>
>>>> Date: Mon, 5 Jan 2015 15:48:11 -0800
>>>>
>>>>> I am looking at the code and it looks like since the route cache for
>>>>> ipv4 was removed from the kernel, this sysctl parameter no longer
>>>>> serves the same purpose. It does not look like it is even used in the
>>>>> ipv4/route.c module. Is there an equivalent sysctl parameter limiting
>>>>> the number of route entries in the kernel? Or is there now no
>>>>> mechanism to limit the number of route entries?
>>>>
>>>> There is nothing to limit, since the cache was removed.
>>>
>>> Shouldn't the documentation be updated to reflect that? Also what's
>>> the point of having a dummy variable that does nothing? Should we not
>>> simply remove it?
>>
>> There is nothing to update, the behavior is completely transparent.
>> Absolutely no cache entries exist, therefore the limit cannot be
>> reached.
>
> I disagree. You are advertising a feature in an official documentation
> that simply does not exist for ipv4. This is very confusing. If I did
> not dig into the code, I wouldn't know that this particular knob is a
> noop since the time the route cache was removed.
You can't change APIs with impunity.
>> The sysctl is kept so that scripts reading it don't suddenly stop
>> working. We can't just remove sysctl values.
Perhaps /proc/sys/net/ipv4/route/max_size should always return 0 when read,
and discard written values?
thanks,
Pádraig
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Jiri Slaby @ 2015-01-06 12:56 UTC (permalink / raw)
To: Julian Anastasov, Smart Weblications GmbH - Florian Wiessner
Cc: Steffen Klassert, netdev, LKML, stable, Simon Horman, lvs-devel
In-Reply-To: <alpine.LFD.2.11.1412132211260.3229@ja.home.ssi.bg>
On 12/13/2014, 09:19 PM, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 11 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
>
>>>> [ 512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5
>>>
>>> Above "#5" is same as previous oops. It means kernel
>>> is not updated. Or you updated only the IPVS modules after
>>> applying the both patches?
>>
>> I did it with make-kpkg --initrd linux_image which only rebuilt the modules,
>> correct. I can retry with make clean before building the package
>
> I just tested PASV and PORT with 3.12.33 including
> both patches (seq adj fix + ip_route_me_harder fix) and do not
> see any crashes in nf_ct_seqadj_set. If you still have problem
> with FTP send me more info offlist.
>
>>> You can also try without FTP tests to see if there
>>> are oopses in xfrm, so that we can close this topic and then
>>> to continue for the FTP problem on IPVS lists without
>>> bothering non-IPVS people.
>>>
>>
>> yeah, it seems that the xfrm issue is away.
>
> Thanks for the confirmation!
Great! Thanks for tracking it down.
So what should be done to fix the issue in stable 3.12? Are those
patches needed in the upstream kernel too? In that case I suppose it
will propagate to me through upstream. Otherwise, could you send "3.12
only" patches to stable@ so that I can apply them?
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH_V3] dm9000: Add regulator and reset support to dm9000
From: Sergei Shtylyov @ 2015-01-06 12:57 UTC (permalink / raw)
To: Zubair Lutfullah Kakakhel, davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1420542916-30169-1-git-send-email-Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Hello.
On 1/6/2015 2:15 PM, Zubair Lutfullah Kakakhel wrote:
> In boards, the dm9000 chip's power and reset can be controlled by gpio.
> It makes sense to add them to the dm9000 driver and let dt be used to
> enable power and reset the phy.
> Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Paul Burton <paul.burton-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
[...]
> diff --git a/drivers/net/ethernet/davicom/dm9000.c b/drivers/net/ethernet/davicom/dm9000.c
> index ef0bb58..246c89d 100644
> --- a/drivers/net/ethernet/davicom/dm9000.c
> +++ b/drivers/net/ethernet/davicom/dm9000.c
[...]
> @@ -1426,11 +1429,49 @@ dm9000_probe(struct platform_device *pdev)
> struct dm9000_plat_data *pdata = dev_get_platdata(&pdev->dev);
> struct board_info *db; /* Point a board information structure */
> struct net_device *ndev;
> + struct device *dev = &pdev->dev;
> const unsigned char *mac_src;
> int ret = 0;
> int iosize;
> int i;
> u32 id_val;
> + int reset_gpios;
> + enum of_gpio_flags flags;
> + struct regulator *power;
> +
> + power = devm_regulator_get(dev, "vcc");
> + if (PTR_ERR(power) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
Line over-indented.
[...]
> + reset_gpios = of_get_named_gpio_flags(dev->of_node, "reset-gpios", 0,
> + &flags);
> + if (gpio_is_valid(reset_gpios)) {
> + ret = devm_gpio_request_one(dev, reset_gpios, flags,
> + "dm9000_reset");
> + if (ret) {
> + dev_err(dev, "failed to request reset gpio %d: %d\n",
> + reset_gpios, ret);
> + return -ENODEV;
> + }
> +
> + gpio_direction_output(reset_gpios, 0);
You could skip this call as devm_gpio_request_one() can handle that for you.
[...]
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* [PATCH net-next] arm_arch_timer: include clocksource.h directly
From: Richard Cochran @ 2015-01-06 13:26 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, David Miller, Guenter Roeck
This driver makes use of the clocksource code. Previously it had only
included the proper header indirectly, but that chain was inadvertently
broken by 74d23cc "time: move the timecounter/cyclecounter code into its
own file."
This patch fixes the issue by including clocksource.h directly.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/clocksource/arm_arch_timer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 6a79fc4..8e67e72 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -15,6 +15,7 @@
#include <linux/cpu.h>
#include <linux/cpu_pm.h>
#include <linux/clockchips.h>
+#include <linux/clocksource.h>
#include <linux/interrupt.h>
#include <linux/of_irq.h>
#include <linux/of_address.h>
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] Revert "ipw2200: select CFG80211_WEXT"
From: Johannes Berg @ 2015-01-06 13:26 UTC (permalink / raw)
To: Paul Bolle
Cc: Arend van Spriel, Linus Torvalds, Marcel Holtmann,
Stanislav Yakovlev, Kalle Valo, Jiri Kosina, linux-wireless,
Network Development, Linux Kernel Mailing List
In-Reply-To: <1420532617.1966.2.camel@sipsolutions.net>
On Tue, 2015-01-06 at 09:23 +0100, Johannes Berg wrote:
> Yours is the theoretical, hopefully-forward-looking one where we still
> expect the driver to actually be modified to take advantage of the new
> frameworks (which is independent of wext support towards userspace). In
> that scenario, yes, it should use more until it uses all, and then it
> can stop concerning itself with wext (which would be a win because
> driver/wext interaction is always finicky) (*)
I just realized that in order to actually do this you'd have to revert
04b0c5c6995103eef56391c163e970ab1f03b59f first, but that would be pretty
simple.
johannes
^ 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