* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Lorenzo Colitti @ 2010-10-26 5:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20101025213841.635b9a15@nehalam>
On Mon, Oct 25, 2010 at 9:38 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> This is incorrect. When link is lost, routes and address should not be
> flushed. They should be marked as tentative and then go through DAD again
> on the new network.
That won't help the case I am trying to fix, which is the case where
the new link has a global prefix different than the old link. Marking
the addresses as tentative will simply make them pass DAD and come
back as soon as link comes back. But since they don't match the prefix
that is assigned to the new link, they are unusable, because packets
can't be routed back to them.
> If you do it this way, you break routing protocols when link is brought
> down and back up.
The only addresses and routes flushed in this way should be ones that
aren't manually configured, i.e., the ones created by autoconf
(addrconf.c:2720 onwards). These won't be used by routing protocols,
except for link-local addresses. So I assume you're talking about
link-local here.
Link-local addresses are immediately recreated in a tentative state as
soon as link comes back, because on NETDEV_UP addrconf_notify calls
addrconf_dev_config. So, this patch only makes it so that they become
tentative when link goes away and comes back. In that time, the router
that temporarily loses link is unable to send packets for the brief
period of time that the link is performing DAD, but if the router has
lost link, it will also fail to send the packet while link is lost.
What's the additional failure scenario? Will it help if I make it so
that link-local addresses aren't touched at all?
^ permalink raw reply
* RE: [PATCH net-next-2.6 1/2] be2net: Adding an option to use INTx instead of MSI-X
From: Somnath.Kotur @ 2010-10-26 5:24 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20101025.162535.226782713.davem@davemloft.net>
Dave,
Could you pls ignore this patch and apply the next patch in the series ?
( PATCH 2/2] be2net: Schedule/Destroy worker thread in probe()/remove() rather than open()/close()
Thanks
Som
________________________________________
From: David Miller [davem@davemloft.net]
Sent: Tuesday, October 26, 2010 4:55 AM
To: bhutchings@solarflare.com
Cc: Kotur, Somnath; netdev@vger.kernel.org; linux-pci@vger.kernel.org
Subject: Re: [PATCH net-next-2.6 1/2] be2net: Adding an option to use INTx instead of MSI-X
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 25 Oct 2010 23:38:53 +0100
> David Miller wrote:
>> From: Somnath Kotur <somnath.kotur@emulex.com>
>> Date: Mon, 25 Oct 2010 16:42:35 +0530
>>
>> > By default, be2net uses MSIx wherever possible.
>> > Adding a module parameter to use INTx for users who do not want to use MSIx.
>> >
>> > Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
>>
>> Either add a new ethtool flag, or use the PCI subsystem facilities
>> for tweaking things to implement this.
>>
>> Do not use a module option, otherwise every other networking driver
>> author will get the same "cool" idea, give the module option
>> different names, and the resulting user experience is terrible.
>
> This has already happened, sadly. So far as I can see it's mostly done
> to allow users to work around systems with broken MSIs; I'm not aware of
> any other reason to prefer legacy interrupts. However, the PCI subsystem
> already implements a blacklist and a kernel parameter for disabling MSIs
> on these systems.
The PCI subsystem bits I'm totally fine with.
But in the drivers themselves, that's what I don't want.
^ permalink raw reply
* Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
From: Krishna Kumar2 @ 2010-10-26 5:10 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: anthony, arnd, avi, davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <20101025161718.GA19559@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> wrote on 10/25/2010 09:47:18 PM:
> > Any feedback, comments, objections, issues or bugs about the
> > patches? Please let me know if something needs to be done.
>
> I am trying to wrap my head around kernel/user interface here.
> E.g., will we need another incompatible change when we add multiple RX
> queues?
Though I added a 'mq' option to qemu, there shouldn't be
any incompatibility between old and new qemu's wrt vhost
and virtio-net drivers. So the old qemu will run new host
and new guest without issues, and new qemu can also run
old host and old guest. Multiple RXQ will also not add
any incompatibility.
With MQ RX, I will be able to remove the hueristic (idea
from David Stevens). The idea is: Guest sends out packets
on, say TXQ#2, vhost#2 processes the packets but packets
going out from host to guest might be sent out on a
different RXQ, say RXQ#4. Guest receives the packet on
RXQ#4, and all future responses on that connection are sent
on TXQ#4. Now vhost#4 processes both RX and TX packets for
this connection. Without needing to hash on the connection,
guest can make sure that the same vhost thread will handle
a single connection.
> Also need to think about how robust our single stream heuristic is,
> e.g. what are the chances it will misdetect a bidirectional
> UDP stream as a single TCP?
I think it should not happen. The hueristic code gets
called for handling just the transmit packets, packets
that vhost sends out to the guest skip this path.
I tested unidirectional and bidirectional UDP to confirm:
8 iterations of iperf tests, each iteration of 15 secs,
result is the sum of all 8 iterations in Gbits/sec
__________________________________________
Uni-directional Bi-directional
Org New Org New
__________________________________________
71.78 71.77 71.74 72.07
__________________________________________
Thanks,
- KK
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH 1/5] netdev: bfin_mac: push settings to platform resources
From: David Miller @ 2010-10-26 5:07 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <AANLkTi=jfho4yd_gSMfKywBPkD_=smgnP_yLtRh=00jv@mail.gmail.com>
From: Mike Frysinger <vapier@gentoo.org>
Date: Mon, 25 Oct 2010 21:54:48 -0400
> On Sun, Oct 24, 2010 at 19:51, Mike Frysinger wrote:
>> On Sun, Oct 24, 2010 at 19:45, David Miller wrote:
>>> From: Mike Frysinger
>>>> and i have the Blackfin changes waiting for you to merge this patch.
>>>> i can squash them into this change and have you merge the result, or i
>>>> can merge it. i dont really care either way.
>>>
>>> Why don't you just apply this to your tree then. Feel free to add my:
>>
>> thanks, i'll do that
>
> Linus has taken this via my tree now. are you going to merge the
> other patches ? or do i need to resend them ?
Please resend them, thanks.
^ permalink raw reply
* ath9k crashing the kernel
From: Jaswinder Singh @ 2010-10-26 5:06 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-wireless, netdev, ath9k-devel
Hello,
ath9k is crashing the kernel :
[ 21.276554] BUG: spinlock bad magic on CPU#1, NetworkManager/1056
[ 21.277015] lock: f5be80a8, .magic: 00000000, .owner: <none>/-1,
.owner_cpu: 0
[ 21.277015] Pid: 1056, comm: NetworkManager Not tainted 2.6.36-netbook+ #20
[ 21.277015] Call Trace:
[ 21.277015] [<c14767a7>] ? printk+0xf/0x11
[ 21.277015] [<c117b823>] spin_bug+0x7c/0x87
[ 21.301365] [<c117b8bd>] do_raw_spin_lock+0x1e/0x125
[ 21.301365] [<c1478d0a>] ? _raw_spin_unlock_bh+0x1a/0x1c
[ 21.301365] [<c1478dc3>] _raw_spin_lock_irqsave+0x17/0x1c
[ 21.318857] [<c1288a74>] ath9k_config+0x255/0x38b
[ 21.318857] [<c1447bdb>] ieee80211_hw_config+0x10a/0x114
[ 21.328034] [<c1453545>] ieee80211_do_open+0x3de/0x4cf
[ 21.328034] [<c1452206>] ? ieee80211_check_concurrent_iface+0x21/0x13a
[ 21.328034] [<c104c470>] ? raw_notifier_call_chain+0xc/0xe
[ 21.328034] [<c1453691>] ieee80211_open+0x5b/0x5e
[ 21.328034] [<c13947cf>] __dev_open+0x80/0xa9
[ 21.328034] [<c13920bb>] __dev_change_flags+0xa1/0x116
[ 21.328034] [<c1394723>] dev_change_flags+0x13/0x3f
[ 21.328034] [<c139d568>] do_setlink+0x226/0x507
[ 21.328034] [<c139d917>] rtnl_setlink+0xce/0xd4
[ 21.328034] [<c11786d2>] ? copy_to_user+0x3a/0x118
[ 21.328034] [<c139d849>] ? rtnl_setlink+0x0/0xd4
[ 21.328034] [<c139df4d>] rtnetlink_rcv_msg+0x17e/0x194
[ 21.328034] [<c139ddcf>] ? rtnetlink_rcv_msg+0x0/0x194
[ 21.328034] [<c13a59c4>] netlink_rcv_skb+0x30/0x76
[ 21.328034] [<c139ddc8>] rtnetlink_rcv+0x1b/0x22
[ 21.328034] [<c13a5772>] netlink_unicast+0x1aa/0x20b
[ 21.328034] [<c13a5eac>] netlink_sendmsg+0x22c/0x27a
[ 21.328034] [<c13862b8>] sock_sendmsg+0xa5/0xbb
[ 21.328034] [<c13862b8>] ? sock_sendmsg+0xa5/0xbb
[ 21.328034] [<c138e05b>] ? verify_iovec+0x3e/0x6b
[ 21.328034] [<c1386ab2>] sys_sendmsg+0x149/0x196
[ 21.328034] [<c10826f5>] ? unlock_page+0x40/0x43
[ 21.328034] [<c10952d5>] ? __do_fault+0x367/0x393
[ 21.328034] [<c1096b8e>] ? handle_mm_fault+0x3bd/0x77a
[ 21.328034] [<c10b6fb3>] ? destroy_inode+0x1f/0x30
[ 21.328034] [<c138694e>] ? sys_recvmsg+0x2b/0x46
[ 21.328034] [<c1387c00>] sys_socketcall+0x146/0x18b
[ 21.328034] [<c1002850>] sysenter_do_call+0x12/0x26
[ 21.344846] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 21.487994] atl1c 0000:03:00.0: irq 42 for MSI/MSI-X
[ 21.543870] ADDRCONF(NETDEV_UP): eth0: link is not ready
Linux 2.6.36 f6f94e2ab1 is good
and
229aebb873e2972 is bad
I am trying to bisect it but I am getting compilation error :
LD .tmp_vmlinux1
drivers/built-in.o: In function `ath_do_set_opmode':
/home/jaswinder/jaswinder-git/linux-2.6/drivers/net/wireless/ath/ath5k/base.c:567:
undefined reference to `ath_opmode_to_string'
/home/jaswinder/jaswinder-git/linux-2.6/drivers/net/wireless/ath/ath5k/base.c:568:
undefined reference to `ath_opmode_to_string'
make: *** [.tmp_vmlinux1] Error 1
[jaswinder@ linux-2.6]$
Thanks,
--
Jaswinder Singh.
^ permalink raw reply
* Re: linux-next: Tree for October 25 (netfilter/nf_conntrack_reasm)
From: David Miller @ 2010-10-26 5:03 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, netfilter-devel, netdev, linux-next, linux-kernel
In-Reply-To: <20101025165529.9cedfeac.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 25 Oct 2010 16:55:29 -0700
> On Mon, 25 Oct 2010 14:58:34 +1100 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Reminder: do not add 2.6.38 destined stuff to linux-next until after
>> 2.6.37-rc1 is released.
>
> net/ipv6/netfilter/nf_conntrack_reasm.c:628: error: 'nf_ct_frag6_sysctl_header' undeclared (first use in this function)
> net/ipv6/netfilter/nf_conntrack_reasm.c:628: error: 'nf_net_netfilter_sysctl_path' undeclared (first use in this function)
> net/ipv6/netfilter/nf_conntrack_reasm.c:629: error: 'nf_ct_frag6_sysctl_table' undeclared (first use in this function)
> net/ipv6/netfilter/nf_conntrack_reasm.c:640: error: 'nf_ct_frag6_sysctl_header' undeclared (first use in this function)
>
>
> config file is attached.
Should also be fixed by the commit I just pointed you to.
^ permalink raw reply
* Re: linux-next: Tree for October 25 (netfilter/xt_socket)
From: David Miller @ 2010-10-26 5:02 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, netdev, linux-next, linux-kernel, netfilter-devel
In-Reply-To: <20101025165407.74b0c0a0.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 25 Oct 2010 16:54:07 -0700
> xt_socket.c:(.text+0x39ff8): undefined reference to `ipv6_find_hdr'
> xt_socket.c:(.init.text+0x1703): undefined reference to `nf_defrag_ipv6_enable'
This ought to be fixed in net-2.6 already, by:
commit f6318e558806c925029dc101f14874be9f9fa78f
Author: KOVACS Krisztian <hidden@balabit.hu>
Date: Sun Oct 24 23:38:32 2010 +0000
netfilter: fix module dependency issues with IPv6 defragmentation, ip6tables and xt_TPROXY
One of the previous tproxy related patches split IPv6 defragmentation and
connection tracking, but did not correctly add Kconfig stanzas to handle the
new dependencies correctly. This patch fixes that by making the config options
mirror the setup we have for IPv4: a distinct config option for defragmentation
that is automatically selected by both connection tracking and
xt_TPROXY/xt_socket.
The patch also changes the #ifdefs enclosing IPv6 specific code in xt_socket
and xt_TPROXY: we only compile these in case we have ip6tables support enabled.
Signed-off-by: KOVACS Krisztian <hidden@balabit.hu>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [net-next] stmmac: enable/disable rx/tx in the core with a single write.
From: Giuseppe CAVALLARO @ 2010-10-26 4:58 UTC (permalink / raw)
To: netdev; +Cc: avisconti
From: avisconti <armando.visconti@st.com>
This patch enables and disables the rx and tx bits in the MAC control reg
by using a single write operation.
This also solves a possible problem (spotted on SPEAr platforms) at 10Mbps
where two consecutive writes to a MAC control register can take more than
4 phy_clk cycles.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/stmmac_main.c | 40 +++++++++----------------------------
1 files changed, 10 insertions(+), 30 deletions(-)
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index 823b9e6..06bc603 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -337,33 +337,19 @@ static int stmmac_init_phy(struct net_device *dev)
return 0;
}
-static inline void stmmac_mac_enable_rx(void __iomem *ioaddr)
+static inline void stmmac_enable_mac(void __iomem *ioaddr)
{
u32 value = readl(ioaddr + MAC_CTRL_REG);
- value |= MAC_RNABLE_RX;
- /* Set the RE (receive enable bit into the MAC CTRL register). */
- writel(value, ioaddr + MAC_CTRL_REG);
-}
-static inline void stmmac_mac_enable_tx(void __iomem *ioaddr)
-{
- u32 value = readl(ioaddr + MAC_CTRL_REG);
- value |= MAC_ENABLE_TX;
- /* Set the TE (transmit enable bit into the MAC CTRL register). */
+ value |= MAC_RNABLE_RX | MAC_ENABLE_TX;
writel(value, ioaddr + MAC_CTRL_REG);
}
-static inline void stmmac_mac_disable_rx(void __iomem *ioaddr)
+static inline void stmmac_disable_mac(void __iomem *ioaddr)
{
u32 value = readl(ioaddr + MAC_CTRL_REG);
- value &= ~MAC_RNABLE_RX;
- writel(value, ioaddr + MAC_CTRL_REG);
-}
-static inline void stmmac_mac_disable_tx(void __iomem *ioaddr)
-{
- u32 value = readl(ioaddr + MAC_CTRL_REG);
- value &= ~MAC_ENABLE_TX;
+ value &= ~(MAC_ENABLE_TX | MAC_RNABLE_RX);
writel(value, ioaddr + MAC_CTRL_REG);
}
@@ -857,8 +843,7 @@ static int stmmac_open(struct net_device *dev)
writel(0xffffffff, priv->ioaddr + MMC_LOW_INTR_MASK);
/* Enable the MAC Rx/Tx */
- stmmac_mac_enable_rx(priv->ioaddr);
- stmmac_mac_enable_tx(priv->ioaddr);
+ stmmac_enable_mac(priv->ioaddr);
/* Set the HW DMA mode and the COE */
stmmac_dma_operation_mode(priv);
@@ -928,9 +913,8 @@ static int stmmac_release(struct net_device *dev)
/* Release and free the Rx/Tx resources */
free_dma_desc_resources(priv);
- /* Disable the MAC core */
- stmmac_mac_disable_tx(priv->ioaddr);
- stmmac_mac_disable_rx(priv->ioaddr);
+ /* Disable the MAC Rx/Tx */
+ stmmac_disable_mac(priv->ioaddr);
netif_carrier_off(dev);
@@ -1787,8 +1771,7 @@ static int stmmac_dvr_remove(struct platform_device *pdev)
priv->hw->dma->stop_rx(priv->ioaddr);
priv->hw->dma->stop_tx(priv->ioaddr);
- stmmac_mac_disable_rx(priv->ioaddr);
- stmmac_mac_disable_tx(priv->ioaddr);
+ stmmac_disable_mac(priv->ioaddr);
netif_carrier_off(ndev);
@@ -1839,13 +1822,11 @@ static int stmmac_suspend(struct platform_device *pdev, pm_message_t state)
dis_ic);
priv->hw->desc->init_tx_desc(priv->dma_tx, priv->dma_tx_size);
- stmmac_mac_disable_tx(priv->ioaddr);
-
/* Enable Power down mode by programming the PMT regs */
if (device_can_wakeup(priv->device))
priv->hw->mac->pmt(priv->ioaddr, priv->wolopts);
else
- stmmac_mac_disable_rx(priv->ioaddr);
+ stmmac_disable_mac(priv->ioaddr);
} else {
priv->shutdown = 1;
/* Although this can appear slightly redundant it actually
@@ -1886,8 +1867,7 @@ static int stmmac_resume(struct platform_device *pdev)
netif_device_attach(dev);
/* Enable the MAC and DMA */
- stmmac_mac_enable_rx(priv->ioaddr);
- stmmac_mac_enable_tx(priv->ioaddr);
+ stmmac_enable_mac(priv->ioaddr);
priv->hw->dma->start_tx(priv->ioaddr);
priv->hw->dma->start_rx(priv->ioaddr);
--
1.5.5.6
^ permalink raw reply related
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Stephen Hemminger @ 2010-10-26 4:38 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: netdev
In-Reply-To: <AANLkTikC4pv8aOODM2pOg2bKQGL69wivcUU3f9ZziPhe@mail.gmail.com>
On Mon, 25 Oct 2010 19:08:27 -0700
Lorenzo Colitti <lorenzo@google.com> wrote:
> When roaming between different networks (e.g., changing wireless
> SSIDs, or plugging in to different wired networks), IPv6 addresses and
> routes are not cleared. If the two networks have different IPv6
> subnets assigned, the host maintains both the old and new IPv6
> addresses and gateways, but only the new ones works. If the host
> chooses the wrong source address or gateway, or if the new network
> does not have IPv6 but the old one did, IPv6 connections time out,
> leading to long delays when trying to connect to IPv6 hosts.
>
> Fix this by ensuring that autoconfigured IPv6 addresses and routes are
> purged when link is lost, not only when the interface goes down.
>
> Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
>
> --- a/net/ipv6/addrconf.c 2010-10-20 13:30:22.000000000 -0700
> +++ b/net/ipv6/addrconf.c 2010-10-25 13:55:15.000000000 -0700
> @@ -2524,6 +2524,14 @@
> } else {
> if (!addrconf_qdisc_ok(dev)) {
> /* device is still not ready. */
> + if (idev && (idev->if_flags & IF_READY)) {
> + /* Link lost. Clear addresses and
> + routes, the device might come back
> + on a link where they are no longer
> + valid. */
> + addrconf_ifdown(dev, 0);
> + idev->if_flags &= ~IF_READY;
> + }
> break;
> }
This is incorrect. When link is lost, routes and address should not be
flushed. They should be marked as tentative and then go through DAD again
on the new network.
If you do it this way, you break routing protocols when link is brought
down and back up.
^ permalink raw reply
* [PATCH] net/unix: Allow Unix sockets to be treated like normal files.
From: Jeff Hansen @ 2010-10-26 4:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jeff Hansen
This allows Unix sockets to be opened, written, read, and closed, like
normal files. This can be especially handy from, for example, a shell
script that wants to send a short message to a Unix socket, but doesn't
want to and/or cannot create the socket itself.
This will try to open the Unix socket first in SOCK_DGRAM mode, then
SOCK_STREAM mode if that fails.
Signed-off-by: Jeff Hansen <x@jeffhansen.com>
---
net/unix/Kconfig | 10 +++++
net/unix/af_unix.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 123 insertions(+), 0 deletions(-)
diff --git a/net/unix/Kconfig b/net/unix/Kconfig
index 5a69733..68df4f1 100644
--- a/net/unix/Kconfig
+++ b/net/unix/Kconfig
@@ -19,3 +19,13 @@ config UNIX
Say Y unless you know what you are doing.
+config UNIX_FOPS
+ boolean "Allow Unix sockets to be treated like normal files"
+ depends on UNIX
+ ---help---
+ If you say Y here, Unix sockets may be opened, written, read, and
+ closed, like normal files. This is handy for sending short commands
+ to Unix sockets (i.e. from shell scripts), without having to create
+ a Unix socket.
+
+ Say Y unless you know what you are doing.
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 0ebc777..b5a6655 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -798,6 +798,114 @@ fail:
return NULL;
}
+#ifdef CONFIG_UNIX_FOPS
+static int unix_open(struct inode *inode, struct file *filp)
+{
+ int err;
+ struct socket *sock = NULL;
+ struct dentry *dentry = filp->f_dentry;
+ struct sockaddr_un sunaddr = { 0 };
+ char *p;
+
+ if (!filp)
+ return -ENXIO;
+ dentry = filp->f_dentry;
+
+ if (!dentry || !dentry->d_parent)
+ return -ENXIO;
+
+ if (filp->private_data)
+ return -EBUSY;
+
+ sunaddr.sun_family = AF_UNIX;
+ p = d_path(&filp->f_path, sunaddr.sun_path, sizeof(sunaddr.sun_path));
+ if (IS_ERR(p))
+ return PTR_ERR(p);
+ memmove(sunaddr.sun_path, p, p[sizeof(sunaddr.sun_path) - 1] ?
+ sizeof(sunaddr.sun_path) : strlen(p));
+
+ err = sock_create(PF_UNIX, SOCK_DGRAM, 0, &sock);
+ if (err)
+ return err;
+
+ err = unix_dgram_connect(sock, (struct sockaddr *)&sunaddr,
+ sizeof(sunaddr), 0);
+ if (err) {
+ sock_release(sock);
+
+ err = sock_create(PF_UNIX, SOCK_STREAM, 0, &sock);
+ if (err)
+ return err;
+
+ err = unix_stream_connect(sock, (struct sockaddr *)&sunaddr,
+ sizeof(sunaddr), 0);
+
+ if (err)
+ return err;
+ }
+ filp->private_data = sock;
+
+ return err;
+}
+
+static int unix_frelease(struct inode *inode, struct file *filp)
+{
+ if (!filp->private_data)
+ return -ENXIO;
+
+ sock_release(filp->private_data);
+ filp->private_data = NULL;
+ return 0;
+}
+
+static ssize_t unix_readwrite(struct file *filp, void *buf,
+ size_t _len, loff_t *ppos, int do_write)
+{
+ struct socket *sock = filp->private_data;
+ int len = (int)_len, err;
+ struct kvec iov = {
+ .iov_base = buf,
+ .iov_len = len,
+ };
+ struct msghdr msg = {
+ /* NB: struct iovec and kvec are equal */
+ .msg_iov = (struct iovec *)&iov,
+ .msg_iovlen = 1,
+ };
+
+ if (!sock)
+ return -ENXIO;
+ if (_len > 0xffffffffLL)
+ return -E2BIG;
+
+ err = do_write ? sock_sendmsg(sock, &msg, len) :
+ sock_recvmsg(sock, &msg, len, 0);
+ if (err > 0 && ppos)
+ *ppos += err;
+
+ return err;
+}
+
+static ssize_t unix_write(struct file *filp, const char __user *buf,
+ size_t _len, loff_t *ppos)
+{
+ return unix_readwrite(filp, (void *)buf, _len, ppos, 0);
+}
+
+static ssize_t unix_read(struct file *filp, const char __user *buf,
+ size_t _len, loff_t *ppos)
+{
+ return unix_readwrite(filp, (void *)buf, _len, ppos, 0);
+}
+
+const struct file_operations unix_sock_fops = {
+ .owner = THIS_MODULE,
+ .open = unix_open,
+ .release = unix_frelease,
+ .write = unix_write,
+ .read = unix_read,
+};
+#endif /* CONFIG_UNIX_FOPS */
static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
@@ -874,6 +982,11 @@ out_mknod_drop_write:
mnt_drop_write(nd.path.mnt);
if (err)
goto out_mknod_dput;
+
+#ifdef CONFIG_UNIX_FOPS
+ dentry->d_inode->i_fop = &unix_sock_fops;
+#endif
+
mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
dput(nd.path.dentry);
nd.path.dentry = dentry;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 36/43] MN10300: ASB2364: Add support for SMSC911X and SMC911X
From: David Howells @ 2010-10-26 2:56 UTC (permalink / raw)
To: linux-am33-list
Cc: steve.glendinning, netdev, linux-kernel, Akira Takeuchi,
Kiyoshi Owada
In-Reply-To: <20101026025301.23512.24525.stgit@warthog.procyon.org.uk>
From: Akira Takeuchi <takeuchi.akr@jp.panasonic.com>
Add support for SMSC911X and SMC911X for the ASB2364 unit.
Signed-off-by: Akira Takeuchi <takeuchi.akr@jp.panasonic.com>
Signed-off-by: Kiyoshi Owada <owada.kiyoshi@jp.panasonic.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: steve.glendinning@smsc.com
cc: netdev@vger.kernel.org
---
arch/mn10300/Kconfig | 1
arch/mn10300/include/asm/smsc911x.h | 1
arch/mn10300/unit-asb2364/Makefile | 2
arch/mn10300/unit-asb2364/include/unit/smsc911x.h | 198 +++++++++++++++++++++
arch/mn10300/unit-asb2364/smsc911x.c | 58 ++++++
drivers/net/Kconfig | 12 +
drivers/net/smsc911x.c | 7 +
drivers/net/smsc911x.h | 17 ++
8 files changed, 292 insertions(+), 4 deletions(-)
create mode 100644 arch/mn10300/include/asm/smsc911x.h
create mode 100644 arch/mn10300/unit-asb2364/include/unit/smsc911x.h
create mode 100644 arch/mn10300/unit-asb2364/smsc911x.c
diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig
index 81e2781..88901a2 100644
--- a/arch/mn10300/Kconfig
+++ b/arch/mn10300/Kconfig
@@ -96,6 +96,7 @@ config MN10300_UNIT_ASB2305
config MN10300_UNIT_ASB2364
bool "ASB2364"
+ select SMSC911X_ARCH_HOOKS if SMSC911X
endchoice
diff --git a/arch/mn10300/include/asm/smsc911x.h b/arch/mn10300/include/asm/smsc911x.h
new file mode 100644
index 0000000..2fcd108
--- /dev/null
+++ b/arch/mn10300/include/asm/smsc911x.h
@@ -0,0 +1 @@
+#include <unit/smsc911x.h>
diff --git a/arch/mn10300/unit-asb2364/Makefile b/arch/mn10300/unit-asb2364/Makefile
index 6dd27d6..2fdd99b 100644
--- a/arch/mn10300/unit-asb2364/Makefile
+++ b/arch/mn10300/unit-asb2364/Makefile
@@ -7,4 +7,4 @@
#
# Note 2! The CFLAGS definitions are now in the main makefile...
-obj-y := unit-init.o leds.o
+obj-y := unit-init.o leds.o smsc911x.o
diff --git a/arch/mn10300/unit-asb2364/include/unit/smsc911x.h b/arch/mn10300/unit-asb2364/include/unit/smsc911x.h
new file mode 100644
index 0000000..1d3bcdf
--- /dev/null
+++ b/arch/mn10300/unit-asb2364/include/unit/smsc911x.h
@@ -0,0 +1,198 @@
+/* Support for the SMSC911x NIC
+ *
+ * Copyright (C) 2006 Matsushita Electric Industrial Co., Ltd.
+ * All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#ifndef _ASM_UNIT_SMSC911X_H
+#define _ASM_UNIT_SMSC911X_H
+
+#include <linux/netdevice.h>
+#include <proc/irq.h>
+#include <unit/fpga-regs.h>
+
+#define MN10300_USE_EXT_EEPROM
+
+
+#define SMSC911X_BASE 0xA8000000UL
+#define SMSC911X_BASE_END 0xA8000100UL
+#define SMSC911X_IRQ XIRQ1
+
+/*
+ * Control the FPGA PIC control regs for the SMSC911x chipset
+ */
+#undef SMSC_INITIALIZE
+#undef SMSC_CHECK_INTERRUPT
+#undef SMSC_CLEAR_INTERRUPT
+#undef SMSC_SET_INTERRUPT_MASK
+#undef SMSC_CLEAR_INTERRUPT_MASK
+
+#define SMSC_INITIALIZE() \
+do { \
+ /* release reset */ \
+ ASB2364_FPGA_REG_RESET_LAN = 0x0001; \
+ SyncExBus(); \
+} while (0)
+
+#define SMSC_CHECK_INTERRUPT() \
+do { \
+ if ((ASB2364_FPGA_REG_IRQ_LAN & 0x0001) == 0x0001) \
+ return IRQ_NONE; \
+} while (0)
+
+#define SMSC_CLEAR_INTERRUPT() \
+do { \
+ ASB2364_FPGA_REG_IRQ_LAN = 0x0001; \
+ SyncExBus(); \
+} while (0)
+
+#define SMSC_SET_INTERRUPT_MASK() \
+do { \
+ ASB2364_FPGA_REG_MASK_LAN = 0x0001; \
+ SyncExBus(); \
+} while (0)
+
+#define SMSC_CLEAR_INTERRUPT_MASK() \
+do { \
+ ASB2364_FPGA_REG_MASK_LAN = 0x0000; \
+ SyncExBus(); \
+} while (0)
+
+
+#ifdef MN10300_USE_EXT_EEPROM
+#include <linux/delay.h>
+#include <unit/clock.h>
+
+#define EEPROM_ADDRESS 0xA0
+#define MAC_OFFSET 0x0008
+#define USE_IIC_CH 0 /* 0 or 1 */
+#define IIC_OFFSET (0x80000 * USE_IIC_CH)
+#define IIC_DTRM __SYSREG(0xd8400000 + IIC_OFFSET, u32)
+#define IIC_DREC __SYSREG(0xd8400004 + IIC_OFFSET, u32)
+#define IIC_MYADD __SYSREG(0xd8400008 + IIC_OFFSET, u32)
+#define IIC_CLK __SYSREG(0xd840000c + IIC_OFFSET, u32)
+#define IIC_BRST __SYSREG(0xd8400010 + IIC_OFFSET, u32)
+#define IIC_HOLD __SYSREG(0xd8400014 + IIC_OFFSET, u32)
+#define IIC_BSTS __SYSREG(0xd8400018 + IIC_OFFSET, u32)
+#define IIC_ICR __SYSREG(0xd4000080 + 4 * USE_IIC_CH, u16)
+
+#define IIC_CLK_PLS ((unsigned short)(MN10300_IOCLK / 100000 - 1))
+#define IIC_CLK_LOW ((unsigned short)(IIC_CLK_PLS / 2))
+
+#define SYS_IIC_DTRM_Bit_STA ((unsigned short)0x0400)
+#define SYS_IIC_DTRM_Bit_STO ((unsigned short)0x0200)
+#define SYS_IIC_DTRM_Bit_ACK ((unsigned short)0x0100)
+#define SYS_IIC_DTRM_Bit_DATA ((unsigned short)0x00FF)
+
+static inline void POLL_INT_REQ(volatile u16 *icr)
+{
+ unsigned long flags;
+ u16 tmp;
+
+ while (!(*icr & GxICR_REQUEST))
+ ;
+ flags = arch_local_cli_save();
+ tmp = *icr;
+ *icr = (tmp & GxICR_LEVEL) | GxICR_DETECT;
+ tmp = *icr;
+ arch_local_irq_restore(flags);
+}
+
+#undef smsc_get_mac
+static inline int smsc_get_mac(struct net_device *dev)
+{
+ unsigned char *mac_buf = dev->dev_addr;
+ int i;
+ unsigned short value;
+ unsigned int data;
+ int mac_length = 6;
+ int check;
+ u16 orig_gicr, tmp;
+ unsigned long flags;
+
+ /* save original GnICR and clear GnICR.IE */
+ flags = arch_local_cli_save();
+ orig_gicr = IIC_ICR;
+ IIC_ICR = orig_gicr & GxICR_LEVEL;
+ tmp = IIC_ICR;
+ arch_local_irq_restore(flags);
+
+ IIC_MYADD = 0x00000008;
+ IIC_CLK = (IIC_CLK_LOW << 16) + (IIC_CLK_PLS);
+ /* bus hung recovery */
+
+ while (1) {
+ check = 0;
+ for (i = 0; i < 3; i++) {
+ if ((IIC_BSTS & 0x00000003) == 0x00000003)
+ check++;
+ udelay(3);
+ }
+
+ if (check == 3) {
+ IIC_BRST = 0x00000003;
+ break;
+ } else {
+ for (i = 0; i < 3; i++) {
+ IIC_BRST = 0x00000002;
+ udelay(8);
+ IIC_BRST = 0x00000003;
+ udelay(8);
+ }
+ }
+ }
+
+ IIC_BRST = 0x00000002;
+ IIC_BRST = 0x00000003;
+
+ value = SYS_IIC_DTRM_Bit_STA | SYS_IIC_DTRM_Bit_ACK;
+ value |= (((unsigned short)EEPROM_ADDRESS & SYS_IIC_DTRM_Bit_DATA) |
+ (unsigned short)0x0000);
+ IIC_DTRM = value;
+ POLL_INT_REQ(&IIC_ICR);
+
+ /** send offset of MAC address in EEPROM **/
+ IIC_DTRM = (unsigned char)((MAC_OFFSET & 0xFF00) >> 8);
+ POLL_INT_REQ(&IIC_ICR);
+
+ IIC_DTRM = (unsigned char)(MAC_OFFSET & 0x00FF);
+ POLL_INT_REQ(&IIC_ICR);
+
+ udelay(1000);
+
+ value = SYS_IIC_DTRM_Bit_STA;
+ value |= (((unsigned short)EEPROM_ADDRESS & SYS_IIC_DTRM_Bit_DATA) |
+ (unsigned short)0x0001);
+ IIC_DTRM = value;
+ POLL_INT_REQ(&IIC_ICR);
+
+ IIC_DTRM = 0x00000000;
+ while (mac_length > 0) {
+ POLL_INT_REQ(&IIC_ICR);
+
+ data = IIC_DREC;
+ mac_length--;
+ if (mac_length == 0)
+ value = 0x00000300; /* stop IIC bus */
+ else if (mac_length == 1)
+ value = 0x00000100; /* no ack */
+ else
+ value = 0x00000000; /* ack */
+ IIC_DTRM = value;
+ *mac_buf++ = (unsigned char)(data & 0xff);
+ }
+
+ /* restore GnICR.LV and GnICR.IE */
+ flags = arch_local_cli_save();
+ IIC_ICR = (orig_gicr & (GxICR_LEVEL | GxICR_ENABLE));
+ tmp = IIC_ICR;
+ arch_local_irq_restore(flags);
+
+ return 0;
+}
+#endif /* MN10300_USE_EXT_EEPROM */
+#endif /* _ASM_UNIT_SMSC911X_H */
diff --git a/arch/mn10300/unit-asb2364/smsc911x.c b/arch/mn10300/unit-asb2364/smsc911x.c
new file mode 100644
index 0000000..544a73e
--- /dev/null
+++ b/arch/mn10300/unit-asb2364/smsc911x.c
@@ -0,0 +1,58 @@
+/* Specification for the SMSC911x NIC
+ *
+ * Copyright (C) 2006 Matsushita Electric Industrial Co., Ltd.
+ * All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/smsc911x.h>
+#include <unit/smsc911x.h>
+
+static struct smsc911x_platform_config smsc911x_config = {
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
+ .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
+ .flags = SMSC911X_USE_32BIT,
+};
+
+static struct resource smsc911x_resources[] = {
+ [0] = {
+ .start = SMSC911X_BASE,
+ .end = SMSC911X_BASE_END,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = SMSC911X_IRQ,
+ .end = SMSC911X_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device smsc911x_device = {
+ .name = "smsc911x",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(smsc911x_resources),
+ .resource = smsc911x_resources,
+ .dev = {
+ .platform_data = &smsc911x_config,
+ }
+};
+
+/*
+ * add platform devices
+ */
+static int __init unit_device_init(void)
+{
+ platform_device_register(&smsc911x_device);
+ return 0;
+}
+
+device_initcall(unit_device_init);
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 86fe67f..9334539 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1041,7 +1041,7 @@ config SMC911X
tristate "SMSC LAN911[5678] support"
select CRC32
select MII
- depends on ARM || SUPERH
+ depends on ARM || SUPERH || MN10300
help
This is a driver for SMSC's LAN911x series of Ethernet chipsets
including the new LAN9115, LAN9116, LAN9117, and LAN9118.
@@ -1055,7 +1055,7 @@ config SMC911X
config SMSC911X
tristate "SMSC LAN911x/LAN921x families embedded ethernet support"
- depends on ARM || SUPERH || BLACKFIN || MIPS
+ depends on ARM || SUPERH || BLACKFIN || MIPS || MN10300
select CRC32
select MII
select PHYLIB
@@ -1067,6 +1067,14 @@ config SMSC911X
<file:Documentation/networking/net-modules.txt>. The module
will be called smsc911x.
+config SMSC911X_ARCH_HOOKS
+ def_bool n
+ depends on SMSC911X
+ help
+ If the arch enables this, it allows the arch to implement various
+ hooks for more comprehensive interrupt control and also to override
+ the source of the MAC address.
+
config NET_VENDOR_RACAL
bool "Racal-Interlan (Micom) NI cards"
depends on ISA
diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c
index a8e5856..54b55c1 100644
--- a/drivers/net/smsc911x.c
+++ b/drivers/net/smsc911x.c
@@ -1456,6 +1456,7 @@ static irqreturn_t smsc911x_irqhandler(int irq, void *dev_id)
int serviced = IRQ_NONE;
u32 temp;
+ SMSC_CHECK_INTERRUPT();
if (unlikely(intsts & inten & INT_STS_SW_INT_)) {
temp = smsc911x_reg_read(pdata, INT_EN);
temp &= (~INT_EN_SW_INT_EN_);
@@ -1506,6 +1507,7 @@ static irqreturn_t smsc911x_irqhandler(int irq, void *dev_id)
serviced = IRQ_HANDLED;
}
+ SMSC_CLEAR_INTERRUPT();
return serviced;
}
@@ -1931,6 +1933,7 @@ static int __devexit smsc911x_drv_remove(struct platform_device *pdev)
platform_set_drvdata(pdev, NULL);
unregister_netdev(dev);
+ SMSC_SET_INTERRUPT_MASK();
free_irq(dev->irq, dev);
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
"smsc911x-memory");
@@ -2042,6 +2045,7 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
"Unable to claim requested irq: %d", dev->irq);
goto out_unmap_io_3;
}
+ SMSC_CLEAR_INTERRUPT_MASK();
platform_set_drvdata(pdev, dev);
@@ -2075,7 +2079,7 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
} else {
/* Try reading mac address from device. if EEPROM is present
* it will already have been set */
- smsc911x_read_mac_address(dev);
+ smsc_get_mac(dev);
if (is_valid_ether_addr(dev->dev_addr)) {
/* eeprom values are valid so use them */
@@ -2176,6 +2180,7 @@ static struct platform_driver smsc911x_driver = {
/* Entry point for loading the module */
static int __init smsc911x_init_module(void)
{
+ SMSC_INITIALIZE();
return platform_driver_register(&smsc911x_driver);
}
diff --git a/drivers/net/smsc911x.h b/drivers/net/smsc911x.h
index 016360c..14a7087 100644
--- a/drivers/net/smsc911x.h
+++ b/drivers/net/smsc911x.h
@@ -394,4 +394,21 @@
#define LPA_PAUSE_ALL (LPA_PAUSE_CAP | \
LPA_PAUSE_ASYM)
+/*
+ * Provide hooks to let the arch implement more comprehensive interrupt control
+ * and to override the source of the MAC address.
+ */
+#define SMSC_INITIALIZE() do {} while (0)
+#define SMSC_CHECK_INTERRUPT() do {} while (0)
+#define SMSC_CLEAR_INTERRUPT() do {} while (0)
+#define SMSC_SET_INTERRUPT_MASK() do {} while (0)
+#define SMSC_CLEAR_INTERRUPT_MASK() do {} while (0)
+#define smsc_get_mac(dev) smsc911x_read_mac_address((dev))
+
+#ifdef CONFIG_SMSC911X_ARCH_HOOKS
+#include <asm/smsc911x.h>
+#endif
+
+
+
#endif /* __SMSC911X_H__ */
^ permalink raw reply related
* Re: [PATCH] Add support for new VLAN acceleration model
From: David Dillow @ 2010-10-26 2:48 UTC (permalink / raw)
To: Jesse Gross; +Cc: netdev, jgarzik, davem
In-Reply-To: <AANLkTi=kYH2NLMChuzd=OF6TPyn8FPJaRLfBg7z1gcYq@mail.gmail.com>
On Mon, 2010-10-25 at 19:22 -0700, Jesse Gross wrote:
> On Sun, Oct 24, 2010 at 1:24 PM, David Dillow <dave@thedillows.org> wrote:
> > Signed-off-by: David Dillow <dave@thedillows.org>
> > ---
> > I used this during testing of the typhoon conversion.
>
> Oops, I have a nearly identical patch that I should have sent out
> earlier to make everyone's lives easier.
Would have saved me a few minutes, but don't sweat it -- it took me
forever to figure out that my WRT54G was stripping VLAN tags, making it
look like the driver had been broken for quite some time...
As for the credit, I'm not at all concerned; I think I like your patch
better anyway.
^ permalink raw reply
* [PATCH 02/10] drivers/atm/eni.c: Remove multiple uses of KERN_<level>
From: Joe Perches @ 2010-10-26 2:44 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Chas Williams, linux-atm-general, netdev, linux-kernel
In-Reply-To: <cover.1288059486.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/atm/eni.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c
index 80f9f36..97c5898 100644
--- a/drivers/atm/eni.c
+++ b/drivers/atm/eni.c
@@ -1736,9 +1736,10 @@ static int __devinit eni_do_init(struct atm_dev *dev)
eprom = (base+EPROM_SIZE-sizeof(struct midway_eprom));
if (readl(&eprom->magic) != ENI155_MAGIC) {
printk("\n");
- printk(KERN_ERR KERN_ERR DEV_LABEL "(itf %d): bad "
- "magic - expected 0x%x, got 0x%x\n",dev->number,
- ENI155_MAGIC,(unsigned) readl(&eprom->magic));
+ printk(KERN_ERR DEV_LABEL
+ "(itf %d): bad magic - expected 0x%x, got 0x%x\n",
+ dev->number, ENI155_MAGIC,
+ (unsigned)readl(&eprom->magic));
error = -EINVAL;
goto unmap;
}
--
1.7.3.dirty
^ permalink raw reply related
* [PATCH 00/10] Remove multiple uses of KERN_<level>
From: Joe Perches @ 2010-10-26 2:44 UTC (permalink / raw)
To: Jiri Kosina
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
x86-DgEjT+Ai2ygdnm+yROfE0A, Chas Williams, Jiri Kosina,
Tom Tucker, Steve Wise, Roland Dreier, Sean Hefty, Hal Rosenstock,
Alessandro Rubini, Dmitry Torokhov, Mauro Carvalho Chehab,
James E.J. Bottomley, David Brown, Daniel Walker, Bryan Huntsman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-atm-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, linux-s
Found using strings vmlinux | grep "^<.>.*<.>"
and a couple of other cleanups of logging message format strings.
Joe Perches (10):
arch/x86/kernel/apic/io_apic.c: Typo fix WARNING
drivers/atm/eni.c: Remove multiple uses of KERN_<level>
drivers/hid/hid-input.c: Remove KERN_DEBUG from dbg_hid use
drivers/infiniband: Remove unnecessary KERN_<level> uses
drivers/input/mouse/appletouch.c: Remove KERN_DEBUG use from dprintk
drivers/input/serio/i8042: Use pr_<level>, pr_fmt. Fix dbg and __FILE__ use
drivers/media: Removed unnecessary KERN_<level>s from dprintk uses
drivers/scsi:mvsas/mv_sas.c: Remove KERN_DEBUG from mv_dprintk use
drivers/video/msm/mddi.c: Remove multiple KERN_<level> uses
fs/proc/vmcore.c: Use pr_<level> and pr_<fmt>
arch/x86/kernel/apic/io_apic.c | 2 +-
drivers/atm/eni.c | 7 +-
drivers/hid/hid-input.c | 2 +-
drivers/infiniband/hw/amso1100/c2_intr.c | 4 +-
drivers/infiniband/hw/cxgb3/iwch_cm.c | 4 +-
drivers/infiniband/hw/cxgb4/cm.c | 4 +-
drivers/input/mouse/appletouch.c | 2 +-
drivers/input/serio/i8042.c | 94 ++++++++++++-------------
drivers/input/serio/i8042.h | 19 +++--
drivers/media/common/tuners/max2165.c | 10 +--
drivers/media/dvb/frontends/atbm8830.c | 8 +--
drivers/media/dvb/frontends/lgs8gxx.c | 11 +--
drivers/media/video/saa7134/saa7134-input.c | 2 +-
drivers/media/video/saa7134/saa7134-tvaudio.c | 12 ++--
drivers/scsi/mvsas/mv_sas.c | 2 +-
drivers/video/msm/mddi.c | 5 +-
fs/proc/vmcore.c | 16 ++---
17 files changed, 97 insertions(+), 107 deletions(-)
--
1.7.3.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* [PATCH] ethtool: Add support for vlan accleration.
From: Jesse Gross @ 2010-10-26 2:22 UTC (permalink / raw)
To: jgarzik; +Cc: netdev
The kernel now has support for enabling and disabling vlan
acceleration, similar to other forms of offloading. This
adds the complementary userspace support.
Signed-off-by: Jesse Gross <jesse@nicira.com>
---
ethtool-copy.h | 2 ++
ethtool.8 | 8 ++++++++
ethtool.c | 21 ++++++++++++++++++---
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 894f1da..557425e 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -308,6 +308,8 @@ struct ethtool_perm_addr {
* flag differs from the read-only value.
*/
enum ethtool_flags {
+ ETH_FLAG_TXVLAN = (1 << 7), /* TX VLAN offload enabled */
+ ETH_FLAG_RXVLAN = (1 << 8), /* RX VLAN offload enabled */
ETH_FLAG_LRO = (1 << 15), /* LRO is enabled */
ETH_FLAG_NTUPLE = (1 << 27), /* N-tuple filters enabled */
ETH_FLAG_RXHASH = (1 << 28),
diff --git a/ethtool.8 b/ethtool.8
index 3ca403c..7801797 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -170,6 +170,8 @@ ethtool \- Display or change ethernet card settings
.B2 gso on off
.B2 gro on off
.B2 lro on off
+.B2 rxvlan on off
+.B2 txvlan on off
.B2 rxhash on off
.B ethtool \-p|\-\-identify
@@ -377,6 +379,12 @@ Specifies whether generic receive offload should be enabled
.A2 lro on off
Specifies whether large receive offload should be enabled
.TP
+.A2 rxvlan on off
+Specifies whether RX VLAN acceleration should be enabled
+.TP
+.A2 txvlan on off
+Specifies whether TX VLAN acceleration should be enabled
+.TP
.A2 rxhash on off
Specifies whether receive hashing offload should be enabled
.TP
diff --git a/ethtool.c b/ethtool.c
index 6b2b7c8..3d24d58 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -200,6 +200,8 @@ static struct option {
" [ gso on|off ]\n"
" [ gro on|off ]\n"
" [ lro on|off ]\n"
+ " [ rxvlan on|off ]\n"
+ " [ txvlan on|off ]\n"
" [ ntuple on|off ]\n"
" [ rxhash on|off ]\n"
},
@@ -435,6 +437,10 @@ static struct cmdline_info cmdline_offload[] = {
{ "lro", CMDL_FLAG, &off_flags_wanted, NULL,
ETH_FLAG_LRO, &off_flags_unwanted },
{ "gro", CMDL_BOOL, &off_gro_wanted, NULL },
+ { "rxvlan", CMDL_FLAG, &off_flags_wanted, NULL,
+ ETH_FLAG_RXVLAN, &off_flags_unwanted },
+ { "txvlan", CMDL_FLAG, &off_flags_wanted, NULL,
+ ETH_FLAG_TXVLAN, &off_flags_unwanted },
{ "ntuple", CMDL_FLAG, &off_flags_wanted, NULL,
ETH_FLAG_NTUPLE, &off_flags_unwanted },
{ "rxhash", CMDL_FLAG, &off_flags_wanted, NULL,
@@ -1732,7 +1738,8 @@ static int dump_coalesce(void)
}
static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
- int gro, int lro, int ntuple, int rxhash)
+ int gro, int lro, int rxvlan, int txvlan, int ntuple,
+ int rxhash)
{
fprintf(stdout,
"rx-checksumming: %s\n"
@@ -1743,6 +1750,8 @@ static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
"generic-segmentation-offload: %s\n"
"generic-receive-offload: %s\n"
"large-receive-offload: %s\n"
+ "rx-vlan-offload: %s\n"
+ "tx-vlan-offload: %s\n"
"ntuple-filters: %s\n"
"receive-hashing: %s\n",
rx ? "on" : "off",
@@ -1753,6 +1762,8 @@ static int dump_offload(int rx, int tx, int sg, int tso, int ufo, int gso,
gso ? "on" : "off",
gro ? "on" : "off",
lro ? "on" : "off",
+ rxvlan ? "on" : "off",
+ txvlan ? "on" : "off",
ntuple ? "on" : "off",
rxhash ? "on" : "off");
@@ -2075,7 +2086,8 @@ static int do_goffload(int fd, struct ifreq *ifr)
{
struct ethtool_value eval;
int err, allfail = 1, rx = 0, tx = 0, sg = 0;
- int tso = 0, ufo = 0, gso = 0, gro = 0, lro = 0, ntuple = 0, rxhash = 0;
+ int tso = 0, ufo = 0, gso = 0, gro = 0, lro = 0, rxvlan = 0, txvlan = 0,
+ ntuple = 0, rxhash = 0;
fprintf(stdout, "Offload parameters for %s:\n", devname);
@@ -2146,6 +2158,8 @@ static int do_goffload(int fd, struct ifreq *ifr)
perror("Cannot get device flags");
} else {
lro = (eval.data & ETH_FLAG_LRO) != 0;
+ rxvlan = (eval.data & ETH_FLAG_RXVLAN) != 0;
+ txvlan = (eval.data & ETH_FLAG_TXVLAN) != 0;
ntuple = (eval.data & ETH_FLAG_NTUPLE) != 0;
rxhash = (eval.data & ETH_FLAG_RXHASH) != 0;
allfail = 0;
@@ -2166,7 +2180,8 @@ static int do_goffload(int fd, struct ifreq *ifr)
return 83;
}
- return dump_offload(rx, tx, sg, tso, ufo, gso, gro, lro, ntuple, rxhash);
+ return dump_offload(rx, tx, sg, tso, ufo, gso, gro, lro, rxvlan, txvlan,
+ ntuple, rxhash);
}
static int do_soffload(int fd, struct ifreq *ifr)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Add support for new VLAN acceleration model
From: Jesse Gross @ 2010-10-26 2:22 UTC (permalink / raw)
To: David Dillow; +Cc: netdev, jgarzik, davem
In-Reply-To: <1287951880-25321-1-git-send-email-dave@thedillows.org>
On Sun, Oct 24, 2010 at 1:24 PM, David Dillow <dave@thedillows.org> wrote:
> Signed-off-by: David Dillow <dave@thedillows.org>
> ---
> I used this during testing of the typhoon conversion.
Oops, I have a nearly identical patch that I should have sent out
earlier to make everyone's lives easier. The only differences in mine
are some man page updates and grouping the vlan settings a little more
closely with the other forms of offloading (as opposed to
filtering/hashing). I guess I'll post my version as well (since we
should at least be sure to update the man page) in case that is more
convenient. I don't mean to steal the credit though.
^ permalink raw reply
* [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Lorenzo Colitti @ 2010-10-26 2:08 UTC (permalink / raw)
To: netdev
When roaming between different networks (e.g., changing wireless
SSIDs, or plugging in to different wired networks), IPv6 addresses and
routes are not cleared. If the two networks have different IPv6
subnets assigned, the host maintains both the old and new IPv6
addresses and gateways, but only the new ones works. If the host
chooses the wrong source address or gateway, or if the new network
does not have IPv6 but the old one did, IPv6 connections time out,
leading to long delays when trying to connect to IPv6 hosts.
Fix this by ensuring that autoconfigured IPv6 addresses and routes are
purged when link is lost, not only when the interface goes down.
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
--- a/net/ipv6/addrconf.c 2010-10-20 13:30:22.000000000 -0700
+++ b/net/ipv6/addrconf.c 2010-10-25 13:55:15.000000000 -0700
@@ -2524,6 +2524,14 @@
} else {
if (!addrconf_qdisc_ok(dev)) {
/* device is still not ready. */
+ if (idev && (idev->if_flags & IF_READY)) {
+ /* Link lost. Clear addresses and
+ routes, the device might come back
+ on a link where they are no longer
+ valid. */
+ addrconf_ifdown(dev, 0);
+ idev->if_flags &= ~IF_READY;
+ }
break;
}
^ permalink raw reply
* Re: [PATCH] Enhance AF_PACKET implementation to not require high order contiguous memory allocation
From: Neil Horman @ 2010-10-26 1:58 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, jpirko
In-Reply-To: <20101025.164646.104054845.davem@davemloft.net>
On Mon, Oct 25, 2010 at 04:46:46PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Mon, 25 Oct 2010 19:35:58 -0400
>
> > On Tue, Oct 26, 2010 at 12:30:56AM +0200, Eric Dumazet wrote:
> >> I would try a two level thing : Try to get high order pages, and
> >> fallback on low order pages, but normally libpcap does this for us ?
> >>
> >>
> > It does, but it tries them in that order, which causes the problem I'm
> > describing, which is to say that attempting to get a large high order allocation
> > causes the system to dig into swap and become unresponsive while it tries to
> > assemble those allocations. I would suggest a vmalloc, with a backoff to high
> > order allocation if that fails.
>
> I think that logic should be maintained, except that one of the GFP_*
> flags should be specified so that it doesn't go all swap crazy on us,
> and instead fails a high order allocation earlier.
>
I suppose we can do that. Specifically we can add __GFP_NORETRY so that we
don't continually drive I/O or swap to get pages freed, but I think that all
that will result in is earlier failures. No matter how you look at it, order 4
allocations are hard to come by, and we can make it work with non-contigous
pages (the vmalloc case). Given that each of the cases can fail, I can see this
being a workable fallback set:
1) get_free_pages (GFP_KERNEL|...+|__GFP_NORETRY)
2) vmalloc
3) get_free_pages (GFP_KERNEL|...)
Theres no reason to fail af_packet socket options just because the system is
under presure. My only concern is that, since af_packet is typically used for
debugging/tracing, I'd rather not have its memory allocation adversely affect
system behavio.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH 1/5] netdev: bfin_mac: push settings to platform resources
From: Mike Frysinger @ 2010-10-26 1:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <AANLkTik6C2tbir0hKJJ2kErha-JJD_yx927qw=3t7=Xu@mail.gmail.com>
On Sun, Oct 24, 2010 at 19:51, Mike Frysinger wrote:
> On Sun, Oct 24, 2010 at 19:45, David Miller wrote:
>> From: Mike Frysinger
>>> and i have the Blackfin changes waiting for you to merge this patch.
>>> i can squash them into this change and have you merge the result, or i
>>> can merge it. i dont really care either way.
>>
>> Why don't you just apply this to your tree then. Feel free to add my:
>
> thanks, i'll do that
Linus has taken this via my tree now. are you going to merge the
other patches ? or do i need to resend them ?
-mike
^ permalink raw reply
* Re: [PATCH] Enhance AF_PACKET implementation to not require high order contiguous memory allocation
From: Neil Horman @ 2010-10-26 1:53 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: David Miller, eric.dumazet, netdev, jpirko
In-Reply-To: <AANLkTinxe7M-_bHdhA-jrW2gBtGLCXkBasSPi7RaFDi-@mail.gmail.com>
On Mon, Oct 25, 2010 at 05:48:33PM -0700, Maciej Żenczykowski wrote:
> This is http://bugzilla.redhat.com/637619
>
> I'm the original reporter and I haven't yet fully vetted / tested the
> patch (not directly related to my job and all that).
>
I validated it. You reported that tcpdump startup caused your system to
'freeze'. I managed to recreate that situation, as observed by my system
becomming unresponsive on the console, and validated that that situation did not
occur when this patch was applied.
Neil
^ permalink raw reply
* Re: [PATCH 2.6.36/stable] vlan: Fix crash when hwaccel rx pkt for non-existant vlan.
From: Jesse Gross @ 2010-10-26 1:51 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <1288047166-5660-1-git-send-email-greearb@candelatech.com>
On Mon, Oct 25, 2010 at 3:52 PM, Ben Greear <greearb@candelatech.com> wrote:
> diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> index 0eb96f7..2883d0e 100644
> --- a/net/8021q/vlan_core.c
> +++ b/net/8021q/vlan_core.c
> @@ -43,10 +43,16 @@ int vlan_hwaccel_do_receive(struct sk_buff *skb)
> struct net_device *dev = skb->dev;
> struct vlan_rx_stats *rx_stats;
>
> - skb->dev = vlan_dev_info(dev)->real_dev;
> - netif_nit_deliver(skb);
> + if (is_vlan_dev(dev)) {
> + skb->dev = vlan_dev_info(dev)->real_dev;
> + netif_nit_deliver(skb);
> + skb->dev = dev;
> + } else {
> + netif_nit_deliver(skb);
> + skb->pkt_type = PACKET_OTHERHOST;
> + return 0;
> + }
Neither setting skb->pkt_type nor calling netif_nit_deliver() should
be necessary here. The former is done on receive if there is no
matching device and the latter happens later on in
__netif_receive_skb(). So you should just be able to do:
if (!is_vlan_dev(dev))
return 0;
One potentially bad outcome of this approach is that other components
like bridging can start to pick up packets with vlan tags in
skb->vlan_tci. However, in 2.6.36 it isn't able to do filtering on
them and the NIC on the output side may not be able to handle the tag
in the skb. It's probably not common to have both bridging and a vlan
group on the same device but you'll get into some weird situations if
you do.
Once you start solving these issues you end up with more invasive
changes that look like the implementation in 2.6.37. Since we don't
want to pull all of that in, it might just be best to deliver the
packet to network taps and then drop it. That was the original reason
for allowing vlan packets with no device this far into the stack.
^ permalink raw reply
* Re: [net-next PATCH 1/3] qlge: Restoring the vlan setting.
From: Jesse Gross @ 2010-10-26 0:56 UTC (permalink / raw)
To: David Miller, netdev@vger.kernel.org, Jitendra Kalsaria,
Ying Ping Lok
In-Reply-To: <20101025194632.GA3545@linux-ox1b.qlogic.org>
On Mon, Oct 25, 2010 at 12:46 PM, Ron Mercer <ron.mercer@qlogic.com> wrote:
> +static void qlge_restore_vlan(struct ql_adapter *qdev)
> +{
> + qlge_vlan_rx_register(qdev->ndev, qdev->vlgrp);
> +
> + if (qdev->vlgrp) {
> + u16 vid;
> + for (vid = 0; vid < VLAN_N_VID; vid++) {
> + if (!vlan_group_get_device(qdev->vlgrp, vid))
> + continue;
> + qlge_vlan_rx_add_vid(qdev->ndev, vid);
> + }
> + }
> +}
Using vlan groups within a driver is now deprecated. I realize that
this is just a bug fix but it would nice if we can avoid introducing
more code around vlan groups. Of course, fully switching the driver
over to use the new vlan model would be even nicer.
^ permalink raw reply
* Re: [PATCH] Enhance AF_PACKET implementation to not require high order contiguous memory allocation
From: Maciej Żenczykowski @ 2010-10-26 0:48 UTC (permalink / raw)
To: David Miller; +Cc: nhorman, eric.dumazet, netdev, jpirko
In-Reply-To: <20101025.164646.104054845.davem@davemloft.net>
This is http://bugzilla.redhat.com/637619
I'm the original reporter and I haven't yet fully vetted / tested the
patch (not directly related to my job and all that).
^ permalink raw reply
* Re: VLAN packets silently dropped in promiscuous mode
From: Jesse Gross @ 2010-10-26 0:40 UTC (permalink / raw)
To: Guillaume Gaudonville; +Cc: Roger Luethi, netdev, Patrick McHardy
In-Reply-To: <4CC58AB9.4090903@6wind.com>
On Mon, Oct 25, 2010 at 6:48 AM, Guillaume Gaudonville
<guillaume.gaudonville@6wind.com> wrote:
> Jesse Gross wrote:
>>
>> On Fri, Oct 15, 2010 at 2:16 AM, Guillaume Gaudonville
>> <guillaume.gaudonville@6wind.com> wrote:
>>
>>>
>>> Jesse Gross wrote:
>>>
>>>>
>>>> On Thu, Sep 30, 2010 at 1:07 AM, Roger Luethi <rl@hellgate.ch> wrote:
>>>>
>>>>
>>>>>
>>>>> On Wed, 29 Sep 2010 10:44:26 -0700, Jesse Gross wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Wed, Sep 29, 2010 at 4:37 AM, Roger Luethi <rl@hellgate.ch> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I noticed packets for unknown VLANs getting silently dropped even in
>>>>>>> promiscuous mode (this is true only for the hardware accelerated
>>>>>>> path).
>>>>>>> netif_nit_deliver was introduced specifically to prevent that, but
>>>>>>> the
>>>>>>> function gets called only _after_ packets from unknown VLANs have
>>>>>>> been
>>>>>>> dropped.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Some drivers are fixing this on a case by case basis by disabling
>>>>>> hardware accelerated VLAN stripping when in promiscuous mode, i.e.:
>>>>>>
>>>>>>
>>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5f6c01819979afbfec7e0b15fe52371b8eed87e8
>>>>>>
>>>>>> However, at this point it is more or less random which drivers do
>>>>>> this. It would obviously be much better if it were consistent.
>>>>>>
>>>>>>
>>>>>
>>>>> My understanding is this. Hardware VLAN tagging and stripping can
>>>>> always
>>>>> be
>>>>> enabled. The kernel passes 802.1Q information along with the stripped
>>>>> header to libpcap which reassembles the original header where
>>>>> necessary.
>>>>> Works for me.
>>>>>
>>>>>
>>>>
>>>> Sorry, I misread your original post as saying that the VLAN header
>>>> gets dropped, rather than the entire packet. I agree that this is how
>>>> it should work but not necessarily how it does work (again, depending
>>>> on the driver). Here's the problem that I was talking about:
>>>>
>>>> Most drivers have a snippet of code that looks something like this
>>>> (taken from ixgbe):
>>>>
>>>> if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
>>>> vlan_gro_receive(napi, adapter->vlgrp, tag, skb);
>>>> else
>>>> napi_gro_receive(napi, skb);
>>>>
>>>> At this point the VLAN has already been stripped in hardware. If
>>>> there is no VLAN group configured on the device then we hit the second
>>>> case. The VLAN header was removed from the SKB and the tag variable
>>>> is unused. It is no longer possible for libpcap to reconstruct the
>>>> header because the information was thrown away (even the fact that
>>>> there was a VLAN tag at all).
>>>>
>>>> There are a couple ways to fix this:
>>>>
>>>> * Turn off VLAN stripping when in promiscuous mode (as done by the ixgbe
>>>> driver)
>>>>
>>>>
>>>
>>> This is not totally true: if changing the MTU ixgbe_change_mtu will call:
>>> ixgbe_reinit_locked--> ixgbe_up --> ixgbe_configure:
>>> --> ixgbe_set_rx_mode: flag IFF_PROMISC is tested
>>> ixgbe_vlan_filter_enable is not called
>>> --> ixgbe_restore_vlan --> ixgbe_vlan_rx_register: flag
>>> IFF_PROMISC is not tested ixgbe_vlan_filter_enable
>>> will be called.
>>>
>>> In fact it should happen each time we configure something which needs a
>>> reset of the device. Why don't add a test
>>> on flag promiscuous directly in ixgbe_vlan_filter_enable? Or do it on
>>> each
>>> call, if we want to allow a device in promiscuous
>>> mode to enable this feature.
>>>
>>> What do you think?
>>>
>>
>> I can believe that there are paths that lead to this not working
>> correctly. That was actually my larger point: this is something that
>> is commonly not implemented correctly in drivers. Rather than try to
>> study every driver my goal is to just avoid the problem completely by
>> handling vlan acceleration centrally in the networking core. I sent
>> out an RFC patch series a few days ago that should solve this problem:
>>
>> http://marc.info/?l=linux-netdev&m=128700022614170&w=3
>> --
>> 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
>>
>
> Thank you, I'm going to check these patches and try to apply them in our
> kernel.
An updated set of patches has been merged into net-2.6, so you might
want to try that instead.
^ permalink raw reply
* Re: [PATCH v2 11/14] bnx2x: Update bnx2x to use new vlan accleration.
From: Jesse Gross @ 2010-10-26 0:29 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: David Miller, netdev@vger.kernel.org, Hao Zheng, Eilon Greenstein
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDEE6B1203@SJEXCHCCR02.corp.ad.broadcom.com>
On Sun, Oct 24, 2010 at 3:11 AM, Vladislav Zolotarov <vladz@broadcom.com> wrote:
>
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Vladislav Zolotarov
>> Sent: Sunday, October 24, 2010 11:22 AM
>> To: Jesse Gross
>> Cc: David Miller; netdev@vger.kernel.org; Hao Zheng; Eilon Greenstein
>> Subject: RE: [PATCH v2 11/14] bnx2x: Update bnx2x to use new vlan
>> accleration.
>>
>>
>>
>> > >
>> > > We hit the same BUG() both when VLAN stripping is disabled.
>> >
>> > This one surprises me because that function shouldn't get called at
>> > all when VLAN stripping is disabled. Are you sure that it is
>> > disabled? From my reading of the bnx2x driver it seems like it is
>> > always enabled.
>>
>> I tried to check all possibilities and to check at which level the
>> problem is,
>> so I patched the bnx2x not to do the stripping and recompiled it with
>> the
>> kernel having CONFIG_VLAN_8021Q disabled. Then I saw the (same) BUG()
>> message
>> again. It seems to me that your patch series were meant to remove the
>> handling of this configuration (CONFIG_VLAN_8021Q) from the L2 drivers
>> as well, isn't it? This means that the same VLAN flows, both
>> accelerated and none
>> accelerated should be "active" both when this configuration is present
>> and
>> when it's not... Do I get it right?
>>
>> Thanks,
>> vlad
>
> Jesse, from the fix u posted I conclude that the answer on the above questions is
> obviously "yes"... ;)
Yes, that's right.
>
> I first answered your question and only then looked at the "fixing"
> thread, my apologies... ;)
Even though the fix prevents the panic, I'm still a little concerned
that you ran into it at all when vlan stripping was disabled. That
function should only be called when a tag was received by the card.
Is it possible that __vlan_hwaccel_put_tag is being called even in
cases when no tag was stripped? Maybe we made a mistake when
converting the driver?
^ 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