* [PATCH 01/11] pcmcia: use pcmica_{read,write}_config_byte
From: Dominik Brodowski @ 2010-08-01 12:59 UTC (permalink / raw)
To: linux-pcmcia
Cc: Dominik Brodowski, netdev, linux-wireless, linux-serial,
Michael Buesch
In-Reply-To: <20100801125749.GA2564@comet.dominikbrodowski.net>
Use pcmcia_read_config_byte and pcmcia_write_config_byte instead
of pcmcia_access_configuration_register.
CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: linux-serial@vger.kernel.org
CC: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
---
drivers/net/pcmcia/axnet_cs.c | 3 +-
drivers/net/pcmcia/nmclan_cs.c | 21 ++-----
drivers/net/pcmcia/xirc2ps_cs.c | 16 ++---
drivers/net/wireless/hostap/hostap_cs.c | 91 ++++++++--------------------
drivers/net/wireless/orinoco/spectrum_cs.c | 32 +++-------
drivers/pcmcia/cistpl.c | 7 +-
drivers/pcmcia/cs_internal.h | 4 +-
drivers/pcmcia/pcmcia_resource.c | 72 +++++++++++++---------
drivers/serial/serial_cs.c | 8 +--
drivers/ssb/pcmcia.c | 14 +----
include/pcmcia/cs.h | 12 ----
include/pcmcia/ds.h | 4 +-
12 files changed, 105 insertions(+), 179 deletions(-)
diff --git a/drivers/net/pcmcia/axnet_cs.c b/drivers/net/pcmcia/axnet_cs.c
index 467fd4b..ee0a6d0 100644
--- a/drivers/net/pcmcia/axnet_cs.c
+++ b/drivers/net/pcmcia/axnet_cs.c
@@ -378,8 +378,7 @@ static int axnet_config(struct pcmcia_device *link)
/* Maybe PHY is in power down mode. (PPD_SET = 1)
Bit 2 of CCSR is active low. */
if (i == 32) {
- conf_reg_t reg = { 0, CS_WRITE, CISREG_CCSR, 0x04 };
- pcmcia_access_configuration_register(link, ®);
+ pcmcia_write_config_byte(link, CISREG_CCSR, 0x04);
for (i = 0; i < 32; i++) {
j = mdio_read(dev->base_addr + AXNET_MII_EEP, i, 1);
j2 = mdio_read(dev->base_addr + AXNET_MII_EEP, i, 2);
diff --git a/drivers/net/pcmcia/nmclan_cs.c b/drivers/net/pcmcia/nmclan_cs.c
index c0eacfa..c0d85af 100644
--- a/drivers/net/pcmcia/nmclan_cs.c
+++ b/drivers/net/pcmcia/nmclan_cs.c
@@ -757,29 +757,20 @@ static void nmclan_reset(struct net_device *dev)
#if RESET_XILINX
struct pcmcia_device *link = &lp->link;
- conf_reg_t reg;
- u_long OrigCorValue;
+ u8 OrigCorValue;
/* Save original COR value */
- reg.Function = 0;
- reg.Action = CS_READ;
- reg.Offset = CISREG_COR;
- reg.Value = 0;
- pcmcia_access_configuration_register(link, ®);
- OrigCorValue = reg.Value;
+ pcmcia_read_config_byte(link, CISREG_COR, &OrigCorValue);
/* Reset Xilinx */
- reg.Action = CS_WRITE;
- reg.Offset = CISREG_COR;
- dev_dbg(&link->dev, "nmclan_reset: OrigCorValue=0x%lX, resetting...\n",
+ dev_dbg(&link->dev, "nmclan_reset: OrigCorValue=0x%x, resetting...\n",
OrigCorValue);
- reg.Value = COR_SOFT_RESET;
- pcmcia_access_configuration_register(link, ®);
+ pcmcia_write_config_byte(link, CISREG_COR, COR_SOFT_RESET);
/* Need to wait for 20 ms for PCMCIA to finish reset. */
/* Restore original COR configuration index */
- reg.Value = COR_LEVEL_REQ | (OrigCorValue & COR_CONFIG_MASK);
- pcmcia_access_configuration_register(link, ®);
+ pcmcia_write_config_byte(link, CISREG_COR,
+ (COR_LEVEL_REQ | (OrigCorValue & COR_CONFIG_MASK)));
/* Xilinx is now completely reset along with the MACE chip. */
lp->tx_free_frames=AM2150_MAX_TX_FRAMES;
diff --git a/drivers/net/pcmcia/xirc2ps_cs.c b/drivers/net/pcmcia/xirc2ps_cs.c
index a7662f0..add6c82 100644
--- a/drivers/net/pcmcia/xirc2ps_cs.c
+++ b/drivers/net/pcmcia/xirc2ps_cs.c
@@ -869,7 +869,6 @@ xirc2ps_config(struct pcmcia_device * link)
goto config_error;
if (local->dingo) {
- conf_reg_t reg;
win_req_t req;
memreq_t mem;
@@ -878,15 +877,14 @@ xirc2ps_config(struct pcmcia_device * link)
* the base address of the ethernet port (BasePort1) is written
* to the BAR registers of the modem.
*/
- reg.Action = CS_WRITE;
- reg.Offset = CISREG_IOBASE_0;
- reg.Value = link->io.BasePort2 & 0xff;
- if ((err = pcmcia_access_configuration_register(link, ®)))
+ err = pcmcia_write_config_byte(link, CISREG_IOBASE_0,
+ link->io.BasePort2 & 0xff);
+ if (err)
goto config_error;
- reg.Action = CS_WRITE;
- reg.Offset = CISREG_IOBASE_1;
- reg.Value = (link->io.BasePort2 >> 8) & 0xff;
- if ((err = pcmcia_access_configuration_register(link, ®)))
+
+ err = pcmcia_write_config_byte(link, CISREG_IOBASE_1,
+ link->io.BasePort2 & 0xff);
+ if (err)
goto config_error;
/* There is no config entry for the Ethernet part which
diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c
index 2f4b6d4..def63bf 100644
--- a/drivers/net/wireless/hostap/hostap_cs.c
+++ b/drivers/net/wireless/hostap/hostap_cs.c
@@ -224,27 +224,18 @@ static int prism2_pccard_card_present(local_info_t *local)
static void sandisk_set_iobase(local_info_t *local)
{
int res;
- conf_reg_t reg;
struct hostap_cs_priv *hw_priv = local->hw_priv;
- reg.Function = 0;
- reg.Action = CS_WRITE;
- reg.Offset = 0x10; /* 0x3f0 IO base 1 */
- reg.Value = hw_priv->link->io.BasePort1 & 0x00ff;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ res = pcmcia_write_config_byte(hw_priv->link, 0x10,
+ hw_priv->link->io.BasePort1 & 0x00ff);
if (res != 0) {
printk(KERN_DEBUG "Prism3 SanDisk - failed to set I/O base 0 -"
" res=%d\n", res);
}
udelay(10);
- reg.Function = 0;
- reg.Action = CS_WRITE;
- reg.Offset = 0x12; /* 0x3f2 IO base 2 */
- reg.Value = (hw_priv->link->io.BasePort1 & 0xff00) >> 8;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ res = pcmcia_write_config_byte(hw_priv->link, 0x12,
+ hw_priv->link->io.BasePort1 & 0x00ff);
if (res != 0) {
printk(KERN_DEBUG "Prism3 SanDisk - failed to set I/O base 1 -"
" res=%d\n", res);
@@ -270,7 +261,6 @@ static void sandisk_write_hcr(local_info_t *local, int hcr)
static int sandisk_enable_wireless(struct net_device *dev)
{
int res, ret = 0;
- conf_reg_t reg;
struct hostap_interface *iface = netdev_priv(dev);
local_info_t *local = iface->local;
struct hostap_cs_priv *hw_priv = local->hw_priv;
@@ -297,12 +287,8 @@ static int sandisk_enable_wireless(struct net_device *dev)
" - using vendor-specific initialization\n", dev->name);
hw_priv->sandisk_connectplus = 1;
- reg.Function = 0;
- reg.Action = CS_WRITE;
- reg.Offset = CISREG_COR;
- reg.Value = COR_SOFT_RESET;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ res = pcmcia_write_config_byte(hw_priv->link, CISREG_COR,
+ COR_SOFT_RESET);
if (res != 0) {
printk(KERN_DEBUG "%s: SanDisk - COR sreset failed (%d)\n",
dev->name, res);
@@ -310,16 +296,13 @@ static int sandisk_enable_wireless(struct net_device *dev)
}
mdelay(5);
- reg.Function = 0;
- reg.Action = CS_WRITE;
- reg.Offset = CISREG_COR;
/*
* Do not enable interrupts here to avoid some bogus events. Interrupts
* will be enabled during the first cor_sreset call.
*/
- reg.Value = COR_LEVEL_REQ | 0x8 | COR_ADDR_DECODE | COR_FUNC_ENA;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ res = pcmcia_write_config_byte(hw_priv->link, CISREG_COR,
+ (COR_LEVEL_REQ | 0x8 | COR_ADDR_DECODE |
+ COR_FUNC_ENA));
if (res != 0) {
printk(KERN_DEBUG "%s: SanDisk - COR sreset failed (%d)\n",
dev->name, res);
@@ -342,30 +325,23 @@ done:
static void prism2_pccard_cor_sreset(local_info_t *local)
{
int res;
- conf_reg_t reg;
+ u8 val;
struct hostap_cs_priv *hw_priv = local->hw_priv;
if (!prism2_pccard_card_present(local))
return;
- reg.Function = 0;
- reg.Action = CS_READ;
- reg.Offset = CISREG_COR;
- reg.Value = 0;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ res = pcmcia_read_config_byte(hw_priv->link, CISREG_COR, &val);
if (res != 0) {
printk(KERN_DEBUG "prism2_pccard_cor_sreset failed 1 (%d)\n",
res);
return;
}
printk(KERN_DEBUG "prism2_pccard_cor_sreset: original COR %02x\n",
- reg.Value);
+ val);
- reg.Action = CS_WRITE;
- reg.Value |= COR_SOFT_RESET;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ val |= COR_SOFT_RESET;
+ res = pcmcia_write_config_byte(hw_priv->link, CISREG_COR, val);
if (res != 0) {
printk(KERN_DEBUG "prism2_pccard_cor_sreset failed 2 (%d)\n",
res);
@@ -374,11 +350,10 @@ static void prism2_pccard_cor_sreset(local_info_t *local)
mdelay(hw_priv->sandisk_connectplus ? 5 : 2);
- reg.Value &= ~COR_SOFT_RESET;
+ val &= ~COR_SOFT_RESET;
if (hw_priv->sandisk_connectplus)
- reg.Value |= COR_IREQ_ENA;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ val |= COR_IREQ_ENA;
+ res = pcmcia_write_config_byte(hw_priv->link, CISREG_COR, val);
if (res != 0) {
printk(KERN_DEBUG "prism2_pccard_cor_sreset failed 3 (%d)\n",
res);
@@ -395,8 +370,7 @@ static void prism2_pccard_cor_sreset(local_info_t *local)
static void prism2_pccard_genesis_reset(local_info_t *local, int hcr)
{
int res;
- conf_reg_t reg;
- int old_cor;
+ u8 old_cor;
struct hostap_cs_priv *hw_priv = local->hw_priv;
if (!prism2_pccard_card_present(local))
@@ -407,25 +381,17 @@ static void prism2_pccard_genesis_reset(local_info_t *local, int hcr)
return;
}
- reg.Function = 0;
- reg.Action = CS_READ;
- reg.Offset = CISREG_COR;
- reg.Value = 0;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ res = pcmcia_read_config_byte(hw_priv->link, CISREG_COR, &old_cor);
if (res != 0) {
printk(KERN_DEBUG "prism2_pccard_genesis_sreset failed 1 "
"(%d)\n", res);
return;
}
printk(KERN_DEBUG "prism2_pccard_genesis_sreset: original COR %02x\n",
- reg.Value);
- old_cor = reg.Value;
+ old_cor);
- reg.Action = CS_WRITE;
- reg.Value |= COR_SOFT_RESET;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ res = pcmcia_write_config_byte(hw_priv->link, CISREG_COR,
+ old_cor | COR_SOFT_RESET);
if (res != 0) {
printk(KERN_DEBUG "prism2_pccard_genesis_sreset failed 2 "
"(%d)\n", res);
@@ -435,11 +401,7 @@ static void prism2_pccard_genesis_reset(local_info_t *local, int hcr)
mdelay(10);
/* Setup Genesis mode */
- reg.Action = CS_WRITE;
- reg.Value = hcr;
- reg.Offset = CISREG_CCSR;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ res = pcmcia_write_config_byte(hw_priv->link, CISREG_CCSR, hcr);
if (res != 0) {
printk(KERN_DEBUG "prism2_pccard_genesis_sreset failed 3 "
"(%d)\n", res);
@@ -447,11 +409,8 @@ static void prism2_pccard_genesis_reset(local_info_t *local, int hcr)
}
mdelay(10);
- reg.Action = CS_WRITE;
- reg.Offset = CISREG_COR;
- reg.Value = old_cor & ~COR_SOFT_RESET;
- res = pcmcia_access_configuration_register(hw_priv->link,
- ®);
+ res = pcmcia_write_config_byte(hw_priv->link, CISREG_COR,
+ old_cor & ~COR_SOFT_RESET);
if (res != 0) {
printk(KERN_DEBUG "prism2_pccard_genesis_sreset failed 4 "
"(%d)\n", res);
diff --git a/drivers/net/wireless/orinoco/spectrum_cs.c b/drivers/net/wireless/orinoco/spectrum_cs.c
index cad30e4..39399cd 100644
--- a/drivers/net/wireless/orinoco/spectrum_cs.c
+++ b/drivers/net/wireless/orinoco/spectrum_cs.c
@@ -79,35 +79,27 @@ static int
spectrum_reset(struct pcmcia_device *link, int idle)
{
int ret;
- conf_reg_t reg;
- u_int save_cor;
+ u8 save_cor;
+ u8 ccsr;
/* Doing it if hardware is gone is guaranteed crash */
if (!pcmcia_dev_present(link))
return -ENODEV;
/* Save original COR value */
- reg.Function = 0;
- reg.Action = CS_READ;
- reg.Offset = CISREG_COR;
- ret = pcmcia_access_configuration_register(link, ®);
+ ret = pcmcia_read_config_byte(link, CISREG_COR, &save_cor);
if (ret)
goto failed;
- save_cor = reg.Value;
/* Soft-Reset card */
- reg.Action = CS_WRITE;
- reg.Offset = CISREG_COR;
- reg.Value = (save_cor | COR_SOFT_RESET);
- ret = pcmcia_access_configuration_register(link, ®);
+ ret = pcmcia_write_config_byte(link, CISREG_COR,
+ (save_cor | COR_SOFT_RESET));
if (ret)
goto failed;
udelay(1000);
/* Read CCSR */
- reg.Action = CS_READ;
- reg.Offset = CISREG_CCSR;
- ret = pcmcia_access_configuration_register(link, ®);
+ ret = pcmcia_read_config_byte(link, CISREG_CCSR, &ccsr);
if (ret)
goto failed;
@@ -115,19 +107,15 @@ spectrum_reset(struct pcmcia_device *link, int idle)
* Start or stop the firmware. Memory width bit should be
* preserved from the value we've just read.
*/
- reg.Action = CS_WRITE;
- reg.Offset = CISREG_CCSR;
- reg.Value = (idle ? HCR_IDLE : HCR_RUN) | (reg.Value & HCR_MEM16);
- ret = pcmcia_access_configuration_register(link, ®);
+ ccsr = (idle ? HCR_IDLE : HCR_RUN) | (ccsr & HCR_MEM16);
+ ret = pcmcia_write_config_byte(link, CISREG_CCSR, ccsr);
if (ret)
goto failed;
udelay(1000);
/* Restore original COR configuration index */
- reg.Action = CS_WRITE;
- reg.Offset = CISREG_COR;
- reg.Value = (save_cor & ~COR_SOFT_RESET);
- ret = pcmcia_access_configuration_register(link, ®);
+ ret = pcmcia_write_config_byte(link, CISREG_COR,
+ (save_cor & ~COR_SOFT_RESET));
if (ret)
goto failed;
udelay(1000);
diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c
index ba4a5ac..1733fab 100644
--- a/drivers/pcmcia/cistpl.c
+++ b/drivers/pcmcia/cistpl.c
@@ -209,7 +209,7 @@ int pcmcia_read_cis_mem(struct pcmcia_socket *s, int attr, u_int addr,
* Probably only useful for writing one-byte registers. Must be called
* with ops_mutex held.
*/
-void pcmcia_write_cis_mem(struct pcmcia_socket *s, int attr, u_int addr,
+int pcmcia_write_cis_mem(struct pcmcia_socket *s, int attr, u_int addr,
u_int len, void *ptr)
{
void __iomem *sys, *end;
@@ -231,7 +231,7 @@ void pcmcia_write_cis_mem(struct pcmcia_socket *s, int attr, u_int addr,
((cis_width) ? MAP_16BIT : 0));
if (!sys) {
dev_dbg(&s->dev, "could not map memory\n");
- return; /* FIXME: Error */
+ return -EINVAL;
}
writeb(flags, sys+CISREG_ICTRL0);
@@ -256,7 +256,7 @@ void pcmcia_write_cis_mem(struct pcmcia_socket *s, int attr, u_int addr,
sys = set_cis_map(s, card_offset, flags);
if (!sys) {
dev_dbg(&s->dev, "could not map memory\n");
- return; /* FIXME: error */
+ return -EINVAL;
}
end = sys + s->map_size;
@@ -270,6 +270,7 @@ void pcmcia_write_cis_mem(struct pcmcia_socket *s, int attr, u_int addr,
addr = 0;
}
}
+ return 0;
}
diff --git a/drivers/pcmcia/cs_internal.h b/drivers/pcmcia/cs_internal.h
index 45e7fd1..cebd40d 100644
--- a/drivers/pcmcia/cs_internal.h
+++ b/drivers/pcmcia/cs_internal.h
@@ -158,8 +158,8 @@ extern struct bin_attribute pccard_cis_attr;
int pcmcia_read_cis_mem(struct pcmcia_socket *s, int attr,
u_int addr, u_int len, void *ptr);
-void pcmcia_write_cis_mem(struct pcmcia_socket *s, int attr,
- u_int addr, u_int len, void *ptr);
+int pcmcia_write_cis_mem(struct pcmcia_socket *s, int attr,
+ u_int addr, u_int len, void *ptr);
void release_cis_mem(struct pcmcia_socket *s);
void destroy_cis_cache(struct pcmcia_socket *s);
int pccard_read_tuple(struct pcmcia_socket *s, unsigned int function,
diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c
index 2394de4..563750e 100644
--- a/drivers/pcmcia/pcmcia_resource.c
+++ b/drivers/pcmcia/pcmcia_resource.c
@@ -108,25 +108,25 @@ static void release_io_space(struct pcmcia_socket *s, unsigned int base,
} /* release_io_space */
-/** pccard_access_configuration_register
+/**
+ * pcmcia_access_config() - read or write card configuration registers
*
- * Access_configuration_register() reads and writes configuration
- * registers in attribute memory. Memory window 0 is reserved for
- * this and the tuple reading services.
+ * pcmcia_access_config() reads and writes configuration registers in
+ * attribute memory. Memory window 0 is reserved for this and the tuple
+ * reading services. Drivers must use pcmcia_read_config_byte() or
+ * pcmcia_write_config_byte().
*/
-
-int pcmcia_access_configuration_register(struct pcmcia_device *p_dev,
- conf_reg_t *reg)
+static int pcmcia_access_config(struct pcmcia_device *p_dev,
+ off_t where, u8 *val,
+ int (*accessf) (struct pcmcia_socket *s,
+ int attr, unsigned int addr,
+ unsigned int len, void *ptr))
{
struct pcmcia_socket *s;
config_t *c;
int addr;
- u_char val;
int ret = 0;
- if (!p_dev || !p_dev->function_config)
- return -EINVAL;
-
s = p_dev->socket;
mutex_lock(&s->ops_mutex);
@@ -138,26 +138,40 @@ int pcmcia_access_configuration_register(struct pcmcia_device *p_dev,
return -EACCES;
}
- addr = (c->ConfigBase + reg->Offset) >> 1;
+ addr = (c->ConfigBase + where) >> 1;
+
+ ret = accessf(s, 1, addr, 1, val);
- switch (reg->Action) {
- case CS_READ:
- ret = pcmcia_read_cis_mem(s, 1, addr, 1, &val);
- reg->Value = val;
- break;
- case CS_WRITE:
- val = reg->Value;
- pcmcia_write_cis_mem(s, 1, addr, 1, &val);
- break;
- default:
- dev_dbg(&s->dev, "Invalid conf register request\n");
- ret = -EINVAL;
- break;
- }
mutex_unlock(&s->ops_mutex);
+
return ret;
-} /* pcmcia_access_configuration_register */
-EXPORT_SYMBOL(pcmcia_access_configuration_register);
+} /* pcmcia_access_config */
+
+
+/**
+ * pcmcia_read_config_byte() - read a byte from a card configuration register
+ *
+ * pcmcia_read_config_byte() reads a byte from a configuration register in
+ * attribute memory.
+ */
+int pcmcia_read_config_byte(struct pcmcia_device *p_dev, off_t where, u8 *val)
+{
+ return pcmcia_access_config(p_dev, where, val, pcmcia_read_cis_mem);
+}
+EXPORT_SYMBOL(pcmcia_read_config_byte);
+
+
+/**
+ * pcmcia_write_config_byte() - write a byte to a card configuration register
+ *
+ * pcmcia_write_config_byte() writes a byte to a configuration register in
+ * attribute memory.
+ */
+int pcmcia_write_config_byte(struct pcmcia_device *p_dev, off_t where, u8 val)
+{
+ return pcmcia_access_config(p_dev, where, &val, pcmcia_write_cis_mem);
+}
+EXPORT_SYMBOL(pcmcia_write_config_byte);
int pcmcia_map_mem_page(struct pcmcia_device *p_dev, window_handle_t wh,
diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c
index 2b99c7b..2be8b10 100644
--- a/drivers/serial/serial_cs.c
+++ b/drivers/serial/serial_cs.c
@@ -114,16 +114,14 @@ static void quirk_setup_brainboxes_0104(struct pcmcia_device *link, struct uart_
static int quirk_post_ibm(struct pcmcia_device *link)
{
- conf_reg_t reg = { 0, CS_READ, 0x800, 0 };
+ u8 val;
int ret;
- ret = pcmcia_access_configuration_register(link, ®);
+ ret = pcmcia_read_config_byte(link, 0x800, &val);
if (ret)
goto failed;
- reg.Action = CS_WRITE;
- reg.Value = reg.Value | 1;
- ret = pcmcia_access_configuration_register(link, ®);
+ ret = pcmcia_write_config_byte(link, 0x800, val | 1);
if (ret)
goto failed;
return 0;
diff --git a/drivers/ssb/pcmcia.c b/drivers/ssb/pcmcia.c
index 2152030..526682d 100644
--- a/drivers/ssb/pcmcia.c
+++ b/drivers/ssb/pcmcia.c
@@ -71,14 +71,9 @@
/* Write to a PCMCIA configuration register. */
static int ssb_pcmcia_cfg_write(struct ssb_bus *bus, u8 offset, u8 value)
{
- conf_reg_t reg;
int res;
- memset(®, 0, sizeof(reg));
- reg.Offset = offset;
- reg.Action = CS_WRITE;
- reg.Value = value;
- res = pcmcia_access_configuration_register(bus->host_pcmcia, ®);
+ res = pcmcia_write_config_byte(bus->host_pcmcia, offset, value);
if (unlikely(res != 0))
return -EBUSY;
@@ -88,16 +83,11 @@ static int ssb_pcmcia_cfg_write(struct ssb_bus *bus, u8 offset, u8 value)
/* Read from a PCMCIA configuration register. */
static int ssb_pcmcia_cfg_read(struct ssb_bus *bus, u8 offset, u8 *value)
{
- conf_reg_t reg;
int res;
- memset(®, 0, sizeof(reg));
- reg.Offset = offset;
- reg.Action = CS_READ;
- res = pcmcia_access_configuration_register(bus->host_pcmcia, ®);
+ res = pcmcia_read_config_byte(bus->host_pcmcia, offset, value);
if (unlikely(res != 0))
return -EBUSY;
- *value = reg.Value;
return 0;
}
diff --git a/include/pcmcia/cs.h b/include/pcmcia/cs.h
index c78d9b1..64e853d 100644
--- a/include/pcmcia/cs.h
+++ b/include/pcmcia/cs.h
@@ -19,18 +19,6 @@
#include <linux/interrupt.h>
#endif
-/* For AccessConfigurationRegister */
-typedef struct conf_reg_t {
- u_char Function;
- u_int Action;
- off_t Offset;
- u_int Value;
-} conf_reg_t;
-
-/* Actions */
-#define CS_READ 1
-#define CS_WRITE 2
-
/* for AdjustResourceInfo */
/* Action field */
#define REMOVE_MANAGED_RESOURCE 1
diff --git a/include/pcmcia/ds.h b/include/pcmcia/ds.h
index e614aa0..d494ce4 100644
--- a/include/pcmcia/ds.h
+++ b/include/pcmcia/ds.h
@@ -174,8 +174,8 @@ struct pcmcia_device *pcmcia_dev_present(struct pcmcia_device *p_dev);
int pcmcia_reset_card(struct pcmcia_socket *skt);
/* CIS config */
-int pcmcia_access_configuration_register(struct pcmcia_device *p_dev,
- conf_reg_t *reg);
+int pcmcia_read_config_byte(struct pcmcia_device *p_dev, off_t where, u8 *val);
+int pcmcia_write_config_byte(struct pcmcia_device *p_dev, off_t where, u8 val);
/* device configuration */
int pcmcia_request_io(struct pcmcia_device *p_dev, io_req_t *req);
--
1.7.0.4
^ permalink raw reply related
* Re: shape traffic on tun interfaces
From: Alexander Clouter @ 2010-08-01 10:27 UTC (permalink / raw)
To: netdev; +Cc: lartc
In-Reply-To: <301941280614170@web105.yandex.ru>
Franchoze Eric <franchoze@yandex.ru> wrote:
>
> Do we have any interface to shape traffic per destination IP? The
> standrad HTB shapes it per device, which is not suitable for case if
> limitation required per destination IP. For example openvpn server
> which servers about 3000 clients and has 10 internal tun interfases
> (tun0-tun9).
>
Do the QoS on your next hop router or on the interface all your
de-encapsulated VPN traffic flows over (ie. 'eth0') instead.
Cheers
--
Alexander Clouter
.sigmonster says: He who always plows a straight furrow is in a rut.
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: Oliver Hartkopp @ 2010-08-01 10:50 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
patrick.ohly-ral2JQCrhuEAvxtiuMwx3w,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20100801.010337.68133932.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 01.08.2010 10:03, David Miller wrote:
> From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
> Date: Fri, 30 Jul 2010 11:44:27 +0200
>
>> Hello Eric, hello Patrick,
>>
>> Commit fc6055a5ba31e2c14e36e8939f9bf2b6d586a7f5 (net: Introduce
>> skb_orphan_try()) allows an early orphan of the skb and takes care on
>> tx timestamping, which needs the sk-reference in the skb on driver level.
>> So does the can-raw socket, which has not been taken into account here.
>>
>> The patch below adds a 'prevent_sk_orphan' bit in the skb tx shared info,
>> which fixes the problem discovered by Matthias Fuchs here:
>>
>> http://marc.info/?t=128030411900003&r=1&w=2
>
> Your patch sets this new value, but I never see it getting tested anywhere.
>
> How does this work?
The flags are tested all together in skb_orphan_try() ...
See at
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=fc6055a5ba31e2c14e36e8939f9bf2b6d586a7f5
+/*
+ * Try to orphan skb early, right before transmission by the device.
+ * We cannot orphan skb if tx timestamp is requested, since
+ * drivers need to call skb_tstamp_tx() to send the timestamp.
+ */
+static inline void skb_orphan_try(struct sk_buff *skb)
+{
+ if (!skb_tx(skb)->flags)
+ skb_orphan(skb);
+}
So my patch just added a new bit that's tested here but does not touch the
rest of the tx timestamp bits that are checked at this place.
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH repost] sched: export sched_set/getaffinity to modules
From: Michael S. Tsirkin @ 2010-08-01 8:50 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Sridhar Samudrala, Peter Zijlstra, Tejun Heo, Ingo Molnar, netdev,
lkml, kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev,
Jiri Kosina, Thomas Gleixner, Andi Kleen
In-Reply-To: <20100730141901.GA9076@redhat.com>
On Fri, Jul 30, 2010 at 04:19:01PM +0200, Oleg Nesterov wrote:
> Sorry for the delay, I can't be responsive these days...
>
> On 07/27, Michael S. Tsirkin wrote:
> >
> > On Mon, Jul 26, 2010 at 08:08:34PM +0200, Oleg Nesterov wrote:
> > > On 07/26, Sridhar Samudrala wrote:
> > > >
> > > > I have been testing out a similar patch that uses kernel_thread() without CLONE_FILES
> > > > flag rather than create_kthread() and then closing the files.
> > >
> > > !CLONE_FILES can't help. copy_files() does dup_fd() in this case.
> > > The child still inherits the files.
> > >
> > > > Either version should be fine.
> > >
> > > I think neither version is fine ;)
> > >
> > > exit_files() is not enough too. How about the signals, reparenting?
> > >
> > >
> > > I already forgot all details, probably I missed somethig. But it
> > > seems to me that it is better to just export get/set affinity and
> > > forget about all complications.
> > >
> > > Oleg.
> >
> > Oleg, so can I attach your Ack to the patch in question, and merge
> > it all through net-next?
>
> Well, I do not think you need my ack ;)
>
>
> But I must admit, I personally dislike this idea. A kernel thread which
> is the child of the user-space process, and in fact it is not the "real"
> kernel thread. I think this is against the common case. If you do not
> care the signals/reparenting, why can't you fork the user-space process
> which does all the work via ioctl's ? OK, I do not understand the problem
> domain, probably this can't work.
>
> Anyway, the patch looks buggy to me. Starting from
>
> create_kthread(&create);
> wait_for_completion(&create.done);
>
> At least you should check create_kthread() suceeds, otherwise
> wait_for_completion() will hang forever. OTOH, if it suceeds then
> wait_for_completion() is not needed. But this is minor.
>
> create_kthread()->kernel_thread() uses CLONE_VM, this means that the
> child will share ->mm. And this means that if the parent recieves
> the coredumping signal it will hang forever in kernel space waiting
> until this child exits.
>
> This is just the immediate surprise I can see with this approach,
> I am afraid there is something else.
>
> And once again. We are doing this hacks only because we lack a
> couples of exports (iiuk). This is, well, a bit strange ;)
>
> Oleg.
Oleg, I mean Ack the exporting of get/set affinity.
Thanks!
--
MST
^ permalink raw reply
* Re: [PATCH] vhost: locking/rcu cleanup
From: Michael S. Tsirkin @ 2010-08-01 8:41 UTC (permalink / raw)
To: Tejun Heo
Cc: David S. Miller, Sridhar Samudrala, Jeff Dike, Juan Quintela,
Rusty Russell, Takuya Yoshikawa, David Stevens, Paul E. McKenney,
kvm, virtualization, netdev, linux-kernel
In-Reply-To: <4C52E692.3070405@kernel.org>
On Fri, Jul 30, 2010 at 04:49:54PM +0200, Tejun Heo wrote:
> Hello,
>
> On 07/29/2010 02:23 PM, Michael S. Tsirkin wrote:
> > I saw WARN_ON(!list_empty(&dev->work_list)) trigger
> > so our custom flush is not as airtight as need be.
>
> Could be but it's also possible that something has queued something
> after the last flush?
> Is the problem reproducible?
Well, We do requeue from the job itself. So need to be careful with what
we do with indexes here. Bug seemed to happen all the time when qemu was
killed under stress but now I can't reproduce anymore :(
Will try again later.
> > This patch switches to a simple atomic counter + srcu instead of
> > the custom locked queue + flush implementation.
> >
> > This will slow down the setup ioctls, which should not matter -
> > it's slow path anyway. We use the expedited flush to at least
> > make sure it has a sane time bound.
> >
> > Works fine for me. I got reports that with many guests,
> > work lock is highly contended, and this patch should in theory
> > fix this as well - but I haven't tested this yet.
>
> Hmmm... vhost_poll_flush() becomes synchronize_srcu_expedited(). Can
> you please explain how it works? synchronize_srcu_expedited() is an
> extremely heavy operation involving scheduling the cpu_stop task on
> all cpus. I'm not quite sure whether doing it from every flush is a
> good idea. Is flush supposed to be a very rare operation?
It is rare - happens on guest reboot typically. I guess I will
switch to regular synchronize_srcu.
> Having custom implementation is fine too but let's try to implement
> something generic if at all possible.
>
> Thanks.
Sure. It does seem that avoiding list lock would be pretty hard
in generic code though.
> --
> tejun
^ permalink raw reply
* Re: [RFC PATCH v8 00/16] Provide a zero-copy method on KVM virtio-net.
From: Michael S. Tsirkin @ 2010-08-01 8:31 UTC (permalink / raw)
To: Shirley Ma
Cc: xiaohui.xin, netdev, kvm, linux-kernel, mingo, davem, herbert,
jdike
In-Reply-To: <1280442682.9058.15.camel@localhost.localdomain>
On Thu, Jul 29, 2010 at 03:31:22PM -0700, Shirley Ma wrote:
> I did some vhost performance measurement over 10Gb ixgbe, and found that
> in order to get consistent BW results, netperf/netserver, qemu, vhost
> threads smp affinities are required.
Could you provide an example of a good setup?
Specifically, is it a good idea for the vhost thread
to inherit CPU affinities from qemu?
> Looking forward to these results for small message size comparison.
I think we should explore the idea for the driver to fall back on data copy
for small message sizes.
The benefit of zero copy would then be CPU utilization on large messages.
> For
> large message size 10Gb ixgbe BW already reached by doing vhost smp
> affinity w/i offloading support, we will see how much CPU utilization it
> can be reduced.
>
> Please provide latency results as well. I did some experimental on
> macvtap zero copy sendmsg, what I have found that get_user_pages latency
> pretty high.
>
> Thanks
> Shirley
>
>
>
^ permalink raw reply
* Re: [RFC PATCH v8 00/16] Provide a zero-copy method on KVM virtio-net.
From: Avi Kivity @ 2010-08-01 8:18 UTC (permalink / raw)
To: Shirley Ma
Cc: xiaohui.xin, netdev, kvm, linux-kernel, mst, mingo, davem,
herbert, jdike
In-Reply-To: <1280504771.9058.25.camel@localhost.localdomain>
On 07/30/2010 06:46 PM, Shirley Ma wrote:
> Hello Avi,
>
> On Fri, 2010-07-30 at 08:02 +0300, Avi Kivity wrote:
>> get_user_pages() is indeed slow. But what about
>> get_user_pages_fast()?
>>
>> Note that when the page is first touched, get_user_pages_fast() falls
>> back to get_user_pages(), so the latency needs to be measured after
>> quite a bit of warm-up.
> Yes, I used get_user_pages_fast, however if falled back to
> get_user_pages() when the apps doesn't allocate buffer on the same page.
> If I run a single ping, the RTT is extremely high, but when running
> multiple pings, the RTT time reduce significantly, but still it is not
> as fast as copy from my initial test. I am thinking that we might need
> to pre-pin memory pool.
>
I don't understand. Under what conditions do you use get_user_pages()
instead of get_user_pages_fast()? Why?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [RFC PATCH 2/2] igb/ixgbe: add code to trigger function reset if reset_devices is set
From: David Miller @ 2010-08-01 8:15 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: jbarnes, netdev, linux-pci, alexander.h.duyck
In-Reply-To: <20100731005910.32625.89518.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 30 Jul 2010 17:59:12 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change makes it so that both igb and ixgbe can trigger a full pcie
> function reset if the reset_devices kernel parameter is defined. The main
> reason for adding this is that kdump can cause serious issues when the
> kdump kernel resets the IOMMU while DMA transactions are still occurring.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
I tend to disagree with the essence of this change.
Which is that we should add workaround after workaround for things
that aren't functioning properly in kdump and kexec.
They should have a pass that shuts devices down properly, so that this
kind of stuff doesn't need to happen in the kernel we then boot into.
What happens on non-PCIE systems then? Do they just lose when this
happens?
No, you dun goof'd. :-) Find another way to fix this please.
Thanks.
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: David Miller @ 2010-08-01 8:03 UTC (permalink / raw)
To: socketcan
Cc: eric.dumazet, patrick.ohly, netdev, socketcan-core,
matthias.fuchs
In-Reply-To: <4C529EFB.4090601@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Fri, 30 Jul 2010 11:44:27 +0200
> Hello Eric, hello Patrick,
>
> Commit fc6055a5ba31e2c14e36e8939f9bf2b6d586a7f5 (net: Introduce
> skb_orphan_try()) allows an early orphan of the skb and takes care on
> tx timestamping, which needs the sk-reference in the skb on driver level.
> So does the can-raw socket, which has not been taken into account here.
>
> The patch below adds a 'prevent_sk_orphan' bit in the skb tx shared info,
> which fixes the problem discovered by Matthias Fuchs here:
>
> http://marc.info/?t=128030411900003&r=1&w=2
Your patch sets this new value, but I never see it getting tested anywhere.
How does this work?
^ permalink raw reply
* Re: [PATCH] Multiqueue macvtap driver
From: David Miller @ 2010-08-01 7:34 UTC (permalink / raw)
To: bhutchings; +Cc: krkumar2, arnd, netdev, mst
In-Reply-To: <1280603907.13192.353.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Sat, 31 Jul 2010 20:18:27 +0100
> On Sat, 2010-07-31 at 19:27 +0530, Krishna Kumar wrote:
> [...]
>> @@ -136,39 +158,68 @@ static void macvtap_put_queue(struct mac
>> }
>>
>> /*
>> - * Since we only support one queue, just dereference the pointer.
>> + * Select a queue based on the rxq of the device on which this packet
>> + * arrived. If the incoming device is not mq, then use our cpu number
>> + * to select a queue. vlan->numvtaps is cached in case it changes
>> + * during the execution of this function.
>> */
> [...]
>
> This can result in reordering if a single-queue device's RX interrupt's
> CPU affinity is changed. We generally try to avoid that. You should
> really use or generate a flow hash. There is code for this in
> net/core/dev.c:get_rps_cpu() which could be factored out into a separate
> function.
Agreed.
^ permalink raw reply
* Re: [PATCH] net: ingress filter message limit
From: David Miller @ 2010-08-01 7:33 UTC (permalink / raw)
To: shemminger; +Cc: hadi, netdev
In-Reply-To: <20100731121316.1adb52c0@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sat, 31 Jul 2010 12:13:16 -0700
> If user misconfigures ingress and causes a redirection loop, don't
> overwhelm the log. This is also a error case so make it unlikely.
> Found by inspection, luckily not in real system.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH] net/rose: Use GFP_ATOMIC
From: David Miller @ 2010-08-01 7:32 UTC (permalink / raw)
To: julia; +Cc: ralf, linux-hams, linux-kernel, netdev, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.1007311156180.6434@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Sat, 31 Jul 2010 11:56:39 +0200 (CEST)
> The other calls to kmalloc in the same function use GFP_ATOMIC, and indeed
> two locks are held within the body of the function.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied, thank you!
^ permalink raw reply
* [PATCH] ip_fragment: fix subtracting PPPOE_SES_HLEN from mtu twice
From: Changli Gao @ 2010-07-31 23:25 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, Bart De Schuymer, netdev, Changli Gao
6c79bf0f2440fd250c8fce8d9b82fcf03d4e8350 subtracts PPPOE_SES_HLEN from mtu at
the front of ip_fragment(). So the later subtraction should be removed. The
MTU of 802.1q is also 1500, so MTU should not be changed.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/ipv4/ip_output.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 6652bd9..04b6989 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -446,7 +446,7 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
int ptr;
struct net_device *dev;
struct sk_buff *skb2;
- unsigned int mtu, hlen, left, len, ll_rs, pad;
+ unsigned int mtu, hlen, left, len, ll_rs;
int offset;
__be16 not_last_frag;
struct rtable *rt = skb_rtable(skb);
@@ -585,9 +585,7 @@ slow_path:
/* for bridged IP traffic encapsulated inside f.e. a vlan header,
* we need to make room for the encapsulating header
*/
- pad = nf_bridge_pad(skb);
- ll_rs = LL_RESERVED_SPACE_EXTRA(rt->dst.dev, pad);
- mtu -= pad;
+ ll_rs = LL_RESERVED_SPACE_EXTRA(rt->dst.dev, nf_bridge_pad(skb));
/*
* Fragment the datagram.
^ permalink raw reply related
* Re: [PATCH] act_nat: the checksum of ICMP doesn't have pseudo header
From: David Miller @ 2010-08-01 5:05 UTC (permalink / raw)
To: herbert; +Cc: xiaosuo, hadi, netdev, linux-kernel, kaber
In-Reply-To: <20100730143016.GA10543@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 30 Jul 2010 22:30:16 +0800
> On Fri, Jul 30, 2010 at 10:16:05PM +0800, Changli Gao wrote:
>>
>> I know we need to update the ICMP checksum if we alter the payload(the
>> inner IP header here) of ICMP. But I doubt if the update is really
>> necessary if the checksum is partial, as the checksum will be done
>> later(by ether skb_checksum_help() or NIC hardware). In fact, as there
>> isn't any pseudo header, the icmph->checksum should be always ZERO,
>> otherwise skb_checksum_help() or NIC will give the wrong checksums,
>> when the checksum is partial.
>
> Actually you are right. I suppose the only reason this has never
> shown up is because CHEKSUM_PARTIAL doesn't usually occur with
> forwarded packets.
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH] act_nat: fix wild pointer
From: David Miller @ 2010-08-01 5:05 UTC (permalink / raw)
To: herbert; +Cc: xiaosuo, hadi, netdev
In-Reply-To: <20100730071838.GA7256@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 30 Jul 2010 15:18:38 +0800
> On Fri, Jul 30, 2010 at 07:41:46AM +0800, Changli Gao wrote:
>> pskb_may_pull() may change skb pointers, so adjust icmph after pskb_may_pull().
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: ss -p is much too slow
From: Stephen Hemminger @ 2010-08-01 2:33 UTC (permalink / raw)
To: David Miller; +Cc: sphink, netdev, stephen.hemminger
In-Reply-To: <20100628.162139.59679342.davem@davemloft.net>
On Mon, 28 Jun 2010 16:21:39 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Steve Fink <sphink@gmail.com>
> Date: Wed, 9 Jun 2010 11:42:38 -0700
>
> > On closer inspection, it appears that ss -p does a quadratic scan. It
> > rescans every entry in /proc/*/fd/* repeatedly (once per listening
> > port? per process? I don't remember what I figured out.)
> >
> > I humbly suggest that this is not a good idea.
>
> Yep, this is junk. Please give this patch a try:
>
> ss: Avoid quadradic complexity with '-p'
>
> Scan the process list of open sockets once, and store in a hash
> table to be used by subsequent find_user() calls.
>
> Reported-by: Steve Fink <sphink@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Applied
--
^ permalink raw reply
* Re: [PATCH] netem: fix installs of dist files
From: Stephen Hemminger @ 2010-08-01 2:33 UTC (permalink / raw)
To: Mike Frysinger; +Cc: stephen.hemminger, netdev
In-Reply-To: <1276131129-18079-1-git-send-email-vapier@gentoo.org>
On Wed, 9 Jun 2010 20:52:09 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> The tc program searches LIBDIR by default for the .dist files, and that
> defaults to /usr/lib. But the netem subdir has /lib/ hardcoded which
> means the default build+install results in the files not being found.
>
> Further, these are plain text files which are read at runtime, so it
> doesn't make sense to give them executable bits.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> ---
> netem/Makefile | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/netem/Makefile b/netem/Makefile
> index b6ccfc6..e52e125 100644
> --- a/netem/Makefile
> +++ b/netem/Makefile
> @@ -20,9 +20,9 @@ stats: stats.c
> $(HOSTCC) $(CCOPTS) -I../include -o $@ $@.c -lm
>
> install: all
> - mkdir -p $(DESTDIR)/lib/tc
> + mkdir -p $(DESTDIR)$(LIBDIR)/tc
> for i in $(DISTDATA); \
> - do install -m 755 $$i $(DESTDIR)/lib/tc; \
> + do install -m 644 $$i $(DESTDIR)$(LIBDIR)/tc; \
> done
>
> clean:
Applied
^ permalink raw reply
* Re: [REGRESSION] e1000e stopped working [MANUALLY BISECTED]
From: Jeff Kirsher @ 2010-08-01 2:08 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Tantilov, Emil S, netdev@vger.kernel.org, Allan, Bruce W,
Pieper, Jeffrey E
In-Reply-To: <AANLkTinSOUcAxnqCo9YVVonhZ4sdC8iUK4r6F1+ayKef@mail.gmail.com>
On Wed, Jul 28, 2010 at 18:10, Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> On Wed, Jul 28, 2010 at 00:04, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> On Mon, 2010-07-26 at 03:25 +0300, Maxim Levitsky wrote:
>>>
>>> This commit, present in net-next, solves the problem:
>>>
>>> commit 1286950690f0f82ffa504e1e149ee3fdb4c51478
>>> Author: Bruce Allan <bruce.w.allan@intel.com>
>>> Date: Mon Jul 26 03:19:38 2010 +0300
>>>
>>> e1000e: cleanup e1000_sw_lcd_config_ich8lan()
>>>
>>> Do not acquire and release the PHY unnecessarily for parts that return
>>> from this workaround without actually accessing the PHY registers.
>>>
>>> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
>>> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
>>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>
>>>
>>>
>>>
>>> Also, the above patch is part of whole series of patches with scary descriptions (that is these fix bugs).
>>> If I were you I would send them to Linus for 2.6.35 inclusion too.
>>>
>>> Best regards,
>>> Maxim Levitsky
>>>
>>>
>>>
>> ping
>>
>
> Sorry for the delayed response. I am working on the issue. Here is
> the problem I am having, the patch that fixes the issue you are seeing
> is fairly large and is a cleanup to the ich8 function, which as it
> stands now, would not be accepted into net-2.6 tree this late into the
> -rc cycle. So, what I looking at is, what specifically fixed the
> issue you are seeing that resides in that patch, and come up with a
> smaller (acceptable) patch that I can submit to net-2.6 now to resolve
> your issue.
>
> I have dedicated most of this evening to finding a resolution to your
> issue that will be acceptable for the net-2.6 tree. As you noted,
> there were several patches before this particular commit that may play
> some part in the resolution as well, and that is what I will be
> looking into. I greatly appreciate the hard work you have done to
> help us resolve this issue, and will make sure you get credit for any
> solution I put together to resolve this issue.
>
> --
> Cheers,
> Jeff
>
To keep everyone informed...
We have found the root cause for this issue with the help of Maxim,
and will have a patch to fix the issue in the next couple of days.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH staging] Add SBE 2T3E3 WAN driver
From: Greg KH @ 2010-08-01 0:27 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: netdev
In-Reply-To: <m362zv5oet.fsf@intrepid.localdomain>
On Sat, Jul 31, 2010 at 11:31:22PM +0200, Krzysztof Halasa wrote:
> Greg KH <greg@kroah.com> writes:
>
> >> include/linux/pci_ids.h | 3 +
> >
> > First off, read the top of the pci_ids.h file, which says to not add new
> > entries that are only used in a single driver.
>
> These entries are also needed for the tulip Ethernet driver, to avoid
> initializing these ports (they are using Tulip DECchips with custom FPGA
> for HDLC). I posted a patch on netdev list.
Then make the patch part of that submission, I can't add non-staging
patches to the drivers/staging/ tree if at all possible.
> > Secondly, why have this as a staging driver? What is lacking in it to
> > get it merged into the main kernel tree as a "normal" driver?
>
> The main reason is the interface ("PRIVATE" netdev ioctls) for
> controlling the hdlcX devices is not stable. The plan is to write a new
> user-kernel interface for generic HDLC, this driver (and other ones)
> will then use it. For now, there is a separate utility from SBE for this
> card.
Ah, ick. Is this going to be fixed up anytime soon?
> > Hint, you
> > need a TODO file in the driver directory that lists the things left to
> > be done to it to get it merged, and a name/email address to send the
> > patches to.
>
> Ok.
Care to respin this with the TODO file?`
> >> + * This code is based on a driver written by SBE Inc.
> >
> > What driver would that have been? If it's based on someone else's work,
> > it's nice to mention the copyright holders of that work you based yours
> > on.
>
> I don't have any details, I'm only told the driver is open-source and
> the file name starts with SBE. No copyright notices except this one:
>
> $ grep LIC *
> linux_sbe2t3e3.c:MODULE_LICENSE("GPL");
Wait, you wrote this driver, yet you don't have any details about the
driver you based it on? That makes absolutely no sense. Please
clarify.
And look, you do have a copy of the file, right there. Care to post it
somewhere? We need to see the license and other markings on it to know
about this driver, right? Where did you get it from?
> BTW SBE Inc. (division?) has been acquired by One Stop Systems, they
> seem to still sell this hw, but I can't see any drivers available for
> downloading (though they mention "open source Linux drivers").
Any links would be appreciated.
> >> +#define DRV_NAME "SBE 2T3E3"
> >
> > spaces and all caps isn't the nicest thing for linux drivers, it does
> > odd things in sysfs for some scripts (the space thing, not the
> > uppercase.)
>
> It seems the DRV_NAME is only used for various printk() and for
> pci_request_regions(). Does it still cause problems?
It's not nice, hopefully you can fix it up. Well, remove it entirely
would be good, but you can add that to the TODO file :)
thanks,
greg k-h
^ permalink raw reply
* shape traffic on tun interfaces
From: Franchoze Eric @ 2010-07-31 22:09 UTC (permalink / raw)
To: lartc; +Cc: netdev
Do we have any interface to shape traffic per destination IP? The standrad HTB shapes it per device, which is not suitable for case if limitation required per destination IP. For example openvpn server which servers about 3000 clients and has 10 internal tun interfases (tun0-tun9). Of course it is possible to do it on application level (vpn), but I would prefer any system solution for this. iptables with --limit does not work in this case because it will simple drop packets. Did somebody work on such task?
Eric.
^ permalink raw reply
* Re: [PATCH staging] Add SBE 2T3E3 WAN driver
From: Krzysztof Halasa @ 2010-07-31 21:31 UTC (permalink / raw)
To: Greg KH; +Cc: netdev
In-Reply-To: <20100731195335.GB4644@kroah.com>
Greg KH <greg@kroah.com> writes:
>> include/linux/pci_ids.h | 3 +
>
> First off, read the top of the pci_ids.h file, which says to not add new
> entries that are only used in a single driver.
These entries are also needed for the tulip Ethernet driver, to avoid
initializing these ports (they are using Tulip DECchips with custom FPGA
for HDLC). I posted a patch on netdev list.
> Secondly, why have this as a staging driver? What is lacking in it to
> get it merged into the main kernel tree as a "normal" driver?
The main reason is the interface ("PRIVATE" netdev ioctls) for
controlling the hdlcX devices is not stable. The plan is to write a new
user-kernel interface for generic HDLC, this driver (and other ones)
will then use it. For now, there is a separate utility from SBE for this
card.
> Hint, you
> need a TODO file in the driver directory that lists the things left to
> be done to it to get it merged, and a name/email address to send the
> patches to.
Ok.
>> + * This code is based on a driver written by SBE Inc.
>
> What driver would that have been? If it's based on someone else's work,
> it's nice to mention the copyright holders of that work you based yours
> on.
I don't have any details, I'm only told the driver is open-source and
the file name starts with SBE. No copyright notices except this one:
$ grep LIC *
linux_sbe2t3e3.c:MODULE_LICENSE("GPL");
BTW SBE Inc. (division?) has been acquired by One Stop Systems, they
seem to still sell this hw, but I can't see any drivers available for
downloading (though they mention "open source Linux drivers").
>> +#define DRV_NAME "SBE 2T3E3"
>
> spaces and all caps isn't the nicest thing for linux drivers, it does
> odd things in sysfs for some scripts (the space thing, not the
> uppercase.)
It seems the DRV_NAME is only used for various printk() and for
pci_request_regions(). Does it still cause problems?
--
Krzysztof Halasa
^ permalink raw reply
* Re: iw reg set does not work because udev and crda do not respond to boot-time request.
From: Luis R. Rodriguez @ 2010-07-31 21:05 UTC (permalink / raw)
To: Daniel Haid; +Cc: linux-wireless, linux-kernel, netdev, Kay Sievers
In-Reply-To: <201007311448.06959.d.haid@gogi.tv>
Netlink / udev folks, please review.
On Sat, Jul 31, 2010 at 5:48 AM, Daniel Haid <d.haid@gogi.tv> wrote:
> Hello,
>
> the driver of my wireless card seems to ask for "US"
> regulatory data during boot, but since udev is not
> running at that point (I think not even the root filesystem
> is mounted) crda does not respond.
CRDA is not the only thing called by the kernel where there would be
an issue due to a delay with udev during bootup to react to a message.
The kernel calls CRDA for udev through kobject_uevent_env(). Uevent
messages are now broadcasted through
netlinknetlink_broadcast_filtered() since the old method of using a
direct call to /sbin/hotplug would lead to many processes being
spawned and in some cases OOM. You can still use this though through
CONFIG_UEVENT_HELPER_PATH which will issue call_usermodehelper()
during early boot on an initramfs for example, if you so need it.
I am not sure though if netlink broadcast messages would be reissued
by the kernel during early boot if no one replied back to the send
message but it is worth looking into. As far as I can tell you would
be the first to notice this. In fact we actually had reports of two
consecutive messages being being sent to userspace when only one was
being sent to userspace so it may indeed be in fact true that messages
are rebroadcasted somehow, I am just not sure so Cc'ing netdev and
lkml.
> The effect is that "iw reg set" does not work, because
> the kernel seems to be still waiting for the "US"
> regulatory data. Running
> COUNTRY="US" crda
> manually once fixes the problem (until the next reboot).
iw reg set will be ignored by net/wireless/reg.c as it is still
waiting for last_request to be processed. It seems in your case the
assumption that the request will be reissued in case udev is running
at early boot is incorrect and we need to further understand exactly
how these messages get queued and perhaps reissued or not.
I considered recently changing the way we handle requests to userspace
to use a completion handler but that would sit idle there for a while
blocking on the reg_mutex... so decided against it. But could take a
look again.
> What is the correct way of solving this? Should udev not
> pick up the request later when it is started?
We need a better understanding of how netlink broadcast messages get
processed during early boot. Right now cfg80211 will drop duplicate
requests or any request while we're still pending for the last one.
Once we find out more details about how netlink broadcast messages get
processed during early boot we can then rework things a bit. In the
meantime can you try using CONFIG_UEVENT_HELPER_PATH during the
initramfs?
Luis
^ permalink raw reply
* Re: [PATCH staging] Add SBE 2T3E3 WAN driver
From: Greg KH @ 2010-07-31 19:53 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: netdev
In-Reply-To: <m3ocdoasen.fsf@intrepid.localdomain>
On Sat, Jul 31, 2010 at 11:53:52AM +0200, Krzysztof Halasa wrote:
> This is a driver for SBE Inc.'s dual port T3/E3 WAN cards. Based on
> their original GPLed driver.
> It needs at least a new generic HDLC setup code (not yet written) before
> moving to drivers/net/wan.
>
> Signed-off-by: Krzysztof Ha??asa <khc@pm.waw.pl>
>
> ---
> I have generated the patch against v2.6.35-rc6. Compiles cleanly.
> Please let me know if it needs extra changes for e.g. staging tree.
> Thanks.
>
> drivers/staging/Kconfig | 2 +
> drivers/staging/Makefile | 1 +
> drivers/staging/sbe-2t3e3/2t3e3.h | 896 ++++++++++++++++++++++++++++++++++
> drivers/staging/sbe-2t3e3/Kconfig | 13 +
> drivers/staging/sbe-2t3e3/Makefile | 4 +
> drivers/staging/sbe-2t3e3/cpld.c | 366 ++++++++++++++
> drivers/staging/sbe-2t3e3/ctrl.c | 363 ++++++++++++++
> drivers/staging/sbe-2t3e3/ctrl.h | 131 +++++
> drivers/staging/sbe-2t3e3/dc.c | 507 +++++++++++++++++++
> drivers/staging/sbe-2t3e3/exar7250.c | 217 ++++++++
> drivers/staging/sbe-2t3e3/exar7300.c | 182 +++++++
> drivers/staging/sbe-2t3e3/intr.c | 651 ++++++++++++++++++++++++
> drivers/staging/sbe-2t3e3/io.c | 352 +++++++++++++
> drivers/staging/sbe-2t3e3/main.c | 171 +++++++
> drivers/staging/sbe-2t3e3/maps.c | 104 ++++
> drivers/staging/sbe-2t3e3/module.c | 210 ++++++++
> drivers/staging/sbe-2t3e3/netdev.c | 142 ++++++
> include/linux/pci_ids.h | 3 +
First off, read the top of the pci_ids.h file, which says to not add new
entries that are only used in a single driver.
Secondly, why have this as a staging driver? What is lacking in it to
get it merged into the main kernel tree as a "normal" driver? Hint, you
need a TODO file in the driver directory that lists the things left to
be done to it to get it merged, and a name/email address to send the
patches to.
> +++ b/drivers/staging/sbe-2t3e3/2t3e3.h
> @@ -0,0 +1,896 @@
> +/*
> + * SBE 2T3E3 synchronous serial card driver for Linux
> + *
> + * Copyright (C) 2009-2010 Krzysztof Halasa <khc@pm.waw.pl>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of version 2 of the GNU General Public License
> + * as published by the Free Software Foundation.
> + *
> + * This code is based on a driver written by SBE Inc.
What driver would that have been? If it's based on someone else's work,
it's nice to mention the copyright holders of that work you based yours
on.
> + */
> +
> +#ifndef T3E3_H
> +#define T3E3_H
> +
> +#include <linux/hdlc.h>
> +#include <linux/interrupt.h>
> +#include <linux/netdevice.h>
> +#include <linux/pci.h>
> +#include <linux/io.h>
> +#include "ctrl.h"
> +
> +#define DRV_NAME "SBE 2T3E3"
spaces and all caps isn't the nicest thing for linux drivers, it does
odd things in sysfs for some scripts (the space thing, not the
uppercase.)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4] can: Add driver for esd CAN-USB/2 device
From: Wolfgang Grandegger @ 2010-07-31 19:27 UTC (permalink / raw)
To: Matthias Fuchs
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201007271542.40997.matthias.fuchs-iOnpLzIbIdM@public.gmane.org>
On 07/27/2010 03:42 PM, Matthias Fuchs wrote:
> This patch adds a driver for esd's USB high speed
> CAN interface. The driver supports devices with
> multiple CAN interfaces.
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs-iOnpLzIbIdM@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks for your contribution.
Wolfgang,
^ permalink raw reply
* Re: [PATCH] Multiqueue macvtap driver
From: Ben Hutchings @ 2010-07-31 19:18 UTC (permalink / raw)
To: Krishna Kumar; +Cc: davem, arnd, netdev, mst
In-Reply-To: <20100731135743.3072.99933.sendpatchset@krkumar2.in.ibm.com>
On Sat, 2010-07-31 at 19:27 +0530, Krishna Kumar wrote:
[...]
> @@ -136,39 +158,68 @@ static void macvtap_put_queue(struct mac
> }
>
> /*
> - * Since we only support one queue, just dereference the pointer.
> + * Select a queue based on the rxq of the device on which this packet
> + * arrived. If the incoming device is not mq, then use our cpu number
> + * to select a queue. vlan->numvtaps is cached in case it changes
> + * during the execution of this function.
> */
[...]
This can result in reordering if a single-queue device's RX interrupt's
CPU affinity is changed. We generally try to avoid that. You should
really use or generate a flow hash. There is code for this in
net/core/dev.c:get_rps_cpu() which could be factored out into a separate
function.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
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