* [PATCH 4/4] wl1251: spi: add device tree support
From: Sebastian Reichel @ 2013-10-27 16:14 UTC (permalink / raw)
To: Sebastian Reichel, Luciano Coelho
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Tony Lindgren, Russell King,
John W. Linville, Felipe Balbi, Sachin Kamat, Greg Kroah-Hartman,
Bill Pemberton, devicetree, linux-doc, linux-kernel, linux-omap,
linux-arm-kernel, linux-wireless, netdev, Sebastian Reichel
In-Reply-To: <1382890469-25286-1-git-send-email-sre@debian.org>
Add device tree support for the spi variant of wl1251
and document the binding.
Signed-off-by: Sebastian Reichel <sre@debian.org>
---
.../devicetree/bindings/net/wireless/ti,wl1251.txt | 36 ++++++++++++++++++++++
drivers/net/wireless/ti/wl1251/spi.c | 23 ++++++++++----
2 files changed, 53 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
new file mode 100644
index 0000000..5f8a154
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
@@ -0,0 +1,36 @@
+* Texas Instruments wl1251 controller
+
+The wl1251 chip can be connected via SPI or via SDIO. The linux
+kernel currently only supports device tree for the SPI variant.
+
+Required properties:
+- compatible : Should be "ti,wl1251"
+- interrupts : Should contain interrupt line
+- interrupt-parent : Should be the phandle for the interrupt
+ controller that services interrupts for this device
+- vio-supply : phandle to regulator providing VIO
+- power-gpio : GPIO connected to chip's PMEN pin
+- For additional required properties on SPI, please consult
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+- ti,use-eeprom : If found, configuration will be loaded from eeprom.
+
+Examples:
+
+&spi1 {
+ wl1251_spi@0 {
+ compatible = "ti,wl1251";
+
+ reg = <0>;
+ spi-max-frequency = <48000000>;
+ spi-cpol;
+ spi-cpha;
+
+ interrupt-parent = <&gpio2>;
+ interrupts = <10 IRQ_TYPE_NONE>; /* gpio line 42 */
+
+ vio-supply = <&vio>;
+ power-gpio = <&gpio3 23 GPIO_ACTIVE_HIGH>; /* 87 */
+ };
+};
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index efea57a..ee6ce4c 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -27,6 +27,8 @@
#include <linux/spi/spi.h>
#include <linux/wl12xx.h>
#include <linux/gpio.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/regulator/consumer.h>
#include "wl1251.h"
@@ -240,13 +242,13 @@ static const struct wl1251_if_operations wl1251_spi_ops = {
static int wl1251_spi_probe(struct spi_device *spi)
{
- struct wl1251_platform_data *pdata;
+ struct wl1251_platform_data *pdata = spi->dev.platform_data;
+ struct device_node *np = spi->dev.of_node;
struct ieee80211_hw *hw;
struct wl1251 *wl;
int ret;
- pdata = spi->dev.platform_data;
- if (!pdata) {
+ if (!np && !pdata) {
wl1251_error("no platform data");
return -ENODEV;
}
@@ -273,7 +275,18 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
- wl->power_gpio = pdata->power_gpio;
+ if (np) {
+ wl->use_eeprom = of_property_read_bool(np, "ti,use-eeprom");
+ wl->power_gpio = of_get_named_gpio(np, "power-gpio", 0);
+ } else if (pdata) {
+ wl->power_gpio = pdata->power_gpio;
+ wl->use_eeprom = pdata->use_eeprom;
+ }
+
+ if (wl->power_gpio == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto out_free;
+ }
if (gpio_is_valid(wl->power_gpio)) {
ret = devm_gpio_request_one(&spi->dev, wl->power_gpio,
@@ -295,8 +308,6 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
- wl->use_eeprom = pdata->use_eeprom;
-
irq_set_status_flags(wl->irq, IRQ_NOAUTOEN);
ret = devm_request_irq(&spi->dev, wl->irq, wl1251_irq, 0,
DRIVER_NAME, wl);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Sebastian Reichel @ 2013-10-27 16:14 UTC (permalink / raw)
To: Sebastian Reichel, Luciano Coelho
Cc: Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, Rob Landley, Tony Lindgren, Russell King,
John W. Linville, Felipe Balbi, Sachin Kamat, Greg Kroah-Hartman,
Bill Pemberton, devicetree, linux-doc, linux-kernel, linux-omap,
linux-arm-kernel, linux-wireless, netdev, Sebastian Reichel
In-Reply-To: <1382890469-25286-1-git-send-email-sre@debian.org>
Move the power GPIO handling from the board code into
the driver. This is a dependency for device tree support.
Signed-off-by: Sebastian Reichel <sre@debian.org>
---
arch/arm/mach-omap2/board-omap3pandora.c | 2 ++
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++--------
drivers/net/wireless/ti/wl1251/sdio.c | 21 +++++++++++++-----
drivers/net/wireless/ti/wl1251/spi.c | 33 ++++++++++++++++++----------
drivers/net/wireless/ti/wl1251/wl1251.h | 2 +-
include/linux/wl12xx.h | 2 +-
6 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 24f3c1b..cf18340 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -541,6 +541,8 @@ static void __init pandora_wl1251_init(void)
memset(&pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
+ pandora_wl1251_pdata.power_gpio = -1;
+
ret = gpio_request_one(PANDORA_WIFI_IRQ_GPIO, GPIOF_IN, "wl1251 irq");
if (ret < 0)
goto fail;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 0d8e7d2..b9d95dd 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1164,13 +1164,7 @@ static inline void board_smc91x_init(void)
#endif
-static void rx51_wl1251_set_power(bool enable)
-{
- gpio_set_value(RX51_WL1251_POWER_GPIO, enable);
-}
-
static struct gpio rx51_wl1251_gpios[] __initdata = {
- { RX51_WL1251_POWER_GPIO, GPIOF_OUT_INIT_LOW, "wl1251 power" },
{ RX51_WL1251_IRQ_GPIO, GPIOF_IN, "wl1251 irq" },
};
@@ -1187,17 +1181,16 @@ static void __init rx51_init_wl1251(void)
if (irq < 0)
goto err_irq;
- wl1251_pdata.set_power = rx51_wl1251_set_power;
+ wl1251_pdata.power_gpio = RX51_WL1251_POWER_GPIO;
rx51_peripherals_spi_board_info[RX51_SPI_WL1251].irq = irq;
return;
err_irq:
gpio_free(RX51_WL1251_IRQ_GPIO);
- gpio_free(RX51_WL1251_POWER_GPIO);
error:
printk(KERN_ERR "wl1251 board initialisation failed\n");
- wl1251_pdata.set_power = NULL;
+ wl1251_pdata.power_gpio = -1;
/*
* Now rx51_peripherals_spi_board_info[1].irq is zero and
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c b/drivers/net/wireless/ti/wl1251/sdio.c
index b75a37a..b661f89 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -28,6 +28,7 @@
#include <linux/wl12xx.h>
#include <linux/irq.h>
#include <linux/pm_runtime.h>
+#include <linux/gpio.h>
#include "wl1251.h"
@@ -182,8 +183,9 @@ static int wl1251_sdio_set_power(struct wl1251 *wl, bool enable)
* callback in case it wants to do any additional setup,
* for example enabling clock buffer for the module.
*/
- if (wl->set_power)
- wl->set_power(true);
+ if (gpio_is_valid(wl->power_gpio))
+ gpio_set_value(wl->power_gpio, true);
+
ret = pm_runtime_get_sync(&func->dev);
if (ret < 0) {
@@ -203,8 +205,8 @@ static int wl1251_sdio_set_power(struct wl1251 *wl, bool enable)
if (ret < 0)
goto out;
- if (wl->set_power)
- wl->set_power(false);
+ if (gpio_is_valid(wl->power_gpio))
+ gpio_set_value(wl->power_gpio, false);
}
out:
@@ -256,11 +258,20 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl1251_board_data = wl1251_get_platform_data();
if (!IS_ERR(wl1251_board_data)) {
- wl->set_power = wl1251_board_data->set_power;
+ wl->power_gpio = wl1251_board_data->power_gpio;
wl->irq = wl1251_board_data->irq;
wl->use_eeprom = wl1251_board_data->use_eeprom;
}
+ if (gpio_is_valid(wl->power_gpio)) {
+ ret = devm_gpio_request(&func->dev, wl->power_gpio,
+ "wl1251 power");
+ if (ret) {
+ wl1251_error("Failed to request gpio: %d\n", ret);
+ goto disable;
+ }
+ }
+
if (wl->irq) {
irq_set_status_flags(wl->irq, IRQ_NOAUTOEN);
ret = request_irq(wl->irq, wl1251_line_irq, 0, "wl1251", wl);
diff --git a/drivers/net/wireless/ti/wl1251/spi.c b/drivers/net/wireless/ti/wl1251/spi.c
index 6bbbfe6..9a2df9d 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -26,6 +26,7 @@
#include <linux/crc7.h>
#include <linux/spi/spi.h>
#include <linux/wl12xx.h>
+#include <linux/gpio.h>
#include "wl1251.h"
#include "reg.h"
@@ -221,8 +222,8 @@ static void wl1251_spi_disable_irq(struct wl1251 *wl)
static int wl1251_spi_set_power(struct wl1251 *wl, bool enable)
{
- if (wl->set_power)
- wl->set_power(enable);
+ if (gpio_is_valid(wl->power_gpio))
+ gpio_set_value(wl->power_gpio, enable);
return 0;
}
@@ -271,22 +272,33 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
- wl->set_power = pdata->set_power;
- if (!wl->set_power) {
- wl1251_error("set power function missing in platform data");
- return -ENODEV;
+ wl->power_gpio = pdata->power_gpio;
+
+ if (gpio_is_valid(wl->power_gpio)) {
+ ret = devm_gpio_request_one(&spi->dev, wl->power_gpio,
+ GPIOF_OUT_INIT_LOW, "wl1251 power");
+ if (ret) {
+ wl1251_error("Failed to request gpio: %d\n", ret);
+ goto out_free;
+ }
+ } else {
+ wl1251_error("set power gpio missing in platform data");
+ ret = -ENODEV;
+ goto out_free;
}
wl->irq = spi->irq;
if (wl->irq < 0) {
wl1251_error("irq missing in platform data");
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_free;
}
wl->use_eeprom = pdata->use_eeprom;
irq_set_status_flags(wl->irq, IRQ_NOAUTOEN);
- ret = request_irq(wl->irq, wl1251_irq, 0, DRIVER_NAME, wl);
+ ret = devm_request_irq(&spi->dev, wl->irq, wl1251_irq, 0,
+ DRIVER_NAME, wl);
if (ret < 0) {
wl1251_error("request_irq() failed: %d", ret);
goto out_free;
@@ -296,13 +308,10 @@ static int wl1251_spi_probe(struct spi_device *spi)
ret = wl1251_init_ieee80211(wl);
if (ret)
- goto out_irq;
+ goto out_free;
return 0;
- out_irq:
- free_irq(wl->irq, wl);
-
out_free:
ieee80211_free_hw(hw);
diff --git a/drivers/net/wireless/ti/wl1251/wl1251.h b/drivers/net/wireless/ti/wl1251/wl1251.h
index fd02060..5e9808c 100644
--- a/drivers/net/wireless/ti/wl1251/wl1251.h
+++ b/drivers/net/wireless/ti/wl1251/wl1251.h
@@ -275,7 +275,7 @@ struct wl1251 {
void *if_priv;
const struct wl1251_if_operations *if_ops;
- void (*set_power)(bool enable);
+ int power_gpio;
int irq;
bool use_eeprom;
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index b516b4f..a9c723b 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -49,7 +49,7 @@ enum {
};
struct wl1251_platform_data {
- void (*set_power)(bool enable);
+ int power_gpio;
/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
int irq;
bool use_eeprom;
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Alexander Shiyan @ 2013-10-27 16:24 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Mark Rutland, linux-doc, Tony Lindgren, Russell King,
Sachin Kamat, Stephen Warren, Sebastian Reichel, Luciano Coelho,
devicetree, Pawel Moll, Ian Campbell, John W. Linville,
Rob Herring, Bill Pemberton, linux-omap, linux-arm-kernel,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <1382890469-25286-3-git-send-email-sre@debian.org>
> Move the power GPIO handling from the board code into
> the driver. This is a dependency for device tree support.
>
> Signed-off-by: Sebastian Reichel <sre@debian.org>
> ---
> arch/arm/mach-omap2/board-omap3pandora.c | 2 ++
> arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++--------
> drivers/net/wireless/ti/wl1251/sdio.c | 21 +++++++++++++-----
> drivers/net/wireless/ti/wl1251/spi.c | 33 ++++++++++++++++++----------
> drivers/net/wireless/ti/wl1251/wl1251.h | 2 +-
> include/linux/wl12xx.h | 2 +-
> 6 files changed, 43 insertions(+), 28 deletions(-)
...
> diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
> index b516b4f..a9c723b 100644
> --- a/include/linux/wl12xx.h
> +++ b/include/linux/wl12xx.h
> @@ -49,7 +49,7 @@ enum {
> };
>
> struct wl1251_platform_data {
> - void (*set_power)(bool enable);
> + int power_gpio;
> /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
> int irq;
> bool use_eeprom;
> --
What a reason for not using regulator API here with GPIO-based regulator?
---
^ permalink raw reply
* [PATCH net-next v2] ipv4: fix DO and PROBE pmtu mode regarding local fragmentation with UFO/CORK
From: Hannes Frederic Sowa @ 2013-10-27 16:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <20131025194003.GG15744@order.stressinduktion.org>
UFO as well as UDP_CORK do not respect IP_PMTUDISC_DO and
IP_PMTUDISC_PROBE well enough.
UFO enabled packet delivery just appends all frags to the cork and hands
it over to the network card. So we just deliver non-DF udp fragments
(DF-flag may get overwritten by hardware or virtual UFO enabled
interface).
UDP_CORK does enqueue the data until the cork is disengaged. At this
point it sets the correct IP_DF and local_df flags and hands it over to
ip_fragment which in this case will generate an icmp error which gets
appended to the error socket queue. This is not reflected in the syscall
error (of course, if UFO is enabled this also won't happen).
Improve this by checking the pmtudisc flags before appending data to the
socket and if we still can fit all data in one packet when IP_PMTUDISC_DO
or IP_PMTUDISC_PROBE is set, only then proceed.
We use (mtu-fragheaderlen) to check for the maximum length because we
ensure not to generate a fragment and non-fragmented data does not need
to have its length aligned on 64 bit boundaries. Also the passed in
ip_options are already aligned correctly.
Maybe, we can relax some other checks around ip_fragment. This needs
more research.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
v2:
Switch from maxfraglen to mtu for length check as outlined in the commit
message.
net/ipv4/ip_output.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 8fbac7d..51be64e 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -810,7 +810,7 @@ static int __ip_append_data(struct sock *sk,
int copy;
int err;
int offset = 0;
- unsigned int maxfraglen, fragheaderlen;
+ unsigned int maxfraglen, fragheaderlen, maxnonfragsize;
int csummode = CHECKSUM_NONE;
struct rtable *rt = (struct rtable *)cork->dst;
@@ -823,8 +823,10 @@ static int __ip_append_data(struct sock *sk,
fragheaderlen = sizeof(struct iphdr) + (opt ? opt->optlen : 0);
maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen;
+ maxnonfragsize = (inet->pmtudisc >= IP_PMTUDISC_DO) ?
+ mtu : 0xFFFF;
- if (cork->length + length > 0xFFFF - fragheaderlen) {
+ if (cork->length + length > maxnonfragsize - fragheaderlen) {
ip_local_error(sk, EMSGSIZE, fl4->daddr, inet->inet_dport,
mtu-exthdrlen);
return -EMSGSIZE;
@@ -1122,7 +1124,7 @@ ssize_t ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
int mtu;
int len;
int err;
- unsigned int maxfraglen, fragheaderlen, fraggap;
+ unsigned int maxfraglen, fragheaderlen, fraggap, maxnonfragsize;
if (inet->hdrincl)
return -EPERM;
@@ -1146,8 +1148,10 @@ ssize_t ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
fragheaderlen = sizeof(struct iphdr) + (opt ? opt->optlen : 0);
maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen;
+ maxnonfragsize = (inet->pmtudisc >= IP_PMTUDISC_DO) ?
+ mtu : 0xFFFF;
- if (cork->length + size > 0xFFFF - fragheaderlen) {
+ if (cork->length + size > maxnonfragsize - fragheaderlen) {
ip_local_error(sk, EMSGSIZE, fl4->daddr, inet->inet_dport, mtu);
return -EMSGSIZE;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Hannes Frederic Sowa @ 2013-10-27 16:48 UTC (permalink / raw)
To: Jiri Pirko
Cc: Vladislav Yasevich, netdev@vger.kernel.org, David Miller, kuznet,
jmorris, yoshfuji, kaber, thaller, Stephen Hemminger
In-Reply-To: <20131027132941.GA1443@minipsycho.orion>
Hi Jiri!
On Sun, Oct 27, 2013 at 02:29:41PM +0100, Jiri Pirko wrote:
> The idea is to provide possibility to do address configuration not in
> kernel but rather in userspace (as it is done for example in NetworkManager)
>
> Maybe I'm missing something, but why is it problem to have the
> possibility to set lifetime even for temporary prefix?
There is no problem setting the lifetime for a temporary prefix (in
contrary, it needs one) but the code paths designed for IFA_F_TEMPORARY
may not fiddle with it. This needs to be checked.
In this constellation addrconf_verify does not refresh the privacy
address when its preferred lifetime is expired, if you create the
address by only passing IFA_F_TEMPORARY to rtm_newaddr (as Vlad pointed
out). E.g. NetworkManager has to take care about that, then.
A temporary address is also bound to a non-privacy public address so
it's lifetime is determined by its lifetime (e.g. if you switch the
network and don't receive on-link information for that prefix any
more). NetworkManager would have to take care about that, too. It is
just a question of what NetworkManager wants to handle itself or lets
the kernel handle for it.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH 0/2] net_sched: Remove broken tc actions
From: Jamal Hadi Salim @ 2013-10-27 16:58 UTC (permalink / raw)
To: Eric W. Biederman, David Miller; +Cc: netdev, alexander.h.duyck
In-Reply-To: <87fvrmu909.fsf@xmission.com>
On 10/27/13 09:40, Eric W. Biederman wrote:
>
> While auditing the code to make certain it would be safe to enable the
> user namespace root to use tc actions I stumbled on the strange fact
> that two of the tc modules in the kernel have been broken for more
> years than I care to think about.
>
> In particular neither of these two modules implements the tc_action_ops
> lookup method. Which means that in practice neither RTM_GETACTION nor
> RTM_DELACTION work. And with RTM_DELACTION broken that looks like a
> permanent leak of kernel memory to me.
>
>
> A leak I am not happy at root having and certainly not something I want
> to allow unprivileged users access to.
>
> On the premise that 5+ years is too long to wait for someone to notice,
> complain and get this code fixed let's just remove these broken tc
> modules.
>
Nah, dude.
You dont have to implement the get/del. Actions are typically bound
to filters; when the filters disappears the action is destroyed.
You Get the filter, you Get the bound actions.
you can add actions without filters - but in such a case, for both
of these ones you picked, you can dump or flush them unless they are
bound to a filter. Thats the minimal requirement (which is met).
What is your use case to need explicit get/del?
Given act_simple is pedagogical in nature, I think
that will be useful for illustration purposes.
cheers,
jamal
^ permalink raw reply
* Re: extending ndo_add_rx_vxlan_port
From: Joseph Gasparakis @ 2013-10-27 17:25 UTC (permalink / raw)
To: Or Gerlitz
Cc: Joseph Gasparakis, John Fastabend, Yan Burman, netdev,
Stephen Hemminger
In-Reply-To: <526D2F8F.1070204@mellanox.com>
On Sun, 27 Oct 2013, Or Gerlitz wrote:
> Hi,
>
> So with commit 53cf527513eed6e7170e9dceacd198f9267171b0 "vxlan: Notify drivers
> for listening UDP port changes" drivers that have HW offloads for vxlan can be
> notified on which UDP port to listen. Taking this further, some HW may need to
> know the multicast address and/or the VNID used by the vxlan instance/s set
> above them. In that respect, do we prefer to extend ndo_add_rx_vxlan_port() or
> introduce new ndo?
>
> Or.
>
The way this patch works is to notify the drivers when a VXLAN UDP port
comes up or down. This way drivers do not need to do any sort of accounting. As
long as this remains, it sounds fine to me to extend the existing ndo. If
by extedning it, drivers now have to keep track of the udp ports so they
can determine if a notification is for a new port or not, I would much
rather go for introducing a new ndo.
Joseph
^ permalink raw reply
* Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
From: Jamal Hadi Salim @ 2013-10-27 17:19 UTC (permalink / raw)
To: Felix Fietkau, Florian Fainelli, Neil Horman
Cc: John Fastabend, netdev, David Miller, Sascha Hauer, John Crispin,
Jonas Gorski, Gary Thomas, Vlad Yasevich, Stephen Hemminger
In-Reply-To: <526A6BB3.7050507@openwrt.org>
On 10/25/13 09:01, Felix Fietkau wrote:
> On 2013-10-25 1:43 PM, Jamal Hadi Salim wrote:
> I think it's common for the switch to have a global MAC address, not a
> per-port one.
Ok, I see. Real cheep.
> 'won't pass up the tag'? The switch is treated in pretty much the same
> way as a normal managed standalone switch (you know, one you can buy in
> a shop and plug your Ethernet cable into).
> You simply tell it, which VLANs to put on which ports, and make the
> ports tagged or untagged.
> The link between the switch and the CPU is not really special, for the
> switch it's just another port. This way of configuring works with pretty
> much all switches that we're using.
So does it get its own MAC address? Other than flooding broadcasts,
how does one end up sending packets to the cpu?
> Yes, some switches have them, and they can be useful when dealing with
> multiple VLANs.
Very nice. So we go from one extreme of cheep to sophisticated ;->
I think the only way you can achieve multiple tables on the bridge
is by creating multiple bridges.
> No, because the connection between the CPU and the switch is handled by
> a normal Ethernet MAC. The Ethernet chip doesn't care if there's a
> switch connected to it, or a regular PHY.
> It's just a normal MII connection, nothing more.
>
[..]
>
> Right, the netdev that owns the PHY is a normal Ethernet MAC, running
> any normal Linux Ethernet driver.
>
[..]
> I remain absolutely unconvinced that this will make the end result
> better. Right now, these switches act like separate devices, because
> aside from the fact that they're put on the same board with other
> components, they pretty much *are* separate devices.
>
> You seem to insist on treating it as a kind of port multiplexer + bridge
> accelerator instead of a mostly standalone switch.
>
Yes, the above is the point i was making.
I apologize for sounding like a broken record, but to just re-iterate:
there are, if i recall correctly, several drivers in the kernel
which are challenged as such (with single entry point into the CPU)
which expose multiple netdevs with the driver acting as mux point.
> This may work for some devices, but on others this simply a model that
> the hardware wasn't designed for.
I agree. But what i just described above is not new. A lot of embedded
multiport NICs tend to be handicapped in exactly the same way.
> Sure, we could try to cram in all
> those special cases, extra options, and hack through the layers where
> they're in the way. If *all* you care about is being able to reuse the
> existing interfaces, that might even seem like a good idea.
>
I do care a lot about using existing interfaces ;-> Great usability
for someone to run a tool that has been around for 20 years and it
works. If i can just reuse my scripts without having to invent
new ones etc etc.
> On the other hand, I've pointed out quite a few examples where the model
> of trying to cram it into the bridge API is just a bad fit in general.
>
Sorry Felix, nothing you described is insurmountable.
The challenge here is non-technical:
You already have code that has been proven and is deployed for what
appears to be sometime now.
I totally empathize.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] netfilter: ipset: remove duplicate define
From: Jozsef Kadlecsik @ 2013-10-27 18:07 UTC (permalink / raw)
To: Michael Opdenacker
Cc: Pablo Neira Ayuso, Patrick McHardy, David Miller, netfilter-devel,
netfilter, coreteam, netdev, linux-kernel
In-Reply-To: <1382524574-3214-1-git-send-email-michael.opdenacker@free-electrons.com>
On Wed, 23 Oct 2013, Michael Opdenacker wrote:
> This patch removes a duplicate define from
> net/netfilter/ipset/ip_set_hash_gen.h
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Patch is applied to the ipset git tree, thanks.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
From: Florian Fainelli @ 2013-10-27 18:14 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Felix Fietkau, Neil Horman, John Fastabend, netdev, David Miller,
Sascha Hauer, John Crispin, Jonas Gorski, Gary Thomas,
Vlad Yasevich, Stephen Hemminger
In-Reply-To: <526D4B06.8040505@mojatatu.com>
2013/10/27 Jamal Hadi Salim <jhs@mojatatu.com>:
> On 10/25/13 09:01, Felix Fietkau wrote:
>>
>> On 2013-10-25 1:43 PM, Jamal Hadi Salim wrote:
>
>
>> I think it's common for the switch to have a global MAC address, not a
>> per-port one.
>
>
> Ok, I see. Real cheep.
They are yes, the only "fancy" features these switches allow is
basically to set a given's port vlan id, which is already a huge
improvement compared to the vendor provided firmware.
>
>
>> 'won't pass up the tag'? The switch is treated in pretty much the same
>> way as a normal managed standalone switch (you know, one you can buy in
>> a shop and plug your Ethernet cable into).
>> You simply tell it, which VLANs to put on which ports, and make the
>> ports tagged or untagged.
>> The link between the switch and the CPU is not really special, for the
>> switch it's just another port. This way of configuring works with pretty
>> much all switches that we're using.
>
>
> So does it get its own MAC address? Other than flooding broadcasts,
> how does one end up sending packets to the cpu?
The switch does have an address learning process which is usually not
controlled by software at all, so yes, flooding is usually the way to
get it to the CPU.
>
>
>> Yes, some switches have them, and they can be useful when dealing with
>> multiple VLANs.
>
>
> Very nice. So we go from one extreme of cheep to sophisticated ;->
> I think the only way you can achieve multiple tables on the bridge
> is by creating multiple bridges.
>
>
>> No, because the connection between the CPU and the switch is handled by
>> a normal Ethernet MAC. The Ethernet chip doesn't care if there's a
>> switch connected to it, or a regular PHY.
>> It's just a normal MII connection, nothing more.
>>
> [..]
>
>>
>> Right, the netdev that owns the PHY is a normal Ethernet MAC, running
>> any normal Linux Ethernet driver.
>>
> [..]
>
>> I remain absolutely unconvinced that this will make the end result
>> better. Right now, these switches act like separate devices, because
>> aside from the fact that they're put on the same board with other
>> components, they pretty much *are* separate devices.
>>
>> You seem to insist on treating it as a kind of port multiplexer + bridge
>> accelerator instead of a mostly standalone switch.
>>
>
>
> Yes, the above is the point i was making.
> I apologize for sounding like a broken record, but to just re-iterate:
> there are, if i recall correctly, several drivers in the kernel
> which are challenged as such (with single entry point into the CPU)
> which expose multiple netdevs with the driver acting as mux point.
Which exact drivers are you refering to? If we are talking about DSA
then yes, this is correct, but it is completely Ethernet MAC driver
agnostic.
>
>
>> This may work for some devices, but on others this simply a model that
>> the hardware wasn't designed for.
>
>
> I agree. But what i just described above is not new. A lot of embedded
> multiport NICs tend to be handicapped in exactly the same way.
Why would we expose the hardware switch physical ports as netdevs if
we cannot even any control over their data-path? Unlike these
multiport NICs, the only traffic you see and you can control is the
one from your CPU port.
>
>
>> Sure, we could try to cram in all
>> those special cases, extra options, and hack through the layers where
>> they're in the way. If *all* you care about is being able to reuse the
>> existing interfaces, that might even seem like a good idea.
>>
>
> I do care a lot about using existing interfaces ;-> Great usability
> for someone to run a tool that has been around for 20 years and it
> works. If i can just reuse my scripts without having to invent
> new ones etc etc.
I do not really see how we could bend the existing interface (is it
rtnetlink we are talking about or something else btw?) to expose these
switches, maybe we could with iproute2, but still, the user-space
interface/tool is far from being the problem here.
>
>
>> On the other hand, I've pointed out quite a few examples where the model
>> of trying to cram it into the bridge API is just a bad fit in general.
>>
>
> Sorry Felix, nothing you described is insurmountable.
> The challenge here is non-technical:
> You already have code that has been proven and is deployed for what appears
> to be sometime now.
> I totally empathize.
I don't think at any point in this discussion there was a mention that
we do not want to change the user or kernel interface in OpenWrt
because we have been using this for the past 5 years, on the contrary,
if we are bringing this to a wide audience, this is to get some proper
review and eventually change it.
--
Florian
^ permalink raw reply
* Re: Netem Delay Normal Distribution
From: Eric Dumazet @ 2013-10-27 19:27 UTC (permalink / raw)
To: anirup dutta; +Cc: netdev, Stephen Hemminger
In-Reply-To: <CAJx7G_xkrVkC7HGQZogivA_6-i2Gas6aJd-sOFNMEbmq8=cS0g@mail.gmail.com>
On Sat, 2013-10-26 at 21:31 -0500, anirup dutta wrote:
> Hello,
>
> I try this on my device
>
> sudo tc qdisc del dev eth0 root netem delay 100ms 20ms distribution normal
>
> I use iperf for transmitting UDP packets and I modified its code to
> get per packet delay. When I plot the distribution of delays and
> analyze the delays they pass the normality tests.
>
> The only problem that I am not able to understand is that the mean of
> those delays shift to 125ms. Its not only me. There was another study
> and it observed the same thing.
>
> http://www.researchgate.net/publication/224256550_An_Empirical_Study_of_NetEm_Network_Emulation_Functionalities/file/d912f5058c9b1e409b.pdf
>
> Figure 7
>
> I found out that this command is valid
>
> sudo tc qdisc del dev eth0 root netem delay 1ms 20ms distribution normal
>
> So I have a feeling that mean gets shifted from the base delay to
> avoid negative delay values.
>
> It would be great if someone can confirm how it is implemented?
What version of linux are you running exactly ? We had many fixes in
netem...
Here are my results running latest net-next tree. I see no problem for
the mean, but for the min/max (range of the variation)
Omitting "distribution normal" gets expected results :
lpq83:~# tc qd del dev eth0 root
lpq83:~# tc qdisc add dev eth0 root netem delay 100ms 20ms
lpq83:~# ping -i 0.1 -q -c 100 lpq84
100 packets transmitted, 100 received, 0% packet loss, time 19721ms
rtt min/avg/max/mdev = 80.504/100.383/120.106/11.534 ms, pipe 2
But using "distribution normal" impacts the min/max :
lpq83:~# tc qd del dev eth0 root
lpq83:~# tc qdisc add dev eth0 root netem delay 10ms 2ms distribution normal
lpq83:~# ping -i 0.1 -q -c 100 lpq84
100 packets transmitted, 100 received, 0% packet loss, time 9963ms
rtt min/avg/max/mdev = 4.829/10.214/13.973/1.988 ms
lpq83:~# tc qd del dev eth0 root
lpq83:~# tc qdisc add dev eth0 root netem delay 100ms 20ms distribution normal
lpq83:~# ping -i 0.1 -q -c 100 lpq84
100 packets transmitted, 100 received, 0% packet loss, time 19166ms
rtt min/avg/max/mdev = 46.137/100.035/159.869/21.136 ms, pipe 2
So the mean seems OK, but the min/max seems scaled by a 2 factor.
NETEM_DIST_SCALE seems to be 8192 in the kernel, but the tc injects
distribution tables with s16 integers, in the -32768 .. 32768 range
Stephen, do you have an idea of what is wrong
(the distribution files in /usr/lib/tc or the kernel )?
Relevant code in tabledist() is :
t = dist->table[rnd % dist->size];
x = (sigma % NETEM_DIST_SCALE) * t;
if (x >= 0)
x += NETEM_DIST_SCALE/2;
else
x -= NETEM_DIST_SCALE/2;
return x / NETEM_DIST_SCALE + (sigma / NETEM_DIST_SCALE) * t + mu;
root@edumazet-glaptop:/usr/lib/tc# head -n 4 /usr/lib/tc/normal.dist
# This is the distribution table for the normal distribution.
-32768 -28307 -26871 -25967 -25298 -24765 -24320 -23937
-23600 -23298 -23025 -22776 -22546 -22333 -22133 -21946
-21770 -21604 -21445 -21295 -21151 -21013 -20882 -20755
root@edumazet-glaptop:/usr/lib/tc# tail -n 4 /usr/lib/tc/normal.dist
19816 19911 20009 20109 20213 20319 20430 20544
20663 20786 20914 21047 21186 21331 21484 21644
21813 21991 22181 22384 22601 22836 23091 23370
23679 24027 24424 24888 25450 26164 27159 28858
^ permalink raw reply
* Re: [PATCH 1/3] vxlan: silence one build warning
From: Stephen Hemminger @ 2013-10-27 19:33 UTC (permalink / raw)
To: Zhi Yong Wu; +Cc: netdev, linux-kernel mlist, Zhi Yong Wu
In-Reply-To: <CAEH94LjOnWgchhV__TLK9se-Cb3WkGnVfNZgNBBLdZL0kNM=-g@mail.gmail.com>
On Sun, 27 Oct 2013 10:30:56 +0800
Zhi Yong Wu <zwu.kernel@gmail.com> wrote:
> HI, Stephen
>
> I saw it on Fedora 17 without latest kernel. Then what do you think
> that it is appropriate to solve this problem? discard this patch? If
> yes, i can also agree.
>
Either find where the uninitialized use is being caused by finding the code
path where it happens (manual analysis), or ignore the warning.
^ permalink raw reply
* Re: Netem Delay Normal Distribution
From: Stephen Hemminger @ 2013-10-27 19:37 UTC (permalink / raw)
To: anirup dutta; +Cc: netdev
In-Reply-To: <CAJx7G_xkrVkC7HGQZogivA_6-i2Gas6aJd-sOFNMEbmq8=cS0g@mail.gmail.com>
On Sat, 26 Oct 2013 21:31:03 -0500
anirup dutta <adutta2@uh.edu> wrote:
> Hello,
>
> I try this on my device
>
> sudo tc qdisc del dev eth0 root netem delay 100ms 20ms distribution normal
>
> I use iperf for transmitting UDP packets and I modified its code to
> get per packet delay. When I plot the distribution of delays and
> analyze the delays they pass the normality tests.
>
> The only problem that I am not able to understand is that the mean of
> those delays shift to 125ms. Its not only me. There was another study
> and it observed the same thing.
>
> http://www.researchgate.net/publication/224256550_An_Empirical_Study_of_NetEm_Network_Emulation_Functionalities/file/d912f5058c9b1e409b.pdf
>
> Figure 7
>
> I found out that this command is valid
>
> sudo tc qdisc del dev eth0 root netem delay 1ms 20ms distribution normal
>
> So I have a feeling that mean gets shifted from the base delay to
> avoid negative delay values.
>
> It would be great if someone can confirm how it is implemented?
The table distribution logic actually predates netem.
It came from NIST Net http://snad.ncsl.nist.gov/nistnet/
The code was direct copy from this public domain code.
^ permalink raw reply
* Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
From: Felix Fietkau @ 2013-10-27 19:51 UTC (permalink / raw)
To: Jamal Hadi Salim, Florian Fainelli, Neil Horman
Cc: John Fastabend, netdev, David Miller, Sascha Hauer, John Crispin,
Jonas Gorski, Gary Thomas, Vlad Yasevich, Stephen Hemminger
In-Reply-To: <526D4B06.8040505@mojatatu.com>
On 2013-10-27 6:19 PM, Jamal Hadi Salim wrote:
> On 10/25/13 09:01, Felix Fietkau wrote:
>> 'won't pass up the tag'? The switch is treated in pretty much the same
>> way as a normal managed standalone switch (you know, one you can buy in
>> a shop and plug your Ethernet cable into).
>> You simply tell it, which VLANs to put on which ports, and make the
>> ports tagged or untagged.
>> The link between the switch and the CPU is not really special, for the
>> switch it's just another port. This way of configuring works with pretty
>> much all switches that we're using.
>
> So does it get its own MAC address? Other than flooding broadcasts,
> how does one end up sending packets to the cpu?
That question does not make any sense to me. Aside from low level
control frames like pause frames for flow control, the switch has no
need to send packets to the CPU port on its own.
Remember what I told you about the switch being a *separate* entity from
the NIC that connects it to the CPU.
>> I remain absolutely unconvinced that this will make the end result
>> better. Right now, these switches act like separate devices, because
>> aside from the fact that they're put on the same board with other
>> components, they pretty much *are* separate devices.
>>
>> You seem to insist on treating it as a kind of port multiplexer + bridge
>> accelerator instead of a mostly standalone switch.
>
> Yes, the above is the point i was making.
> I apologize for sounding like a broken record, but to just re-iterate:
> there are, if i recall correctly, several drivers in the kernel
> which are challenged as such (with single entry point into the CPU)
> which expose multiple netdevs with the driver acting as mux point.
DSA does this, and last time I looked, it pushes *all* bridge traffic
through the CPU, making it completely unusable for slower embedded CPUs.
If I remember correctly, adding support 'bridge acceleration' was left
as an exercise for the reader and never actually implemented.
Sure, this could be fixed somehow, but even then the model and
assumptions that DSA is built on simply don't work for some of the
dumber switches that we support.
>> This may work for some devices, but on others this simply a model that
>> the hardware wasn't designed for.
>
> I agree. But what i just described above is not new. A lot of embedded
> multiport NICs tend to be handicapped in exactly the same way.
>
>> Sure, we could try to cram in all
>> those special cases, extra options, and hack through the layers where
>> they're in the way. If *all* you care about is being able to reuse the
>> existing interfaces, that might even seem like a good idea.
>
> I do care a lot about using existing interfaces ;-> Great usability
> for someone to run a tool that has been around for 20 years and it
> works. If i can just reuse my scripts without having to invent
> new ones etc etc.
I see that. But please stop treating this as the *only* factor that
matters! I'd like to see a more balanced cost/benefit analysis.
>> On the other hand, I've pointed out quite a few examples where the model
>> of trying to cram it into the bridge API is just a bad fit in general.
>
> Sorry Felix, nothing you described is insurmountable.
I'm not saying it's insurmountable, I'm saying it's impractical!
It makes one aspect (code reuse) better in some cases, while making lots
of other aspects worse.
> The challenge here is non-technical:
> You already have code that has been proven and is deployed for what
> appears to be sometime now.
> I totally empathize.
Please stop making it look like this is the primary issue. Sure, it's
more convenient for us to reuse the existing code, but it's far from
being the only important factor here!
As an embedded Linux developer, I care a lot about fighting complexity
and bloat, and those do tend to be much harder to deal with than a bit
of API consistency.
I get the sense that trying to communicate on an abstract level gets us
nowhere in this discussion, so let me make it a bit more specific with
some examples:
One of the currently very common switches in many embedded devices is
the RTL8366/RTL8367. It has some flexibility when it comes to
configuring VLANs, and it's one of the few ones where you can configure
a forwarding table for a VLAN (which spans multiple ports), which allows
software bridging between multiple VLANs.
However, what this switch does *not* support is adding a header/trailer
to packets to indicate the originating port.
This means that all per-port netdevs will be dummy ports which don't
include the data path.
So let's say you have a configuration where you're using VLAN ID 4 on
port 1, and you want to bridge it to VLAN ID 400 on port 2.
Sounds easy enough, you can easily create a bridge that spans port1.4
and port2.400. Except, this particular switch (like pretty much any
other switch supported by swconfig) isn't actually able to handle such a
configuration on its own.
It needs two VLAN configurations, with different forwarding table IDs,
and then the software bridge on the CPU port needs to forward between
the two different VLANs.
To be able to handle such a configuration, the code would have to detect
this kind of special case scenario, somehow hook itself via rx handler
into the NIC connected to the CPU port and emulate that VLAN ID
replacement behavior.
With swconfig, you create two VLANs: VLAN 4, containing CPU and port1;
VLAN 400, containing CPU and port2. You then create a software bridge
between eth0.4 and eth0.400 (assuming eth0 is the NIC connected to the
switch).
In a different scenario, the code would also have to detect
configurations that the switch isn't able to handle, e.g.: bridging
port1.4 to eth1 and port2.4 to eth2.
Such a configuration wouldn't work at all with such a switch, because
the CPU isn't able to tell apart traffic from port1 and port2, and
there's no way to tell the switch that port1.4 and port2.4 should not be
connected to each other, but both should go to the CPU.
Those are just two simple scenarios from the top of my head - I'm pretty
sure I could come up with a long list of further corner cases and
quirks, which are simply either difficult to deal with, or completely
unnatural in the model that you're describing.
Trying to make all of these cases work in the code will make the whole
thing a lot more difficult to deal with and maintain. It will also make
it much harder for the user to figure out, what configurations work, and
what configurations don't.
Especially the case with reusing VLANs on different ports (but not
connecting them to each other) is something that can easily work with
software devices, but cannot be emulated on most embedded device
switches. The software bridge configuration model raises a lot of
expectations that these switches simply cannot meet.
If you look at the swconfig model, you will see that the abstraction
clearly communicates the limitations of these typical switches.
The configuration model simply doesn't even let you express these kinds
of unsuppported configurations that seem normal in the tools used to set
up software bridges/vlans.
At the same time, it's fairly consistent across the range of different
chips that we have drivers for. That certainly leaves a much smaller
amount of traps and surprises for users, compared to trying to emulate
the software bridge model by hacking through the layers.
Hopefully this will clear a few things up for you.
- Felix
^ permalink raw reply
* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Sebastian Reichel @ 2013-10-27 20:12 UTC (permalink / raw)
To: Alexander Shiyan
Cc: Luciano Coelho, Mark Rutland, devicetree, Russell King,
Pawel Moll, Ian Campbell, Tony Lindgren, Greg Kroah-Hartman,
Stephen Warren, linux-doc, John W. Linville, Rob Herring,
linux-kernel, Sachin Kamat, Bill Pemberton, Felipe Balbi,
Rob Landley, netdev, linux-wireless, linux-omap, linux-arm-kernel
In-Reply-To: <1382891056.102746625@f315.i.mail.ru>
[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]
On Sun, Oct 27, 2013 at 08:24:16PM +0400, Alexander Shiyan wrote:
> > Move the power GPIO handling from the board code into
> > the driver. This is a dependency for device tree support.
> >
> > Signed-off-by: Sebastian Reichel <sre@debian.org>
> > ---
> > arch/arm/mach-omap2/board-omap3pandora.c | 2 ++
> > arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++--------
> > drivers/net/wireless/ti/wl1251/sdio.c | 21 +++++++++++++-----
> > drivers/net/wireless/ti/wl1251/spi.c | 33 ++++++++++++++++++----------
> > drivers/net/wireless/ti/wl1251/wl1251.h | 2 +-
> > include/linux/wl12xx.h | 2 +-
> > 6 files changed, 43 insertions(+), 28 deletions(-)
> ...
> > diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
> > index b516b4f..a9c723b 100644
> > --- a/include/linux/wl12xx.h
> > +++ b/include/linux/wl12xx.h
> > @@ -49,7 +49,7 @@ enum {
> > };
> >
> > struct wl1251_platform_data {
> > - void (*set_power)(bool enable);
> > + int power_gpio;
> > /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
> > int irq;
> > bool use_eeprom;
> > --
>
> What a reason for not using regulator API here with GPIO-based
> regulator?
I think this pin is not used as power supply, but like an enable pin
for low power states. Of course the regulator API could still be
(mis?)used for this, but I think it would be the first linux device
driver doing this.
Note: I don't have wl1251 documentation.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: extending ndo_add_rx_vxlan_port
From: Or Gerlitz @ 2013-10-27 20:34 UTC (permalink / raw)
To: Joseph Gasparakis
Cc: Or Gerlitz, John Fastabend, Yan Burman, netdev, Stephen Hemminger
In-Reply-To: <alpine.LFD.2.03.1310271017120.19783@intel.com>
On Sun, Oct 27, 2013 at 7:25 PM, Joseph Gasparakis
<joseph.gasparakis@intel.com> wrote:
>
>
> On Sun, 27 Oct 2013, Or Gerlitz wrote:
>
>> Hi,
>>
>> So with commit 53cf527513eed6e7170e9dceacd198f9267171b0 "vxlan: Notify drivers
>> for listening UDP port changes" drivers that have HW offloads for vxlan can be
>> notified on which UDP port to listen. Taking this further, some HW may need to
>> know the multicast address and/or the VNID used by the vxlan instance/s set
>> above them. In that respect, do we prefer to extend ndo_add_rx_vxlan_port() or
>> introduce new ndo?
>>
>> Or.
>>
>
> The way this patch works is to notify the drivers when a VXLAN UDP port
> comes up or down. This way drivers do not need to do any sort of accounting. As
Could you elaborate why do we want to notify all the netdev instances
in the system (on a certain name-space)
that vxlan instance/s are set to listen on certain UDP port and not
only the device over which the
vxlan device is being set? say the HW can listen limited amount of UDP
ports and few vxlan instances are created
one of top of each "real" netdev in the system and each on different
port. Each netdevice will get all callbacks on port addition
and at some point will start to fail adding them into the HW when the
HW limit is met.
Or.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-27 20:37 UTC (permalink / raw)
To: dingtianhong; +Cc: fubar, andy, nikolay, vfalico, netdev
In-Reply-To: <52688F33.30904@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Thu, 24 Oct 2013 11:08:35 +0800
> The slave list will add and del by bond_master_upper_dev_link() and bond_upper_dev_unlink(),
> which will call call_netdevice_notifiers(), even it is safe to call it in write bond lock now,
> but we can't sure that whether it is safe later, because other drivers may deal NETDEV_CHANGEUPPER
> in sleep way, so I didn't admit move the bond_upper_dev_unlink() in write bond lock.
>
> now the bond_for_each_slave only protect by rtnl_lock(), maybe use bond_for_each_slave_rcu is a good
> way to protect slave list for bond, but as a system slow path, it is no need to transform bond_for_each_slave()
> to bond_for_each_slave_rcu() in slow path, so in the patchset, I will remove the unused read bond lock
> for monitor function, maybe it is a better way, I will wait to accept any relay for it.
>
> Thanks for the Veaceslav Falico opinion.
>
> v2: add and modify commit for patchset and patch, it will be the first step for the whole patchset.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] net_sched: Remove broken tc actions
From: Alexander Duyck @ 2013-10-27 20:37 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Eric W. Biederman, David Miller, netdev, alexander.h.duyck
In-Reply-To: <526D463E.6040000@mojatatu.com>
On 10/27/2013 09:58 AM, Jamal Hadi Salim wrote:
> On 10/27/13 09:40, Eric W. Biederman wrote:
>>
>> While auditing the code to make certain it would be safe to enable the
>> user namespace root to use tc actions I stumbled on the strange fact
>> that two of the tc modules in the kernel have been broken for more
>> years than I care to think about.
>>
>> In particular neither of these two modules implements the tc_action_ops
>> lookup method. Which means that in practice neither RTM_GETACTION nor
>> RTM_DELACTION work. And with RTM_DELACTION broken that looks like a
>> permanent leak of kernel memory to me.
>>
>>
>> A leak I am not happy at root having and certainly not something I want
>> to allow unprivileged users access to.
>>
>> On the premise that 5+ years is too long to wait for someone to notice,
>> complain and get this code fixed let's just remove these broken tc
>> modules.
>>
>
>
> Nah, dude.
> You dont have to implement the get/del. Actions are typically bound
> to filters; when the filters disappears the action is destroyed.
> You Get the filter, you Get the bound actions.
> you can add actions without filters - but in such a case, for both
> of these ones you picked, you can dump or flush them unless they are
> bound to a filter. Thats the minimal requirement (which is met).
>
> What is your use case to need explicit get/del?
> Given act_simple is pedagogical in nature, I think
> that will be useful for illustration purposes.
>
> cheers,
> jamal
The primary use case for act_skbedit was to have it associated with a
filter. I based it off of act_simple so it isn't surprising that it
inherited this issue.
>From what I can tell all of the other actions are just using
tcf_hash_search for lookup. Is there anything special that is needed in
order to add the lookup call, or could we just add a one liner
associating simple and skbedit lookup with tcf_hash_search?
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH net v4] be2net: Warn users of possible broken functionality on BE2 cards with very old FW versions with latest driver
From: David Miller @ 2013-10-27 20:38 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev
In-Reply-To: <62f97dab-6b78-43bd-9b77-36c7f0dcdbf8@CMEXHTCAS1.ad.emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Thu, 24 Oct 2013 14:37:53 +0530
> On very old FW versions < 4.0, the mailbox command to set interrupts
> on the card succeeds even though it is not supported and should have
> failed, leading to a scenario where interrupts do not work.
> Hence warn users to upgrade to a suitable FW version to avoid seeing
> broken functionality.
>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown
From: Linus Torvalds @ 2013-10-27 20:39 UTC (permalink / raw)
To: Thomas Gleixner, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David Miller
Cc: Knut Petersen, Ingo Molnar, Paul McKenney,
Frédéric Weisbecker, Greg KH, linux-kernel,
Network Development, netfilter-devel
In-Reply-To: <CA+55aFyb72qoZ1Tjpb+=q-6+GmwoOXjfntY_zZnf300gg3d1Hg@mail.gmail.com>
On Sun, Oct 27, 2013 at 8:20 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Appended is a warning I get with DEBUG_TIMER_OBJECTS. Seems to be a
> device-mapper issue.
.. and here's another one. This time it looks like nf_conntrack_free()
is freeing something that has a delayed work in it (again, likely an
embedded 'struct kobject'). Looks like it is the
kmem_cache_destroy(net->ct.nf_conntrack_cachep);
that triggers this. Which probably means that there are still slab
entries on that slab cache or something, but I didn't dig any deeper..
David? Patrick? Pablo? Jozsef? Any ideas? This was immediately preceded by
[ 1136.316280] kobject: 'nf_conntrack_ffff8800b74d0000'
(ffff8801196fac78): kobject_uevent_env
[ 1136.316287] kobject: 'nf_conntrack_ffff8800b74d0000'
(ffff8801196fac78): fill_kobj_path: path =
'/kernel/slab/nf_conntrack_ffff8800b74d0000'
[ 1136.316331] kobject: 'nf_conntrack_ffff8800b74d0000'
(ffff8801196fac78): kobject_release, parent (null) (delayed)
and I think it's that delayed "kobject_release()" that triggers this.
Notice that kobject_release() can be delayed *without* the magic
kobject debugging option by simply having a reference count on it from
some external source. So this particular issue is probably triggered
by my extra debug options in this case (I'm running with all those
nasty "try to find bad object freeing" options, and doing module
unloading etc), but can happen without it (it's just very hard to
trigger in practice without the debug options).
Linus
---
[ 1136.321294] ------------[ cut here ]------------
[ 1136.321305] WARNING: CPU: 2 PID: 2483 at lib/debugobjects.c:260
debug_print_object+0x83/0xa0()
[ 1136.321311] ODEBUG: free active (active state 0) object type:
timer_list hint: delayed_work_timer_fn+0x0/0x20
[ 1136.321313] Modules linked in: fuse nf_conntrack_netbios_ns
nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_conntrack bnep
bluetooth ebtable_nat ebt
[ 1136.321357] mfd_core mei snd_page_alloc snd_timer snd soundcore
sony_laptop rfkill uinput dm_crypt crc32_pclmul crc32c_intel i915
i2c_algo_bit drm_kms_h
[ 1136.321371] CPU: 2 PID: 2483 Comm: kworker/u8:2 Tainted: G W
3.12.0-rc6-00331-ga2ff82065b5b #2
[ 1136.321373] Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS
R0270V7 05/17/2013
[ 1136.321378] Workqueue: netns cleanup_net
[ 1136.321380] 0000000000000009 ffff8800a86cdbc8 ffffffff8160d4a2
ffff8800a86cdc10
[ 1136.321384] ffff8800a86cdc00 ffffffff810514e8 ffff8800b745f848
ffffffff81c365e0
[ 1136.321387] ffffffff819f9133 ffffffff81f34750 0000000000000001
ffff8800a86cdc60
[ 1136.321390] Call Trace:
[ 1136.321398] [<ffffffff8160d4a2>] dump_stack+0x45/0x56
[ 1136.321405] [<ffffffff810514e8>] warn_slowpath_common+0x78/0xa0
[ 1136.321410] [<ffffffff81051557>] warn_slowpath_fmt+0x47/0x50
[ 1136.321414] [<ffffffff812f8883>] debug_print_object+0x83/0xa0
[ 1136.321420] [<ffffffff8106aa90>] ? execute_in_process_context+0x90/0x90
[ 1136.321424] [<ffffffff812f99fb>] debug_check_no_obj_freed+0x20b/0x250
[ 1136.321429] [<ffffffff8112e7f2>] ? kmem_cache_destroy+0x92/0x100
[ 1136.321433] [<ffffffff8115d945>] kmem_cache_free+0x125/0x210
[ 1136.321436] [<ffffffff8112e7f2>] kmem_cache_destroy+0x92/0x100
[ 1136.321443] [<ffffffffa046b806>]
nf_conntrack_cleanup_net_list+0x126/0x160 [nf_conntrack]
[ 1136.321449] [<ffffffffa046c43d>]
nf_conntrack_pernet_exit+0x6d/0x80 [nf_conntrack]
[ 1136.321453] [<ffffffff81511cc3>] ops_exit_list.isra.3+0x53/0x60
[ 1136.321457] [<ffffffff815124f0>] cleanup_net+0x100/0x1b0
[ 1136.321460] [<ffffffff8106b31e>] process_one_work+0x18e/0x430
[ 1136.321463] [<ffffffff8106bf49>] worker_thread+0x119/0x390
[ 1136.321467] [<ffffffff8106be30>] ? manage_workers.isra.23+0x2a0/0x2a0
[ 1136.321470] [<ffffffff8107210b>] kthread+0xbb/0xc0
[ 1136.321472] [<ffffffff81072050>] ? kthread_create_on_node+0x110/0x110
[ 1136.321477] [<ffffffff8161b8fc>] ret_from_fork+0x7c/0xb0
[ 1136.321479] [<ffffffff81072050>] ? kthread_create_on_node+0x110/0x110
[ 1136.321481] ---[ end trace 25f53c192da70825 ]---
^ permalink raw reply
* Re: [PATCH net] tcp: fix SYNACK RTT estimation in Fast Open
From: David Miller @ 2013-10-27 20:51 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, panweiping3, netdev
In-Reply-To: <1382629465-20310-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 24 Oct 2013 08:44:25 -0700
> tp->lsndtime may not always be the SYNACK timestamp if a passive
> Fast Open socket sends data before handshake completes. And if the
> remote acknowledges both the data and the SYNACK, the RTT sample
> is already taken in tcp_ack(), so no need to call
> tcp_update_ack_rtt() in tcp_synack_rtt_meas() aagain.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] tcp: fix SYNACK RTT estimation in Fast Open
From: David Miller @ 2013-10-27 20:51 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, panweiping3, netdev
In-Reply-To: <1382629465-20310-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 24 Oct 2013 08:44:25 -0700
> tp->lsndtime may not always be the SYNACK timestamp if a passive
> Fast Open socket sends data before handshake completes. And if the
> remote acknowledges both the data and the SYNACK, the RTT sample
> is already taken in tcp_ack(), so no need to call
> tcp_update_ack_rtt() in tcp_synack_rtt_meas() aagain.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] tcp: only take RTT from timestamps if new data is acked
From: David Miller @ 2013-10-27 20:51 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, netdev
In-Reply-To: <1382630125-21416-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 24 Oct 2013 08:55:25 -0700
> Patch ed08495c3 "tcp: use RTT from SACK for RTO" has a bug that
> it does not check if the ACK acknowledge new data before taking
> the RTT sample from TCP timestamps. This patch adds the check
> back as required by the RFC.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] tcp: do not rearm RTO when future data are sacked
From: David Miller @ 2013-10-27 20:52 UTC (permalink / raw)
To: ycheng; +Cc: ncardwell, edumazet, brakmo, netdev
In-Reply-To: <1382630367-21964-1-git-send-email-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 24 Oct 2013 08:59:27 -0700
> Patch ed08495c3 "tcp: use RTT from SACK for RTO" always re-arms RTO upon
> obtaining a RTT sample from newly sacked data.
>
> But technically RTO should only be re-armed when the data sent before
> the last (re)transmission of write queue head are (s)acked. Otherwise
> the RTO may continue to extend during loss recovery on data sent
> in the future.
>
> Note that RTTs from ACK or timestamps do not have this problem, as the RTT
> source must be from data sent before.
>
> The new RTO re-arm policy is
> 1) Always re-arm RTO if SND.UNA is advanced
> 2) Re-arm RTO if sack RTT is available, provided the sacked data was
> sent before the last time write_queue_head was sent.
>
> Signed-off-by: Larry Brakmo <brakmo@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Also applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] pkt_sched: fq: clear time_next_packet for reused flows
From: David Miller @ 2013-10-27 20:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1382612508.7572.53.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 24 Oct 2013 04:01:48 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> When a socket is freed/reallocated, we need to clear time_next_packet
> or else we can inherit a prior value and delay first packets of the
> new flow.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Eric this has been mangled by your email client, please fix.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox