* Re: small RPS cache for fragments?
From: David Miller @ 2011-06-06 19:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: rick.jones2, netdev
In-Reply-To: <1307380513.3098.76.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 06 Jun 2011 19:15:13 +0200
> Le lundi 06 juin 2011 à 10:08 -0700, Rick Jones a écrit :
>
>> Mode-rr bonding reorders TCP segments all the time.
>
> Shouldnt TCP frames have DF bit set ?
That has nothing to do with this discussion :-)
DF bit set or not, TCP or UDP, this bonding mode apparently reorders
frames all the time.
^ permalink raw reply
* Re: small RPS cache for fragments?
From: David Miller @ 2011-06-06 19:22 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev
In-Reply-To: <1307380132.8149.2718.camel@tardy>
From: Rick Jones <rick.jones2@hp.com>
Date: Mon, 06 Jun 2011 10:08:52 -0700
> Mode-rr bonding reorders TCP segments all the time.
Oh well, then don't use this if you care about performance at all.
And therefore it's not even worth considering for our RPS fragment
cache.
^ permalink raw reply
* Re: [PATCHv3] net: Define enum for the bits used in features.
From: David Miller @ 2011-06-06 19:20 UTC (permalink / raw)
To: mst; +Cc: maheshb, netdev, therbert, mirqus, shemminger
In-Reply-To: <20110606153253.GB30665@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Mon, 6 Jun 2011 18:32:53 +0300
> On Sun, Jun 05, 2011 at 10:15:37PM -0700, David Miller wrote:
>> Since the GSO accessors deal with mutliple bits, you can create
>> special GSO specific interfaces to manipulate them.
>
> Yes but it's not just GSO.
> It's anything that includes more than 1 feature.
> Examples:
> NETIF_F_ALL_CSUM
> NETIF_F_ALL_TX_OFFLOADS
> NETIF_F_V6_CSUM
> NETIF_F_SOFT_FEATURES
>
> etc
>
> Creating many accessors for each will need a lot
> of code duplication ...
Yet this is something you must resolve in order to change the feature
bit implementation.
Whether this issue is difficult or not to address, it has to be done
either way.
^ permalink raw reply
* Re: Multicast IP packet routed between 2 ports nic on the same host
From: David Stevens @ 2011-06-06 19:17 UTC (permalink / raw)
To: BONNEAU Guy; +Cc: netdev@vger.kernel.org, netdev-owner
In-Reply-To: <24665DDC0D7CF047BD6471A56E615EA628ABF4DE@CA-OPS-MAILBOX.miranda.com>
netdev-owner@vger.kernel.org wrote on 06/06/2011 06:40:26 AM:
> From: BONNEAU Guy <gbonneau@miranda.com>
> I open a second console and I use mreceive to join the same
> multicast group 239.255.200.200:8000 to receive multicast data from
> subnet 172.30.8.xx using the console command : ./mreceive -g 239.
> 255.200.200 -p 8000 -i 172.30.8.31 to the eth1 adapter of my
> workstation. The application starts to receive multicast data and
> advertises the data received. This is also the expected behaviour.
>
> Now this is where the problem begins. As soon as the multicast data
> begin to be received on the eth1 adapter the first console begins to
> advertise multicast data received on eth0 adapter. I am well aware
> that the Linux kernel implements a multicast level 2 routing
> capability. Thus at first glance this seems to be the expected
> behaviour. However... I have forwarding disabled as well as
> mc_forwarding disabled and rp_filter is enabled for both adapters.
> Thus I don't expect the kernel to forward the multicast data from
> eth1 to eth0.
Routing is between multiple machines. You're receiving the
packets on the sockets because they have a binding that matches.
If you only want to receive multicast packets from a particular
interface, then you need to use "SO_BINDTODEVICE" to restrict to
that interface.
Group membership is per-interface, but socket bindings match
against any packets delivered to the entire machine, if you haven't
otherwise restricted it.
+-DLS
^ permalink raw reply
* pull request: wireless-2.6 2011-06-06
From: John W. Linville @ 2011-06-06 19:04 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are a few more fixes intended for 3.0 -- a libertas fix for a
regression related to spurious interrupts, an ath5k fix to disable
"fast" channel switching (since it caused a number of devices to
regress in performance), an ssb fix for a regression that was applying
PCIe workarounds to PCI devices (causing a machine check), an fix for an
iwlagn locking regression, and a mac80211 fix for a device-naming
regression.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 5fb9fb132c5a83010cd8d4bf6d0ee34fb3b9d488:
net: fix smc91x.c device tree support (2011-06-05 17:02:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git for-davem
Daniel Drake (1):
libertas_sdio: handle spurious interrupts
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6 into for-davem
Nick Kossifidis (1):
ath5k: Disable fast channel switching by default
Rafał Miłecki (1):
ssb: fix PCI(e) driver regression causing oops on PCI cards
Stanislaw Gruszka (1):
iwlagn: fix channel switch locking
Thadeu Lima de Souza Cascardo (1):
mac80211: call dev_alloc_name before copying name to sdata
drivers/net/wireless/ath/ath5k/base.c | 11 ++++-
drivers/net/wireless/ath/ath5k/reset.c | 5 ++-
drivers/net/wireless/iwlwifi/iwl-2000.c | 74 ---------------------------
drivers/net/wireless/iwlwifi/iwl-5000.c | 2 -
drivers/net/wireless/iwlwifi/iwl-6000.c | 2 -
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 19 ++++---
drivers/net/wireless/iwlwifi/iwl-core.c | 6 +--
drivers/net/wireless/iwlwifi/iwl-core.h | 1 +
drivers/net/wireless/iwlwifi/iwl-dev.h | 13 +----
drivers/net/wireless/iwlwifi/iwl-rx.c | 24 ++++----
drivers/net/wireless/libertas/if_sdio.c | 21 ++++++--
drivers/ssb/driver_pcicore.c | 10 ++--
net/mac80211/iface.c | 4 ++
14 files changed, 68 insertions(+), 130 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 2204762..b6c5d37 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -72,6 +72,11 @@ static int modparam_all_channels;
module_param_named(all_channels, modparam_all_channels, bool, S_IRUGO);
MODULE_PARM_DESC(all_channels, "Expose all channels the device can use.");
+static int modparam_fastchanswitch;
+module_param_named(fastchanswitch, modparam_fastchanswitch, bool, S_IRUGO);
+MODULE_PARM_DESC(fastchanswitch, "Enable fast channel switching for AR2413/AR5413 radios.");
+
+
/* Module info */
MODULE_AUTHOR("Jiri Slaby");
MODULE_AUTHOR("Nick Kossifidis");
@@ -2686,6 +2691,7 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan,
struct ath5k_hw *ah = sc->ah;
struct ath_common *common = ath5k_hw_common(ah);
int ret, ani_mode;
+ bool fast;
ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
@@ -2705,7 +2711,10 @@ ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan,
ath5k_drain_tx_buffs(sc);
if (chan)
sc->curchan = chan;
- ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, chan != NULL,
+
+ fast = ((chan != NULL) && modparam_fastchanswitch) ? 1 : 0;
+
+ ret = ath5k_hw_reset(ah, sc->opmode, sc->curchan, fast,
skip_pcu);
if (ret) {
ATH5K_ERR(sc, "can't reset hardware (%d)\n", ret);
diff --git a/drivers/net/wireless/ath/ath5k/reset.c b/drivers/net/wireless/ath/ath5k/reset.c
index 3510de2..126a4ea 100644
--- a/drivers/net/wireless/ath/ath5k/reset.c
+++ b/drivers/net/wireless/ath/ath5k/reset.c
@@ -1124,8 +1124,11 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum nl80211_iftype op_mode,
/* Non fatal, can happen eg.
* on mode change */
ret = 0;
- } else
+ } else {
+ ATH5K_DBG(ah->ah_sc, ATH5K_DEBUG_RESET,
+ "fast chan change successful\n");
return 0;
+ }
}
/*
diff --git a/drivers/net/wireless/iwlwifi/iwl-2000.c b/drivers/net/wireless/iwlwifi/iwl-2000.c
index 86feec8..2282279 100644
--- a/drivers/net/wireless/iwlwifi/iwl-2000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-2000.c
@@ -177,79 +177,6 @@ static int iwl2000_hw_set_hw_params(struct iwl_priv *priv)
return 0;
}
-static int iwl2030_hw_channel_switch(struct iwl_priv *priv,
- struct ieee80211_channel_switch *ch_switch)
-{
- /*
- * MULTI-FIXME
- * See iwl_mac_channel_switch.
- */
- struct iwl_rxon_context *ctx = &priv->contexts[IWL_RXON_CTX_BSS];
- struct iwl6000_channel_switch_cmd cmd;
- const struct iwl_channel_info *ch_info;
- u32 switch_time_in_usec, ucode_switch_time;
- u16 ch;
- u32 tsf_low;
- u8 switch_count;
- u16 beacon_interval = le16_to_cpu(ctx->timing.beacon_interval);
- struct ieee80211_vif *vif = ctx->vif;
- struct iwl_host_cmd hcmd = {
- .id = REPLY_CHANNEL_SWITCH,
- .len = { sizeof(cmd), },
- .flags = CMD_SYNC,
- .data = { &cmd, },
- };
-
- cmd.band = priv->band == IEEE80211_BAND_2GHZ;
- ch = ch_switch->channel->hw_value;
- IWL_DEBUG_11H(priv, "channel switch from %u to %u\n",
- ctx->active.channel, ch);
- cmd.channel = cpu_to_le16(ch);
- cmd.rxon_flags = ctx->staging.flags;
- cmd.rxon_filter_flags = ctx->staging.filter_flags;
- switch_count = ch_switch->count;
- tsf_low = ch_switch->timestamp & 0x0ffffffff;
- /*
- * calculate the ucode channel switch time
- * adding TSF as one of the factor for when to switch
- */
- if ((priv->ucode_beacon_time > tsf_low) && beacon_interval) {
- if (switch_count > ((priv->ucode_beacon_time - tsf_low) /
- beacon_interval)) {
- switch_count -= (priv->ucode_beacon_time -
- tsf_low) / beacon_interval;
- } else
- switch_count = 0;
- }
- if (switch_count <= 1)
- cmd.switch_time = cpu_to_le32(priv->ucode_beacon_time);
- else {
- switch_time_in_usec =
- vif->bss_conf.beacon_int * switch_count * TIME_UNIT;
- ucode_switch_time = iwl_usecs_to_beacons(priv,
- switch_time_in_usec,
- beacon_interval);
- cmd.switch_time = iwl_add_beacon_time(priv,
- priv->ucode_beacon_time,
- ucode_switch_time,
- beacon_interval);
- }
- IWL_DEBUG_11H(priv, "uCode time for the switch is 0x%x\n",
- cmd.switch_time);
- ch_info = iwl_get_channel_info(priv, priv->band, ch);
- if (ch_info)
- cmd.expect_beacon = is_channel_radar(ch_info);
- else {
- IWL_ERR(priv, "invalid channel switch from %u to %u\n",
- ctx->active.channel, ch);
- return -EFAULT;
- }
- priv->switch_rxon.channel = cmd.channel;
- priv->switch_rxon.switch_in_progress = true;
-
- return iwl_send_cmd_sync(priv, &hcmd);
-}
-
static struct iwl_lib_ops iwl2000_lib = {
.set_hw_params = iwl2000_hw_set_hw_params,
.rx_handler_setup = iwlagn_rx_handler_setup,
@@ -258,7 +185,6 @@ static struct iwl_lib_ops iwl2000_lib = {
.is_valid_rtc_data_addr = iwlagn_hw_valid_rtc_data_addr,
.send_tx_power = iwlagn_send_tx_power,
.update_chain_flags = iwl_update_chain_flags,
- .set_channel_switch = iwl2030_hw_channel_switch,
.apm_ops = {
.init = iwl_apm_init,
.config = iwl2000_nic_config,
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index a70b8cf..5b721c5 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -331,8 +331,6 @@ static int iwl5000_hw_channel_switch(struct iwl_priv *priv,
ctx->active.channel, ch);
return -EFAULT;
}
- priv->switch_rxon.channel = cmd.channel;
- priv->switch_rxon.switch_in_progress = true;
return iwl_send_cmd_sync(priv, &hcmd);
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index fda6fe0..fbe565c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -270,8 +270,6 @@ static int iwl6000_hw_channel_switch(struct iwl_priv *priv,
ctx->active.channel, ch);
return -EFAULT;
}
- priv->switch_rxon.channel = cmd.channel;
- priv->switch_rxon.switch_in_progress = true;
return iwl_send_cmd_sync(priv, &hcmd);
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
index a95ad84..2532c7d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
@@ -342,10 +342,10 @@ int iwlagn_commit_rxon(struct iwl_priv *priv, struct iwl_rxon_context *ctx)
* receive commit_rxon request
* abort any previous channel switch if still in process
*/
- if (priv->switch_rxon.switch_in_progress &&
- (priv->switch_rxon.channel != ctx->staging.channel)) {
+ if (test_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status) &&
+ (priv->switch_channel != ctx->staging.channel)) {
IWL_DEBUG_11H(priv, "abort channel switch on %d\n",
- le16_to_cpu(priv->switch_rxon.channel));
+ le16_to_cpu(priv->switch_channel));
iwl_chswitch_done(priv, false);
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index a662adc..8e1942e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -2843,16 +2843,13 @@ static void iwlagn_mac_channel_switch(struct ieee80211_hw *hw,
goto out;
if (test_bit(STATUS_EXIT_PENDING, &priv->status) ||
- test_bit(STATUS_SCANNING, &priv->status))
+ test_bit(STATUS_SCANNING, &priv->status) ||
+ test_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status))
goto out;
if (!iwl_is_associated_ctx(ctx))
goto out;
- /* channel switch in progress */
- if (priv->switch_rxon.switch_in_progress == true)
- goto out;
-
if (priv->cfg->ops->lib->set_channel_switch) {
ch = channel->hw_value;
@@ -2901,15 +2898,19 @@ static void iwlagn_mac_channel_switch(struct ieee80211_hw *hw,
* at this point, staging_rxon has the
* configuration for channel switch
*/
+ set_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status);
+ priv->switch_channel = cpu_to_le16(ch);
if (priv->cfg->ops->lib->set_channel_switch(priv,
- ch_switch))
- priv->switch_rxon.switch_in_progress = false;
+ ch_switch)) {
+ clear_bit(STATUS_CHANNEL_SWITCH_PENDING,
+ &priv->status);
+ priv->switch_channel = 0;
+ ieee80211_chswitch_done(ctx->vif, false);
+ }
}
}
out:
mutex_unlock(&priv->mutex);
- if (!priv->switch_rxon.switch_in_progress)
- ieee80211_chswitch_done(ctx->vif, false);
IWL_DEBUG_MAC80211(priv, "leave\n");
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 4653dea..213c80c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -843,12 +843,8 @@ void iwl_chswitch_done(struct iwl_priv *priv, bool is_success)
if (test_bit(STATUS_EXIT_PENDING, &priv->status))
return;
- if (priv->switch_rxon.switch_in_progress) {
+ if (test_and_clear_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status))
ieee80211_chswitch_done(ctx->vif, is_success);
- mutex_lock(&priv->mutex);
- priv->switch_rxon.switch_in_progress = false;
- mutex_unlock(&priv->mutex);
- }
}
#ifdef CONFIG_IWLWIFI_DEBUG
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 3bb76f6..a54d416 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -560,6 +560,7 @@ void iwlcore_free_geos(struct iwl_priv *priv);
#define STATUS_POWER_PMI 16
#define STATUS_FW_ERROR 17
#define STATUS_DEVICE_ENABLED 18
+#define STATUS_CHANNEL_SWITCH_PENDING 19
static inline int iwl_is_ready(struct iwl_priv *priv)
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index 22a6e3e..c8de236 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -982,17 +982,6 @@ struct traffic_stats {
};
/*
- * iwl_switch_rxon: "channel switch" structure
- *
- * @ switch_in_progress: channel switch in progress
- * @ channel: new channel
- */
-struct iwl_switch_rxon {
- bool switch_in_progress;
- __le16 channel;
-};
-
-/*
* schedule the timer to wake up every UCODE_TRACE_PERIOD milliseconds
* to perform continuous uCode event logging operation if enabled
*/
@@ -1287,7 +1276,7 @@ struct iwl_priv {
struct iwl_rxon_context contexts[NUM_IWL_RXON_CTX];
- struct iwl_switch_rxon switch_rxon;
+ __le16 switch_channel;
struct {
u32 error_event_table;
diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c
index 0053e9e..b774517 100644
--- a/drivers/net/wireless/iwlwifi/iwl-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
@@ -250,19 +250,19 @@ static void iwl_rx_csa(struct iwl_priv *priv, struct iwl_rx_mem_buffer *rxb)
struct iwl_rxon_context *ctx = &priv->contexts[IWL_RXON_CTX_BSS];
struct iwl_rxon_cmd *rxon = (void *)&ctx->active;
- if (priv->switch_rxon.switch_in_progress) {
- if (!le32_to_cpu(csa->status) &&
- (csa->channel == priv->switch_rxon.channel)) {
- rxon->channel = csa->channel;
- ctx->staging.channel = csa->channel;
- IWL_DEBUG_11H(priv, "CSA notif: channel %d\n",
- le16_to_cpu(csa->channel));
- iwl_chswitch_done(priv, true);
- } else {
- IWL_ERR(priv, "CSA notif (fail) : channel %d\n",
+ if (!test_bit(STATUS_CHANNEL_SWITCH_PENDING, &priv->status))
+ return;
+
+ if (!le32_to_cpu(csa->status) && csa->channel == priv->switch_channel) {
+ rxon->channel = csa->channel;
+ ctx->staging.channel = csa->channel;
+ IWL_DEBUG_11H(priv, "CSA notif: channel %d\n",
le16_to_cpu(csa->channel));
- iwl_chswitch_done(priv, false);
- }
+ iwl_chswitch_done(priv, true);
+ } else {
+ IWL_ERR(priv, "CSA notif (fail) : channel %d\n",
+ le16_to_cpu(csa->channel));
+ iwl_chswitch_done(priv, false);
}
}
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index a7b5cb0..224e985 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -907,7 +907,7 @@ static void if_sdio_interrupt(struct sdio_func *func)
card = sdio_get_drvdata(func);
cause = sdio_readb(card->func, IF_SDIO_H_INT_STATUS, &ret);
- if (ret)
+ if (ret || !cause)
goto out;
lbs_deb_sdio("interrupt: 0x%X\n", (unsigned)cause);
@@ -1008,10 +1008,6 @@ static int if_sdio_probe(struct sdio_func *func,
if (ret)
goto release;
- ret = sdio_claim_irq(func, if_sdio_interrupt);
- if (ret)
- goto disable;
-
/* For 1-bit transfers to the 8686 model, we need to enable the
* interrupt flag in the CCCR register. Set the MMC_QUIRK_LENIENT_FN0
* bit to allow access to non-vendor registers. */
@@ -1083,6 +1079,21 @@ static int if_sdio_probe(struct sdio_func *func,
card->rx_unit = 0;
/*
+ * Set up the interrupt handler late.
+ *
+ * If we set it up earlier, the (buggy) hardware generates a spurious
+ * interrupt, even before the interrupt has been enabled, with
+ * CCCR_INTx = 0.
+ *
+ * We register the interrupt handler late so that we can handle any
+ * spurious interrupts, and also to avoid generation of that known
+ * spurious interrupt in the first place.
+ */
+ ret = sdio_claim_irq(func, if_sdio_interrupt);
+ if (ret)
+ goto disable;
+
+ /*
* Enable interrupts now that everything is set up
*/
sdio_writeb(func, 0x0f, IF_SDIO_H_INT_MASK, &ret);
diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c
index 82feb34..2a20dab 100644
--- a/drivers/ssb/driver_pcicore.c
+++ b/drivers/ssb/driver_pcicore.c
@@ -539,10 +539,12 @@ void ssb_pcicore_init(struct ssb_pcicore *pc)
if (!pc->hostmode)
ssb_pcicore_init_clientmode(pc);
- /* Additional always once-executed workarounds */
- ssb_pcicore_serdes_workaround(pc);
- /* TODO: ASPM */
- /* TODO: Clock Request Update */
+ /* Additional PCIe always once-executed workarounds */
+ if (dev->id.coreid == SSB_DEV_PCIE) {
+ ssb_pcicore_serdes_workaround(pc);
+ /* TODO: ASPM */
+ /* TODO: Clock Request Update */
+ }
}
static u32 ssb_pcie_read(struct ssb_pcicore *pc, u32 address)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 49d4f86..dee30ae 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1145,6 +1145,10 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
+ IEEE80211_ENCRYPT_HEADROOM;
ndev->needed_tailroom = IEEE80211_ENCRYPT_TAILROOM;
+ ret = dev_alloc_name(ndev, ndev->name);
+ if (ret < 0)
+ goto fail;
+
ieee80211_assign_perm_addr(local, ndev, type);
memcpy(ndev->dev_addr, ndev->perm_addr, ETH_ALEN);
SET_NETDEV_DEV(ndev, wiphy_dev(local->hw.wiphy));
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [RFC] breakage in sysfs_readdir() and s_instances abuse in sysfs
From: Eric W. Biederman @ 2011-06-06 19:03 UTC (permalink / raw)
To: Al Viro; +Cc: linux-fsdevel, Linus Torvalds, netdev, Linux Containers
In-Reply-To: <20110604001518.GT11521@ZenIV.linux.org.uk>
Al Viro <viro@ZenIV.linux.org.uk> writes:
> What I'm planning to do (for unrelated reasons - ubifs needs it) is to add
> an analog of iterate_supers() that would go over the superblocks of given
> type and call a function on them. I would like to convert sysfs_exit_ns()
> to it and kill the last abuser of s_instances (and one of the last sb_lock
> ones), but that really depends on what kind of locking is needed for
> readdir() and friends - as it is, the damn thing looks *wrong*.
Answering your primary question first, what locking is needed in
sysfs_exit_ns().
Wrapping my head around this code again, to the best of my memory
the intent was.
For consistency "info->type[ns]" is an atomic value (void *) so
it can be safely read and written without relying on locks. For
things like lookup
The assumption is that is primarily an atomic value and so it can
be safely read by things like sysfs_readdir() and get a valid value
without relying on the locks.
sysfs_mutex is needed in things like sysfs_lookup if we want the
value to not change.
There is indeed a small race in sysfs_readdir.
As for sysfs_lookup it looks like my code to handle untagged members in
directories where everything else is tagged, such as
"/sys/class/net/bonding_masters" introduced an overloading of what NULL
means in the context of sysfs_readdir and sysfs_lookup. ns == NULL can
either mean that we have type == KOBJ_NS_TYPE_NONE, or ns == NULL can
mean that the namespace has gone away beneath us. I looks like I need
to fix that.
To sysfs_exit_ns() we have the call chain:
cleanup_net()
ops_exit_list()
net_kobj_ns_exit()
sysfs_exit_ns()
Which makes the locking order needed for that call path.
net_mutex()
rtnl_lock()
sysfs_mutex()
Now somewhere I was also careful that mount did not cause problems,
with sysfs_exit_ns() but I forget where.
You were asking about kobj_ns_current.
kboj_ns_current()
net_current_ns()
current->nsproxy->net_ns
And current has a reference on it's network namespace.
Other pieces of information that should be helpful to know.
- All sysfs directory entries for a network namespace should be
removed from sysfs by the time sysfs_exit_ns is called.
Al hopefully that is enough to get you going and I will what I can
do with the rest of the sysfs ugliness.
Eric
^ permalink raw reply
* Re: [RFC PATCHv2] ipv6: implementation of reverse path filtering
From: Eric Dumazet @ 2011-06-06 18:18 UTC (permalink / raw)
To: Eric Leblond; +Cc: netdev
In-Reply-To: <1307382805-5753-1-git-send-email-eric@regit.org>
Le lundi 06 juin 2011 à 19:53 +0200, Eric Leblond a écrit :
> This patch provides a basic implementation of reverse path filtering
> for IPv6. Functionnality can be activatedor desactivated through an
> rp_filter entry similar to the IPv4 one.
>
> The functionnality is disabled by default for backward compatibility
> but should be enable on all IPv6 routers/firewalls for security reason.
>
> This implementation is heavily based on the patch Denis Semmau proposed
> in 2006.
>
> Signed-off-by: Eric Leblond <eric@regit.org>
> ---
> include/linux/ipv6.h | 2 ++
> include/linux/sysctl.h | 1 +
> net/ipv6/addrconf.c | 10 ++++++++++
> net/ipv6/ip6_output.c | 35 +++++++++++++++++++++++++++++++++++
> 4 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> index 0c99776..6b61869 100644
> --- a/include/linux/ipv6.h
> +++ b/include/linux/ipv6.h
> @@ -172,6 +172,7 @@ struct ipv6_devconf {
> __s32 disable_ipv6;
> __s32 accept_dad;
> __s32 force_tllao;
> + __s32 rp_filter;
> void *sysctl;
> };
>
> @@ -213,6 +214,7 @@ enum {
> DEVCONF_DISABLE_IPV6,
> DEVCONF_ACCEPT_DAD,
> DEVCONF_FORCE_TLLAO,
> + DEVCONF_RP_FILTER,
> DEVCONF_MAX
> };
>
> diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
> index 11684d9..bdcb7f8 100644
> --- a/include/linux/sysctl.h
> +++ b/include/linux/sysctl.h
> @@ -568,6 +568,7 @@ enum {
> NET_IPV6_ACCEPT_RA_RT_INFO_MAX_PLEN=22,
> NET_IPV6_PROXY_NDP=23,
> NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
> + NET_IPV6_RP_FILTER=26,
not needed ?
> __NET_IPV6_MAX
> };
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 498b927..ba1c574 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -196,6 +196,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
> .accept_source_route = 0, /* we do not accept RH0 by default. */
> .disable_ipv6 = 0,
> .accept_dad = 1,
> + .rp_filter = 0,
> };
>
> static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
> @@ -230,6 +231,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
> .accept_source_route = 0, /* we do not accept RH0 by default. */
> .disable_ipv6 = 0,
> .accept_dad = 1,
> + .rp_filter = 0,
> };
>
> /* IPv6 Wildcard Address and Loopback Address defined by RFC2553 */
> @@ -3805,6 +3807,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
> array[DEVCONF_DISABLE_IPV6] = cnf->disable_ipv6;
> array[DEVCONF_ACCEPT_DAD] = cnf->accept_dad;
> array[DEVCONF_FORCE_TLLAO] = cnf->force_tllao;
> + array[DEVCONF_RP_FILTER] = cnf->rp_filter;
> }
>
> static inline size_t inet6_ifla6_size(void)
> @@ -4459,6 +4462,13 @@ static struct addrconf_sysctl_table
> .proc_handler = proc_dointvec
> },
> {
> + .procname = "rp_filter",
> + .data = &ipv6_devconf.rp_filter,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec
> + },
> + {
> /* sentinel */
> }
> },
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 9d4b165..ad8f351 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -374,6 +374,22 @@ static int ip6_forward_proxy_check(struct sk_buff *skb)
> return 0;
> }
>
> +static int rt6_validate_source(struct sk_buff *skb, char mode)
> +{
> + struct rt6_info *rt;
> + struct ipv6hdr *hdr = ipv6_hdr(skb);
> + if (mode == 0)
> + return 0;
> + rt = rt6_lookup(dev_net(skb->dev), &hdr->saddr, NULL, 0, 0);
> + if (rt != NULL) {
route leak ? you need dst_release(&rt->dst); [ and/or rcu ;) ]
> + if ((mode >= 2) && rt->rt6i_idev->dev)
> + return 0;
> + if ((mode == 1) && (rt->rt6i_idev->dev == skb->dev))
> + return 0;
> + }
> + return -1;
> +}
> +
^ permalink raw reply
* Re: small RPS cache for fragments?
From: Rick Jones @ 2011-06-06 18:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1307380513.3098.76.camel@edumazet-laptop>
On Mon, 2011-06-06 at 19:15 +0200, Eric Dumazet wrote:
> Le lundi 06 juin 2011 à 10:08 -0700, Rick Jones a écrit :
>
> > Mode-rr bonding reorders TCP segments all the time.
>
> Shouldnt TCP frames have DF bit set ?
I was ass-u-me-ing that when talking about TCP, David was speaking
generally about TCP segments, and suggesting that were bonding's mode-rr
altered to not re-order TCP segments, a similar technique
could/would/should avoid re-ordering IP datagram fragments, regardless
of their payload.
Jay will have to weigh-in on how difficult that would be, I'm guessing
it would mean a fair bit of overhead to mode-rr though, to know the
completion status of frames from the same flow and/or the depth of the
tx queues etc etc. I thought that one of mode-rr's (few IMO, just check
the archives where I've complained about it :) redeeming qualities was
its minimal overhead.
rick jones
^ permalink raw reply
* Re: [PATCH] e100: Fix inconsistency in bad frames handling
From: Ben Greear @ 2011-06-06 17:56 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: Andrea Merello, e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <alpine.WNT.2.00.1106060940010.3568@JBRANDEB-DESK2.amr.corp.intel.com>
On 06/06/2011 10:49 AM, Brandeburg, Jesse wrote:
>
> <added netdev>, removed other useless lists.
>
> On Sat, 4 Jun 2011, Andrea Merello wrote:
>> In e100 driver it seems that the intention was to accept bad frames in
>> promiscuous mode and loopback mode.
>> I think this is evident because of the following code in the driver:
>>
>> if (nic->flags& promiscuous || nic->loopback) {
>> config->rx_save_bad_frames = 0x1; /* 1=save, 0=discard */
>> config->rx_discard_short_frames = 0x0; /* 1=discard, 0=save */
>> config->promiscuous_mode = 0x1; /* 1=on, 0=off */
>> }
>>
>
> Hi, thanks for your work on e100.
>
>> However this intention is not really realized because bad frames are
>> discarded later by SW check.
>> This patch finally honors the above intention, making the RX code to
>> let bad frames to pass when the NIC is in promiscuous or loopback
>> mode.
>
> I think this may be a mistake by the authors of the software developers
> manual. The manual suggests that save bad frames and save short frames
> should be enabled in promisc mode, but all of our other drivers *do not*
> save bad frames when in promiscuous mode (by design). This is intentional
> because a bad frame is just that, bad, and with no hope of knowing if the
> data in it is okay/malicious/other. I understand your reasoning above,
> but realistically the rx_save_bad_frames should NOT be set. I'd ack a
> patch to comment that line out.
>
>> This helped me a lot to debug an FPGA ethernet core.
>> Maybe it can be also useful to someone else..
>
> I think this patch is just that, debug only. As a developer I understand
> why this is useful, but there is no reason any normal user would be able
> to benefit from this, so for now, sorry:
>
> NACK.
I think anyone sniffing a funky network would have benefit in
receiving all frames. So, while it shouldn't be enabled by default,
it would be nice to have an ethtool command to turn on receiving
bad-crc frames, as well as receiving the 4-byte CRC on the end of
the packets.
It just so happens I have such a patch, in case others agree :)
Thanks,
Ben
>
>>
>> Thanks
>> Andrea
>>
>> --- drivers/net/e100_orig.c 2011-06-14 23:29:38.322267075 +0200
>> +++ drivers/net/e100.c 2011-06-14 23:34:10.700791472 +0200
>> @@ -1975,7 +1975,8 @@ static int e100_rx_indicate(struct nic *
>> skb_put(skb, actual_size);
>> skb->protocol = eth_type_trans(skb, nic->netdev);
>>
>> - if (unlikely(!(rfd_status& cb_ok))) {
>> + if (unlikely(!(nic->flags& promiscuous || nic->loopback)&&
>> + !(rfd_status& cb_ok))) {
>> /* Don't indicate if hardware indicates errors */
>> dev_kfree_skb_any(skb);
>> } else if (actual_size> ETH_DATA_LEN + VLAN_ETH_HLEN) {
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [RFC PATCHv2] ipv6: implementation of reverse path filtering
From: Eric Leblond @ 2011-06-06 17:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, Eric Leblond
In-Reply-To: <1307362957.3098.7.camel@edumazet-laptop>
This patch provides a basic implementation of reverse path filtering
for IPv6. Functionnality can be activatedor desactivated through an
rp_filter entry similar to the IPv4 one.
The functionnality is disabled by default for backward compatibility
but should be enable on all IPv6 routers/firewalls for security reason.
This implementation is heavily based on the patch Denis Semmau proposed
in 2006.
Signed-off-by: Eric Leblond <eric@regit.org>
---
include/linux/ipv6.h | 2 ++
include/linux/sysctl.h | 1 +
net/ipv6/addrconf.c | 10 ++++++++++
net/ipv6/ip6_output.c | 35 +++++++++++++++++++++++++++++++++++
4 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 0c99776..6b61869 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -172,6 +172,7 @@ struct ipv6_devconf {
__s32 disable_ipv6;
__s32 accept_dad;
__s32 force_tllao;
+ __s32 rp_filter;
void *sysctl;
};
@@ -213,6 +214,7 @@ enum {
DEVCONF_DISABLE_IPV6,
DEVCONF_ACCEPT_DAD,
DEVCONF_FORCE_TLLAO,
+ DEVCONF_RP_FILTER,
DEVCONF_MAX
};
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 11684d9..bdcb7f8 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -568,6 +568,7 @@ enum {
NET_IPV6_ACCEPT_RA_RT_INFO_MAX_PLEN=22,
NET_IPV6_PROXY_NDP=23,
NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
+ NET_IPV6_RP_FILTER=26,
__NET_IPV6_MAX
};
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 498b927..ba1c574 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -196,6 +196,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
.accept_source_route = 0, /* we do not accept RH0 by default. */
.disable_ipv6 = 0,
.accept_dad = 1,
+ .rp_filter = 0,
};
static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
@@ -230,6 +231,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
.accept_source_route = 0, /* we do not accept RH0 by default. */
.disable_ipv6 = 0,
.accept_dad = 1,
+ .rp_filter = 0,
};
/* IPv6 Wildcard Address and Loopback Address defined by RFC2553 */
@@ -3805,6 +3807,7 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
array[DEVCONF_DISABLE_IPV6] = cnf->disable_ipv6;
array[DEVCONF_ACCEPT_DAD] = cnf->accept_dad;
array[DEVCONF_FORCE_TLLAO] = cnf->force_tllao;
+ array[DEVCONF_RP_FILTER] = cnf->rp_filter;
}
static inline size_t inet6_ifla6_size(void)
@@ -4459,6 +4462,13 @@ static struct addrconf_sysctl_table
.proc_handler = proc_dointvec
},
{
+ .procname = "rp_filter",
+ .data = &ipv6_devconf.rp_filter,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
+ {
/* sentinel */
}
},
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 9d4b165..ad8f351 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -374,6 +374,22 @@ static int ip6_forward_proxy_check(struct sk_buff *skb)
return 0;
}
+static int rt6_validate_source(struct sk_buff *skb, char mode)
+{
+ struct rt6_info *rt;
+ struct ipv6hdr *hdr = ipv6_hdr(skb);
+ if (mode == 0)
+ return 0;
+ rt = rt6_lookup(dev_net(skb->dev), &hdr->saddr, NULL, 0, 0);
+ if (rt != NULL) {
+ if ((mode >= 2) && rt->rt6i_idev->dev)
+ return 0;
+ if ((mode == 1) && (rt->rt6i_idev->dev == skb->dev))
+ return 0;
+ }
+ return -1;
+}
+
static inline int ip6_forward_finish(struct sk_buff *skb)
{
return dst_output(skb);
@@ -384,6 +400,7 @@ int ip6_forward(struct sk_buff *skb)
struct dst_entry *dst = skb_dst(skb);
struct ipv6hdr *hdr = ipv6_hdr(skb);
struct inet6_skb_parm *opt = IP6CB(skb);
+ struct inet6_dev *idev = NULL;
struct net *net = dev_net(dst->dev);
u32 mtu;
@@ -401,6 +418,24 @@ int ip6_forward(struct sk_buff *skb)
if (skb->pkt_type != PACKET_HOST)
goto drop;
+ idev = in6_dev_get(skb->dev);
+ if (!idev) {
+ printk(KERN_WARNING "idev error for rp_filter\n");
+ goto error;
+ }
+
+ if (rt6_validate_source(skb,
+ max(net->ipv6.devconf_all->rp_filter,
+ idev->cnf.rp_filter)) < 0) {
+ printk(KERN_WARNING
+ "rp_filter: packet refused on %s, invalid src %pI6 (dst: %pI6)",
+ skb->dev->name,
+ &hdr->saddr,
+ &hdr->daddr
+ );
+ goto drop;
+ }
+
skb_forward_csum(skb);
/*
--
1.7.5.3
^ permalink raw reply related
* Re: [E1000-devel] [PATCH] e100: Fix inconsistency in bad frames handling
From: Brandeburg, Jesse @ 2011-06-06 17:49 UTC (permalink / raw)
To: Andrea Merello; +Cc: e1000-devel@lists.sourceforge.net, netdev
In-Reply-To: <BANLkTimpYniHhN6ccMXN7Lx3xDdK6sC+FQ@mail.gmail.com>
<added netdev>, removed other useless lists.
On Sat, 4 Jun 2011, Andrea Merello wrote:
> In e100 driver it seems that the intention was to accept bad frames in
> promiscuous mode and loopback mode.
> I think this is evident because of the following code in the driver:
>
> if (nic->flags & promiscuous || nic->loopback) {
> config->rx_save_bad_frames = 0x1; /* 1=save, 0=discard */
> config->rx_discard_short_frames = 0x0; /* 1=discard, 0=save */
> config->promiscuous_mode = 0x1; /* 1=on, 0=off */
> }
>
Hi, thanks for your work on e100.
> However this intention is not really realized because bad frames are
> discarded later by SW check.
> This patch finally honors the above intention, making the RX code to
> let bad frames to pass when the NIC is in promiscuous or loopback
> mode.
I think this may be a mistake by the authors of the software developers
manual. The manual suggests that save bad frames and save short frames
should be enabled in promisc mode, but all of our other drivers *do not*
save bad frames when in promiscuous mode (by design). This is intentional
because a bad frame is just that, bad, and with no hope of knowing if the
data in it is okay/malicious/other. I understand your reasoning above,
but realistically the rx_save_bad_frames should NOT be set. I'd ack a
patch to comment that line out.
> This helped me a lot to debug an FPGA ethernet core.
> Maybe it can be also useful to someone else..
I think this patch is just that, debug only. As a developer I understand
why this is useful, but there is no reason any normal user would be able
to benefit from this, so for now, sorry:
NACK.
>
> Thanks
> Andrea
>
> --- drivers/net/e100_orig.c 2011-06-14 23:29:38.322267075 +0200
> +++ drivers/net/e100.c 2011-06-14 23:34:10.700791472 +0200
> @@ -1975,7 +1975,8 @@ static int e100_rx_indicate(struct nic *
> skb_put(skb, actual_size);
> skb->protocol = eth_type_trans(skb, nic->netdev);
>
> - if (unlikely(!(rfd_status & cb_ok))) {
> + if (unlikely(!(nic->flags & promiscuous || nic->loopback) &&
> + !(rfd_status & cb_ok))) {
> /* Don't indicate if hardware indicates errors */
> dev_kfree_skb_any(skb);
> } else if (actual_size > ETH_DATA_LEN + VLAN_ETH_HLEN) {
>
^ permalink raw reply
* RE: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: H Hartley Sweeten @ 2011-06-06 17:48 UTC (permalink / raw)
To: Mika Westerberg, David Miller
Cc: ynezz@true.cz, netdev@vger.kernel.org, ryan@bluewatersys.com,
kernel@wantstofly.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20110606172607.GB3082@acer>
On Monday, June 06, 2011 10:26 AM, Mika Westerberg wrote:
> On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
>> From: Mika Westerberg <mika.westerberg@iki.fi>
>> Date: Sun, 5 Jun 2011 11:59:48 +0300
>>
>>> It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
>>> he knows this better.
>>
>> Someone needs to step up and take over as the real maintainer of this
>> driver. The way the driver is currently being hacked on is
>> unsustainable.
>
> Can't agree more.
>
> Hartley, Ryan: do you have any preferences? Are you guys already overwhelmed
> with your current maintenance work, or could you consider taking this one as
> well?
>
> If no one else steps up, I can volunteer but I have to admit that I don't know
> much about that driver.
I feel the same way.
If Lennert is no longer maintaining the this driver we really need someone to
step up and handle it.
I have no problem doing it but I really don't have a good grasp on the driver
or the whole network subsystem.
If Lennert is willing to hand it over, I have no problem being listed as a
co-maintainer along with either yourself of Ryan. Between the two (or three)
of us we should be able to handle it.
Lennert,
You are listed as the maintainer for these EP93xx related pieces:
ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
CIRRUS LOGIC EP93XX ETHERNET DRIVER
CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER
I can take over the edb9315a with no problem. It actually falls under
arch/arm/mach-ep93xx, so the entry could just be removed from MAINTAINERS.
For the OHCI driver, I'm in the same boat as the Ethernet. If you are no longer
maintaining this driver I'm willing to handle it but would like someone to step
up as a co-maintainer. Hopefully someone that has some grasp of that subsystem.
Your also listed in the source as the maintainer of these ep93xx boards:
ADSSPHERE adssphere.c
EDB9302A edb93xx.c
EDB9315 edb93xx.c
EDB9315A edb93xx.c
GESBC9312 gesbc9312.c
TS72XX ts72xx.c
I'm willing to handle those also since they are under arch/arm/mach-ep93xx.
Regards,
Hartley
^ permalink raw reply
* Re: [PATCH] ep93xx-eth: convert to phylib
From: Lennert Buytenhek @ 2011-06-06 17:34 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, mika.westerberg, hvr, hsweeten, ryan, David Miller,
linux-arm-kernel
In-Reply-To: <201106060715.52332.florian@openwrt.org>
On Mon, Jun 06, 2011 at 07:15:52AM +0200, Florian Fainelli wrote:
> > Instead there are several different people submitting changes to
> > this one driver and I haven't got a clue who is authoritative and
> > who is not.
> >
> > So 9 times out of ten I'm not going to merge anything submitted
> > in this way unless I start to see lots of ACKs from other developers.
> >
> > When it gets to the point where multiple people are touching the
> > driver in all sorts of ways, there needs to be someone to do all of
> > the merging and making sure the patches get applied in the right order
> > and handling merge conflicts handled properly. Then they submit them
> > formally here as a sane single set of patches to the list.
> >
> > So who is going to step up and be the ep93xx-eth maintainer? Lennert
> > is listed in MAINTAINERS, but I see little to no activity from him.
>
> Lennert, do you still have time, hardware and will to maintain that driver?
I still have hardware, but I have been pretty short on time lately.
I'd be happy to hand over maintainership of this driver.
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Jeff Kirsher @ 2011-06-06 17:31 UTC (permalink / raw)
To: Joe Perches
Cc: Eric Dumazet, Américo Wang, Michał Mirosław,
Neil Horman, Andy Gospodarek, Linux Kernel Network Developers,
David Miller, Jay Vosburgh
In-Reply-To: <1307380827.4994.8.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On Mon, 2011-06-06 at 10:20 -0700, Joe Perches wrote:
> On Mon, 2011-06-06 at 19:04 +0200, Eric Dumazet wrote:
> > Le lundi 06 juin 2011 à 09:50 -0700, Joe Perches a écrit :
> > > There is a proposal to move some drivers/net content to
> > > drivers/net/sw/
> > > http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
> > > I think that'd be fine too.
> > > I believe Jeff is going to submit patches soonish.
> > > http://comments.gmane.org/gmane.linux.network/197232
> > As long as the re-organization is done without loosing "git blame"
> > information on current files, I am fine.
> > If not, this is a showstopper and not worth the pain, exactly like other
> > cleanup patches.
>
> To preserve history, all of this should be done via:
> git mv oldpath/file newpath/file
> git commit -m newpath/file
> with some extra cleanups to Kconfig/Makefile files
> so no worries.
>
>
Joe is right, and that is the method that I have been using.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Jeff Kirsher @ 2011-06-06 17:31 UTC (permalink / raw)
To: Joe Perches
Cc: Américo Wang, Michał Mirosław, Neil Horman,
Andy Gospodarek, Linux Kernel Network Developers, David Miller,
Jay Vosburgh
In-Reply-To: <1307379022.4994.4.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
On Mon, 2011-06-06 at 09:50 -0700, Joe Perches wrote:
> On Tue, 2011-06-07 at 00:34 +0800, Américo Wang wrote:
> > I agree with this, IMHO this would help to organize the code better.
> > And currently only tuntap and bonding are still in net/ directory.
> > In any aspects, now we are mixing net/ and drivers/net/ currently,
> > which could be improved.
>
> There is a proposal to move some drivers/net content to
> drivers/net/sw/
>
> http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
>
> I think that'd be fine too.
>
> I believe Jeff is going to submit patches soonish.
>
> http://comments.gmane.org/gmane.linux.network/197232
>
>
Correct, patches will be sent out here this week.
As far as moving tunap, bonding, etc into /drivers/net/sw that is the
eventual plan, but I have not done this work for this upcoming patchset.
I want to coordinate this work with Stephen Hemminger before I do any
moves.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: 3.0.0-rc1: dmesg shows 'wlan%d' instead of 'wlan0'
From: Sergei Trofimovich @ 2011-06-06 17:32 UTC (permalink / raw)
To: Mohammed Shafi; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <BANLkTimLXr1+OLtGGXE2kzccRRG5T-G2mw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
> > Here we see 'wlan0' -> 'wlan%d' switch. I presume those lines go from firmware
> > (and not from userspace).
> this seems to be fixed by the following commit which was recently
> merged in wireless-testing
>
> commit 59e7e7078d6c2c6294caf454c6e3695f9d3e46a2
> Author: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
> Date: Thu Jun 2 17:28:37 2011 -0300
> are we still getting it?
I never ran 'wireless-testing' before.
Applied this commit on top of 3.0-rc2 and wlan%d switched to wlan0 back.
Thanks!
--
Sergei
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth
From: Mika Westerberg @ 2011-06-06 17:26 UTC (permalink / raw)
To: David Miller; +Cc: ynezz, netdev, hsweeten, ryan, kernel, linux-arm-kernel
In-Reply-To: <20110605.140801.1144137337172959622.davem@davemloft.net>
On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
> From: Mika Westerberg <mika.westerberg@iki.fi>
> Date: Sun, 5 Jun 2011 11:59:48 +0300
>
> > It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
> > he knows this better.
>
> Someone needs to step up and take over as the real maintainer of this
> driver. The way the driver is currently being hacked on is
> unsustainable.
Can't agree more.
Hartley, Ryan: do you have any preferences? Are you guys already overwhelmed
with your current maintenance work, or could you consider taking this one as
well?
If no one else steps up, I can volunteer but I have to admit that I don't know
much about that driver.
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Joe Perches @ 2011-06-06 17:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Américo Wang, Jeffrey Kirsher, Michał Mirosław,
Neil Horman, Andy Gospodarek, Linux Kernel Network Developers,
David Miller, Jay Vosburgh
In-Reply-To: <1307379881.3098.71.camel@edumazet-laptop>
On Mon, 2011-06-06 at 19:04 +0200, Eric Dumazet wrote:
> Le lundi 06 juin 2011 à 09:50 -0700, Joe Perches a écrit :
> > There is a proposal to move some drivers/net content to
> > drivers/net/sw/
> > http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
> > I think that'd be fine too.
> > I believe Jeff is going to submit patches soonish.
> > http://comments.gmane.org/gmane.linux.network/197232
> As long as the re-organization is done without loosing "git blame"
> information on current files, I am fine.
> If not, this is a showstopper and not worth the pain, exactly like other
> cleanup patches.
To preserve history, all of this should be done via:
git mv oldpath/file newpath/file
git commit -m newpath/file
with some extra cleanups to Kconfig/Makefile files
so no worries.
^ permalink raw reply
* Re: small RPS cache for fragments?
From: Eric Dumazet @ 2011-06-06 17:15 UTC (permalink / raw)
To: rick.jones2; +Cc: David Miller, netdev
In-Reply-To: <1307380132.8149.2718.camel@tardy>
Le lundi 06 juin 2011 à 10:08 -0700, Rick Jones a écrit :
> Mode-rr bonding reorders TCP segments all the time.
Shouldnt TCP frames have DF bit set ?
^ permalink raw reply
* Re: small RPS cache for fragments?
From: Rick Jones @ 2011-06-06 17:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110604.132940.2214949964968775365.davem@davemloft.net>
On Sat, 2011-06-04 at 13:29 -0700, David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Tue, 24 May 2011 14:38:48 -0700
>
> > Isn't there still an issue (perhaps small) of traffic being sent through
> > a mode-rr bond, either at the origin or somewhere along the way? At the
> > origin point will depend on the presence of UFO and whether it is
> > propagated up through the bond interface, but as a quick test, I
> > disabled TSO, GSO and UFO on four e1000e driven interfaces, bonded them
> > mode-rr and ran a netperf UDP_RR test with a 1473 byte request size and
> > this is what they looked like at my un-bonded reciever at the other end:
> >
> > 14:31:01.011370 IP (tos 0x0, ttl 64, id 24960, offset 1480, flags
> > [none], proto UDP (17), length 21)
> > tardy.local > raj-8510w.local: udp
> > 14:31:01.011420 IP (tos 0x0, ttl 64, id 24960, offset 0, flags [+],
> > proto UDP (17), length 1500)
> > tardy.local.36073 > raj-8510w.local.59951: UDP, length 1473
> > 14:31:01.011514 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> > UDP (17), length 29)
> > raj-8510w.local.59951 > tardy.local.36073: UDP, length 1
>
> That's not good behavior, and it's of course going to cause sub-optimal
> performance if we do the RPS fragment cache.
>
> RR bond mode could do something similar, to alleviate this.
>
> I assume it doesn't do this kind of reordering for TCP.
Mode-rr bonding reorders TCP segments all the time.
rick
^ permalink raw reply
* Re: bridge/netfilter: regression in 2.6.39.1
From: Neil Horman @ 2011-06-06 17:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexander Holler, linux-kernel, David Miller, Herbert Xu, netdev
In-Reply-To: <1307376705.3098.58.camel@edumazet-laptop>
On Mon, Jun 06, 2011 at 06:11:45PM +0200, Eric Dumazet wrote:
> Le lundi 06 juin 2011 à 11:32 -0400, Neil Horman a écrit :
>
> > Not to drag this out further, but since you illustrated the correct way to do
> > this with the blackhole_ops test, and this modification now gives us two
> > instances of that case, would it perhaps be better to just do this in
> > dst_metrics_write_ptr:
> >
> > return dst->ops->cow_metrics ? return dst->ops->cow_metrics(dst, p) : NULL;
> >
> > Then we could eliminate the two functions that do nothing be retun NULL (along
> > with their respective call instructions), and save any future users from having
> > to remember to include a dummy cow_metrics method if they happen to set the read
> > only flag on thier dst_ops?
>
> Well, I prefer how David coded the thing.
> We can add selective traces where we want.
>
> Having a default behavior might give much more work to find a bug in
> this area. A NULL pointer access gives us an immediate indication.
>
> Its a bit late to add an "if (dst->ops->cow_metrics)" test now that we
> covered all call sites ;)
>
> But we probably have more bugs elsewhere, because of many dst changes in
> 2.6.39
Ok, sounds reasonable to me.
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Eric Dumazet @ 2011-06-06 17:04 UTC (permalink / raw)
To: Joe Perches
Cc: Américo Wang, Jeffrey Kirsher, Michał Mirosław,
Neil Horman, Andy Gospodarek, Linux Kernel Network Developers,
David Miller, Jay Vosburgh
In-Reply-To: <1307379022.4994.4.camel@Joe-Laptop>
Le lundi 06 juin 2011 à 09:50 -0700, Joe Perches a écrit :
> On Tue, 2011-06-07 at 00:34 +0800, Américo Wang wrote:
> > I agree with this, IMHO this would help to organize the code better.
> > And currently only tuntap and bonding are still in net/ directory.
> > In any aspects, now we are mixing net/ and drivers/net/ currently,
> > which could be improved.
>
> There is a proposal to move some drivers/net content to
> drivers/net/sw/
>
> http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
>
> I think that'd be fine too.
>
> I believe Jeff is going to submit patches soonish.
>
> http://comments.gmane.org/gmane.linux.network/197232
>
As long as the re-organization is done without loosing "git blame"
information on current files, I am fine.
If not, this is a showstopper and not worth the pain, exactly like other
cleanup patches.
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Joe Perches @ 2011-06-06 16:50 UTC (permalink / raw)
To: Américo Wang, Jeffrey Kirsher
Cc: Michał Mirosław, Neil Horman, Andy Gospodarek,
Linux Kernel Network Developers, David Miller, Jay Vosburgh
In-Reply-To: <BANLkTin4VyK3boPqDQnd+Dkv6==cHww9PA@mail.gmail.com>
On Tue, 2011-06-07 at 00:34 +0800, Américo Wang wrote:
> I agree with this, IMHO this would help to organize the code better.
> And currently only tuntap and bonding are still in net/ directory.
> In any aspects, now we are mixing net/ and drivers/net/ currently,
> which could be improved.
There is a proposal to move some drivers/net content to
drivers/net/sw/
http://vger.kernel.org/netconf2010_slides/netconf-jtk.pdf
I think that'd be fine too.
I believe Jeff is going to submit patches soonish.
http://comments.gmane.org/gmane.linux.network/197232
^ permalink raw reply
* IPv6 DNSSL (rfc6106): please include the patch to pass it to user space
From: Carlos Carvalho @ 2011-06-06 16:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <20080408122545.GA31729@2ka.mipt.ru>
Currently the kernel doesn't pass DNSSL lists received by router
advertsiments (rfc 6106) to user space via netlink. Pierre Ossman sent
a patch for it about 6 months ago:
http://patchwork.ozlabs.org/patch/75243. Could you please include it
in mainline? This is a very useful feature.
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Américo Wang @ 2011-06-06 16:34 UTC (permalink / raw)
To: Michał Mirosław
Cc: Neil Horman, Andy Gospodarek, Linux Kernel Network Developers,
David Miller, Jay Vosburgh
In-Reply-To: <BANLkTikrsr5sZ4aZ5aEmfBSvPE0mEL8g0g@mail.gmail.com>
2011/5/26 Michał Mirosław <mirqus@gmail.com>:
> 2011/5/26 Neil Horman <nhorman@tuxdriver.com>:
>> On Thu, May 26, 2011 at 05:32:08PM +0800, Américo Wang wrote:
>>> I don't think other drivers are supposed to use this function to register
>>> a packet handler, which is an important difference from my view.
>> Note you just referred to the bridge/bond and vlan code as 'drivers' :). And
>> why is that function the gating factor? Why not register_netdev? or
>> netif_receive_skb or dev_add_pack? They all relate to the creation of device
>> interface and the reception of network data.
>>
>> The fact is, bonding/bridging/vlans/tunnels/etc all have aspects that
>> make them more than just drivers. They are where they are for a myrriad of
>> reasons. Moving them around changes their location, but does _nothing_ about
>> the underlying fact that they're driver code plus other stuff, and as such
>> provides no real advantage in terms of organization.
>
> If you want to draw a line between net/ and drivers/net I propose
> following idea:
>
> net/ - everything that is about networking (or library for it) and
> interacts only within the system (kernel<->user, or in-kernel)
> drivers/net/ - everything that is a connecting point between the
> system and external world - be it hardware, other VMs or hypervisor.
>
> net/ would include wireless stack, all kinds of loopback devices,
> tunnels (incl. vlan), bridging, bonding, tuntap, etc.
> drivers/net/ would keep only what is hardware or external ABI dependent
>
I agree with this, IMHO this would help to organize the code better.
And currently only tuntap and bonding are still in net/ directory.
In any aspects, now we are mixing net/ and drivers/net/ currently,
which could be improved.
Thanks!
^ 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