* [PATCH v2 2/2] can: remove references to berlios mailinglist
From: Marc Kleine-Budde @ 2011-10-17 19:32 UTC (permalink / raw)
To: linux-can; +Cc: netdev, Marc Kleine-Budde
In-Reply-To: <1318879920-25280-1-git-send-email-mkl@pengutronix.de>
The BerliOS project, which currently hosts our mailinglist, will
close with the end of the year. Now take the chance and remove all
occurrences of the mailinglist address from the source files.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Changes since v1:
- remove mailinglist address altogether (tnx David).
drivers/net/can/at91_can.c | 2 --
drivers/net/can/sja1000/sja1000.c | 2 --
drivers/net/can/sja1000/sja1000.h | 2 --
drivers/net/can/slcan.c | 2 --
drivers/net/can/vcan.c | 2 --
include/linux/can.h | 2 --
include/linux/can/bcm.h | 2 --
include/linux/can/core.h | 2 --
include/linux/can/dev.h | 1 -
include/linux/can/error.h | 2 --
include/linux/can/gw.h | 2 --
include/linux/can/netlink.h | 2 --
include/linux/can/raw.h | 2 --
net/can/af_can.c | 2 --
net/can/af_can.h | 2 --
net/can/bcm.c | 2 --
net/can/gw.c | 2 --
net/can/proc.c | 2 --
net/can/raw.c | 2 --
19 files changed, 0 insertions(+), 37 deletions(-)
diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index 121ede6..044ea06 100644
--- a/drivers/net/can/at91_can.c
+++ b/drivers/net/can/at91_can.c
@@ -8,8 +8,6 @@
* Public License ("GPL") version 2 as distributed in the 'COPYING'
* file from the main directory of the linux kernel source.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*
* Your platform definition file should specify something like:
*
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index f501bba..04a3f1b 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -40,8 +40,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#include <linux/module.h>
diff --git a/drivers/net/can/sja1000/sja1000.h b/drivers/net/can/sja1000/sja1000.h
index 78bd4ec..23fff06 100644
--- a/drivers/net/can/sja1000/sja1000.h
+++ b/drivers/net/can/sja1000/sja1000.h
@@ -40,8 +40,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#ifndef SJA1000_DEV_H
diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c
index 4b70b7e..a979b00 100644
--- a/drivers/net/can/slcan.c
+++ b/drivers/net/can/slcan.c
@@ -35,8 +35,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#include <linux/module.h>
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index a30b8f4..f93e2d6 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -37,8 +37,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#include <linux/module.h>
diff --git a/include/linux/can.h b/include/linux/can.h
index bb047dc..9a19bcb 100644
--- a/include/linux/can.h
+++ b/include/linux/can.h
@@ -8,8 +8,6 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#ifndef CAN_H
diff --git a/include/linux/can/bcm.h b/include/linux/can/bcm.h
index e96154d..3ebe387 100644
--- a/include/linux/can/bcm.h
+++ b/include/linux/can/bcm.h
@@ -7,8 +7,6 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#ifndef CAN_BCM_H
diff --git a/include/linux/can/core.h b/include/linux/can/core.h
index 5ce6b5d..0ccc1cd 100644
--- a/include/linux/can/core.h
+++ b/include/linux/can/core.h
@@ -8,8 +8,6 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#ifndef CAN_CORE_H
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index cc0bb49..a0969fc 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -8,7 +8,6 @@
*
* Copyright (C) 2008 Wolfgang Grandegger <wg@grandegger.com>
*
- * Send feedback to <socketcan-users@lists.berlios.de>
*/
#ifndef CAN_DEV_H
diff --git a/include/linux/can/error.h b/include/linux/can/error.h
index 5958074..63e855e 100644
--- a/include/linux/can/error.h
+++ b/include/linux/can/error.h
@@ -7,8 +7,6 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#ifndef CAN_ERROR_H
diff --git a/include/linux/can/gw.h b/include/linux/can/gw.h
index 5527b54..8e1db18 100644
--- a/include/linux/can/gw.h
+++ b/include/linux/can/gw.h
@@ -7,8 +7,6 @@
* Copyright (c) 2011 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#ifndef CAN_GW_H
diff --git a/include/linux/can/netlink.h b/include/linux/can/netlink.h
index 34542d3..14966dd 100644
--- a/include/linux/can/netlink.h
+++ b/include/linux/can/netlink.h
@@ -5,8 +5,6 @@
*
* Copyright (c) 2009 Wolfgang Grandegger <wg@grandegger.com>
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#ifndef CAN_NETLINK_H
diff --git a/include/linux/can/raw.h b/include/linux/can/raw.h
index b2a0f87..781f3a3 100644
--- a/include/linux/can/raw.h
+++ b/include/linux/can/raw.h
@@ -8,8 +8,6 @@
* Copyright (c) 2002-2007 Volkswagen Group Electronic Research
* All rights reserved.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#ifndef CAN_RAW_H
diff --git a/net/can/af_can.c b/net/can/af_can.c
index d1ff515..0ce2ad0 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -38,8 +38,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#include <linux/module.h>
diff --git a/net/can/af_can.h b/net/can/af_can.h
index 34253b8..fd882db 100644
--- a/net/can/af_can.h
+++ b/net/can/af_can.h
@@ -35,8 +35,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#ifndef AF_CAN_H
diff --git a/net/can/bcm.c b/net/can/bcm.c
index c84963d..151b773 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -37,8 +37,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#include <linux/module.h>
diff --git a/net/can/gw.c b/net/can/gw.c
index ac11407..3d79b12 100644
--- a/net/can/gw.c
+++ b/net/can/gw.c
@@ -37,8 +37,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#include <linux/module.h>
diff --git a/net/can/proc.c b/net/can/proc.c
index 0016f73..ba873c3 100644
--- a/net/can/proc.c
+++ b/net/can/proc.c
@@ -37,8 +37,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#include <linux/module.h>
diff --git a/net/can/raw.c b/net/can/raw.c
index dea99a6..cde1b4a 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -37,8 +37,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*
- * Send feedback to <socketcan-users@lists.berlios.de>
- *
*/
#include <linux/module.h>
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 0/2] MAINTAINERS: can: the mailinglist moved to vger.kernel.org
From: Marc Kleine-Budde @ 2011-10-17 19:31 UTC (permalink / raw)
To: linux-can; +Cc: netdev
Hello,
the BerliOS project will close with the end of the year, so we moved our
mailinglist to vger.kernel.org, it's now linux-can@vger.kernel.org.
This patch series change the mailinglist in MAINTAINERS and remove all other
references from the source tree. As David pointed out, automated tool will
use MAINTAINERS to gather this information.
cheers, Marc
The following changes since commit fd38f734cb8200529e281338514945fcbff2364b:
igbvf: convert to ndo_fix_features (2011-10-16 13:18:47 -0700)
are available in the git repository at:
git.pengutronix.de:/git/mkl/linux-2.6.git can/mailinglist-for-net-next
Marc Kleine-Budde (2):
MAINTAINERS: can: the mailinglist moved to vger.kernel.org
can: remove references to berlios mailinglist
MAINTAINERS | 4 ++--
drivers/net/can/at91_can.c | 2 --
drivers/net/can/sja1000/sja1000.c | 2 --
drivers/net/can/sja1000/sja1000.h | 2 --
drivers/net/can/slcan.c | 2 --
drivers/net/can/vcan.c | 2 --
include/linux/can.h | 2 --
include/linux/can/bcm.h | 2 --
include/linux/can/core.h | 2 --
include/linux/can/dev.h | 1 -
include/linux/can/error.h | 2 --
include/linux/can/gw.h | 2 --
include/linux/can/netlink.h | 2 --
include/linux/can/raw.h | 2 --
net/can/af_can.c | 2 --
net/can/af_can.h | 2 --
net/can/bcm.c | 2 --
net/can/gw.c | 2 --
net/can/proc.c | 2 --
net/can/raw.c | 2 --
20 files changed, 2 insertions(+), 39 deletions(-)
^ permalink raw reply
* [PATCH v2 1/2] MAINTAINERS: can: the mailinglist moved to vger.kernel.org
From: Marc Kleine-Budde @ 2011-10-17 19:31 UTC (permalink / raw)
To: linux-can; +Cc: netdev, Marc Kleine-Budde
In-Reply-To: <1318879920-25280-1-git-send-email-mkl@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
MAINTAINERS | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index aac56f9..5008b08 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1671,7 +1671,7 @@ CAN NETWORK LAYER
M: Oliver Hartkopp <socketcan@hartkopp.net>
M: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
M: Urs Thuermann <urs.thuermann@volkswagen.de>
-L: socketcan-core@lists.berlios.de (subscribers-only)
+L: linux-can@vger.kernel.org
L: netdev@vger.kernel.org
W: http://developer.berlios.de/projects/socketcan/
S: Maintained
@@ -1683,7 +1683,7 @@ F: include/linux/can/raw.h
CAN NETWORK DRIVERS
M: Wolfgang Grandegger <wg@grandegger.com>
-L: socketcan-core@lists.berlios.de (subscribers-only)
+L: linux-can@vger.kernel.org
L: netdev@vger.kernel.org
W: http://developer.berlios.de/projects/socketcan/
S: Maintained
--
1.7.4.1
^ permalink raw reply related
* pull request: wireless-next 2011-10-17
From: John W. Linville @ 2011-10-17 19:19 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
Here is one more (last?) wireless pull request intended for 3.2.
The most notable bits of this request are the long awaited brcm80211
drivers. Along with those come the usual strong showings from the
iwlwifi and ath9k teams and some mac80211 updates from Johannes
and others. There are also updates for mwifiex, rtlwifi, wl12xx,
and b43, as well as a few other random bits.
Please let me know if there are problems!
Thanks,
JOhn
---
The following changes since commit fd38f734cb8200529e281338514945fcbff2364b:
igbvf: convert to ndo_fix_features (2011-10-16 13:18:47 -0700)
are available in the git repository at:
git://git.infradead.org/users/linville/wireless-next.git for-davem
Alwin Beukers (9):
brcm80211: cleanup function prototypes
brcm80211: removed unused functions
brcm80211: moved power conversion functions
brcm80211: moved function brcmu_chipname
brcm80211: moved function brcmu_parse_tlvs
brcm80211: moved function brcmu_chspec_malformed
brcm80211: moved function brcmu_mkiovar
brcm80211: moved function brcmu_format_flags
brcm80211: removed file wifi.c
Amitkumar Karwar (3):
mwifiex: add support for Marvell pcie8766 chipset
mwifiex: use separate wait condition for each command node
mwifiex: fix make namespacecheck warnings
Arend van Spriel (11):
net: wireless: add brcm80211 drivers
brcm80211: remove sparse warning in fullmac debug function
brcm80211: fix sparse endianess error in mac80211_if.c
brcm80211: add endian annotation to packet filter structures
brcm80211: rename variable in _brcmf_set_multicast_list()
brcm80211: fix annotations in TOE configuration functions
brcm80211: use endian annotations in scan related function
brcm80211: use endian annotation for pmk related structure
brcm80211: use endian annotations for assoc ie length request
brcm80211: use endian annotation for roaming related parameters
brcm80211: use endian annotation for scan time configuration
Chaoming Li (4):
rtlwifi: Update to new Realtek version - Part I
rtlwifi: rtl8192ce: Add new chip revisions
rtlwifi: rtl8192se: Updates from latest Realtek driver version - Part II
rtlwifi: rtl8192de: Updates from latest Reaktek driver - Part III
Dan Carpenter (3):
ath5k: remove some unneeded error handling code
ath9k: remove some bogus error handling code
iwmc3200wifi: add a range check to iwm_cfg80211_get_key()
Daniel Drake (1):
libertas: fix changing interface type when interface is down
Don Fry (1):
iwlagn: eliminate bus pointer from iwl_priv structure
Eliad Peller (2):
wl12xx: configure rate policy for p2p operations
wl12xx: disable AP-mode-specific quirks
Emmanuel Grumbach (7):
iwlagn: kill hw_params.max_stations
iwlagn: fix a race in the unmapping of the TFDs
iwlagn: warn only once if AGG state is wrong
iwlagn: move iwl_beacon_time_mask_XXX near to usage
iwlagn: move iwl_enable_rfkill_int and kill iwl-helpers.h
iwlagn: remove uneeded include to iwl-dev.h
iwlagn: add missing include to iwl-agn-rs.h
Felix Fietkau (11):
ath9k: indicate which queues are blocked when stopping tx fails
ath9k: keep track of what's triggering hardware resets
ath9k: improve PS filter clearing and retry counting for A-MPDU
ath9k: fix retry counting / BAR handling during queue flush
ath9k: disable unnecessary PHY error reporting
ath9k_hw: make ath9k_hw_set_interrupts use ah->imask by default
ath9k_hw: clean up tx power handling
ath: remove ath_regulatory::current_rd_ext
ath9k_hw: remove EEP_REG_1
ath9k_hw: fix a regression in key miss handling
ath9k: only send FCS-fail packets to mac80211 if requested
Helmut Schaa (5):
mac80211: Update injection documentation
mac80211: Build TX radiotap header dynamically
mac80211: Populate radiotap header with MCS info for TX frames
nl80211: Add sta_flags to the station info
mac80211: Provide station flags to cfg80211
Javier Cardona (1):
mac80211: Fix regression that allowed mpaths between non-peers.
Johannes Berg (16):
mac80211: pass no-CCK flag through to HW scan
mac80211: fix offchannel TX cookie matching
mac80211: optimise monitor xmit
mac80211: remove tx_data ethertype
mac80211: move fragment flag to info flag as dont-fragment
mac80211: parse radiotap header earlier
mac80211: dont adjust truesize
mac80211: dont orphan TX skb
iwlagn: update beacon smarter
iwlagn: don't assign seqno to QoS Null frames
iwlagn: send simple LQ command for WoWLAN
iwlagn: stop interrupts when suspending
iwlagn: remove 5000 hw header
iwlagn: remove 6000 hw header
mac80211: reformat TX unauthorised check
mac80211: fix TID for null poll response
John W. Linville (2):
Merge branch 'for-linville' of git://github.com/lucacoelho/wl12xx
Merge branch 'master' of git://git.infradead.org/users/linville/wireless-next into for-davem
Larry Finger (2):
rtlwifi: Change debug parameter to apply to individual drivers
rtlwifi: Change PCI drivers to use the new PM framework
Luciano Coelho (1):
wl12xx: set max_sched_scan_ie_len correctly
Rafał Miłecki (3):
b43: trivial: do not report any link quality instead of invalid one
Revert "b43: trivial: do not report any link quality instead of invalid one"
b43: N-PHY: report signal to mac80211
Rajkumar Manoharan (14):
ath9k_hw: Fix ASPM L1 issue for AR9480
ath9k_hw: Updated ar9003 initval table for AR9380
ath9k_hw: Update AR9003 initval to improve phase noise
ath9k_hw: Updated AR9003 tx gain table for 5GHz
ath9k_hw: Improve fast channel change for AR9003 chips
ath9k_hw: Add support to reuse TxIQ cal measurements
ath9k_hw: Add support to reuse Carrier leak calibration
ath9k_hw: Cleanup Tx calibrations for AR9003 chips
ath9k_hw: Support fast channel change on 5GHz for AR9003 chips
ath9k_hw: Update normal/min noise floor value for AR9480
ath9k_hw: Add radio retention support for AR9480
ath9k_hw: Do fast channel change based on reusable calibration results
ath9k_hw: Rename AR9480 -> AR9462 initvals
ath9k: Rename AR9480 into AR9462
Roland Vossen (3):
brcm80211: smac: removed redundant timer function parameters
brcm80211: smac: decreased timer callback irq level
brcm80211: fmac: fixed weird indentation
Shahar Levi (1):
wl12xx: Add support for HW channel switch
Stanislaw Gruszka (1):
iwlagn: fix priv->cfg->ht_params NULL pointer dereference
Stephen Rothwell (2):
net: wireless: brcm80211: replace ndo_set_multicast_list with ndo_set_rx_mode
net: wireless: brcm80210: include module.h
Wey-Yi Guy (20):
iwlagn: separate init calib and rt calib
iwlagn: add cmd queue pointer info when timeout
iwlagn: add REPLY_ECHO host command
iwlagn: add WARN if tx cmd complete come back late
iwlagn: add "echo" test when command queue stuck
iwlagn: check rf kill in queue stuck
iwlagn: add "echo test" command to debugfs
iwlagn: remove un-necessary step
iwlagn: set rts retry limit
iwlagn: add "_d" sku to 6005 series of devices
iwlagn: Add "_d" sku to 105 series of devices
iwlagn: do nothing when disable agg in wrong state
iwlagn: use low retry limit for WoWLAN
iwlwifi: update comments on how to enable debug flag
iwlagn: more info on warning for shutdown agg queue
iwlagn: don't stop rts/cts until last aggregation queue close
iwlagn: add debug for mac80211 callback
iwlagn: rename all the mac80211 callback functions
iwlagn: merge station management functions
iwlagn: rename iwl-rx.c to iwl-agn-rx.c
Yogesh Ashok Powar (1):
mwifiex: fix smatch errors
Documentation/networking/mac80211-injection.txt | 4 +
drivers/net/wireless/Kconfig | 1 +
drivers/net/wireless/Makefile | 3 +
drivers/net/wireless/ath/ath.h | 2 -
drivers/net/wireless/ath/ath5k/base.c | 6 -
drivers/net/wireless/ath/ath9k/Makefile | 1 +
drivers/net/wireless/ath/ath9k/ani.c | 5 -
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 11 +-
.../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 172 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 250 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 59 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 186 +-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 4 +-
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 15 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 97 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 52 +-
drivers/net/wireless/ath/ath9k/ar9003_rtt.c | 153 +
drivers/net/wireless/ath/ath9k/ar9003_rtt.h | 28 +
...ar9480_1p0_initvals.h => ar9462_1p0_initvals.h} | 62 +-
...ar9480_2p0_initvals.h => ar9462_2p0_initvals.h} | 68 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/beacon.c | 10 +-
drivers/net/wireless/ath/ath9k/common.c | 6 +-
drivers/net/wireless/ath/ath9k/debug.c | 19 +-
drivers/net/wireless/ath/ath9k/debug.h | 13 +
drivers/net/wireless/ath/ath9k/eeprom.h | 10 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 29 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 35 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 45 +-
drivers/net/wireless/ath/ath9k/gpio.c | 8 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 7 +
drivers/net/wireless/ath/ath9k/hw.c | 158 +-
drivers/net/wireless/ath/ath9k/hw.h | 39 +-
drivers/net/wireless/ath/ath9k/init.c | 2 -
drivers/net/wireless/ath/ath9k/mac.c | 10 +-
drivers/net/wireless/ath/ath9k/mac.h | 6 +-
drivers/net/wireless/ath/ath9k/main.c | 25 +-
drivers/net/wireless/ath/ath9k/pci.c | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 35 +-
drivers/net/wireless/ath/ath9k/reg.h | 29 +-
drivers/net/wireless/ath/ath9k/xmit.c | 40 +-
drivers/net/wireless/ath/carl9170/main.c | 1 -
drivers/net/wireless/b43/xmit.c | 18 +-
drivers/net/wireless/b43/xmit.h | 10 +-
drivers/net/wireless/brcm80211/Kconfig | 35 +
drivers/net/wireless/brcm80211/Makefile | 23 +
drivers/net/wireless/brcm80211/brcmfmac/Makefile | 33 +
drivers/net/wireless/brcm80211/brcmfmac/bcmchip.h | 32 +
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 371 +
.../net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 626 +
drivers/net/wireless/brcm80211/brcmfmac/dhd.h | 776 +
drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h | 57 +
drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c | 498 +
.../net/wireless/brcm80211/brcmfmac/dhd_common.c | 895 +
drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.h | 58 +
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 1356 +
.../net/wireless/brcm80211/brcmfmac/dhd_proto.h | 60 +
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 4591 ++++
.../net/wireless/brcm80211/brcmfmac/sdio_host.h | 252 +
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 3868 +++
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.h | 375 +
drivers/net/wireless/brcm80211/brcmsmac/Makefile | 51 +
drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 2079 ++
drivers/net/wireless/brcm80211/brcmsmac/aiutils.h | 378 +
drivers/net/wireless/brcm80211/brcmsmac/ampdu.c | 1241 +
drivers/net/wireless/brcm80211/brcmsmac/ampdu.h | 30 +
drivers/net/wireless/brcm80211/brcmsmac/antsel.c | 307 +
drivers/net/wireless/brcm80211/brcmsmac/antsel.h | 29 +
.../brcm80211/brcmsmac/brcms_trace_events.c | 23 +
.../brcm80211/brcmsmac/brcms_trace_events.h | 92 +
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 1591 ++
drivers/net/wireless/brcm80211/brcmsmac/channel.h | 53 +
drivers/net/wireless/brcm80211/brcmsmac/d11.h | 1898 ++
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 1425 +
drivers/net/wireless/brcm80211/brcmsmac/dma.h | 120 +
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 1696 ++
.../net/wireless/brcm80211/brcmsmac/mac80211_if.h | 108 +
drivers/net/wireless/brcm80211/brcmsmac/main.c | 8775 ++++++
drivers/net/wireless/brcm80211/brcmsmac/main.h | 735 +
drivers/net/wireless/brcm80211/brcmsmac/nicpci.c | 835 +
drivers/net/wireless/brcm80211/brcmsmac/nicpci.h | 82 +
drivers/net/wireless/brcm80211/brcmsmac/otp.c | 426 +
drivers/net/wireless/brcm80211/brcmsmac/otp.h | 36 +
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 2988 ++
.../net/wireless/brcm80211/brcmsmac/phy/phy_hal.h | 301 +
.../net/wireless/brcm80211/brcmsmac/phy/phy_int.h | 1169 +
.../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c | 5154 ++++
.../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.h | 121 +
.../net/wireless/brcm80211/brcmsmac/phy/phy_n.c |28876 ++++++++++++++++++++
.../wireless/brcm80211/brcmsmac/phy/phy_qmath.c | 308 +
.../wireless/brcm80211/brcmsmac/phy/phy_qmath.h | 42 +
.../wireless/brcm80211/brcmsmac/phy/phy_radio.h | 1533 ++
.../net/wireless/brcm80211/brcmsmac/phy/phyreg_n.h | 167 +
.../wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c | 3250 +++
.../wireless/brcm80211/brcmsmac/phy/phytbl_lcn.h | 54 +
.../net/wireless/brcm80211/brcmsmac/phy/phytbl_n.c |10630 +++++++
.../net/wireless/brcm80211/brcmsmac/phy/phytbl_n.h | 50 +
drivers/net/wireless/brcm80211/brcmsmac/phy_shim.c | 225 +
drivers/net/wireless/brcm80211/brcmsmac/phy_shim.h | 182 +
drivers/net/wireless/brcm80211/brcmsmac/pmu.c | 458 +
drivers/net/wireless/brcm80211/brcmsmac/pmu.h | 38 +
drivers/net/wireless/brcm80211/brcmsmac/pub.h | 634 +
drivers/net/wireless/brcm80211/brcmsmac/rate.c | 514 +
drivers/net/wireless/brcm80211/brcmsmac/rate.h | 250 +
drivers/net/wireless/brcm80211/brcmsmac/scb.h | 82 +
drivers/net/wireless/brcm80211/brcmsmac/srom.c | 1298 +
drivers/net/wireless/brcm80211/brcmsmac/srom.h | 34 +
drivers/net/wireless/brcm80211/brcmsmac/stf.c | 436 +
drivers/net/wireless/brcm80211/brcmsmac/stf.h | 42 +
drivers/net/wireless/brcm80211/brcmsmac/types.h | 352 +
.../net/wireless/brcm80211/brcmsmac/ucode_loader.c | 109 +
.../net/wireless/brcm80211/brcmsmac/ucode_loader.h | 58 +
drivers/net/wireless/brcm80211/brcmutil/Makefile | 28 +
drivers/net/wireless/brcm80211/brcmutil/utils.c | 386 +
.../net/wireless/brcm80211/include/brcm_hw_ids.h | 59 +
.../net/wireless/brcm80211/include/brcmu_utils.h | 195 +
.../net/wireless/brcm80211/include/brcmu_wifi.h | 239 +
.../net/wireless/brcm80211/include/chipcommon.h | 284 +
drivers/net/wireless/brcm80211/include/defs.h | 104 +
drivers/net/wireless/brcm80211/include/soc.h | 90 +
drivers/net/wireless/iwlwifi/Kconfig | 4 +-
drivers/net/wireless/iwlwifi/Makefile | 3 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 3 -
drivers/net/wireless/iwlwifi/iwl-2000.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-5000-hw.h | 88 -
drivers/net/wireless/iwlwifi/iwl-5000.c | 22 +-
drivers/net/wireless/iwlwifi/iwl-6000-hw.h | 81 -
drivers/net/wireless/iwlwifi/iwl-6000.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-agn-hw.h | 15 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 2 -
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.h | 4 +
.../wireless/iwlwifi/{iwl-rx.c => iwl-agn-rx.c} | 112 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 861 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 32 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 1 -
drivers/net/wireless/iwlwifi/iwl-agn.c | 126 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 131 +-
drivers/net/wireless/iwlwifi/iwl-cfg.h | 2 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 11 +
drivers/net/wireless/iwlwifi/iwl-core.c | 83 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 20 +-
drivers/net/wireless/iwlwifi/iwl-debug.h | 8 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 22 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 3 -
drivers/net/wireless/iwlwifi/iwl-helpers.h | 72 -
drivers/net/wireless/iwlwifi/iwl-led.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-pci.c | 2 +
drivers/net/wireless/iwlwifi/iwl-power.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-shared.h | 2 -
drivers/net/wireless/iwlwifi/iwl-sta.c | 835 -
drivers/net/wireless/iwlwifi/iwl-sta.h | 141 -
drivers/net/wireless/iwlwifi/iwl-sv-open.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c | 1 -
drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 23 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 21 +-
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 6 +-
drivers/net/wireless/libertas/cfg.c | 20 +-
drivers/net/wireless/libertas/decl.h | 2 +
drivers/net/wireless/libertas/main.c | 32 +
drivers/net/wireless/mwifiex/11n_aggr.c | 3 +-
drivers/net/wireless/mwifiex/Kconfig | 11 +
drivers/net/wireless/mwifiex/Makefile | 3 +
drivers/net/wireless/mwifiex/cfp.c | 10 +-
drivers/net/wireless/mwifiex/cmdevt.c | 34 +-
drivers/net/wireless/mwifiex/decl.h | 1 -
drivers/net/wireless/mwifiex/fw.h | 36 +-
drivers/net/wireless/mwifiex/init.c | 73 +-
drivers/net/wireless/mwifiex/main.c | 10 +-
drivers/net/wireless/mwifiex/main.h | 35 +-
drivers/net/wireless/mwifiex/pcie.c | 1948 ++
drivers/net/wireless/mwifiex/pcie.h | 148 +
drivers/net/wireless/mwifiex/scan.c | 56 +-
drivers/net/wireless/mwifiex/sdio.c | 19 +-
drivers/net/wireless/mwifiex/sdio.h | 24 +-
drivers/net/wireless/mwifiex/sta_cmd.c | 64 +
drivers/net/wireless/mwifiex/sta_cmdresp.c | 2 +
drivers/net/wireless/mwifiex/sta_ioctl.c | 12 +-
drivers/net/wireless/mwifiex/sta_tx.c | 2 +-
drivers/net/wireless/mwifiex/txrx.c | 45 +-
drivers/net/wireless/mwifiex/util.c | 5 +-
drivers/net/wireless/mwifiex/util.h | 9 +-
drivers/net/wireless/mwifiex/wmm.c | 4 +-
drivers/net/wireless/rtlwifi/base.c | 6 +-
drivers/net/wireless/rtlwifi/debug.c | 6 -
drivers/net/wireless/rtlwifi/pci.c | 19 +-
drivers/net/wireless/rtlwifi/pci.h | 4 +-
drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 14 +
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 35 +-
drivers/net/wireless/rtlwifi/rtl8192cu/def.h | 4 -
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 7 +
drivers/net/wireless/rtlwifi/rtl8192de/def.h | 135 +-
drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 15 +-
drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 21 +-
drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 22 +-
drivers/net/wireless/rtlwifi/rtl8192se/reg.h | 1 +
drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 22 +-
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 55 +-
drivers/net/wireless/rtlwifi/wifi.h | 5 +
drivers/net/wireless/wl12xx/acx.c | 16 +
drivers/net/wireless/wl12xx/acx.h | 1 +
drivers/net/wireless/wl12xx/boot.c | 6 +-
drivers/net/wireless/wl12xx/cmd.c | 63 +-
drivers/net/wireless/wl12xx/cmd.h | 20 +
drivers/net/wireless/wl12xx/conf.h | 6 +-
drivers/net/wireless/wl12xx/event.c | 15 +
drivers/net/wireless/wl12xx/main.c | 48 +-
drivers/net/wireless/wl12xx/wl12xx.h | 7 +-
drivers/staging/Kconfig | 2 +-
drivers/staging/Makefile | 4 +-
include/linux/nl80211.h | 2 +
include/net/cfg80211.h | 5 +-
include/net/mac80211.h | 10 +-
net/mac80211/cfg.c | 22 +-
net/mac80211/ieee80211_i.h | 15 +-
net/mac80211/main.c | 6 +-
net/mac80211/mesh_hwmp.c | 9 +
net/mac80211/scan.c | 1 +
net/mac80211/sta_info.c | 6 +-
net/mac80211/status.c | 137 +-
net/mac80211/tx.c | 360 +-
net/mac80211/work.c | 2 +-
net/mac80211/wpa.c | 3 +-
net/wireless/nl80211.c | 4 +
226 files changed, 102247 insertions(+), 2686 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_rtt.c
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_rtt.h
rename drivers/net/wireless/ath/ath9k/{ar9480_1p0_initvals.h => ar9462_1p0_initvals.h} (97%)
rename drivers/net/wireless/ath/ath9k/{ar9480_2p0_initvals.h => ar9462_2p0_initvals.h} (97%)
create mode 100644 drivers/net/wireless/brcm80211/Kconfig
create mode 100644 drivers/net/wireless/brcm80211/Makefile
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/Makefile
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/bcmchip.h
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd.h
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_bus.h
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.h
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_proto.h
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/sdio_host.h
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
create mode 100644 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/Makefile
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/aiutils.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/aiutils.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/ampdu.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/ampdu.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/antsel.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/antsel.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/brcms_trace_events.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/channel.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/channel.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/d11.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/dma.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/dma.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/main.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/main.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/nicpci.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/nicpci.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/otp.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/otp.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_hal.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_int.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phy_radio.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phyreg_n.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy_shim.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/phy_shim.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/pmu.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/pmu.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/pub.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/rate.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/rate.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/scb.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/srom.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/srom.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/stf.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/stf.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/types.h
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.c
create mode 100644 drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.h
create mode 100644 drivers/net/wireless/brcm80211/brcmutil/Makefile
create mode 100644 drivers/net/wireless/brcm80211/brcmutil/utils.c
create mode 100644 drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
create mode 100644 drivers/net/wireless/brcm80211/include/brcmu_utils.h
create mode 100644 drivers/net/wireless/brcm80211/include/brcmu_wifi.h
create mode 100644 drivers/net/wireless/brcm80211/include/chipcommon.h
create mode 100644 drivers/net/wireless/brcm80211/include/defs.h
create mode 100644 drivers/net/wireless/brcm80211/include/soc.h
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-5000-hw.h
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-6000-hw.h
rename drivers/net/wireless/iwlwifi/{iwl-rx.c => iwl-agn-rx.c} (91%)
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-helpers.h
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-sta.c
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-sta.h
create mode 100644 drivers/net/wireless/mwifiex/pcie.c
create mode 100644 drivers/net/wireless/mwifiex/pcie.h
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* bridge: allow forwarding LLDP frames
From: Ed Swierk @ 2011-10-17 18:12 UTC (permalink / raw)
To: shemminger, davem, netdev, eswierk
LLDP frames have reserved destination MAC address 01-80-C2-00-00-0E,
which by default are not forwarded by 802.1d-compliant bridges.
In certain situations, like when creating a transparent link-layer
relay between a pair of interfaces, it may be useful to configure a
bridge interface to forward LLDP and other control frames in the
01-80-C2-00-00-xx range rather than filtering them.
Stephen Hemminger's recent patch allows the user to set a sysfs
attribute /sys/class/net/brX/bridge/group_fwd_mask to enable
forwarding of normally filtered addresses, with certain exceptions.
This patch eliminates the restriction on LLDP frames, allowing the
user to override the default behavior of filtering them.
Signed-off-by: Ed Swierk <eswierk@bigswitch.com>
---
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index a248fe6..b016dd8 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -31,8 +31,8 @@
/* Control of forwarding link local multicast */
#define BR_GROUPFWD_DEFAULT 0
-/* Don't allow forwarding control protocols like STP and LLDP */
-#define BR_GROUPFWD_RESTRICTED 0x4007u
+/* Don't allow forwarding control protocols like STP */
+#define BR_GROUPFWD_RESTRICTED 0x0007u
/* Path to usermode spanning tree program */
#define BR_STP_PROG "/sbin/bridge-stp"
^ permalink raw reply related
* realtek 8168 driver problem
From: HacKurx @ 2011-10-17 18:13 UTC (permalink / raw)
To: netdev
Hi,
A very annoying problem affects a large number of GNU/Linux distribution.
Network card problem (with 8111/8168 chipset), As you can see:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/839393
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627704#84
http://forums.linuxmint.com/viewtopic.php?f=49&t=80757
https://aur.archlinux.org/packages.php?ID=27000
Can you fix it?
Thank you, best regards
Loic (HacKurx).
^ permalink raw reply
* RE: [net-next 6/6] ixgbe: change the eeprom version reported by ethtool
From: Tantilov, Emil S @ 2011-10-17 18:02 UTC (permalink / raw)
To: Ben Hutchings, Joe Perches
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <1318871797.2784.36.camel@bwh-desktop>
>-----Original Message-----
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Monday, October 17, 2011 10:17 AM
>To: Joe Perches
>Cc: Kirsher, Jeffrey T; davem@davemloft.net; Tantilov, Emil S;
>netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
>Subject: Re: [net-next 6/6] ixgbe: change the eeprom version reported by
>ethtool
>
>On Mon, 2011-10-17 at 08:57 -0700, Joe Perches wrote:
>> On Mon, 2011-10-17 at 05:21 -0700, Jeff Kirsher wrote:
>> > From: Emil Tantilov <emil.s.tantilov@intel.com>
>> >
>> > Use 32bit value starting at offset 0x2d for displaying the firmware
>> > version in ethtool. This should work for all current ixgbe HW
>> []
>> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
>b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
>> []
>> > - snprintf(firmware_version, sizeof(firmware_version), "%d.%d-%d",
>> > - (adapter->eeprom_version & 0xF000) >> 12,
>> > - (adapter->eeprom_version & 0x0FF0) >> 4,
>> > - adapter->eeprom_version & 0x000F);
>> > + nvm_track_id = (adapter->eeprom_verh << 16) |
>> > + adapter->eeprom_verl;
>> > + snprintf(firmware_version, sizeof(firmware_version), "0x%08x",
>> > + nvm_track_id);
>>
>> Is ethtool output like proc output considered an abi
>> that should not be changed?
>
>No-one should make any assumptions about the format of firmware_version
>strings. However they ought to be consistent with vendor documentation,
>update programs, etc.
The old value was only marginally useful as it was possible to have different
images with the same version. The 32 bit value shown by this patch is what
is being used by the FW team to record the revisions of the images.
The words used to hold the 32 bit value are not described in the datasheet
for 82598/9, but will be in X540 once it becomes available and I have requested that this information be added to the 82598/9 docs as well.
Thanks,
Emil
>
>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: [net-next 6/6] ixgbe: change the eeprom version reported by ethtool
From: Ben Hutchings @ 2011-10-17 17:16 UTC (permalink / raw)
To: Joe Perches; +Cc: Jeff Kirsher, davem, Emil Tantilov, netdev, gospo, sassmann
In-Reply-To: <1318867035.5407.5.camel@Joe-Laptop>
On Mon, 2011-10-17 at 08:57 -0700, Joe Perches wrote:
> On Mon, 2011-10-17 at 05:21 -0700, Jeff Kirsher wrote:
> > From: Emil Tantilov <emil.s.tantilov@intel.com>
> >
> > Use 32bit value starting at offset 0x2d for displaying the firmware
> > version in ethtool. This should work for all current ixgbe HW
> []
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> []
> > - snprintf(firmware_version, sizeof(firmware_version), "%d.%d-%d",
> > - (adapter->eeprom_version & 0xF000) >> 12,
> > - (adapter->eeprom_version & 0x0FF0) >> 4,
> > - adapter->eeprom_version & 0x000F);
> > + nvm_track_id = (adapter->eeprom_verh << 16) |
> > + adapter->eeprom_verl;
> > + snprintf(firmware_version, sizeof(firmware_version), "0x%08x",
> > + nvm_track_id);
>
> Is ethtool output like proc output considered an abi
> that should not be changed?
No-one should make any assumptions about the format of firmware_version
strings. However they ought to be consistent with vendor documentation,
update programs, etc.
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] iproute2: update CAN bitrate SJW help text
From: Oliver Hartkopp @ 2011-10-17 17:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Wolfgang Grandegger, Linux Netdev List, linux-can
In-Reply-To: <20111017085826.7a62ed11@nehalam.linuxnetplumber.net>
On 10/17/11 17:58, Stephen Hemminger wrote:
> On Mon, 17 Oct 2011 17:43:37 +0200
> Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>
>> The ip-tool from iproute2 already supports to pass a user defined SJW
>> value for the in-kernel bittiming calculation. This patch updates the
>> help text accordingly.
>>
>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>>
>> ---
>>
>> diff --git a/ip/iplink_can.c b/ip/iplink_can.c
>> index c8af4bc..00e7d98 100644
>> --- a/ip/iplink_can.c
>> +++ b/ip/iplink_can.c
>> @@ -23,7 +23,8 @@ static void usage(void)
>> {
>> fprintf(stderr,
>> "Usage: ip link set DEVICE type can\n"
>> - "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] | \n"
>> + "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT ] [ sjw SJW "
>> + "] ] | \n"
>> "\t[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1\n "
>> "\t phase-seg2 PHASE-SEG2 [ sjw SJW ] ]\n"
>> "\n"
>
> Please update man page as well.
Oops. The manpage has several issues regarding CAN support:
- this updated help text is _not_ part of the ip.8 man page at all
It can only be accessed by 'ip link set <anynetdev> type can help'
Usage: ip link set DEVICE type can
[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
[ loopback { on | off } ]
[ listen-only { on | off } ]
[ triple-sampling { on | off } ]
[ one-shot { on | off } ]
[ berr-reporting { on | off } ]
[ restart-ms TIME-MS ]
[ restart ]
Where: BITRATE := { 1..1000000 }
SAMPLE-POINT := { 0.000..0.999 }
TQ := { NUMBER }
PROP-SEG := { 1..8 }
PHASE-SEG1 := { 1..8 }
PHASE-SEG2 := { 1..8 }
SJW := { 1..4 }
RESTART-MS := { 0 | NUMBER }
-> ip link set <anynetdev> "type TYPE" is not documented in help text & man
page anywhere
- VCAN and CAN interfaces are mixed in the man page
You can not create real CAN interfaces, only virtual ones.
Looks like i tapped into a bigger problem here :-(
Maybe it's the best to apply this help text update first and then to try to
rework the ip.8 man page according to the latest version.
Setting the CAN bittiming & controller setting does not seem to fit into the
'ip link' section of the man page. Do you have an idea how to do that in a
'nice' way?
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: inet6_connection_sock.h needs flowi
From: Christoph Paasch @ 2011-10-17 16:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111016.201310.2196482600418365872.davem@davemloft.net>
On 10/17/2011 03:13 AM, David Miller wrote:
> From: Christoph Paasch<christoph.paasch@uclouvain.be>
> Date: Sun, 16 Oct 2011 12:13:39 +0300
>
>> On 10/16/2011 01:41 AM, David Miller wrote:
>>> From: Christoph Paasch<christoph.paasch@uclouvain.be>
>>> Date: Sat, 15 Oct 2011 12:34:24 +0300
>>>
>>>> Otherwise we have a compiler-warning in c-files not including
>>>> net/flow.h
>>>> before inet6_connection_sock.h .
>>>>
>>>> Signed-off-by: Christoph Paasch<christoph.paasch@uclouvain.be>
>>>
>>> Example? I've never seen this warning.
>>
>> Currently, all the c-files that include inet6_connection_sock.h
>> indirectly include flow.h before inet6_connection_sock.h. Thus
>> currently there is no compiler-warning.
>
> Then there is no bug you are fixing.
You're right. The patch did not intend to fix a bug (maybe the
commit-message should have been more clear about that).
It was intended to make inet6_connection_sock.h not rely on the c-files
to include flow.h, even if they would not need to. And to do the same
for struct flowi as it is done for the other structs in this
header-file. Thus it was rather a coding-style patch... :)
But ok, maybe I should not try to change something which is not really
broken... ;-)
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
--
^ permalink raw reply
* Re: [PATCH net-next] tcp: reduce memory needs of out of order queue
From: Rick Jones @ 2011-10-17 16:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1318660775.2525.29.camel@edumazet-laptop>
>
> Rick, could you redo the test, using following bit on receiver :
>
> echo 1>/proc/sys/net/ipv4/tcp_adv_win_scale
raj@tardy:~/netperf2_trunk$ netstat -s > before; src/netperf -H
raj-8510w.americas.hpqcorp.net -t tcp_rr -- -b 256 -D -o
throughput,local_transport_retrans,remote_transport_retrans,lss_size_end,rsr_size_end
; netstat -s > afterMIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0
(0.0.0.0) port 0 AF_INET to internal-host.americas.hpqcorp.net
(16.89.245.115) port 0 AF_INET : nodelay : first burst 256
Throughput,Local Transport Retransmissions,Remote Transport
Retransmissions,Local Send Socket Size Final,Remote Recv Socket Size Final
78527.68,289,0,16384,98304
Deltas on the receiver:
TcpExt:
27 packets pruned from receive queue because of socket buffer overrun
0 TCP sockets finished time wait in fast timer
0 delayed acks sent
0 delayed acks further delayed because of locked socket
Quick ack mode was activated 0 times
19 packets directly queued to recvmsg prequeue.
0 bytes directly in process context from backlog
670 bytes directly received in process context from prequeue
739983 packet headers predicted
14 packets header predicted and directly queued to user
127 acknowledgments not containing data payload received
235774 predicted acknowledgments
0 other TCP timeouts
6553 packets collapsed in receive queue due to low socket buffer
0 DSACKs sent for old packets
TCPBacklogDrop: 294
So, moving on to:
> If you still have collapses/retransmits, you then could try :
>
> echo -2>/proc/sys/net/ipv4/tcp_adv_win_scale
raj@tardy:~/netperf2_trunk$ netstat -s > before; src/netperf -H
raj-8510w.americas.hpqcorp.net -t tcp_rr -- -b 256 -D -o
throughput,local_transport_retrans,remote_transport_retrans,lss_size_end,rsr_size_end
; netstat -s > after
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
to internal-host.americas.hpqcorp.net (16.89.245.115) port 0 AF_INET :
nodelay : first burst 256
Throughput,Local Transport Retransmissions,Remote Transport
Retransmissions,Local Send Socket Size Final,Remote Recv Socket Size Final
95981.83,0,0,121200,156600
No retransmissions in that one.
rick
^ permalink raw reply
* Re: [net-next 5/6] ixgbe: add hardware timestamping support
From: Richard Cochran @ 2011-10-17 16:44 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Jacob Keller, netdev, gospo, sassmann
In-Reply-To: <1318854062-3628-6-git-send-email-jeffrey.t.kirsher@intel.com>
On Mon, Oct 17, 2011 at 05:21:01AM -0700, Jeff Kirsher wrote:
> The cyclecounter has the potential to miss a wrap-around of the
> systim register (this should occur no more often than every 35
> seconds) unless some activity regarding the cycle counter occurs at
> least once within this time. This version adds a cycle counter read
> every time the watchdog task is run, which should occur at least once
> within this timeframe. Any packets being timestamped will also count
> as a read due to the call to timecompare_update.
So, is this wrap around due to the fact that you are tied to the
system time via time_compare? Or, putting it another way, can't you
program the hardware time stamping unit so that the registers have
some reasonable resolution (like 64 bits worth of nanoseconds) and
just offer RAW timestamps?
I would really like to move away from the timecompare hacks and
towards a proper PHC->SYS PPS solution.
> This version fixes an issue regarding timecompare not updating
> detected skew after the clock offset is changed due to ptpd or outside
> influence from the OS. Now the skew detection is forced just before we
> hand a timestamp up to the kernel stack
Again, doing the update thing on every packet won't work for real
world PTP scenarios.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] bnx2x: Adding FW 7.0.29.0
From: Dmitry Kravkov @ 2011-10-17 16:12 UTC (permalink / raw)
To: dwmw2@infradead.org
Cc: ben@decadent.org.uk, netdev@vger.kernel.org, Eilon Greenstein
In-Reply-To: <1318860047-5044-1-git-send-email-dmitry@broadcom.com>
Adding netdev
On Mon, 2011-10-17 at 07:00 -0700, Dmitry Kravkov wrote:
> Includes fixes for the following issues:
> 1. (iSCSI) Arrival of un-solicited ASYNC message causes
> firmware to abort the connection with RST.
> 2. (FCoE) There is a probability that truncated FCoE packet on
> RX path won't get detected which might lead to FW assert.
> 3. (iSCSI) Arrival of target-initiated NOP-IN during intense
> ISCSI traffic might lead to FW assert.
> 4. (iSCSI) Chip hangs when in case of retransmission not aligned
> to 4-bytes from the beginning of iSCSI PDU.
> 5. (FCoE) Arrival of packets beyond task IO size can lead to crash.
>
>
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> ---
> The patch also available at:
> http://linux.broadcom.com/eilong/FW-7.0.29.0/0001-bnx2x-Adding-FW-7.0.29.0.patch
> ___
^ permalink raw reply
* Re: [PATCH] iproute2: update CAN bitrate SJW help text
From: Stephen Hemminger @ 2011-10-17 15:58 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Wolfgang Grandegger, Linux Netdev List, linux-can
In-Reply-To: <4E9C4D29.7010302@hartkopp.net>
On Mon, 17 Oct 2011 17:43:37 +0200
Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> The ip-tool from iproute2 already supports to pass a user defined SJW
> value for the in-kernel bittiming calculation. This patch updates the
> help text accordingly.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> ---
>
> diff --git a/ip/iplink_can.c b/ip/iplink_can.c
> index c8af4bc..00e7d98 100644
> --- a/ip/iplink_can.c
> +++ b/ip/iplink_can.c
> @@ -23,7 +23,8 @@ static void usage(void)
> {
> fprintf(stderr,
> "Usage: ip link set DEVICE type can\n"
> - "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] | \n"
> + "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT ] [ sjw SJW "
> + "] ] | \n"
> "\t[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1\n "
> "\t phase-seg2 PHASE-SEG2 [ sjw SJW ] ]\n"
> "\n"
Please update man page as well.
^ permalink raw reply
* Re: [net-next 6/6] ixgbe: change the eeprom version reported by ethtool
From: Joe Perches @ 2011-10-17 15:57 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Emil Tantilov, netdev, gospo, sassmann
In-Reply-To: <1318854062-3628-7-git-send-email-jeffrey.t.kirsher@intel.com>
On Mon, 2011-10-17 at 05:21 -0700, Jeff Kirsher wrote:
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> Use 32bit value starting at offset 0x2d for displaying the firmware
> version in ethtool. This should work for all current ixgbe HW
[]
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
[]
> - snprintf(firmware_version, sizeof(firmware_version), "%d.%d-%d",
> - (adapter->eeprom_version & 0xF000) >> 12,
> - (adapter->eeprom_version & 0x0FF0) >> 4,
> - adapter->eeprom_version & 0x000F);
> + nvm_track_id = (adapter->eeprom_verh << 16) |
> + adapter->eeprom_verl;
> + snprintf(firmware_version, sizeof(firmware_version), "0x%08x",
> + nvm_track_id);
Is ethtool output like proc output considered an abi
that should not be changed?
^ permalink raw reply
* Re: sky2: only 10Mb/s
From: Stephen Hemminger @ 2011-10-17 15:56 UTC (permalink / raw)
To: Pavel Mateja; +Cc: netdev
In-Reply-To: <201110171434.50436.pavel@netsafe.cz>
On Mon, 17 Oct 2011 14:34:50 +0200
Pavel Mateja <pavel@netsafe.cz> wrote:
> Hi,
> I tested new kernel and I have found out I have only 10Mb/s link instead of
> 100Mb/s to my router.
> If I did the git bisect right it was caused by commit
> 4fb99cd6ac4fe6d03a334a6f4ebb2bbfc4b479ed which was submitted by you.
>
> My card is (lspci -v):
> 05:00.0 Ethernet controller: Marvell Technology Group Ltd. Yukon Optima
> 88E8059 [PCIe Gigabit Ethernet Controller with AVB] (rev 11)
> Subsystem: ASUSTeK Computer Inc. Device 8439
> Flags: bus master, fast devsel, latency 0, IRQ 80
> Memory at fe6fc000 (64-bit, non-prefetchable) [size=16K]
> I/O ports at b800 [size=256]
> Expansion ROM at fe6c0000 [disabled] [size=128K]
> Capabilities: [48] Power Management version 3
> Capabilities: [5c] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [c0] Express Legacy Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [130] Device Serial Number a5-89-6d-ff-ff-30-cf-20
> Kernel driver in use: sky2
>
> I'm quite sure it's related to Yukon Optima because "Ethernet controller:
> Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller" in my
> work computer has 100Mb/s with the same kernel and driver.
>
> I got no response on netdev@vger.kernel.org.
> Can you help me?
What is output of dmesg for sky2.
dmesg | grep sky2
The problem is related to PHY setup. Almost all of that is copied from the
vendor driver. It might take a few steps to fix because I don't think I
have one of those cards handy.
^ permalink raw reply
* Re: [net-next 2/6 v2] igb: Check if subordinate VFs are assigned to virtual machines
From: Joe Perches @ 2011-10-17 15:53 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, Greg Rose, netdev, gospo, sassmann, Konrad Rzeszutek Wilk,
Christian Benvenuti, Sathya Perla, Dimitris Michailidis,
Jon Mason, James Smart
In-Reply-To: <1318854062-3628-3-git-send-email-jeffrey.t.kirsher@intel.com>
On Mon, 2011-10-17 at 05:20 -0700, Jeff Kirsher wrote:
> From: Greg Rose <gregory.v.rose@intel.com>
Trivia:
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
[]
> + if (old_vfs) {
> + dev_info(&pdev->dev, "%d pre-allocated VFs found - override "
> + "max_vfs setting of %d\n", old_vfs, max_vfs);
[]
> + dev_err(&pdev->dev, "Unable to allocate memory for VF "
> + "Data Storage\n");
The dev_err line isn't really necessary.
There is a generic allocation failure dump_stack.
Also, please don't split formats into multiple lines.
^ permalink raw reply
* [PATCH] NET: asix: fix ethtool -e for AX88178 USB dongle
From: Grant Grundler @ 2011-10-17 15:51 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, allan, Freddy Xin, Grant Grundler
"ethtool -e ethX" dumps EEPROM data. Patch sets EEPROM length for device.
Ethtool works alot better when the kernel believes the length is > 0.
From: Allan Chou <allan@asix.com.tw>
Signed-off-by: Grant Grundler <grundler@chromium.org>
---
drivers/net/usb/asix.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/asix.c b/drivers/net/usb/asix.c
index 66e5ccb..03a1621 100644
--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -1399,6 +1399,9 @@ static int ax88178_bind(struct usbnet *dev, struct usb_interface *intf)
int ret;
u8 buf[ETH_ALEN];
u32 phyid;
+ struct asix_data *data = (struct asix_data *)&dev->data;
+
+ data->eeprom_len = AX88772_EEPROM_LEN;
usbnet_get_endpoints(dev,intf);
--
1.7.2.3
^ permalink raw reply related
* [PATCH] iproute2: update CAN bitrate SJW help text
From: Oliver Hartkopp @ 2011-10-17 15:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Wolfgang Grandegger, Linux Netdev List, linux-can
The ip-tool from iproute2 already supports to pass a user defined SJW
value for the in-kernel bittiming calculation. This patch updates the
help text accordingly.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/ip/iplink_can.c b/ip/iplink_can.c
index c8af4bc..00e7d98 100644
--- a/ip/iplink_can.c
+++ b/ip/iplink_can.c
@@ -23,7 +23,8 @@ static void usage(void)
{
fprintf(stderr,
"Usage: ip link set DEVICE type can\n"
- "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] | \n"
+ "\t[ bitrate BITRATE [ sample-point SAMPLE-POINT ] [ sjw SJW "
+ "] ] | \n"
"\t[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1\n "
"\t phase-seg2 PHASE-SEG2 [ sjw SJW ] ]\n"
"\n"
^ permalink raw reply related
* Re: [PATCH v2 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Daney @ 2011-10-17 15:41 UTC (permalink / raw)
To: Kumar Gala
Cc: Grant Likely, David Miller, devicetree-discuss, linux-kernel,
netdev
In-Reply-To: <C81814FF-4E56-4B28-8043-F874EE1D6B51@kernel.crashing.org>
On 10/17/2011 07:48 AM, Kumar Gala wrote:
>
> On Sep 29, 2011, at 7:32 PM, Grant Likely wrote:
>
>> On Thu, Sep 29, 2011 at 04:31:12PM -0400, David Miller wrote:
>>> From: David Daney<david.daney@cavium.com>
>>> Date: Tue, 27 Sep 2011 16:26:52 -0700
>>>
>>>> v2: Update bindings to use "reg" and "mdio-parent-bus" insutead of
>>>> "cell-index" and "parent-bus"
>>>
>>> Grant, when the final version of this patch set is ready how do
>>> you want to handle merging it in?
>>>
>>> I think it would be safe to merge this via your tree, since the
>>> changes made to existing network driver files are rather trivial and
>>> thus merge conflict friendly.
>>
>> Your tree or mine, I'm happy either way. Even if there were
>> conflicts, they would be trivial.
>>
>> Sure, I'll take care of merging it when I see an ack from you.
>>
>>> Actually, I feel like we've discussed this before :-)
>>
>> :)
>>
>> g.
>
> Any updates to these patches?
Not yet, so you didn't miss anything.
They are on my to-do list though
David Daney
^ permalink raw reply
* Re: [PATCH] smsc911x: Add regulator support
From: Mark Brown @ 2011-10-17 15:38 UTC (permalink / raw)
To: Robert MARKLUND; +Cc: netdev@vger.kernel.org, Steve Glendinning, Mathieu Poirer
In-Reply-To: <2B1D156D95AE9B4EAD379CB9E465FE7324AB09E0EE@EXDCVYMBSTM005.EQ1STM.local>
On Mon, Oct 17, 2011 at 05:28:08PM +0200, Robert MARKLUND wrote:
> > If we fail to grab a critical resource for the device like the power
> > supply then we should be failing passing the error back. As I keep
> > saying this is what all the other regulator consumers are doing.
> Most of the boards out there don't have any regulators for the chip(power is always on).
> So when we can't get the regulator, we assume that the power is already on.
> That's why it hasn't been implemented before.
> So adding this functionality will make all the other boards out there fail, to start the driver.
Clearly this issue is going to apply to every single user of the
regulator API which is one reason why it's insane to open code handling
of missing regulators in individual regulator consumer drivers. As I
keep saying you should unconditionally use the regulators and let the
regulator API facilities for stubbing itself out deal with this.
^ permalink raw reply
* RE: [PATCH] smsc911x: Add regulator support
From: Robert MARKLUND @ 2011-10-17 15:28 UTC (permalink / raw)
To: Mark Brown; +Cc: netdev@vger.kernel.org, Steve Glendinning, Mathieu Poirer
In-Reply-To: <20111017143358.GI5448@sirena.org.uk>
> -----Original Message-----
> From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]
> Sent: den 17 oktober 2011 16:34
> To: Robert MARKLUND
> Cc: netdev@vger.kernel.org; Steve Glendinning; Mathieu Poirer
> Subject: Re: [PATCH] smsc911x: Add regulator support
>
> On Mon, Oct 17, 2011 at 04:13:47PM +0200, Robert MARKLUND wrote:
>
> > > You should fix your mail client to word wrap within paragraphs, I've
> > > reformatted it for legibility. Also leave a blank line between
> > > paragraphs for the same reason.
>
> > I have tried but it's not as easy as it sounds :)
> > Does it look better now ?
>
> Yes, thanks.
>
> > > No, you should do what all the other drivers do and actually pay
> > > attention to the errors. If we can't get power to the device that's a
> > > pretty serious problem and the driver ought to fail.
>
> > Then I don't understand the initial comment.
> > Can you please elaborate that one.
>
> If we fail to grab a critical resource for the device like the power
> supply then we should be failing passing the error back. As I keep
> saying this is what all the other regulator consumers are doing.
Most of the boards out there don't have any regulators for the chip(power is always on).
So when we can't get the regulator, we assume that the power is already on.
That's why it hasn't been implemented before.
So adding this functionality will make all the other boards out there fail, to start the driver.
/R
^ permalink raw reply
* Re: [PATCH] iproute2: Conforming to -D_FORTIFY_SOURCE=2 restrictions
From: Stephen Hemminger @ 2011-10-17 15:23 UTC (permalink / raw)
To: Bin Li; +Cc: netdev
In-Reply-To: <CAGBH1r6P_nmVhSQ7d9sj1qU_1VY7QssWm3ftS4mNcQjyAuCcqA@mail.gmail.com>
On Mon, 17 Oct 2011 15:35:35 +0800
Bin Li <libin.charles@gmail.com> wrote:
> (gdb) l
> 161 len = slen;
> 162 if (len > 0) {
> 163 if (len > max)
> 164 invarg("\"ALGOKEY\" makes buffer
> overflow\n", key);
> 165
> 166 strncpy(buf, key, len);
> 167 }
> 168 }
> 169
> 170 alg->alg_key_len = len * 8;
> (gdb) up
> #8 xfrm_state_modify (cmd=<optimized out>, flags=<optimized out>, argc=1,
> argv=0x7fffffffe370) at xfrm_state.c:406
> 406 xfrm_algo_parse((void *)&alg, type,
> name, key,
>
> the compiler passes zero to __builtin___strncpy_chk as the buffer size.
> xfrm_algo_parse is inlined into xfrm_state_modify.
I don't understand, looks like a compiler bug. Call strncpy with
0 length should not be possible since the check was 3 lines
before for len > 0.
^ permalink raw reply
* Re: [PATCH 1/1] ethtool: add ETHTOOL_{G,S}CHANNEL support.
From: Ben Hutchings @ 2011-10-17 15:20 UTC (permalink / raw)
To: Sucheta Chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1317988730-4197-2-git-send-email-sucheta.chakraborty@qlogic.com>
On Fri, 2011-10-07 at 04:58 -0700, Sucheta Chakraborty wrote:
> Used to configure number of tx/ rx/ other channels.
> Reqd. man page changes are included.
[...]
Applied. Thanks and sorry for the delay.
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 2/2] bridge: allow forwarding some link local frames
From: Stephen Hemminger @ 2011-10-17 15:18 UTC (permalink / raw)
To: Ed Swierk; +Cc: David S. Miller, netdev
In-Reply-To: <CAF5U64AYRhZ1e0=-RhSemgaOnewTQSpAoRY2FUrFr252PG98Pw@mail.gmail.com>
On Mon, 17 Oct 2011 07:35:53 -0700
Ed Swierk <eswierk@bigswitch.com> wrote:
> Why is forwarding LLDP (01-80-C2-00-00-0E) frames forbidden? I'm
> testing LLDP in a virtual topology and need the bridge to forward
> them.
>
> If we're worried about standards, there is justification for allowing
> forwarding of LLDP frames. 802.1d-2005 specifies two classes of
> bridge, customer (C-VLAN) and provider (S-VLAN). Customer bridge is
> just new terminology for what was previously just called an
> 802.1d-compliant bridge, while provider bridge is a new class that
> transparently forwards certain control frames.
Because in current 802.1Q (2005) standard there explicit language
that LLDP should not be forwarded. In Section 7.5
Frames that carry control information to determine the active
topology and current extent of each VLAN, i.e., spanning tree
and GVRP BPDUs, and frames from other link constrained
protocols, such as EAPOL and LLDP, are not forwarded.
Permanently configured static entries in the filtering database
(8.2, 8.3, and 8.12) ensure that such frames are discarded by
the Forwarding Process (8.6).
> The only MAC addresses that are not supposed to be forwarded by either
> customer or provider bridges are:
>
> IEEE 802.3 Full Duplex PAUSE operation (01-80-C2-00-00-01)
> IEEE 802.3 Slow_Protocols_Multicast address (01-80-C2-00-00-02)
> IEEE 802.1X PAE address (01-80-C2-00-00-03)
> Provider Bridge Group Address (01-80-C2-00-00-08)
>
> Customer bridges are also not supposed to forward these addresses:
>
> Bridge Group Address (01-80-C2-00-00-00)
> Provider Bridge GVRP Address (01-80-C2-00-00-0D)
> IEEE 802.1AB Link Layer Discovery Protocol multicast address (01-80-C2-00-00-0E)
>
> My application requires a bridge between a pair of interfaces that
> forwards (at least) LLDP frames; call this a provider bridge if you
> care about standards conformance. It sounds like others require
> forwarding 802.1X PAE frames, which appears non-conformant in any
> case.
>
> Standards aside, given that the default behavior is safe and that
> /sys/class/net/brX/bridge/group_fwd_mask is unlikely to be modified by
> accident by a casual user, can we just remove the
> BR_GROUPFWD_RESTRICTED mask and allow users to forward whatever they
Since EAPOL is allowed, and there is a use case for LLDP, allowing
that is probably okay.
I would prefer not to let user break standards by default. You of course are
free to compile what ever you want
^ 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