Re: [PATCH 0/2] of: fsl/fman: reuse the fixed node parsing code
12.08.2015 16:26, Madalin-Cristian Bucur пишет: I've tried to make the smallest changes that allow me to retrieve those without modifying existing API. Why is it important to hide the default values from the MAC driver? My worry is that the fixed values are not really fixed, and therefore are not always useful to access directly. It is likely not a problem for your use-case, as, as you say, the AN is disabled, but this is probably not the best to do in general. Yes, not a problem in my case. And also you do: --- - err = of_phy_register_fixed_link(mac_node); - if (err) + struct phy_device *phy; + + mac_dev-fixed_link = kzalloc(sizeof(*mac_dev- fixed_link), + GFP_KERNEL); + if (of_phy_parse_fixed_link(mac_node, mac_dev- fixed_link)) + goto _return_dev_set_drvdata; + + phy = fixed_phy_register(PHY_POLL, mac_dev-fixed_link, +mac_node); --- which means you really want to circumvent the current OF api quite a lot, without saying why in the patch description. I circumvent the API because I din not want to change existing API. If I could get a reference to the status struct without changing any code or without being required to call by myself fixed_phy_register(), I would of done that. Given the existing code in of_phy_register_fixed_link(), this was my only option. I could have broken of_phy_register_fixed_link() in two functions: of_phy_parse_fixed_link() and of_phy_register_fixed_link(), the latter doing only the call to fixed_phy_register() that would allow to keep of_phy_register_fixed_link() as it is, broken in two stages: - parsing - registering than can be used by other drivers in order to get the status but I think it's overkill. What I referred to as circumventing an API is that you do phy = fixed_phy_register(PHY_POLL, mac_dev-fixed_link, + mac_node); by hands, instead of letting the of_phy_register_fixed_link() doing so. How about a smaller circumvention, like this for instance: --- err = of_phy_register_fixed_link(mac_node); phy = of_phy_find_device(dn); status = fixed_phy_get_link_status(phy);// no such func, to be coded up --- Or even like this: --- err = of_phy_register_fixed_link(mac_node); phy = of_phy_find_device(dn); set_speed_and_duplex(phy-speed, phy-duplex);// not sure if these values are available that early --- Also I meant the description should have been in the patch, not in the e-mail. :) You only wrote _what_ the patch does (which is of course obvious from the code itself), but not _why_ and _what was fixed_ (what didn't work). As to your problem: would it be possible to set speed duplex after you do of_phy_connect()? It returns the phy_device pointer, and perhaps you can look into phydev-speed and phydev-duplex at that point? It would be possible but un-natural as I'd have probing information only available at runtime. This is un-natural only if you deal just with a fixed case. If your driver can deal also with the non-fixed cases (either AN or MDIO), then this looks more natural as the non-fixed management should be done at any point of time, and certainly _after_ of_phy_connect(). So if your driver is universal, this look like the natural choise to me, but if it is limited to the fixed case, then, as a simplification, you move that to the init time. But I am not argueing what is more natural. Maybe the above approaches with of_phy_find_device() can be used in init time? That would just complicate matters for my particular case ans I suspect there will be other drivers that get into this situation. I suspect only those that are limited to the fixed-link case. Only then they may decide to move phy management to init time, but IMHO this is just an optimization. You are concerned about people abusing this API to read fixed link status when the link is not really fixed, I'm concerned about declaring the link as fixed-link when it's not. Maybe the naming/binding needs to be revised to cover the case when all is fixed but the link. Yes, naming is the problem. fixed-link is just a bad name. See how it is defined: --- Some Ethernet MACs have a fixed link, and are not connected to a normal MDIO-managed PHY device. --- To me this means any non-MDIO PHY connection, but unfortunately the name fixed-link suggests a bit more than advertised. :( -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] of: fsl/fman: reuse the fixed node parsing code
-Original Message-
From: Stas Sergeev [mailto:s...@list.ru]
12.08.2015 16:26, Madalin-Cristian Bucur пишет:
I've tried to make the smallest changes that allow me to retrieve those
without modifying existing API.
Why is it important to hide the default values from the MAC driver?
My worry is that the fixed values are not really fixed, and
therefore are not always useful to access directly. It is likely
not a problem for your use-case, as, as you say, the AN is
disabled, but this is probably not the best to do in general.
Yes, not a problem in my case.
And also you do:
---
- err = of_phy_register_fixed_link(mac_node);
- if (err)
+ struct phy_device *phy;
+
+ mac_dev-fixed_link = kzalloc(sizeof(*mac_dev-
fixed_link),
+GFP_KERNEL);
+ if (of_phy_parse_fixed_link(mac_node, mac_dev-
fixed_link))
+ goto _return_dev_set_drvdata;
+
+ phy = fixed_phy_register(PHY_POLL, mac_dev-fixed_link,
+ mac_node);
---
which means you really want to circumvent the current OF
api quite a lot, without saying why in the patch description.
I circumvent the API because I din not want to change existing API.
If I could get a reference to the status struct without changing any code
or without being required to call by myself fixed_phy_register(), I
would of done that. Given the existing code in
of_phy_register_fixed_link(),
this was my only option. I could have broken of_phy_register_fixed_link()
in two functions:
of_phy_parse_fixed_link() and of_phy_register_fixed_link(), the latter
doing only
the call to fixed_phy_register()
that would allow to keep of_phy_register_fixed_link() as it is, broken in
two stages:
- parsing
- registering
than can be used by other drivers in order to get the status but I think
it's
overkill.
What I referred to as circumventing an API is that you do
phy = fixed_phy_register(PHY_POLL, mac_dev-fixed_link, + mac_node);
by hands, instead of letting the of_phy_register_fixed_link() doing so.
How about a smaller circumvention, like this for instance:
---
err = of_phy_register_fixed_link(mac_node);
phy = of_phy_find_device(dn);
status = fixed_phy_get_link_status(phy);// no such func, to be coded up
---
Or even like this:
---
err = of_phy_register_fixed_link(mac_node);
phy = of_phy_find_device(dn);
set_speed_and_duplex(phy-speed, phy-duplex);// not sure if these
values are available that early
---
After my patch, all that of_phy_register_fixed_link() does is to call
the new parsing function I introduced then register the fixed PHY.
I could have done this (pseudocode):
- add of_phy_parse_fixed_link() as seen in the patch
- add of_phy_register_fixed_phy() that just calls fixed_phy_register():
int of_phy_register_fixed_phy(node)
{
phy = fixed_phy_register(PHY_POLL, mac_dev-fixed_link,
mac_node);
return (!phy);
}
- change of_phy_register_fixed_link() to contain only this:
int of_phy_register_fixed_link(node)
{
of_phy_parse_fixed_link(node, status);
return of_phy_register_fixed_phy(node);
}
Then I could call only of_* functions but the end result would be the same and
of_phy_register_fixed_phy() would not justify its existence that much...
The getter for status you suggest would be fine, but not sure how one would
retrieve
it from the mac_node unless we change of_phy_register_fixed_link() to return the
pointer to phy (and all the drivers that use it...).
Also I meant the description should have been in the patch,
not in the e-mail. :) You only wrote _what_ the patch does
(which is of course obvious from the code itself), but not
_why_ and _what was fixed_ (what didn't work).
If you refer to the first, separation patch, I thought the description was
enough:
of: separate fixed link parsing from registration
Some drivers may need to parse the fixed link values before registering
the fixed link phy. Separate the parsing from the actual registration
and provide an export for the added parsing function.
Signed-off-by: Madalin Bucur madalin.bu...@freescale.com
For this one it was a bit brief, I admit - the longer version would be that
before it
we were not using from fixed link anything else but the fact the link was fixed
(ignored actual speed, duplex values there) and this patch tries to fix that.
In the end this patch will be squashed in a new FMan patch set, let me use that
as
an excuse for the brief commit log :)
snip
You are concerned about people
abusing this API to read fixed link status when the link is not really
fixed, I'm
concerned
about declaring the link as fixed-link when it's not. Maybe the
naming/binding needs to be
revised to cover the case when all is fixed but the link.
Yes, naming is the
[PATCH net-next] net: fec: Remove unneeded use of IS_ERR_VALUE() macro
From: Fabio Estevam fabio.este...@freescale.com There is no need to use the IS_ERR_VALUE() macro for checking the return value from pm_runtime_* functions. Just do a simple negative test instead. The semantic patch that makes this change is available in scripts/coccinelle/api/pm_runtime.cocci. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/net/ethernet/freescale/fec_main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index 3cebf93..787da8e 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -1779,7 +1779,7 @@ static int fec_enet_mdio_read(struct mii_bus *bus, int mii_id, int regnum) int ret = 0; ret = pm_runtime_get_sync(dev); - if (IS_ERR_VALUE(ret)) + if (ret 0) return ret; fep-mii_timeout = 0; @@ -1818,7 +1818,7 @@ static int fec_enet_mdio_write(struct mii_bus *bus, int mii_id, int regnum, int ret = 0; ret = pm_runtime_get_sync(dev); - if (IS_ERR_VALUE(ret)) + if (ret 0) return ret; fep-mii_timeout = 0; @@ -2870,7 +2870,7 @@ fec_enet_open(struct net_device *ndev) int ret; ret = pm_runtime_get_sync(fep-pdev-dev); - if (IS_ERR_VALUE(ret)) + if (ret 0) return ret; pinctrl_pm_select_default_state(fep-pdev-dev); -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] of: fsl/fman: reuse the fixed node parsing code
12.08.2015 17:43, Madalin-Cristian Bucur пишет:
-Original Message-
From: Stas Sergeev [mailto:s...@list.ru]
12.08.2015 16:26, Madalin-Cristian Bucur пишет:
I've tried to make the smallest changes that allow me to retrieve those
without modifying existing API.
Why is it important to hide the default values from the MAC driver?
My worry is that the fixed values are not really fixed, and
therefore are not always useful to access directly. It is likely
not a problem for your use-case, as, as you say, the AN is
disabled, but this is probably not the best to do in general.
Yes, not a problem in my case.
And also you do:
---
- err = of_phy_register_fixed_link(mac_node);
- if (err)
+ struct phy_device *phy;
+
+ mac_dev-fixed_link = kzalloc(sizeof(*mac_dev-
fixed_link),
+ GFP_KERNEL);
+ if (of_phy_parse_fixed_link(mac_node, mac_dev-
fixed_link))
+ goto _return_dev_set_drvdata;
+
+ phy = fixed_phy_register(PHY_POLL, mac_dev-fixed_link,
+mac_node);
---
which means you really want to circumvent the current OF
api quite a lot, without saying why in the patch description.
I circumvent the API because I din not want to change existing API.
If I could get a reference to the status struct without changing any code
or without being required to call by myself fixed_phy_register(), I
would of done that. Given the existing code in
of_phy_register_fixed_link(),
this was my only option. I could have broken of_phy_register_fixed_link()
in two functions:
of_phy_parse_fixed_link() and of_phy_register_fixed_link(), the latter
doing only
the call to fixed_phy_register()
that would allow to keep of_phy_register_fixed_link() as it is, broken in
two stages:
- parsing
- registering
than can be used by other drivers in order to get the status but I think it's
overkill.
What I referred to as circumventing an API is that you do
phy = fixed_phy_register(PHY_POLL, mac_dev-fixed_link, + mac_node);
by hands, instead of letting the of_phy_register_fixed_link() doing so.
How about a smaller circumvention, like this for instance:
---
err = of_phy_register_fixed_link(mac_node);
phy = of_phy_find_device(dn);
status = fixed_phy_get_link_status(phy);// no such func, to be coded up
---
Or even like this:
---
err = of_phy_register_fixed_link(mac_node);
phy = of_phy_find_device(dn);
set_speed_and_duplex(phy-speed, phy-duplex);// not sure if these
values are available that early
---
After my patch, all that of_phy_register_fixed_link() does is to call
the new parsing function I introduced then register the fixed PHY.
I could have done this (pseudocode):
- add of_phy_parse_fixed_link() as seen in the patch
- add of_phy_register_fixed_phy() that just calls fixed_phy_register():
int of_phy_register_fixed_phy(node)
{
phy = fixed_phy_register(PHY_POLL, mac_dev-fixed_link,
mac_node);
return (!phy);
}
- change of_phy_register_fixed_link() to contain only this:
int of_phy_register_fixed_link(node)
{
of_phy_parse_fixed_link(node, status);
return of_phy_register_fixed_phy(node);
}
But have you looked into the patch I pointed previously?
https://lkml.org/lkml/2015/7/20/711
You code will likely clash with it because my patch extends
of_phy_register_fixed_link().
Then I could call only of_* functions but the end result would be the same and
of_phy_register_fixed_phy() would not justify its existence that much...
You didn't say you wanted to obsolete the of_phy_register_fixed_phy().
Since it is there (and even changed by me in a way your
patch will likely clash), IMHO it would be better if it is used,
rather than copy/pasted into the driver.
The getter for status you suggest would be fine, but not sure how one would
retrieve
it from the mac_node unless we change of_phy_register_fixed_link() to return the
pointer to phy (and all the drivers that use it...).
If you look for instance to mvneta.c, you'll find the following:
---
err = of_phy_register_fixed_link(dn);
/* In the case of a fixed PHY, the DT node associated
* to the PHY is the Ethernet MAC DT node.
*/
phy_node = of_node_get(dn);
...
phy = of_phy_find_device(dn);
---
So the answer is: just use the same mac_node for both.
Also I meant the description should have been in the patch,
not in the e-mail. :) You only wrote _what_ the patch does
(which is of course obvious from the code itself), but not
_why_ and _what was fixed_ (what didn't work).
If you refer to the first, separation patch, I thought the description was
enough:
of: separate fixed link parsing from registration
Some drivers may need
may need? I don't understand.
If it is a fix, then they _do need_, and in this case it should
be specified what was broken and what is fixed.
If it is just a clean-up, then may need
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote: On 08/11/2015 11:49 AM, David Miller wrote: From: David Daney ddaney.c...@gmail.com Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information from the ACPI tables. Series applied. Thank you very much. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? On arm64 (unless you use a vendor kernel), DT takes precedence over ACPI if both arm provided to the kernel (and it's a fair assumption given that ACPI on ARM is still in the early days). You could also force ACPI with acpi=force on the kernel cmd line and the arch code will not unflatten the DT even if it is provided, therefore is_of_node(fwnode) returning false. I haven't looked at your driver in detail but something like AMD's xgbe_probe() uses a single function for both DT and ACPI with device_property_read_*() functions getting the information from the correct place in either case. The ACPI vs DT precedence is handled by the arch boot code, we never mix the two and confuse the drivers. -- Catalin -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] net/ipv4: inconsistent routing table
On Wed, 12 Aug 2015 16:14:33 +0800 Zang MingJie zealot0...@gmail.com wrote: On Wed, Aug 12, 2015 at 4:52 AM, Alexander Duyck alexander.du...@gmail.com wrote: On 08/10/2015 04:50 AM, Hannes Frederic Sowa wrote: Hello, Zang MingJie zealot0...@gmail.com writes: Here comes several options: 1. reject local next hop w/ EINVAL 2. delete route when local next hop removed Will also cause some people to complain. 3. transition between RT_SCOPE_HOST amd RT_SCOPE_LINK I don't understand the scope transition. I know Alex mentioned it for the first time. Maybe he can explain? If I am not mistaken part of the issue in terms of the behaviour being seen is due to the fact that the nexthop scope is recorded only when the route is added, and there is code in place in rt_set_nexthop which will only use the gateway if the scope is RT_SCOPE_LINK. So what we would probably need to do is go through and audit any routes on a given interface every time an address is added or removed and if the nh_gw is equal to the address added or removed would would need to transition between RT_SCOPE_LINK and RT_SCOPE_HOST since the gateway is transitioning between the local system and somewhere on the other side of the link. The problem is that this would still be a behaviour change and there may be somebody that has heartburn about it. That's why I'm going to introduce a sysconf entry, with the entry unset, keep compatibility; with the entry set, fix the bug. 4. document it I prefer that one :) Yeah, me too. The fact is things have worked this way up until now and I suspect the reason why this hasn't been reported until now is simply because in many cases it works since routes are usually updated if you are moving the gateway onto the local system. Most people doing any router use routing protocols suites like Quagga or Bird which have a routing management daemon. This is the kind of change that the routing services portion manages. When a route or interface change is detected it updates the FIB based on the bigger RIB. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/2] of: fsl/fman: reuse the fixed node parsing code
-Original Message- From: Stas Sergeev [mailto:s...@list.ru] snip But have you looked into the patch I pointed previously? https://lkml.org/lkml/2015/7/20/711 You code will likely clash with it because my patch extends of_phy_register_fixed_link(). I admin I failed to grasp the details of your change - the lack of ample context Lines makes it a bit difficult. I'm sure your change could be merged then the of parsing could be separated from the actual fixed_phy_register() call if anyone cares about that. Then I could call only of_* functions but the end result would be the same and of_phy_register_fixed_phy() would not justify its existence that much... You didn't say you wanted to obsolete the of_phy_register_fixed_phy(). Since it is there (and even changed by me in a way your patch will likely clash), IMHO it would be better if it is used, rather than copy/pasted into the driver. Please note I was referring to a fictional new function that would embed the call to fixed_phy_register(). I was not talking about some existing API, just about a new of_call named of_phy_register_fixed_phy() that would in the end be called by of_phy_register_fixed_link() and by some drivers that want to get in the middle of things and get a hold on status. Maybe the fact we're reviewing two patches in one thread is what makes the discussion less than optimal. The getter for status you suggest would be fine, but not sure how one would retrieve it from the mac_node unless we change of_phy_register_fixed_link() to return the pointer to phy (and all the drivers that use it...). If you look for instance to mvneta.c, you'll find the following: --- err = of_phy_register_fixed_link(dn); /* In the case of a fixed PHY, the DT node associated * to the PHY is the Ethernet MAC DT node. */ phy_node = of_node_get(dn); ... phy = of_phy_find_device(dn); --- So the answer is: just use the same mac_node for both. I understand, I'll use this approach although is suboptimal imho to scan the device tree again to get a phy pointer that you need just to get some of info that was parsed in a call you just made. Also I meant the description should have been in the patch, not in the e-mail. :) You only wrote _what_ the patch does (which is of course obvious from the code itself), but not _why_ and _what was fixed_ (what didn't work). If you refer to the first, separation patch, I thought the description was enough: of: separate fixed link parsing from registration Some drivers may need may need? I don't understand. If it is a fix, then they _do need_, and in this case it should be specified what was broken and what is fixed. If it is just a clean-up, then may need may suffice, but it was not mentioned it is a clean-up. So I still don't know what this patch is all about. Some drivers - which ones? The ones that are limited to the purely fixed links, and never support AN or MDIO? Or some other drivers too? So really, the description sounds very cryptic to me. Mine, when there is a fixed link node, maybe others. When there isn't any fixed link node, the internal PHY config defaults to 1G full duplex AN enabled and adjust link takes care of things. to parse the fixed link values before registering the fixed link phy. Separate the parsing from the actual registration and provide an export for the added parsing function. Signed-off-by: Madalin Bucur madalin.bu...@freescale.com For this one it was a bit brief, I admit - the longer version would be that before it we were not using from fixed link anything else but the fact the link was fixed (ignored actual speed, duplex values there) And what didn't work as the result? and this patch tries to fix that. What started to work after that patch that didn't without it? 10M half duplex for instance I'd close this thread for now and use in my driver of_phy_find_device(mac_node). Thank you, Madalin
Re: ipv6_mc_check_mld - kernel BUG at net/core/skbuff.c:1128
On Tue, 2015-08-11 at 21:56 -0700, David Miller wrote: Calling pskb_expand_head() with a shared SKB is absolutely, positively, a bug. You just don't understand why it is. Definitely agree. Its a pain to find races otherwise. skb_get() in general is quite tricky. Better avoid it unless really needed in performance critical paths. Relevant commits ba34e6d9d346fe4e05d7e417b9edf5140772d34c tcp: make sure skb is not shared before using skb_get() fc752f1f43c1c038a2c6ae58cc739ebb5953ccb0 ping: Fix race in free in receive path 1dc7b90f7cd050ef6d5e511e652347e52874469c ipv6: tcp: fix race in IPV6_2292PKTOPTIONS -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 net-next] bpf: fix bpf_perf_event_read() loop upper bound
Verifier rejects programs incorrectly.
Fixes: 35578d798400 (bpf: Implement function bpf_perf_event_read())
Cc: Kaixu Xia xiaka...@huawei.com
Cc: Alexei Starovoitov a...@plumgrid.com
Signed-off-by: Wei-Chun Chao weich...@plumgrid.com
---
v2: better subject line
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 48e1c71..ed12e38 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -853,7 +853,7 @@ static int check_map_func_compatibility(struct bpf_map
*map, int func_id)
if (!map)
return 0;
- for (i = 0; i = ARRAY_SIZE(func_limit); i++) {
+ for (i = 0; i ARRAY_SIZE(func_limit); i++) {
bool_map = (map-map_type == func_limit[i].map_type);
bool_func = (func_id == func_limit[i].func_id);
/* only when map func pair match it can continue.
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH 1/3] net: make default tx_queue_len configurable
On Tue, 2015-08-11 at 18:13 -0700, Alexei Starovoitov wrote:
Also why introduce the flag? Why not just add 'tx_queue_len = 0;'
to veth_setup() like the whole bunch of devices do?
Sigh.
Because some people install htb or pfifo on veth, leaving tx_queue_len
unchanged.
If you install htb while tx_queue_len is 0, pfifo created on htb classe
can only queue one packet.
static int fifo_init(struct Qdisc *sch, struct nlattr *opt)
{
bool bypass;
bool is_bfifo = sch-ops == bfifo_qdisc_ops;
if (opt == NULL) {
u32 limit = qdisc_dev(sch)-tx_queue_len ? : 1;
if (is_bfifo)
limit *= psched_mtu(qdisc_dev(sch));
sch-limit = limit;
Changing veth txqueuelen is too late.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 net-next] sky2: use random address if EEPROM is bad
On Wed, 12 Aug 2015 10:30:05 +0100
Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Aug 11, 2015 at 06:01:32PM +0100, Stephen Hemminger wrote:
On Tue, 11 Aug 2015 15:35:56 +0100
Liviu Dudau liviu.du...@arm.com wrote:
On some embedded systems the EEPROM does not contain a valid MAC address.
In that case it is better to fallback to a generated mac address and
let init scripts fix the value later.
Reported-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Stephen Hemminger step...@networkplumber.org
[Changed handcoded setup to use eth_hw_addr_random() instead]
Signed-off-by: Liviu Dudau liviu.du...@arm.com
---
I have tested this on my Juno platform and I can successfully do an
nfsroot boot.
Best regards,
Liviu
drivers/net/ethernet/marvell/sky2.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/marvell/sky2.c
b/drivers/net/ethernet/marvell/sky2.c
index d9f4498..c309879 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -4819,6 +4819,13 @@ static struct net_device *sky2_init_netdev(struct
sky2_hw *hw, unsigned port,
memcpy_fromio(dev-dev_addr, hw-regs + B2_MAC_1 + port * 8,
ETH_ALEN);
+ /* if the address is invalid, use a random value */
+ if (!is_valid_ether_addr(dev-dev_addr)) {
+ netdev_warn(dev,
+ Invalid MAC address, defaulting to random\n);
+ eth_hw_addr_random(dev);
+ }
+
return dev;
}
This is not enough, you need to program the hardware with the new random MAC
address. The easiest way is calling sky2_set_mac_address, but you need to
convert
the address from array back to sockaddr.
OK, I am a bit confused as to why sky2_set_mac_address is needed here, as
this was not
required by the existing function. Given that in my tests I get a random MAC
address
assigned every time to the device and I can see the same MAC address with
ifconfig, how
can I test the effect of sky2_set_mac_address if I add it?
The network device address is stored in two places. One is in the
kernel (dev-dev_addr) and is used by networking stack.
The other is the hardware (actually two places) and is used filtering received
packets
in the PHY and for sending hardware generated pause frames.
When a random address is generated, you need to tell the hardware
to use that address as well. I suspect your hardware maybe limited in
functionality
and not do the normal filtering.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On 08/12/2015 08:23 AM, Catalin Marinas wrote: On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote: On 08/11/2015 11:49 AM, David Miller wrote: From: David Daney ddaney.c...@gmail.com Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information from the ACPI tables. Series applied. Thank you very much. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? On arm64 (unless you use a vendor kernel), DT takes precedence over ACPI if both arm provided to the kernel (and it's a fair assumption given that ACPI on ARM is still in the early days). You could also force ACPI with acpi=force on the kernel cmd line and the arch code will not unflatten the DT even if it is provided, therefore is_of_node(fwnode) returning false. I haven't looked at your driver in detail but something like AMD's xgbe_probe() uses a single function for both DT and ACPI with device_property_read_*() functions getting the information from the correct place in either case. The ACPI vs DT precedence is handled by the arch boot code, we never mix the two and confuse the drivers. My long term plan is to create something like firmware_get_mac_address(), that would encapsulate of_get_mac_address() and the ACPI equivalent. Same for firmware_phy_find_device(). These would function as you suggest, but lacking this infrastructure, we implemented this patch set instead. Thanks, David Daney -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] dlm: use sctp 1-to-1 API
From: Marcelo Ricardo Leitner Sent: 12 August 2015 14:16 Em 12-08-2015 07:23, David Laight escreveu: From: Marcelo Ricardo Leitner Sent: 11 August 2015 23:22 DLM is using 1-to-many API but in a 1-to-1 fashion. That is, it's not needed but this causes it to use sctp_do_peeloff() to mimic an kernel_accept() and this causes a symbol dependency on sctp module. By switching it to 1-to-1 API we can avoid this dependency and also reduce quite a lot of SCTP-specific code in lowcomms.c. ... You still need to enable sctp notifications (I think the patch deleted that code). Otherwise you don't get any kind of indication if the remote system 'resets' (ie sends an new INIT chunk) on an existing connection. Right, it would miss the restart event and could generate a corrupted tx/rx buffers by glueing parts of old messages with new ones. Except that it is SCTP so you'd expect DATA chunks to contain entire messages and so get unexpected message sequences rather than corrupt messages. The problem is that the recovery is likely to be another reset. (Particularly with M3UA where the source and destination port numbers are likely to be the same and fixed.) It is probably enough to treat the MSG_NOTIFICATION as a fatal error and close the socket. Just so we are on the same page, you mean that after accepting the new association and enabling notifications on it, any further notification on it can be treated as fatal errors, right? Seems reasonable to me. That's what I had to do. The far end will probably see an additional disconnect, but it shouldn't matter. This is probably a bug in the sctp stack - if a connection is reset but the user hasn't requested notifications then it should be converted to a disconnect indication and a new incoming connection. Maybe in such case resets shouldn't be allowed at all? Because unless it happens on a moment of silence it will always lead to application buffer corruption. Checked the RFCs now but couldn't find anything restricting them to some condition. I certainly expected the 'reset' to cause an inwards abortive disconnect on the old socket and a new indication on the listening socket. I think (hope) that is what you get for a TCP SYN that matches an existing connection. In our case I think they were happening when the remote system was power cycled. David -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ip/ipnetns: prevent potential string buffer overflow
Rather than chopping the string off, I decided to solve the problem by changing network namespace cache to use variable length structure. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 4/6] openvswitch: Use Geneve device.
On Tue, Aug 11, 2015 at 10:17 PM, Pravin B Shelar pshe...@nicira.com wrote: With help of tunnel metadata mode OVS can directly use Geneve devices to implement Geneve tunnels. This patch removes all of the OVS specific Geneve code and make OVS use a Geneve net_device. Basic geneve vport is still there to handle compatibility with current userspace application. Signed-off-by: Pravin B Shelar pshe...@nicira.com Reviewed-by: Jesse Gross je...@nicira.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 0/4] Add some more debug info
From: Hariprasad Shenai haripra...@chelsio.com Date: Wed, 12 Aug 2015 16:55:03 +0530 This patch series adds the following. Add more info for sge_qinfo dump Differentiate tid and stids between different regions, and add a debugfs entry to dump all the tid info This patch series has been created against net-next tree and includes patches on cxgb4 driver. We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. Series applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 net-next 06/10] openvswitch: Allow matching on conntrack mark
On 12 August 2015 at 16:00, Pravin Shelar pshe...@nicira.com wrote:
On Tue, Aug 11, 2015 at 3:59 PM, Joe Stringer joestrin...@nicira.com wrote:
From: Justin Pettit jpet...@nicira.com
Allow matching and setting the conntrack mark field. As with conntrack
state and zone, these are populated by executing the ct() action. Unlike
these, the ct_mark is also a writable field. The set_field() action may
be used to modify the mark, which will take effect on the most recent
conntrack entry.
E.g.: actions:ct(zone=0),ct(zone=1),set_field(1-ct_mark)
This will perform conntrack lookup in zone 0, then lookup in zone 1,
then modify the mark for the entry in zone 1. The mark for the entry in
zone 0 is unchanged. The conntrack entry itself must be committed using
the commit flag in the conntrack action flags for this change to persist.
Signed-off-by: Justin Pettit jpet...@nicira.com
Signed-off-by: Joe Stringer joestrin...@nicira.com
---
...
+int ovs_ct_set_mark(struct sk_buff *skb, struct sw_flow_key *key,
+ u32 ct_mark, u32 mask)
+{
+#ifdef CONFIG_NF_CONNTRACK_MARK
+ enum ip_conntrack_info ctinfo;
+ struct nf_conn *ct;
+ u32 new_mark;
+
+ /* This must happen directly after lookup/commit. */
+ ct = nf_ct_get(skb, ctinfo);
+ if (!ct)
+ return -EINVAL;
+
+ new_mark = ct_mark | (ct-mark ~(mask));
+ if (ct-mark != new_mark) {
+ ct-mark = new_mark;
+ nf_conntrack_event_cache(IPCT_MARK, ct);
+ key-ct.mark = ct_mark;
+ }
+
Is it fine to set just set mark and not initialize reset of key-ct members?
I don't quite follow. This action acts upon the current connection,
and modifies its metadata. key-ct should already be populated with
the existing connection info.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/2] net: track link status of ipv6 nexthops
From: Andy Gospodarek go...@cumulusnetworks.com Date: Mon, 10 Aug 2015 14:46:52 -0400 I went this way as the idea of storing this info in a flags structure for 2 reasons: - This idea or marking on link status changes and checking for that mark during forwarding was done what was suggested by Alex et al for the ipv4 code and I wanted to keep the overall design similar. - New flags will likely be needed when switchdev support is added for ipv6 routes so going ahead and mirroring the RTNH_F* flags in the the ipv6 code seemed reasonable. I would actually be fine with what you proposed (it is closer to the first implementation), so if my justification above does not change your mind, let me know and I'll post a v2 that does not add rt6i_nhflags and simply checks netif_carrier_ok() rather than RTNH_F_LINKDOWN. Ok fair enough, if we'll need more flags later then so be it. Andy, please resubmit this series, I'll apply it. Thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: eth: altera: Remove sgdmadesclen member from altera_tse_private
From: Tobias Klauser tklau...@distanz.ch Date: Mon, 10 Aug 2015 12:26:32 +0200 altera_tse_private-sgdmadesclen is always assigned assigned the same value and never changes during runtime. Remove the struct member and use a new define for sizeof(struct sgdma_descrip) instead. Signed-off-by: Tobias Klauser tklau...@distanz.ch No feedback from Vince about whether this was intended to be used in some way or not, so I'm applying this to net-next, thanks Tobias. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Add a matching set of device_ functions for determining mac/phy
On 12/08/15 15:06, Jeremy Linton wrote:
OF has some helper functions for parsing MAC and PHY settings.
In cases where the platform is providing this information rather
than the device itself, there needs to be similar functions for ACPI.
These functions are slightly modified versions of the ones in
of_net which can use information provided via DT or ACPI.
Signed-off-by: Jeremy Linton jeremy.lin...@arm.com
---
[snip]
+
+static void *device_get_mac_addr(struct device *dev,
+ const char *name, char *addr,
+ int alen)
+{
+ int ret = device_property_read_u8_array(dev, name, addr, alen);
+
+ if (ret == 0 is_valid_ether_addr(addr))
+ return addr;
+ return NULL;
The DT counterpart has an additional check on the properly length to be
ETH_ALEN, you might want to have such check here for consistency and
correctness.
Other than that, this looks good to me.
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: atl1c: add BQL support
Ron Angeles ronange...@gmail.com :
This BQL implementation is mostly derived from its related driver, alx.
Tested on AR8131 (rev c0) [1969:1063]. Saturated a 100mbps link with 5
concurrent runs of netperf. Ping latency dropped from 14ms to 3ms.
Could you use some time to test the attached experimental stuff as well ?
--
Ueimor
From 3f5bcfcc93ecc8634e5da95cc58a751e39a1ec9f Mon Sep 17 00:00:00 2001
Message-Id:
3f5bcfcc93ecc8634e5da95cc58a751e39a1ec9f.1439418772.git.rom...@fr.zoreil.com
From: Francois Romieu rom...@fr.zoreil.com
Date: Sun, 19 Apr 2015 00:23:51 +0200
Subject: [PATCH 1/5] atl1c: use return value where argument pointer makes no
sense.
X-Organisation: Land of Sunshine Inc.
Signed-off-by: Francois Romieu rom...@fr.zoreil.com
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 932bd18..282ec17 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -56,8 +56,7 @@ static int atl1c_stop_mac(struct atl1c_hw *hw);
static void atl1c_disable_l0s_l1(struct atl1c_hw *hw);
static void atl1c_set_aspm(struct atl1c_hw *hw, u16 link_speed);
static void atl1c_start_mac(struct atl1c_adapter *adapter);
-static void atl1c_clean_rx_irq(struct atl1c_adapter *adapter,
- int *work_done, int work_to_do);
+static int atl1c_clean_rx_irq(struct atl1c_adapter *adapter, int budget);
static int atl1c_up(struct atl1c_adapter *adapter);
static void atl1c_down(struct atl1c_adapter *adapter);
static int atl1c_reset_mac(struct atl1c_hw *hw);
@@ -1787,11 +1786,10 @@ static void atl1c_clean_rfd(struct atl1c_rfd_ring
*rfd_ring,
rfd_ring-next_to_clean = rfd_index;
}
-static void atl1c_clean_rx_irq(struct atl1c_adapter *adapter,
- int *work_done, int work_to_do)
+static int atl1c_clean_rx_irq(struct atl1c_adapter *adapter, int budget)
{
u16 rfd_num, rfd_index;
- u16 count = 0;
+ u16 count;
u16 length;
struct pci_dev *pdev = adapter-pdev;
struct net_device *netdev = adapter-netdev;
@@ -1801,9 +1799,7 @@ static void atl1c_clean_rx_irq(struct atl1c_adapter
*adapter,
struct atl1c_recv_ret_status *rrs;
struct atl1c_buffer *buffer_info;
- while (1) {
- if (*work_done = work_to_do)
- break;
+ for (count = 0; count budget; count++) {
rrs = ATL1C_RRD_DESC(rrd_ring, rrd_ring-next_to_clean);
if (likely(RRS_RXD_IS_VALID(rrs-word3))) {
rfd_num = (rrs-word0 RRS_RX_RFD_CNT_SHIFT)
@@ -1857,12 +1853,11 @@ rrs_checked:
__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan);
}
netif_receive_skb(skb);
-
- (*work_done)++;
- count++;
}
if (count)
atl1c_alloc_rx_buffer(adapter);
+
+ return count;
}
/**
@@ -1875,10 +1870,10 @@ static int atl1c_clean(struct napi_struct *napi, int
budget)
int work_done = 0;
/* Keep link state information with original netdev */
- if (!netif_carrier_ok(adapter-netdev))
+ if (unlikely(!netif_carrier_ok(adapter-netdev)))
goto quit_polling;
/* just enable one RXQ */
- atl1c_clean_rx_irq(adapter, work_done, budget);
+ work_done = atl1c_clean_rx_irq(adapter, budget);
if (work_done budget) {
quit_polling:
--
2.4.3
From c1eb6bb4817ed04155e829df435264be675aeab4 Mon Sep 17 00:00:00 2001
Message-Id:
c1eb6bb4817ed04155e829df435264be675aeab4.1439418772.git.rom...@fr.zoreil.com
In-Reply-To:
3f5bcfcc93ecc8634e5da95cc58a751e39a1ec9f.1439418772.git.rom...@fr.zoreil.com
References:
3f5bcfcc93ecc8634e5da95cc58a751e39a1ec9f.1439418772.git.rom...@fr.zoreil.com
From: Francois Romieu rom...@fr.zoreil.com
Date: Sun, 19 Apr 2015 00:45:09 +0200
Subject: [PATCH 2/5] atl1c: highlight normal code path in receive poller
atl1c_clean_rx_irq.
X-Organisation: Land of Sunshine Inc.
Signed-off-by: Francois Romieu rom...@fr.zoreil.com
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 46 +++--
1 file changed, 20 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 282ec17..35ea3ec 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -1801,46 +1801,40 @@ static int atl1c_clean_rx_irq(struct atl1c_adapter
*adapter, int budget)
for (count = 0; count budget; count++) {
rrs = ATL1C_RRD_DESC(rrd_ring, rrd_ring-next_to_clean);
- if (likely(RRS_RXD_IS_VALID(rrs-word3))) {
- rfd_num = (rrs-word0 RRS_RX_RFD_CNT_SHIFT)
-
RE: VxLAN support question
Hi Alexei, I run into following issue: root@ODLserver:/home/andrew# ip li add vxlan0 type vxlan id 42 remote 171.1.1.1 local 170.1.1.1 dev eth1 OK root@ODLserver:/home/andrew# ip li add vxlan1 type vxlan id 42 remote 172.1.1.1 local 170.1.1.1 dev eth2 == RTNETLINK answers: File exists Do you know why Linux kernel reject second CLI ? From user perspective, it is a perfect fine configuration because I want to create two P2P vxlan Tunnels to connect TWO VTEPs using same VNI. Thanks, Andrew root@ODLserver:/home/andrew# -Original Message- From: Alexei Starovoitov [mailto:a...@plumgrid.com] Sent: Monday, August 10, 2015 10:37 PM To: Andrew Qu; David Miller Cc: tg...@suug.ch; je...@nicira.com; pshe...@nicira.com; netdev@vger.kernel.org Subject: Re: VxLAN support question On 8/10/15 4:47 PM, Andrew Qu wrote: Pretty much what I want is that kernel will have about 1K interfaces (something like Tunnel100.1-tunnel100.1000 To be created and attached to 1K bridge domains on which each VNI is associated with given VNI to bridge-domain will be assigned using other CLIs) creating 1k vxlan devices is doable, but you probably want to take a look at recently added metadata mode of vxlan. Also sounds like for each vni you'd need a different multicast group? What fabric going to support that? * Email Confidentiality Notice please avoid such banners. * Email Confidentiality Notice The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Convert smsc911x to use ACPI as well as DT
Add ACPI bindings for the smsc911x driver. Convert the DT specific calls
to nonspecific device* calls, This allows the driver to work
with both ACPI and DT configurations. Ethernet should now work when using
ACPI on ARM Juno.
Signed-off-by: Jeremy Linton jeremy.lin...@arm.com
---
drivers/net/ethernet/smsc/smsc911x.c | 48 +---
1 file changed, 22 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 959aeea..0f21aa3 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -59,7 +59,9 @@
#include linux/of_device.h
#include linux/of_gpio.h
#include linux/of_net.h
+#include linux/acpi.h
#include linux/pm_runtime.h
+#include linux/property.h
#include smsc911x.h
@@ -2362,59 +2364,46 @@ static const struct smsc911x_ops shifted_smsc911x_ops =
{
.tx_writefifo = smsc911x_tx_writefifo_shift,
};
-#ifdef CONFIG_OF
-static int smsc911x_probe_config_dt(struct smsc911x_platform_config *config,
- struct device_node *np)
+static int smsc911x_probe_config(struct smsc911x_platform_config *config,
+struct device *dev)
{
- const char *mac;
u32 width = 0;
- if (!np)
+ if (!dev)
return -ENODEV;
- config-phy_interface = of_get_phy_mode(np);
+ config-phy_interface = device_get_phy_mode(dev);
- mac = of_get_mac_address(np);
- if (mac)
- memcpy(config-mac, mac, ETH_ALEN);
+ device_get_mac_address(dev, config-mac, ETH_ALEN);
- of_property_read_u32(np, reg-shift, config-shift);
+ device_property_read_u32(dev, reg-shift, config-shift);
- of_property_read_u32(np, reg-io-width, width);
+ device_property_read_u32(dev, reg-io-width, width);
if (width == 4)
config-flags |= SMSC911X_USE_32BIT;
else
config-flags |= SMSC911X_USE_16BIT;
- if (of_get_property(np, smsc,irq-active-high, NULL))
+ if (device_property_present(dev, smsc,irq-active-high))
config-irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH;
- if (of_get_property(np, smsc,irq-push-pull, NULL))
+ if (device_property_present(dev, smsc,irq-push-pull))
config-irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL;
- if (of_get_property(np, smsc,force-internal-phy, NULL))
+ if (device_property_present(dev, smsc,force-internal-phy))
config-flags |= SMSC911X_FORCE_INTERNAL_PHY;
- if (of_get_property(np, smsc,force-external-phy, NULL))
+ if (device_property_present(dev, smsc,force-external-phy))
config-flags |= SMSC911X_FORCE_EXTERNAL_PHY;
- if (of_get_property(np, smsc,save-mac-address, NULL))
+ if (device_property_present(dev, smsc,save-mac-address))
config-flags |= SMSC911X_SAVE_MAC_ADDRESS;
return 0;
}
-#else
-static inline int smsc911x_probe_config_dt(
- struct smsc911x_platform_config *config,
- struct device_node *np)
-{
- return -ENODEV;
-}
-#endif /* CONFIG_OF */
static int smsc911x_drv_probe(struct platform_device *pdev)
{
- struct device_node *np = pdev-dev.of_node;
struct net_device *dev;
struct smsc911x_data *pdata;
struct smsc911x_platform_config *config = dev_get_platdata(pdev-dev);
@@ -2478,7 +2467,7 @@ static int smsc911x_drv_probe(struct platform_device
*pdev)
goto out_disable_resources;
}
- retval = smsc911x_probe_config_dt(pdata-config, np);
+ retval = smsc911x_probe_config(pdata-config, pdev-dev);
if (retval config) {
/* copy config parameters across to pdata */
memcpy(pdata-config, config, sizeof(pdata-config));
@@ -2654,6 +2643,12 @@ static const struct of_device_id smsc911x_dt_ids[] = {
MODULE_DEVICE_TABLE(of, smsc911x_dt_ids);
#endif
+static const struct acpi_device_id smsc911x_acpi_match[] = {
+ { ARMH9118, 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, smsc911x_acpi_match);
+
static struct platform_driver smsc911x_driver = {
.probe = smsc911x_drv_probe,
.remove = smsc911x_drv_remove,
@@ -2661,6 +2656,7 @@ static struct platform_driver smsc911x_driver = {
.name = SMSC_CHIPNAME,
.pm = SMSC911X_PM_OPS,
.of_match_table = of_match_ptr(smsc911x_dt_ids),
+ .acpi_match_table = ACPI_PTR(smsc911x_acpi_match),
},
};
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Enable smsc911x for use with ACPI
This set of patches enables the front Ethernet port on the ARM Juno development platform when used with an ACPI enabled kernel. These patches covert the of_property* calls in the driver to the DT/ACPI agnostic device_property* calls, and add the arm hardware id to the acpi_match_table. To support the above changes I copied a couple routines from of_net into the properties.c file, and modified them to be ACPI/DT agnostic. I'm not 100% sure this is the correct location for these functions. But I think they are required to avoid having a dozen different implementations scattered across assorted Ethernet adapters that are being enabled to use ACPI properties. Jeremy Linton (2): Add a matching set of device_ functions for determining mac/phy Convert smsc911x to use ACPI as well as DT drivers/base/property.c | 73 drivers/net/ethernet/smsc/smsc911x.c | 48 +++- include/linux/property.h | 4 ++ 3 files changed, 99 insertions(+), 26 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv1 net-next 0/5] netlink: mmap: kernel panic and some issues
From: Ken-ichirou MATSUZAWA chama...@gmail.com Date: Wed, 12 Aug 2015 17:28:24 +0900 It would be better if someone else is working on this. Or could you help me out? It's a tough work for me. If you are fixing a panic, you must show that panic message and describe in detail the exact sequence of events and state that lead to that crash. And then also exactly why your fix takes care of the problem, and why it is the proper way to approach the issue. As-is, your commit message and this top-level introductory posting are way too terse and I myself can't even figure out what exactly the purpose of this series is, and what bug it is precisely fixing. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 11/11] soc/qman: add qman_delete_cgr_safe()
From: Madalin Bucur madalin.bu...@freescale.com
Add qman_delete_cgr_safe() that can be called from any CPU.
This in turn schedules qman_delete_cgr() on the proper CPU.
Signed-off-by: Madalin Bucur madalin.bu...@freescale.com
Signed-off-by: Roy Pledge roy.ple...@freescale.com
---
drivers/soc/fsl/qbman/qman_api.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman_api.c b/drivers/soc/fsl/qbman/qman_api.c
index d4f9be0..1dd60f2 100644
--- a/drivers/soc/fsl/qbman/qman_api.c
+++ b/drivers/soc/fsl/qbman/qman_api.c
@@ -2463,6 +2463,8 @@ EXPORT_SYMBOL(qman_modify_cgr);
QM_CHANNEL_SWPORTAL0))
#define PORTAL_IDX(n) (n-config-public_cfg.channel - QM_CHANNEL_SWPORTAL0)
+static u8 qman_cgr_cpus[__CGR_NUM];
+
int qman_create_cgr(struct qman_cgr *cgr, u32 flags,
struct qm_mcc_initcgr *opts)
{
@@ -2479,7 +2481,10 @@ int qman_create_cgr(struct qman_cgr *cgr, u32 flags,
if (cgr-cgrid = __CGR_NUM)
return -EINVAL;
+ preempt_disable();
p = get_affine_portal();
+ qman_cgr_cpus[cgr-cgrid] = smp_processor_id();
+ preempt_enable();
memset(local_opts, 0, sizeof(struct qm_mcc_initcgr));
cgr-chan = p-config-public_cfg.channel;
@@ -2621,6 +2626,47 @@ put_portal:
}
EXPORT_SYMBOL(qman_delete_cgr);
+struct cgr_comp {
+ struct qman_cgr *cgr;
+ struct completion completion;
+};
+
+static int qman_delete_cgr_thread(void *p)
+{
+ struct cgr_comp *cgr_comp = (struct cgr_comp *)p;
+ int res;
+
+ res = qman_delete_cgr((struct qman_cgr *)cgr_comp-cgr);
+ complete(cgr_comp-completion);
+
+ return res;
+}
+
+void qman_delete_cgr_safe(struct qman_cgr *cgr)
+{
+ struct task_struct *thread;
+ struct cgr_comp cgr_comp;
+
+ preempt_disable();
+ if (qman_cgr_cpus[cgr-cgrid] != smp_processor_id()) {
+ init_completion(cgr_comp.completion);
+ cgr_comp.cgr = cgr;
+ thread = kthread_create(qman_delete_cgr_thread, cgr_comp,
+ cgr_del);
+
+ if (likely(!IS_ERR(thread))) {
+ kthread_bind(thread, qman_cgr_cpus[cgr-cgrid]);
+ wake_up_process(thread);
+ wait_for_completion(cgr_comp.completion);
+ preempt_enable();
+ return;
+ }
+ }
+ qman_delete_cgr(cgr);
+ preempt_enable();
+}
+EXPORT_SYMBOL(qman_delete_cgr_safe);
+
int qman_set_wpm(int wpm_enable)
{
return qm_set_wpm(wpm_enable);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 07/11] soc/bman: Add debugfs support for the BMan driver
From: Geoff Thorpe geoff.tho...@freescale.com
Add debugfs support for querying the state of hardware based
Buffer Manager pools used in DPAA 1.0.
Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com
Signed-off-by: Emil Medve emilian.me...@freescale.com
Signed-off-by: Roy Pledge roy.ple...@freescale.com
---
drivers/soc/fsl/qbman/Kconfig|7 ++
drivers/soc/fsl/qbman/Makefile |1 +
drivers/soc/fsl/qbman/bman-debugfs.c | 117 ++
drivers/soc/fsl/qbman/bman_api.c | 19 ++
drivers/soc/fsl/qbman/dpaa_sys.h |7 +-
5 files changed, 145 insertions(+), 6 deletions(-)
create mode 100644 drivers/soc/fsl/qbman/bman-debugfs.c
diff --git a/drivers/soc/fsl/qbman/Kconfig b/drivers/soc/fsl/qbman/Kconfig
index 1f2063a..919ef15 100644
--- a/drivers/soc/fsl/qbman/Kconfig
+++ b/drivers/soc/fsl/qbman/Kconfig
@@ -54,6 +54,13 @@ config FSL_BMAN_TEST_THRESH
drainer thread, and the other threads that they observe exactly
the depletion state changes that are expected.
+config FSL_BMAN_DEBUGFS
+ tristate BMan debugfs support
+ depends on DEBUG_FS
+ default n
+ help
+ BMan debugfs support
+
config FSL_QMAN
bool QMan device management
default n
diff --git a/drivers/soc/fsl/qbman/Makefile b/drivers/soc/fsl/qbman/Makefile
index 82f5482..2b53fbc 100644
--- a/drivers/soc/fsl/qbman/Makefile
+++ b/drivers/soc/fsl/qbman/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_FSL_BMAN_TEST) += bman-test.o
bman-test-y = bman_test.o
bman-test-$(CONFIG_FSL_BMAN_TEST_API) += bman_test_api.o
bman-test-$(CONFIG_FSL_BMAN_TEST_THRESH) += bman_test_thresh.o
+obj-$(CONFIG_FSL_BMAN_DEBUGFS) += bman-debugfs.o
obj-$(CONFIG_FSL_QMAN) += qman_api.o qman_utils.o
qman_driver.o
obj-$(CONFIG_FSL_QMAN_CONFIG) += qman.o qman_portal.o
diff --git a/drivers/soc/fsl/qbman/bman-debugfs.c
b/drivers/soc/fsl/qbman/bman-debugfs.c
new file mode 100644
index 000..b384f47
--- /dev/null
+++ b/drivers/soc/fsl/qbman/bman-debugfs.c
@@ -0,0 +1,117 @@
+/* Copyright 2010 - 2015 Freescale Semiconductor, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include bman_priv.h
+
+static struct dentry *dfs_root; /* debugfs root directory */
+
+/* Query Buffer Pool State */
+
+static int query_bp_state_show(struct seq_file *file, void *offset)
+{
+ int ret;
+ struct bm_pool_state state;
+ int i, j;
+ u32 mask;
+
+ memset(state, 0, sizeof(state));
+ ret = bman_query_pools(state);
+ if (ret) {
+ seq_printf(file, Error %d\n, ret);
+ return ret;
+ }
+
+ seq_puts(file, bp_id free_buffers_avail bp_depleted\n);
+ for (i = 0; i 2; i++) {
+ mask = 0x8000;
+ for (j = 0; j 32; j++) {
+ seq_printf(file,
+ %-2u %-3s %-3s\n,
+(i * 32) + j,
+state.as.state.__state[i] mask ? no : yes,
+state.ds.state.__state[i] mask ? yes : no);
+mask = 1;
+
[patch] cosa: missing error code on failure in probe()
If register_hdlc_device() fails, the current code returns 0 but we
should return an error code instead.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index 7193b73..848ea6a 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -589,7 +589,8 @@ static int cosa_probe(int base, int irq, int dma)
chan-netdev-base_addr = chan-cosa-datareg;
chan-netdev-irq = chan-cosa-irq;
chan-netdev-dma = chan-cosa-dma;
- if (register_hdlc_device(chan-netdev)) {
+ err = register_hdlc_device(chan-netdev);
+ if (err) {
netdev_warn(chan-netdev,
register_hdlc_device() failed\n);
free_netdev(chan-netdev);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] net: dsa: Do not override PHY interface if already configured
From: Florian Fainelli f.faine...@gmail.com Date: Sat, 8 Aug 2015 12:58:57 -0700 In case we need to divert reads/writes using the slave MII bus, we may have already fetched a valid PHY interface property from Device Tree, and that mode is used by the PHY driver to make configuration decisions. If we could not fetch the phy-mode property, we will assign p-phy_interface to PHY_INTERFACE_MODE_NA, such that we can actually check for that condition as to whether or not we should override the interface value. Fixes: 19334920eaf7 (net: dsa: Set valid phy interface type) Signed-off-by: Florian Fainelli f.faine...@gmail.com --- Hi Guenter, Could you verify this does not break what you were trying to fix with your change? I am fairly confident this will not because for PHYs built-into the switch port we will not be able to fetch a phy-mode property from DT, so we will use PHY_INTERFACE_MODE_NA, but here, we will re-assign them to PHY_INTERFACE_MODE_GMII as before. I was trying to wait for Guenter's testing before applying this, but it's been some time already and it makes no sense to wait any longer. Applied to 'net', thanks Florian. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/2] net: track link status of ipv6 nexthops
On Wed, Aug 12, 2015 at 02:32:26PM -0700, David Miller wrote: From: Andy Gospodarek go...@cumulusnetworks.com Date: Mon, 10 Aug 2015 14:46:52 -0400 I went this way as the idea of storing this info in a flags structure for 2 reasons: - This idea or marking on link status changes and checking for that mark during forwarding was done what was suggested by Alex et al for the ipv4 code and I wanted to keep the overall design similar. - New flags will likely be needed when switchdev support is added for ipv6 routes so going ahead and mirroring the RTNH_F* flags in the the ipv6 code seemed reasonable. I would actually be fine with what you proposed (it is closer to the first implementation), so if my justification above does not change your mind, let me know and I'll post a v2 that does not add rt6i_nhflags and simply checks netif_carrier_ok() rather than RTNH_F_LINKDOWN. Ok fair enough, if we'll need more flags later then so be it. Andy, please resubmit this series, I'll apply it. Thanks, Dave. Will do. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/2] lan78xx: Fix Smatch Warnings
From: woojung@microchip.com Date: Tue, 11 Aug 2015 15:21:41 + lan78xx.c:2282 tx_complete() warn: variable dereferenced before check 'skb' (see line 2249) lan78xx.c:2885 lan78xx_bh() info: ignoring unreachable code. lan78xx.c:3159 lan78xx_probe() info: ignoring unreachable code. Reported-by: Dan Carpenter dan.carpen...@oracle.com Signed-off-by: Woojung Huh woojung@microchip.com Applied. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/2] lan78xx: Remove BUG_ON()
From: woojung@microchip.com Date: Tue, 11 Aug 2015 15:23:33 + Removing BUG_ON() Signed-off-by: Woojung Huh woojung@microchip.com Applied. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On 2015-08-12 23:40, David Miller wrote: From: li...@eikelenboom.it Date: Wed, 12 Aug 2015 22:50:42 +0200 On 2015-08-12 22:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 21:19 +0200, li...@eikelenboom.it wrote: Hi, On my box running Xen with a 4.2-rc6 kernel i still get this splat in dom0, which crashes the box. (i reported a similar splat before (at rc4) here, http://www.spinics.net/lists/netdev/msg337570.html) Never seen this one on 4.1, so it seems a regression. -- Sander [81133.193439] general protection fault: [#1] SMP [81133.204284] Modules linked in: [81133.214934] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.2.0-rc6-20150811-linus-doflr+ #1 [81133.225632] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [81133.236237] task: 880059b91580 ti: 880059bb4000 task.ti: 880059bb4000 [81133.246808] RIP: e030:[8110fb18] [8110fb18] detach_if_pending+0x18/0x80 [81133.257354] RSP: e02b:880059bb7848 EFLAGS: 00010086 [81133.267749] RAX: 88004eddc7f0 RBX: 88000e20ae08 RCX: dead00200200 [81133.278201] RDX: RSI: 88005f60e600 RDI: 88000e20ae08 [81133.288723] RBP: 880059bb7848 R08: 0001 R09: 0001 [81133.298930] R10: 0003 R11: 88000e20ad68 R12: [81133.308875] R13: 000101735569 R14: 00015f90 R15: 88005f60e600 [81133.318845] FS: 7f28c6f7c800() GS:88005f60() knlGS: [81133.328864] CS: e033 DS: ES: CR0: 8005003b [81133.338693] CR2: 807f6800 CR3: 3d55c000 CR4: 0660 [81133.348462] Stack: [81133.358005] 880059bb7898 8110fe3f 810fc261 0200 [81133.367682] 0003 88000e20ad68 88005854d400 [81133.377064] 00015f90 880059bb78c8 819b5243 [81133.386374] Call Trace: [81133.395596] [8110fe3f] mod_timer_pending+0x3f/0xe0 [81133.404999] [810fc261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [81133.414255] [819b5243] __nf_ct_refresh_acct+0xa3/0xb0 [81133.423137] [819bbe8b] tcp_packet+0xb3b/0x1290 [81133.431894] [810cb8ca] ? __local_bh_enable_ip+0x2a/0x90 [81133.440622] [819b4939] ? __nf_conntrack_find_get+0x129/0x2a0 [81133.449339] [819b682c] nf_conntrack_in+0x29c/0x7c0 [81133.457940] [81a67181] ipv4_conntrack_in+0x21/0x30 [81133.466296] [819aea1c] nf_iterate+0x4c/0x80 [81133.474401] [819aeab4] nf_hook_slow+0x64/0xc0 [81133.482615] [81a211ec] ip_rcv+0x2ec/0x380 [81133.490781] [81a209f0] ? ip_local_deliver_finish+0x130/0x130 [81133.498790] [8197e140] __netif_receive_skb_core+0x2a0/0x970 [81133.506714] [81a56db8] ? inet_gro_receive+0x1c8/0x200 [81133.514609] [81980705] __netif_receive_skb+0x15/0x70 [81133.522333] [8198077e] netif_receive_skb_internal+0x1e/0x80 [81133.529840] [81980f3b] napi_gro_receive+0x6b/0x90 [81133.537173] [81740fb6] rtl8169_poll+0x2e6/0x600 [81133.54] [810fc261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [81133.551566] [81981ad7] net_rx_action+0x1f7/0x300 [81133.558412] [810cb6c3] __do_softirq+0x103/0x210 [81133.565353] [810cb807] run_ksoftirqd+0x37/0x60 [81133.572359] [810e4de0] smpboot_thread_fn+0x130/0x190 [81133.579215] [810e4cb0] ? sort_range+0x20/0x20 [81133.586042] [810e1fae] kthread+0xee/0x110 [81133.592792] [810e1ec0] ? kthread_create_on_node+0x1b0/0x1b0 [81133.599694] [81af92df] ret_from_fork+0x3f/0x70 [81133.606662] [810e1ec0] ? kthread_create_on_node+0x1b0/0x1b0 [81133.613445] Code: 77 28 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 8b 47 08 55 48 89 e5 48 85 c0 74 6a 48 8b 0f 48 85 c9 48 89 08 74 04 48 89 41 08 84 d2 74 08 48 c7 47 08 00 00 00 00 f6 47 2a 10 48 [81133.627196] RIP [8110fb18] detach_if_pending+0x18/0x80 [81133.634036] RSP 880059bb7848 [81133.640817] ---[ end trace eaf596e1fcf6a591 ]--- [81133.647521] Kernel panic - not syncing: Fatal exception in interrupt This looks like the bug fixed in David Miller net tree : http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=2235f2ac75fd2501c251b0b699a9632e80239a6d Will pull the net-tree in and re-test. You should not pull the 'net-next', but rather the 'net' one. 'net' is not necessarily included in 'net-next'. Thanks for the reminder, but luckily i was aware of that, seen enough of your replies asking for patches to be resubmitted against the other tree ;) Kernel with patch is currently running so fingers crossed. -- Sander -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 3/6] geneve: Add support to collect tunnel metadata.
On Wed, Aug 12, 2015 at 1:53 PM, Jesse Gross je...@nicira.com wrote:
On Tue, Aug 11, 2015 at 10:17 PM, Pravin B Shelar pshe...@nicira.com wrote:
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 5e9bab8..a463383 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
+static struct geneve_dev *geneve_lookup(struct geneve_net *gn,
+ struct iphdr *iph,
+ struct genevehdr *gnvh)
{
- struct genevehdr *gnvh = geneve_hdr(skb);
- struct geneve_dev *dummy, *geneve = NULL;
- struct geneve_net *gn;
- struct iphdr *iph = NULL;
- struct pcpu_sw_netstats *stats;
struct hlist_head *vni_list_head;
- int err = 0;
+ struct geneve_dev *geneve;
__u32 hash;
- iph = ip_hdr(skb); /* Still outer IP header... */
-
- gn = gs-rcv_data;
-
/* Find the device for this VNI */
hash = geneve_net_vni_hash(gnvh-vni);
vni_list_head = gn-vni_list[hash];
- hlist_for_each_entry_rcu(dummy, vni_list_head, hlist) {
- if (!memcmp(gnvh-vni, dummy-vni, sizeof(dummy-vni))
- iph-saddr == dummy-remote.sin_addr.s_addr) {
- geneve = dummy;
- break;
+ hlist_for_each_entry_rcu(geneve, vni_list_head, hlist) {
+ if (!memcmp(gnvh-vni, geneve-vni, sizeof(geneve-vni))
+ iph-saddr == geneve-remote.sin_addr.s_addr) {
+ return geneve;
}
}
+
+ return rcu_dereference(gn-collect_md_tun);
+}
I think this operates differently from VXLAN (and GRE I believe) where
you can't have tunnels based on the VNI overlapping the
collect_md_tun. VXLAN is nice because it can go straight from the
socket to collecting metadata without having to an additional lookup
that doesn't give any additional information and it seems a little
simpler because we don't need to keep track of a flow-based device.
However, at the very least the behavior should be consistent.
This is how GRE works. But I can check for flow based device first to
keep it consistent with vxlan.
+/* geneve receive/decap routine */
+static void geneve_rx(struct geneve_sock *gs, struct sk_buff *skb)
+{
+ struct genevehdr *gnvh = geneve_hdr(skb);
+ struct metadata_dst *tun_dst = NULL;
+ struct geneve_dev *geneve = NULL;
+ struct pcpu_sw_netstats *stats;
+ struct geneve_net *gn;
+ struct iphdr *iph;
+ int err;
+
+ iph = ip_hdr(skb); /* Still outer IP header... */
+ gn = gs-rcv_data;
+ geneve = geneve_lookup(gn, iph, gnvh);
if (!geneve)
goto drop;
- /* Drop packets w/ critical options,
-* since we don't support any...
-*/
- if (gnvh-critical)
- goto drop;
+ if (geneve-collect_md) {
Should this also check ip_tunnel_collect_metadata()? GRE has the same issue.
ok.
@@ -103,7 +146,8 @@ static void geneve_rx(struct geneve_sock *gs, struct
sk_buff *skb)
skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
/* Ignore packet loops (and multicast echo) */
- if (ether_addr_equal(eth_hdr(skb)-h_source, geneve-dev-dev_addr))
+ if (!geneve-collect_md
+ ether_addr_equal(eth_hdr(skb)-h_source, geneve-dev-dev_addr))
goto drop;
Why is this different in the collect_md case?
@@ -128,10 +169,18 @@ static void geneve_rx(struct geneve_sock *gs, struct
sk_buff *skb)
stats-rx_bytes += skb-len;
u64_stats_update_end(stats-syncp);
+ if (tun_dst)
+ skb_dst_set(skb, (struct dst_entry *)tun_dst);
I think there is a leak if we allocate the dst but then drop the
packet before we set it on the skb. It seems easier to just set it
earlier.
ok.
-static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
+static struct rtable *geneve_get_rt(struct sk_buff *skb,
+ struct net_device *dev,
+ struct flowi4 *fl4,
+ struct ip_tunnel_info *info)
{
[...]
+ if (info) {
+ fl4-daddr = info-key.ipv4_dst;
+ fl4-saddr = info-key.ipv4_src;
+ fl4-flowi4_tos = RT_TOS(info-key.ipv4_tos);
+ fl4-flowi4_mark = skb-mark;
+ fl4-flowi4_proto = IPPROTO_UDP;
+ } else {
+ tos = geneve-tos;
+ if (tos == 1) {
+ const struct iphdr *iip = ip_hdr(skb);
+
+ tos = ip_tunnel_get_dsfield(iip, skb);
+ }
Should the mark and protocol be used in both cases?
It is not done in current code, so did not changed the behavior.
+static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct
Re: [PATCH v2 net-next] bpf: fix bpf_perf_event_read() loop upper bound
From: Wei-Chun Chao weich...@plumgrid.com Date: Wed, 12 Aug 2015 07:57:12 -0700 Verifier rejects programs incorrectly. Fixes: 35578d798400 (bpf: Implement function bpf_perf_event_read()) Cc: Kaixu Xia xiaka...@huawei.com Cc: Alexei Starovoitov a...@plumgrid.com Signed-off-by: Wei-Chun Chao weich...@plumgrid.com --- v2: better subject line Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] cosa: missing error code on failure in probe()
From: Dan Carpenter dan.carpen...@oracle.com Date: Thu, 13 Aug 2015 00:08:01 +0300 If register_hdlc_device() fails, the current code returns 0 but we should return an error code instead. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Applied, thanks Dan. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 08/11] soc/qman: Add debugfs support for the QMan driver
From: Geoff Thorpe geoff.tho...@freescale.com
Add debugfs sypport for querying the state of hardware based
queues managed by the DPAA 1.0 Queue Manager.
Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com
Signed-off-by: Emil Medve emilian.me...@freescale.com
Signed-off-by: Madalin Bucur madalin.bu...@freescale.com
Signed-off-by: Roy Pledge roy.ple...@freescale.com
---
drivers/soc/fsl/qbman/Makefile |1 +
drivers/soc/fsl/qbman/dpaa_sys.h |2 +
drivers/soc/fsl/qbman/qman-debugfs.c | 1313 ++
drivers/soc/fsl/qbman/qman_api.c | 60 +-
drivers/soc/fsl/qbman/qman_priv.h|8 +
5 files changed, 1382 insertions(+), 2 deletions(-)
create mode 100644 drivers/soc/fsl/qbman/qman-debugfs.c
diff --git a/drivers/soc/fsl/qbman/Makefile b/drivers/soc/fsl/qbman/Makefile
index 2b53fbc..cce1f70 100644
--- a/drivers/soc/fsl/qbman/Makefile
+++ b/drivers/soc/fsl/qbman/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_FSL_QMAN_TEST) += qman-test.o
qman-test-y = qman_test.o
qman-test-$(CONFIG_FSL_QMAN_TEST_API) += qman_test_api.o
qman-test-$(CONFIG_FSL_QMAN_TEST_STASH)+= qman_test_stash.o
+obj-$(CONFIG_FSL_QMAN_DEBUGFS) += qman-debugfs.o
diff --git a/drivers/soc/fsl/qbman/dpaa_sys.h b/drivers/soc/fsl/qbman/dpaa_sys.h
index 3cf446a..0dd341c 100644
--- a/drivers/soc/fsl/qbman/dpaa_sys.h
+++ b/drivers/soc/fsl/qbman/dpaa_sys.h
@@ -38,7 +38,9 @@
#include linux/of_irq.h
#include linux/of_reserved_mem.h
#include linux/kthread.h
+#include linux/uaccess.h
#include linux/debugfs.h
+#include linux/vmalloc.h
#include linux/platform_device.h
#include linux/ctype.h
diff --git a/drivers/soc/fsl/qbman/qman-debugfs.c
b/drivers/soc/fsl/qbman/qman-debugfs.c
new file mode 100644
index 000..57585e8
--- /dev/null
+++ b/drivers/soc/fsl/qbman/qman-debugfs.c
@@ -0,0 +1,1313 @@
+/* Copyright 2010 - 2015 Freescale Semiconductor, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include qman_priv.h
+
+#define MAX_FQID (0x00ff)
+#define QM_FQD_BLOCK_SIZE 64
+#define QM_FQD_AR(0xC10)
+
+static u32 fqid_max;
+static u64 qman_ccsr_start;
+static u64 qman_ccsr_size;
+
+static const char * const state_txt[] = {
+ Out of Service,
+ Retired,
+ Tentatively Scheduled,
+ Truly Scheduled,
+ Parked,
+ Active, Active Held or Held Suspended,
+ Unknown State 6,
+ Unknown State 7,
+ NULL,
+};
+
+static const u8 fqd_states[] = {
+ QM_MCR_NP_STATE_OOS, QM_MCR_NP_STATE_RETIRED, QM_MCR_NP_STATE_TEN_SCHED,
+ QM_MCR_NP_STATE_TRU_SCHED, QM_MCR_NP_STATE_PARKED,
+ QM_MCR_NP_STATE_ACTIVE};
+
+struct mask_to_text {
+ u16 mask;
+ const char *txt;
+};
+
+struct mask_filter_s {
+ u16 mask;
+ u8 filter;
+};
+
+static const struct mask_filter_s mask_filter[] = {
+ {QM_FQCTRL_PREFERINCACHE, 0},
+ {QM_FQCTRL_PREFERINCACHE, 1},
+ {QM_FQCTRL_HOLDACTIVE, 0},
+ {QM_FQCTRL_HOLDACTIVE, 1},
+ {QM_FQCTRL_AVOIDBLOCK, 0},
+ {QM_FQCTRL_AVOIDBLOCK, 1},
+ {QM_FQCTRL_FORCESFDR, 0},
+ {QM_FQCTRL_FORCESFDR, 1},
+ {QM_FQCTRL_CPCSTASH, 0},
+ {QM_FQCTRL_CPCSTASH, 1},
+
Re: Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
From: li...@eikelenboom.it Date: Wed, 12 Aug 2015 22:50:42 +0200 On 2015-08-12 22:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 21:19 +0200, li...@eikelenboom.it wrote: Hi, On my box running Xen with a 4.2-rc6 kernel i still get this splat in dom0, which crashes the box. (i reported a similar splat before (at rc4) here, http://www.spinics.net/lists/netdev/msg337570.html) Never seen this one on 4.1, so it seems a regression. -- Sander [81133.193439] general protection fault: [#1] SMP [81133.204284] Modules linked in: [81133.214934] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.2.0-rc6-20150811-linus-doflr+ #1 [81133.225632] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [81133.236237] task: 880059b91580 ti: 880059bb4000 task.ti: 880059bb4000 [81133.246808] RIP: e030:[8110fb18] [8110fb18] detach_if_pending+0x18/0x80 [81133.257354] RSP: e02b:880059bb7848 EFLAGS: 00010086 [81133.267749] RAX: 88004eddc7f0 RBX: 88000e20ae08 RCX: dead00200200 [81133.278201] RDX: RSI: 88005f60e600 RDI: 88000e20ae08 [81133.288723] RBP: 880059bb7848 R08: 0001 R09: 0001 [81133.298930] R10: 0003 R11: 88000e20ad68 R12: [81133.308875] R13: 000101735569 R14: 00015f90 R15: 88005f60e600 [81133.318845] FS: 7f28c6f7c800() GS:88005f60() knlGS: [81133.328864] CS: e033 DS: ES: CR0: 8005003b [81133.338693] CR2: 807f6800 CR3: 3d55c000 CR4: 0660 [81133.348462] Stack: [81133.358005] 880059bb7898 8110fe3f 810fc261 0200 [81133.367682] 0003 88000e20ad68 88005854d400 [81133.377064] 00015f90 880059bb78c8 819b5243 [81133.386374] Call Trace: [81133.395596] [8110fe3f] mod_timer_pending+0x3f/0xe0 [81133.404999] [810fc261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [81133.414255] [819b5243] __nf_ct_refresh_acct+0xa3/0xb0 [81133.423137] [819bbe8b] tcp_packet+0xb3b/0x1290 [81133.431894] [810cb8ca] ? __local_bh_enable_ip+0x2a/0x90 [81133.440622] [819b4939] ? __nf_conntrack_find_get+0x129/0x2a0 [81133.449339] [819b682c] nf_conntrack_in+0x29c/0x7c0 [81133.457940] [81a67181] ipv4_conntrack_in+0x21/0x30 [81133.466296] [819aea1c] nf_iterate+0x4c/0x80 [81133.474401] [819aeab4] nf_hook_slow+0x64/0xc0 [81133.482615] [81a211ec] ip_rcv+0x2ec/0x380 [81133.490781] [81a209f0] ? ip_local_deliver_finish+0x130/0x130 [81133.498790] [8197e140] __netif_receive_skb_core+0x2a0/0x970 [81133.506714] [81a56db8] ? inet_gro_receive+0x1c8/0x200 [81133.514609] [81980705] __netif_receive_skb+0x15/0x70 [81133.522333] [8198077e] netif_receive_skb_internal+0x1e/0x80 [81133.529840] [81980f3b] napi_gro_receive+0x6b/0x90 [81133.537173] [81740fb6] rtl8169_poll+0x2e6/0x600 [81133.54] [810fc261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [81133.551566] [81981ad7] net_rx_action+0x1f7/0x300 [81133.558412] [810cb6c3] __do_softirq+0x103/0x210 [81133.565353] [810cb807] run_ksoftirqd+0x37/0x60 [81133.572359] [810e4de0] smpboot_thread_fn+0x130/0x190 [81133.579215] [810e4cb0] ? sort_range+0x20/0x20 [81133.586042] [810e1fae] kthread+0xee/0x110 [81133.592792] [810e1ec0] ? kthread_create_on_node+0x1b0/0x1b0 [81133.599694] [81af92df] ret_from_fork+0x3f/0x70 [81133.606662] [810e1ec0] ? kthread_create_on_node+0x1b0/0x1b0 [81133.613445] Code: 77 28 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 8b 47 08 55 48 89 e5 48 85 c0 74 6a 48 8b 0f 48 85 c9 48 89 08 74 04 48 89 41 08 84 d2 74 08 48 c7 47 08 00 00 00 00 f6 47 2a 10 48 [81133.627196] RIP [8110fb18] detach_if_pending+0x18/0x80 [81133.634036] RSP 880059bb7848 [81133.640817] ---[ end trace eaf596e1fcf6a591 ]--- [81133.647521] Kernel panic - not syncing: Fatal exception in interrupt This looks like the bug fixed in David Miller net tree : http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=2235f2ac75fd2501c251b0b699a9632e80239a6d Will pull the net-tree in and re-test. You should not pull the 'net-next', but rather the 'net' one. 'net' is not necessarily included in 'net-next'. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] bpf: fix build warnings and add function read_trace_pipe()
From: Kaixu Xia xiaka...@huawei.com Date: Wed, 12 Aug 2015 09:37:53 + There are two improvements in this patch: 1. Fix the build warnings; 2. Add function read_trace_pipe() to print the result on the screen; Before this patch, we can get the result through /sys/kernel/de bug/tracing/trace_pipe and get nothing on the screen. By applying this patch, the result can be printed on the screen. $ ./tracex6 ... tracex6-705 [003] d..1 131.428593: : CPU-3 19981414 sshd-683 [000] d..1 131.428727: : CPU-0 221682321 sshd-683 [000] d..1 131.428821: : CPU-0 221808766 sshd-683 [000] d..1 131.428950: : CPU-0 221982984 sshd-683 [000] d..1 131.429045: : CPU-0 222111851 tracex6-705 [003] d..1 131.429168: : CPU-3 20757551 sshd-683 [000] d..1 131.429170: : CPU-0 81240 sshd-683 [000] d..1 131.429261: : CPU-0 222403340 sshd-683 [000] d..1 131.429378: : CPU-0 222561024 ... Signed-off-by: Kaixu Xia xiaka...@huawei.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 09/11] soc/bman: Add HOTPLUG_CPU support to the BMan driver
From: Hai-Ying Wang haiying.w...@freescale.com
Add support for CPU hotplug for the DPAA 1.0 Buffer Manager
driver
Signed-off-by: Hai-Ying Wang haiying.w...@freescale.com
Signed-off-by: Emil Medve emilian.me...@freescale.com
Signed-off-by: Roy Pledge roy.ple...@freescale.com
---
drivers/soc/fsl/qbman/bman_portal.c | 40 +++
drivers/soc/fsl/qbman/dpaa_sys.h|3 +++
2 files changed, 43 insertions(+)
diff --git a/drivers/soc/fsl/qbman/bman_portal.c
b/drivers/soc/fsl/qbman/bman_portal.c
index 62d8f64..f33d671 100644
--- a/drivers/soc/fsl/qbman/bman_portal.c
+++ b/drivers/soc/fsl/qbman/bman_portal.c
@@ -129,6 +129,42 @@ static void __cold bman_offline_cpu(unsigned int cpu)
}
}
+#ifdef CONFIG_HOTPLUG_CPU
+static void __cold bman_online_cpu(unsigned int cpu)
+{
+ struct bman_portal *p = (struct bman_portal *)affine_bportals[cpu];
+ const struct bm_portal_config *pcfg;
+
+ if (p) {
+ pcfg = bman_get_bm_portal_config(p);
+ if (pcfg)
+ irq_set_affinity(pcfg-public_cfg.irq, cpumask_of(cpu));
+ }
+}
+
+static int __cold bman_hotplug_cpu_callback(struct notifier_block *nfb,
+ unsigned long action, void *hcpu)
+{
+ unsigned int cpu = (unsigned long)hcpu;
+
+ switch (action) {
+ case CPU_ONLINE:
+ case CPU_ONLINE_FROZEN:
+ bman_online_cpu(cpu);
+ break;
+ case CPU_DOWN_PREPARE:
+ case CPU_DOWN_PREPARE_FROZEN:
+ bman_offline_cpu(cpu);
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block bman_hotplug_cpu_notifier = {
+ .notifier_call = bman_hotplug_cpu_callback,
+};
+#endif /* CONFIG_HOTPLUG_CPU */
+
static int __cold bman_portal_probe(struct platform_device *of_dev)
{
struct device *dev = of_dev-dev;
@@ -342,6 +378,10 @@ static int __init bman_portal_driver_register(struct
platform_driver *drv)
for_each_cpu(cpu, offline_cpus)
bman_offline_cpu(cpu);
+#ifdef CONFIG_HOTPLUG_CPU
+ register_hotcpu_notifier(bman_hotplug_cpu_notifier);
+#endif
+
bman_seed_bpid_range(0, bman_pool_max);
return 0;
diff --git a/drivers/soc/fsl/qbman/dpaa_sys.h b/drivers/soc/fsl/qbman/dpaa_sys.h
index 0dd341c..d1da092 100644
--- a/drivers/soc/fsl/qbman/dpaa_sys.h
+++ b/drivers/soc/fsl/qbman/dpaa_sys.h
@@ -43,6 +43,9 @@
#include linux/vmalloc.h
#include linux/platform_device.h
#include linux/ctype.h
+#ifdef CONFIG_HOTPLUG_CPU
+#include linux/cpu.h
+#endif
#include asm/pgtable.h
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 10/11] soc/qman: Add HOTPLUG_CPU support to the QMan driver
From: Hai-Ying Wang haiying.w...@freescale.com
Add support for CPU hotplug for the DPAA 1.0 Queue Manager
driver.
Signed-off-by: Hai-Ying Wang haiying.w...@freescale.com
Signed-off-by: Emil Medve emilian.me...@freescale.com
Signed-off-by: Roy Pledge roy.ple...@freescale.com
---
drivers/soc/fsl/qbman/qman_portal.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman_portal.c
b/drivers/soc/fsl/qbman/qman_portal.c
index ad9e3ba..85acba2 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -474,6 +474,46 @@ static void qman_offline_cpu(unsigned int cpu)
}
}
+#ifdef CONFIG_HOTPLUG_CPU
+static void qman_online_cpu(unsigned int cpu)
+{
+ struct qman_portal *p;
+ const struct qm_portal_config *pcfg;
+
+ p = (struct qman_portal *)affine_portals[cpu];
+ if (p) {
+ pcfg = qman_get_qm_portal_config(p);
+ if (pcfg) {
+ irq_set_affinity(pcfg-public_cfg.irq, cpumask_of(cpu));
+ qman_portal_update_sdest(pcfg, cpu);
+ }
+ }
+}
+
+static int qman_hotplug_cpu_callback(struct notifier_block *nfb,
+unsigned long action, void *hcpu)
+{
+ unsigned int cpu = (unsigned long)hcpu;
+
+ switch (action) {
+ case CPU_ONLINE:
+ case CPU_ONLINE_FROZEN:
+ qman_online_cpu(cpu);
+ break;
+ case CPU_DOWN_PREPARE:
+ case CPU_DOWN_PREPARE_FROZEN:
+ qman_offline_cpu(cpu);
+ default:
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block qman_hotplug_cpu_notifier = {
+ .notifier_call = qman_hotplug_cpu_callback,
+};
+#endif /* CONFIG_HOTPLUG_CPU */
+
__init int qman_init(void)
{
struct cpumask slave_cpus;
@@ -597,6 +637,9 @@ __init int qman_init(void)
cpumask_andnot(offline_cpus, cpu_possible_mask, cpu_online_mask);
for_each_cpu(cpu, offline_cpus)
qman_offline_cpu(cpu);
+#ifdef CONFIG_HOTPLUG_CPU
+ register_hotcpu_notifier(qman_hotplug_cpu_notifier);
+#endif
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 06/11] soc/qman: Add self-tester for QMan driver
From: Geoff Thorpe geoff.tho...@freescale.com
Add a self test for the DPAA 1.0 Queue Manager driver. The tests
ensure that the driver can properly enqueue and dequeue from frame
queues using the QMan portal infrastructure.
Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com
Signed-off-by: Emil Medve emilian.me...@freescale.com
Signed-off-by: Roy Pledge roy.ple...@freescale.com
---
drivers/soc/fsl/qbman/Makefile |4 +
drivers/soc/fsl/qbman/qman_test.c | 57
drivers/soc/fsl/qbman/qman_test.h | 44 +++
drivers/soc/fsl/qbman/qman_test_api.c | 216 +
drivers/soc/fsl/qbman/qman_test_stash.c | 502 +++
5 files changed, 823 insertions(+)
create mode 100644 drivers/soc/fsl/qbman/qman_test.c
create mode 100644 drivers/soc/fsl/qbman/qman_test.h
create mode 100644 drivers/soc/fsl/qbman/qman_test_api.c
create mode 100644 drivers/soc/fsl/qbman/qman_test_stash.c
diff --git a/drivers/soc/fsl/qbman/Makefile b/drivers/soc/fsl/qbman/Makefile
index 04509c3..82f5482 100644
--- a/drivers/soc/fsl/qbman/Makefile
+++ b/drivers/soc/fsl/qbman/Makefile
@@ -12,3 +12,7 @@ bman-test-$(CONFIG_FSL_BMAN_TEST_THRESH) +=
bman_test_thresh.o
obj-$(CONFIG_FSL_QMAN) += qman_api.o qman_utils.o
qman_driver.o
obj-$(CONFIG_FSL_QMAN_CONFIG) += qman.o qman_portal.o
+obj-$(CONFIG_FSL_QMAN_TEST)+= qman-test.o
+qman-test-y = qman_test.o
+qman-test-$(CONFIG_FSL_QMAN_TEST_API) += qman_test_api.o
+qman-test-$(CONFIG_FSL_QMAN_TEST_STASH)+= qman_test_stash.o
diff --git a/drivers/soc/fsl/qbman/qman_test.c
b/drivers/soc/fsl/qbman/qman_test.c
new file mode 100644
index 000..9ec49cb
--- /dev/null
+++ b/drivers/soc/fsl/qbman/qman_test.c
@@ -0,0 +1,57 @@
+/* Copyright 2008 - 2015 Freescale Semiconductor, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include qman_test.h
+
+MODULE_AUTHOR(Geoff Thorpe);
+MODULE_LICENSE(Dual BSD/GPL);
+MODULE_DESCRIPTION(QMan testing);
+
+static int test_init(void)
+{
+ int loop = 1;
+
+ while (loop--) {
+#ifdef CONFIG_FSL_QMAN_TEST_STASH
+ qman_test_stash();
+#endif
+#ifdef CONFIG_FSL_QMAN_TEST_API
+ qman_test_api();
+#endif
+ }
+ return 0;
+}
+
+static void test_exit(void)
+{
+}
+
+module_init(test_init);
+module_exit(test_exit);
diff --git a/drivers/soc/fsl/qbman/qman_test.h
b/drivers/soc/fsl/qbman/qman_test.h
new file mode 100644
index 000..0b34a67
--- /dev/null
+++ b/drivers/soc/fsl/qbman/qman_test.h
@@ -0,0 +1,44 @@
+/* Copyright 2008 - 2015 Freescale Semiconductor, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor
[v2 02/11] soc/fsl: Introduce DPAA BMan device management driver
From: Geoff Thorpe geoff.tho...@freescale.com This driver enables the Freescale DPAA 1.0 Buffer Manager block. BMan is a hardware buffer pool manager that allows accelerators connected to the SoC datapath to acquire and release buffers during data processing. Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com Signed-off-by: Emil Medve emilian.me...@freescale.com Signed-off-by: Roy Pledge roy.ple...@freescale.com --- drivers/soc/Kconfig |1 + drivers/soc/Makefile |1 + drivers/soc/fsl/Kconfig |5 + drivers/soc/fsl/Makefile |3 + drivers/soc/fsl/qbman/Kconfig | 25 ++ drivers/soc/fsl/qbman/Makefile|1 + drivers/soc/fsl/qbman/bman.c | 553 + drivers/soc/fsl/qbman/bman_priv.h | 53 drivers/soc/fsl/qbman/dpaa_sys.h | 55 9 files changed, 697 insertions(+) create mode 100644 drivers/soc/fsl/Kconfig create mode 100644 drivers/soc/fsl/Makefile create mode 100644 drivers/soc/fsl/qbman/Kconfig create mode 100644 drivers/soc/fsl/qbman/Makefile create mode 100644 drivers/soc/fsl/qbman/bman.c create mode 100644 drivers/soc/fsl/qbman/bman_priv.h create mode 100644 drivers/soc/fsl/qbman/dpaa_sys.h diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 96ddecb..4e3c8f4 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -1,6 +1,7 @@ menu SOC (System On Chip) specific Drivers source drivers/soc/mediatek/Kconfig +source drivers/soc/fsl/Kconfig source drivers/soc/qcom/Kconfig source drivers/soc/sunxi/Kconfig source drivers/soc/ti/Kconfig diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 7dc7c0d..7adcd97 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/ +obj-$(CONFIG_FSL_SOC) += fsl/ obj-$(CONFIG_ARCH_QCOM)+= qcom/ obj-$(CONFIG_ARCH_SUNXI) += sunxi/ obj-$(CONFIG_ARCH_TEGRA) += tegra/ diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig new file mode 100644 index 000..daa9c0d --- /dev/null +++ b/drivers/soc/fsl/Kconfig @@ -0,0 +1,5 @@ +menu Freescale SOC (System On Chip) specific Drivers + +source drivers/soc/fsl/qbman/Kconfig + +endmenu diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile new file mode 100644 index 000..19e74bb --- /dev/null +++ b/drivers/soc/fsl/Makefile @@ -0,0 +1,3 @@ +# Common +obj-$(CONFIG_FSL_DPA) += qbman/ + diff --git a/drivers/soc/fsl/qbman/Kconfig b/drivers/soc/fsl/qbman/Kconfig new file mode 100644 index 000..be4ae01 --- /dev/null +++ b/drivers/soc/fsl/qbman/Kconfig @@ -0,0 +1,25 @@ +menuconfig FSL_DPA + bool Freescale DPAA support + depends on FSL_SOC || COMPILE_TEST + default n + help + FSL Data-Path Acceleration Architecture drivers + + These are not the actual Ethernet driver(s) + +if FSL_DPA + +config FSL_DPA_CHECKING + bool additional driver checking + default n + help + Compiles in additional checks to sanity-check the drivers and + any use of it by other code. Not recommended for performance + +config FSL_BMAN + tristate BMan device management + default n + help + FSL DPAA BMan driver + +endif # FSL_DPA diff --git a/drivers/soc/fsl/qbman/Makefile b/drivers/soc/fsl/qbman/Makefile new file mode 100644 index 000..02014d9 --- /dev/null +++ b/drivers/soc/fsl/qbman/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_FSL_BMAN) += bman.o diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c new file mode 100644 index 000..9a500ce --- /dev/null +++ b/drivers/soc/fsl/qbman/bman.c @@ -0,0 +1,553 @@ +/* Copyright (c) 2009 - 2015 Freescale Semiconductor, Inc. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * * Neither the name of Freescale Semiconductor nor the + * names of its contributors may be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * ALTERNATIVELY, this software may be distributed under the terms of the + * GNU General Public License (GPL) as published by the Free Software + * Foundation, either version 2 of that License or (at your option) any + * later version. + * + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +
[v2 00/11] Freescale DPAA QBMan Drivers
The Freescale Data Path Acceleration Architecture (DPAA) is a set of hardware components on specific QorIQ multicore processors. This architecture provides the infrastructure to support simplified sharing of networking interfaces and accelerators by multiple CPU cores and the accelerators. The Queue Manager (QMan) is a hardware queue management block that allows software and accelerators on the datapath to enqueue and dequeue frames in order to communicate. The Buffer Manager (BMan) is a hardware buffer pool management block that allows software and accelerators on the datapath to acquire and release buffers in order to build frames. This patch set introduces the QBMan driver code that configures initializes the QBMan hardware and provides APIs for software to use the frame queues and buffer pools the blocks provide. These drivers provide the base fuctionality for software to communicate with the other DPAA accelerators on Freescale QorIQ processors. Changes from v1: - Cleanup Kconfig options - Changed base QMan and BMan drivers to only be buit in. Will add loadable support in future patch - Replace panic() call with WARN_ON() - Elimanated some unused APIs - Replaced PowerPC specific IO accessors with platform independent versions Emil Medve (1): powerpc: re-add devm_ioremap_prot() Geoff Thorpe (7): soc/fsl: Introduce DPAA BMan device management driver soc/fsl: Introduce the DPAA BMan portal driver soc/fsl: Introduce drivers for the DPAA QMan soc/bman: Add self-tester for BMan driver soc/qman: Add self-tester for QMan driver soc/bman: Add debugfs support for the BMan driver soc/qman: Add debugfs support for the QMan driver Hai-Ying Wang (2): soc/bman: Add HOTPLUG_CPU support to the BMan driver soc/qman: Add HOTPLUG_CPU support to the QMan driver Madalin Bucur (1): soc/qman: add qman_delete_cgr_safe() arch/powerpc/include/asm/io.h |3 + arch/powerpc/lib/Makefile |1 + arch/powerpc/lib/devres.c | 43 + arch/powerpc/platforms/85xx/corenet_generic.c | 16 + arch/powerpc/platforms/85xx/p1023_rdb.c | 14 + drivers/soc/Kconfig |1 + drivers/soc/Makefile |1 + drivers/soc/fsl/Kconfig |5 + drivers/soc/fsl/Makefile |3 + drivers/soc/fsl/qbman/Kconfig | 120 + drivers/soc/fsl/qbman/Makefile| 20 + drivers/soc/fsl/qbman/bman-debugfs.c | 117 + drivers/soc/fsl/qbman/bman.c | 553 + drivers/soc/fsl/qbman/bman.h | 542 + drivers/soc/fsl/qbman/bman_api.c | 1072 + drivers/soc/fsl/qbman/bman_portal.c | 391 drivers/soc/fsl/qbman/bman_priv.h | 134 ++ drivers/soc/fsl/qbman/bman_test.c | 56 + drivers/soc/fsl/qbman/bman_test.h | 34 + drivers/soc/fsl/qbman/bman_test_api.c | 184 ++ drivers/soc/fsl/qbman/bman_test_thresh.c | 198 ++ drivers/soc/fsl/qbman/bman_utils.c| 72 + drivers/soc/fsl/qbman/dpaa_resource.c | 359 +++ drivers/soc/fsl/qbman/dpaa_sys.h | 271 +++ drivers/soc/fsl/qbman/qman-debugfs.c | 1313 +++ drivers/soc/fsl/qbman/qman.c | 1026 + drivers/soc/fsl/qbman/qman.h | 1128 ++ drivers/soc/fsl/qbman/qman_api.c | 2921 + drivers/soc/fsl/qbman/qman_driver.c | 83 + drivers/soc/fsl/qbman/qman_portal.c | 672 ++ drivers/soc/fsl/qbman/qman_priv.h | 287 +++ drivers/soc/fsl/qbman/qman_test.c | 57 + drivers/soc/fsl/qbman/qman_test.h | 44 + drivers/soc/fsl/qbman/qman_test_api.c | 216 ++ drivers/soc/fsl/qbman/qman_test_stash.c | 502 + drivers/soc/fsl/qbman/qman_utils.c| 305 +++ include/soc/fsl/bman.h| 518 + include/soc/fsl/qman.h| 1977 + 38 files changed, 15259 insertions(+) create mode 100644 arch/powerpc/lib/devres.c create mode 100644 drivers/soc/fsl/Kconfig create mode 100644 drivers/soc/fsl/Makefile create mode 100644 drivers/soc/fsl/qbman/Kconfig create mode 100644 drivers/soc/fsl/qbman/Makefile create mode 100644 drivers/soc/fsl/qbman/bman-debugfs.c create mode 100644 drivers/soc/fsl/qbman/bman.c create mode 100644 drivers/soc/fsl/qbman/bman.h create mode 100644 drivers/soc/fsl/qbman/bman_api.c create mode 100644 drivers/soc/fsl/qbman/bman_portal.c create mode 100644 drivers/soc/fsl/qbman/bman_priv.h create mode 100644 drivers/soc/fsl/qbman/bman_test.c create mode 100644 drivers/soc/fsl/qbman/bman_test.h create mode 100644 drivers/soc/fsl/qbman/bman_test_api.c create mode 100644 drivers/soc/fsl/qbman/bman_test_thresh.c create
[v2 01/11] powerpc: re-add devm_ioremap_prot()
From: Emil Medve emilian.me...@freescale.com
devm_ioremap_prot() was removed in commit dedd24a12,
and was introduced in commit b41e5fffe8.
This reverts commit dedd24a12fe6735898feeb06184ee346907abb5d.
Signed-off-by: Emil Medve emilian.me...@freescale.com
---
arch/powerpc/include/asm/io.h |3 +++
arch/powerpc/lib/Makefile |1 +
arch/powerpc/lib/devres.c | 43 +
3 files changed, 47 insertions(+)
create mode 100644 arch/powerpc/lib/devres.c
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index a8d2ef3..9eaf301 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -855,6 +855,9 @@ static inline void * bus_to_virt(unsigned long address)
#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
+void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IO_H */
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index a47e142..7ae60f0 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -13,6 +13,7 @@ obj-y += string.o alloc.o crtsavres.o ppc_ksyms.o
code-patching.o \
feature-fixups.o
obj-$(CONFIG_PPC32)+= div64.o copy_32.o
+obj-$(CONFIG_HAS_IOMEM)+= devres.o
obj64-y+= copypage_64.o copyuser_64.o usercopy_64.o mem_64.o
hweight_64.o \
copyuser_power7.o string_64.o copypage_power7.o memcpy_power7.o \
diff --git a/arch/powerpc/lib/devres.c b/arch/powerpc/lib/devres.c
new file mode 100644
index 000..8df55fc
--- /dev/null
+++ b/arch/powerpc/lib/devres.c
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2008 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include linux/device.h /* devres_*(), devm_ioremap_release() */
+#include linux/gfp.h
+#include linux/io.h /* ioremap_prot() */
+#include linux/export.h /* EXPORT_SYMBOL() */
+
+/**
+ * devm_ioremap_prot - Managed ioremap_prot()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ * @flags: Page flags
+ *
+ * Managed ioremap_prot(). Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
+size_t size, unsigned long flags)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_prot(offset, size, flags);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_prot);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 05/11] soc/bman: Add self-tester for BMan driver
From: Geoff Thorpe geoff.tho...@freescale.com Add a self test for the DPAA 1.0 Buffer Manager driver. This test ensures that the driver can properly acquire and release buffers using the BMan portal infrastructure. Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com Signed-off-by: Emil Medve emilian.me...@freescale.com Signed-off-by: Roy Pledge roy.ple...@freescale.com --- drivers/soc/fsl/qbman/Kconfig| 26 drivers/soc/fsl/qbman/Makefile |4 + drivers/soc/fsl/qbman/bman_test.c| 56 + drivers/soc/fsl/qbman/bman_test.h| 34 + drivers/soc/fsl/qbman/bman_test_api.c| 184 +++ drivers/soc/fsl/qbman/bman_test_thresh.c | 198 ++ drivers/soc/fsl/qbman/dpaa_sys.h |1 + 7 files changed, 503 insertions(+) create mode 100644 drivers/soc/fsl/qbman/bman_test.c create mode 100644 drivers/soc/fsl/qbman/bman_test.h create mode 100644 drivers/soc/fsl/qbman/bman_test_api.c create mode 100644 drivers/soc/fsl/qbman/bman_test_thresh.c diff --git a/drivers/soc/fsl/qbman/Kconfig b/drivers/soc/fsl/qbman/Kconfig index 1ff52a8..1f2063a 100644 --- a/drivers/soc/fsl/qbman/Kconfig +++ b/drivers/soc/fsl/qbman/Kconfig @@ -28,6 +28,32 @@ config FSL_BMAN_PORTAL help FSL BMan portal driver +config FSL_BMAN_TEST + tristate BMan self-tests + default n + help + Compile self-test code + +config FSL_BMAN_TEST_API + bool High-level API self-test + depends on FSL_BMAN_TEST + default y + help + This requires the presence of cpu-affine portals, and performs + high-level API testing with them (whichever portal(s) are affine + to the cpu(s) the test executes on). + +config FSL_BMAN_TEST_THRESH + bool Thresholds self-test + depends on FSL_BMAN_TEST + default y + help + Multi-threaded (SMP) test of BMan pool depletion. A pool is seeded + before multiple threads (one per cpu) create pool objects to track + depletion state changes. The pool is then drained to empty by a + drainer thread, and the other threads that they observe exactly + the depletion state changes that are expected. + config FSL_QMAN bool QMan device management default n diff --git a/drivers/soc/fsl/qbman/Makefile b/drivers/soc/fsl/qbman/Makefile index 0d96598..04509c3 100644 --- a/drivers/soc/fsl/qbman/Makefile +++ b/drivers/soc/fsl/qbman/Makefile @@ -5,6 +5,10 @@ obj-$(CONFIG_FSL_BMAN) += bman.o obj-$(CONFIG_FSL_BMAN_PORTAL) += bman-portal.o bman-portal-y = bman_portal.o bman_api.o \ bman_utils.o +obj-$(CONFIG_FSL_BMAN_TEST)+= bman-test.o +bman-test-y = bman_test.o +bman-test-$(CONFIG_FSL_BMAN_TEST_API) += bman_test_api.o +bman-test-$(CONFIG_FSL_BMAN_TEST_THRESH) += bman_test_thresh.o obj-$(CONFIG_FSL_QMAN) += qman_api.o qman_utils.o qman_driver.o obj-$(CONFIG_FSL_QMAN_CONFIG) += qman.o qman_portal.o diff --git a/drivers/soc/fsl/qbman/bman_test.c b/drivers/soc/fsl/qbman/bman_test.c new file mode 100644 index 000..9298093 --- /dev/null +++ b/drivers/soc/fsl/qbman/bman_test.c @@ -0,0 +1,56 @@ +/* Copyright 2008 - 2015 Freescale Semiconductor, Inc. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * * Neither the name of Freescale Semiconductor nor the + * names of its contributors may be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * ALTERNATIVELY, this software may be distributed under the terms of the + * GNU General Public License (GPL) as published by the Free Software + * Foundation, either version 2 of that License or (at your option) any + * later version. + * + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE,
Re: [PATCH] bonding: Gratuitous ARP gets dropped when first slave added
From: Venkat Venkatsubra venkat.x.venkatsu...@oracle.com Date: Tue, 11 Aug 2015 07:57:23 -0700 When the first slave is added (such as during bootup) the first gratuitous ARP gets dropped. We don't see this drop during a failover. The packet gets dropped in qdisc (noop_enqueue). The fix is to delay the sending of gratuitous ARPs till the bond dev's carrier is present. It can also be worked around by setting num_grat_arp to more than 1. Signed-off-by: Venkat Venkatsubra venkat.x.venkatsu...@oracle.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 net-next 05/10] openvswitch: Add conntrack action
On Tue, Aug 11, 2015 at 3:59 PM, Joe Stringer joestrin...@nicira.com wrote: Expose the kernel connection tracker via OVS. Userspace components can make use of the ct() action, followed by recirculate, to populate the conntracking state in the OVS flow key, and subsequently match on that state. Example ODP flows allowing traffic from 1-2, only replies from 2-1: in_port=1,tcp,action=ct(commit,zone=1),2 in_port=2,ct_state=-trk,tcp,action=ct(zone=1),recirc(1) recirc_id=1,in_port=2,ct_state=+trk+est-new,tcp,action=1 IP fragments are handled by transparently assembling them as part of the ct action. The maximum received unit (MRU) size is tracked so that refragmentation can occur during output. IP frag handling contributed by Andy Zhou. Signed-off-by: Joe Stringer joestrin...@nicira.com Signed-off-by: Justin Pettit jpet...@nicira.com Signed-off-by: Andy Zhou az...@nicira.com Acked-by: Pravin B Shelar pshe...@nicira.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH] net: ipv4: increase dhcp inter device timeout
From: Mugunthan V N mugunthan...@ti.com Date: Wed, 12 Aug 2015 15:31:43 +0530 When a system has multiple ethernet devices and during DHCP request (for using NFS), the system waits only for HZ/2 which is 500mS before switching to another interface for DHCP. There are some routers (Ex: Trendnet routers) which responds to DHCP request at about 560mS. When the system has only one ethernet interface there is no issue as the timeout is 2S and the dev xid doesn't changes and only retries. But when the system has multiple Ethernet like DRA74x with CPSW in dual EMAC mode, the DHCP response is dropped as the dev xid changes while shifting to the next device. So changing inter device timeout to HZ (which is 1S). Signed-off-by: Mugunthan V N mugunthan...@ti.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On Wed, 2015-08-12 at 21:19 +0200, li...@eikelenboom.it wrote: Hi, On my box running Xen with a 4.2-rc6 kernel i still get this splat in dom0, which crashes the box. (i reported a similar splat before (at rc4) here, http://www.spinics.net/lists/netdev/msg337570.html) Never seen this one on 4.1, so it seems a regression. -- Sander [81133.193439] general protection fault: [#1] SMP [81133.204284] Modules linked in: [81133.214934] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.2.0-rc6-20150811-linus-doflr+ #1 [81133.225632] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [81133.236237] task: 880059b91580 ti: 880059bb4000 task.ti: 880059bb4000 [81133.246808] RIP: e030:[8110fb18] [8110fb18] detach_if_pending+0x18/0x80 [81133.257354] RSP: e02b:880059bb7848 EFLAGS: 00010086 [81133.267749] RAX: 88004eddc7f0 RBX: 88000e20ae08 RCX: dead00200200 [81133.278201] RDX: RSI: 88005f60e600 RDI: 88000e20ae08 [81133.288723] RBP: 880059bb7848 R08: 0001 R09: 0001 [81133.298930] R10: 0003 R11: 88000e20ad68 R12: [81133.308875] R13: 000101735569 R14: 00015f90 R15: 88005f60e600 [81133.318845] FS: 7f28c6f7c800() GS:88005f60() knlGS: [81133.328864] CS: e033 DS: ES: CR0: 8005003b [81133.338693] CR2: 807f6800 CR3: 3d55c000 CR4: 0660 [81133.348462] Stack: [81133.358005] 880059bb7898 8110fe3f 810fc261 0200 [81133.367682] 0003 88000e20ad68 88005854d400 [81133.377064] 00015f90 880059bb78c8 819b5243 [81133.386374] Call Trace: [81133.395596] [8110fe3f] mod_timer_pending+0x3f/0xe0 [81133.404999] [810fc261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [81133.414255] [819b5243] __nf_ct_refresh_acct+0xa3/0xb0 [81133.423137] [819bbe8b] tcp_packet+0xb3b/0x1290 [81133.431894] [810cb8ca] ? __local_bh_enable_ip+0x2a/0x90 [81133.440622] [819b4939] ? __nf_conntrack_find_get+0x129/0x2a0 [81133.449339] [819b682c] nf_conntrack_in+0x29c/0x7c0 [81133.457940] [81a67181] ipv4_conntrack_in+0x21/0x30 [81133.466296] [819aea1c] nf_iterate+0x4c/0x80 [81133.474401] [819aeab4] nf_hook_slow+0x64/0xc0 [81133.482615] [81a211ec] ip_rcv+0x2ec/0x380 [81133.490781] [81a209f0] ? ip_local_deliver_finish+0x130/0x130 [81133.498790] [8197e140] __netif_receive_skb_core+0x2a0/0x970 [81133.506714] [81a56db8] ? inet_gro_receive+0x1c8/0x200 [81133.514609] [81980705] __netif_receive_skb+0x15/0x70 [81133.522333] [8198077e] netif_receive_skb_internal+0x1e/0x80 [81133.529840] [81980f3b] napi_gro_receive+0x6b/0x90 [81133.537173] [81740fb6] rtl8169_poll+0x2e6/0x600 [81133.54] [810fc261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [81133.551566] [81981ad7] net_rx_action+0x1f7/0x300 [81133.558412] [810cb6c3] __do_softirq+0x103/0x210 [81133.565353] [810cb807] run_ksoftirqd+0x37/0x60 [81133.572359] [810e4de0] smpboot_thread_fn+0x130/0x190 [81133.579215] [810e4cb0] ? sort_range+0x20/0x20 [81133.586042] [810e1fae] kthread+0xee/0x110 [81133.592792] [810e1ec0] ? kthread_create_on_node+0x1b0/0x1b0 [81133.599694] [81af92df] ret_from_fork+0x3f/0x70 [81133.606662] [810e1ec0] ? kthread_create_on_node+0x1b0/0x1b0 [81133.613445] Code: 77 28 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 8b 47 08 55 48 89 e5 48 85 c0 74 6a 48 8b 0f 48 85 c9 48 89 08 74 04 48 89 41 08 84 d2 74 08 48 c7 47 08 00 00 00 00 f6 47 2a 10 48 [81133.627196] RIP [8110fb18] detach_if_pending+0x18/0x80 [81133.634036] RSP 880059bb7848 [81133.640817] ---[ end trace eaf596e1fcf6a591 ]--- [81133.647521] Kernel panic - not syncing: Fatal exception in interrupt This looks like the bug fixed in David Miller net tree : http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=2235f2ac75fd2501c251b0b699a9632e80239a6d -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 3/6] geneve: Add support to collect tunnel metadata.
On Tue, Aug 11, 2015 at 10:17 PM, Pravin B Shelar pshe...@nicira.com wrote:
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 5e9bab8..a463383 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
+static struct geneve_dev *geneve_lookup(struct geneve_net *gn,
+ struct iphdr *iph,
+ struct genevehdr *gnvh)
{
- struct genevehdr *gnvh = geneve_hdr(skb);
- struct geneve_dev *dummy, *geneve = NULL;
- struct geneve_net *gn;
- struct iphdr *iph = NULL;
- struct pcpu_sw_netstats *stats;
struct hlist_head *vni_list_head;
- int err = 0;
+ struct geneve_dev *geneve;
__u32 hash;
- iph = ip_hdr(skb); /* Still outer IP header... */
-
- gn = gs-rcv_data;
-
/* Find the device for this VNI */
hash = geneve_net_vni_hash(gnvh-vni);
vni_list_head = gn-vni_list[hash];
- hlist_for_each_entry_rcu(dummy, vni_list_head, hlist) {
- if (!memcmp(gnvh-vni, dummy-vni, sizeof(dummy-vni))
- iph-saddr == dummy-remote.sin_addr.s_addr) {
- geneve = dummy;
- break;
+ hlist_for_each_entry_rcu(geneve, vni_list_head, hlist) {
+ if (!memcmp(gnvh-vni, geneve-vni, sizeof(geneve-vni))
+ iph-saddr == geneve-remote.sin_addr.s_addr) {
+ return geneve;
}
}
+
+ return rcu_dereference(gn-collect_md_tun);
+}
I think this operates differently from VXLAN (and GRE I believe) where
you can't have tunnels based on the VNI overlapping the
collect_md_tun. VXLAN is nice because it can go straight from the
socket to collecting metadata without having to an additional lookup
that doesn't give any additional information and it seems a little
simpler because we don't need to keep track of a flow-based device.
However, at the very least the behavior should be consistent.
+/* geneve receive/decap routine */
+static void geneve_rx(struct geneve_sock *gs, struct sk_buff *skb)
+{
+ struct genevehdr *gnvh = geneve_hdr(skb);
+ struct metadata_dst *tun_dst = NULL;
+ struct geneve_dev *geneve = NULL;
+ struct pcpu_sw_netstats *stats;
+ struct geneve_net *gn;
+ struct iphdr *iph;
+ int err;
+
+ iph = ip_hdr(skb); /* Still outer IP header... */
+ gn = gs-rcv_data;
+ geneve = geneve_lookup(gn, iph, gnvh);
if (!geneve)
goto drop;
- /* Drop packets w/ critical options,
-* since we don't support any...
-*/
- if (gnvh-critical)
- goto drop;
+ if (geneve-collect_md) {
Should this also check ip_tunnel_collect_metadata()? GRE has the same issue.
@@ -103,7 +146,8 @@ static void geneve_rx(struct geneve_sock *gs, struct
sk_buff *skb)
skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
/* Ignore packet loops (and multicast echo) */
- if (ether_addr_equal(eth_hdr(skb)-h_source, geneve-dev-dev_addr))
+ if (!geneve-collect_md
+ ether_addr_equal(eth_hdr(skb)-h_source, geneve-dev-dev_addr))
goto drop;
Why is this different in the collect_md case?
@@ -128,10 +169,18 @@ static void geneve_rx(struct geneve_sock *gs, struct
sk_buff *skb)
stats-rx_bytes += skb-len;
u64_stats_update_end(stats-syncp);
+ if (tun_dst)
+ skb_dst_set(skb, (struct dst_entry *)tun_dst);
I think there is a leak if we allocate the dst but then drop the
packet before we set it on the skb. It seems easier to just set it
earlier.
-static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
+static struct rtable *geneve_get_rt(struct sk_buff *skb,
+ struct net_device *dev,
+ struct flowi4 *fl4,
+ struct ip_tunnel_info *info)
{
[...]
+ if (info) {
+ fl4-daddr = info-key.ipv4_dst;
+ fl4-saddr = info-key.ipv4_src;
+ fl4-flowi4_tos = RT_TOS(info-key.ipv4_tos);
+ fl4-flowi4_mark = skb-mark;
+ fl4-flowi4_proto = IPPROTO_UDP;
+ } else {
+ tos = geneve-tos;
+ if (tos == 1) {
+ const struct iphdr *iip = ip_hdr(skb);
+
+ tos = ip_tunnel_get_dsfield(iip, skb);
+ }
Should the mark and protocol be used in both cases?
+static netdev_tx_t geneve_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct geneve_dev *geneve = netdev_priv(dev);
+ struct geneve_sock *gs = geneve-sock;
+ struct ip_tunnel_info *info = NULL;
+ struct rtable *rt = NULL;
+ const struct iphdr *iip; /* interior IP header */
+ struct flowi4 fl4;
+ __u8
Re: [PATCHv2 0/3] gianfar: filer changes
From: Jakub Kicinski moorr...@wp.pl Date: Wed, 12 Aug 2015 02:41:54 +0200 respinning with examples as requested. Series applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 net-next] documentation: bring vxlan documentation more up-to-date
On 08/12/2015 04:46 PM, David Miller wrote: From: r...@tardy.usa.hp.com (Rick Jones) Date: Wed, 12 Aug 2015 10:23:14 -0700 (PDT) From: Rick Jones rick.jon...@hp.com A few things have changed since the previous version of the vxlan documentation was written, so update it and correct some grammer and such while we are at it. Signed-off-by: Rick Jones rick.jon...@hp.com Applied with grammar misspelling fixed. Thanks. rick -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: fec: Remove unneeded use of IS_ERR_VALUE() macro
From: Fabio Estevam feste...@gmail.com Date: Wed, 12 Aug 2015 12:10:23 -0300 From: Fabio Estevam fabio.este...@freescale.com There is no need to use the IS_ERR_VALUE() macro for checking the return value from pm_runtime_* functions. Just do a simple negative test instead. The semantic patch that makes this change is available in scripts/coccinelle/api/pm_runtime.cocci. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 net-next 04/10] dst: Add __skb_dst_copy() variation
On Tue, Aug 11, 2015 at 3:59 PM, Joe Stringer joestrin...@nicira.com wrote: This variation on skb_dst_copy() doesn't require two skbs. Signed-off-by: Joe Stringer joestrin...@nicira.com Acked-by: Pravin B Shelar pshe...@nicira.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] net: dsa: Do not override PHY interface if already configured
On Wed, Aug 12, 2015 at 02:30:35PM -0700, David Miller wrote: From: Florian Fainelli f.faine...@gmail.com Date: Sat, 8 Aug 2015 12:58:57 -0700 In case we need to divert reads/writes using the slave MII bus, we may have already fetched a valid PHY interface property from Device Tree, and that mode is used by the PHY driver to make configuration decisions. If we could not fetch the phy-mode property, we will assign p-phy_interface to PHY_INTERFACE_MODE_NA, such that we can actually check for that condition as to whether or not we should override the interface value. Fixes: 19334920eaf7 (net: dsa: Set valid phy interface type) Signed-off-by: Florian Fainelli f.faine...@gmail.com --- Hi Guenter, Could you verify this does not break what you were trying to fix with your change? I am fairly confident this will not because for PHYs built-into the switch port we will not be able to fetch a phy-mode property from DT, so we will use PHY_INTERFACE_MODE_NA, but here, we will re-assign them to PHY_INTERFACE_MODE_GMII as before. I was trying to wait for Guenter's testing before applying this, but it's been some time already and it makes no sense to wait any longer. No problem. I am overloaded, and my test system is currently down, so it will take a while. If I find a problem I'll discuss with Florian and send a follow-up patch if needed. Guenter -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 net-next 03/10] ipv6: Export nf_ct_frag6_gather()
On Tue, Aug 11, 2015 at 3:59 PM, Joe Stringer joestrin...@nicira.com wrote: Signed-off-by: Joe Stringer joestrin...@nicira.com Acked-by: Thomas Graf tg...@suug.ch Acked-by: Pravin B Shelar pshe...@nicira.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] net: dsa: Do not override PHY interface if already configured
On 12/08/15 14:30, David Miller wrote: From: Florian Fainelli f.faine...@gmail.com Date: Sat, 8 Aug 2015 12:58:57 -0700 In case we need to divert reads/writes using the slave MII bus, we may have already fetched a valid PHY interface property from Device Tree, and that mode is used by the PHY driver to make configuration decisions. If we could not fetch the phy-mode property, we will assign p-phy_interface to PHY_INTERFACE_MODE_NA, such that we can actually check for that condition as to whether or not we should override the interface value. Fixes: 19334920eaf7 (net: dsa: Set valid phy interface type) Signed-off-by: Florian Fainelli f.faine...@gmail.com --- Hi Guenter, Could you verify this does not break what you were trying to fix with your change? I am fairly confident this will not because for PHYs built-into the switch port we will not be able to fetch a phy-mode property from DT, so we will use PHY_INTERFACE_MODE_NA, but here, we will re-assign them to PHY_INTERFACE_MODE_GMII as before. I was trying to wait for Guenter's testing before applying this, but it's been some time already and it makes no sense to wait any longer. I should be able to verify this myself in the future since I just setup a Marvell/DSA switch device here for testing. Applied to 'net', thanks Florian. Could you also schedule this for -stable, at least 4.1 is affected by this change, thank you! -- Florian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 net-next 01/10] openvswitch: Serialize acts with original netlink len
On Tue, Aug 11, 2015 at 3:59 PM, Joe Stringer joestrin...@nicira.com wrote: Previously, we used the kernel-internal netlink actions length to calculate the size of messages to serialize back to userspace. However,the sw_flow_actions may not be formatted exactly the same as the actions on the wire, so store the original actions length when de-serializing and re-use the original length when serializing. Signed-off-by: Joe Stringer joestrin...@nicira.com Acked-by: Pravin B Shelar pshe...@nicira.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 net-next 02/10] openvswitch: Move MASKED* macros to datapath.h
On Tue, Aug 11, 2015 at 3:59 PM, Joe Stringer joestrin...@nicira.com wrote: This will allow the ovs-conntrack code to reuse these macros. Signed-off-by: Joe Stringer joestrin...@nicira.com Acked-by: Thomas Graf tg...@suug.ch Acked-by: Pravin B Shelar pshe...@nicira.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] net: dsa: Do not override PHY interface if already configured
From: Florian Fainelli f.faine...@gmail.com Date: Wed, 12 Aug 2015 14:34:12 -0700 On 12/08/15 14:30, David Miller wrote: Applied to 'net', thanks Florian. Could you also schedule this for -stable, at least 4.1 is affected by this change, thank you! Done, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: atl1c: add BQL support
From: Ron Angeles ronange...@gmail.com Date: Tue, 11 Aug 2015 23:01:20 -0700 This BQL implementation is mostly derived from its related driver, alx. Tested on AR8131 (rev c0) [1969:1063]. Saturated a 100mbps link with 5 concurrent runs of netperf. Ping latency dropped from 14ms to 3ms. Signed-off-by: Ron Angeles ronange...@gmail.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IGMP: Inhibit reports for local multicast groups
From: Philip Downey pdow...@brocade.com Date: Wed, 12 Aug 2015 17:13:53 +0100 IGMP reports are generated for link local multicast groups (224.0.0.1 - 224.0.0.255) used by the routing protocols such as RIP, OSPF etc. In general routers do not generate reports for local multicast groups. IGMP reports for local multicast groups can now be inhibited by means of a system control variable (setting the value to zero). To retain backwards compatibility the previous behaviour is retained by default on system boot. Signed-off-by: Philip Downey pdow...@brocade.com I'm always hesitent to apply patches like this. I can't even understand from your explanation: 1) what about local reporting behavior is so bad 2) why you want to inhibit them at all For example, this: In general routers do not generate reports for local multicast groups. Doesn't tell me anything. You need to go into more detail about this, and explain the situation sufficiently. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 net-next] documentation: bring vxlan documentation more up-to-date
From: r...@tardy.usa.hp.com (Rick Jones) Date: Wed, 12 Aug 2015 10:23:14 -0700 (PDT) From: Rick Jones rick.jon...@hp.com A few things have changed since the previous version of the vxlan documentation was written, so update it and correct some grammer and such while we are at it. Signed-off-by: Rick Jones rick.jon...@hp.com Applied with grammar misspelling fixed. Thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On 2015-08-12 22:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 21:19 +0200, li...@eikelenboom.it wrote: Hi, On my box running Xen with a 4.2-rc6 kernel i still get this splat in dom0, which crashes the box. (i reported a similar splat before (at rc4) here, http://www.spinics.net/lists/netdev/msg337570.html) Never seen this one on 4.1, so it seems a regression. -- Sander [81133.193439] general protection fault: [#1] SMP [81133.204284] Modules linked in: [81133.214934] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.2.0-rc6-20150811-linus-doflr+ #1 [81133.225632] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [81133.236237] task: 880059b91580 ti: 880059bb4000 task.ti: 880059bb4000 [81133.246808] RIP: e030:[8110fb18] [8110fb18] detach_if_pending+0x18/0x80 [81133.257354] RSP: e02b:880059bb7848 EFLAGS: 00010086 [81133.267749] RAX: 88004eddc7f0 RBX: 88000e20ae08 RCX: dead00200200 [81133.278201] RDX: RSI: 88005f60e600 RDI: 88000e20ae08 [81133.288723] RBP: 880059bb7848 R08: 0001 R09: 0001 [81133.298930] R10: 0003 R11: 88000e20ad68 R12: [81133.308875] R13: 000101735569 R14: 00015f90 R15: 88005f60e600 [81133.318845] FS: 7f28c6f7c800() GS:88005f60() knlGS: [81133.328864] CS: e033 DS: ES: CR0: 8005003b [81133.338693] CR2: 807f6800 CR3: 3d55c000 CR4: 0660 [81133.348462] Stack: [81133.358005] 880059bb7898 8110fe3f 810fc261 0200 [81133.367682] 0003 88000e20ad68 88005854d400 [81133.377064] 00015f90 880059bb78c8 819b5243 [81133.386374] Call Trace: [81133.395596] [8110fe3f] mod_timer_pending+0x3f/0xe0 [81133.404999] [810fc261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [81133.414255] [819b5243] __nf_ct_refresh_acct+0xa3/0xb0 [81133.423137] [819bbe8b] tcp_packet+0xb3b/0x1290 [81133.431894] [810cb8ca] ? __local_bh_enable_ip+0x2a/0x90 [81133.440622] [819b4939] ? __nf_conntrack_find_get+0x129/0x2a0 [81133.449339] [819b682c] nf_conntrack_in+0x29c/0x7c0 [81133.457940] [81a67181] ipv4_conntrack_in+0x21/0x30 [81133.466296] [819aea1c] nf_iterate+0x4c/0x80 [81133.474401] [819aeab4] nf_hook_slow+0x64/0xc0 [81133.482615] [81a211ec] ip_rcv+0x2ec/0x380 [81133.490781] [81a209f0] ? ip_local_deliver_finish+0x130/0x130 [81133.498790] [8197e140] __netif_receive_skb_core+0x2a0/0x970 [81133.506714] [81a56db8] ? inet_gro_receive+0x1c8/0x200 [81133.514609] [81980705] __netif_receive_skb+0x15/0x70 [81133.522333] [8198077e] netif_receive_skb_internal+0x1e/0x80 [81133.529840] [81980f3b] napi_gro_receive+0x6b/0x90 [81133.537173] [81740fb6] rtl8169_poll+0x2e6/0x600 [81133.54] [810fc261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [81133.551566] [81981ad7] net_rx_action+0x1f7/0x300 [81133.558412] [810cb6c3] __do_softirq+0x103/0x210 [81133.565353] [810cb807] run_ksoftirqd+0x37/0x60 [81133.572359] [810e4de0] smpboot_thread_fn+0x130/0x190 [81133.579215] [810e4cb0] ? sort_range+0x20/0x20 [81133.586042] [810e1fae] kthread+0xee/0x110 [81133.592792] [810e1ec0] ? kthread_create_on_node+0x1b0/0x1b0 [81133.599694] [81af92df] ret_from_fork+0x3f/0x70 [81133.606662] [810e1ec0] ? kthread_create_on_node+0x1b0/0x1b0 [81133.613445] Code: 77 28 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 8b 47 08 55 48 89 e5 48 85 c0 74 6a 48 8b 0f 48 85 c9 48 89 08 74 04 48 89 41 08 84 d2 74 08 48 c7 47 08 00 00 00 00 f6 47 2a 10 48 [81133.627196] RIP [8110fb18] detach_if_pending+0x18/0x80 [81133.634036] RSP 880059bb7848 [81133.640817] ---[ end trace eaf596e1fcf6a591 ]--- [81133.647521] Kernel panic - not syncing: Fatal exception in interrupt This looks like the bug fixed in David Miller net tree : http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=2235f2ac75fd2501c251b0b699a9632e80239a6d Will pull the net-tree in and re-test. But since it only seems to crash after a day or two, that will take some time. Thanks, Sander -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/2] hv_netvsc: Set vRSS with num_chn in RNDIS filter
From: Andrew Schwartzmeyer andsc...@microsoft.com Date: Tue, 11 Aug 2015 17:14:31 -0700 Uses device_info-num_chn to pass user provided number of vRSS queues (from ethtool --set-channels) to rndis_filter_device_add. If nonzero and less than the maximum, set net_device-num_chn to the given value; else default to prior algorithm. Always initialize struct device_info to 0, otherwise not all its fields are guaranteed to be 0, which is necessary when checking if num_chn has been purposefully set. Signed-off-by: Andrew Schwartzmeyer andsc...@microsoft.com Applied. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/2] hv_netvsc: Implement set_channels ethtool op
From: Andrew Schwartzmeyer andsc...@microsoft.com Date: Tue, 11 Aug 2015 17:14:32 -0700 This enables the use of ethtool --set-channels devname combined N to change the number of vRSS queues. Separate rx, tx, and other parameters are not supported. The maximum is rsscap.num_recv_que. It passes the given value to rndis_filter_device_add through the device_info-num_chn field. If the procedure fails, it attempts to recover to the prior state. If the recovery fails, it logs an error and aborts. Current num_chn is saved and restored when changing the MTU. Signed-off-by: Andrew Schwartzmeyer andsc...@microsoft.com Applied. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 5/6] geneve: Consolidate Geneve functionality in single module.
On Tue, Aug 11, 2015 at 10:17 PM, Pravin B Shelar pshe...@nicira.com wrote: diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index c18f9e6..0002ab7 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -181,7 +181,7 @@ config VXLAN config GENEVE tristate Generic Network Virtualization Encapsulation netdev - depends on INET GENEVE_CORE + depends on INET select NET_IP_TUNNEL I think this now needs to select NET_UDP_TUNNEL instead of NET_IP_TUNNEL. I would also drop netdev from the end of the title since there is no longer a split between the netdev and library. The farther I go in the series, the more that I hope that we can avoid the use of collect_md_tun. It really seems to add a lot of special cases. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 6/6] geneve: Remove duplicate dev list
On Tue, Aug 11, 2015 at 10:17 PM, Pravin B Shelar pshe...@nicira.com wrote:
static void __net_exit geneve_exit_net(struct net *net)
{
struct geneve_net *gn = net_generic(net, geneve_net_id);
- struct geneve_dev *geneve, *next;
+ struct hlist_head *vni_list_head;
+ struct hlist_node *next;
struct net_device *dev, *aux;
+ struct geneve_dev *geneve;
I think these newly added variables could be inside the VNI_HASH_SIZE loop.
Reviewed-by: Jesse Gross je...@nicira.com
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Add a matching set of device_ functions for determining mac/phy
OF has some helper functions for parsing MAC and PHY settings.
In cases where the platform is providing this information rather
than the device itself, there needs to be similar functions for ACPI.
These functions are slightly modified versions of the ones in
of_net which can use information provided via DT or ACPI.
Signed-off-by: Jeremy Linton jeremy.lin...@arm.com
---
drivers/base/property.c | 73
include/linux/property.h | 4 +++
2 files changed, 77 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index f3f6d16..2e8cd14 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -16,6 +16,8 @@
#include linux/of.h
#include linux/of_address.h
#include linux/property.h
+#include linux/etherdevice.h
+#include linux/phy.h
/**
* device_add_property_set - Add a collection of properties to a device object.
@@ -533,3 +535,74 @@ bool device_dma_is_coherent(struct device *dev)
return coherent;
}
EXPORT_SYMBOL_GPL(device_dma_is_coherent);
+
+/**
+ * device_get_phy_mode - Get phy mode for given device_node
+ * @dev: Pointer to the given device
+ *
+ * The function gets phy interface string from property 'phy-mode' or
+ * 'phy-connection-type', and return its index in phy_modes table, or errno in
+ * error case.
+ */
+int device_get_phy_mode(struct device *dev)
+{
+ const char *pm;
+ int err, i;
+
+ err = device_property_read_string(dev, phy-mode, pm);
+ if (err 0)
+ err = device_property_read_string(dev,
+ phy-connection-type, pm);
+ if (err 0)
+ return err;
+
+ for (i = 0; i PHY_INTERFACE_MODE_MAX; i++)
+ if (!strcasecmp(pm, phy_modes(i)))
+ return i;
+
+ return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(device_get_phy_mode);
+
+static void *device_get_mac_addr(struct device *dev,
+const char *name, char *addr,
+int alen)
+{
+ int ret = device_property_read_u8_array(dev, name, addr, alen);
+
+ if (ret == 0 is_valid_ether_addr(addr))
+ return addr;
+ return NULL;
+}
+
+/**
+ * Search the device tree for the best MAC address to use. 'mac-address' is
+ * checked first, because that is supposed to contain to most recent MAC
+ * address. If that isn't set, then 'local-mac-address' is checked next,
+ * because that is the default address. If that isn't set, then the obsolete
+ * 'address' is checked, just in case we're using an old device tree.
+ *
+ * Note that the 'address' property is supposed to contain a virtual address of
+ * the register set, but some DTS files have redefined that property to be the
+ * MAC address.
+ *
+ * All-zero MAC addresses are rejected, because those could be properties that
+ * exist in the device tree, but were not set by U-Boot. For example, the
+ * DTS could define 'mac-address' and 'local-mac-address', with zero MAC
+ * addresses. Some older U-Boots only initialized 'local-mac-address'. In
+ * this case, the real MAC is in 'local-mac-address', and 'mac-address' exists
+ * but is all zeros.
+*/
+void *device_get_mac_address(struct device *dev, char *addr, int alen)
+{
+ addr = device_get_mac_addr(dev, mac-address, addr, alen);
+ if (addr)
+ return addr;
+
+ addr = device_get_mac_addr(dev, local-mac-address, addr, alen);
+ if (addr)
+ return addr;
+
+ return device_get_mac_addr(dev, address, addr, alen);
+}
+EXPORT_SYMBOL(device_get_mac_address);
diff --git a/include/linux/property.h b/include/linux/property.h
index 76ebde9..a59c6ee 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -166,4 +166,8 @@ void device_add_property_set(struct device *dev, struct
property_set *pset);
bool device_dma_is_coherent(struct device *dev);
+int device_get_phy_mode(struct device *dev);
+
+void *device_get_mac_address(struct device *dev, char *addr, int alen);
+
#endif /* _LINUX_PROPERTY_H_ */
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote: Thanks for the reminder, but luckily i was aware of that, seen enough of your replies asking for patches to be resubmitted against the other tree ;) Kernel with patch is currently running so fingers crossed. Thanks for testing. I am definitely interested knowing your results. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 net-next 06/10] openvswitch: Allow matching on conntrack mark
On Tue, Aug 11, 2015 at 3:59 PM, Joe Stringer joestrin...@nicira.com wrote:
From: Justin Pettit jpet...@nicira.com
Allow matching and setting the conntrack mark field. As with conntrack
state and zone, these are populated by executing the ct() action. Unlike
these, the ct_mark is also a writable field. The set_field() action may
be used to modify the mark, which will take effect on the most recent
conntrack entry.
E.g.: actions:ct(zone=0),ct(zone=1),set_field(1-ct_mark)
This will perform conntrack lookup in zone 0, then lookup in zone 1,
then modify the mark for the entry in zone 1. The mark for the entry in
zone 0 is unchanged. The conntrack entry itself must be committed using
the commit flag in the conntrack action flags for this change to persist.
Signed-off-by: Justin Pettit jpet...@nicira.com
Signed-off-by: Joe Stringer joestrin...@nicira.com
---
...
+int ovs_ct_set_mark(struct sk_buff *skb, struct sw_flow_key *key,
+ u32 ct_mark, u32 mask)
+{
+#ifdef CONFIG_NF_CONNTRACK_MARK
+ enum ip_conntrack_info ctinfo;
+ struct nf_conn *ct;
+ u32 new_mark;
+
+ /* This must happen directly after lookup/commit. */
+ ct = nf_ct_get(skb, ctinfo);
+ if (!ct)
+ return -EINVAL;
+
+ new_mark = ct_mark | (ct-mark ~(mask));
+ if (ct-mark != new_mark) {
+ ct-mark = new_mark;
+ nf_conntrack_event_cache(IPCT_MARK, ct);
+ key-ct.mark = ct_mark;
+ }
+
Is it fine to set just set mark and not initialize reset of key-ct members?
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 5/6] geneve: Consolidate Geneve functionality in single module.
On Wed, Aug 12, 2015 at 2:55 PM, Jesse Gross je...@nicira.com wrote: On Tue, Aug 11, 2015 at 10:17 PM, Pravin B Shelar pshe...@nicira.com wrote: diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index c18f9e6..0002ab7 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -181,7 +181,7 @@ config VXLAN config GENEVE tristate Generic Network Virtualization Encapsulation netdev - depends on INET GENEVE_CORE + depends on INET select NET_IP_TUNNEL I think this now needs to select NET_UDP_TUNNEL instead of NET_IP_TUNNEL. ok. I would also drop netdev from the end of the title since there is no longer a split between the netdev and library. ok. The farther I go in the series, the more that I hope that we can avoid the use of collect_md_tun. It really seems to add a lot of special cases. Use of collect_md_tun allows us to avoid hash table lookup. thats why I did it. Anyways we need a flag or pointer in geneve-sock structure to locate tunnel metadata. I dont see how is it simple if collect_md_tun is replaced with a flag. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] genet:Fix error handling in the function bcmgenet_fini_gma
Le 08/12/15 19:27, Nicholas Krause a écrit :
This fixes error handing in the function bcmgenet_fini_gma to
properly check if its internal call to the function
bcm_genet_teardown has failed by returning a error code and if
so return immediately to this function's caller with a return
statement as this function call can no longer continue without
issues arising from the call to the function bcm_genet_teardown.
NACK, this is not a good idea, there are specific reasons why the DMA
teardown can fail, e.g: when no bandwidth has been allocated at the
memory controller level, and we still want to keep tearing down and
freeing up resources while we reconfigure the controller one way or the
other, this can happen while debugging a system, and this is specific to
how GENET is integrated on Broadcom BCM7xxx SoCs.
Also, if you ever need to submit more patches, please look at the git
log history and use consistent prefixes, for this driver this would be
net: bcmgenet: blah blah
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 64c1e9d..50e6183 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2180,7 +2180,8 @@ static void bcmgenet_fini_dma(struct bcmgenet_priv
*priv)
bcmgenet_fini_tx_napi(priv);
/* disable DMA */
- bcmgenet_dma_teardown(priv);
+ if (bcmgenet_dma_teardown(priv))
+ return;
for (i = 0; i priv-num_tx_bds; i++) {
if (priv-tx_cbs[i].skb != NULL) {
--
Florian
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] cxgb4: Add MPS tracing support
Handle TRACE_PKT, stack can sniff them on the first port
Add debubfs enrty to configure tracing for offload traffic like iWARP
iSCSI for debugging purpose.
Signed-off-by: Hariprasad Shenai haripra...@chelsio.com
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 8 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 298 +
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 113
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 56
4 files changed, 475 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 58de444..3c99454 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -768,6 +768,10 @@ struct adapter {
struct dentry *debugfs_root;
u32 use_bd; /* Use SGE Back Door intfc for reading SGE Contexts */
+ u32 trace_rss; /* 1 implies that different RSS flit per filter is
+* used per filter else if 0 default RSS flit is
+* used for all 4 filters.
+*/
spinlock_t stats_lock;
spinlock_t win0_lock cacheline_aligned_in_smp;
@@ -1441,6 +1445,10 @@ int t4_sge_ctxt_flush(struct adapter *adap, unsigned int
mbox);
int t4_handle_fw_rpl(struct adapter *adap, const __be64 *rpl);
void t4_db_full(struct adapter *adapter);
void t4_db_dropped(struct adapter *adapter);
+int t4_set_trace_filter(struct adapter *adapter, const struct trace_params *tp,
+ int filter_index, int enable);
+void t4_get_trace_filter(struct adapter *adapter, struct trace_params *tp,
+int filter_index, int *enabled);
int t4_fwaddrspace_write(struct adapter *adap, unsigned int mbox,
u32 addr, u32 val);
void t4_sge_decode_idma_state(struct adapter *adapter, int state);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index ce075d1..c6b9de1 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -1201,6 +1201,298 @@ static const struct file_operations mbox_debugfs_fops =
{
.write = mbox_write
};
+static int mps_trc_show(struct seq_file *seq, void *v)
+{
+ int enabled, i;
+ struct trace_params tp;
+ unsigned int trcidx = (uintptr_t)seq-private 3;
+ struct adapter *adap = seq-private - trcidx;
+
+ t4_get_trace_filter(adap, tp, trcidx, enabled);
+ if (!enabled) {
+ seq_puts(seq, tracer is disabled\n);
+ return 0;
+ }
+
+ if (tp.skip_ofst * 8 = TRACE_LEN) {
+ dev_err(adap-pdev_dev, illegal trace pattern skip offset\n);
+ return -EINVAL;
+ }
+ if (tp.port 8) {
+ i = adap-chan_map[tp.port 3];
+ if (i = MAX_NPORTS) {
+ dev_err(adap-pdev_dev, tracer %u is assigned
+ to non-existing port\n, trcidx);
+ return -EINVAL;
+ }
+ seq_printf(seq, tracer is capturing %s %s, ,
+ adap-port[i]-name, tp.port 4 ? Rx : Tx);
+ } else
+ seq_printf(seq, tracer is capturing loopback %d, ,
+ tp.port - 8);
+ seq_printf(seq, snap length: %u, min length: %u\n, tp.snap_len,
+ tp.min_len);
+ seq_printf(seq, packets captured %smatch filter\n,
+ tp.invert ? do not : );
+
+ if (tp.skip_ofst) {
+ seq_puts(seq, filter pattern: );
+ for (i = 0; i tp.skip_ofst * 2; i += 2)
+ seq_printf(seq, %08x%08x, tp.data[i], tp.data[i + 1]);
+ seq_putc(seq, '/');
+ for (i = 0; i tp.skip_ofst * 2; i += 2)
+ seq_printf(seq, %08x%08x, tp.mask[i], tp.mask[i + 1]);
+ seq_puts(seq, @0\n);
+ }
+
+ seq_puts(seq, filter pattern: );
+ for (i = tp.skip_ofst * 2; i TRACE_LEN / 4; i += 2)
+ seq_printf(seq, %08x%08x, tp.data[i], tp.data[i + 1]);
+ seq_putc(seq, '/');
+ for (i = tp.skip_ofst * 2; i TRACE_LEN / 4; i += 2)
+ seq_printf(seq, %08x%08x, tp.mask[i], tp.mask[i + 1]);
+ seq_printf(seq, @%u\n, (tp.skip_ofst + tp.skip_len) * 8);
+ return 0;
+}
+
+static int mps_trc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mps_trc_show, inode-i_private);
+}
+
+static unsigned int xdigit2int(unsigned char c)
+{
+ return isdigit(c) ? c - '0' : tolower(c) - 'a' + 10;
+}
+
+#define TRC_PORT_NONE 0xff
+#define TRC_RSS_ENABLE 0x33
+#define TRC_RSS_DISABLE 0x13
+
+/* Set an MPS trace filter. Syntax is:
+ *
+ * disable
+ *
+ * to disable tracing, or
+ *
+ * interface qid=qid no [snaplen=val] [minlen=val] [not] [pattern]...
+ *
+
Re: [PATCH net-next 0/3] mpls: multipath support
On 8/12/15, 10:30 AM, Robert Shearman wrote: On 11/08/15 22:45, Roopa Prabhu wrote: From: Roopa Prabhu ro...@cumulusnetworks.com This patch series adds multipath support to mpls routes. resembles ipv4 multipath support. The multipath route nexthop selection algorithm is the same code as in ipv4 fib code. I understand that the multipath algorithm in ipv4 is undergoing some changes and will move mpls to similar algo if applicable once those get merged. Is it necessary for the mpls patch selection algorithm to closely resemble the ipv4 one? No, It is not necessary. I picked that because it was already there. And I see that ipv4 is also getting some new multipath algorithms (https://marc.info/?l=linux-apim=143457208315573w=2). I wanted to move to the new RT_MP infra if that becomes applicable in the future. A flow based algorithm would be much better for traffic that is sensitive to re-ordering (e.g TCP, L2VPN) and IMHO we should do this from the start for MPLS. I've also been looking at implementing this functionality. I've got a set of patches for this that I can send if you'd like. Definitely. But, It seems like you can also submit incremental patches to mine. You can replace the current algo with a hash based with your patches. If that does not work for you and if you want me to merge with this series that works too. Thanks!, Roopa -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/3] mpls: consistently use u8 to store number of labels
On 8/12/15, 12:17 PM, Robert Shearman wrote:
On 11/08/15 22:45, Roopa Prabhu wrote:
From: Roopa Prabhu ro...@cumulusnetworks.com
change all types representing number of labels to u8
to be consistent.
This also changes labels to u8 in the light weight
mpls_tunnel_encap structure. This is because the
light weight mpls iptunnel code shares some of the label
encoding functions like nla_get/put_labels with the af_mpls
code.
Signed-off-by: Roopa Prabhu ro...@cumulusnetworks.com
---
...
@@ -243,11 +243,11 @@ static const struct nla_policy
rtm_mpls_policy[RTA_MAX+1] = {
struct mpls_route_config {
u32rc_protocol;
u32rc_ifindex;
-u16rc_via_table;
-u16rc_via_alen;
+u8rc_via_table;
+u8rc_via_alen;
IMHO, it would be better to make rc_via_alen an int to avoid overflow
which could cause false negatives in this check on the RTA_VIA attribute:
if (cfg-rc_via_alen MAX_VIA_ALEN)
goto errout;
ok,
...
u8rc_via[MAX_VIA_ALEN];
+u8rc_output_labels;
u32rc_label;
-u32rc_output_labels;
u32rc_output_label[MAX_NEW_LABELS];
u32rc_nlflags;
enum mpls_payload_typerc_payload_type;
@@ -751,7 +751,7 @@ int nla_put_labels(struct sk_buff *skb, int
attrtype,
EXPORT_SYMBOL_GPL(nla_put_labels);
int nla_get_labels(const struct nlattr *nla,
- u32 max_labels, u32 *labels, u32 label[])
+ u32 max_labels, u8 *labels, u32 label[])
How about making max_labels a u8? That would make it even more
consistent and avoids any problem of overflow in the number of labels.
yes, I did want to change max_labels to u8. will do in v2.
thanks,
Roopa
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 3/3] mpls: add multipath route support
On 8/12/15, 12:18 PM, Robert Shearman wrote:
On 11/08/15 22:45, Roopa Prabhu wrote:
From: Roopa Prabhu ro...@cumulusnetworks.com
Adds support for MPLS multipath routes.
supports parse/fill of RTA_MULTIPATH netlink attribute
for multipath routes similar to ipv4 fib. Mostly based on
multipath handling in ipv4 fib code.
The multipath route nexthop selection algorithm is the same
code as in ipv4 fib.
This patch also adds new functions to parse multipath attributes
from route config into mpls_nhlfe.
note that it also simplifies mpls_route_update. Removes handling
route updates based on dev argument. The reason for
doing that is, the function was not being used for route updates
based on dev and if we do need to support route updates based
on dev in the future it will have to be done differently.
Signed-off-by: Roopa Prabhu ro...@cumulusnetworks.com
---
net/mpls/af_mpls.c | 378
+--
net/mpls/internal.h | 19 +++
2 files changed, 323 insertions(+), 74 deletions(-)
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index eb089ef..de5ae29 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -19,10 +19,12 @@
#include net/ipv6.h
#include net/addrconf.h
#endif
+#include net/nexthop.h
#include internal.h
static int zero = 0;
static int label_limit = (1 20) - 1;
+static DEFINE_SPINLOCK(mpls_multipath_lock);
static void rtmsg_lfib(int event, u32 label, struct mpls_route *rt,
struct nlmsghdr *nlh, struct net *net, u32 portid,
@@ -51,10 +53,10 @@ bool mpls_output_possible(const struct net_device
*dev)
}
EXPORT_SYMBOL_GPL(mpls_output_possible);
-static unsigned int mpls_rt_header_size(const struct mpls_route *rt)
+static unsigned int mpls_nhlfe_header_size(const struct mpls_nhlfe
*nhlfe)
{
/* The size of the layer 2.5 labels to be added for this route */
-return rt-rt_nh-nh_labels * sizeof(struct mpls_shim_hdr);
+return nhlfe-nh_labels * sizeof(struct mpls_shim_hdr);
}
unsigned int mpls_dev_mtu(const struct net_device *dev)
@@ -76,7 +78,52 @@ bool mpls_pkt_too_big(const struct sk_buff *skb,
unsigned int mtu)
}
EXPORT_SYMBOL_GPL(mpls_pkt_too_big);
-static bool mpls_egress(struct mpls_route *rt, struct sk_buff *skb,
+/* This is a cut/copy/modify from fib_select_multipath */
+static void mpls_select_multipath(struct mpls_route *rt, int *nhidx)
+{
+int w;
+
+spin_lock_bh(mpls_multipath_lock);
+if (rt-rt_power = 0) {
+int power = 0;
+
+change_nexthops(rt) {
+power += nhlfe-nh_weight;
+nhlfe-nh_power = nhlfe-nh_weight;
+} endfor_nexthops(rt);
+rt-rt_power = power;
+if (power = 0) {
+spin_unlock_bh(mpls_multipath_lock);
+/* Race condition: route has just become dead. */
+*nhidx = 0;
+return;
+}
+}
+
+/* w should be random number [0..rt-rt_power-1],
+ * it is pretty bad approximation.
+ */
+w = jiffies % rt-rt_power;
+
+change_nexthops(rt) {
+if (nhlfe-nh_power) {
+w -= nhlfe-nh_power;
+if (w = 0) {
+nhlfe-nh_power--;
+rt-rt_power--;
+*nhidx = nhsel;
+spin_unlock_bh(mpls_multipath_lock);
+return;
+}
+}
+} endfor_nexthops(rt);
+
+/* Race condition: route has just become dead. */
+*nhidx = 0;
+spin_unlock_bh(mpls_multipath_lock);
+}
If we were to do flow-based hashing then this would also avoid the
locking required here.
ok,
+
+static bool mpls_egress(struct mpls_nhlfe *nhlfe, struct sk_buff *skb,
struct mpls_entry_decoded dec)
{
enum mpls_payload_type payload_type;
@@ -95,7 +142,7 @@ static bool mpls_egress(struct mpls_route *rt,
struct sk_buff *skb,
if (!pskb_may_pull(skb, 12))
return false;
-payload_type = rt-rt_nh-nh_payload_type;
+payload_type = nhlfe-nh_payload_type;
if (payload_type == MPT_UNSPEC)
payload_type = ip_hdr(skb)-version;
@@ -130,6 +177,7 @@ static int mpls_forward(struct sk_buff *skb,
struct net_device *dev,
struct net *net = dev_net(dev);
struct mpls_shim_hdr *hdr;
struct mpls_route *rt;
+struct mpls_nhlfe *nhlfe;
struct mpls_entry_decoded dec;
struct net_device *out_dev;
struct mpls_dev *mdev;
@@ -137,6 +185,7 @@ static int mpls_forward(struct sk_buff *skb,
struct net_device *dev,
unsigned int new_header_size;
unsigned int mtu;
int err;
+int nhidx;
/* Careful this entire function runs inside of an rcu critical
section */
@@ -167,9 +216,12 @@ static int mpls_forward(struct sk_buff *skb,
struct net_device *dev,
if (!rt)
goto drop;
+mpls_select_multipath(rt, nhidx);
+nhlfe = rt-rt_nh[nhidx];
How about just returning the nexthop from mpls_select_multipath rather
than going via nhidx?
sure,
+
Re: kernel warning in tcp_fragment
On Mon, Aug 10, 2015 at 02:35:37PM -0400, Neal Cardwell wrote: On Mon, Aug 10, 2015 at 2:10 PM, Jovi Zhangwei j...@cloudflare.com wrote: Ping? We saw a lot of this warnings in our production system. It would be great appreciate if someone can give us the fix on this warnings. :) What is your net.ipv4.tcp_mtu_probing setting? If 1, have you tried setting it to 0? Hi Jovi, If setting net.ipv4.tcp_mtu_probing=0 helps, can you give the patch we posted earlier a try: https://patchwork.ozlabs.org/patch/481609/ It is the same patch that I pointed out earlier. You can click on the download link. We are currently using a similar patch while keeping net.ipv4.tcp_mtu_probing=1. Thanks, --Martin -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-next PATCH 1/3] net: make default tx_queue_len configurable
On Tue, Aug 11, 2015 at 06:13:49PM -0700, Alexei Starovoitov wrote: On Tue, Aug 11, 2015 at 06:23:35PM +0200, Phil Sutter wrote: I have an unfinished solution in the oven, but being kept busy with other things for now. The action plan is as follows: 1) Introduce IFF_NO_QUEUE net_device-priv_flag. 2) Have attach_default_qdiscs() and attach_one_default_qdisc() treat IFF_NO_QUEUE as alternative to tx_queue_len == 0. 3) Add warning to register_netdevice() if tx_queue_len == 0. 4) Change virtual NIC drivers to set IFF_NO_QUEUE and leave tx_queue_len alone. 5) Eventually drop all special handling for tx_queue_len == 0. I am currently somewhere in 2) and need to implement 4) for veth as PoC to check if 2) suffices in all situations we want. Not sure if 3) is desireable at all or if there are valid cases for a literally zero length TX queue length. sounds like you want to change default qdisc from pfifo_fast to noqueue for veth, right? In general 'changing the default' may be an acceptable thing, but then it needs to strongly justified. How much performance does it bring? Also why introduce the flag? Why not just add 'tx_queue_len = 0;' to veth_setup() like the whole bunch of devices do? A quick test on my local VM with veth and netperf (netserver and veth peer in different netns) I see an increase of about 5% of throughput when using noqueue instead of the default pfifo_fast. Cheers, Phil -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH iproute2] ip: replace exit with return
From: netdev-ow...@vger.kernel.org
Sent: 11 August 2015 10:40
In our manual, we have this description of 'EXIT STATUS':
Exit status is 0 if command was successful, and 1 if there is a syntax
error.
But we exit in command functions with code -1 when there is a syntax
error.
It's better to use return.
Eh?
Using exit() makes it much more obvious that the program is going to exit.
I've not looked at the call site (I'm not entirely sure where this code is
in the
source tree), but main() shouldn't return -1 any more than exit(-1) is
invalid.
The domain for both is 0..127.
So the code should be using a valid value.
1. Using exit(-1) will make program exit with -1.
With return -1, the do_cmd() function will make sure 1 is returned.
do_cmd()
{
return -(c-func(argc-1, argv+1));
}
2. Replace with return will confirm with manual description like I said in
last mail.
BRs,
Zhang
...
diff --git a/ip/ipaddress.c b/ip/ipaddress.c index b7b4e3e..6d29a69
100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1879,5 +1879,5 @@ int do_ipaddr(int argc, char **argv)
if (matches(*argv, help) == 0)
usage();
fprintf(stderr, Command \%s\ is unknown, try \ip addr
help\.\n,
*argv);
- exit(-1);
+ return -1;
}
...
David
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] net: atl1c: add BQL support
On 08/12/2015 03:40 PM, Francois Romieu wrote: Ron Angeles ronange...@gmail.com : This BQL implementation is mostly derived from its related driver, alx. Tested on AR8131 (rev c0) [1969:1063]. Saturated a 100mbps link with 5 concurrent runs of netperf. Ping latency dropped from 14ms to 3ms. Could you use some time to test the attached experimental stuff as well ? I only have one of these NICs and it is running on something critical throughout the weekdays. I can try running these when I have time on a weekend. Is there any particular way you would suggest testing? Would an overnight smoke test with netperf suffice? -Ron -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code
The recent refactoring of the IGMP and MLD parsing code into
ipv6_mc_check_mld() / ip_mc_check_igmp() introduced a potential crash /
BUG() invocation for bridges:
I wrongly assumed that skb_get() could be used as a simple reference
counter for an skb which is not the case. skb_get() bears additional
semantics, a user count. This leads to a BUG() invocation in
pskb_expand_head() / kernel panic if pskb_may_pull() is called on an skb
with a user count greater than one - unfortunately the refactoring did
just that.
Fixing this by removing the skb_get() call and changing the API: The
caller of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to
additionally check whether the returned skb_trimmed is a clone.
Fixes: 9afd85c9e455 (net: Export IGMP/MLD message validation code)
Reported-by: Brenden Blanco bbla...@plumgrid.com
Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
net/bridge/br_multicast.c |4 ++--
net/core/skbuff.c | 37 ++---
net/ipv4/igmp.c | 33 ++---
net/ipv6/mcast_snoop.c| 33 ++---
4 files changed, 56 insertions(+), 51 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 0b39dcc..1285eaf 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1591,7 +1591,7 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
break;
}
- if (skb_trimmed)
+ if (skb_trimmed skb_trimmed != skb)
kfree_skb(skb_trimmed);
return err;
@@ -1636,7 +1636,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
break;
}
- if (skb_trimmed)
+ if (skb_trimmed skb_trimmed != skb)
kfree_skb(skb_trimmed);
return err;
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index b6a19ca..bf9a5d9 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4022,8 +4022,8 @@ EXPORT_SYMBOL(skb_checksum_setup);
* Otherwise returns the provided skb. Returns NULL in error cases
* (e.g. transport_len exceeds skb length or out-of-memory).
*
- * Caller needs to set the skb transport header and release the returned skb.
- * Provided skb is consumed.
+ * Caller needs to set the skb transport header and free any returned skb if it
+ * differs from the provided skb.
*/
static struct sk_buff *skb_checksum_maybe_trim(struct sk_buff *skb,
unsigned int transport_len)
@@ -4032,16 +4032,12 @@ static struct sk_buff *skb_checksum_maybe_trim(struct
sk_buff *skb,
unsigned int len = skb_transport_offset(skb) + transport_len;
int ret;
- if (skb-len len) {
- kfree_skb(skb);
+ if (skb-len len)
return NULL;
- } else if (skb-len == len) {
+ else if (skb-len == len)
return skb;
- }
skb_chk = skb_clone(skb, GFP_ATOMIC);
- kfree_skb(skb);
-
if (!skb_chk)
return NULL;
@@ -4066,8 +4062,8 @@ static struct sk_buff *skb_checksum_maybe_trim(struct
sk_buff *skb,
* If the skb has data beyond the given transport length, then a
* trimmed cloned skb is checked and returned.
*
- * Caller needs to set the skb transport header and release the returned skb.
- * Provided skb is consumed.
+ * Caller needs to set the skb transport header and free any returned skb if it
+ * differs from the provided skb.
*/
struct sk_buff *skb_checksum_trimmed(struct sk_buff *skb,
unsigned int transport_len,
@@ -4079,23 +4075,26 @@ struct sk_buff *skb_checksum_trimmed(struct sk_buff
*skb,
skb_chk = skb_checksum_maybe_trim(skb, transport_len);
if (!skb_chk)
- return NULL;
+ goto err;
- if (!pskb_may_pull(skb_chk, offset)) {
- kfree_skb(skb_chk);
- return NULL;
- }
+ if (!pskb_may_pull(skb_chk, offset))
+ goto err;
__skb_pull(skb_chk, offset);
ret = skb_chkf(skb_chk);
__skb_push(skb_chk, offset);
- if (ret) {
- kfree_skb(skb_chk);
- return NULL;
- }
+ if (ret)
+ goto err;
return skb_chk;
+
+err:
+ if (skb_chk skb_chk != skb)
+ kfree_skb(skb_chk);
+
+ return NULL;
+
}
EXPORT_SYMBOL(skb_checksum_trimmed);
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 651cdf6..9fdfd9d 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1435,33 +1435,35 @@ static int __ip_mc_check_igmp(struct sk_buff *skb,
struct sk_buff **skb_trimmed)
struct sk_buff *skb_chk;
unsigned int transport_len;
unsigned int len = skb_transport_offset(skb) + sizeof(struct igmphdr);
- int ret;
+ int ret = -EINVAL;
transport_len = ntohs(ip_hdr(skb)-tot_len) - ip_hdrlen(skb);
- skb_get(skb);
Re: [PATCH] net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code
On Thu, Aug 13, 2015 at 05:54:07AM +0200, Linus Lüssing wrote: The recent refactoring of the IGMP and MLD parsing code into ipv6_mc_check_mld() / ip_mc_check_igmp() introduced a potential crash / BUG() invocation for bridges: I wrongly assumed that skb_get() could be used as a simple reference counter for an skb which is not the case. skb_get() bears additional semantics, a user count. This leads to a BUG() invocation in pskb_expand_head() / kernel panic if pskb_may_pull() is called on an skb with a user count greater than one - unfortunately the refactoring did just that. Fixing this by removing the skb_get() call and changing the API: The caller of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to additionally check whether the returned skb_trimmed is a clone. Fixes: 9afd85c9e455 (net: Export IGMP/MLD message validation code) Reported-by: Brenden Blanco bbla...@plumgrid.com Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue I think the fix actually made the code easier to read. Thank you. Looks good to me. Acked-by: Alexei Starovoitov a...@plumgrid.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] rocker: hook ndo_neigh_destroy to cleanup neigh refs in driver
From: Scott Feldman sfel...@gmail.com
Rocker driver tracks arp_tbl neighs to resolve IPv4 route nexthops. The
driver uses NETEVENT_NEIGH_UPDATE for neigh adds and updates, but there is
no event when the neigh is removed from the device (such as when the device
goes admin down). This patches hooks ndo_neigh_destroy so the driver can
know when a neigh is removed from the device. In response, the driver will
purge the neigh entry from its internal tbl.
I didn't find an in-tree users of ndo_neigh_destroy, so I'm not sure if
this ndo is vestigial or if there are out-of-tree users. In any case, it
does what I need here. An alternative design would be to generate
NETEVENT_NEIGH_UPDATE event when neigh is being destroyed, setting state to
NUD_NONE so driver knows neigh entry is dead.
Signed-off-by: Scott Feldman sfel...@gmail.com
---
Documentation/networking/switchdev.txt |3 ++-
drivers/net/ethernet/rocker/rocker.c | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/switchdev.txt
b/Documentation/networking/switchdev.txt
index 9825f32..476df04 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -367,4 +367,5 @@ driver's rocker_port_ipv4_resolve() for an example.
The driver can monitor for updates to arp_tbl using the netevent notifier
NETEVENT_NEIGH_UPDATE. The device can be programmed with resolved nexthops
-for the routes as arp_tbl updates.
+for the routes as arp_tbl updates. The driver implements ndo_neigh_destroy
+to know when arp_tbl neighbor entries are purged from the port.
diff --git a/drivers/net/ethernet/rocker/rocker.c
b/drivers/net/ethernet/rocker/rocker.c
index af05075..619b2e2 100644
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@ -4264,6 +4264,16 @@ static int rocker_port_change_proto_down(struct
net_device *dev,
return 0;
}
+static void rocker_port_neigh_destroy(struct neighbour *n)
+{
+ struct rocker_port *rocker_port = netdev_priv(n-dev);
+ int flags = ROCKER_OP_FLAG_REMOVE | ROCKER_OP_FLAG_NOWAIT;
+ __be32 ip_addr = *(__be32 *)n-primary_key;
+
+ rocker_port_ipv4_neigh(rocker_port, SWITCHDEV_TRANS_NONE,
+ flags, ip_addr, n-ha);
+}
+
static const struct net_device_ops rocker_port_netdev_ops = {
.ndo_open = rocker_port_open,
.ndo_stop = rocker_port_stop,
@@ -4278,6 +4288,7 @@ static const struct net_device_ops rocker_port_netdev_ops
= {
.ndo_fdb_dump = switchdev_port_fdb_dump,
.ndo_get_phys_port_name = rocker_port_get_phys_port_name,
.ndo_change_proto_down = rocker_port_change_proto_down,
+ .ndo_neigh_destroy = rocker_port_neigh_destroy,
};
/
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] rocker: print switch ID consistent with phys_switch_id sysfs node
From: Scott Feldman sfel...@gmail.com On sucessful probe, driver prints the switch ID. This patch changes the format of the printed ID to match what's used in sysfs phys_switch_id node. Signed-off-by: Scott Feldman sfel...@gmail.com --- drivers/net/ethernet/rocker/rocker.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c index 619b2e2..d963cdc 100644 --- a/drivers/net/ethernet/rocker/rocker.c +++ b/drivers/net/ethernet/rocker/rocker.c @@ -5193,7 +5193,8 @@ static int rocker_probe(struct pci_dev *pdev, const struct pci_device_id *id) goto err_probe_ports; } - dev_info(pdev-dev, Rocker switch with id %016llx\n, rocker-hw.id); + dev_info(pdev-dev, Rocker switch with id %*phN\n, +(int)sizeof(rocker-hw.id), rocker-hw.id); return 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Intel-wired-lan] [PATCH] igbvf: clear buffer_info-dma after dma_unmap_single()
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On Behalf Of Stefan Assmann Sent: Thursday, August 06, 2015 12:32 AM To: intel-wired-...@lists.osuosl.org Cc: netdev@vger.kernel.org; sassm...@kpanic.de Subject: [Intel-wired-lan] [PATCH] igbvf: clear buffer_info-dma after dma_unmap_single() The driver doesn't clear buffer_info-dma after calling dma_unmap_single() in all cases. This has been discovered by changing the mtu twice, which caused the following backtrace. [ 68.569280] WARNING: CPU: 2 PID: 1860 at drivers/iommu/intel- iommu.c:3517 intel_unmap+0x20c/0x220() [ 68.579392] Driver unmaps unmatched page at PFN fffc2a40 [ 68.585322] Modules linked in: igbvf ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat kvm_intel kvm igb megs [ 68.599163] CPU: 2 PID: 1860 Comm: ifconfig Not tainted 4.2.0-rc4+ #147 [ 68.606543] Hardware name: IBM -[546025Z]-/00Y7630, BIOS -[VVE134TUS- 1.51]- 10/17/2013 [ 68.615473] 0dbd 88046441bb08 81a5ad0b 81e2f9ea [ 68.623775] 88046441bb58 88046441bb48 81056b55 88047fc583c0 [ 68.632075] 880469a8e600 fffc2a40 880465b32098 [ 68.640375] Call Trace: [ 68.643109] [81a5ad0b] dump_stack+0x48/0x5d [ 68.648844] [81056b55] warn_slowpath_common+0x95/0xe0 [ 68.655549] [81056c56] warn_slowpath_fmt+0x46/0x70 [ 68.661960] [8158a614] ? find_iova+0x54/0x90 [ 68.667791] [815988dc] intel_unmap+0x20c/0x220 [ 68.673815] [8159891e] intel_unmap_page+0xe/0x10 [ 68.680038] [a0067536] igbvf_clean_rx_ring+0x96/0x370 [igbvf] [ 68.687516] [a0067915] igbvf_down+0x105/0x110 [igbvf] [ 68.694219] [a0067beb] igbvf_change_mtu+0x16b/0x180 [igbvf] [...] Signed-off-by: Stefan Assmann sassm...@kpanic.de --- drivers/net/ethernet/intel/igbvf/netdev.c | 1 + 1 file changed, 1 insertion(+) Tested-by: Aaron Brown aaron.f.br...@intel.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/3] mpls: move mpls_route nexthop fields to a new nhlfe struct
On 8/12/15, 12:15 PM, Robert Shearman wrote:
On 11/08/15 22:45, Roopa Prabhu wrote:
From: Roopa Prabhu ro...@cumulusnetworks.com
moves mpls_route nexthop fields to a new mpls_nhlfe
struct. mpls_nhlfe represents a mpls nexthop label forwarding entry.
It prepares mpls route structure for multipath support.
In the process moves mpls_route structure into internal.h.
Is there a requirement for moving this and the new datastructures into
internal.h? I may have missed it, but I don't see any dependency on
this in this patch series.
No dependency really. In my initial implementation of iptunnels I had
some shared code and it had been in internal.h since then.
i don't share any of this with iptunnels now. But, if you see patch
3/3, there is a lot more macros I add with struct nhlfe etc and it is
cleaner
to move all this to a header file than keeping it in the .c file.
Moves some of the code from mpls_route_add into a separate mpls
nhlfe build function. changed mpls_rt_alloc to take number of
nexthops as argument.
A mpls route can point to multiple mpls_nhlfe. This patch
does not support multipath yet, hence the rest of the changes
assume that a mpls route points to a single mpls_nhlfe
Signed-off-by: Roopa Prabhu ro...@cumulusnetworks.com
---
net/mpls/af_mpls.c | 225
---
net/mpls/internal.h | 35
2 files changed, 158 insertions(+), 102 deletions(-)
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 8c5707d..cf86e9d 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -21,35 +21,6 @@
#endif
#include internal.h
-#define LABEL_NOT_SPECIFIED (120)
-#define MAX_NEW_LABELS 2
-
-/* This maximum ha length copied from the definition of struct
neighbour */
-#define MAX_VIA_ALEN (ALIGN(MAX_ADDR_LEN, sizeof(unsigned long)))
-
-enum mpls_payload_type {
-MPT_UNSPEC, /* IPv4 or IPv6 */
-MPT_IPV4 = 4,
-MPT_IPV6 = 6,
-
-/* Other types not implemented:
- * - Pseudo-wire with or without control word (RFC4385)
- * - GAL (RFC5586)
- */
-};
-
-struct mpls_route { /* next hop label forwarding entry */
-struct net_device __rcu *rt_dev;
-struct rcu_headrt_rcu;
-u32rt_label[MAX_NEW_LABELS];
-u8rt_protocol; /* routing protocol that set this
entry */
-u8 rt_payload_type;
-u8rt_labels;
-u8rt_via_alen;
-u8rt_via_table;
-u8rt_via[0];
-};
-
static int zero = 0;
static int label_limit = (1 20) - 1;
...
@@ -281,13 +254,15 @@ struct mpls_route_config {
struct nl_inforc_nlinfo;
};
-static struct mpls_route *mpls_rt_alloc(size_t alen)
+static struct mpls_route *mpls_rt_alloc(int num_nh)
{
struct mpls_route *rt;
-rt = kzalloc(sizeof(*rt) + alen, GFP_KERNEL);
+rt = kzalloc(sizeof(*rt) + (num_nh * sizeof(struct mpls_nhlfe)),
How about this instead:
offsetof(typeof(*rt), rt_nh[num_nh])
?
That way, you don't need to write out the type of rt_nh here.
I don't mind, but i followed existing convention for this (especially
the fib code).
would prefer keeping it the current way.
+ GFP_KERNEL);
if (rt)
-rt-rt_via_alen = alen;
+rt-rt_nhn = num_nh;
+
return rt;
}
@@ -322,7 +297,7 @@ static void mpls_route_update(struct net *net,
unsigned index,
platform_label = rtnl_dereference(net-mpls.platform_label);
rt = rtnl_dereference(platform_label[index]);
-if (!dev || (rt (rtnl_dereference(rt-rt_dev) == dev))) {
+if (!dev || (rt (rtnl_dereference(rt-rt_nh-nh_dev) == dev))) {
rcu_assign_pointer(platform_label[index], new);
old = rt;
}
@@ -406,23 +381,23 @@ static struct net_device
*inet6_fib_lookup_dev(struct net *net, void *addr)
#endif
static struct net_device *find_outdev(struct net *net,
- struct mpls_route_config *cfg)
+ struct mpls_nhlfe *nhlfe, int oif)
{
struct net_device *dev = NULL;
-if (!cfg-rc_ifindex) {
-switch (cfg-rc_via_table) {
+if (!oif) {
+switch (nhlfe-nh_via_table) {
case NEIGH_ARP_TABLE:
-dev = inet_fib_lookup_dev(net, cfg-rc_via);
+dev = inet_fib_lookup_dev(net, nhlfe-nh_via);
break;
case NEIGH_ND_TABLE:
-dev = inet6_fib_lookup_dev(net, cfg-rc_via);
+dev = inet6_fib_lookup_dev(net, nhlfe-nh_via);
break;
case NEIGH_LINK_TABLE:
break;
}
} else {
-dev = dev_get_by_index(net, cfg-rc_ifindex);
+dev = dev_get_by_index(net, oif);
}
if (!dev)
@@ -431,15 +406,81 @@ static struct net_device *find_outdev(struct
net *net,
return dev;
}
+int mpls_nhlfe_assign_dev(struct net *net, struct mpls_nhlfe *nhlfe,
int oif)
+{
+struct net_device *dev = NULL;
+int err = -ENODEV;
+
+dev =
[PATCH] net/fddi: remove HWM_REVERSE() macro
HWM_REVERSE() macro is unused, remove it. Signed-off-by: yalin wang yalin.wang2...@gmail.com --- drivers/net/fddi/skfp/h/hwmtm.h | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h index 5924d42..4ca2341 100644 --- a/drivers/net/fddi/skfp/h/hwmtm.h +++ b/drivers/net/fddi/skfp/h/hwmtm.h @@ -74,15 +74,6 @@ #define NULL 0 #endif -#ifdef LITTLE_ENDIAN -#define HWM_REVERSE(x) (x) -#else -#defineHWM_REVERSE(x) x)24L)0xff00L) + \ -(((x) 8L)0x00ffL) + \ -(((x) 8L)0xff00L) + \ -(((x)24L)0x00ffL)) -#endif - #define C_INDIC(1L25) #define A_INDIC(1L26) #defineRD_FS_LOCAL 0x80 -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] net/ipv4: inconsistent routing table
On Wed, Aug 12, 2015 at 4:52 AM, Alexander Duyck alexander.du...@gmail.com wrote: On 08/10/2015 04:50 AM, Hannes Frederic Sowa wrote: Hello, Zang MingJie zealot0...@gmail.com writes: Here comes several options: 1. reject local next hop w/ EINVAL 2. delete route when local next hop removed Will also cause some people to complain. 3. transition between RT_SCOPE_HOST amd RT_SCOPE_LINK I don't understand the scope transition. I know Alex mentioned it for the first time. Maybe he can explain? If I am not mistaken part of the issue in terms of the behaviour being seen is due to the fact that the nexthop scope is recorded only when the route is added, and there is code in place in rt_set_nexthop which will only use the gateway if the scope is RT_SCOPE_LINK. So what we would probably need to do is go through and audit any routes on a given interface every time an address is added or removed and if the nh_gw is equal to the address added or removed would would need to transition between RT_SCOPE_LINK and RT_SCOPE_HOST since the gateway is transitioning between the local system and somewhere on the other side of the link. The problem is that this would still be a behaviour change and there may be somebody that has heartburn about it. That's why I'm going to introduce a sysconf entry, with the entry unset, keep compatibility; with the entry set, fix the bug. 4. document it I prefer that one :) Yeah, me too. The fact is things have worked this way up until now and I suspect the reason why this hasn't been reported until now is simply because in many cases it works since routes are usually updated if you are moving the gateway onto the local system. - Alex -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DO YOU NEED A PERSONAL OR BUSINESS LOAN
Do you need credit for any legal purpose both business and personal?contact the Arab investment company now as We grant credit at 2% interest rate annually. Contact TAIC using the email: abdult...@qq.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv1 net-next 2/5] netlink: mmap: apply mmaped skb helper functions
Signed-off-by: Ken-ichirou MATSUZAWA cha...@h4.dion.ne.jp
---
net/netfilter/nfnetlink_log.c|2 +-
net/netfilter/nfnetlink_queue_core.c |6 +++---
net/netlink/af_netlink.c | 26 +-
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
index 4670821..cca2c50 100644
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -357,7 +357,7 @@ __nfulnl_send(struct nfulnl_instance *inst)
0);
if (WARN_ONCE(!nlh, bad nlskb size: %u, tailroom %d\n,
inst-skb-len, skb_tailroom(inst-skb))) {
- kfree_skb(inst-skb);
+ netlink_free_skb(inst-skb);
goto out;
}
}
diff --git a/net/netfilter/nfnetlink_queue_core.c
b/net/netfilter/nfnetlink_queue_core.c
index 685cc6a..8d07036 100644
--- a/net/netfilter/nfnetlink_queue_core.c
+++ b/net/netfilter/nfnetlink_queue_core.c
@@ -389,7 +389,7 @@ nfqnl_build_packet_message(struct net *net, struct
nfqnl_instance *queue,
sizeof(struct nfgenmsg), 0);
if (!nlh) {
skb_tx_error(entskb);
- kfree_skb(skb);
+ netlink_free_skb(skb);
return NULL;
}
nfmsg = nlmsg_data(nlh);
@@ -536,7 +536,7 @@ nfqnl_build_packet_message(struct net *net, struct
nfqnl_instance *queue,
nla_put_failure:
skb_tx_error(entskb);
- kfree_skb(skb);
+ netlink_free_skb(skb);
net_err_ratelimited(nf_queue: error creating packet message\n);
return NULL;
}
@@ -584,7 +584,7 @@ __nfqnl_enqueue_packet(struct net *net, struct
nfqnl_instance *queue,
return 0;
err_out_free_nskb:
- kfree_skb(nskb);
+ netlink_free_skb(nskb);
err_out_unlock:
spin_unlock_bh(queue-lock);
if (failopen)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 98ed579..45c8502 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -205,7 +205,7 @@ static int __netlink_deliver_tap_skb(struct sk_buff *skb,
int ret = -ENOMEM;
dev_hold(dev);
- nskb = skb_clone(skb, GFP_ATOMIC);
+ nskb = netlink_skb_clone(skb, GFP_ATOMIC);
if (nskb) {
nskb-dev = dev;
nskb-protocol = htons((u16) sk-sk_protocol);
@@ -764,7 +764,7 @@ static int netlink_mmap_sendmsg(struct sock *sk, struct
msghdr *msg,
err = security_netlink_send(sk, skb);
if (err) {
- kfree_skb(skb);
+ kfree_skb_partial(skb, true);
goto out;
}
@@ -804,7 +804,7 @@ static void netlink_queue_mmaped_skb(struct sock *sk,
struct sk_buff *skb)
netlink_set_status(hdr, NL_MMAP_STATUS_VALID);
NETLINK_CB(skb).flags |= NETLINK_SKB_DELIVERED;
- kfree_skb(skb);
+ kfree_skb_partial(skb, true);
}
static void netlink_ring_set_copied(struct sock *sk, struct sk_buff *skb)
@@ -1804,7 +1804,7 @@ int netlink_unicast(struct sock *ssk, struct sk_buff *skb,
retry:
sk = netlink_getsockbyportid(ssk, portid);
if (IS_ERR(sk)) {
- kfree_skb(skb);
+ netlink_free_skb(skb);
return PTR_ERR(sk);
}
if (netlink_is_kernel(sk))
@@ -1812,7 +1812,7 @@ retry:
if (sk_filter(sk, skb)) {
err = skb-len;
- kfree_skb(skb);
+ netlink_free_skb(skb);
sock_put(sk);
return err;
}
@@ -1876,7 +1876,7 @@ struct sk_buff *netlink_alloc_skb(struct sock *ssk,
unsigned int size,
return skb;
err2:
- kfree_skb(skb);
+ kfree_skb_partial(skb, true);
spin_unlock_bh(sk-sk_receive_queue.lock);
netlink_overrun(sk);
err1:
@@ -1884,7 +1884,7 @@ err1:
return NULL;
out_free:
- kfree_skb(skb);
+ kfree_skb_partial(skb, true);
spin_unlock_bh(sk-sk_receive_queue.lock);
out_put:
sock_put(sk);
@@ -2029,7 +2029,7 @@ static void do_one_broadcast(struct sock *sk,
sock_hold(sk);
if (p-skb2 == NULL) {
if (skb_shared(p-skb)) {
- p-skb2 = skb_clone(p-skb, p-allocation);
+ p-skb2 = netlink_skb_clone(p-skb, p-allocation);
} else {
p-skb2 = skb_get(p-skb);
/*
@@ -2105,7 +2105,7 @@ int netlink_broadcast_filtered(struct sock *ssk, struct
sk_buff *skb, u32 portid
sk_for_each_bound(sk, nl_table[ssk-sk_protocol].mc_list)
do_one_broadcast(sk, info);
- consume_skb(skb);
+ netlink_consume_skb(skb);
netlink_unlock_table();
@@ -2810,7 +2810,7 @@ static int netlink_dump(struct sock *sk)
[PATCHv1 net-next 3/5] netlink: mmap: fix status for not delivered skb
Signed-off-by: Ken-ichirou MATSUZAWA cha...@h4.dion.ne.jp
---
net/netlink/af_netlink.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 45c8502..c03fad0 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -864,7 +864,7 @@ static void netlink_skb_destructor(struct sk_buff *skb)
} else {
if (!(NETLINK_CB(skb).flags NETLINK_SKB_DELIVERED)) {
hdr-nm_len = 0;
- netlink_set_status(hdr, NL_MMAP_STATUS_VALID);
+ netlink_set_status(hdr, NL_MMAP_STATUS_UNUSED);
}
ring = nlk_sk(sk)-rx_ring;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] bpf: fix verifier
Wrong array boundary is used.
Fixes: 35578d798400 bpf: Implement function bpf_perf_event_read())
Cc: Kaixu Xia xiaka...@huawei.com
Cc: Alexei Starovoitov a...@plumgrid.com
Signed-off-by: Wei-Chun Chao weich...@plumgrid.com
---
kernel/bpf/verifier.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 48e1c71..ed12e38 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -853,7 +853,7 @@ static int check_map_func_compatibility(struct bpf_map
*map, int func_id)
if (!map)
return 0;
- for (i = 0; i = ARRAY_SIZE(func_limit); i++) {
+ for (i = 0; i ARRAY_SIZE(func_limit); i++) {
bool_map = (map-map_type == func_limit[i].map_type);
bool_func = (func_id == func_limit[i].func_id);
/* only when map func pair match it can continue.
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv1 net-next 1/5] netlink: mmap: introduce mmaped skb helper functions
It seems that we need helper functions for skb which is allocated
at netlink_alloc_skb() since it does not have skb_shared_info.
Signed-off-by: Ken-ichirou MATSUZAWA cha...@h4.dion.ne.jp
---
include/linux/netlink.h | 21 +-
net/netlink/af_netlink.c | 55 ++
2 files changed, 60 insertions(+), 16 deletions(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 9120edb..60492bf 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -70,6 +70,11 @@ extern void netlink_ack(struct sk_buff *in_skb, struct
nlmsghdr *nlh, int err);
extern int netlink_has_listeners(struct sock *sk, unsigned int group);
extern struct sk_buff *netlink_alloc_skb(struct sock *ssk, unsigned int size,
u32 dst_portid, gfp_t gfp_mask);
+extern struct sk_buff *netlink_skb_copy(const struct sk_buff *skb, gfp_t
gfp_mask);
+extern struct sk_buff *netlink_skb_clone(struct sk_buff *skb, gfp_t gfp_mask);
+extern void netlink_free_skb(struct sk_buff *skb);
+void netlink_consume_skb(struct sk_buff *skb);
+
extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32
portid, int nonblock);
extern int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, __u32
portid,
__u32 group, gfp_t allocation);
@@ -88,22 +93,6 @@ int netlink_attachskb(struct sock *sk, struct sk_buff *skb,
void netlink_detachskb(struct sock *sk, struct sk_buff *skb);
int netlink_sendskb(struct sock *sk, struct sk_buff *skb);
-static inline struct sk_buff *
-netlink_skb_clone(struct sk_buff *skb, gfp_t gfp_mask)
-{
- struct sk_buff *nskb;
-
- nskb = skb_clone(skb, gfp_mask);
- if (!nskb)
- return NULL;
-
- /* This is a large skb, set destructor callback to release head */
- if (is_vmalloc_addr(skb-head))
- nskb-destructor = skb-destructor;
-
- return nskb;
-}
-
/*
* skb should fit one page. This choice is good for headerless malloc.
* But we should limit to 8K so that userspace does not have to
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index d8e2e39..98ed579 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1894,6 +1894,61 @@ out:
}
EXPORT_SYMBOL_GPL(netlink_alloc_skb);
+struct sk_buff *netlink_skb_copy(const struct sk_buff *skb, gfp_t gfp_mask)
+{
+#ifdef CONFIG_NETLINK_MMAP
+ if (netlink_skb_is_mmaped(skb)) {
+ struct sk_buff *n = alloc_skb(skb-len, gfp_mask);
+ if (!n)
+ return NULL;
+
+ skb_put(n, skb-len);
+ NETLINK_CB(n).portid = NETLINK_CB(skb).portid;
+ memcpy(n-data, skb-data, skb-len);
+ return n;
+ } else
+#endif
+ return skb_copy(skb, gfp_mask);
+}
+EXPORT_SYMBOL_GPL(netlink_skb_copy);
+
+struct sk_buff *netlink_skb_clone(struct sk_buff *skb, gfp_t gfp_mask)
+{
+ struct sk_buff *nskb;
+
+#ifdef CONFIG_NETLINK_MMAP
+ if (netlink_skb_is_mmaped(skb))
+ return netlink_skb_copy(skb, gfp_mask);
+#endif
+ nskb = skb_clone(skb, gfp_mask);
+ if (!nskb)
+ return NULL;
+
+ /* This is a large skb, set destructor callback to release head */
+ if (is_vmalloc_addr(skb-head))
+ nskb-destructor = skb-destructor;
+
+ return nskb;
+}
+EXPORT_SYMBOL_GPL(netlink_skb_clone);
+
+void netlink_free_skb(struct sk_buff *skb)
+{
+ kfree_skb_partial(skb, netlink_skb_is_mmaped(skb));
+}
+EXPORT_SYMBOL_GPL(netlink_free_skb);
+
+void netlink_consume_skb(struct sk_buff *skb)
+{
+#ifdef CONFIG_NETLINK_MMAP
+ if (netlink_skb_is_mmaped(skb))
+ kfree_skb_partial(skb, true);
+ else
+#endif
+ consume_skb(skb);
+}
+EXPORT_SYMBOL_GPL(netlink_consume_skb);
+
int netlink_has_listeners(struct sock *sk, unsigned int group)
{
int res = 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv1 net-next 4/5] netlink: mmap: update tx type check
We need to accept msg_iter.type 1(WRITE) which is set in sendto/sendmsg.
Signed-off-by: Ken-ichirou MATSUZAWA cha...@h4.dion.ne.jp
---
net/netlink/af_netlink.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index c03fad0..d8f5151 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2451,7 +2451,7 @@ static int netlink_sendmsg(struct socket *sock, struct
msghdr *msg, size_t len)
* sendmsg(), but that's what we've got...
*/
if (netlink_tx_is_mmaped(sk)
- msg-msg_iter.type == ITER_IOVEC
+ !(msg-msg_iter.type (ITER_KVEC | ITER_BVEC))
msg-msg_iter.nr_segs == 1
msg-msg_iter.iov-iov_base == NULL) {
err = netlink_mmap_sendmsg(sk, msg, dst_portid, dst_group,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH iproute2 0/3] iplink: shortify printing the usage of bridge
This patch set enables bridge related links to print usage with short format.
Or else it is needed to use the following way:
ip link { add | del | set } type TYPE help
Zhang Shengju (3):
iplink: add missing link type
iplink: use the short format to print help info
iplink: shortify printing the usage of link type
ip/iplink.c | 2 +-
ip/iplink_bridge.c | 16 ++--
ip/iplink_bridge_slave.c | 16 ++--
3 files changed, 29 insertions(+), 5 deletions(-)
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH iproute2 2/3] iplink: use the short format to print help info
Allow to print link type usage by: ip link help bridge
Signed-off-by: Zhang Shengju zhangshen...@cmss.chinamobile.com
---
ip/iplink_bridge.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/ip/iplink_bridge.c b/ip/iplink_bridge.c
index 297160c..1e69960 100644
--- a/ip/iplink_bridge.c
+++ b/ip/iplink_bridge.c
@@ -17,9 +17,9 @@
#include utils.h
#include ip_common.h
-static void explain(void)
+static void print_explain(FILE *f)
{
- fprintf(stderr,
+ fprintf(f,
Usage: ... bridge [ forward_delay FORWARD_DELAY ]\n
[ hello_time HELLO_TIME ]\n
[ max_age MAX_AGE ]\n
@@ -29,6 +29,11 @@ static void explain(void)
);
}
+static void explain(void)
+{
+ print_explain(stderr);
+}
+
static int bridge_parse_opt(struct link_util *lu, int argc, char **argv,
struct nlmsghdr *n)
{
@@ -111,9 +116,16 @@ static void bridge_print_opt(struct link_util *lu, FILE
*f, struct rtattr *tb[])
rta_getattr_u32(tb[IFLA_BR_MAX_AGE]));
}
+static void bridge_print_help(struct link_util *lu, int argc, char **argv,
+ FILE *f)
+{
+ print_explain(f);
+}
+
struct link_util bridge_link_util = {
.id = bridge,
.maxattr= IFLA_BR_MAX,
.parse_opt = bridge_parse_opt,
.print_opt = bridge_print_opt,
+ .print_help = bridge_print_help,
};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] net: atl1c: add BQL support
This BQL implementation is mostly derived from its related driver, alx.
Tested on AR8131 (rev c0) [1969:1063]. Saturated a 100mbps link with 5
concurrent runs of netperf. Ping latency dropped from 14ms to 3ms.
Signed-off-by: Ron Angeles ronange...@gmail.com
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 932bd18..2795d6d 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -874,6 +874,8 @@ static void atl1c_clean_tx_ring(struct atl1c_adapter
*adapter,
atl1c_clean_buffer(pdev, buffer_info);
}
+ netdev_reset_queue(adapter-netdev);
+
/* Zero out Tx-buffers */
memset(tpd_ring-desc, 0, sizeof(struct atl1c_tpd_desc) *
ring_count);
@@ -1551,6 +1553,7 @@ static bool atl1c_clean_tx_irq(struct atl1c_adapter
*adapter,
u16 next_to_clean = atomic_read(tpd_ring-next_to_clean);
u16 hw_next_to_clean;
u16 reg;
+ unsigned int total_bytes = 0, total_packets = 0;
reg = type == atl1c_trans_high ? REG_TPD_PRI1_CIDX : REG_TPD_PRI0_CIDX;
@@ -1558,12 +1561,18 @@ static bool atl1c_clean_tx_irq(struct atl1c_adapter
*adapter,
while (next_to_clean != hw_next_to_clean) {
buffer_info = tpd_ring-buffer_info[next_to_clean];
+ if (buffer_info-skb) {
+ total_bytes += buffer_info-skb-len;
+ total_packets++;
+ }
atl1c_clean_buffer(pdev, buffer_info);
if (++next_to_clean == tpd_ring-count)
next_to_clean = 0;
atomic_set(tpd_ring-next_to_clean, next_to_clean);
}
+ netdev_completed_queue(adapter-netdev, total_packets, total_bytes);
+
if (netif_queue_stopped(adapter-netdev)
netif_carrier_ok(adapter-netdev)) {
netif_wake_queue(adapter-netdev);
@@ -2256,6 +2265,7 @@ static netdev_tx_t atl1c_xmit_frame(struct sk_buff *skb,
spin_unlock_irqrestore(adapter-tx_lock, flags);
dev_kfree_skb_any(skb);
} else {
+ netdev_sent_queue(adapter-netdev, skb-len);
atl1c_tx_queue(adapter, skb, tpd, type);
spin_unlock_irqrestore(adapter-tx_lock, flags);
}
--
2.4.6
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv1 net-next 0/5] netlink: mmap: kernel panic and some issues
Hi, It would be better if someone else is working on this. Or could you help me out? It's a tough work for me. Changes from RFC: * remove netlink_skb_zerocopy() I made a big mistake, and ``len = skb_tailroom(to)'' for mmaped skb is always true in nfqnl_build_packet_message() * copy portid in netlink_skb_copy() for netlink_lookup() in __netlink_dump_start() -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
