* Re: [PATCH 5/16] drivers/net/irda: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:49 UTC (permalink / raw)
To: julia; +Cc: samuel, netdev, arnd, joe, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181921450.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:22:05 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 7/16] drivers/net/r6040.c: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:50 UTC (permalink / raw)
To: julia; +Cc: florian, netdev, arnd, joe, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181922450.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:23:00 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 8/16] drivers/net/smsc9420.c: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:51 UTC (permalink / raw)
To: julia; +Cc: steve.glendinning, netdev, arnd, joe, linux-kernel,
kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181923010.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:23:17 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 9/16] drivers/net/typhoon.c: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:51 UTC (permalink / raw)
To: julia; +Cc: dave, netdev, arnd, joe, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181923180.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:23:34 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 10/16] drivers/net/via-rhine.c: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:51 UTC (permalink / raw)
To: julia; +Cc: rl, netdev, arnd, joe, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181923340.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:23:53 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 12/16] drivers/net/wan: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:52 UTC (permalink / raw)
To: julia; +Cc: romieu, netdev, arnd, joe, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181924140.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:24:30 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 11/16] drivers/net/via-velocity.c: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:51 UTC (permalink / raw)
To: julia; +Cc: romieu, netdev, arnd, joe, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181923540.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:24:13 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 14/16] drivers/net/wireless/iwlwifi: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:52 UTC (permalink / raw)
To: julia
Cc: yi.zhu, reinette.chatre, ilw, linville, linux-wireless, netdev,
arnd, joe, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181924510.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:25:25 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 13/16] drivers/net/adm8211.c: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:52 UTC (permalink / raw)
To: julia
Cc: flamingice, linville, linux-wireless, netdev, arnd, joe,
linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181924310.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:24:50 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 15/16] drivers/net/wireless/p54: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:52 UTC (permalink / raw)
To: julia-dAYI7NvHqcQ
Cc: flamingice-R9e9/4HEdknk1uMJSBkQmQ,
linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
joe-6d6DIl74uiNBDgjK7y7TUQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.64.0911181925260.20943-QfmoRoYWmW9knbxzx/v8hQ@public.gmane.org>
From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Date: Wed, 18 Nov 2009 19:25:43 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Applied.
--
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 16/16] drivers/net/wireless/rtl818x: remove exceptional & on function name
From: David Miller @ 2009-11-18 18:52 UTC (permalink / raw)
To: julia
Cc: linville, linux-wireless, netdev, arnd, joe, linux-kernel,
kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0911181925440.20943@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Wed, 18 Nov 2009 19:26:02 +0100 (CET)
> In this file, function names are otherwise used as pointers without &.
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* RE: NETLINK sockets dont honor SO_RCVLOWAT?
From: Jeff Haran @ 2009-11-18 19:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091118.104434.185425439.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, November 18, 2009 10:45 AM
> To: Jeff Haran
> Cc: netdev@vger.kernel.org
> Subject: Re: NETLINK sockets dont honor SO_RCVLOWAT?
>
> From: Jeff Haran <jharan@Brocade.COM>
> Date: Wed, 18 Nov 2009 10:41:06 -0800
>
> > The operative term is "shall". The RFCs define "shall" to be
> > required behavior. I realize the RFCs do not dictate how Linux
> > works, but even the common English language usage of the word
> > "shall" conveys this meaning.
>
> The low water mark can be seen as a hint, therefore we can
> apply the term "support" loosely here.
>
> And the errors are advisory, just like things like -EFAULT.
>
> Look, I'm not going to add a feature flag or some callback just to
> handle this.
>
> You have to know what kind of protocol you are working with, and
> therefore which socket options make any sense for it.
If the open source community doesn't want a fix for something that is obviously broken, that's fine. We fix a lot of broken kernel code here at Brocade. But at least now I know that I need not bother with submitting a patch. That will save everybody a lot of time.
Thanks,
Jeff Haran
Brocade Communications
^ permalink raw reply
* Re: [PATCH 2/3] TI Davinci EMAC : add platform specific interrupt enable/disable logic.
From: Troy Kisky @ 2009-11-18 19:08 UTC (permalink / raw)
To: Sriramakrishnan
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/
In-Reply-To: <1258537328-31527-3-git-send-email-srk-l0cyMroinI0@public.gmane.org>
Sriramakrishnan wrote:
> On certain SOCs, the EMAC controller is interfaced with a wrapper logic
> for handling interrupts. This patch implements a platform
> specific hook to cater to platforms that require custom interrupt
> handling logic
>
> Signed-off-by: Sriramakrishnan <srk-l0cyMroinI0@public.gmane.org>
> Acked-by: Chaithrika U S <chaithrika-l0cyMroinI0@public.gmane.org>
> ---
> drivers/net/davinci_emac.c | 11 +++++++++++
> include/linux/davinci_emac.h | 2 ++
> 2 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 6aec8f5..81931f8 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -487,6 +487,9 @@ struct emac_priv {
> struct mii_bus *mii_bus;
> struct phy_device *phydev;
> spinlock_t lock;
> + /*platform specific members*/
> + void (*wrapper_int_enable) (void);
> + void (*wrapper_int_disable) (void);
Would platform_int_enable be more appropriate then wrapper_int_enable ?
> };
>
> /* clock frequency for EMAC */
> @@ -1001,6 +1004,8 @@ static void emac_int_disable(struct emac_priv *priv)
> emac_ctrl_write(EMAC_DM646X_CMRXINTEN, 0x0);
> emac_ctrl_write(EMAC_DM646X_CMTXINTEN, 0x0);
> /* NOTE: Rx Threshold and Misc interrupts are not disabled */
> + if (priv->wrapper_int_disable)
> + priv->wrapper_int_disable();
>
> local_irq_restore(flags);
>
> @@ -1020,6 +1025,9 @@ static void emac_int_disable(struct emac_priv *priv)
> static void emac_int_enable(struct emac_priv *priv)
> {
> if (priv->version == EMAC_VERSION_2) {
> + if (priv->wrapper_int_enable)
> + priv->wrapper_int_enable();
> +
> emac_ctrl_write(EMAC_DM646X_CMRXINTEN, 0xff);
> emac_ctrl_write(EMAC_DM646X_CMTXINTEN, 0xff);
>
> @@ -2662,6 +2670,9 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
> priv->phy_mask = pdata->phy_mask;
> priv->rmii_en = pdata->rmii_en;
> priv->version = pdata->version;
> + priv->wrapper_int_enable = pdata->wrapper_interrupt_enable;
> + priv->wrapper_int_disable = pdata->wrapper_interrupt_disable;
> +
> emac_dev = &ndev->dev;
> /* Get EMAC platform data */
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
> index ff55487..eb24dc0 100644
> --- a/include/linux/davinci_emac.h
> +++ b/include/linux/davinci_emac.h
> @@ -25,6 +25,8 @@ struct emac_platform_data {
> u32 mdio_max_freq;
> u8 rmii_en;
> u8 version;
> + void (*wrapper_interrupt_enable) (void);
> + void (*wrapper_interrupt_disable) (void);
> };
>
> enum {
^ permalink raw reply
* Re: NETLINK sockets dont honor SO_RCVLOWAT?
From: David Miller @ 2009-11-18 19:09 UTC (permalink / raw)
To: jharan; +Cc: netdev
In-Reply-To: <D67825C5985D0647BE40A5F5B0B70D1106E9C5690C@HQ-EXCH-7.corp.brocade.com>
From: Jeff Haran <jharan@Brocade.COM>
Date: Wed, 18 Nov 2009 11:00:35 -0800
> If the open source community doesn't want a fix for something that
> is obviously broken, that's fine.
It is a bug in your opinion, and adding a check for these cases
doesn't necessarily make the kernel any better.
You can even check BSD, it behaves just like we do for several socket
options (they are just pieces of state stored in the socket, having
protocol specific checks and/or callbacks for every single socket
option would be just a lot of useless bloat).
And when all else fails BSD's behavior is what we use to determine
what is reasonable.
^ permalink raw reply
* Re: [PATCH 3/3] TI Davinci EMAC : Abstract Buffer address translation logic.
From: Troy Kisky @ 2009-11-18 19:15 UTC (permalink / raw)
To: Sriramakrishnan; +Cc: netdev, davinci-linux-open-source
In-Reply-To: <1258537328-31527-4-git-send-email-srk@ti.com>
Sriramakrishnan wrote:
> When programming the DMA engine, the next pointers must be
> programmed with physical address as seen from the DMA master
> address space. This address may be different from physical
> address of the buffer RAM area. This patch abstracts the
> buffer address translation logic.
>
> Signed-off-by: Sriramakrishnan <srk@ti.com>
> Acked-by: Chaithrika U S <chaithrika@ti.com>
> ---
> drivers/net/davinci_emac.c | 41 ++++++++++++++++++++++++-----------------
> include/linux/davinci_emac.h | 1 +
> 2 files changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 81931f8..d4e173b 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -464,6 +464,7 @@ struct emac_priv {
> void __iomem *ctrl_base;
> void __iomem *emac_ctrl_ram;
> u32 ctrl_ram_size;
> + u32 hw_ram_addr;
> struct emac_txch *txch[EMAC_DEF_MAX_TX_CH];
> struct emac_rxch *rxch[EMAC_DEF_MAX_RX_CH];
> u32 link; /* 1=link on, 0=link off */
> @@ -497,11 +498,9 @@ static struct clk *emac_clk;
> static unsigned long emac_bus_frequency;
> static unsigned long mdio_max_freq;
>
> -/* EMAC internal utility function */
> -static inline u32 emac_virt_to_phys(void __iomem *addr)
> -{
> - return (u32 __force) io_v2p(addr);
> -}
> +#define emac_virt_to_phys(addr, priv) \
> + (((u32 __force)(addr) - (u32 __force)(priv->emac_ctrl_ram)) \
> + + priv->hw_ram_addr)
Maybe instead of hw_ram_addr, you could use virtual_to_phys_translation
where virtual_to_phys_translation = your hw_ram_addr - emac_ctrl_ram
I'm fine with your way too though.
>
> /* Cache macros - Packet buffers would be from skb pool which is cached */
> #define EMAC_VIRT_NOCACHE(addr) (addr)
> @@ -1309,7 +1308,7 @@ static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
> curr_bd = txch->active_queue_head;
> if (NULL == curr_bd) {
> emac_write(EMAC_TXCP(ch),
> - emac_virt_to_phys(txch->last_hw_bdprocessed));
> + emac_virt_to_phys(txch->last_hw_bdprocessed, priv));
> txch->no_active_pkts++;
> spin_unlock_irqrestore(&priv->tx_lock, flags);
> return 0;
> @@ -1319,7 +1318,7 @@ static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
> while ((curr_bd) &&
> ((frame_status & EMAC_CPPI_OWNERSHIP_BIT) == 0) &&
> (pkts_processed < budget)) {
> - emac_write(EMAC_TXCP(ch), emac_virt_to_phys(curr_bd));
> + emac_write(EMAC_TXCP(ch), emac_virt_to_phys(curr_bd, priv));
> txch->active_queue_head = curr_bd->next;
> if (frame_status & EMAC_CPPI_EOQ_BIT) {
> if (curr_bd->next) { /* misqueued packet */
> @@ -1406,7 +1405,7 @@ static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch)
> txch->active_queue_tail = curr_bd;
> if (1 != txch->queue_active) {
> emac_write(EMAC_TXHDP(ch),
> - emac_virt_to_phys(curr_bd));
> + emac_virt_to_phys(curr_bd, priv));
> txch->queue_active = 1;
> }
> ++txch->queue_reinit;
> @@ -1418,10 +1417,11 @@ static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch)
> tail_bd->next = curr_bd;
> txch->active_queue_tail = curr_bd;
> tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
> - tail_bd->h_next = (int)emac_virt_to_phys(curr_bd);
> + tail_bd->h_next = (int)emac_virt_to_phys(curr_bd, priv);
> frame_status = tail_bd->mode;
> if (frame_status & EMAC_CPPI_EOQ_BIT) {
> - emac_write(EMAC_TXHDP(ch), emac_virt_to_phys(curr_bd));
> + emac_write(EMAC_TXHDP(ch),
> + emac_virt_to_phys(curr_bd, priv));
> frame_status &= ~(EMAC_CPPI_EOQ_BIT);
> tail_bd->mode = frame_status;
> ++txch->end_of_queue_add;
> @@ -1611,7 +1611,8 @@ static int emac_init_rxch(struct emac_priv *priv, u32 ch, char *param)
> }
>
> /* populate the hardware descriptor */
> - curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head);
> + curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head,
> + priv);
> /* FIXME buff_ptr = dma_map_single(... data_ptr ...) */
> curr_bd->buff_ptr = virt_to_phys(curr_bd->data_ptr);
> curr_bd->off_b_len = rxch->buf_size;
> @@ -1886,7 +1887,7 @@ static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch,
> rxch->active_queue_tail = curr_bd;
> if (0 != rxch->queue_active) {
> emac_write(EMAC_RXHDP(ch),
> - emac_virt_to_phys(rxch->active_queue_head));
> + emac_virt_to_phys(rxch->active_queue_head, priv));
> rxch->queue_active = 1;
> }
> } else {
> @@ -1897,11 +1898,11 @@ static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch,
> rxch->active_queue_tail = curr_bd;
> tail_bd->next = curr_bd;
> tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
> - tail_bd->h_next = emac_virt_to_phys(curr_bd);
> + tail_bd->h_next = emac_virt_to_phys(curr_bd, priv);
> frame_status = tail_bd->mode;
> if (frame_status & EMAC_CPPI_EOQ_BIT) {
> emac_write(EMAC_RXHDP(ch),
> - emac_virt_to_phys(curr_bd));
> + emac_virt_to_phys(curr_bd, priv));
> frame_status &= ~(EMAC_CPPI_EOQ_BIT);
> tail_bd->mode = frame_status;
> ++rxch->end_of_queue_add;
> @@ -1994,7 +1995,7 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
> curr_pkt->num_bufs = 1;
> curr_pkt->pkt_length =
> (frame_status & EMAC_RX_BD_PKT_LENGTH_MASK);
> - emac_write(EMAC_RXCP(ch), emac_virt_to_phys(curr_bd));
> + emac_write(EMAC_RXCP(ch), emac_virt_to_phys(curr_bd, priv));
> ++rxch->processed_bd;
> last_bd = curr_bd;
> curr_bd = last_bd->next;
> @@ -2005,7 +2006,7 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
> if (curr_bd) {
> ++rxch->mis_queued_packets;
> emac_write(EMAC_RXHDP(ch),
> - emac_virt_to_phys(curr_bd));
> + emac_virt_to_phys(curr_bd, priv));
> } else {
> ++rxch->end_of_queue;
> rxch->queue_active = 0;
> @@ -2106,7 +2107,7 @@ static int emac_hw_enable(struct emac_priv *priv)
> emac_write(EMAC_RXINTMASKSET, BIT(ch));
> rxch->queue_active = 1;
> emac_write(EMAC_RXHDP(ch),
> - emac_virt_to_phys(rxch->active_queue_head));
> + emac_virt_to_phys(rxch->active_queue_head, priv));
> }
>
> /* Enable MII */
> @@ -2705,6 +2706,12 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
> priv->ctrl_ram_size = pdata->ctrl_ram_size;
> priv->emac_ctrl_ram = priv->remap_addr + pdata->ctrl_ram_offset;
>
> + if (pdata->hw_ram_addr)
> + priv->hw_ram_addr = pdata->hw_ram_addr;
> + else
> + priv->hw_ram_addr = (u32 __force)res->start +
> + pdata->ctrl_ram_offset;
> +
> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> if (!res) {
> dev_err(emac_dev, "DaVinci EMAC: Error getting irq res\n");
> diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
> index eb24dc0..b318dfd 100644
> --- a/include/linux/davinci_emac.h
> +++ b/include/linux/davinci_emac.h
> @@ -19,6 +19,7 @@ struct emac_platform_data {
> u32 ctrl_reg_offset;
> u32 ctrl_mod_reg_offset;
> u32 ctrl_ram_offset;
> + u32 hw_ram_addr;
> u32 mdio_reg_offset;
> u32 ctrl_ram_size;
> u32 phy_mask;
^ permalink raw reply
* Re: [RFC PATCH iproute2] ip: Add support for setting MAC and VLAN on hardware queues
From: Stephen Hemminger @ 2009-11-18 19:15 UTC (permalink / raw)
To: David Miller; +Cc: jeffrey.t.kirsher, netdev, gospo, mitch.a.williams
In-Reply-To: <20091118.100728.91511216.davem@davemloft.net>
On Wed, 18 Nov 2009 10:07:28 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Tue, 17 Nov 2009 14:06:41 -0800
>
> > On Tue, 17 Nov 2009 13:55:07 -0800
> > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> >
> >> From: Williams, Mitch A <mitch.a.williams@intel.com>
> >>
> >> This patch adds support to the "ip" tool for setting the MAC address and
> >> VLAN filter for hardware device queues. This is most immediately useful for
> >> SR-IOV; for VF devices to be usable in the real world, the hypervisor or VM
> >> manager must be able to set these parameters before the VF device is
> >> assigned to any VM.
> >>
> >> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> >> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >
> > Is there anything to avoid prevent this from being misused by users who
> > are doing multiqueue. Maybe we need equivalent of "mounted" flag that block
> > devices have?
>
> It's a privileged config operation as far as I can tell.
>
> Given that, what could we possibly need to protect?
>
> This stuff looks basically fine to me.
>
I was thinking that maybe the general question of SR-IOV overlap with other
multiqueue usage. How is it possible to be sure queue is not being used
for other traffic? The MAC stuff itself is fine, just an example where
changing a queue being used for SR-IOV makes sense, but if being used
for regular multiqueue receive doesn't.
The filesystem example is that for years it was possible to do something
dumb like do fsck on a mounted filesystem and cause trouble (on unix and early
linux); but current systems don't allow it because it is stupid idea.
--
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-11-17
From: David Miller @ 2009-11-18 19:33 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091117161038.GA2854-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 17 Nov 2009 11:10:38 -0500
> Another round of wireless bits for -next...
>
> Included are a bunch of rt2x00 updates (related to rt2800{usb,pci}), an
> 802.11s mesh support refresh to match current drafts of the spec, big
> ath9k and iwlwifi drivers updates, new mac80211 support for using
> 4-address frames to talk to APs, a smattering of other driver and
> infrastructure updates, and of course my fix for the zdnet build break.
Pulled, thanks a lot John!
--
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: [net-next-2.6 PATCH 2/3] ixgbe: Set MSI-X vectors to NOBALANCING and set affinity
From: Ben Hutchings @ 2009-11-18 19:46 UTC (permalink / raw)
To: David Miller; +Cc: peter.p.waskiewicz.jr, jeffrey.t.kirsher, gospo, netdev
In-Reply-To: <20091118.101030.22004862.davem@davemloft.net>
On Wed, 2009-11-18 at 10:10 -0800, David Miller wrote:
> From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
> Date: Thu, 12 Nov 2009 11:12:22 -0800
>
> > Jesse Brandeburg and I talked with Arjan yesterday regarding these patches.
>
> Thanks for the update.
>
> > We also discussed the need for irqbalance to distinguish between Rx
> > and Tx queue vectors. Right now, irqbalance can identify an
> > interrupt belong to an Ethernet device, but it stops there. It
> > needs to also distinguish the directional vectors, and make sure to
> > balance the right queue vector with its paired queue (i.e. make sure
> > Tx queue 0's vector lines up with Rx queue 0's vector).
>
> Why don't you just simply use the same MSI-X vector for both TX
> queue 0 and RX queue 0, can't your hardware do that?
>
> That's what I plan on doing in the NIU driver soon.
When forwarding between 2 ports it can be beneficial to match the
affinity of each port's TX interrupts with the other port's RX
interrupts. Obviously this is not the case when the system is acting as
an endpoint, and the situation is presumably more complex when
forwarding between >2 ports.
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
* Re: [net-next-2.6 PATCH 2/3] ixgbe: Set MSI-X vectors to NOBALANCING and set affinity
From: David Miller @ 2009-11-18 19:50 UTC (permalink / raw)
To: bhutchings; +Cc: peter.p.waskiewicz.jr, jeffrey.t.kirsher, gospo, netdev
In-Reply-To: <1258573570.2780.14.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 18 Nov 2009 19:46:10 +0000
> When forwarding between 2 ports it can be beneficial to match the
> affinity of each port's TX interrupts with the other port's RX
> interrupts. Obviously this is not the case when the system is
> acting as an endpoint, and the situation is presumably more complex
> when forwarding between >2 ports.
Yes, but tricks like that won't be necessary with changes that Eric
Dumazet said he'd work on soon, wherein SKB frees always get scheduled
to occur on the cpu where allocation occured.
^ permalink raw reply
* Re: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Ben Hutchings @ 2009-11-18 19:53 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, shemminger, netdev, gospo, Mitch Williams
In-Reply-To: <20091117214923.15119.98918.stgit@localhost.localdomain>
On Tue, 2009-11-17 at 13:50 -0800, Jeff Kirsher wrote:
> From: Williams, Mitch A <mitch.a.williams@intel.com>
>
> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
>
> include/linux/netdevice.h | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 7043f85..6a70365 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -610,6 +610,8 @@ struct netdev_queue {
> * this function is called when a VLAN id is unregistered.
> *
> * void (*ndo_poll_controller)(struct net_device *dev);
> + * int (*ndo_set_queue_mac)(struct net_device *dev, int queue, u8* mac);
> + * int (*ndo_set_queue_vlan)(struct net_device *dev, int queue, u16 vlan);
> */
> #define HAVE_NET_DEVICE_OPS
> struct net_device_ops {
> @@ -659,6 +661,10 @@ struct net_device_ops {
> #define HAVE_NETDEV_POLL
> void (*ndo_poll_controller)(struct net_device *dev);
> #endif
> + int (*ndo_set_queue_mac)(struct net_device *dev,
> + int queue, u8 *mac);
> + int (*ndo_set_queue_vlan)(struct net_device *dev,
> + int queue, u16 vlan);
[...]
How do you remove a filter?
What about filtering on both MAC address and VLAN (our new controller
supports that)?
It seems like this could be defined as an extension to the existing
ethtool RX flow filter API.
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
* Re: large packet loss take2 2.6.31.x
From: Jarek Poplawski @ 2009-11-18 20:10 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Frans Pop, Andi Kleen, linux-kernel, netdev
In-Reply-To: <81bfc67a0911181021n1b969565y4a39b181360b5e92@mail.gmail.com>
On Wed, Nov 18, 2009 at 01:21:19PM -0500, Caleb Cushing wrote:
> > So, there is a basic question: can this mtr loss be seen while no
> > other traffic is present? After looking into these current dumps I
> > doubt. There are e.g. 3 pings unanswered between 09:21:50 and
> > 09:21:52 (21:31:34 to 21:31:38 router time), but a lot of tcp
> > packets to and from 192.168.1.3, so looks like simply dropped and
> > we can guess the reason.
>
> yes. this was at a fairly low traffic time of day. 5am only 2 people
> were up, and I was using the other computer during. I've had everyone
> actively doing one or more of downloading/uploading/video/voip/gaming
> stuff on this network with no noticeable packet loss. if really,
> really needed I can probably restrict this network to 2 machines for
> the duration of the test.
Alas "a fairly low traffic" can have a fairly high surges, so it's not
easy to compare. Anyway, try to check, if it's still available, if
there were any messages from the NIC in syslog etc. during this test
(~09:21:50).
>
> > Since this patch from the bisection is really limited to this one
> > module I doubt we should follow this direction. IMHO it shows the
> > test wasn't reproducible enough. Probably the amount and/or kind of
> > other traffic really matter. If I'm wrong and missed something again
> > let me know. Btw, could you try if changing with ifconfig the
> > txqueuelen of desktop's eth0 from 100 to 1000 changes anything
> > in this mtr test?
>
> yeah testing it under my known working config first. I'll get back w/ you later.
Btw, since dropping at hardware (NIC) level seems more likely to me,
could you send 'ethtool eth0', and 'ethtool -S eth0' after such tests
(both sides).
Jarek P.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] allow access to sysfs_groups member
From: Kurt Van Dijck @ 2009-11-18 20:57 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20091118.095716.61189059.davem@davemloft.net>
On Wed, Nov 18, 2009 at 09:57:16AM -0800, David Miller wrote:
> > This patch allows adding sysfs attribute groups during netdevice registration.
> > The idea is that before the register_netdev call, several calls to
> > netdev_sysfs_add_group can be done. These attributes are accessible (by
> > udev) during the uevent.
> >
> > Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
> > Acked-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Patch is corrupted by your email client. Tab characters have
> been turned into spaces, etc.
Oops. My fault. I did an copy in X ...
Sorry for that.
>
> Please fix this up and resubmit.
>
> Thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] allow access to sysfs_groups member
From: Kurt Van Dijck @ 2009-11-18 20:59 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20091118.095716.61189059.davem@davemloft.net>
This patch allows adding sysfs attribute groups during netdevice registration.
The idea is that before the register_netdev call, several calls to
netdev_sysfs_add_group can be done. These attributes are accessible (by
udev) during the uevent.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/netdevice.h | 2 ++
net/core/net-sysfs.c | 29 ++++++++++++++++++++++++-----
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8380009..ebfc789 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1115,6 +1115,8 @@ extern int dev_open(struct net_device *dev);
extern int dev_close(struct net_device *dev);
extern void dev_disable_lro(struct net_device *dev);
extern int dev_queue_xmit(struct sk_buff *skb);
+extern int netdev_sysfs_add_group(struct net_device *net,
+ const struct attribute_group *grp);
extern int register_netdevice(struct net_device *dev);
extern void unregister_netdevice(struct net_device *dev);
extern void free_netdev(struct net_device *dev);
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 753c420..6451e9a 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -527,27 +527,46 @@ void netdev_unregister_kobject(struct net_device * net)
device_del(dev);
}
+/* Add a sysfs group to the netdev groups */
+int netdev_sysfs_add_group(struct net_device *net,
+ const struct attribute_group *grp)
+{
+ struct attribute_group **groups = net->sysfs_groups;
+ struct attribute_group **end;
+
+ BUG_ON(net->reg_state >= NETREG_REGISTERED);
+ /* end pointer, with room for null terminator */
+ end = &net->sysfs_groups[ARRAY_SIZE(net->sysfs_groups) - 1];
+ for (; groups < end; ++groups) {
+ if (!*groups) {
+ *groups = grp;
+ return 0;
+ }
+ }
+ return -ENOSPC;
+}
+EXPORT_SYMBOL_GPL(netdev_sysfs_add_group);
+
/* Create sysfs entries for network device. */
int netdev_register_kobject(struct net_device *net)
{
struct device *dev = &(net->dev);
- const struct attribute_group **groups = net->sysfs_groups;
dev->class = &net_class;
dev->platform_data = net;
- dev->groups = groups;
+ dev->groups = net->sysfs_groups;
dev_set_name(dev, "%s", net->name);
#ifdef CONFIG_SYSFS
- *groups++ = &netstat_group;
+ netdev_sysfs_add_group(net, &netstat_group);
#ifdef CONFIG_WIRELESS_EXT_SYSFS
if (net->ieee80211_ptr)
- *groups++ = &wireless_group;
+ netdev_sysfs_add_group(net, &wireless_group);
#ifdef CONFIG_WIRELESS_EXT
else if (net->wireless_handlers)
- *groups++ = &wireless_group;
+ netdev_sysfs_add_group(net, &wireless_group);
#endif
#endif
#endif /* CONFIG_SYSFS */
^ permalink raw reply related
* Re: [net-next-2.6 PATCH v2] allow access to sysfs_groups member
From: David Miller @ 2009-11-18 21:08 UTC (permalink / raw)
To: kurt.van.dijck; +Cc: shemminger, netdev
In-Reply-To: <20091118205952.GB282@e-circ.dyndns.org>
From: Kurt Van Dijck <kurt.van.dijck@eia.be>
Date: Wed, 18 Nov 2009 21:59:52 +0100
> This patch allows adding sysfs attribute groups during netdevice registration.
> The idea is that before the register_netdev call, several calls to
> netdev_sysfs_add_group can be done. These attributes are accessible (by
> udev) during the uevent.
>
> Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Unfortunately, the code in this function is much different
in net-next-2.6 which is where I want to add this, and your
patch doesn't apply.
Please rebase your patch on that tree, thank you.
^ permalink raw reply
* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Williams, Mitch A @ 2009-11-18 21:37 UTC (permalink / raw)
To: Ben Hutchings, Kirsher, Jeffrey T
Cc: davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1258573987.2780.20.camel@achroite.uk.solarflarecom.com>
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Wednesday, November 18, 2009 11:53 AM
>How do you remove a filter?
>
You remove a filter by setting it to 0 on that queue. Works for either MAC or VLAN.
>What about filtering on both MAC address and VLAN (our new controller
>supports that)?
Setting a MAC filter doesn't blow away the VLAN filter, or vice-versa. So just run 'ip' twice to set the filters. Our hardware does it too, and it works fine for me:
$ ip link set eth1 queue 1 mac 00:11:22:33:44:55
$ ip link set eth1 queue 1 vlan 10
-Mitch
^ 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