* [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
* Re: Possible BUG in ipv6_find_hdr function for fragmented packets
From: Hannes Frederic Sowa @ 2015-01-06 13:31 UTC (permalink / raw)
To: Rahul Sharma; +Cc: netdev
In-Reply-To: <CAFB3abyNNpMbX-XbJbVRNr98ns3w7VqEveiRqg2S__DrvZjT3Q@mail.gmail.com>
Hi Rahul,
On Mi, 2014-12-31 at 12:33 +0530, Rahul Sharma wrote:
> I have observed a problem when I added an AH header before protocol
> header (OSPFv3) while implementing authentication support for OSPFv3.
>
> Problem: Fragmented packets which include authentication header don't
> get reassembled in the kernel. This was because ipv6_find_hdr returns
> ENOENT for the non-first fragment since AH is an extension header.
>
> Firstly, this comment "Note that non-1st fragment is special case
> that "the protocol number of last header" is "next header" field in
> Fragment header" ('last header' doesn't include AH or other extension
> headers) before ipv6_find_hdr looks incorrect as per the description
> of the fragmentation process in RFC2460. The rfc clearly states that
> next header value in the fragments will be the first header of the
> Fragmentable part of the original packet which could be AH (51) as in
> our case.
>
> This code looks like a problem:
> if (_frag_off) {
> 253 if (target < 0 &&
> 254 ((!ipv6_ext_hdr(hp->nexthdr)) ||
> 255 hp->nexthdr == NEXTHDR_NONE)) {
> 256 if (fragoff)
> 257 *fragoff = _frag_off;
> 258 return hp->nexthdr;
> 259 }
> 260 return -ENOENT;
> 261 }
>
> For non-first fragments, the 'next header' in the fragment header
> would *always* be AUTH (or whatever extension header is the first
> header in first fragment). But the above code will keep on returning
> ENOENT for the non-first fragment in such cases.
>
> Solution: I suggest we should get away with this check
> ((!ipv6_ext_hdr(hp->nexthdr)) ||hp->nexthdr == NEXTHDR_NONE)) and
> simply return hp->nexthdr if the _frag_off is non zero. I tested it on
> my machine and it works. Adding an special case for NEXTHDR_AUTH also
> works for me.
The packets do get dropped in netfilter code? Do you have any idea were
specifically?
Your suggestion seems correct to me, can you provide a patch to fix
this?
Thanks,
Hannes
^ permalink raw reply
* NetDev 0.1 Hotel guaranteed rate expiry fast approaching
From: Richard Guy Briggs @ 2015-01-06 13:39 UTC (permalink / raw)
To: netdev, linux-wireless, lwn, netdev01, lartc, netfilter,
netfilter-devel
Hotel guaranteed rate expiry fast approaching
The Westin Hotel is holding a block of rooms for Netdev01 at a guaranteed rate
of $159.00 or $179.00 (depending on the type of room required). That guarantee
expires on January 23, so book now to avoid disappointment and get the low
rate. The rooms are going faster than we expected!
Hotel room reservation link:
https://www.starwoodmeeting.com/StarGroupsWeb/res?id=1412035802&key=1AC9C1F8
Registration: (closes Feb 12) https://onlineregistrations.ca/netdev01
Main site: https://www.netdev01.org/
Announcement: https://www.netdev01.org/announce
CFP: https://www.netdev01.org/cfp
Travel/hotel/weather/clothing: https://www.netdev01.org/travel
netdev 0.1 is the community-driven Linux networking conference held
back-to-back with netconf in Ottawa, Canada, February 14-17, 2015.
slainte mhath, RGB
--
Richard Guy Briggs -- ~\ -- ~\ <hpv.tricolour.ca>
<www.TriColour.ca> -- \___ o \@ @ Ride yer bike!
Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\%
Vote! -- <greenparty.ca>_____GTVS6#790__(*)__(*)________(*)(*)_________________
^ permalink raw reply
* Re: [PATCH net-next v2 0/8] net: extend ethtool link mode bitmaps to 48 bits
From: Amir Vadai @ 2015-01-06 13:56 UTC (permalink / raw)
To: David Decotigny, Florian Fainelli, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
Saeed Mahameed
Cc: David Decotigny, David S. Miller, Jason Wang, Michael S. Tsirkin,
Herbert Xu, Al Viro, Ben Hutchings, Masatake YAMATO, Xi Wang,
Neil Horman, WANG Cong, Flavio Leitner, Tom Gundersen, Jiri Pirko,
Vlad Yasevich, Eric W. Biederman, Venkata Duvvuru,
Govindarajulu Varadarajan
In-Reply-To: <1420512850-24699-1-git-send-email-ddecotig@gmail.com>
On 1/6/2015 4:54 AM, David Decotigny wrote:
> This patch series increases the width of the supported/advertising
> ethtool masks from 32 bits to 48. This should allow to breathe for a
> couple more years (or... months?).
Hi,
Nice work.
What worries me is that it is going to be for weeks more than years or
months...
Mellanox is about to release next month a driver for a new NIC, with 3
new speeds * few link modes for each + new link modes for 10G.
It seems that we will need to consume almost all the new bits.
Amir
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: add IPv4 routing FIB support for swdev
From: Hannes Frederic Sowa @ 2015-01-06 13:58 UTC (permalink / raw)
To: sfeldma; +Cc: netdev, jiri, john.fastabend, tgraf, jhs, andy, roopa
In-Reply-To: <1420169361-31767-2-git-send-email-sfeldma@gmail.com>
Hi Scott,
On Do, 2015-01-01 at 19:29 -0800, sfeldma@gmail.com wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> To offload IPv4 L3 routing functions to swdev device, the swdev device driver
> implements two new ndo ops (ndo_switch_fib_ipv4_add/del). The ops are called
> by the core IPv4 FIB code when installing/removing FIB entries to/from the
> kernel FIB. On install, the driver should return 0 if FIB entry (route) can be
> installed to device for offloading, -EOPNOTSUPP if route cannot be installed
> due to device limitations, and other negative error code on failure to install
> route to device. On failure error code, the route is not installed to device,
> and not installed in kernel FIB, and the return code is propagated back to the
> user-space caller (via netlink). An -EOPNOTSUPP error code is skipped for the
> device but installed in the kernel FIB.
>
> The FIB entry (route) nexthop list is used to find the swdev device port to
> anchor the ndo op call. The route's fib_dev (the first nexthop's dev) is used
> find the swdev port by recursively traversing the fib_dev's lower_dev list
> until a swdev port is found. The ndo op is called on this swdev port.
>
> Since the FIB entry is "naked" when push from the kernel, the driver/device
> is responsible for resolving the route's nexthops to neighbor MAC addresses.
> This can be done by the driver by monitoring NETEVENT_NEIGH_UPDATE
> netevent notifier to watch for ARP activity. Once a nexthop is resolved to
> neighbor MAC address, it can be installed to the device and the device will
> do the L3 routing offload in HW, for that nexthop.
>
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> include/linux/netdevice.h | 22 +++++++++++
> include/net/switchdev.h | 18 +++++++++
> net/ipv4/fib_trie.c | 17 ++++++++-
> net/switchdev/switchdev.c | 89 +++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 145 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 679e6e9..b66d22b 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -767,6 +767,8 @@ struct netdev_phys_item_id {
> typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
> struct sk_buff *skb);
>
> +struct fib_info;
> +
> /*
> * This structure defines the management hooks for network devices.
> * The following hooks can be defined; unless noted otherwise, they are
> @@ -1030,6 +1032,14 @@ typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
> * int (*ndo_switch_port_stp_update)(struct net_device *dev, u8 state);
> * Called to notify switch device port of bridge port STP
> * state change.
> + * int (*ndo_sw_parent_fib_ipv4_add)(struct net_device *dev, __be32 dst,
> + * int dst_len, struct fib_info *fi,
> + * u8 tos, u8 type, u32 tb_id);
> + * Called to add IPv4 route to switch device.
> + * int (*ndo_sw_parent_fib_ipv4_del)(struct net_device *dev, __be32 dst,
> + * int dst_len, struct fib_info *fi,
> + * u8 tos, u8 type, u32 tb_id);
> + * Called to delete IPv4 route from switch device.
> */
> struct net_device_ops {
> int (*ndo_init)(struct net_device *dev);
> @@ -1189,6 +1199,18 @@ struct net_device_ops {
> struct netdev_phys_item_id *psid);
> int (*ndo_switch_port_stp_update)(struct net_device *dev,
> u8 state);
> + int (*ndo_switch_fib_ipv4_add)(struct net_device *dev,
> + __be32 dst,
> + int dst_len,
> + struct fib_info *fi,
> + u8 tos, u8 type,
> + u32 tb_id);
> + int (*ndo_switch_fib_ipv4_del)(struct net_device *dev,
> + __be32 dst,
> + int dst_len,
> + struct fib_info *fi,
> + u8 tos, u8 type,
> + u32 tb_id);
> #endif
> };
At this point I would like to start the discussion about handling of the
table ids/vrfs (again :) ): as I can see it, this version just passes
table ids down to the driver layer and the rocker driver filters them by
local/main table? This seems to be mostly fine for a first version but
does not feel like it will integrate well with the rest of the linux
networking ecosystem.
Will hardware have the capabilities to do programmable matches like "ip
rule" is currently capable to do? Should we plan for that? Do we want to
support hardware which does support multiple tables/VRFs?
I would like to present a first suggestion:
My take on this would be strive towards an integration with ip-rule, so
we add tables which will be offloaded to hardware. This happens only in
situations where those tables will be the first match for incoming
packets specified with an in-interface filter which has the capability
to do the offloading (for example). The determination if the table is
capable for hardware offloading should be done automatically, so if
later hardware will be capable of doing ip rule like matches, we can
just expand the check which flags the tables accordingly.
Anyway, if hardware supports multiple tables or VRFs, it is better to
manage pass in a pointer where drivers can embed private data for
management, I think.
Thanks,
Hannes
^ permalink raw reply
* Re: [net-next PATCH v1 08/11] net: rocker: add get flow API operation
From: John Fastabend @ 2015-01-06 14:59 UTC (permalink / raw)
To: Scott Feldman
Cc: Thomas Graf, Jiří Pírko, Jamal Hadi Salim,
simon.horman@netronome.com, Netdev, David S. Miller,
Andy Gospodarek
In-Reply-To: <CAE4R7bCfpiCaiUwkOnPhHTRPJ3szcLtN8V8E35r=vKJ6rvTt3A@mail.gmail.com>
On 01/05/2015 11:40 PM, Scott Feldman wrote:
> On Wed, Dec 31, 2014 at 11:48 AM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>> Add operations to get flows. I wouldn't mind cleaning this code
>> up a bit but my first attempt to do this used macros which shortered
>> the code up but when I was done I decided it just made the code
>> unreadable and unmaintainable.
>>
>> I might think about it a bit more but this implementation albeit
>> a bit long and repeatative is easier to understand IMO.
>
> Dang, you put a lot of work into this one.
>
> Something doesn't feel right though. In this case, rocker driver just
> happened to have cached all the flow/group stuff in hash tables in
> software, so you don't need to query thru to the device to extract the
> if_flow info. What doesn't feel right is all the work need in the
> driver. For each and every driver. get_flows needs to go above
> driver, somehow.
Another option is to have a software cache in the flow_table.c I
was trying to avoid caching as I really don't expect 'get' operations
to be fast path and going to hardware seems good enough for me.
Other than its a bit annoying to write the mapping code.
If you don't have a cache then somewhere there has to be a mapping
from hardware flow descriptors to the flow descriptors used by the
flow API. Like I noted I tried to help by using macros and helper
routines but in the end I simply decided it convoluted the code to
much and made it hard to debug.
>
> Seems the caller of if_flow already knows the flows pushed down with
> add_flows/del_flows, and with the err handling can't mess it up.
yes the caller could know if it cached them which it doesn't. We
can add a cache if its helpful. You may have multiple users of the
API (both in-kernel and user space) though so I don't think you can
push it much beyond the flow_table.c.
>
> Is one use-case for get_flows to recover from a fatal OS/driver crash,
> and to rely on hardware to recover flow set? In this rocker example,
> that's not going to work because driver didn't get thru to device to
> get_flows. I think I'd like to know more about the use-cases of
> get_flows.
Its helpful for debugging. And if you have multiple consumers it
may be helpful to "learn" what other consumers are doing. I don't
have any concrete cases at the moment though.
For the CLI case its handy to add some flows, forget what you did,
and then do a get to refresh your mind. Not likely a problem for
"real" management software.
At least its not part of the UAPI so we could tweak/improve it as
much as we wanted. Any better ideas? I'm open to suggestions on this
one.
>
> -scott
>
--
John Fastabend Intel Corporation
^ 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