* Re: [PATCH] CAN: Add Flexcan CAN controller driver
From: Wolfgang Grandegger @ 2010-06-17 19:12 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1276784480-32340-1-git-send-email-mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 06/17/2010 04:21 PM, Marc Kleine-Budde wrote:
> From: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> This core is found on some Freescale SoCs and also some Coldfire
> SoCs. Support for Coldfire is missing though at the moment as
> they have an older revision of the core which does not have RX FIFO
> support.
>
> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> drivers/net/can/Kconfig | 6 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/flexcan.c | 1010 ++++++++++++++++++++++++++++++++++
> include/linux/can/platform/flexcan.h | 20 +
> 4 files changed, 1037 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/can/flexcan.c
> create mode 100644 include/linux/can/platform/flexcan.h
>
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 05b7517..3d932a4 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -63,6 +63,12 @@ config CAN_BFIN
> To compile this driver as a module, choose M here: the
> module will be called bfin_can.
>
> +config CAN_FLEXCAN
> + tristate "Support for Freescale FLEXCAN based chips"
> + depends on CAN_DEV
> + ---help---
> + Say Y here if you want to support for Freescale FlexCAN.
> +
> source "drivers/net/can/mscan/Kconfig"
>
> source "drivers/net/can/sja1000/Kconfig"
> diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
> index 7a702f2..5bf3621 100644
> --- a/drivers/net/can/Makefile
> +++ b/drivers/net/can/Makefile
> @@ -15,5 +15,6 @@ obj-$(CONFIG_CAN_AT91) += at91_can.o
> obj-$(CONFIG_CAN_TI_HECC) += ti_hecc.o
> obj-$(CONFIG_CAN_MCP251X) += mcp251x.o
> obj-$(CONFIG_CAN_BFIN) += bfin_can.o
> +obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o
>
> ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> new file mode 100644
> index 0000000..f341989
> --- /dev/null
> +++ b/drivers/net/can/flexcan.c
> @@ -0,0 +1,1010 @@
> +/*
> + * flexcan.c - FLEXCAN CAN controller driver
> + *
> + * Copyright (c) 2005-2006 Varma Electronics Oy
> + * Copyright (c) 2009 Sascha Hauer, Pengutronix
> + * Copyright (c) 2010 Marc Kleine-Budde, Pengutronix
> + *
> + * Based on code originally by Andrey Volkov <avolkov-ppI4tVfbJvJWk0Htik3J/w@public.gmane.org>
> + *
> + * LICENCE:
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + */
...
> +MODULE_AUTHOR("Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, "
> + "Marc Kleine-Budde <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>");
> +MODULE_LICENSE("GPL v2");
This does not match to the license text above.
Wolfgang.
^ permalink raw reply
* [PATCH] PCI: MSI: Remove unsafe and unnecessary hardware access
From: Ben Hutchings @ 2010-06-17 19:16 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Michael Chan, Matthew Wilcox, linux-pci, netdev
In-Reply-To: <1276564403.19104.28.camel@HP1>
During suspend on an SMP system, {read,write}_msi_msg_desc() may be
called to mask and unmask interrupts on a device that is already in a
reduced power state. At this point memory-mapped registers including
MSI-X tables are not accessible, and config space may not be fully
functional either.
While a device is in a reduced power state its interrupts are
effectively masked and its MSI(-X) state will be restored when it is
brought back to D0. Therefore these functions can simply read and
write msi_desc::msg for devices not in D0.
Further, read_msi_msg_desc() should only ever be used to update a
previously written message, so it can always read msi_desc::msg
and never needs to touch the hardware.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
On Mon, 2010-06-14 at 18:13 -0700, Michael Chan wrote:
> I'm debugging the bnx2 driver which doesn't work after suspend/resume if
> it is running in MSI-X mode. The problem is that during suspend, the
> MSI-X vectors are disabled by the following sequence on x86:
>
> take_cpu_down() -> cpu_disable_common() -> fixup_irqs()
>
> The MSI-X address/data used to disable the vectors are remembered in the
> above sequence. During resume, these address/data are then programmed
> back to the device during pci_restore_state(), causing all the vectors
> to remain disabled.
That's not quite what I see. What I see is that the message is read
back from the table *after* the driver's suspend method has been called.
At this point the device is already in D3 and memory-mapped registers
are not accessible, so we get random bits as the message. At least,
that's what I see happening with the sfc driver.
> Some drivers call free_irq() during suspend and request_irq() during
> resume, and that should avoid the problem. bnx2 and some other drivers
> do not do that. These drivers rely on pci_restore_state() to restore
> the MSI-X vectors to the same working state before suspend.
>
> What's the right way to fix this? Thanks.
This is my attempt, which works for sfc. See if it works for bnx2.
Ben.
drivers/pci/msi.c | 34 +++++++++++-----------------------
1 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 77b68ea..03f04dc 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -196,30 +196,15 @@ void unmask_msi_irq(unsigned int irq)
void read_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg)
{
struct msi_desc *entry = get_irq_desc_msi(desc);
- if (entry->msi_attrib.is_msix) {
- void __iomem *base = entry->mask_base +
- entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;
- msg->address_lo = readl(base + PCI_MSIX_ENTRY_LOWER_ADDR);
- msg->address_hi = readl(base + PCI_MSIX_ENTRY_UPPER_ADDR);
- msg->data = readl(base + PCI_MSIX_ENTRY_DATA);
- } else {
- struct pci_dev *dev = entry->dev;
- int pos = entry->msi_attrib.pos;
- u16 data;
+ /* We do not touch the hardware (which may not even be
+ * accessible at the moment) but return the last message
+ * written. Assert that this is valid, assuming that
+ * valid messages are not all-zeroes. */
+ BUG_ON(!(entry->msg.address_hi | entry->msg.address_lo |
+ entry->msg.data));
- pci_read_config_dword(dev, msi_lower_address_reg(pos),
- &msg->address_lo);
- if (entry->msi_attrib.is_64) {
- pci_read_config_dword(dev, msi_upper_address_reg(pos),
- &msg->address_hi);
- pci_read_config_word(dev, msi_data_reg(pos, 1), &data);
- } else {
- msg->address_hi = 0;
- pci_read_config_word(dev, msi_data_reg(pos, 0), &data);
- }
- msg->data = data;
- }
+ *msg = entry->msg;
}
void read_msi_msg(unsigned int irq, struct msi_msg *msg)
@@ -232,7 +217,10 @@ void read_msi_msg(unsigned int irq, struct msi_msg *msg)
void write_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg)
{
struct msi_desc *entry = get_irq_desc_msi(desc);
- if (entry->msi_attrib.is_msix) {
+
+ if (entry->dev->current_state != PCI_D0) {
+ /* Don't touch the hardware now */
+ } else if (entry->msi_attrib.is_msix) {
void __iomem *base;
base = entry->mask_base +
entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;
--
1.6.2.5
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* Re: [PATCH] gainfar.c : skb_over_panic
From: David Miller @ 2010-06-17 19:20 UTC (permalink / raw)
To: liberty; +Cc: galak, netdev
In-Reply-To: <4C1A4E36.5060902@extricom.com>
From: Eran Liberty <liberty@extricom.com>
Date: Thu, 17 Jun 2010 19:32:54 +0300
> I have demonstrated skb_over_panic with linux 2.6.32.15 on a mpc8548
> based product.
A fix for a similar bug was necessary for the ucc_geth driver,
see below.
The real problem is that skb->data assignment, the rest of the
SKB state has to be reset, and not doing that is what results in
the skb_over_panic calls.
>From db176edc89abbf22e6db6853f8581f9475fe8ec1 Mon Sep 17 00:00:00 2001
From: Sergey Matyukevich <geomatsi@gmail.com>
Date: Mon, 14 Jun 2010 06:35:20 +0000
Subject: [PATCH] ucc_geth: fix for RX skb buffers recycling
This patch implements a proper modification of RX skb buffers before
recycling. Adjusting only skb->data is not enough because after that
skb->tail and skb->len become incorrect.
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/ucc_geth.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 4a34833..807470e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3215,6 +3215,8 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
__func__, __LINE__, (u32) skb);
if (skb) {
skb->data = skb->head + NET_SKB_PAD;
+ skb->len = 0;
+ skb_reset_tail_pointer(skb);
__skb_queue_head(&ugeth->rx_recycle, skb);
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] bridge: fdb cleanup runs too often
From: David Miller @ 2010-06-17 20:55 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100615091412.17e0d656@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 15 Jun 2010 09:14:12 -0700
>
> It is common in end-node, non STP bridges to set forwarding
> delay to zero; which causes the forwarding database cleanup
> to run every clock tick. Change to run only as soon as needed
> or at next ageing timer interval which ever is sooner.
>
> Use round_jiffies_up macro rather than attempting round up
> by changing value.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* pull request: wireless-next-2.6 2010-06-17
From: John W. Linville @ 2010-06-17 21:02 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
David,
Another week, another bunch of patches intende for 2.6.36...
This week's batch includes the usual updates to ath5k, ath9k,
iwlwifi, rt2x00, and other drivers. Also included are a lot of
cleanup/maintenance for mac80211 from Johannes and some IBSS-related
changes from Teemu, as well as a number of other patches from a
variety of contributors.
Please let me know if there are problems!
John
P.S. This also includes a pull of the 2.6.35 bits I sent yesterday
in order to resolve some merge conflicts.
---
The following changes since commit 4de57826810fd2cfeb2ab5c7d003ff9116b8f7ee:
Amit Kumar Salecha (1):
qlcnic: fix register access
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Bruno Randolf (17):
ath5k: more debug prints for resets
ath5k: rename ath5k_txbuf_free() to ath5k_txbuf_free_skb()
ath5k: fix some comment typos
ath5k: fix rx descriptor debugging
ath5k: print more errors when decriptor setup fails
ath5k: reset more pointers after we free skbs
ath5k: unify rx descriptor error handling
ath5k: split descriptor handling and frame receive
ath5k: move checks and stats into new function
ath5k: use direct function calls for descriptors when possible
ath5k: cosmetic changes in ath5k_hw_proc_5212_rx_status()
ath5k: remove pointless rx error overlay struct
ath5k: review and add comments for descriptors
ath5k: update 5210/5211 frame types
ath5k: take descriptor differences between 5210 and 5211 into account
ath5k: review RX descriptor functions
ath5k: report PHY error frames only for chips which need it
Christoph Fritz (1):
mac80211: fix warn, enum may be used uninitialized
Dor Shaish (1):
iwlwifi: Fix null pointer referencing in iwl_dbgfs_rx_queue_read.
Emmanuel Grumbach (2):
iwlwifi: rename rxq->dma_addr
iwlwifi: rename iwl4965_rx_mpdu_res_start
Felix Fietkau (20):
ath9k: fix mac80211 queue lookup for waking up queues
ath9k_htc: use common WMM AC definitions instead of ath9k ones
ath9k: remove duplicate WMM AC definitions
ath9k: remove declarations of some nonexistant functions
ath9k: make ath_get_hal_qnum static
ath9k: fix extending the rx timestamp with the hardware TSF
ath9k: fix queue stopping threshold
ath9k: add a debugfs entry for ignoring CCA on the extension channel in HT40
ath9k_hw: remove a useless function for setting the mac address
ath9k_hw: add register definitions related to PA predistortion
ath9k_hw: add support for parsing PA predistortion related EEPROM fields
ath9k_hw: add functions for controlling PA predistortion calibration
ath9k: implement PA predistortion support
ath9k_hw: remove ATH9K_CAP_CIPHER
ath9k_hw: remove ATH9K_CAP_TXPOW
ath9k_hw: remove ATH9K_CAP_TKIP_MIC
ath9k_hw: remove ATH9K_CAP_TKIP_SPLIT
ath9k_hw: remove ATH9K_CAP_MCAST_KEYSRCH
ath9k/ath9k_htc: remove redundand checks for dual-stream tx support
ath9k_hw: remove ATH9K_CAP_DS
Helmut Schaa (9):
rt2x00: clarify meaning of txdone flags
rt2x00: don't use TXDONE_FALLBACK as success indicator
rt2x00: only set TXDONE_FALLBACK in rt2800pci if the frame was retried
rt2x00: Fix IEEE80211_TX_CTL_MORE_FRAMES handling
rt2x00: Add comment about BBP1_TX_POWER
rt2x00: Fix TX_STA_FIFO handling
rt2x00: Fix typo in rt2800_config_txpower
rt2x00: provide mac80211 a suitable max_rates value
rt2x00: Fix tx status reporting when falling back to the lowest rate
Ivo van Doorn (5):
rt2x00: Enable fallback rates for rt61pci and rt73usb
rt2x00: Update author rt2800lib
rt2x00: Limit TX done looping to number of TX ring entries
rt2x00: Enable HW crypto by default
rt2x00: Synchronize WCID initialization with legacy driver
Joerg Albert (1):
p54pci: add Symbol AP-300 minipci adapters pciid
Johannes Berg (27):
iwlwifi: trace full RX
iwlwifi: print warning about disconnected antennas
cfg80211/mac80211: allow action frame TX/RX in IBSS
mac80211: simplify station/aggregation code
mac80211: use common skb queue
mac80211: use common work struct
mac80211: use common work function
mac80211: common work skb freeing
mac80211: pull mgmt frame rx into rx handler
mac80211: always process blockack action from workqueue
mac80211: move blockack stop due to fragmentation
mac80211: move aggregation callback processing
mac80211: use RCU for RX aggregation
mac80211: use RCU for TX aggregation
mac80211: remove non-irqsafe aggregation callbacks
mac80211: refcount aggregation queue stop
mac80211: make TX aggregation start/stop request async
mac80211: move BA session work
mac80211: defer RX agg session teardown to work
mac80211: fix RX aggregation timer
mac80211: change RX aggregation locking
mac80211: defer TX agg session teardown to work
mac80211: change TX aggregation locking
mac80211: allow drivers to sleep in ampdu_action
mac80211: update aggregation documentation
mac80211: fix mgmt frame accounting
mac80211: bracket driver tracing
John W. Linville (3):
iwlwifi: cancel scan watchdog in iwl_bg_abort_scan
zd1211rw: change ZD_REGDOMAIN_JAPAN_* naming
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Jouni Malinen (2):
mac80211: Protect Deauthentication frame when using MFP
mac80211: Use a separate CCMP PN receive counter for management frames
Juuso Oikarinen (2):
mac80211: Fix circular locking dependency in ARP filter handling
mac80211: Fix ps-qos network latency handling
Kouhei Sutou (1):
zd1211rw: add 0x49 -> JP regulatory domain map
Leann Ogasawara (1):
p54usb: Comment out duplicate Medion MD40900 device id
Luis R. Rodriguez (12):
ath9k_hw: move clock definitions from hw.c to hw.h
ath9k_hw: fix clock rate calculations for ANI
ath9k_hw: clear MIB interrupt causes when skipping ANI adjustments
ath9k_hw: allow for spliting up ANI operations by family
ath9k_hw: add register definitions for the new ANI
ath9k_hw: inform ANI calibration when scanning
ath9k: add new ANI implementation for AR9003
ath9k_hw: enable ANI for AR9003
ath9k_hw: reduce delay on programming INI on AR9003
ath9k_hw: update 5 GHz tx gain tables for femless and high power PA
ath9k: enable AR9003 PCI IDs
ath9k_hw: avoid setting cwmin/cwmax to 0 for IBSS for AR9003
Prarit Bhargava (1):
libertas_tf: Fix warning in lbtf_rx for stats struct
Reinette Chatre (1):
iwlwifi: serialize station management actions
Shanyu Zhao (1):
iwlagn: verify flow id in compressed BA packet
Sujith (1):
ath9k_htc: Fix ampdu_action callback
Teemu Paasikivi (3):
mac80211: Set basic rates while joining ibss network
mac80211: Set changed basic rates flag
mac80211: remove BSS from cfg80211 list when leaving IBSS
Tim Gardner (1):
hostap: Protect against initialization interrupt
Wey-Yi Guy (1):
iwlwifi: cancel run time calibration work when going down
Zhu Yi (1):
wireless: orphan ipw2x00 drivers
ubuntu-A+nqLdfjWwLR7s880joybQ@public.gmane.org (1):
ipw2200: Enable LED by default
Documentation/networking/README.ipw2200 | 2 +-
MAINTAINERS | 10 +-
drivers/net/b44.c | 144 ++--
drivers/net/wireless/ath/ath5k/Makefile | 1 +
drivers/net/wireless/ath/ath5k/ani.c | 20 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 19 +-
drivers/net/wireless/ath/ath5k/attach.c | 2 -
drivers/net/wireless/ath/ath5k/base.c | 373 +++++----
drivers/net/wireless/ath/ath5k/caps.c | 7 -
drivers/net/wireless/ath/ath5k/debug.c | 79 ++-
drivers/net/wireless/ath/ath5k/debug.h | 9 +-
drivers/net/wireless/ath/ath5k/desc.c | 152 ++--
drivers/net/wireless/ath/ath5k/desc.h | 310 ++++----
drivers/net/wireless/ath/ath5k/dma.c | 13 -
drivers/net/wireless/ath/ath5k/eeprom.c | 3 +-
drivers/net/wireless/ath/ath5k/gpio.c | 7 -
drivers/net/wireless/ath/ath5k/pcu.c | 24 -
drivers/net/wireless/ath/ath5k/phy.c | 82 +-
drivers/net/wireless/ath/ath5k/qcu.c | 9 -
drivers/net/wireless/ath/ath5k/reset.c | 64 +--
drivers/net/wireless/ath/ath5k/sysfs.c | 116 +++
drivers/net/wireless/ath/ath9k/Makefile | 3 +-
drivers/net/wireless/ath/ath9k/ani.c | 743 +++++++++++++++++-
drivers/net/wireless/ath/ath9k/ani.h | 78 ++-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 372 +++++++++-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 118 ++-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 6 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.h | 7 +
.../{ar9003_initvals.h => ar9003_2p0_initvals.h} | 254 +++---
.../{ar9003_initvals.h => ar9003_2p2_initvals.h} | 433 +++++-----
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 13 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 4 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 165 ++++-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 13 +
drivers/net/wireless/ath/ath9k/ar9003_mac.h | 5 +
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 714 +++++++++++++++++
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 513 ++++++++++---
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 298 ++++++--
drivers/net/wireless/ath/ath9k/ath9k.h | 85 ++-
drivers/net/wireless/ath/ath9k/beacon.c | 3 +-
drivers/net/wireless/ath/ath9k/common.c | 314 +-------
drivers/net/wireless/ath/ath9k/common.h | 77 +--
drivers/net/wireless/ath/ath9k/debug.c | 68 ++-
drivers/net/wireless/ath/ath9k/debug.h | 2 +
drivers/net/wireless/ath/ath9k/eeprom.c | 29 +
drivers/net/wireless/ath/ath9k/eeprom.h | 5 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 1 +
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 618 ++++++++--------
drivers/net/wireless/ath/ath9k/eeprom_def.c | 1 +
drivers/net/wireless/ath/ath9k/hif_usb.c | 58 +-
drivers/net/wireless/ath/ath9k/hif_usb.h | 2 +
drivers/net/wireless/ath/ath9k/htc.h | 37 +-
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 23 +
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 168 +++-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 491 +++++++------
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 86 ++-
drivers/net/wireless/ath/ath9k/htc_hst.c | 3 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 16 +
drivers/net/wireless/ath/ath9k/hw.c | 185 ++----
drivers/net/wireless/ath/ath9k/hw.h | 91 ++-
drivers/net/wireless/ath/ath9k/init.c | 54 +-
drivers/net/wireless/ath/ath9k/mac.c | 14 +-
drivers/net/wireless/ath/ath9k/mac.h | 13 +-
drivers/net/wireless/ath/ath9k/main.c | 411 ++++------
drivers/net/wireless/ath/ath9k/pci.c | 1 +
drivers/net/wireless/ath/ath9k/rc.c | 184 +++--
drivers/net/wireless/ath/ath9k/recv.c | 296 +++++++-
drivers/net/wireless/ath/ath9k/reg.h | 62 +-
drivers/net/wireless/ath/ath9k/virtual.c | 2 +-
drivers/net/wireless/ath/ath9k/wmi.c | 3 -
drivers/net/wireless/ath/ath9k/xmit.c | 144 ++--
drivers/net/wireless/b43/dma.c | 69 +-
drivers/net/wireless/b43legacy/dma.c | 49 +-
drivers/net/wireless/hostap/hostap_cs.c | 15 +-
drivers/net/wireless/hostap/hostap_hw.c | 13 +
drivers/net/wireless/hostap/hostap_wlan.h | 2 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 18 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 7 +-
drivers/net/wireless/iwlwifi/Kconfig | 6 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 2 +
drivers/net/wireless/iwlwifi/iwl-3945-debugfs.c | 28 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 203 +-----
drivers/net/wireless/iwlwifi/iwl-4965.c | 83 ++-
drivers/net/wireless/iwlwifi/iwl-5000.c | 58 ++-
drivers/net/wireless/iwlwifi/iwl-6000.c | 345 ++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 27 +-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 26 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 230 ++----
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 82 ++-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 123 +++
drivers/net/wireless/iwlwifi/iwl-agn.c | 327 +++++++--
drivers/net/wireless/iwlwifi/iwl-agn.h | 34 +
drivers/net/wireless/iwlwifi/iwl-calib.c | 7 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 5 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 266 +++----
drivers/net/wireless/iwlwifi/iwl-core.h | 23 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 88 +--
drivers/net/wireless/iwlwifi/iwl-dev.h | 80 +-
drivers/net/wireless/iwlwifi/iwl-helpers.h | 27 +
drivers/net/wireless/iwlwifi/iwl-rx.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 41 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 76 +-
drivers/net/wireless/iwlwifi/iwl-sta.h | 29 +
drivers/net/wireless/iwlwifi/iwl-tx.c | 33 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 145 +---
drivers/net/wireless/iwmc3200wifi/hal.c | 2 +-
drivers/net/wireless/iwmc3200wifi/rx.c | 4 +-
drivers/net/wireless/libertas/cmd.c | 37 +-
drivers/net/wireless/libertas/cmdresp.c | 30 +-
drivers/net/wireless/libertas/decl.h | 2 +-
drivers/net/wireless/libertas/dev.h | 6 +
drivers/net/wireless/libertas/ethtool.c | 24 +-
drivers/net/wireless/libertas/if_sdio.c | 58 ++
drivers/net/wireless/libertas/if_usb.c | 12 +-
drivers/net/wireless/libertas/main.c | 79 ++-
drivers/net/wireless/libertas/scan.c | 2 +-
drivers/net/wireless/libertas_tf/if_usb.c | 5 +-
drivers/net/wireless/libertas_tf/main.c | 2 +-
drivers/net/wireless/mwl8k.c | 12 +-
drivers/net/wireless/orinoco/hermes_dld.c | 2 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 4 +-
drivers/net/wireless/orinoco/wext.c | 4 +-
drivers/net/wireless/p54/eeprom.c | 4 +-
drivers/net/wireless/p54/p54pci.c | 2 +
drivers/net/wireless/p54/p54spi.c | 5 +-
drivers/net/wireless/p54/p54usb.c | 6 +-
drivers/net/wireless/prism54/isl_ioctl.c | 11 +-
drivers/net/wireless/rndis_wlan.c | 36 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 17 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 17 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 31 +-
drivers/net/wireless/rt2x00/rt2800.h | 57 ++-
drivers/net/wireless/rt2x00/rt2800lib.c | 210 +++---
drivers/net/wireless/rt2x00/rt2800lib.h | 13 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 136 ++--
drivers/net/wireless/rt2x00/rt2800pci.h | 19 -
drivers/net/wireless/rt2x00/rt2800usb.c | 106 ++--
drivers/net/wireless/rt2x00/rt2800usb.h | 37 -
drivers/net/wireless/rt2x00/rt2x00.h | 42 +-
drivers/net/wireless/rt2x00/rt2x00config.c | 12 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 23 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 7 +-
drivers/net/wireless/rt2x00/rt2x00ht.c | 47 +-
drivers/net/wireless/rt2x00/rt2x00lib.h | 26 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 51 ++-
drivers/net/wireless/rt2x00/rt2x00pci.h | 8 +
drivers/net/wireless/rt2x00/rt2x00queue.c | 43 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 9 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 33 +-
drivers/net/wireless/rt2x00/rt2x00usb.h | 19 -
drivers/net/wireless/rt2x00/rt61pci.c | 59 +-
drivers/net/wireless/rt2x00/rt73usb.c | 51 +-
drivers/net/wireless/wl12xx/Kconfig | 4 +-
drivers/net/wireless/wl12xx/wl1251_main.c | 4 +-
drivers/net/wireless/wl12xx/wl1251_sdio.c | 40 +-
drivers/net/wireless/wl12xx/wl1271.h | 31 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 41 +-
drivers/net/wireless/wl12xx/wl1271_cmd.h | 28 +-
drivers/net/wireless/wl12xx/wl1271_event.c | 10 +-
drivers/net/wireless/wl12xx/wl1271_ini.h | 123 +++
drivers/net/wireless/wl12xx/wl1271_main.c | 95 ++-
drivers/net/wireless/wl12xx/wl1271_sdio.c | 2 +-
drivers/net/wireless/wl12xx/wl1271_testmode.c | 11 +-
drivers/net/wireless/wl12xx/wl1271_tx.c | 36 +-
drivers/net/wireless/wl12xx/wl1271_tx.h | 1 +
drivers/net/wireless/zd1211rw/zd_mac.c | 5 +-
drivers/net/wireless/zd1211rw/zd_mac.h | 3 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 2 +-
drivers/ssb/driver_chipcommon.c | 25 +
drivers/ssb/driver_chipcommon_pmu.c | 17 +-
drivers/ssb/main.c | 76 +--
drivers/ssb/pci.c | 15 +-
include/linux/nl80211.h | 2 +-
include/linux/ssb/ssb.h | 159 +----
include/net/cfg80211.h | 122 +++-
include/net/mac80211.h | 81 +--
net/mac80211/Kconfig | 7 +
net/mac80211/Makefile | 4 +
net/mac80211/agg-rx.c | 123 ++--
net/mac80211/agg-tx.c | 554 ++++++++------
net/mac80211/cfg.c | 75 ++-
net/mac80211/debugfs.c | 154 ++---
net/mac80211/debugfs_key.c | 2 +-
net/mac80211/debugfs_sta.c | 65 +-
net/mac80211/driver-ops.h | 95 ++-
net/mac80211/driver-trace.h | 188 +++---
net/mac80211/ht.c | 50 +-
net/mac80211/ibss.c | 109 ++--
net/mac80211/ieee80211_i.h | 71 +-
net/mac80211/iface.c | 188 ++++-
net/mac80211/key.c | 290 ++------
net/mac80211/key.h | 30 +-
net/mac80211/main.c | 116 +++-
net/mac80211/mesh.c | 73 +--
net/mac80211/mesh.h | 2 -
net/mac80211/mesh_hwmp.c | 4 +-
net/mac80211/mesh_pathtbl.c | 4 +-
net/mac80211/mlme.c | 200 +----
net/mac80211/pm.c | 18 +-
net/mac80211/rate.h | 13 +
net/mac80211/rc80211_minstrel_ht.c | 824 ++++++++++++++++++++
net/mac80211/rc80211_minstrel_ht.h | 128 +++
net/mac80211/rc80211_minstrel_ht_debugfs.c | 120 +++
net/mac80211/rx.c | 175 +++--
net/mac80211/sta_info.c | 22 +-
net/mac80211/sta_info.h | 97 ++-
net/mac80211/status.c | 2 +-
net/mac80211/tx.c | 93 ++-
net/mac80211/util.c | 31 +-
net/mac80211/work.c | 4 +-
net/mac80211/wpa.c | 8 +-
net/wireless/chan.c | 5 +-
net/wireless/core.h | 1 +
net/wireless/mlme.c | 8 +-
net/wireless/nl80211.c | 58 ++-
218 files changed, 11254 insertions(+), 6435 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath5k/sysfs.c
copy drivers/net/wireless/ath/ath9k/{ar9003_initvals.h => ar9003_2p0_initvals.h} (87%)
rename drivers/net/wireless/ath/ath9k/{ar9003_initvals.h => ar9003_2p2_initvals.h} (78%)
create mode 100644 drivers/net/wireless/ath/ath9k/ar9003_paprd.c
create mode 100644 drivers/net/wireless/wl12xx/wl1271_ini.h
create mode 100644 net/mac80211/rc80211_minstrel_ht.c
create mode 100644 net/mac80211/rc80211_minstrel_ht.h
create mode 100644 net/mac80211/rc80211_minstrel_ht_debugfs.c
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-06-17.patch.bz2
--
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
* Re: [0/8] netpoll/bridge fixes
From: Paul E. McKenney @ 2010-06-17 21:26 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, herbert, eric.dumazet, shemminger, frzhang, netdev,
amwang, mpm
In-Reply-To: <20100617101830.GJ7912@redhat.com>
On Thu, Jun 17, 2010 at 01:18:30PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jun 16, 2010 at 04:02:49PM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 15, 2010 at 09:47:02PM -0700, David Miller wrote:
> > > From: Herbert Xu <herbert@gondor.apana.org.au>
> > > Date: Wed, 16 Jun 2010 13:33:36 +1000
> > >
> > > > On Wed, Jun 16, 2010 at 05:03:20AM +0200, Eric Dumazet wrote:
> > > >>
> > > >> I wonder how these patches were tested, Herbert ?
> > > >
> > > > You know, not everyone enables RCU debugging...
> > >
> > > Even though I'm as guilty as you, I have to agree with Eric that
> > > especially us core folks should be running with the various lock
> > > debugging options on all the time.
> > >
> > > Maybe someone should add the RCU debugging config option to
> > > Documentation/SubmitChecklist :-)
> >
> > How about the following added to Documentation/RCU/checklist.txt?
> >
> > The first is in mainline, the second partly there, and the third
> > is still languishing in my tree. I did manage to remove a dependency
> > on other maintainers, so things will hopefully move a bit faster.
> >
> > Thanx, Paul
> >
> > diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
> > index 790d1a8..c7c6788 100644
> > --- a/Documentation/RCU/checklist.txt
> > +++ b/Documentation/RCU/checklist.txt
> > @@ -365,3 +365,26 @@ over a rather long period of time, but improvements are always welcome!
> > and the compiler to freely reorder code into and out of RCU
> > read-side critical sections. It is the responsibility of the
> > RCU update-side primitives to deal with this.
> > +
> > +17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
> > + the __rcu sparse checks to validate your RCU code. These
> > + can help find problems as follows:
> > +
> > + CONFIG_PROVE_RCU: check that accesses to RCU-protected data
> > + structures are carried out under the proper RCU
> > + read-side critical section, while holding the right
> > + combination of locks, or whatever other conditions
> > + are appropriate.
> > +
> > + CONFIG_DEBUG_OBJECTS_RCU_HEAD: check that you don't pass the
> > + same object to call_rcu() (or friends) before an RCU
> > + grace period has elapsed since the last time that you
> > + passed that same object to call_rcu() (or friends).
> > +
>
> Cool, will this also work with synchronize etc?
Unfortunately, it will not. With call_rcu() and friends you can tag
the struct rcu_head and track it. With synchronize_rcu() and friends,
there is nothing to track. :-(
Thanx, Paul
> > + __rcu sparse checks: tag the pointer to the RCU-protected data
> > + structure with __rcu, and sparse will warn you if you
> > + access that pointer without the services of one of the
> > + variants of rcu_dereference().
> > +
> > + These debugging aids can help you find problems that are
> > + otherwise extremely difficult to spot.
^ permalink raw reply
* Re: [PATCH] PCI: MSI: Remove unsafe and unnecessary hardware access
From: Michael Chan @ 2010-06-17 23:58 UTC (permalink / raw)
To: Ben Hutchings
Cc: Jesse Barnes, Matthew Wilcox, linux-pci@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <1276802196.2083.12.camel@achroite.uk.solarflarecom.com>
On Thu, 2010-06-17 at 12:16 -0700, Ben Hutchings wrote:
> During suspend on an SMP system, {read,write}_msi_msg_desc() may be
> called to mask and unmask interrupts on a device that is already in a
> reduced power state. At this point memory-mapped registers including
> MSI-X tables are not accessible, and config space may not be fully
> functional either.
>
> While a device is in a reduced power state its interrupts are
> effectively masked and its MSI(-X) state will be restored when it is
> brought back to D0. Therefore these functions can simply read and
> write msi_desc::msg for devices not in D0.
>
> Further, read_msi_msg_desc() should only ever be used to update a
> previously written message, so it can always read msi_desc::msg
> and never needs to touch the hardware.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
This works for me too. Thanks Ben.
> ---
> On Mon, 2010-06-14 at 18:13 -0700, Michael Chan wrote:
> > I'm debugging the bnx2 driver which doesn't work after suspend/resume if
> > it is running in MSI-X mode. The problem is that during suspend, the
> > MSI-X vectors are disabled by the following sequence on x86:
> >
> > take_cpu_down() -> cpu_disable_common() -> fixup_irqs()
> >
> > The MSI-X address/data used to disable the vectors are remembered in the
> > above sequence. During resume, these address/data are then programmed
> > back to the device during pci_restore_state(), causing all the vectors
> > to remain disabled.
>
> That's not quite what I see. What I see is that the message is read
> back from the table *after* the driver's suspend method has been called.
> At this point the device is already in D3 and memory-mapped registers
> are not accessible, so we get random bits as the message. At least,
> that's what I see happening with the sfc driver.
>
> > Some drivers call free_irq() during suspend and request_irq() during
> > resume, and that should avoid the problem. bnx2 and some other drivers
> > do not do that. These drivers rely on pci_restore_state() to restore
> > the MSI-X vectors to the same working state before suspend.
> >
> > What's the right way to fix this? Thanks.
>
> This is my attempt, which works for sfc. See if it works for bnx2.
>
> Ben.
>
> drivers/pci/msi.c | 34 +++++++++++-----------------------
> 1 files changed, 11 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 77b68ea..03f04dc 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -196,30 +196,15 @@ void unmask_msi_irq(unsigned int irq)
> void read_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg)
> {
> struct msi_desc *entry = get_irq_desc_msi(desc);
> - if (entry->msi_attrib.is_msix) {
> - void __iomem *base = entry->mask_base +
> - entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;
>
> - msg->address_lo = readl(base + PCI_MSIX_ENTRY_LOWER_ADDR);
> - msg->address_hi = readl(base + PCI_MSIX_ENTRY_UPPER_ADDR);
> - msg->data = readl(base + PCI_MSIX_ENTRY_DATA);
> - } else {
> - struct pci_dev *dev = entry->dev;
> - int pos = entry->msi_attrib.pos;
> - u16 data;
> + /* We do not touch the hardware (which may not even be
> + * accessible at the moment) but return the last message
> + * written. Assert that this is valid, assuming that
> + * valid messages are not all-zeroes. */
> + BUG_ON(!(entry->msg.address_hi | entry->msg.address_lo |
> + entry->msg.data));
>
> - pci_read_config_dword(dev, msi_lower_address_reg(pos),
> - &msg->address_lo);
> - if (entry->msi_attrib.is_64) {
> - pci_read_config_dword(dev, msi_upper_address_reg(pos),
> - &msg->address_hi);
> - pci_read_config_word(dev, msi_data_reg(pos, 1), &data);
> - } else {
> - msg->address_hi = 0;
> - pci_read_config_word(dev, msi_data_reg(pos, 0), &data);
> - }
> - msg->data = data;
> - }
> + *msg = entry->msg;
> }
>
> void read_msi_msg(unsigned int irq, struct msi_msg *msg)
> @@ -232,7 +217,10 @@ void read_msi_msg(unsigned int irq, struct msi_msg *msg)
> void write_msi_msg_desc(struct irq_desc *desc, struct msi_msg *msg)
> {
> struct msi_desc *entry = get_irq_desc_msi(desc);
> - if (entry->msi_attrib.is_msix) {
> +
> + if (entry->dev->current_state != PCI_D0) {
> + /* Don't touch the hardware now */
> + } else if (entry->msi_attrib.is_msix) {
> void __iomem *base;
> base = entry->mask_base +
> entry->msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE;
> --
> 1.6.2.5
>
>
^ permalink raw reply
* Re: [PATCH v2 2/2] broadcom: Add 5241 support
From: Matt Carlson @ 2010-06-18 1:22 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: netdev@vger.kernel.org, David S. Miller, Matthew Carlson,
Michael Chan
In-Reply-To: <1276765344-12675-2-git-send-email-dbaryshkov@gmail.com>
On Thu, Jun 17, 2010 at 02:02:24AM -0700, Dmitry Eremin-Solenikov wrote:
> This patch adds the 5241 PHY ID to the broadcom module.
This looks O.K. to me. I'm curious, do the LEDs behave as
you expect them to?
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
> drivers/net/phy/broadcom.c | 22 ++++++++++++++++++++++
> include/linux/brcmphy.h | 1 +
> 2 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
> index b743d37..4accd83 100644
> --- a/drivers/net/phy/broadcom.c
> +++ b/drivers/net/phy/broadcom.c
> @@ -834,6 +834,21 @@ static struct phy_driver bcmac131_driver = {
> .driver = { .owner = THIS_MODULE },
> };
>
> +static struct phy_driver bcm5241_driver = {
> + .phy_id = PHY_ID_BCM5241,
> + .phy_id_mask = 0xfffffff0,
> + .name = "Broadcom BCM5241",
> + .features = PHY_BASIC_FEATURES |
> + SUPPORTED_Pause | SUPPORTED_Asym_Pause,
> + .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
> + .config_init = brcm_fet_config_init,
> + .config_aneg = genphy_config_aneg,
> + .read_status = genphy_read_status,
> + .ack_interrupt = brcm_fet_ack_interrupt,
> + .config_intr = brcm_fet_config_intr,
> + .driver = { .owner = THIS_MODULE },
> +};
> +
> static int __init broadcom_init(void)
> {
> int ret;
> @@ -868,8 +883,13 @@ static int __init broadcom_init(void)
> ret = phy_driver_register(&bcmac131_driver);
> if (ret)
> goto out_ac131;
> + ret = phy_driver_register(&bcm5241_driver);
> + if (ret)
> + goto out_5241;
> return ret;
>
> +out_5241:
> + phy_driver_unregister(&bcmac131_driver);
> out_ac131:
> phy_driver_unregister(&bcm57780_driver);
> out_57780:
> @@ -894,6 +914,7 @@ out_5411:
>
> static void __exit broadcom_exit(void)
> {
> + phy_driver_unregister(&bcm5241_driver);
> phy_driver_unregister(&bcmac131_driver);
> phy_driver_unregister(&bcm57780_driver);
> phy_driver_unregister(&bcm50610m_driver);
> @@ -920,6 +941,7 @@ static struct mdio_device_id broadcom_tbl[] = {
> { PHY_ID_BCM50610M, 0xfffffff0 },
> { PHY_ID_BCM57780, 0xfffffff0 },
> { PHY_ID_BCMAC131, 0xfffffff0 },
> + { PHY_ID_BCM5241, 0xfffffff0 },
> { }
> };
>
> diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
> index c14c3a1..b840a49 100644
> --- a/include/linux/brcmphy.h
> +++ b/include/linux/brcmphy.h
> @@ -1,5 +1,6 @@
> #define PHY_ID_BCM50610 0x0143bd60
> #define PHY_ID_BCM50610M 0x0143bd70
> +#define PHY_ID_BCM5241 0x0143bc30
> #define PHY_ID_BCMAC131 0x0143bc70
> #define PHY_ID_BCM5481 0x0143bca0
> #define PHY_ID_BCM5482 0x0143bcb0
> --
> 1.7.1
>
>
^ permalink raw reply
* Re: BUG: double spinlock in "drivers/net/3c505.c"
From: David Miller @ 2010-06-18 3:12 UTC (permalink / raw)
To: chf.fritz; +Cc: strakh, philb, craigs, tridge, Alan.Cox, netdev, linux-kernel
In-Reply-To: <1276003605.3916.14.camel@lovely>
From: Christoph Fritz <chf.fritz@googlemail.com>
Date: Tue, 08 Jun 2010 15:26:45 +0200
> On Mon, 2010-06-07 at 15:17 +0400, Alexander Strakh wrote:
>> KERNEL_VERSION: 2.6.35-rc1
>> SUBJECT: duble spinlock in function elp_start_xmit
>
> Not only in elp_start_xmit. This driver is for a pretty old and slow isa
> ethernet card and I think nobody cares. To quote a comment from the
> source: "[...] the concurrency protection is particularly awful".
Indeed, I spent some time trying to unravel the locking mess
for these call chains to check_3c505_dma() and it was just
too much to sanely cure.
^ permalink raw reply
* Re: [PATCH 8/8] bridge: Fix netpoll support
From: Cong Wang @ 2010-06-18 3:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael S. Tsirkin, Qianfeng Zhang, David S. Miller, netdev,
Stephen Hemminger, Matt Mackall, Paul E. McKenney
In-Reply-To: <20100617105526.GA1440@gondor.apana.org.au>
On 06/17/10 18:55, Herbert Xu wrote:
> On Thu, Jun 17, 2010 at 06:57:28PM +0800, Cong Wang wrote:
>>
>> Hmm, I get it now. So this helps to fix problem 3)?
>
> Yes, by allocating real netpoll structures for each device that
> we're polling, instead of sharing a single one amongst all of
> them.
>
> This is also the basis of the solution of the use-after-free bug.
>
Looks reasonable.
Thank you for your patch!
^ permalink raw reply
* Re: [Patch 2/2] mlx4: add dynamic LRO disable support
From: Cong Wang @ 2010-06-18 3:10 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Ben Hutchings, netdev, herbert.xu, nhorman, davem
In-Reply-To: <20100617120318.GA4059@dhcp-lab-161.englab.brq.redhat.com>
On 06/17/10 20:03, Stanislaw Gruszka wrote:
> On Thu, Jun 17, 2010 at 06:54:28PM +0800, Cong Wang wrote:
>>>> I don't think mdev->state_lock is used to protect dev->feature.
>>>> rtnl_lock is. I think switching to mlx4_ethtool_op_set_flags()
>>>> from the default one has already solved this.
>>>
>>> Ahh, you have right, may intention was use it to stop and start
>>> port. Code rather should look like below:
>>>
>>> if (netdev_running(dev)) {
>>> mutex_lock(&mdev->state_lock);
>>> mlx4_en_stop_port(dev);
>>> }
>>>
>>> dev->features ^= NETIF_F_LRO;
>>>
>>> if (netdev_running(dev)) {
>>> rc = mlx4_en_start_port(dev);
>>> mutex_unlock(&mdev->state_lock);
>>> if (rc)
>>> en_err(priv, "Failed to restart port\n");
>>> }
>>>
>>
>> Hmm, you mean ->features should be changed after port is stopped?
>
> Actually not ->features variable, but NETIF_F_LRO bit, as only this
> bit is used in rx path.
>
Yeah, this is what I meant.
>> Why?
>
> For reasons you talked before in this thread :) to do not change
> LRO in the middle of receiving packages.
>
Ohh... I missed this, seems reasonable, will fix this in the next update.
Thanks.
^ permalink raw reply
* [net-next-2.6 PATCH 1/4] e1000e: avoid polling h/w registers during link negotiation
From: Jeff Kirsher @ 2010-06-18 4:58 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Bruce Allan, Jeff Kirsher
From: Bruce Allan <bruce.w.allan@intel.com>
Avoid touching hardware registers when possible, otherwise link negotiation
can get messed up when user-level scripts are rapidly polling the driver to
see if/when link is up. Use the saved link state information instead when
possible.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/e1000.h | 1 -
drivers/net/e1000e/ethtool.c | 54 ++++++++++++++++++++++--------------------
drivers/net/e1000e/netdev.c | 2 +-
3 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index 328b7f4..9ee133f 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -461,7 +461,6 @@ extern int e1000e_setup_tx_resources(struct e1000_adapter *adapter);
extern void e1000e_free_rx_resources(struct e1000_adapter *adapter);
extern void e1000e_free_tx_resources(struct e1000_adapter *adapter);
extern void e1000e_update_stats(struct e1000_adapter *adapter);
-extern bool e1000e_has_link(struct e1000_adapter *adapter);
extern void e1000e_set_interrupt_capability(struct e1000_adapter *adapter);
extern void e1000e_reset_interrupt_capability(struct e1000_adapter *adapter);
extern void e1000e_disable_aspm(struct pci_dev *pdev, u16 state);
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index db86850..77c5829 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -118,7 +118,6 @@ static int e1000_get_settings(struct net_device *netdev,
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
- u32 status;
if (hw->phy.media_type == e1000_media_type_copper) {
@@ -156,22 +155,29 @@ static int e1000_get_settings(struct net_device *netdev,
ecmd->transceiver = XCVR_EXTERNAL;
}
- status = er32(STATUS);
- if (status & E1000_STATUS_LU) {
- if (status & E1000_STATUS_SPEED_1000)
- ecmd->speed = 1000;
- else if (status & E1000_STATUS_SPEED_100)
- ecmd->speed = 100;
- else
- ecmd->speed = 10;
+ ecmd->speed = -1;
+ ecmd->duplex = -1;
- if (status & E1000_STATUS_FD)
- ecmd->duplex = DUPLEX_FULL;
- else
- ecmd->duplex = DUPLEX_HALF;
+ if (netif_running(netdev)) {
+ if (netif_carrier_ok(netdev)) {
+ ecmd->speed = adapter->link_speed;
+ ecmd->duplex = adapter->link_duplex - 1;
+ }
} else {
- ecmd->speed = -1;
- ecmd->duplex = -1;
+ u32 status = er32(STATUS);
+ if (status & E1000_STATUS_LU) {
+ if (status & E1000_STATUS_SPEED_1000)
+ ecmd->speed = 1000;
+ else if (status & E1000_STATUS_SPEED_100)
+ ecmd->speed = 100;
+ else
+ ecmd->speed = 10;
+
+ if (status & E1000_STATUS_FD)
+ ecmd->duplex = DUPLEX_FULL;
+ else
+ ecmd->duplex = DUPLEX_HALF;
+ }
}
ecmd->autoneg = ((hw->phy.media_type == e1000_media_type_fiber) ||
@@ -179,7 +185,7 @@ static int e1000_get_settings(struct net_device *netdev,
/* MDI-X => 2; MDI =>1; Invalid =>0 */
if ((hw->phy.media_type == e1000_media_type_copper) &&
- !hw->mac.get_link_status)
+ netif_carrier_ok(netdev))
ecmd->eth_tp_mdix = hw->phy.is_mdix ? ETH_TP_MDI_X :
ETH_TP_MDI;
else
@@ -191,19 +197,15 @@ static int e1000_get_settings(struct net_device *netdev,
static u32 e1000_get_link(struct net_device *netdev)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
- struct e1000_mac_info *mac = &adapter->hw.mac;
+ struct e1000_hw *hw = &adapter->hw;
/*
- * If the link is not reported up to netdev, interrupts are disabled,
- * and so the physical link state may have changed since we last
- * looked. Set get_link_status to make sure that the true link
- * state is interrogated, rather than pulling a cached and possibly
- * stale link state from the driver.
+ * Avoid touching hardware registers when possible, otherwise
+ * link negotiation can get messed up when user-level scripts
+ * are rapidly polling the driver to see if link is up.
*/
- if (!netif_carrier_ok(netdev))
- mac->get_link_status = 1;
-
- return e1000e_has_link(adapter);
+ return netif_running(netdev) ? netif_carrier_ok(netdev) :
+ !!(er32(STATUS) & E1000_STATUS_LU);
}
static int e1000_set_spd_dplx(struct e1000_adapter *adapter, u16 spddplx)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 8faf224..2a71889 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3964,7 +3964,7 @@ static void e1000_print_link_info(struct e1000_adapter *adapter)
((ctrl & E1000_CTRL_TFCE) ? "TX" : "None" )));
}
-bool e1000e_has_link(struct e1000_adapter *adapter)
+static bool e1000e_has_link(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
bool link_active = 0;
^ permalink raw reply related
* [net-next-2.6 PATCH 2/4] e1000e: do not touch PHY page 800 registers when link speed is 1000Mbps
From: Jeff Kirsher @ 2010-06-18 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100618045804.6728.37945.stgit@localhost.localdomain>
From: Bruce Allan <bruce.w.allan@intel.com>
The PHY on 82577/82578 has issues when the registers on page 800 are
accessed when in gigabit mode. Do not clear the Wakeup Control register
when resetting the part since it is on page 800 (and will be cleared on
reset anyway).
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 2a71889..aa14976 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3184,8 +3184,6 @@ void e1000e_reset(struct e1000_adapter *adapter)
e1000_get_hw_control(adapter);
ew32(WUC, 0);
- if (adapter->flags2 & FLAG2_HAS_PHY_WAKEUP)
- e1e_wphy(&adapter->hw, BM_WUC, 0);
if (mac->ops.init_hw(hw))
e_err("Hardware Error\n");
^ permalink raw reply related
* [net-next-2.6 PATCH 3/4] e1000e: packet split should not be used with early receive
From: Jeff Kirsher @ 2010-06-18 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100618045804.6728.37945.stgit@localhost.localdomain>
From: Bruce Allan <bruce.w.allan@intel.com>
Originally it was thought there were issues with ICHx/PCH parts with packet
split when jumbo frames were enabled but in fact it is really only when
early-receive is enabled (via ERT register) on these parts. Use packet
split with jumbos but only when early-receive is not enabled.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index aa14976..71592ed 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -2772,7 +2772,7 @@ static void e1000_setup_rctl(struct e1000_adapter *adapter)
* per packet.
*/
pages = PAGE_USE_COUNT(adapter->netdev->mtu);
- if (!(adapter->flags & FLAG_IS_ICH) && (pages <= 3) &&
+ if (!(adapter->flags & FLAG_HAS_ERT) && (pages <= 3) &&
(PAGE_SIZE <= 16384) && (rctl & E1000_RCTL_LPE))
adapter->rx_ps_pages = pages;
else
^ permalink raw reply related
* [net-next-2.6 PATCH 4/4] e1000e: disable gig speed when in S0->Sx transition
From: Jeff Kirsher @ 2010-06-18 4:59 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100618045804.6728.37945.stgit@localhost.localdomain>
From: Bruce Allan <bruce.w.allan@intel.com>
Most of this workaround is necessary for all ICHx/PCH parts so one of
the two MAC-type checks can be removed.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/ich8lan.c | 19 +++++--------------
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index c7292a1..6b5e108 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -3457,21 +3457,12 @@ void e1000e_disable_gig_wol_ich8lan(struct e1000_hw *hw)
{
u32 phy_ctrl;
- switch (hw->mac.type) {
- case e1000_ich8lan:
- case e1000_ich9lan:
- case e1000_ich10lan:
- case e1000_pchlan:
- phy_ctrl = er32(PHY_CTRL);
- phy_ctrl |= E1000_PHY_CTRL_D0A_LPLU |
- E1000_PHY_CTRL_GBE_DISABLE;
- ew32(PHY_CTRL, phy_ctrl);
+ phy_ctrl = er32(PHY_CTRL);
+ phy_ctrl |= E1000_PHY_CTRL_D0A_LPLU | E1000_PHY_CTRL_GBE_DISABLE;
+ ew32(PHY_CTRL, phy_ctrl);
- if (hw->mac.type == e1000_pchlan)
- e1000_phy_hw_reset_ich8lan(hw);
- default:
- break;
- }
+ if (hw->mac.type >= e1000_pchlan)
+ e1000_phy_hw_reset_ich8lan(hw);
}
/**
^ permalink raw reply related
* RE: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
From: Xin, Xiaohui @ 2010-06-18 5:26 UTC (permalink / raw)
To: Herbert Xu
Cc: Stephen Hemminger, netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mst@redhat.com, mingo@elte.hu,
davem@davemloft.net, jdike@linux.intel.com
In-Reply-To: <20100617112119.GB1515@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]
>-----Original Message-----
>From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
>Sent: Thursday, June 17, 2010 7:21 PM
>To: Xin, Xiaohui
>Cc: Stephen Hemminger; netdev@vger.kernel.org; kvm@vger.kernel.org;
>linux-kernel@vger.kernel.org; mst@redhat.com; mingo@elte.hu; davem@davemloft.net;
>jdike@linux.intel.com
>Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
>
>On Sun, Jun 13, 2010 at 04:58:36PM +0800, Xin, Xiaohui wrote:
>>
>> Herbert,
>> In this way, I think we should create 3 functions at least in drivers to allocate rx buffer, to
>receive the rx buffers, and to clean the rx buffers.
>>
>> We can also have another way here. We can provide a function to only substitute
>> alloc_page(), and a function to release the pages when cleaning the rx buffers.
>
>Yes that's exactly what I had in mind.
>
Herbert,
I have questions about the idea above:
1) Since netdev_alloc_skb() is still there, and we only modify alloc_page(),
then we don't need napi_gro_frags() any more, the driver's original receiving
function is ok. Right?
2) Is napi_gro_frags() only suitable for TCP protocol packet?
I have done a small test for ixgbe driver to let it only allocate paged buffers
and found kernel hangs when napi_gro_frags() receives an ARP packet.
3) As I have mentioned above, with this idea, netdev_alloc_skb() will allocate
as usual, the data pointed by skb->data will be copied into the first guest buffer.
That means we should reserve sufficient room in guest buffer. For PS mode
supported driver (for example ixgbe), the room will be more than 128. After 128bytes,
we will put the first frag data. Look into virtio-net.c the function page_to_skb()
and receive_mergeable(), that means we should modify guest virtio-net driver to
compute the offset as the parameter for skb_set_frag().
How do you think about this? Attached is a patch to how to modify the guest driver.
I reserve 512 bytes as an example, and transfer the header len of the skb in hdr->hdr_len.
Thanks
Xiaohui
>Cheers,
>--
>Visit Openswan at http://www.openswan.org/
>Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
>Home Page: http://gondor.apana.org.au/~herbert/
>PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: mod-guest.diff --]
[-- Type: application/octet-stream, Size: 2031 bytes --]
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b0577dd..a4e6988 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -36,7 +36,9 @@ 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 GOOD_COPY_LEN 512
#define VIRTNET_SEND_COMMAND_SG_MAX 2
@@ -147,11 +149,12 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
{
struct sk_buff *skb;
struct skb_vnet_hdr *hdr;
- unsigned int copy, hdr_len, offset;
+ unsigned int copy, hdr_len, offset, end;
char *p;
p = page_address(page);
@@ -172,14 +175,25 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
len -= hdr_len;
p += offset;
- copy = len;
+ if (!hdr->hdr.hdr_len)
+ copy = len;
+ else {
+ copy = hdr->hdr.hdr_len;
+ end = skb_tailroom(skb);
+ printk(KERN_INFO "c %d, e %d\n", copy, end);
+ }
+
if (copy > skb_tailroom(skb))
copy = skb_tailroom(skb);
memcpy(skb_put(skb, copy), p, copy);
len -= copy;
- offset += copy;
+ if (!hdr->hdr.hdr_len)
+ offset += copy;
+ else
+ offset = end;
+ printk(KERN_INFO "off %d\n", offset);
while (len) {
set_skb_frag(skb, page, offset, &len);
page = (struct page *)page->private;
@@ -218,7 +238,12 @@ static int receive_mergeable(struct virtnet_info *vi, struct sk_buff *skb)
len = PAGE_SIZE;
set_skb_frag(skb, page, 0, &len);
-
+ if (hdr->hdr.hdr_len)
+ set_skb_frag(skb, page, 542, &len);
+ else
+ set_skb_frag(skb, page, 0, &len);
--vi->num;
}
return 0;
@@ -311,7 +340,15 @@ static void receive_buf(struct net_device *dev, void *buf, unsigned int len)
skb_shinfo(skb)->gso_type |= SKB_GSO_DODGY;
skb_shinfo(skb)->gso_segs = 0;
}
-
+ skb->ip_summed = 1;
netif_receive_skb(skb);
return;
@@ -479,7 +516,8 @@ again:
received++;
}
- if (vi->num < vi->max / 2) {
+ if (vi->num < vi->max - 10) {
if (!try_fill_recv(vi, GFP_ATOMIC))
schedule_delayed_work(&vi->refill, 0);
}
^ permalink raw reply related
* Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
From: Herbert Xu @ 2010-06-18 5:59 UTC (permalink / raw)
To: Xin, Xiaohui
Cc: Stephen Hemminger, netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mst@redhat.com, mingo@elte.hu,
davem@davemloft.net, jdike@linux.intel.com, Rusty Russell
In-Reply-To: <F2E9EB7348B8264F86B6AB8151CE2D7915089FE4CC@shsmsx502.ccr.corp.intel.com>
On Fri, Jun 18, 2010 at 01:26:49PM +0800, Xin, Xiaohui wrote:
>
> Herbert,
> I have questions about the idea above:
> 1) Since netdev_alloc_skb() is still there, and we only modify alloc_page(),
> then we don't need napi_gro_frags() any more, the driver's original receiving
> function is ok. Right?
Well I was actually thinking about converting all drivers that
need this to napi_gro_frags. But now that you mention it, yes
we could still keep the old interface to minimise the work.
> 2) Is napi_gro_frags() only suitable for TCP protocol packet?
> I have done a small test for ixgbe driver to let it only allocate paged buffers
> and found kernel hangs when napi_gro_frags() receives an ARP packet.
It should work with any packet. In fact, I'm pretty sure the
other drivers (e.g., cxgb3) use that interface for all packets.
> 3) As I have mentioned above, with this idea, netdev_alloc_skb() will allocate
> as usual, the data pointed by skb->data will be copied into the first guest buffer.
> That means we should reserve sufficient room in guest buffer. For PS mode
> supported driver (for example ixgbe), the room will be more than 128. After 128bytes,
> we will put the first frag data. Look into virtio-net.c the function page_to_skb()
> and receive_mergeable(), that means we should modify guest virtio-net driver to
> compute the offset as the parameter for skb_set_frag().
>
> How do you think about this? Attached is a patch to how to modify the guest driver.
> I reserve 512 bytes as an example, and transfer the header len of the skb in hdr->hdr_len.
Expanding the buffer size to 512 bytes to accomodate PS mode
looks reasonable to me.
However, I don't think we should increase the copy threshold to
512 bytes at the same time. I don't have any figures myself but
I think if we are to make such a change it should be a separate
one and come with supporting numbers.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 16187] New: Carrier detection failed in dhcpcd when link is up
From: Grant Grundler @ 2010-06-18 6:16 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, Grant Grundler, Kyle McMartin, bugzilla-daemon,
bugme-daemon, casteyde.christian
In-Reply-To: <20100615142418.f47e8abd.akpm@linux-foundation.org>
On Tue, Jun 15, 2010 at 02:24:18PM -0700, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
I've resync to linus' tree (2.6.35-rc3) and reviewed the output of:
git diff v2.6.34 drivers/net/tulip/
I don't see anything that would affect how link state
changes get reported to user space.
I'm not inclined to believe this is a tulip "bug" unless
core netdev behavior changed and tulip is not longer
doing the right thing.
hth,
grant
^ permalink raw reply
* Distributed Switch Architecture(DSA)
From: Joakim Tjernlund @ 2010-06-18 7:06 UTC (permalink / raw)
To: Lennert Buytenhek, netdev
I am trying to wrap my head around DSA and I need some help.
Assume the example from Lennert:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
If I understand this correctly I get at least 5 virtual I/Fs corresponding
to WAN, LAN1-4, but how is the RGMII I/F modelled?
I guess I will have one "real" ethX I/F which maps to RGMII but do I get one
virtual I/F too?
What use are these virtual I/Fs? Just to read status from the corresponding
ports? Can one TX and RX network pkgs over these I/Fs too?
Now I want to add STP/RSTP to the switch. How would one do that?
Jocke
^ permalink raw reply
* RE: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
From: Xin, Xiaohui @ 2010-06-18 7:14 UTC (permalink / raw)
To: Herbert Xu
Cc: Stephen Hemminger, netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mst@redhat.com, mingo@elte.hu,
davem@davemloft.net, jdike@linux.intel.com, Rusty Russell
In-Reply-To: <20100618055929.GA11333@gondor.apana.org.au>
>-----Original Message-----
>From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
>Sent: Friday, June 18, 2010 1:59 PM
>To: Xin, Xiaohui
>Cc: Stephen Hemminger; netdev@vger.kernel.org; kvm@vger.kernel.org;
>linux-kernel@vger.kernel.org; mst@redhat.com; mingo@elte.hu; davem@davemloft.net;
>jdike@linux.intel.com; Rusty Russell
>Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
>
>On Fri, Jun 18, 2010 at 01:26:49PM +0800, Xin, Xiaohui wrote:
>>
>> Herbert,
>> I have questions about the idea above:
>> 1) Since netdev_alloc_skb() is still there, and we only modify alloc_page(),
>> then we don't need napi_gro_frags() any more, the driver's original receiving
>> function is ok. Right?
>
>Well I was actually thinking about converting all drivers that
>need this to napi_gro_frags. But now that you mention it, yes
>we could still keep the old interface to minimise the work.
>
>> 2) Is napi_gro_frags() only suitable for TCP protocol packet?
>> I have done a small test for ixgbe driver to let it only allocate paged buffers
>> and found kernel hangs when napi_gro_frags() receives an ARP packet.
>
>It should work with any packet. In fact, I'm pretty sure the
>other drivers (e.g., cxgb3) use that interface for all packets.
>
Thanks for the verification. By the way, does that mean that nearly all drivers can use the
same napi_gro_frags() to receive buffers though currently each driver has it's own receiving
function?
>> 3) As I have mentioned above, with this idea, netdev_alloc_skb() will allocate
>> as usual, the data pointed by skb->data will be copied into the first guest buffer.
>> That means we should reserve sufficient room in guest buffer. For PS mode
>> supported driver (for example ixgbe), the room will be more than 128. After 128bytes,
>> we will put the first frag data. Look into virtio-net.c the function page_to_skb()
>> and receive_mergeable(), that means we should modify guest virtio-net driver to
>> compute the offset as the parameter for skb_set_frag().
>>
>> How do you think about this? Attached is a patch to how to modify the guest driver.
>> I reserve 512 bytes as an example, and transfer the header len of the skb in hdr->hdr_len.
>
>Expanding the buffer size to 512 bytes to accomodate PS mode
>looks reasonable to me.
>
>However, I don't think we should increase the copy threshold to
>512 bytes at the same time. I don't have any figures myself but
>I think if we are to make such a change it should be a separate
>one and come with supporting numbers.
>
Let me have a look to see if I can retain the copy threshold as 128 bytes
and copy the header data safely.
>Cheers,
>--
>Visit Openswan at http://www.openswan.org/
>Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
>Home Page: http://gondor.apana.org.au/~herbert/
>PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Lennert Buytenhek @ 2010-06-18 7:33 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF4DC5B7A3.2D318B4E-ONC1257746.00253DA6-C1257746.002714B0@transmode.se>
On Fri, Jun 18, 2010 at 09:06:52AM +0200, Joakim Tjernlund wrote:
> I am trying to wrap my head around DSA and I need some help.
>
> Assume the example from Lennert:
>
> +-----------+ +-----------+
> | | RGMII | |
> | +-------+ +------ 1000baseT MDI ("WAN")
> | | | 6-port +------ 1000baseT MDI ("LAN1")
> | CPU | | ethernet +------ 1000baseT MDI ("LAN2")
> | |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
> | +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
> | | | |
> +-----------+ +-----------+
>
> If I understand this correctly I get at least 5 virtual I/Fs corresponding
> to WAN, LAN1-4, but how is the RGMII I/F modelled?
The RGMII interface is just the interface that your "real" network
driver exports. In the case of the Kirkwood 6281 A0 Reference Design
(which I developed this code on), that would be eth0. After the DSA
driver is instantiated, you don't send or receive over eth0 directly
anymore -- eth0 becomes purely a transport for DSA-tagged packets.
> I guess I will have one "real" ethX I/F which maps to RGMII but do I
> get one virtual I/F too?
You get a virtual interface for each of the ports on the switch (that
are not CPU or inter-switch ports), i.e. all ports on the right of the
diagram -- wan, lan1, lan2, lan3, lan4. These interfaces are created
by net/dsa/slave.c and are called DSA interfaces or slave interfaces.
> What use are these virtual I/Fs? Just to read status from the
> corresponding ports?
That's one of the purposes, yes. There's a polling routine that
periodically checks the status of each of the ports on the switch (via
the MII management interface) and feeds back that status to the virtual
interfaces. I.e. if you plug a cable into lan3, you'll see a syslog
message about the link on the virtual interface lan3 having come up,
with the link speed, etc.
> Can one TX and RX network pkgs over these I/Fs too?
Sure -- that's the whole point.
> Now I want to add STP/RSTP to the switch. How would one do that?
First, you'll want the hardware bridging patches that I posted to
netdev@ a while back, e.g.:
http://patchwork.ozlabs.org/patch/16578/
They aren't in upstream-mergeable form in their current form, but they
do the job. These will propagate brctl addif/delif calls into the switch
chip, so that switching between those ports will be done in hardware.
Now if all you want is regular STP, with that patch you'll be done --
the ->bridge_set_stp_state() hook propagates the spanning tree state of
each of the DSA virtual interfaces into the switch chip automatically.
If you want to use a userspace STP implementation, you'll just have to
make sure that STP state (listening/learning/blocking/forwarding/etc) is
correctly propagated to the switch chip similarly to how it's done in the
patch.
(Ideally, these patches should be reworked to receive bridge configuration
and port status changes via netlink. Unfortunately, I was asked to return
all my Marvell hardware when I left Marvell, so someone else will have to
do this work.)
^ permalink raw reply
* Re: [PATCH 2/2] Driver core: reduce duplicated code
From: Uwe Kleine-König @ 2010-06-18 7:39 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, Greg Kroah-Hartman, Magnus Damm, Rafael J. Wysocki,
Paul Mundt, Dmitry Torokhov, Eric Miao, netdev
In-Reply-To: <20100616205332.GB15837@kroah.com>
Hi Greg,
On Wed, Jun 16, 2010 at 01:53:32PM -0700, Greg KH wrote:
> On Tue, Jun 15, 2010 at 11:05:00AM +0200, Uwe Kleine-König wrote:
> > On Tue, Jun 15, 2010 at 10:47:56AM +0200, Uwe Kleine-König wrote:
> > > This makes the two similar functions platform_device_register_simple
> > > and platform_device_register_data one line inline functions using a new
> > > generic function platform_device_register_resndata.
> > I forgot to add some comments to this mail, ... sorry.
> >
> > - I'm not completely happy with the name of the new function. If
> > someone has a better name please tell me.
>
> I don't like it either, what is "resndata" supposed to stand for?
resources and data -> res'n'data -> resndata.
> > - can platform_device_register_resndata be moved to __init_or_module?
>
> I doubt it, but try it and see if a build warns about it.
for x86_64_defconfig + MODULES=n there are two section mismatches:
dock_add
regulatory_init
regulatory_init is only called from
static int __init cfg80211_init(void)
. (I just sent a patch[1] that moves regulatory_init to .init.text.)
dock_add (in drivers/acpi/dock.c) is a bit harder. I will take a look
later if it can go to .init.text (together with a few more functions),
too.
> > - I moved the kernel docs to the header but didn't test if they are
> > picked up when generating docs. Even if not, there is no better
> > place, is there?
>
> No, that's the proper place, but make sure the docbook source is also
> picking up the .h file, I don't know if it currently does.
It does not, will fix in a v2.
Thanks
Uwe
[1] http://mid.gmane.org/1276846735-12105-2-git-send-email-u.kleine-koenig@pengutronix.de
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external.
From: Herbert Xu @ 2010-06-18 7:45 UTC (permalink / raw)
To: Xin, Xiaohui
Cc: Stephen Hemminger, netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mst@redhat.com, mingo@elte.hu,
davem@davemloft.net, jdike@linux.intel.com, Rusty Russell
In-Reply-To: <F2E9EB7348B8264F86B6AB8151CE2D7915089FE573@shsmsx502.ccr.corp.intel.com>
On Fri, Jun 18, 2010 at 03:14:18PM +0800, Xin, Xiaohui wrote:
>
> Thanks for the verification. By the way, does that mean that nearly all drivers can use the
> same napi_gro_frags() to receive buffers though currently each driver has it's own receiving
> function?
There is no reason why the napi_gro_frags can't be used by any
driver that supports receiving data into pages.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Joakim Tjernlund @ 2010-06-18 9:15 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev
In-Reply-To: <20100618073309.GB14513@mail.wantstofly.org>
Lennert Buytenhek <buytenh@wantstofly.org> wrote on 2010/06/18 09:33:09:
>
> On Fri, Jun 18, 2010 at 09:06:52AM +0200, Joakim Tjernlund wrote:
>
> > I am trying to wrap my head around DSA and I need some help.
> >
> > Assume the example from Lennert:
> >
> > +-----------+ +-----------+
> > | | RGMII | |
> > | +-------+ +------ 1000baseT MDI ("WAN")
> > | | | 6-port +------ 1000baseT MDI ("LAN1")
> > | CPU | | ethernet +------ 1000baseT MDI ("LAN2")
> > | |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
> > | +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
> > | | | |
> > +-----------+ +-----------+
> >
> > If I understand this correctly I get at least 5 virtual I/Fs corresponding
> > to WAN, LAN1-4, but how is the RGMII I/F modelled?
>
> The RGMII interface is just the interface that your "real" network
> driver exports. In the case of the Kirkwood 6281 A0 Reference Design
> (which I developed this code on), that would be eth0. After the DSA
> driver is instantiated, you don't send or receive over eth0 directly
> anymore -- eth0 becomes purely a transport for DSA-tagged packets.
hmm, but how do I send normal pkgs form the CPU to the switch then?
I envision I would get some interface in the CPU I can set an IP address
on and use as a normal I/F which would be switched by the HW switch to
the appropriate port.
>
>
> > I guess I will have one "real" ethX I/F which maps to RGMII but do I
> > get one virtual I/F too?
>
> You get a virtual interface for each of the ports on the switch (that
> are not CPU or inter-switch ports), i.e. all ports on the right of the
> diagram -- wan, lan1, lan2, lan3, lan4. These interfaces are created
> by net/dsa/slave.c and are called DSA interfaces or slave interfaces.
>
>
> > What use are these virtual I/Fs? Just to read status from the
> > corresponding ports?
>
> That's one of the purposes, yes. There's a polling routine that
> periodically checks the status of each of the ports on the switch (via
> the MII management interface) and feeds back that status to the virtual
> interfaces. I.e. if you plug a cable into lan3, you'll see a syslog
> message about the link on the virtual interface lan3 having come up,
> with the link speed, etc.
>
>
> > Can one TX and RX network pkgs over these I/Fs too?
>
> Sure -- that's the whole point.
TX:ing pkgs on such virtual I/F would go directly to the port, bypassing
normal switching?
What about RX? What decides which pkg to route through the switch and
which pgk to send up to the virtual I/F?
>
>
> > Now I want to add STP/RSTP to the switch. How would one do that?
>
> First, you'll want the hardware bridging patches that I posted to
> netdev@ a while back, e.g.:
>
> http://patchwork.ozlabs.org/patch/16578/
I see, will have to study this a bit closer. One question though,
does this disable MAC learning in the linux bridge?
Do you have any idea how to do DSA on a Broadcom switch?
The control plane is an attached with PCI and has a big
user space lib/apps to manage the switch.
>
> They aren't in upstream-mergeable form in their current form, but they
> do the job. These will propagate brctl addif/delif calls into the switch
> chip, so that switching between those ports will be done in hardware.
>
> Now if all you want is regular STP, with that patch you'll be done --
> the ->bridge_set_stp_state() hook propagates the spanning tree state of
> each of the DSA virtual interfaces into the switch chip automatically.
>
> If you want to use a userspace STP implementation, you'll just have to
> make sure that STP state (listening/learning/blocking/forwarding/etc) is
> correctly propagated to the switch chip similarly to how it's done in the
> patch.
>
> (Ideally, these patches should be reworked to receive bridge configuration
> and port status changes via netlink. Unfortunately, I was asked to return
> all my Marvell hardware when I left Marvell, so someone else will have to
> do this work.)
>
^ permalink raw reply
* Re: [PATCH] socketcan: add a driver for FlexCAN controllers.
From: Wolfgang Grandegger @ 2010-06-18 9:47 UTC (permalink / raw)
To: Hans J. Koch; +Cc: netdev, socketcan-core
In-Reply-To: <20100617105201.GA2015@bluebox.local>
Hi Hans-Jürgen,
On 06/17/2010 12:52 PM, Hans J. Koch wrote:
> This adds a driver for FlexCAN based CAN controllers,
> e.g. found in Freescale i.MX35 SoCs.
>
> The original version of this driver was posted by Sascha Hauer in July 2009:
> http://kerneltrap.org/mailarchive/linux-netdev/2009/7/29/6251621
>
> I took this version, added NAPI support, and fixed some problems found
> during testing. Well, here is the result. Please review.
I briefly browsed the patch and various bits and pieces are missing or
not correctly implemented. Marc already pointed out a few of them:
- I do not find can_put/get_echo_skb functions in the code. How is
IFF_ECHO supposed to work?
- Support for CAN_CTRLMODE_BERR_REPORTING and do_get_berr_counter()
seems to be missing.
- Make use of alloc_can_skb() and alloc_can_err_skb().
Wolfgang.
^ 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