* Re: [PATCH 03/16] wl1251: add sysfs interface for bluetooth coexistence mode configuration
From: Ben Hutchings @ 2013-10-28 23:39 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen, David Gnedt
In-Reply-To: <1382819655-30430-4-git-send-email-pali.rohar@gmail.com>
On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> From: David Gnedt <david.gnedt@davizone.at>
>
> Port the bt_coex_mode sysfs interface from wl1251 driver version included
> in the Maemo Fremantle kernel to allow bt-coexistence mode configuration.
> This enables userspace applications to set one of the modes
> WL1251_BT_COEX_OFF, WL1251_BT_COEX_ENABLE and WL1251_BT_COEX_MONOAUDIO.
> The default mode is WL1251_BT_COEX_OFF.
> It should be noted that this driver always enabled bt-coexistence before
> and enabled bt-coexistence directly affects the receiving performance,
> rendering it unusable in some low-signal situations. Especially monitor
> mode is affected very badly with bt-coexistence enabled.
[...]
This should be implemented consistently with other drivers:
drivers/net/wireless/ath/ath9k/htc_drv_init.c:module_param_named(btcoex_enable, ath9k_htc_btcoex_enable, int, 0444);
drivers/net/wireless/ath/ath9k/init.c:module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
drivers/net/wireless/b43/main.c:module_param_named(btcoex, modparam_btcoex, int, 0444);
drivers/net/wireless/ipw2x00/ipw2200.c:module_param(bt_coexist, int, 0444);
drivers/net/wireless/iwlegacy/common.c:module_param(bt_coex_active, bool, S_IRUGO);
drivers/net/wireless/iwlwifi/iwl-drv.c:module_param_named(bt_coex_active, iwlwifi_mod_params.bt_coex_active,
drivers/net/wireless/ti/wlcore/sysfs.c:static DEVICE_ATTR(bt_coex_state, S_IRUGO | S_IWUSR,
Oh, hmm, I see a problem here.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Laurent Pinchart @ 2013-10-28 23:46 UTC (permalink / raw)
To: linux-sh
Cc: linux-fbdev, Wolfram Sang, Linus Walleij, Guennadi Liakhovetski,
Thierry Reding, linux-mtd, linux-i2c, Vinod Koul, Joerg Roedel,
Magnus Damm, Eduardo Valentin, Tomi Valkeinen, linux-serial,
linux-input, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard, linux-media, linux-pwm,
Samuel Ortiz, linux-pm, Ian Molton, Mark Brown, linux-arm-kernel,
Sergei Shtylyov <sergei.shtyly
Hello,
This patch series, based on v3.12-rc7, prepares various Renesas drivers
for migration to multiplatform kernels by enabling their compilation or
otherwise fixing them on all ARM platforms. The patches are pretty
straightforward and are described in their commit message.
I'd like to get all these patches merged in v3.14. As they will need to go
through their respective subsystems' trees, I would appreciate if all
maintainers involved could notify me when they merge patches from this series
in their tree to help me tracking the merge status. I don't plan to send pull
requests individually for these patches, and I will repost patches
individually if changes are requested during review.
If you believe the issue should be solved in a different way (for instance by
removing the architecture dependency completely) please reply to the cover
letter to let other maintainers chime in.
Cc: Chris Ball <cjb@laptop.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: dmaengine@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: iommu@lists.linux-foundation.org
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-pm@vger.kernel.org
Cc: linux-pwm@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: netdev@vger.kernel.org
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Laurent Pinchart (19):
serial: sh-sci: Enable the driver on all ARM platforms
DMA: shdma: Enable the driver on all ARM platforms
i2c: sh_mobile: Enable the driver on all ARM platforms
input: sh_keysc: Enable the driver on all ARM platforms
iommu: shmobile: Enable the driver on all ARM platforms
i2c: rcar: Enable the driver on all ARM platforms
v4l: sh_vou: Enable the driver on all ARM platforms
mmc: sdhi: Enable the driver on all ARM platforms
mmc: sh_mmcif: Enable the driver on all ARM platforms
mtd: sh_flctl: Enable the driver on all ARM platforms
net: sh_eth: Set receive alignment correctly on all ARM platforms
irda: sh_irda: Enable the driver on all ARM platforms
pinctrl: sh-pfc: Enable the driver on all ARM platforms
pwm: pwm-renesas-tpu: Enable the driver on all ARM platforms
sh: intc: Enable the driver on all ARM platforms
spi: sh_msiof: Enable the driver on all ARM platforms
spi: sh_hspi: Enable the driver on all ARM platforms
thermal: rcar-thermal: Enable the driver on all ARM platforms
fbdev: sh-mobile-lcdcfb: Enable the driver on all ARM platforms
drivers/dma/sh/Kconfig | 2 +-
drivers/dma/sh/shdmac.c | 6 +++---
drivers/i2c/busses/Kconfig | 4 ++--
drivers/input/keyboard/Kconfig | 2 +-
drivers/iommu/Kconfig | 2 +-
drivers/media/platform/Kconfig | 2 +-
drivers/mmc/host/Kconfig | 4 ++--
drivers/mmc/host/tmio_mmc_dma.c | 2 +-
drivers/mtd/nand/Kconfig | 2 +-
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
drivers/net/irda/Kconfig | 2 +-
drivers/pinctrl/Makefile | 2 +-
drivers/pinctrl/sh-pfc/Kconfig | 2 +-
drivers/pwm/Kconfig | 2 +-
drivers/sh/intc/Kconfig | 2 +-
drivers/spi/Kconfig | 4 ++--
drivers/thermal/Kconfig | 2 +-
drivers/tty/serial/Kconfig | 2 +-
drivers/video/Kconfig | 6 +++---
20 files changed, 27 insertions(+), 27 deletions(-)
--
Regards,
Laurent Pinchart
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH 11/19] net: sh_eth: Set receive alignment correctly on all ARM platforms
From: Laurent Pinchart @ 2013-10-28 23:46 UTC (permalink / raw)
To: linux-sh; +Cc: linux-arm-kernel, David S. Miller, Sergei Shtylyov, netdev
In-Reply-To: <1383004027-25036-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Renesas ARM platforms are transitioning from single-platform to
multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Configure the
receive alignement correctly on all ARM platforms to enable the driver
on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index b57c278..990fd5b 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -809,7 +809,7 @@ out:
return ret;
}
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARM)
static void sh_eth_set_receive_align(struct sk_buff *skb)
{
int reserve;
diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
index a0db02c..41509f7 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -165,7 +165,7 @@ enum {
};
/* Driver's parameters */
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARM)
#define SH4_SKB_RX_ALIGN 32
#else
#define SH2_SH3_SKB_RX_ALIGN 2
--
1.8.1.5
^ permalink raw reply related
* [PATCH 12/19] irda: sh_irda: Enable the driver on all ARM platforms
From: Laurent Pinchart @ 2013-10-28 23:47 UTC (permalink / raw)
To: linux-sh; +Cc: linux-arm-kernel, Samuel Ortiz, netdev
In-Reply-To: <1383004027-25036-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Renesas ARM platforms are transitioning from single-platform to
multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
and ARCH_SHMOBILE_MULTI and increase build testing coverage.
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: netdev@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/net/irda/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
index 2a30193..54b4101 100644
--- a/drivers/net/irda/Kconfig
+++ b/drivers/net/irda/Kconfig
@@ -403,7 +403,7 @@ config MCS_FIR
config SH_IRDA
tristate "SuperH IrDA driver"
- depends on IRDA && ARCH_SHMOBILE
+ depends on IRDA && ARM
help
Say Y here if your want to enable SuperH IrDA devices.
--
1.8.1.5
^ 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-28 23:48 UTC (permalink / raw)
To: Dan Williams
Cc: David Miller, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji,
kaber, thaller, stephen
In-Reply-To: <1383002179.28991.14.camel@dcbw.foobar.com>
On Mon, Oct 28, 2013 at 06:16:19PM -0500, Dan Williams wrote:
> On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> > From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Date: Sun, 27 Oct 2013 17:48:35 +0100
> >
> > > 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.
> >
> > How much really needs to be in userspace to implement RFC4941?
> >
> > I don't like the idea that even for a fully up and properly
> > functioning link, if NetworkManager wedges then critical things like
> > temporary address (re-)generation, will cease.
>
> Honestly, I'd be completely happy to leave temporary address handling up
> to the kernel and *not* do it in userspace; the kernel already has all
> the code. There are two problems with that though, (a) it's tied to
> in-kernel RA handling, and (b) it's controlled by a CONFIG option. Both
> these are solvable.
Ah, (a) does complicate things, I agree. But the tieing is essential
currently. So it seems a netlink interface would be needed to tie a new
address to an already installed one, if the kernel should still deal
with the regeneration?
> First off, what's the reasoning behind having IPv6 privacy as a config
> option? It's off-by-default and must be explicitly turned on, so is
> there any harm in removing the config? Or is it just for
> smallest-kernel-ever folks?
I don't know about the policy. Does it really matter as distributions
normally switch it on? But I would not like to see the option removed
entirly, maybe the default could be changed.
> Would a new IFA_F_MANAGE_TEMP (or better name) work here, indicating
> that for some new static address, that the kernel should create and
> manage the temporary privacy addresses associated with its prefix?
But this would only be needed if they were managed in user-space, no?
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] 6lowpan: trivial changes
From: David Miller @ 2013-10-28 23:48 UTC (permalink / raw)
To: alex.aring
Cc: alex.bluesman.smirnov, linux-zigbee-devel, werner, dbaryshkov,
netdev
In-Reply-To: <1382952260-23174-1-git-send-email-alex.aring@gmail.com>
From: Alexander Aring <alex.aring@gmail.com>
Date: Mon, 28 Oct 2013 10:24:15 +0100
> This patch series includes some trivial changes to prepare the 6lowpan stack
> for upcomming patch-series which mainly fix fragmentation according to rfc4944
> and udp handling(which is currently broken).
>
> Changes since v3:
> - really fix intendation in patch 3/5
>
> Changes since v2:
> - change intendation in patch 3/5
> - fix typo in 5/5 unecessary -> unnecessary
> - add missing 6lowpan tag in cover-letter
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Ben Hutchings @ 2013-10-28 23:50 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen
In-Reply-To: <1382819655-30430-17-git-send-email-pali.rohar@gmail.com>
On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> Driver wl1251 generating mac address randomly at startup and there is no way to
> set permanent mac address via SET_IEEE80211_PERM_ADDR. This patch export sysfs
> file which can set permanent mac address by userspace helper program. Patch is
> needed for devices which do not store mac address in internal wl1251 eeprom.
[...]
This belongs in struct wl12xx_platform_data or (better) Device Tree
properties. It definitely should not be settable once the device is
registered.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
From: Ben Hutchings @ 2013-10-29 0:07 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, Mark Cave-Ayland, netdev, Stable
In-Reply-To: <1383002903-8746-1-git-send-email-Larry.Finger@lwfinger.net>
On Mon, 2013-10-28 at 18:28 -0500, Larry Finger wrote:
> From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>
> All of the rtlwifi drivers have an error in the routine that tests if
> the received data is "special". The 16-bit quantity is big-endian, but
> was being extracted in native CPU mode. One of the effects of this bug
> is to inhibit association under some conditions.
>
> A statement that would have made the code correct had been changed to
> a comment. Rather than just reinstating that code, the fix here passes
> sparse tests.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> Cc: Stable <stable@vger.kernel.org> [2.6.38+]
> ---
> drivers/net/wireless/rtlwifi/base.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
> index 9a78e3d..1efde7f 100644
> --- a/drivers/net/wireless/rtlwifi/base.c
> +++ b/drivers/net/wireless/rtlwifi/base.c
> @@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
>
> ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
> SNAP_SIZE + PROTOC_TYPE_SIZE);
> - ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
> - /* ether_type = ntohs(ether_type); */
> + ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
> + SNAP_SIZE));
>
> if (ETH_P_IP == ether_type) {
> if (IPPROTO_UDP == ip->protocol) {
This crazy function also says that *all* IPv6 frames are special, which
apparently means that on TX they should get sent at the lowest possible
bit rate. So I think this is going to cause a regression for IPv6
throughput unless you remove that case.
The DHCP case is also not validating IP and UDP header lengths against
the packet length, though this may be harmless in practice.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-29 0:08 UTC (permalink / raw)
To: dcbw
Cc: hannes, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <1383002179.28991.14.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Mon, 28 Oct 2013 18:16:19 -0500
> On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> First off, what's the reasoning behind having IPv6 privacy as a config
> option? It's off-by-default and must be explicitly turned on, so is
> there any harm in removing the config? Or is it just for
> smallest-kernel-ever folks?
I think it's for "smallest kernel ever" stuff. Even every arch
defconfig that mentions it has it enabled :-)
Maybe it was optional initially because the code was new and
experimental'ish. I don't know.
Regardless of the reason I think it only obfuscates the code with
ifdefs right now and I would be happy to see it disappear.
Any objections to this patch?
====================
[PATCH] ipv6: Remove privacy config option.
The code for privacy extentions is very mature, and making it
configurable only gives marginal memory/code savings in exchange
for obfuscation and hard to read code via CPP ifdef'ery.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/ipv6.h | 2 --
include/net/if_inet6.h | 5 +----
net/ipv6/Kconfig | 18 ------------------
net/ipv6/addrconf.c | 41 +++--------------------------------------
4 files changed, 4 insertions(+), 62 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index a80a63c..5d89d1b 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -21,13 +21,11 @@ struct ipv6_devconf {
__s32 force_mld_version;
__s32 mldv1_unsolicited_report_interval;
__s32 mldv2_unsolicited_report_interval;
-#ifdef CONFIG_IPV6_PRIVACY
__s32 use_tempaddr;
__s32 temp_valid_lft;
__s32 temp_prefered_lft;
__s32 regen_max_retry;
__s32 max_desync_factor;
-#endif
__s32 max_addresses;
__s32 accept_ra_defrtr;
__s32 accept_ra_pinfo;
diff --git a/include/net/if_inet6.h b/include/net/if_inet6.h
index 02ef772..76d5427 100644
--- a/include/net/if_inet6.h
+++ b/include/net/if_inet6.h
@@ -66,11 +66,10 @@ struct inet6_ifaddr {
struct hlist_node addr_lst;
struct list_head if_list;
-#ifdef CONFIG_IPV6_PRIVACY
struct list_head tmp_list;
struct inet6_ifaddr *ifpub;
int regen_count;
-#endif
+
bool tokenized;
struct rcu_head rcu;
@@ -192,11 +191,9 @@ struct inet6_dev {
__u32 if_flags;
int dead;
-#ifdef CONFIG_IPV6_PRIVACY
u8 rndid[8];
struct timer_list regen_timer;
struct list_head tempaddr_list;
-#endif
struct in6_addr token;
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index e1a8d90..d92e558 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -21,24 +21,6 @@ menuconfig IPV6
if IPV6
-config IPV6_PRIVACY
- bool "IPv6: Privacy Extensions (RFC 3041) support"
- ---help---
- Privacy Extensions for Stateless Address Autoconfiguration in IPv6
- support. With this option, additional periodically-altered
- pseudo-random global-scope unicast address(es) will be assigned to
- your interface(s).
-
- We use our standard pseudo-random algorithm to generate the
- randomized interface identifier, instead of one described in RFC 3041.
-
- By default the kernel does not generate temporary addresses.
- To use temporary addresses, do
-
- echo 2 >/proc/sys/net/ipv6/conf/all/use_tempaddr
-
- See <file:Documentation/networking/ip-sysctl.txt> for details.
-
config IPV6_ROUTER_PREF
bool "IPv6: Router Preference (RFC 4191) support"
---help---
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cd3fb30..542d095 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -83,11 +83,7 @@
#include <linux/if_tunnel.h>
#include <linux/rtnetlink.h>
#include <linux/netconf.h>
-
-#ifdef CONFIG_IPV6_PRIVACY
#include <linux/random.h>
-#endif
-
#include <linux/uaccess.h>
#include <asm/unaligned.h>
@@ -124,11 +120,9 @@ static inline void addrconf_sysctl_unregister(struct inet6_dev *idev)
}
#endif
-#ifdef CONFIG_IPV6_PRIVACY
static void __ipv6_regen_rndid(struct inet6_dev *idev);
static void __ipv6_try_regen_rndid(struct inet6_dev *idev, struct in6_addr *tmpaddr);
static void ipv6_regen_rndid(unsigned long data);
-#endif
static int ipv6_generate_eui64(u8 *eui, struct net_device *dev);
static int ipv6_count_addresses(struct inet6_dev *idev);
@@ -183,13 +177,11 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
.rtr_solicits = MAX_RTR_SOLICITATIONS,
.rtr_solicit_interval = RTR_SOLICITATION_INTERVAL,
.rtr_solicit_delay = MAX_RTR_SOLICITATION_DELAY,
-#ifdef CONFIG_IPV6_PRIVACY
.use_tempaddr = 0,
.temp_valid_lft = TEMP_VALID_LIFETIME,
.temp_prefered_lft = TEMP_PREFERRED_LIFETIME,
.regen_max_retry = REGEN_MAX_RETRY,
.max_desync_factor = MAX_DESYNC_FACTOR,
-#endif
.max_addresses = IPV6_MAX_ADDRESSES,
.accept_ra_defrtr = 1,
.accept_ra_pinfo = 1,
@@ -221,13 +213,11 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
.rtr_solicits = MAX_RTR_SOLICITATIONS,
.rtr_solicit_interval = RTR_SOLICITATION_INTERVAL,
.rtr_solicit_delay = MAX_RTR_SOLICITATION_DELAY,
-#ifdef CONFIG_IPV6_PRIVACY
.use_tempaddr = 0,
.temp_valid_lft = TEMP_VALID_LIFETIME,
.temp_prefered_lft = TEMP_PREFERRED_LIFETIME,
.regen_max_retry = REGEN_MAX_RETRY,
.max_desync_factor = MAX_DESYNC_FACTOR,
-#endif
.max_addresses = IPV6_MAX_ADDRESSES,
.accept_ra_defrtr = 1,
.accept_ra_pinfo = 1,
@@ -371,7 +361,6 @@ static struct inet6_dev *ipv6_add_dev(struct net_device *dev)
}
#endif
-#ifdef CONFIG_IPV6_PRIVACY
INIT_LIST_HEAD(&ndev->tempaddr_list);
setup_timer(&ndev->regen_timer, ipv6_regen_rndid, (unsigned long)ndev);
if ((dev->flags&IFF_LOOPBACK) ||
@@ -384,7 +373,7 @@ static struct inet6_dev *ipv6_add_dev(struct net_device *dev)
in6_dev_hold(ndev);
ipv6_regen_rndid((unsigned long) ndev);
}
-#endif
+
ndev->token = in6addr_any;
if (netif_running(dev) && addrconf_qdisc_ok(dev))
@@ -865,12 +854,10 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr,
/* Add to inet6_dev unicast addr list. */
ipv6_link_dev_addr(idev, ifa);
-#ifdef CONFIG_IPV6_PRIVACY
if (ifa->flags&IFA_F_TEMPORARY) {
list_add(&ifa->tmp_list, &idev->tempaddr_list);
in6_ifa_hold(ifa);
}
-#endif
in6_ifa_hold(ifa);
write_unlock(&idev->lock);
@@ -913,7 +900,7 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
spin_unlock_bh(&addrconf_hash_lock);
write_lock_bh(&idev->lock);
-#ifdef CONFIG_IPV6_PRIVACY
+
if (ifp->flags&IFA_F_TEMPORARY) {
list_del(&ifp->tmp_list);
if (ifp->ifpub) {
@@ -922,7 +909,6 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)
}
__in6_ifa_put(ifp);
}
-#endif
list_for_each_entry_safe(ifa, ifn, &idev->addr_list, if_list) {
if (ifa == ifp) {
@@ -1013,7 +999,6 @@ out:
in6_ifa_put(ifp);
}
-#ifdef CONFIG_IPV6_PRIVACY
static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp, struct inet6_ifaddr *ift)
{
struct inet6_dev *idev = ifp->idev;
@@ -1116,7 +1101,6 @@ retry:
out:
return ret;
}
-#endif
/*
* Choose an appropriate source address (RFC3484)
@@ -1131,9 +1115,7 @@ enum {
#endif
IPV6_SADDR_RULE_OIF,
IPV6_SADDR_RULE_LABEL,
-#ifdef CONFIG_IPV6_PRIVACY
IPV6_SADDR_RULE_PRIVACY,
-#endif
IPV6_SADDR_RULE_ORCHID,
IPV6_SADDR_RULE_PREFIX,
IPV6_SADDR_RULE_MAX
@@ -1247,7 +1229,6 @@ static int ipv6_get_saddr_eval(struct net *net,
&score->ifa->addr, score->addr_type,
score->ifa->idev->dev->ifindex) == dst->label;
break;
-#ifdef CONFIG_IPV6_PRIVACY
case IPV6_SADDR_RULE_PRIVACY:
{
/* Rule 7: Prefer public address
@@ -1259,7 +1240,6 @@ static int ipv6_get_saddr_eval(struct net *net,
ret = (!(score->ifa->flags & IFA_F_TEMPORARY)) ^ preftmp;
break;
}
-#endif
case IPV6_SADDR_RULE_ORCHID:
/* Rule 8-: Prefer ORCHID vs ORCHID or
* non-ORCHID vs non-ORCHID
@@ -1588,7 +1568,6 @@ static void addrconf_dad_stop(struct inet6_ifaddr *ifp, int dad_failed)
if (dad_failed)
ipv6_ifa_notify(0, ifp);
in6_ifa_put(ifp);
-#ifdef CONFIG_IPV6_PRIVACY
} else if (ifp->flags&IFA_F_TEMPORARY) {
struct inet6_ifaddr *ifpub;
spin_lock_bh(&ifp->lock);
@@ -1602,7 +1581,6 @@ static void addrconf_dad_stop(struct inet6_ifaddr *ifp, int dad_failed)
spin_unlock_bh(&ifp->lock);
}
ipv6_del_addr(ifp);
-#endif
} else
ipv6_del_addr(ifp);
}
@@ -1851,7 +1829,6 @@ static int ipv6_inherit_eui64(u8 *eui, struct inet6_dev *idev)
return err;
}
-#ifdef CONFIG_IPV6_PRIVACY
/* (re)generation of randomized interface identifier (RFC 3041 3.2, 3.5) */
static void __ipv6_regen_rndid(struct inet6_dev *idev)
{
@@ -1919,7 +1896,6 @@ static void __ipv6_try_regen_rndid(struct inet6_dev *idev, struct in6_addr *tmp
if (tmpaddr && memcmp(idev->rndid, &tmpaddr->s6_addr[8], 8) == 0)
__ipv6_regen_rndid(idev);
}
-#endif
/*
* Add prefix route.
@@ -2207,9 +2183,7 @@ ok:
if (ifp) {
int flags;
unsigned long now;
-#ifdef CONFIG_IPV6_PRIVACY
struct inet6_ifaddr *ift;
-#endif
u32 stored_lft;
/* update lifetime (RFC2462 5.5.3 e) */
@@ -2250,7 +2224,6 @@ ok:
} else
spin_unlock(&ifp->lock);
-#ifdef CONFIG_IPV6_PRIVACY
read_lock_bh(&in6_dev->lock);
/* update all temporary addresses in the list */
list_for_each_entry(ift, &in6_dev->tempaddr_list,
@@ -2315,7 +2288,7 @@ ok:
} else {
read_unlock_bh(&in6_dev->lock);
}
-#endif
+
in6_ifa_put(ifp);
addrconf_verify(0);
}
@@ -2995,7 +2968,6 @@ static int addrconf_ifdown(struct net_device *dev, int how)
if (!how)
idev->if_flags &= ~(IF_RS_SENT|IF_RA_RCVD|IF_READY);
-#ifdef CONFIG_IPV6_PRIVACY
if (how && del_timer(&idev->regen_timer))
in6_dev_put(idev);
@@ -3015,7 +2987,6 @@ static int addrconf_ifdown(struct net_device *dev, int how)
in6_ifa_put(ifa);
write_lock_bh(&idev->lock);
}
-#endif
while (!list_empty(&idev->addr_list)) {
ifa = list_first_entry(&idev->addr_list,
@@ -3528,7 +3499,6 @@ restart:
in6_ifa_put(ifp);
goto restart;
}
-#ifdef CONFIG_IPV6_PRIVACY
} else if ((ifp->flags&IFA_F_TEMPORARY) &&
!(ifp->flags&IFA_F_TENTATIVE)) {
unsigned long regen_advance = ifp->idev->cnf.regen_max_retry *
@@ -3556,7 +3526,6 @@ restart:
} else if (time_before(ifp->tstamp + ifp->prefered_lft * HZ - regen_advance * HZ, next))
next = ifp->tstamp + ifp->prefered_lft * HZ - regen_advance * HZ;
spin_unlock(&ifp->lock);
-#endif
} else {
/* ifp->prefered_lft <= ifp->valid_lft */
if (time_before(ifp->tstamp + ifp->prefered_lft * HZ, next))
@@ -4128,13 +4097,11 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
jiffies_to_msecs(cnf->mldv1_unsolicited_report_interval);
array[DEVCONF_MLDV2_UNSOLICITED_REPORT_INTERVAL] =
jiffies_to_msecs(cnf->mldv2_unsolicited_report_interval);
-#ifdef CONFIG_IPV6_PRIVACY
array[DEVCONF_USE_TEMPADDR] = cnf->use_tempaddr;
array[DEVCONF_TEMP_VALID_LFT] = cnf->temp_valid_lft;
array[DEVCONF_TEMP_PREFERED_LFT] = cnf->temp_prefered_lft;
array[DEVCONF_REGEN_MAX_RETRY] = cnf->regen_max_retry;
array[DEVCONF_MAX_DESYNC_FACTOR] = cnf->max_desync_factor;
-#endif
array[DEVCONF_MAX_ADDRESSES] = cnf->max_addresses;
array[DEVCONF_ACCEPT_RA_DEFRTR] = cnf->accept_ra_defrtr;
array[DEVCONF_ACCEPT_RA_PINFO] = cnf->accept_ra_pinfo;
@@ -4828,7 +4795,6 @@ static struct addrconf_sysctl_table
.mode = 0644,
.proc_handler = proc_dointvec_ms_jiffies,
},
-#ifdef CONFIG_IPV6_PRIVACY
{
.procname = "use_tempaddr",
.data = &ipv6_devconf.use_tempaddr,
@@ -4864,7 +4830,6 @@ static struct addrconf_sysctl_table
.mode = 0644,
.proc_handler = proc_dointvec,
},
-#endif
{
.procname = "max_addresses",
.data = &ipv6_devconf.max_addresses,
--
1.7.11.7
^ permalink raw reply related
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-29 0:12 UTC (permalink / raw)
To: dcbw
Cc: hannes, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <1383002583.28991.19.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Mon, 28 Oct 2013 18:23:03 -0500
> Except that we've run out of IFA_F_* flags already, since it's a u8 and
> there are already 8 flags. What to do?
That's not a problem, just add a new netlink attribute "extended
flags" that can be passed in with address netlink messages.
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Hannes Frederic Sowa @ 2013-10-29 0:13 UTC (permalink / raw)
To: David Miller
Cc: dcbw, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131028.200810.66180312939474324.davem@davemloft.net>
On Mon, Oct 28, 2013 at 08:08:10PM -0400, David Miller wrote:
> From: Dan Williams <dcbw@redhat.com>
> Date: Mon, 28 Oct 2013 18:16:19 -0500
>
> > On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> > First off, what's the reasoning behind having IPv6 privacy as a config
> > option? It's off-by-default and must be explicitly turned on, so is
> > there any harm in removing the config? Or is it just for
> > smallest-kernel-ever folks?
>
> I think it's for "smallest kernel ever" stuff. Even every arch
> defconfig that mentions it has it enabled :-)
>
> Maybe it was optional initially because the code was new and
> experimental'ish. I don't know.
>
> Regardless of the reason I think it only obfuscates the code with
> ifdefs right now and I would be happy to see it disappear.
>
> Any objections to this patch?
Yeah, I changed my mind. The ifdefs are really hideous. Fine for me.
Greetings,
Hannes
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-29 0:43 UTC (permalink / raw)
To: hannes
Cc: jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131028233158.GA26185@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 29 Oct 2013 00:31:58 +0100
> I wonder why NetworkManager rewrote IPv6 router discovery but not IPv4
> DHCP client stuff. It could have been a good moment to introduce something
> like PROT_DHCP sockets. Maybe it is not too late... ;)
Note that you don't even need to put the DHCP protocol core into the
kernel to fix the promiscuous problem. You just have to use the
current kernel interfaces correctly.
It used to be the case a very long time ago that you couldn't even
receive broadcast UDP datagrams on a socket until an address was
configured on it.
So everyone turns on promiscuous mode and uses RAW sockets or
AF_PACKET.
Stupid? yes.
But now the kernel will receive broadcast UDP datagrams just fine even
if there are no ipv4 addresses assigned yet.
I did a mock-up simple ipv4 DHCP client implementation just to test it
out, and it did work just fine. Unfortunately, I can't find it at the
moment, I hope I didn't just delete it in frustration. :-)
> My current idea to handle this, is that a kernel boot parameter is
> provided to stop the generation of link-local addresses and that we kick
> off address configuration from user-space at early as the secret key is
> provided, which may well be from the initramfs. I'll send a RFC as soon
> as I can find some time to clean it up and have it actually tested.
I guess I'm ok with this, as I can't come up with any reasonable
alternative scheme.
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-29 0:46 UTC (permalink / raw)
To: hannes
Cc: dcbw, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131029001340.GC26185@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 29 Oct 2013 01:13:40 +0100
> On Mon, Oct 28, 2013 at 08:08:10PM -0400, David Miller wrote:
>> From: Dan Williams <dcbw@redhat.com>
>> Date: Mon, 28 Oct 2013 18:16:19 -0500
>>
>> > On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
>> > First off, what's the reasoning behind having IPv6 privacy as a config
>> > option? It's off-by-default and must be explicitly turned on, so is
>> > there any harm in removing the config? Or is it just for
>> > smallest-kernel-ever folks?
>>
>> I think it's for "smallest kernel ever" stuff. Even every arch
>> defconfig that mentions it has it enabled :-)
>>
>> Maybe it was optional initially because the code was new and
>> experimental'ish. I don't know.
>>
>> Regardless of the reason I think it only obfuscates the code with
>> ifdefs right now and I would be happy to see it disappear.
>>
>> Any objections to this patch?
>
> Yeah, I changed my mind. The ifdefs are really hideous. Fine for me.
Ok, pushed to net-next.
^ permalink raw reply
* Re: Bug in skb_segment: fskb->len != len
From: Eric Dumazet @ 2013-10-29 1:15 UTC (permalink / raw)
To: Christoph Paasch; +Cc: Herbert Xu, netdev
In-Reply-To: <1382966471.13037.18.camel@edumazet-glaptop.roam.corp.google.com>
On Mon, 2013-10-28 at 06:21 -0700, Eric Dumazet wrote:
> But we also need to fix the skb_segment() bug anyway.
Hi Christoph
I cooked a minimal patch, could you please try it ?
I'll refactor skb_segment() to be smarter for the next release
(linux-3.14).
Thanks !
net/core/skbuff.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 0ab32faa520f..771946487a8d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2761,7 +2761,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
unsigned int len;
__be16 proto;
bool csum;
- int sg = !!(features & NETIF_F_SG);
+ bool sg = !!(features & NETIF_F_SG);
int nfrags = skb_shinfo(skb)->nr_frags;
int err = -ENOMEM;
int i = 0;
@@ -2793,7 +2793,11 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
hsize = len;
if (!hsize && i >= nfrags) {
- BUG_ON(fskb->len != len);
+ if (fskb->len != len) {
+ hsize = len;
+ sg = false;
+ goto do_linear;
+ }
pos += len;
nskb = skb_clone(fskb, GFP_ATOMIC);
@@ -2812,6 +2816,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_release_head_state(nskb);
__skb_push(nskb, doffset);
} else {
+do_linear:
nskb = __alloc_skb(hsize + doffset + headroom,
GFP_ATOMIC, skb_alloc_rx_flag(skb),
NUMA_NO_NODE);
@@ -2838,9 +2843,6 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
nskb->data - tnl_hlen,
doffset + tnl_hlen);
- if (fskb != skb_shinfo(skb)->frag_list)
- goto perform_csum_check;
-
if (!sg) {
nskb->ip_summed = CHECKSUM_NONE;
nskb->csum = skb_copy_and_csum_bits(skb, offset,
@@ -2849,6 +2851,9 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
continue;
}
+ if (fskb != skb_shinfo(skb)->frag_list)
+ goto perform_csum_check;
+
frag = skb_shinfo(nskb)->frags;
skb_copy_from_linear_data_offset(skb, offset,
^ permalink raw reply related
* [PATCH] netdev: octeon_mgmt: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 1:27 UTC (permalink / raw)
To: netdev; +Cc: david.daney, Luka Perkov
Checking if MAC address is valid using is_valid_ether_addr() is already done in
of_get_mac_address().
Signed-off-by: Luka Perkov <luka@openwrt.org>
---
drivers/net/ethernet/octeon/octeon_mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c
index 622aa75..1b326cbc 100644
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@ -1545,7 +1545,7 @@ static int octeon_mgmt_probe(struct platform_device *pdev)
mac = of_get_mac_address(pdev->dev.of_node);
- if (mac && is_valid_ether_addr(mac))
+ if (mac)
memcpy(netdev->dev_addr, mac, ETH_ALEN);
else
eth_hw_addr_random(netdev);
--
1.8.4.1
^ permalink raw reply related
* [PATCH] net: mvneta: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 1:29 UTC (permalink / raw)
To: netdev; +Cc: thomas.petazzoni, Luka Perkov
Checking if MAC address is valid using is_valid_ether_addr() is already done in
of_get_mac_address().
Signed-off-by: Luka Perkov <luka@openwrt.org>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index e35bac7..7d99e695 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2811,7 +2811,7 @@ static int mvneta_probe(struct platform_device *pdev)
}
dt_mac_addr = of_get_mac_address(dn);
- if (dt_mac_addr && is_valid_ether_addr(dt_mac_addr)) {
+ if (dt_mac_addr) {
mac_from = "device tree";
memcpy(dev->dev_addr, dt_mac_addr, ETH_ALEN);
} else {
--
1.8.4.1
^ permalink raw reply related
* [PATCH] ethernet/arc/arc_emac: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 1:32 UTC (permalink / raw)
To: netdev; +Cc: abrodkin, Luka Perkov
Checking if MAC address is valid using is_valid_ether_addr() is already done in
of_get_mac_address(). While at it, reorganize checking so it matches checks in
other drivers.
Signed-off-by: Luka Perkov <luka@openwrt.org>
---
drivers/net/ethernet/arc/emac_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index 9e16014..d818ded 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -725,10 +725,10 @@ static int arc_emac_probe(struct platform_device *pdev)
/* Get MAC address from device tree */
mac_addr = of_get_mac_address(pdev->dev.of_node);
- if (!mac_addr || !is_valid_ether_addr(mac_addr))
- eth_hw_addr_random(ndev);
- else
+ if (mac_addr)
memcpy(ndev->dev_addr, mac_addr, ETH_ALEN);
+ else
+ eth_hw_addr_random(ndev);
dev_info(&pdev->dev, "MAC address is now %pM\n", ndev->dev_addr);
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Mark Brown @ 2013-10-29 1:33 UTC (permalink / raw)
To: Grazvydas Ignotas, Alexander Shiyan, 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@vger.kernel.org, Sachin Kamat,
Bill Pemberton, Felipe Balbi, Rob Landley, netdev,
linux-wireless@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <20131028232624.GA950@earth.universe>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Tue, Oct 29, 2013 at 12:26:26AM +0100, Sebastian Reichel wrote:
> 1. The pin is named PMEN in the Nokia N900 schematics
> 2. PMEN is described as "Power management enable - system shutdown"
> in a crippled datasheet of the wl1253, which I found in the internet.
> I don't think this is supposed to be handled by the regulator API.
I agree, this sounds like a GPIO that the driver should be understanding
directly to me.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/3] tipc: message reassembly using fragment chain
From: Ying Xue @ 2013-10-29 1:56 UTC (permalink / raw)
To: Jon Maloy; +Cc: jon.maloy, netdev, tipc-discussion, David Miller
In-Reply-To: <526E3B49.9030506@donjonn.com>
On 10/28/2013 06:24 PM, Jon Maloy wrote:
> On 10/28/2013 01:07 AM, David Miller wrote:
>> From: Jon Maloy <jon.maloy@ericsson.com>
>> Date: Sat, 26 Oct 2013 14:41:02 -0400
>>
>>> + int ret = tipc_link_recv_fragment(
>>> + &node->bclink.reasm_head,
>>> + &node->bclink.reasm_tail,
>>> + &buf);
>> This is not the correct way to indent a function call that spans
>> multiple lines. In such a situation the arguments that appear
>> on the second and subsequent lines must start at the first column
>> after the openning parenthesis of the function call.
>>
>> Like this:
>>
>> func(a, b, c,
>> d, e, f);
>>
>> Please audit this in your entire set of patches and resubmit,
>> thanks.
>
> Doing as David says here means that some lines will be >80 chars.
> This was the reason for the somewhat strange indentation.
> I tried to rename the function to tipc_link_rcv_fragm(), but one
> line was still too long. The problem we have goes deeper.
>
> In Linus' coding style manual I read that the 80 char limit is a hard limit,
> a limit we violate in several places. One offender is that we have too
> many indentation levels, at least in tipc_recv_msg() and probably in
> some other places. This is sensitive code, that I don't feel for touching
> right now. A more low hanging fruit is our local variable names:
> names such as l_ptr, n_ptr, b_ptr is exactly what Linus characterizes
> as "brain dead Hungarian style", and I never liked that naming anyway.
> For me l, n, and b is good enough as long as the context is clear.
>
> But, doing so, at least in tipc_recv_msg(), would require another, separate,
> patch, and it would lead to style inconsistency.
>
> In brief, I am at loss about to proceed here, and I am not going to submit
> this patch again until I have some feedback from somebody who can tell me
> what is the right thing to do. Maybe > 80 chars is fine for now?
>
It's hard completely resolve the issue by simply changing variable
names. So in my opinion, this is not a simple code style problem any
more. As tipc_recv_msg() is too complex, it includes at least three
embedded loops so that it doesn't remain too much space for functions in
the most inner loop. This is the key point.
Therefore, the best method is to divide tipc_recv_msg() into several
smaller functions to simplify the current implementation. But it's not
an easy job. Actually I ever tried to do it, but I gave up lastly
because I did not find one perfect solution about how to divide it.
Regards,
Ying
> ///jon
>
>
>
>
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: migrate mergeable rx buffers to page frag allocators
From: Rusty Russell @ 2013-10-29 1:51 UTC (permalink / raw)
To: Michael Dalton, David S. Miller
Cc: netdev, Eric Dumazet, Michael S. Tsirkin, Daniel Borkmann,
virtualization, Michael Dalton
In-Reply-To: <1383000258-1458-1-git-send-email-mwdalton@google.com>
Michael Dalton <mwdalton@google.com> writes:
> The virtio_net driver's mergeable receive buffer allocator
> uses 4KB packet buffers. For MTU-sized traffic, SKB truesize
> is > 4KB but only ~1500 bytes of the buffer is used to store
> packet data, reducing the effective TCP window size
> substantially. This patch addresses the performance concerns
> with mergeable receive buffers by allocating MTU-sized packet
> buffers using page frag allocators. If more than MAX_SKB_FRAGS
> buffers are needed, the SKB frag_list is used.
>
> Signed-off-by: Michael Dalton <mwdalton@google.com>
Hi Michael,
Nice work! Just one comment. Your patch highlights the
anachronistic name MAX_PACKET_LEN: it was from the original
implementation which only supported 1500 byte packets, and only used in
one place.
Please apply a first patch like this, then come up with a new constant
name (GOOD_PACKET_LEN?) for that value. Because it's not the maximum
packet we can receive for mergable buffers.
Thanks,
Rusty.
Subject: virtio_net: remove anachronistic MAX_PACKET_LEN constant.
From: Rusty Russell <rusty@rustcorp.com.au>
The initial implementation of virtio_net only allowed ethernet-style
MTU packets; with more recent features this isn't true. Move the
constant into the function where it's used.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 057ea13..dcbfccd 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -35,8 +35,6 @@ static bool csum = true, gso = true;
module_param(csum, bool, 0444);
module_param(gso, bool, 0444);
-/* FIXME: MTU in config. */
-#define MAX_PACKET_LEN (ETH_HLEN + VLAN_HLEN + ETH_DATA_LEN)
#define GOOD_COPY_LEN 128
#define VIRTNET_DRIVER_VERSION "1.0.0"
@@ -434,12 +432,13 @@ static int add_recvbuf_small(struct receive_queue *rq, gfp_t gfp)
struct sk_buff *skb;
struct skb_vnet_hdr *hdr;
int err;
+ const int len = ETH_HLEN + VLAN_HLEN + ETH_DATA_LEN;
- skb = __netdev_alloc_skb_ip_align(vi->dev, MAX_PACKET_LEN, gfp);
+ skb = __netdev_alloc_skb_ip_align(vi->dev, len, gfp);
if (unlikely(!skb))
return -ENOMEM;
- skb_put(skb, MAX_PACKET_LEN);
+ skb_put(skb, len);
hdr = skb_vnet_hdr(skb);
sg_set_buf(rq->sg, &hdr->hdr, sizeof hdr->hdr);
^ permalink raw reply related
* Re: [PATCH] bridge: pass correct vlan id to multicast code
From: Amos Kong @ 2013-10-29 2:36 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, shemminger, makita.toshiaki
In-Reply-To: <1382989507-23061-1-git-send-email-vyasevic@redhat.com>
On Mon, Oct 28, 2013 at 03:45:07PM -0400, Vlad Yasevich wrote:
> Currently multicast code attempts to extrace the vlan id from
> the skb even when vlan filtering is disabled. This can lead
> to mdb entries being created with the wrong vlan id.
> Pass the already extracted vlan id to the multicast
> filtering code to make the correct id is used in
> creation as well as lookup.
Hi Vlad,
Can we just update br_vlan_get_tag() to set vid to 0 if dev->vlan is
disabled? I guess it would effect br_handle_local_finish().
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
> ---
> net/bridge/br_device.c | 2 +-
> net/bridge/br_input.c | 2 +-
> net/bridge/br_multicast.c | 44 +++++++++++++++++++-------------------------
> net/bridge/br_private.h | 6 ++++--
> 4 files changed, 25 insertions(+), 29 deletions(-)
...
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 8b0b610..686284f 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -947,7 +947,8 @@ void br_multicast_disable_port(struct net_bridge_port *port)
>
> static int br_ip4_multicast_igmp3_report(struct net_bridge *br,
> struct net_bridge_port *port,
> - struct sk_buff *skb)
> + struct sk_buff *skb,
> + u16 vid)
> {
> struct igmpv3_report *ih;
> struct igmpv3_grec *grec;
> @@ -957,12 +958,10 @@ static int br_ip4_multicast_igmp3_report(struct net_bridge *br,
> int type;
> int err = 0;
> __be32 group;
> - u16 vid = 0;
>
> if (!pskb_may_pull(skb, sizeof(*ih)))
> return -EINVAL;
>
> - br_vlan_get_tag(skb, &vid);
After applied the patch, we always use vid in br_dev_xmit()->br_allowed_ingress(),
is it possible that the vlan of bridge is re-enabled when other
changed functions are called?
We can just add a enabled checking before this kind of br_vlan_get_tag()?
if (!br->vlan_enabled)
br_vlan_get_tag(skb2, &vid);
> ih = igmpv3_report_hdr(skb);
> num = ntohs(ih->ngrec);
> len = sizeof(*ih);
...
--
Amos.
^ permalink raw reply
* Re: [PATCH net V3] xen-netback: use jiffies_64 value to calculate credit timeout
From: annie li @ 2013-10-29 2:39 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, netdev, david.vrabel, jbeulich, Ian Campbell,
Jason Luan
In-Reply-To: <1382962077-13406-1-git-send-email-wei.liu2@citrix.com>
On 2013-10-28 20:07, Wei Liu wrote:
> time_after_eq() only works if the delta is < MAX_ULONG/2.
>
> For a 32bit Dom0, if netfront sends packets at a very low rate, the time
> between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
> and the test for timer_after_eq() will be incorrect. Credit will not be
> replenished and the guest may become unable to send packets (e.g., if
> prior to the long gap, all credit was exhausted).
>
> Use jiffies_64 variant to mitigate this problem for 32bit Dom0.
>
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jason Luan <jianhai.luan@oracle.com>
> ---
> drivers/net/xen-netback/common.h | 1 +
> drivers/net/xen-netback/interface.c | 3 +--
> drivers/net/xen-netback/netback.c | 10 +++++-----
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index 5715318..400fea1 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -163,6 +163,7 @@ struct xenvif {
> unsigned long credit_usec;
> unsigned long remaining_credit;
> struct timer_list credit_timeout;
> + u64 credit_window_start;
>
> /* Statistics */
> unsigned long rx_gso_checksum_fixup;
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 01bb854..459935a 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -312,8 +312,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> vif->credit_bytes = vif->remaining_credit = ~0UL;
> vif->credit_usec = 0UL;
> init_timer(&vif->credit_timeout);
> - /* Initialize 'expires' now: it's used to track the credit window. */
> - vif->credit_timeout.expires = jiffies;
> + vif->credit_window_start = get_jiffies_64();
>
> dev->netdev_ops = &xenvif_netdev_ops;
> dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index f3e591c..900da4b 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1185,9 +1185,8 @@ out:
>
> static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
> {
> - unsigned long now = jiffies;
> - unsigned long next_credit =
> - vif->credit_timeout.expires +
> + u64 now = get_jiffies_64();
> + u64 next_credit = vif->credit_window_start +
> msecs_to_jiffies(vif->credit_usec / 1000);
>
> /* Timer could already be pending in rare cases. */
> @@ -1195,8 +1194,8 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
> return true;
>
> /* Passed the point where we can replenish credit? */
> - if (time_after_eq(now, next_credit)) {
> - vif->credit_timeout.expires = now;
> + if (time_after_eq64(now, next_credit)) {
> + vif->credit_window_start = now;
> tx_add_credit(vif);
> }
>
> @@ -1208,6 +1207,7 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
> tx_credit_callback;
> mod_timer(&vif->credit_timeout,
> next_credit);
> + vif->credit_window_start = next_credit;
>
> return true;
> }
This patch looks good, thanks Wei.
Thanks
Annie
^ permalink raw reply
* [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
From: Du, ChangbinX @ 2013-10-29 3:30 UTC (permalink / raw)
To: oliver@neukum.org
Cc: linux-usb@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
From: "Du, Changbin" <changbinx.du@intel.com>
In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
be called which calls free_netdev(net). Thus usbnet structure(alloced
with net_device structure) will be freed,too.
So we cannot call usbnet_link_change() if cdc_ncm_bind_common() return
error.
BUG: unable to handle kernel NULL pointer dereference at 00000078
EIP is at usbnet_link_change+0x1e/0x80
Call Trace:
[<c24bc69a>] cdc_ncm_bind+0x3a/0x50
[<c24b8d32>] usbnet_probe+0x282/0x7d0
[<c2167f2c>] ? sysfs_new_dirent+0x6c/0x100
[<c2821253>] ? mutex_lock+0x13/0x40
[<c24bb278>] cdc_ncm_probe+0x8/0x10
[<c24e0ef7>] usb_probe_interface+0x187/0x2c0
[<c23caa8a>] ? driver_sysfs_add+0x6a/0x90
[<c23cb290>] ? __driver_attach+0x90/0x90
[<c23caf14>] driver_probe_device+0x74/0x360
[<c24e07b1>] ? usb_match_id+0x41/0x60
[<c24e081e>] ? usb_device_match+0x4e/0x90
[<c23cb290>] ? __driver_attach+0x90/0x90
[<c23cb2c9>] __device_attach+0x39/0x50
[<c23c93f4>] bus_for_each_drv+0x34/0x70
[<c23cae2b>] device_attach+0x7b/0x90
[<c23cb290>] ? __driver_attach+0x90/0x90
[<c23ca38f>] bus_probe_device+0x6f/0x90
[<c23c8a08>] device_add+0x558/0x630
[<c24e4821>] ? usb_create_ep_devs+0x71/0xd0
[<c24dd0db>] ? create_intf_ep_devs+0x4b/0x70
[<c24df2bf>] usb_set_configuration+0x4bf/0x800
[<c23cb290>] ? __driver_attach+0x90/0x90
[<c24e809b>] generic_probe+0x2b/0x90
[<c24e105c>] usb_probe_device+0x2c/0x70
[<c23caf14>] driver_probe_device+0x74/0x360
Signed-off-by: Du, Changbin <changbinx.du@intel.com>
---
drivers/net/usb/cdc_ncm.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 43afde8..af37ecf 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -603,14 +603,15 @@ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
/* NCM data altsetting is always 1 */
ret = cdc_ncm_bind_common(dev, intf, 1);
-
- /*
- * We should get an event when network connection is "connected" or
- * "disconnected". Set network connection in "disconnected" state
- * (carrier is OFF) during attach, so the IP network stack does not
- * start IPv6 negotiation and more.
- */
- usbnet_link_change(dev, 0, 0);
+ if (!ret) {
+ /*
+ * We should get an event when network connection is "connected"
+ * or "disconnected". Set network connection in "disconnected"
+ * state (carrier is OFF) during attach, so the IP network stack
+ * does not start IPv6 negotiation and more.
+ */
+ usbnet_link_change(dev, 0, 0);
+ }
return ret;
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] ethernet/arc/arc_emac: drop redundant mac address check
From: David Miller @ 2013-10-29 3:48 UTC (permalink / raw)
To: luka; +Cc: netdev, abrodkin
In-Reply-To: <1383010340-26445-1-git-send-email-luka@openwrt.org>
I've seen you use three inconsistent Subject prefixes here, pick a scheme
and stick to it please!
First patch was:
netdev: ${driver_name}:
Second patch was:
net: ${driver_name}:
Third patch was:
patch/to/driver/directory:
This is really not acceptable. Just using "${driver_name}: " is good
enough.
^ permalink raw reply
* Re: [PATCH net-next 2/3] tipc: message reassembly using fragment chain
From: David Miller @ 2013-10-29 3:49 UTC (permalink / raw)
To: ying.xue
Cc: maloy, jon.maloy, paul.gortmaker, erik.hugne, tipc-discussion,
netdev
In-Reply-To: <526F15E8.9020009@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Tue, 29 Oct 2013 09:56:56 +0800
> Therefore, the best method is to divide tipc_recv_msg() into several
> smaller functions to simplify the current implementation. But it's not
> an easy job. Actually I ever tried to do it, but I gave up lastly
> because I did not find one perfect solution about how to divide it.
But you're going to have to find a way, this indent level is out of
control.
^ 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