* [PATCH net-next-2.6] bonding: remove unused variable "found"
From: Jiri Pirko @ 2010-05-17 13:49 UTC (permalink / raw)
To: netdev; +Cc: davem
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index b8bec08..392e291 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -219,7 +219,7 @@ static ssize_t bonding_store_slaves(struct device *d,
{
char command[IFNAMSIZ + 1] = { 0, };
char *ifname;
- int i, res, found, ret = count;
+ int i, res, ret = count;
u32 original_mtu;
struct slave *slave;
struct net_device *dev = NULL;
@@ -245,7 +245,6 @@ static ssize_t bonding_store_slaves(struct device *d,
if (command[0] == '+') {
/* Got a slave name in ifname. Is it already in the list? */
- found = 0;
dev = __dev_get_by_name(dev_net(bond->dev), ifname);
if (!dev) {
^ permalink raw reply related
* Re: [PATCH] vhost: Storage class should be before const qualifier
From: Joe Perches @ 2010-05-17 13:54 UTC (permalink / raw)
To: Tobias Klauser; +Cc: Michael S. Tsirkin, LKML, netdev
In-Reply-To: <20100517132748.GQ9489@distanz.ch>
On Mon, 2010-05-17 at 15:27 +0200, Tobias Klauser wrote:
> On 2010-05-17 at 15:13:35 +0200, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, May 17, 2010 at 03:12:49PM +0200, Tobias Klauser wrote:
> > > The C99 specification states in section 6.11.5:
> > > The placement of a storage-class specifier other than at the beginning
> > > of the declaration specifiers in a declaration is an obsolescent
> > > feature.
> > > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> > Just to clarify: does some compiler/checker actually barf on this?
> GCC does emit a warning if the options '-std=c99 -W -Wall' are present.
> ICC also does warn about this, though I don't know whether this depends
> on any commandline options.
Perhaps others should be converted as well.
$ grep -rPl --include=*.[ch] "^[ \t]*const\s+static" * | \
xargs sed -i -r -e 's/^[ \t]*const[ \t]+static\b/static const/g'
gives:
---
arch/arm/mach-pxa/palmtc.c | 4 +-
arch/xtensa/variants/s6000/include/variant/dmac.h | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 38 ++++++++++----------
drivers/mfd/timberdale.c | 18 +++++-----
drivers/net/wireless/iwlwifi/iwl-core.c | 4 +-
drivers/staging/hv/vmbus_drv.c | 2 +-
fs/ceph/mds_client.c | 4 +-
fs/ceph/mon_client.c | 4 +-
fs/ceph/osd_client.c | 4 +-
sound/pci/hda/patch_realtek.c | 2 +-
10 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-pxa/palmtc.c b/arch/arm/mach-pxa/palmtc.c
index 717d7a6..8c09d48 100644
--- a/arch/arm/mach-pxa/palmtc.c
+++ b/arch/arm/mach-pxa/palmtc.c
@@ -263,11 +263,11 @@ const struct matrix_keymap_data palmtc_keymap_data = {
.keymap_size = ARRAY_SIZE(palmtc_matrix_keys),
};
-const static unsigned int palmtc_keypad_row_gpios[] = {
+static const unsigned int palmtc_keypad_row_gpios[] = {
0, 9, 10, 11
};
-const static unsigned int palmtc_keypad_col_gpios[] = {
+static const unsigned int palmtc_keypad_col_gpios[] = {
18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 79, 80
};
diff --git a/arch/xtensa/variants/s6000/include/variant/dmac.h b/arch/xtensa/variants/s6000/include/variant/dmac.h
index 89ab948..a24c4bb 100644
--- a/arch/xtensa/variants/s6000/include/variant/dmac.h
+++ b/arch/xtensa/variants/s6000/include/variant/dmac.h
@@ -357,7 +357,7 @@ static inline u32 s6dmac_channel_enabled(u32 dmac, int chan)
static inline void s6dmac_dp_setup_group(u32 dmac, int port,
int nrch, int frrep)
{
- const static u8 mask[4] = {0, 3, 1, 2};
+static const u8 mask[4] = {0, 3, 1, 2};
BUG_ON(dmac != S6_REG_DPDMA);
if ((port < 0) || (port > 3) || (nrch < 1) || (nrch > 4))
return;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc03537..20533ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -60,95 +60,95 @@ extern int intel_agp_enabled;
.subdevice = PCI_ANY_ID, \
.driver_data = (unsigned long) info }
-const static struct intel_device_info intel_i830_info = {
+static const struct intel_device_info intel_i830_info = {
.is_i8xx = 1, .is_mobile = 1, .cursor_needs_physical = 1,
};
-const static struct intel_device_info intel_845g_info = {
+static const struct intel_device_info intel_845g_info = {
.is_i8xx = 1,
};
-const static struct intel_device_info intel_i85x_info = {
+static const struct intel_device_info intel_i85x_info = {
.is_i8xx = 1, .is_i85x = 1, .is_mobile = 1,
.cursor_needs_physical = 1,
};
-const static struct intel_device_info intel_i865g_info = {
+static const struct intel_device_info intel_i865g_info = {
.is_i8xx = 1,
};
-const static struct intel_device_info intel_i915g_info = {
+static const struct intel_device_info intel_i915g_info = {
.is_i915g = 1, .is_i9xx = 1, .cursor_needs_physical = 1,
};
-const static struct intel_device_info intel_i915gm_info = {
+static const struct intel_device_info intel_i915gm_info = {
.is_i9xx = 1, .is_mobile = 1,
.cursor_needs_physical = 1,
};
-const static struct intel_device_info intel_i945g_info = {
+static const struct intel_device_info intel_i945g_info = {
.is_i9xx = 1, .has_hotplug = 1, .cursor_needs_physical = 1,
};
-const static struct intel_device_info intel_i945gm_info = {
+static const struct intel_device_info intel_i945gm_info = {
.is_i945gm = 1, .is_i9xx = 1, .is_mobile = 1,
.has_hotplug = 1, .cursor_needs_physical = 1,
};
-const static struct intel_device_info intel_i965g_info = {
+static const struct intel_device_info intel_i965g_info = {
.is_i965g = 1, .is_i9xx = 1, .has_hotplug = 1,
};
-const static struct intel_device_info intel_i965gm_info = {
+static const struct intel_device_info intel_i965gm_info = {
.is_i965g = 1, .is_mobile = 1, .is_i965gm = 1, .is_i9xx = 1,
.is_mobile = 1, .has_fbc = 1, .has_rc6 = 1,
.has_hotplug = 1,
};
-const static struct intel_device_info intel_g33_info = {
+static const struct intel_device_info intel_g33_info = {
.is_g33 = 1, .is_i9xx = 1, .need_gfx_hws = 1,
.has_hotplug = 1,
};
-const static struct intel_device_info intel_g45_info = {
+static const struct intel_device_info intel_g45_info = {
.is_i965g = 1, .is_g4x = 1, .is_i9xx = 1, .need_gfx_hws = 1,
.has_pipe_cxsr = 1,
.has_hotplug = 1,
};
-const static struct intel_device_info intel_gm45_info = {
+static const struct intel_device_info intel_gm45_info = {
.is_i965g = 1, .is_mobile = 1, .is_g4x = 1, .is_i9xx = 1,
.is_mobile = 1, .need_gfx_hws = 1, .has_fbc = 1, .has_rc6 = 1,
.has_pipe_cxsr = 1,
.has_hotplug = 1,
};
-const static struct intel_device_info intel_pineview_info = {
+static const struct intel_device_info intel_pineview_info = {
.is_g33 = 1, .is_pineview = 1, .is_mobile = 1, .is_i9xx = 1,
.need_gfx_hws = 1,
.has_hotplug = 1,
};
-const static struct intel_device_info intel_ironlake_d_info = {
+static const struct intel_device_info intel_ironlake_d_info = {
.is_ironlake = 1, .is_i965g = 1, .is_i9xx = 1, .need_gfx_hws = 1,
.has_pipe_cxsr = 1,
.has_hotplug = 1,
};
-const static struct intel_device_info intel_ironlake_m_info = {
+static const struct intel_device_info intel_ironlake_m_info = {
.is_ironlake = 1, .is_mobile = 1, .is_i965g = 1, .is_i9xx = 1,
.need_gfx_hws = 1, .has_rc6 = 1,
.has_hotplug = 1,
};
-const static struct intel_device_info intel_sandybridge_d_info = {
+static const struct intel_device_info intel_sandybridge_d_info = {
.is_i965g = 1, .is_i9xx = 1, .need_gfx_hws = 1,
.has_hotplug = 1, .is_gen6 = 1,
};
-const static struct intel_device_info intel_sandybridge_m_info = {
+static const struct intel_device_info intel_sandybridge_m_info = {
.is_i965g = 1, .is_mobile = 1, .is_i9xx = 1, .need_gfx_hws = 1,
.has_hotplug = 1, .is_gen6 = 1,
};
-const static struct pci_device_id pciidlist[] = {
+static const struct pci_device_id pciidlist[] = {
INTEL_VGA_DEVICE(0x3577, &intel_i830_info),
INTEL_VGA_DEVICE(0x2562, &intel_845g_info),
INTEL_VGA_DEVICE(0x3582, &intel_i85x_info),
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 7f478ec..8443e52 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -77,7 +77,7 @@ timberdale_ocores_platform_data = {
.num_devices = ARRAY_SIZE(timberdale_i2c_board_info)
};
-const static __devinitconst struct resource timberdale_ocores_resources[] = {
+static const __devinitconst struct resource timberdale_ocores_resources[] = {
{
.start = OCORESOFFSET,
.end = OCORESEND,
@@ -126,7 +126,7 @@ static __devinitdata struct xspi_platform_data timberdale_xspi_platform_data = {
*/
};
-const static __devinitconst struct resource timberdale_spi_resources[] = {
+static const __devinitconst struct resource timberdale_spi_resources[] = {
{
.start = SPIOFFSET,
.end = SPIEND,
@@ -139,7 +139,7 @@ const static __devinitconst struct resource timberdale_spi_resources[] = {
},
};
-const static __devinitconst struct resource timberdale_eth_resources[] = {
+static const __devinitconst struct resource timberdale_eth_resources[] = {
{
.start = ETHOFFSET,
.end = ETHEND,
@@ -159,7 +159,7 @@ static __devinitdata struct timbgpio_platform_data
.irq_base = 200,
};
-const static __devinitconst struct resource timberdale_gpio_resources[] = {
+static const __devinitconst struct resource timberdale_gpio_resources[] = {
{
.start = GPIOOFFSET,
.end = GPIOEND,
@@ -172,7 +172,7 @@ const static __devinitconst struct resource timberdale_gpio_resources[] = {
},
};
-const static __devinitconst struct resource timberdale_mlogicore_resources[] = {
+static const __devinitconst struct resource timberdale_mlogicore_resources[] = {
{
.start = MLCOREOFFSET,
.end = MLCOREEND,
@@ -190,7 +190,7 @@ const static __devinitconst struct resource timberdale_mlogicore_resources[] = {
},
};
-const static __devinitconst struct resource timberdale_uart_resources[] = {
+static const __devinitconst struct resource timberdale_uart_resources[] = {
{
.start = UARTOFFSET,
.end = UARTEND,
@@ -203,7 +203,7 @@ const static __devinitconst struct resource timberdale_uart_resources[] = {
},
};
-const static __devinitconst struct resource timberdale_uartlite_resources[] = {
+static const __devinitconst struct resource timberdale_uartlite_resources[] = {
{
.start = UARTLITEOFFSET,
.end = UARTLITEEND,
@@ -216,7 +216,7 @@ const static __devinitconst struct resource timberdale_uartlite_resources[] = {
},
};
-const static __devinitconst struct resource timberdale_radio_resources[] = {
+static const __devinitconst struct resource timberdale_radio_resources[] = {
{
.start = RDSOFFSET,
.end = RDSEND,
@@ -250,7 +250,7 @@ static __devinitdata struct timb_radio_platform_data
}
};
-const static __devinitconst struct resource timberdale_dma_resources[] = {
+static const __devinitconst struct resource timberdale_dma_resources[] = {
{
.start = DMAOFFSET,
.end = DMAEND,
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 049b652..47d1a4b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -3204,7 +3204,7 @@ void iwl_update_stats(struct iwl_priv *priv, bool is_tx, __le16 fc, u16 len)
EXPORT_SYMBOL(iwl_update_stats);
#endif
-const static char *get_csr_string(int cmd)
+static const char *get_csr_string(int cmd)
{
switch (cmd) {
IWL_CMD(CSR_HW_IF_CONFIG_REG);
@@ -3275,7 +3275,7 @@ void iwl_dump_csr(struct iwl_priv *priv)
}
EXPORT_SYMBOL(iwl_dump_csr);
-const static char *get_fh_string(int cmd)
+static const char *get_fh_string(int cmd)
{
switch (cmd) {
IWL_CMD(FH_RSCSR_CHNL0_STTS_WPTR_REG);
diff --git a/drivers/staging/hv/vmbus_drv.c b/drivers/staging/hv/vmbus_drv.c
index 3397ef0..ece5014 100644
--- a/drivers/staging/hv/vmbus_drv.c
+++ b/drivers/staging/hv/vmbus_drv.c
@@ -999,7 +999,7 @@ static void __exit vmbus_exit(void)
* installed and/or configured. We don't do anything else with the table, but
* it needs to be present.
*/
-const static struct pci_device_id microsoft_hv_pci_table[] = {
+static const struct pci_device_id microsoft_hv_pci_table[] = {
{ PCI_DEVICE(0x1414, 0x5353) }, /* VGA compatible controller */
{ 0 }
};
diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
index 24561a5..4854943 100644
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -40,7 +40,7 @@
static void __wake_requests(struct ceph_mds_client *mdsc,
struct list_head *head);
-const static struct ceph_connection_operations mds_con_ops;
+static const struct ceph_connection_operations mds_con_ops;
/*
@@ -3031,7 +3031,7 @@ static int invalidate_authorizer(struct ceph_connection *con)
return ceph_monc_validate_auth(&mdsc->client->monc);
}
-const static struct ceph_connection_operations mds_con_ops = {
+static const struct ceph_connection_operations mds_con_ops = {
.get = con_get,
.put = con_put,
.dispatch = dispatch,
diff --git a/fs/ceph/mon_client.c b/fs/ceph/mon_client.c
index 8fdc011..c5d3883 100644
--- a/fs/ceph/mon_client.c
+++ b/fs/ceph/mon_client.c
@@ -28,7 +28,7 @@
* resend any outstanding requests.
*/
-const static struct ceph_connection_operations mon_con_ops;
+static const struct ceph_connection_operations mon_con_ops;
static int __validate_auth(struct ceph_mon_client *monc);
@@ -826,7 +826,7 @@ out:
mutex_unlock(&monc->mutex);
}
-const static struct ceph_connection_operations mon_con_ops = {
+static const struct ceph_connection_operations mon_con_ops = {
.get = ceph_con_get,
.put = ceph_con_put,
.dispatch = dispatch,
diff --git a/fs/ceph/osd_client.c b/fs/ceph/osd_client.c
index 3514f71..763fdb1 100644
--- a/fs/ceph/osd_client.c
+++ b/fs/ceph/osd_client.c
@@ -16,7 +16,7 @@
#define OSD_OP_FRONT_LEN 4096
#define OSD_OPREPLY_FRONT_LEN 512
-const static struct ceph_connection_operations osd_con_ops;
+static const struct ceph_connection_operations osd_con_ops;
static int __kick_requests(struct ceph_osd_client *osdc,
struct ceph_osd *kickosd);
@@ -1552,7 +1552,7 @@ static int invalidate_authorizer(struct ceph_connection *con)
return ceph_monc_validate_auth(&osdc->client->monc);
}
-const static struct ceph_connection_operations osd_con_ops = {
+static const struct ceph_connection_operations osd_con_ops = {
.get = get_osd_con,
.put = put_osd_con,
.dispatch = dispatch,
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 886d8e4..ae85771 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -14082,7 +14082,7 @@ enum {
ALC269_FIXUP_SONY_VAIO,
};
-const static struct hda_verb alc269_sony_vaio_fixup_verbs[] = {
+static const struct hda_verb alc269_sony_vaio_fixup_verbs[] = {
{0x19, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREFGRD},
{}
};
^ permalink raw reply related
* [PATCH net-next-2.6] can: sja1000 platform data fixes
From: Wolfgang Grandegger @ 2010-05-17 14:25 UTC (permalink / raw)
To: Netdev-u79uwXL29TY76Z2rM5mHXA
Cc: SocketCAN Core Mailing List, Marc Kleine-Budde
The member "clock" of struct "sja1000_platform_data" is documented as
"CAN bus oscillator frequency in Hz" but it's actually used as the CAN
clock frequency, which is half of it. To avoid further confusion, this
patch fixes it by renaming the member to "osc_freq". That way, also
non mainline users will notice the change. The platform code for the
relevant boards is updated accordingly. Furthermore, pre-defined
values are now used for the members "ocr" and "cdr".
Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
CC: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
diff --git a/arch/arm/mach-mx2/pcm970-baseboard.c b/arch/arm/mach-mx2/pcm970-baseboard.c
index 4aafd5b..f490a40 100644
--- a/arch/arm/mach-mx2/pcm970-baseboard.c
+++ b/arch/arm/mach-mx2/pcm970-baseboard.c
@@ -201,9 +201,9 @@ static struct resource pcm970_sja1000_resources[] = {
};
struct sja1000_platform_data pcm970_sja1000_platform_data = {
- .clock = 16000000 / 2,
- .ocr = 0x40 | 0x18,
- .cdr = 0x40,
+ .osc_freq = 16000000,
+ .ocr = OCR_TX1_PULLDOWN | OCR_TX0_PUSHPULL,
+ .cdr = CDR_CBP,
};
static struct platform_device pcm970_sja1000 = {
diff --git a/arch/arm/mach-mx3/mach-pcm037.c b/arch/arm/mach-mx3/mach-pcm037.c
index 2df1ec5..78ecd75 100644
--- a/arch/arm/mach-mx3/mach-pcm037.c
+++ b/arch/arm/mach-mx3/mach-pcm037.c
@@ -530,9 +530,9 @@ static struct resource pcm970_sja1000_resources[] = {
};
struct sja1000_platform_data pcm970_sja1000_platform_data = {
- .clock = 16000000 / 2,
- .ocr = 0x40 | 0x18,
- .cdr = 0x40,
+ .osc_freq = 16000000,
+ .ocr = OCR_TX1_PULLDOWN | OCR_TX0_PUSHPULL,
+ .cdr = CDR_CBP,
};
static struct platform_device pcm970_sja1000 = {
diff --git a/drivers/net/can/sja1000/sja1000_platform.c b/drivers/net/can/sja1000/sja1000_platform.c
index b65cabb..d9fadc4 100644
--- a/drivers/net/can/sja1000/sja1000_platform.c
+++ b/drivers/net/can/sja1000/sja1000_platform.c
@@ -111,7 +111,8 @@ static int sp_probe(struct platform_device *pdev)
dev->irq = res_irq->start;
priv->irq_flags = res_irq->flags & (IRQF_TRIGGER_MASK | IRQF_SHARED);
priv->reg_base = addr;
- priv->can.clock.freq = pdata->clock;
+ /* The CAN clock frequency is half the oscillator clock frequency */
+ priv->can.clock.freq = pdata->osc_freq / 2;
priv->ocr = pdata->ocr;
priv->cdr = pdata->cdr;
diff --git a/include/linux/can/platform/sja1000.h b/include/linux/can/platform/sja1000.h
index 01ee2ae..96f8fcc 100644
--- a/include/linux/can/platform/sja1000.h
+++ b/include/linux/can/platform/sja1000.h
@@ -26,7 +26,7 @@
#define OCR_TX_SHIFT 2
struct sja1000_platform_data {
- u32 clock; /* CAN bus oscillator frequency in Hz */
+ u32 osc_freq; /* CAN bus oscillator frequency in Hz */
u8 ocr; /* output control register */
u8 cdr; /* clock divider register */
^ permalink raw reply related
* Re: [PATCH] Fix SJA1000 command register writes on SMP systems
From: Wolfgang Grandegger @ 2010-05-17 14:29 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: SocketCAN Core Mailing List, Linux Netdev List, David Miller,
stable-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <4BF12321.6080506-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Hi Oliver,
On 05/17/2010 01:06 PM, Oliver Hartkopp wrote:
> The SJA1000 command register is concurrently written in the rx-path to free
> the receive buffer _and_ in the tx-path to start the transmission.
> On SMP systems this leads to a write stall in the tx-path, which can be
> solved by adding some locking for the command register in the SMP case.
We should explain why a write stall can happen. Here is the relavant
part from the SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR):
"Between two commands at least one internal clock cycle is needed in
order to proceed. The internal clock is half of the external oscillator
frequency."
Wolfgang.
^ permalink raw reply
* Re: [PATCH net-next-2.6] can: sja1000 platform data fixes
From: Marc Kleine-Budde @ 2010-05-17 14:42 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BF151D2.5030906-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3446 bytes --]
Wolfgang Grandegger wrote:
> The member "clock" of struct "sja1000_platform_data" is documented as
> "CAN bus oscillator frequency in Hz" but it's actually used as the CAN
> clock frequency, which is half of it. To avoid further confusion, this
> patch fixes it by renaming the member to "osc_freq". That way, also
> non mainline users will notice the change. The platform code for the
> relevant boards is updated accordingly. Furthermore, pre-defined
> values are now used for the members "ocr" and "cdr".
>
> Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
> CC: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cheers, Marc
>
> diff --git a/arch/arm/mach-mx2/pcm970-baseboard.c b/arch/arm/mach-mx2/pcm970-baseboard.c
> index 4aafd5b..f490a40 100644
> --- a/arch/arm/mach-mx2/pcm970-baseboard.c
> +++ b/arch/arm/mach-mx2/pcm970-baseboard.c
> @@ -201,9 +201,9 @@ static struct resource pcm970_sja1000_resources[] = {
> };
>
> struct sja1000_platform_data pcm970_sja1000_platform_data = {
> - .clock = 16000000 / 2,
> - .ocr = 0x40 | 0x18,
> - .cdr = 0x40,
> + .osc_freq = 16000000,
> + .ocr = OCR_TX1_PULLDOWN | OCR_TX0_PUSHPULL,
> + .cdr = CDR_CBP,
> };
>
> static struct platform_device pcm970_sja1000 = {
> diff --git a/arch/arm/mach-mx3/mach-pcm037.c b/arch/arm/mach-mx3/mach-pcm037.c
> index 2df1ec5..78ecd75 100644
> --- a/arch/arm/mach-mx3/mach-pcm037.c
> +++ b/arch/arm/mach-mx3/mach-pcm037.c
> @@ -530,9 +530,9 @@ static struct resource pcm970_sja1000_resources[] = {
> };
>
> struct sja1000_platform_data pcm970_sja1000_platform_data = {
> - .clock = 16000000 / 2,
> - .ocr = 0x40 | 0x18,
> - .cdr = 0x40,
> + .osc_freq = 16000000,
> + .ocr = OCR_TX1_PULLDOWN | OCR_TX0_PUSHPULL,
> + .cdr = CDR_CBP,
> };
>
> static struct platform_device pcm970_sja1000 = {
> diff --git a/drivers/net/can/sja1000/sja1000_platform.c b/drivers/net/can/sja1000/sja1000_platform.c
> index b65cabb..d9fadc4 100644
> --- a/drivers/net/can/sja1000/sja1000_platform.c
> +++ b/drivers/net/can/sja1000/sja1000_platform.c
> @@ -111,7 +111,8 @@ static int sp_probe(struct platform_device *pdev)
> dev->irq = res_irq->start;
> priv->irq_flags = res_irq->flags & (IRQF_TRIGGER_MASK | IRQF_SHARED);
> priv->reg_base = addr;
> - priv->can.clock.freq = pdata->clock;
> + /* The CAN clock frequency is half the oscillator clock frequency */
> + priv->can.clock.freq = pdata->osc_freq / 2;
> priv->ocr = pdata->ocr;
> priv->cdr = pdata->cdr;
>
> diff --git a/include/linux/can/platform/sja1000.h b/include/linux/can/platform/sja1000.h
> index 01ee2ae..96f8fcc 100644
> --- a/include/linux/can/platform/sja1000.h
> +++ b/include/linux/can/platform/sja1000.h
> @@ -26,7 +26,7 @@
> #define OCR_TX_SHIFT 2
>
> struct sja1000_platform_data {
> - u32 clock; /* CAN bus oscillator frequency in Hz */
> + u32 osc_freq; /* CAN bus oscillator frequency in Hz */
>
> u8 ocr; /* output control register */
> u8 cdr; /* clock divider register */
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* [PATCH net-next-2.6] bonding: move slave MTU handling from sysfs
From: Jiri Pirko @ 2010-05-17 14:47 UTC (permalink / raw)
To: netdev; +Cc: davem, fubar, bonding-devel, monis
For some reason, MTU handling (storing, and restoring) is taking place in
bond_sysfs. The correct place for this code is in bond_enslave, bond_release.
So move it there.
Jirka
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5e12462..2c3f9db 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1533,6 +1533,14 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
*/
new_slave->original_flags = slave_dev->flags;
+ /* Save slave's original mtu and then set it to match the bond */
+ new_slave->original_mtu = slave_dev->mtu;
+ res = dev_set_mtu(slave_dev, bond->dev->mtu);
+ if (res) {
+ pr_debug("Error %d calling dev_set_mtu\n", res);
+ goto err_free;
+ }
+
/*
* Save slave's original ("permanent") mac address for modes
* that need it, and for restoring it upon release, and then
@@ -1550,7 +1558,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
res = dev_set_mac_address(slave_dev, &addr);
if (res) {
pr_debug("Error %d calling set_mac_address\n", res);
- goto err_free;
+ goto err_restore_mtu;
}
}
@@ -1785,6 +1793,9 @@ err_restore_mac:
dev_set_mac_address(slave_dev, &addr);
}
+err_restore_mtu:
+ dev_set_mtu(slave_dev, new_slave->original_mtu);
+
err_free:
kfree(new_slave);
@@ -1969,6 +1980,8 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
dev_set_mac_address(slave_dev, &addr);
}
+ dev_set_mtu(slave_dev, slave->original_mtu);
+
slave_dev->priv_flags &= ~(IFF_MASTER_8023AD | IFF_MASTER_ALB |
IFF_SLAVE_INACTIVE | IFF_BONDING |
IFF_SLAVE_NEEDARP);
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 392e291..4e84cfc 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -220,7 +220,6 @@ static ssize_t bonding_store_slaves(struct device *d,
char command[IFNAMSIZ + 1] = { 0, };
char *ifname;
int i, res, ret = count;
- u32 original_mtu;
struct slave *slave;
struct net_device *dev = NULL;
struct bonding *bond = to_bond(d);
@@ -281,43 +280,22 @@ static ssize_t bonding_store_slaves(struct device *d,
memcpy(bond->dev->dev_addr, dev->dev_addr,
dev->addr_len);
- /* Set the slave's MTU to match the bond */
- original_mtu = dev->mtu;
- res = dev_set_mtu(dev, bond->dev->mtu);
- if (res) {
- ret = res;
- goto out;
- }
-
res = bond_enslave(bond->dev, dev);
- bond_for_each_slave(bond, slave, i)
- if (strnicmp(slave->dev->name, ifname, IFNAMSIZ) == 0)
- slave->original_mtu = original_mtu;
- if (res)
- ret = res;
goto out;
}
if (command[0] == '-') {
dev = NULL;
- original_mtu = 0;
bond_for_each_slave(bond, slave, i)
if (strnicmp(slave->dev->name, ifname, IFNAMSIZ) == 0) {
dev = slave->dev;
- original_mtu = slave->original_mtu;
break;
}
if (dev) {
pr_info("%s: Removing slave %s\n",
bond->dev->name, dev->name);
- res = bond_release(bond->dev, dev);
- if (res) {
- ret = res;
- goto out;
- }
- /* set the slave MTU to the default */
- dev_set_mtu(dev, original_mtu);
+ res = bond_release(bond->dev, dev);
} else {
pr_err("unable to remove non-existent slave %s for bond %s.\n",
ifname, bond->dev->name);
^ permalink raw reply related
* Re: [PATCH v3 1/3] ptp: Added a brand new class driver for ptp clocks.
From: Wolfgang Grandegger @ 2010-05-17 15:41 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, linuxppc-dev, devicetree-discuss
In-Reply-To: <aa2a85799677c08001b152c2921d0e55d5693ffa.1273855017.git.richard.cochran@omicron.at>
On 05/14/2010 06:45 PM, Richard Cochran wrote:
> This patch adds an infrastructure for hardware clocks that implement
> IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
> registration method to particular hardware clock drivers. Each clock is
> exposed to user space as a character device with ioctls that allow tuning
> of the PTP clock.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Tested-by: Wolfgang Grandegger <wg@denx.de>
on my Freescale MPC8313 setup with ptpd and ptpv2d.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Wolfgang Grandegger @ 2010-05-17 15:41 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, linuxppc-dev, devicetree-discuss
In-Reply-To: <ee6c3edca3ee6aa86565e59da999375f79c9de1b.1273855017.git.richard.cochran@omicron.at>
On 05/14/2010 06:46 PM, Richard Cochran wrote:
> The eTSEC includes a PTP clock with quite a few features. This patch adds
> support for the basic clock adjustment functions, plus two external time
> stamps and one alarm.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Tested-by: Wolfgang Grandegger <wg@denx.de>
on my Freescale MPC8313 setup with ptpd and ptpv2d.
FYI: checkplatch.pl reports various errors for this patch series.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Stephen Hemminger @ 2010-05-17 15:59 UTC (permalink / raw)
To: Chris Wright; +Cc: davem, kaber, mitch.a.williams, arnd, scofeldm, netdev
In-Reply-To: <20100515031416.GE15313@sequoia.sous-sol.org>
On Fri, 14 May 2010 20:14:16 -0700
Chris Wright <chrisw@sous-sol.org> wrote:
> Now we have a set of nested attributes:
>
> IFLA_VFINFO_LIST (NESTED)
> IFLA_VF_INFO (NESTED)
> IFLA_VF_MAC
> IFLA_VF_VLAN
> IFLA_VF_TX_RATE
>
> This allows a single set to operate on multiple attributes if desired.
> Among other things, it means a dump can be replayed to set state.
>
> The current interface has yet to be released, so this seems like
> something to consider for 2.6.34.
>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org
> ---
iproute2 update please?
Also I would really like documentation on this.
--
^ permalink raw reply
* RE: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Williams, Mitch A @ 2010-05-17 16:02 UTC (permalink / raw)
To: Stephen Hemminger, Chris Wright
Cc: davem@davemloft.net, kaber@trash.net, arnd@arndb.de,
scofeldm@cisco.com, netdev@vger.kernel.org
In-Reply-To: <20100517085936.39016980@nehalam>
>-----Original Message-----
>From: Stephen Hemminger [mailto:shemminger@vyatta.com]
>Sent: Monday, May 17, 2010 9:00 AM
>To: Chris Wright
>Cc: davem@davemloft.net; kaber@trash.net; Williams, Mitch A;
>arnd@arndb.de; scofeldm@cisco.com; netdev@vger.kernel.org
>Subject: Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
>
>On Fri, 14 May 2010 20:14:16 -0700
>Chris Wright <chrisw@sous-sol.org> wrote:
>
>> Now we have a set of nested attributes:
>>
>> IFLA_VFINFO_LIST (NESTED)
>> IFLA_VF_INFO (NESTED)
>> IFLA_VF_MAC
>> IFLA_VF_VLAN
>> IFLA_VF_TX_RATE
>>
>> This allows a single set to operate on multiple attributes if desired.
>> Among other things, it means a dump can be replayed to set state.
>>
>> The current interface has yet to be released, so this seems like
>> something to consider for 2.6.34.
>>
>> Signed-off-by: Chris Wright <chrisw@sous-sol.org
>> ---
>
>iproute2 update please?
>
>Also I would really like documentation on this.
>
>
>--
Chris, have you got the iproute2 parts working, or do I need to pick it up?
Thanks again for your work on this.
-Mitch
^ permalink raw reply
* Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Chris Wright @ 2010-05-17 16:07 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Stephen Hemminger, Chris Wright, davem@davemloft.net,
kaber@trash.net, arnd@arndb.de, scofeldm@cisco.com,
netdev@vger.kernel.org
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FF3999206@rrsmsx501.amr.corp.intel.com>
* Williams, Mitch A (mitch.a.williams@intel.com) wrote:
> >-----Original Message-----
> >From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> >Sent: Monday, May 17, 2010 9:00 AM
> >To: Chris Wright
> >Cc: davem@davemloft.net; kaber@trash.net; Williams, Mitch A;
> >arnd@arndb.de; scofeldm@cisco.com; netdev@vger.kernel.org
> >Subject: Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
> >
> >On Fri, 14 May 2010 20:14:16 -0700
> >Chris Wright <chrisw@sous-sol.org> wrote:
> >
> >> Now we have a set of nested attributes:
> >>
> >> IFLA_VFINFO_LIST (NESTED)
> >> IFLA_VF_INFO (NESTED)
> >> IFLA_VF_MAC
> >> IFLA_VF_VLAN
> >> IFLA_VF_TX_RATE
> >>
> >> This allows a single set to operate on multiple attributes if desired.
> >> Among other things, it means a dump can be replayed to set state.
> >>
> >> The current interface has yet to be released, so this seems like
> >> something to consider for 2.6.34.
> >>
> >> Signed-off-by: Chris Wright <chrisw@sous-sol.org
> >> ---
> >
> >iproute2 update please?
> >
> >Also I would really like documentation on this.
And a pony? ;-)
Docs in what form?
> Chris, have you got the iproute2 parts working, or do I need to pick it up?
>
> Thanks again for your work on this.
I've got those bits, just was waiting until patches merged.
Will send them out this afternoon.
thanks,
-chris
^ permalink raw reply
* Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Chris Wright @ 2010-05-17 16:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Chris Wright, davem, kaber, mitch.a.williams, scofeldm,
shemminger, netdev
In-Reply-To: <201005151104.41158.arnd@arndb.de>
* Arnd Bergmann (arnd@arndb.de) wrote:
> On Saturday 15 May 2010 05:14:16 Chris Wright wrote:
> > Now we have a set of nested attributes:
> >
> > IFLA_VFINFO_LIST (NESTED)
> > IFLA_VF_INFO (NESTED)
> > IFLA_VF_MAC
> > IFLA_VF_VLAN
> > IFLA_VF_TX_RATE
> >
> > This allows a single set to operate on multiple attributes if desired.
> > Among other things, it means a dump can be replayed to set state.
> >
> > The current interface has yet to be released, so this seems like
> > something to consider for 2.6.34.
> >
> > Signed-off-by: Chris Wright <chrisw@sous-sol.org
>
> Very nice! This would be the minimum change to make the ABI conform
> to the general rules, so it would be really good to have that.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> It does make the interface a bit strange (less than before), since the
> new IFLA_VF_INFO now contains three nested attributes that each contain their
> own vf number field, and we don't require that they are identical or that
> each of the nested attributes inside VF_INFO appears only once.
>
> How about a second patch that splits out an IFLA_VF_NUMBER attribute
> and makes do_setvfinfo use nla_parse_nested instead of nla_for_each_nested
> in order to tighten the rules on this some more?
Yes, that's a great idea Arnd. I'll tighten that up.
thanks,
-chris
^ permalink raw reply
* [PATCH -next] bridge: fix build for CONFIG_SYSFS disabled
From: Randy Dunlap @ 2010-05-17 16:17 UTC (permalink / raw)
To: Stephen Rothwell, Stephen Hemminger; +Cc: linux-next, LKML, netdev, davem
In-Reply-To: <20100517163521.649526d0.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix build when CONFIG_SYSFS is not enabled:
net/bridge/br_if.c:136: error: 'struct net_bridge_port' has no member named 'sysfs_name'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
net/bridge/br_if.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-next-20100517.orig/net/bridge/br_if.c
+++ linux-next-20100517/net/bridge/br_if.c
@@ -133,7 +133,9 @@ static void del_nbp(struct net_bridge_po
struct net_bridge *br = p->br;
struct net_device *dev = p->dev;
+#ifdef CONFIG_SYSFS
sysfs_remove_link(br->ifobj, p->sysfs_name);
+#endif
dev_set_promiscuity(dev, -1);
^ permalink raw reply
* Re: [PATCH 1/37] drivers/net/wireless/libertas: Use kmemdup
From: Dan Williams @ 2010-05-17 16:35 UTC (permalink / raw)
To: Julia Lawall
Cc: John W. Linville, libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.64.1005152312060.21345-QfmoRoYWmW9knbxzx/v8hQ@public.gmane.org>
On Sat, 2010-05-15 at 23:12 +0200, Julia Lawall wrote:
> From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
>
> Use kmemdup when some other buffer is immediately copied into the
> allocated region.
>
> A simplified version of the semantic patch that makes this change is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression from,to,size,flag;
> statement S;
> @@
>
> - to = \(kmalloc\|kzalloc\)(size,flag);
> + to = kmemdup(from,size,flag);
> if (to==NULL || ...) S
> - memcpy(to, from, size);
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Acked-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/net/wireless/libertas/if_usb.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff -u -p a/drivers/net/wireless/libertas/if_usb.c b/drivers/net/wireless/libertas/if_usb.c
> --- a/drivers/net/wireless/libertas/if_usb.c
> +++ b/drivers/net/wireless/libertas/if_usb.c
> @@ -618,16 +618,14 @@ static void if_usb_receive_fwload(struct
> return;
> }
>
> - syncfwheader = kmalloc(sizeof(struct fwsyncheader), GFP_ATOMIC);
> + syncfwheader = kmemdup(skb->data + IPFIELD_ALIGN_OFFSET,
> + sizeof(struct fwsyncheader), GFP_ATOMIC);
> if (!syncfwheader) {
> lbs_deb_usbd(&cardp->udev->dev, "Failure to allocate syncfwheader\n");
> kfree_skb(skb);
> return;
> }
>
> - memcpy(syncfwheader, skb->data + IPFIELD_ALIGN_OFFSET,
> - sizeof(struct fwsyncheader));
> -
> if (!syncfwheader->cmd) {
> lbs_deb_usb2(&cardp->udev->dev, "FW received Blk with correct CRC\n");
> lbs_deb_usb2(&cardp->udev->dev, "FW received Blk seqnum = %d\n",
--
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: [PATCH 0/6] sky2: update
From: David Miller @ 2010-05-17 16:55 UTC (permalink / raw)
To: shemminger; +Cc: mikem, netdev
In-Reply-To: <20100514081957.00f342d5@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 14 May 2010 08:19:57 -0700
> On Fri, 14 May 2010 03:15:01 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Thu, 13 May 2010 09:12:47 -0700
>>
>> > Bunch of patches from Mike, with some additional comments.
>>
>> All applied to net-next-2.6, thanks.
>
> The first one needs to go to net-2.6 because it a regression:
> Current code will lose multicast addresses when the automatic
> recovery from stuck chip happens. Auto recovery happens a lot
> under load on some configurations.
2.6.34 got released yesterday, so it is a moot point.
Just submit it to -stable.
^ permalink raw reply
* Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
From: Stephen Hemminger @ 2010-05-17 16:55 UTC (permalink / raw)
To: Chris Wright
Cc: Williams, Mitch A, davem@davemloft.net, kaber@trash.net,
arnd@arndb.de, scofeldm@cisco.com, netdev@vger.kernel.org
In-Reply-To: <20100517160732.GA8301@sequoia.sous-sol.org>
On Mon, 17 May 2010 09:07:32 -0700
Chris Wright <chrisw@sous-sol.org> wrote:
> * Williams, Mitch A (mitch.a.williams@intel.com) wrote:
> > >-----Original Message-----
> > >From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> > >Sent: Monday, May 17, 2010 9:00 AM
> > >To: Chris Wright
> > >Cc: davem@davemloft.net; kaber@trash.net; Williams, Mitch A;
> > >arnd@arndb.de; scofeldm@cisco.com; netdev@vger.kernel.org
> > >Subject: Re: [PATCH] rtnetlink: make SR-IOV VF interface symmetric
> > >
> > >On Fri, 14 May 2010 20:14:16 -0700
> > >Chris Wright <chrisw@sous-sol.org> wrote:
> > >
> > >> Now we have a set of nested attributes:
> > >>
> > >> IFLA_VFINFO_LIST (NESTED)
> > >> IFLA_VF_INFO (NESTED)
> > >> IFLA_VF_MAC
> > >> IFLA_VF_VLAN
> > >> IFLA_VF_TX_RATE
> > >>
> > >> This allows a single set to operate on multiple attributes if desired.
> > >> Among other things, it means a dump can be replayed to set state.
> > >>
> > >> The current interface has yet to be released, so this seems like
> > >> something to consider for 2.6.34.
> > >>
> > >> Signed-off-by: Chris Wright <chrisw@sous-sol.org
> > >> ---
> > >
> > >iproute2 update please?
> > >
> > >Also I would really like documentation on this.
>
> And a pony? ;-)
>
> Docs in what form?
>
The man page for ip.8 already has some pieces from other version.
Just fix them. I just pushed up a couple of changes.
--
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Stephen Hemminger @ 2010-05-17 17:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <1274072629.2299.58.camel@edumazet-laptop>
On Mon, 17 May 2010 07:03:49 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 17 mai 2010 à 03:49 +0000, Bijay Singh a écrit :
>
> > I am on quite an old kernel 2.6.27 and could not apply your patches.
> >
> > Then i moved on to the kernel 2.6.32.11 however since then I have not been able to bring up my card, this is something i need to fix before i can test you fix. Working on that.
> >
>
> Thanks again for the status report.
>
> I see bug is older than what I stated in my previous mail
>
> I could reproduce it in my lab and confirm following patch fixes it
>
> This is a stable candidate (2.6.27 kernels)
>
> Thanks
>
> [PATCH] tcp: tcp_synack_options() fix
>
> Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
> if MD5+SACK+timestamps were used in initial SYN message.
>
> Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
> sessions, but since 20 bytes of tcp options space are not enough to
> store all the bits needed, we chose to disable timestamps in this case.
>
> We send a SYN-ACK _without_ timestamp option, but socket has timestamps
> enabled and all further outgoing messages contain a TS block, all with
> the initial timestamp of the remote peer.
>
> Fix is to really disable timestamps option for the whole session.
>
> Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/tcp_output.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 0dda86e..b8bb226 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -667,7 +667,7 @@ static unsigned tcp_synack_options(struct sock *sk,
> u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
> xvp->cookie_plus :
> 0;
> - bool doing_ts = ireq->tstamp_ok;
> + bool doing_ts;
>
> #ifdef CONFIG_TCP_MD5SIG
> *md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
> @@ -680,11 +680,12 @@ static unsigned tcp_synack_options(struct sock *sk,
> * rather than TS in order to fit in better with old,
> * buggy kernels, but that was deemed to be unnecessary.
> */
> - doing_ts &= !ireq->sack_ok;
> + ireq->tstamp_ok &= !ireq->sack_ok;
> }
> #else
> *md5 = NULL;
> #endif
> + doing_ts = ireq->tstamp_ok;
>
> /* We always send an MSS option. */
> opts->mss = mss;
>
>
Make this gets back to stable as well.
--
^ permalink raw reply
* Re: [PATCH BUGFIX ] ipv6: fix the bug of address check
From: Stephen Hemminger @ 2010-05-17 17:31 UTC (permalink / raw)
To: Shan Wei; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <4BF1354A.3060003@cn.fujitsu.com>
On Mon, 17 May 2010 20:23:38 +0800
Shan Wei <shanwei@cn.fujitsu.com> wrote:
>
> If there are several IPv6 addresses with same hash value in hashlist,
> and they are all not matched with addr argument.
> In this case, ipv6_chk_addr() should return 0.
>
> This bug is introduced by commit c2e21293c054817c42eb5fa9c613d2ad51954136
> (title: ipv6: convert addrconf list to hlist).
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
> ---
> net/ipv6/addrconf.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 3984f52..d8e5907 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1291,7 +1291,7 @@ int ipv6_chk_addr(struct net *net, struct in6_addr *addr,
> }
> rcu_read_unlock_bh();
>
> - return ifp != NULL;
> + return node != NULL;
> }
> EXPORT_SYMBOL(ipv6_chk_addr);
>
Why not this instead. I don't like depending on the value of the
loop variable in the hlist_for_each()
--- a/net/ipv6/addrconf.c 2010-05-17 10:27:58.218628126 -0700
+++ b/net/ipv6/addrconf.c 2010-05-17 10:29:46.012198338 -0700
@@ -1274,7 +1274,7 @@ static int ipv6_count_addresses(struct i
int ipv6_chk_addr(struct net *net, struct in6_addr *addr,
struct net_device *dev, int strict)
{
- struct inet6_ifaddr *ifp = NULL;
+ struct inet6_ifaddr *ifp;
struct hlist_node *node;
unsigned int hash = ipv6_addr_hash(addr);
@@ -1283,15 +1283,16 @@ int ipv6_chk_addr(struct net *net, struc
if (!net_eq(dev_net(ifp->idev->dev), net))
continue;
if (ipv6_addr_equal(&ifp->addr, addr) &&
- !(ifp->flags&IFA_F_TENTATIVE)) {
- if (dev == NULL || ifp->idev->dev == dev ||
- !(ifp->scope&(IFA_LINK|IFA_HOST) || strict))
- break;
+ !(ifp->flags&IFA_F_TENTATIVE) &&
+ (dev == NULL || ifp->idev->dev == dev ||
+ !(ifp->scope&(IFA_LINK|IFA_HOST) || strict))) {
+ rcu_read_unlock_bh();
+ return 1;
}
}
- rcu_read_unlock_bh();
- return ifp != NULL;
+ rcu_read_unlock_bh();
+ return 0;
}
EXPORT_SYMBOL(ipv6_chk_addr);
--
^ permalink raw reply
* Re: [PATCH -next] bridge: fix build for CONFIG_SYSFS disabled
From: Stephen Hemminger @ 2010-05-17 17:56 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, netdev, davem
In-Reply-To: <20100517091756.e232bdc2.randy.dunlap@oracle.com>
On Mon, 17 May 2010 09:17:56 -0700
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix build when CONFIG_SYSFS is not enabled:
>
> net/bridge/br_if.c:136: error: 'struct net_bridge_port' has no member named 'sysfs_name'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> net/bridge/br_if.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-next-20100517.orig/net/bridge/br_if.c
> +++ linux-next-20100517/net/bridge/br_if.c
> @@ -133,7 +133,9 @@ static void del_nbp(struct net_bridge_po
> struct net_bridge *br = p->br;
> struct net_device *dev = p->dev;
>
> +#ifdef CONFIG_SYSFS
> sysfs_remove_link(br->ifobj, p->sysfs_name);
> +#endif
>
> dev_set_promiscuity(dev, -1);
>
I don't like peppering code with #ifdef like this.
Turns out that in this place sysfs_name is always the same
as the device name so instead:
--- a/net/bridge/br_if.c 2010-05-17 10:40:49.808031840 -0700
+++ b/net/bridge/br_if.c 2010-05-17 10:49:47.767669246 -0700
@@ -133,7 +133,7 @@ static void del_nbp(struct net_bridge_po
struct net_bridge *br = p->br;
struct net_device *dev = p->dev;
- sysfs_remove_link(br->ifobj, p->sysfs_name);
+ sysfs_remove_link(br->ifobj, p->dev->name);
dev_set_promiscuity(dev, -1);
--
^ permalink raw reply
* Re: [PATCH -next] bridge: fix build for CONFIG_SYSFS disabled
From: Randy Dunlap @ 2010-05-17 18:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Stephen Rothwell, linux-next, LKML, netdev, davem
In-Reply-To: <20100517105654.2451e61f@nehalam>
On 05/17/10 10:56, Stephen Hemminger wrote:
> On Mon, 17 May 2010 09:17:56 -0700
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Fix build when CONFIG_SYSFS is not enabled:
>>
>> net/bridge/br_if.c:136: error: 'struct net_bridge_port' has no member named 'sysfs_name'
>>
>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>> ---
>> net/bridge/br_if.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> --- linux-next-20100517.orig/net/bridge/br_if.c
>> +++ linux-next-20100517/net/bridge/br_if.c
>> @@ -133,7 +133,9 @@ static void del_nbp(struct net_bridge_po
>> struct net_bridge *br = p->br;
>> struct net_device *dev = p->dev;
>>
>> +#ifdef CONFIG_SYSFS
>> sysfs_remove_link(br->ifobj, p->sysfs_name);
>> +#endif
>>
>> dev_set_promiscuity(dev, -1);
>>
>
> I don't like peppering code with #ifdef like this.
Thanks. I didn't like it either.
> Turns out that in this place sysfs_name is always the same
> as the device name so instead:
>
>
> --- a/net/bridge/br_if.c 2010-05-17 10:40:49.808031840 -0700
> +++ b/net/bridge/br_if.c 2010-05-17 10:49:47.767669246 -0700
> @@ -133,7 +133,7 @@ static void del_nbp(struct net_bridge_po
> struct net_bridge *br = p->br;
> struct net_device *dev = p->dev;
>
> - sysfs_remove_link(br->ifobj, p->sysfs_name);
> + sysfs_remove_link(br->ifobj, p->dev->name);
>
> dev_set_promiscuity(dev, -1);
>
>
>
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH v3 3/3] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Scott Wood @ 2010-05-17 18:05 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, devicetree-discuss, linuxppc-dev
In-Reply-To: <20100517082757.GA9703@riccoc20.at.omicron.at>
On 05/17/2010 03:27 AM, Richard Cochran wrote:
> On Fri, May 14, 2010 at 12:46:57PM -0500, Scott Wood wrote:
>> On 05/14/2010 11:46 AM, Richard Cochran wrote:
>>> diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
>>
>> Get rid of both device_type and model, and specify a compatible
>> string instead (e.g. "fsl,etsec-ptp").
>
> Okay, will do. I really am at a loss at understanding all the rules in
> the whole device tree world. I just tried to follow
> Documentation/powerpc and what is already present in the kernel.
There's some stuff in there that isn't how we'd do it now, but is slow
to change for compatibility reasons.
>> Or perhaps this should just be some additional properties on the
>> existing gianfar nodes, rather than presenting it as a separate
>> device? How do you associate a given ptp block with the
>> corresponding gianfar node?
>
> There only one PTP clock. Its registers repeat in each port's memory
> space, but you are only supposed to touch the first set of PTP
> registers.
OK. I'm not too familiar with PTP itself, was looking more at the
device tree and similar structural bits.
> There are no differences (that I know of) in how the PTP clocks
> work. I have in house the mpc8313, the mpc8572, and the p2020. The
> mpc8572 appears to lack some of the TMR_CTRL bits, but this is
> probably a documentation bug. I will check it.
If there's any possibility of needing to make a distinction (which
probably can't be ruled out with future chips), the chip name could be
made part of the compatible string, with a secondary compatible showing
a canonical part name for that version of the PTP block. E.g. p2020
might have:
compatble = "fsl,p2020-etsec-ptp", "fsl,mpc8313-etsec-ptp";
The driver would bind only on the mpc8313 version.
There are several examples of this, such as the Freescale i2c driver and
binding (ignore the legacy "fsl-i2c").
>> > >+ - tmr_fiper1 Fixed interval period pulse generator.
>> > >+ - tmr_fiper2 Fixed interval period pulse generator.
>>
MPC8572 and P2020 have fiper3 as well.
>> They should probably have an "fsl,ptp-" prefix as well.
>
> Okay, but must I then change the following code in order to find them?
> Does adding the prefix just mean that I also add it to my search
> strings, or is it preprocessed (stripped) somehow?
It is not stripped; you have to change the code as well.
>> You've got two IRQs, with the same handler, and the same dev_id?
>> From the manual it looks like there's one PTP interrupt per eTSEC
>> (which would explain 3 interrupts on p2020).
>
> Will reduce to just one IRQ.
The device tree should still contain all of the interrupts, in case
they're needed later -- and put a comment in the driver saying why the
first interrupt seems sufficient.
>>> +static struct of_device_id match_table[] = {
>>> + { .type = "ptp_clock" },
>>> + {},
>>> +};
>>
>> This driver controls every possible PTP implementation?
>
> No, I only want to match with the eTSEC clock device. Given the
> compatible string above ("fsl,etsec-ptp"), what is the correct way to
> do this? (pointer to an existing driver to emulate would be enough)
Put .compatible = "fsl,etsec-ptp" (or "fsl,mpc8313-etsec-ptp") where you
have .type = "ptp_clock".
-Scott
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 18:11 UTC (permalink / raw)
To: David Miller
Cc: ebiederm, gregkh, kay.sievers, linux-kernel, tj, cornelia.huck,
eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100515.232643.212422307.davem@davemloft.net>
On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Thu, 6 May 2010 13:04:04 -0700
>
> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >>
> >> With the tagged sysfs support finally merged into Greg's tree,
> >> it is time for the last little bits of work to get the kobject
> >> layer and network namespaces to play together properly.
> >>
> >> These patches are roughly evenly divided between network layer work
> >> and sysfs layer work. Last time this conundrum came up I believe
> >> we decided that the easiest way to handle this was for Greg to carry
> >> all of the patches. David, Greg does that still make sense?
> >
> > That's fine, if I get David's ack on these.
>
> Looks good to me:
>
> Acked-by: David S. Miller <davem@davemloft.net>
Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
them up then to get some testing in linux-next so that they can make it
into .36?
thanks,
greg k-h
^ permalink raw reply
* pull request: wireless-next-2.6 2010-05-17
From: John W. Linville @ 2010-05-17 18:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
One last big batch intended for 2.6.35 -- these have all been in
linux-next for several days. Included are the usual driver updates for
iwlwifi, ath9k, and rt2x00 along with a smattering of other bits
(including some trivial fixups).
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 278554bd6579206921f5d8a523649a7a57f8850d:
David S. Miller (1):
Merge branch 'master' of master.kernel.org:/.../davem/net-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Abhijeet Kolekar (3):
iwl3945: fix scan races
iwl3945: add plcp error checking
mac80211: fix paged defragmentation
Dan Carpenter (3):
wl1271: add missing spin_lock()
wl1271: fix notifier interface supported test
wl1271: remove some unneeded code
Felix Fietkau (4):
ath9k: use debugfs_remove_recursive() instead of keeping pointers to all entries
ath9k: add debugfs files for reading/writing the rx and tx chainmask
ath9k: add debugfs files for reading/writing registers
ath9k_hw: clean up EEPROM endian handling on AR9003
Gertjan van Wingerde (6):
rt2x00: Consistently name skb frame descriptor skbdesc.
rt2x00: Fix beacon descriptor writing for rt61pci.
rt2x00: Re-order tx descriptor writing code in drivers.
rt2x00: Simplify TXD handling of beacons.
rt2x00: Dump beacons under a different identifier than TX frames.
rt2x00: In debugfs frame dumping allow the TX descriptor to be part of the skb.
Johannes Berg (34):
iwlagn: wait for asynchronous firmware loading
iwlwifi: use vif iwl_bss_info_changed
iwl3945: use iwl3945_add_bcast_station
iwlwifi: pass address to iwl_remove_station
iwlwifi: manage IBSS station properly
iwlagn: show and store firmware build number
iwl3945: remove ucode access indirection
iwlwifi: remove ucode virtual functions
iwlwifi: move eeprom version printout to eeprom init
iwlagn: prepare for new firmware file format
iwlagn: implement loading a new firmware file type
iwlwifi: remove rts_threshold
iwlagn: move iwl_get_ra_sta_id to 4965
iwlagn: use vif->type to check station
iwlwifi: apply filter flags directly
iwlwifi: push virtual interface through
iwlagn: use virtual interface in TX aggregation handling
iwlwifi: remove useless priv->vif check
iwlwifi: use vif in iwl_ht_conf
iwlwifi: note that priv->bssid is used only by 3945
iwlwifi: fix iwl_sta_init_lq station ID
iwlwifi: split allocation/sending local station LQ
iwlwifi: rework broadcast station management
iwlwifi: track station IDs
iwlwifi: add iwl_sta_id()
iwlwifi: use iwl_find_station less
iwlagn: use iwl_sta_id() for aggregation
iwlwifi: use iwl_sta_id() for TKIP key update
iwlwifi: move iwl_find_station() to 4965
iwlwifi: rename iwl_add_local_station
iwlwifi: remove pointless HT check
iwlwifi: clear driver stations when going down
mac80211: don't process work item with wrong frame
mac80211: add offload channel switch support
John W. Linville (2):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Julia Lawall (1):
drivers/net/wireless/hostap: Drop memory allocation cast
Luis R. Rodriguez (2):
ath5k: drop warning on jumbo frames
ath9k_hw: new initialization values for AR9003
Reinette Chatre (3):
Merge branch 'wireless-2.6' into wireless-next-2.6
iwlwifi: make bcast LQ command available for later restore actions
iwlagn: work around rate scaling reset delay
Shanyu Zhao (2):
iwlwifi: rename 6000 series Gen2 devices to Gen2a
iwlwifi: dump firmware build info in error case
Steve Tanner (1):
ar9170usb: add vendor and device ID for Qwest/Actiontec 802AIN Wireless N USB Network Adapter
Sujith.Manoharan-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org (5):
ath9k_htc: Lock sta_notify() callback
ath9k_htc: Allocate URBs properly
ath9k_htc: Reorder HTC initialization
ath9k_htc: Fix target ready race condition
ath9k_htc: Fix array overflow
Vasanthakumar Thiagarajan (2):
ath9k: Fix bug in handling rx frames with invalid descriptor content
ath9k: Remove unused rx_edma in ath_rx_addbuffer_edma()
Wey-Yi Guy (11):
iwlwifi: remove powersave debugfs if it is not supported
iwlwifi: rename "tx_power" to "chain_tx_power"
iwlwifi: remove device type checking for tx power in debugfs
iwlwifi: use .cfg to enable/disable continuous ucode trace
iwlwifi: use cfg to configure calibration operation
iwlwifi: give correct return information for tx power debugfs
iwlwifi: wimax co-exist code clean up
iwlwifi: checking for all the possible failure cases
iwlwifi: "tx power per chain" are part of ucode_tx_stats
iwlwifi: provide more comments for cfg structure
mac80211: check channel switch mode for future frames transmit
drivers/net/wireless/ath/ar9170/usb.c | 2 +
drivers/net/wireless/ath/ath5k/base.c | 12 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 174 +++----
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_initvals.h | 268 ++++++------
drivers/net/wireless/ath/ath9k/debug.c | 236 ++++++++--
drivers/net/wireless/ath/ath9k/debug.h | 8 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 58 ++--
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 7 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 +
drivers/net/wireless/ath/ath9k/htc_hst.c | 51 +-
drivers/net/wireless/ath/ath9k/htc_hst.h | 15 +-
drivers/net/wireless/ath/ath9k/recv.c | 3 +-
drivers/net/wireless/hostap/hostap_80211_rx.c | 3 +-
drivers/net/wireless/hostap/hostap_ioctl.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 147 ++++--
drivers/net/wireless/iwlwifi/iwl-3945.h | 22 +-
drivers/net/wireless/iwlwifi/iwl-4965.c | 100 +++--
drivers/net/wireless/iwlwifi/iwl-5000.c | 27 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 51 ++-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 16 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 31 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 29 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 109 +++--
drivers/net/wireless/iwlwifi/iwl-agn.c | 556 +++++++++++++++-------
drivers/net/wireless/iwlwifi/iwl-agn.h | 14 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 6 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 199 +++-----
drivers/net/wireless/iwlwifi/iwl-core.h | 60 ++-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 66 +--
drivers/net/wireless/iwlwifi/iwl-dev.h | 89 +++-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 7 +
drivers/net/wireless/iwlwifi/iwl-power.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 456 ++++++++----------
drivers/net/wireless/iwlwifi/iwl-sta.h | 60 ++-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 163 ++++---
drivers/net/wireless/rt2x00/rt2400pci.c | 26 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 26 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 55 ++-
drivers/net/wireless/rt2x00/rt2800pci.c | 14 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 21 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 3 +
drivers/net/wireless/rt2x00/rt2x00pci.c | 9 -
drivers/net/wireless/rt2x00/rt2x00queue.c | 15 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 3 +
drivers/net/wireless/rt2x00/rt2x00usb.c | 8 -
drivers/net/wireless/rt2x00/rt61pci.c | 35 +-
drivers/net/wireless/rt2x00/rt73usb.c | 71 ++--
drivers/net/wireless/wl12xx/wl1271_main.c | 5 +-
include/net/mac80211.h | 39 ++
net/mac80211/driver-ops.h | 11 +
net/mac80211/driver-trace.h | 49 ++
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/mlme.c | 59 +++-
net/mac80211/rx.c | 6 +
net/mac80211/work.c | 27 +-
60 files changed, 2152 insertions(+), 1442 deletions(-)
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-05-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: [PATCH net-next-2.6 2/2] bonding: allow user-controlled output slave selection
From: Neil Horman @ 2010-05-17 18:45 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Jay Vosburgh, netdev
In-Reply-To: <20100513171504.GD21535@shamino.rdu.redhat.com>
On Thu, May 13, 2010 at 01:15:04PM -0400, Neil Horman wrote:
> On Wed, May 12, 2010 at 06:14:08PM -0400, Andy Gospodarek wrote:
> > On Wed, May 12, 2010 at 12:41:54PM -0700, Jay Vosburgh wrote:
> > > Neil Horman <nhorman@tuxdriver.com> wrote:
> > >
> > > >On Tue, May 11, 2010 at 01:09:39PM -0700, Jay Vosburgh wrote:
> > > >> Andy Gospodarek <andy@greyhouse.net> wrote:
> > > >>
> > > >> >This patch give the user the ability to control the output slave for
> > > >> >round-robin and active-backup bonding. Similar functionality was
> > > >> >discussed in the past, but Jay Vosburgh indicated he would rather see a
> > > >> >feature like this added to existing modes rather than creating a
> > > >> >completely new mode. Jay's thoughts as well as Neil's input surrounding
> > > >> >some of the issues with the first implementation pushed us toward a
> > > >> >design that relied on the queue_mapping rather than skb marks.
> > > >> >Round-robin and active-backup modes were chosen as the first users of
> > > >> >this slave selection as they seemed like the most logical choices when
> > > >> >considering a multi-switch environment.
> > > >> >
> > > >> >Round-robin mode works without any modification, but active-backup does
> > > >> >require inclusion of the first patch in this series and setting
> > > >> >the 'keep_all' flag. This will allow reception of unicast traffic on
> > > >> >any of the backup interfaces.
> > > >>
> > > >> Yes, I did think that the mark business fit better into existing
> > > >> modes (I thought of it as kind of a new hash for xor and 802.3ad modes).
> > > >> I also didn't expect to see so much new stuff (this, as well as the FCOE
> > > >> special cases being discussed elsewhere) being shoehorned into the
> > > >> active-backup mode. I'm not so sure that adding so many special cases
> > > >> to active-backup is a good thing.
> > > >>
> > > >> Now, I'm starting to wonder if you were right, and it would be
> > > >> better overall to have a "manual" mode that would hopefully satisfy this
> > > >> case as well as the FCOE special case. I don't think either of these is
> > > >> a bad use case, I'm just not sure the right way to handle them is
> > > >> another special knob in active-backup mode (either directly, or
> > > >> implicitly in __netif_receive_skb), which wasn't what I expected to see.
> > > >>
> > > >I honestly don't think a separate mode is warranted here. While I'm not opposed
> > > >to adding a new mode, I really think doing so is no different from overloading
> > > >an existing mode. I say that because to add a new mode in which we explicitly
> > > >expect traffic to be directed to various slaves requires that we implement a
> > > >policy for frames which have no queue mapping determined on egress. Any policy
> > > >I can think of is really an approximation of an existing policy, so we may as
> > > >well reuse the policy code that we already have in place. About the only way a
> > > >separate mode makes sense is in the 'passthrough' queue mode you document below.
> > > >In this model, in which queue ids map to slaves in a 1:1 fashion it doesn't make
> > > >senes.
> > >
> > > One goal I'm hoping to achieve is something that would satisfy
> > > both the queue map stuff that you're looking for, and would meet the
> > > needs of the FCOE people who also want to disable the duplicate
> > > suppression (i.e., permit incoming traffic on the inactive slave) for a
> > > different special case.
> > >
> > > The FCOE proposal revolves around, essentially, active-backup
> > > mode, but permitting incoming traffic on the inactive slave. At the
> > > moment, the patches attempt to special case things such that only
> > > dev_add_pack listeners directly bound to the inactive slave are checked
> > > (to permit the FCOE traffic to pass on the inactive slave, but still
> > > dropping IP, as ip_rcv is a wildcard bind).
> > >
> > > Your keep_all patch is, by and large, the same thing, except
> > > that it permits anything to come in on the "inactive" slave, and it's a
> > > switch that has to be turned on.
> > >
> > > This seems like needless duplication to me; I'd prefer to see a
> > > single solution that handles both cases instead of two special cases
> > > that each do 90% of what the other does.
> > >
> > > As far as a new mode goes, one major reason I think a separate
> > > mode is warranted is the semantics: with either of these changes (to
> > > permit more or less regular use of the "inactive" slaves), the mode
> > > isn't really an "active-backup" mode any longer; there is no "inactive"
> > > or "backup" slave. I think of this as being a major change of
> > > functionality, not simply a minor option.
> > >
> > > Hence my thought that "active-backup" could stay as a "true" hot
> > > standby mode (backup slaves are just that: for backup, only), and this
> > > new mode would be the place to do the special queue-map / FCOE /
> > > whatever that isn't really a hot standby configuration any longer.
> > >
> > > As far as the behavior of the new mode (your concern about its
> > > policy map approximations), in the end, it would probably act pretty
> > > much like active-backup with your patch applied: traffic goes out the
> > > active slave, unless directed otherwise. It's a lot less complicated
> > > than I had feared.
> > >
> >
> > It's beginning to sound like the 'FCoE use-case' and the one Neil and I
> > are proposing are quite similar. The main goal of both is to have the
> > option to have multiple slaves send and receive traffic during the
> > steady-state, but in the event of a failover all traffic would run on a
> > single interface.
> >
> > The implementation proposed with this patch is a bit different that the
> > 'mark-mode' patch you may recall I posted a few months ago. It created
> > a new mode that essentially did exactly what you are describing --
> > transmit on the primary interface unless pushed to another interface via
> > info in the skb and receive on all interfaces. We initially did not
> > create a new mode based on your reservations about the previous
> > mark-mode patch and went the direction of enhancing one or two modes
> > initially (figuring it would be good to run before walking), with the
> > idea that other modes could take care of this output slave selection
> > logic in the future.
>
>
> So, its sounding to me like everyone is leaning toward a new mode approach here.
> Before we go ahead and start coding, I hear the bullet points for this approach
> as:
>
> 1) Implement a new bond mode where queue ids are used to steer frames to output
> interfaces
>
> 2) Use said mode to imply universal frame reception (i.e. remove the keep_all
> knob, and turn on that behavior when this new mode is selected)
>
> 3) use John F.'s skb_should_drop changes to implement the keep_all feature.
>
> Does that sound about right?
>
> Regards
> Neil
>
Ping, Jay, any feedback on these bullet points. I'd like to keep working on
this while we have the time, but I'd rather not play guess & check on the list
here any more than we need to.
> --
> 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
* iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 19:03 UTC (permalink / raw)
To: NetDev
On older releases, you can do this with iproute:
# ip ru add from 9.9.9.2/32 table 226 pref 400
#
But, in latest git, it returns an error:
# ip ru add from 9.9.9.2/32 table 226 pref 400
Error: an inet prefix is expected rather than "9.9.9.2/32".
Is that on purpose?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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