* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Hannes Frederic Sowa @ 2013-10-06 15:13 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CABfLueFYZkzpEpDJ7YcHJaXfm-=QcgnL3-Es8gybea2cAacQQw@mail.gmail.com>
On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
> The initialization in ip6gre_tnl_link_config is done as the following:
> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
> {
> ...
> int addend = sizeof(struct ipv6hdr) + 4;
> ...
> /* Precalculate GRE options length */
> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
> if (t->parms.o_flags&GRE_CSUM)
> addend += 4;
> if (t->parms.o_flags&GRE_KEY)
> addend += 4;
> if (t->parms.o_flags&GRE_SEQ)
> addend += 4;
> }
> ...
> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
> ...
> t->hlen = addend;
> ..
> }
>
> Unless they are other reasons, the hard_header_len is taken into
> account the GRE_KEY, GRE_SEQ ..
But only if a new route is found. The hard_header_len reinitialization is
guarded by a (rt == NULL). We may have not found one on boot up.
> > To make this correct we would have to refactor the usage of the variables a
> > bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
> > check as-is currently although we exclude some allowed mtus.
> >
> > Perhaps you want to take a look how to achieve that? ;)
> >
> Why not, consistency is good ...
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Fix pages never dma unmapped on rx
From: Amir Vadai @ 2013-10-06 15:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
In-Reply-To: <1381069372.3564.68.camel@edumazet-glaptop.roam.corp.google.com>
On 06/10/2013 17:22, Eric Dumazet wrote:
> On Sun, 2013-10-06 at 14:57 +0200, Amir Vadai wrote:
>> This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
>> order-0 memory allocations in RX path).
>>
>> dma_unmap_page never reached because condition to detect last fragment
>> in page is wrong. offset+frag_stride can't be greater than size, need to
>> make sure no additional frag will fit in page => compare offset +
>> frag_stride + next_frag_size instead.
>> next_frag_size could be next frag in the same skb, or the first frag in
>> the next.
>>
>> CC: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
>> index dec455c..44d8865 100644
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
>> @@ -131,8 +131,11 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
>> int i)
>> {
>> const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
>> + u16 next_frag_end = frags[i].offset + frag_info->frag_stride;
>>
>
> Hmm, could you make this an u32 ?
>
> frags[i].offset and frags[i].size are u32
>
> Maybe some folks want to use PAGE_SIZE=65536 or whatever high order
> allocs
>
>
>> - if (frags[i].offset + frag_info->frag_stride > frags[i].size)
>> + next_frag_end += frags[(i + 1) % priv->num_frags].size;
>> +
>> + if (next_frag_end > frags[i].size)
>> dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
>> PCI_DMA_FROMDEVICE);
>>
>
> Not sure I understand how this can work. How was this tested ?
>
> frags[i + 1].size is the size of the page containing next fragment,
> so now test should _always_ trigger.
>
> (We could rename @size to @page_size to avoid confusion)
>
> I think you meant to add the size of the next fragment ?
>
> What about following instead (I also removed the divide operation)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index dec455c..22444de 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -131,10 +131,17 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
> int i)
> {
> const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
> + u32 next_frag_end = frags[i].offset + frag_info->frag_stride;
>
> - if (frags[i].offset + frag_info->frag_stride > frags[i].size)
> + frag_info++;
> + if (i + 1 == priv->num_frags)
> + frag_info = &priv->frag_info[0];
> +
> + next_frag_end += frag_info->frag_stride;
> +
> + if (next_frag_end > frags[i].size)
> dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
> - PCI_DMA_FROMDEVICE);
> + PCI_DMA_FROMDEVICE);
>
> if (frags[i].page)
> put_page(frags[i].page);
>
>
It looks good.
Will also change it into a small patchset with a new patch to rename
@size to @page_size and @offset to @page_offset.
I Will send it after I finish testing.
(Previously I had the typo added just after I removed the prints I used
while testing).
Thanks,
Amir
^ permalink raw reply
* Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
From: Ming Lei @ 2013-10-06 15:05 UTC (permalink / raw)
To: Dan Murphy
Cc: Steve Glendinning, Network Development, Linux Kernel Mailing List,
linux-usb, mugunthanvnm
In-Reply-To: <1380911156-14112-1-git-send-email-dmurphy@ti.com>
On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy <dmurphy@ti.com> wrote:
> If the smsc95xx does not have a valid MAC address stored within
> the eeprom then a random number is generated. The MAC can also
> be set by uBoot but the smsc95xx does not have a way to read this.
>
> Create the binding for the smsc95xx so that uBoot can set the MAC
> and the code can retrieve the MAC from the modified DTB file.
Suppose there are two smsc95xx usbnet devices connected to usb bus, and
one is built-in, another is hotplug device, can your patch handle the situation
correctly?
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> Documentation/devicetree/bindings/net/smsc95xx.txt | 17 ++++++++++++++
> drivers/net/usb/smsc95xx.c | 24 ++++++++++++++++++++
> 2 files changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/smsc95xx.txt
>
> diff --git a/Documentation/devicetree/bindings/net/smsc95xx.txt b/Documentation/devicetree/bindings/net/smsc95xx.txt
> new file mode 100644
> index 0000000..4c37280
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/smsc95xx.txt
> @@ -0,0 +1,17 @@
> +* Smart Mixed-Signal Connectivity (SMSC) 95xx Controller
> +
> +Required properties:
> +None
> +
> +Optional properties:
> +- mac-address - Read the mac address that was stored by uBoot
> +- local-address - Read the mac address that was stored by uBoot
> +- address - Read the mac address that was stored by uBoot
> +
> +Examples:
> +
> +smsc0: smsc95xx@0 {
> + /* Filled in by U-Boot */
> + mac-address = [ 00 00 00 00 00 00 ];
> +};
> +
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index 3f38ba8..baee0bd 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -31,6 +31,9 @@
> #include <linux/crc32.h>
> #include <linux/usb/usbnet.h>
> #include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/of_net.h>
> +
> #include "smsc95xx.h"
>
> #define SMSC_CHIPNAME "smsc95xx"
> @@ -62,6 +65,8 @@
> #define SUSPEND_ALLMODES (SUSPEND_SUSPEND0 | SUSPEND_SUSPEND1 | \
> SUSPEND_SUSPEND2 | SUSPEND_SUSPEND3)
>
> +#define SMSC95XX_OF_NAME "/smsc95xx@"
> +
> struct smsc95xx_priv {
> u32 mac_cr;
> u32 hash_hi;
> @@ -767,6 +772,25 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
>
> static void smsc95xx_init_mac_address(struct usbnet *dev)
> {
> +
> +#ifdef CONFIG_OF
> + struct device_node *ap;
> + const char *mac = NULL;
> + char *of_name = SMSC95XX_OF_NAME;
> +
> + sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
> + ap = of_find_node_by_path(of_name);
> + if (ap) {
> + mac = of_get_mac_address(ap);
> + if (is_valid_ether_addr(mac)) {
> + /* Device tree has a mac for this so use that */
> + memcpy(dev->net->dev_addr, mac, ETH_ALEN);
> + netif_dbg(dev, ifup, dev->net, "MAC address read from DTB\n");
> + return;
> + }
> + }
> +#endif
> +
> /* try reading mac address from EEPROM */
> if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
> dev->net->dev_addr) == 0) {
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Oussama Ghorbel @ 2013-10-06 14:42 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20131005140636.GA25076@order.stressinduktion.org>
On Sat, Oct 5, 2013 at 3:06 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Fri, Oct 04, 2013 at 10:52:13AM +0100, Oussama Ghorbel wrote:
>> Unlike ipv4, the struct member hlen holds the length of the GRE and ipv6
>> headers. This length is also counted in dev->hard_header_len.
>> Perhaps, it's more clean to modify the hlen to count only the GRE header
>> without ipv6 header as the variable name suggest, but the simple way to fix
>> this without regression risk is simply modify the calculation of the limit
>> in ip6gre_tunnel_change_mtu function.
>> Verified in kernel version v3.11.
>>
>> Signed-off-by: Oussama Ghorbel <ou.ghorbel@gmail.com>
>> ---
>> net/ipv6/ip6_gre.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
>> index 90747f1..41487ab 100644
>> --- a/net/ipv6/ip6_gre.c
>> +++ b/net/ipv6/ip6_gre.c
>> @@ -1175,9 +1175,8 @@ done:
>>
>> static int ip6gre_tunnel_change_mtu(struct net_device *dev, int new_mtu)
>> {
>> - struct ip6_tnl *tunnel = netdev_priv(dev);
>> if (new_mtu < 68 ||
>> - new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen)
>> + new_mtu > 0xFFF8 - dev->hard_header_len)
>> return -EINVAL;
>> dev->mtu = new_mtu;
>> return 0;
>
> Hmmm...
>
> dev->hard_header_len is initialized to LL_MAX_HEADER + sizeof(struct ipv6hdr)
> + 4 but won't include the additional head space needed for GRE_SEQ, GRE_KEY
> etc. if at time of tunnel creation the routing table did not had a good guess
> for the outgoing device.
>
This hard_header_len initialization that you have shown above is taken
from ip6gre_tunnel_setup, however this same variable seems to be
reinitialized in ip6gre_tnl_link_config() which are called from
ip6gre_newlink()
The initialization in ip6gre_tnl_link_config is done as the following:
static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
{
...
int addend = sizeof(struct ipv6hdr) + 4;
...
/* Precalculate GRE options length */
if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
if (t->parms.o_flags&GRE_CSUM)
addend += 4;
if (t->parms.o_flags&GRE_KEY)
addend += 4;
if (t->parms.o_flags&GRE_SEQ)
addend += 4;
}
...
dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
...
t->hlen = addend;
..
}
Unless they are other reasons, the hard_header_len is taken into
account the GRE_KEY, GRE_SEQ ..
> To make this correct we would have to refactor the usage of the variables a
> bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
> check as-is currently although we exclude some allowed mtus.
>
> Perhaps you want to take a look how to achieve that? ;)
>
Why not, consistency is good ...
> Greetings,
>
> Hannes
>
Thanks,
Oussama
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Fix pages never dma unmapped on rx
From: Eric Dumazet @ 2013-10-06 14:22 UTC (permalink / raw)
To: Amir Vadai; +Cc: netdev, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
In-Reply-To: <1381064240-12902-1-git-send-email-amirv@mellanox.com>
On Sun, 2013-10-06 at 14:57 +0200, Amir Vadai wrote:
> This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
> order-0 memory allocations in RX path).
>
> dma_unmap_page never reached because condition to detect last fragment
> in page is wrong. offset+frag_stride can't be greater than size, need to
> make sure no additional frag will fit in page => compare offset +
> frag_stride + next_frag_size instead.
> next_frag_size could be next frag in the same skb, or the first frag in
> the next.
>
> CC: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index dec455c..44d8865 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -131,8 +131,11 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
> int i)
> {
> const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
> + u16 next_frag_end = frags[i].offset + frag_info->frag_stride;
>
Hmm, could you make this an u32 ?
frags[i].offset and frags[i].size are u32
Maybe some folks want to use PAGE_SIZE=65536 or whatever high order
allocs
> - if (frags[i].offset + frag_info->frag_stride > frags[i].size)
> + next_frag_end += frags[(i + 1) % priv->num_frags].size;
> +
> + if (next_frag_end > frags[i].size)
> dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
> PCI_DMA_FROMDEVICE);
>
Not sure I understand how this can work. How was this tested ?
frags[i + 1].size is the size of the page containing next fragment,
so now test should _always_ trigger.
(We could rename @size to @page_size to avoid confusion)
I think you meant to add the size of the next fragment ?
What about following instead (I also removed the divide operation)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index dec455c..22444de 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -131,10 +131,17 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
int i)
{
const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
+ u32 next_frag_end = frags[i].offset + frag_info->frag_stride;
- if (frags[i].offset + frag_info->frag_stride > frags[i].size)
+ frag_info++;
+ if (i + 1 == priv->num_frags)
+ frag_info = &priv->frag_info[0];
+
+ next_frag_end += frag_info->frag_stride;
+
+ if (next_frag_end > frags[i].size)
dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
- PCI_DMA_FROMDEVICE);
+ PCI_DMA_FROMDEVICE);
if (frags[i].page)
put_page(frags[i].page);
^ permalink raw reply related
* [PATCH net] net/mlx4_en: Fix pages never dma unmapped on rx
From: Amir Vadai @ 2013-10-06 12:57 UTC (permalink / raw)
To: netdev; +Cc: Amir Vadai, Or Gerlitz, Eugenia Emantayev, Eric Dumazet
This patch fixes a bug introduced by commit 51151a16 (mlx4: allow
order-0 memory allocations in RX path).
dma_unmap_page never reached because condition to detect last fragment
in page is wrong. offset+frag_stride can't be greater than size, need to
make sure no additional frag will fit in page => compare offset +
frag_stride + next_frag_size instead.
next_frag_size could be next frag in the same skb, or the first frag in
the next.
CC: Eric Dumazet <edumazet@google.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index dec455c..44d8865 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -131,8 +131,11 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv,
int i)
{
const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i];
+ u16 next_frag_end = frags[i].offset + frag_info->frag_stride;
- if (frags[i].offset + frag_info->frag_stride > frags[i].size)
+ next_frag_end += frags[(i + 1) % priv->num_frags].size;
+
+ if (next_frag_end > frags[i].size)
dma_unmap_page(priv->ddev, frags[i].dma, frags[i].size,
PCI_DMA_FROMDEVICE);
--
1.8.3.4
^ permalink raw reply related
* Re: IPv6 path MTU discovery broken
From: Steinar H. Gunderson @ 2013-10-06 12:48 UTC (permalink / raw)
To: netdev, edumazet
In-Reply-To: <20131006124403.GA9295@order.stressinduktion.org>
On Sun, Oct 06, 2013 at 02:44:03PM +0200, Hannes Frederic Sowa wrote:
> Do you know which remote IP address is part in the failing communication? Same
> as above?
It's in 2001:67c:a4:3::/64 or 2001:67c:a4:1::/64. Unsure which, because now
I rebooted the client for a different reason (giving it a different privacy
address and possibly subnet), and now it's unreproducible again...
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Hannes Frederic Sowa @ 2013-10-06 12:44 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: netdev, edumazet
In-Reply-To: <20131006120612.GA27852@sesse.net>
On Sun, Oct 06, 2013 at 02:06:12PM +0200, Steinar H. Gunderson wrote:
> On Sat, Sep 28, 2013 at 10:33:18PM +0200, Hannes Frederic Sowa wrote:
> >> So the “packet too big” packets really look like they're being ignored.
> >> However, they _do_ reach the kernel somehow, since Icmp6InPktTooBigs
> >> seems to increase.
> >>
> >> Could this be related somehow to the packets coming from 2001:67c:29f4::31,
> >> while the default route is to a link-local address? (An RPF issue?) This used
> >> to work (although it was often flaky for me) in 3.10 and before. I can't
> >> easily bisect, though, as I don't boot this machine too often.
> > This looks like a bug and should definitely get fixed. There should be
> > no RPF issue. May I have a look at your /proc/net/ipv6_route?
>
> It started again, so now I could capture what you asked for:
Thanks!
Do you know which remote IP address is part in the failing communication? Same
as above?
Greetings,
Hannes
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Steinar H. Gunderson @ 2013-10-06 12:06 UTC (permalink / raw)
To: netdev, edumazet
In-Reply-To: <20130928203318.GC23654@order.stressinduktion.org>
On Sat, Sep 28, 2013 at 10:33:18PM +0200, Hannes Frederic Sowa wrote:
>> So the “packet too big” packets really look like they're being ignored.
>> However, they _do_ reach the kernel somehow, since Icmp6InPktTooBigs
>> seems to increase.
>>
>> Could this be related somehow to the packets coming from 2001:67c:29f4::31,
>> while the default route is to a link-local address? (An RPF issue?) This used
>> to work (although it was often flaky for me) in 3.10 and before. I can't
>> easily bisect, though, as I don't boot this machine too often.
> This looks like a bug and should definitely get fixed. There should be
> no RPF issue. May I have a look at your /proc/net/ipv6_route?
It started again, so now I could capture what you asked for:
pannekake:~> cat /proc/net/ipv6_route
20010500007200000000000000000000 30 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
2001067c00a400037c4d9ae8ab73230f 80 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000000 00000001 00000137 01000023 eth0
2001067c00a400000000000000000000 30 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f400000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00003dc0 01000001 eth0
2001067c29f400000000000000000031 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00047359 01000001 eth0
2001067c29f400000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000001 00000001 eth0
2001067c29f400010000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410000000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410010000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410030000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410050000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f410070000000000000000 40 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000064 00000000 00000000 00000003 eth0
2001067c29f400000000000000000000 30 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
20010700000000000000000000000000 20 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
2001070800402001a822bafffec42428 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000001 0000ab13 01000003 eth0
20010840000010000001000000000001 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000001 0001114c 01000003 eth0
26200000105f0004be305bfffed17063 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000003 0000002f 01000003 eth0
2a01023842d7aa006667669799990042 80 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000000 00000001 000081ef 01000003 eth0
2a022368000000000000000000000000 20 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
fe80000000000000000000002ae38049 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_magne
fe80000000000000000000002cb7a217 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000004 01000001 k_molvenfinnoy
fe8000000000000000000000315e851e 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_trygve
fe8000000000000000000000419b407a 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_molven
fe80000000000000000000005ccc2ed1 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_sessesveits
fe800000000000000000000077707d72 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_berge
fe8000000000000000000000c2faf88c 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000001 01000001 k_wikene
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_sessesveits
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_trygve
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_wikene
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molven
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_magne
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_berge
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molvenfinnoy
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_sessesveits
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_trygve
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_wikene
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molven
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_magne
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_berge
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molvenfinnoy
00000000000000000000000000000000 00 00000000000000000000000000000000 00 2001067c29f400000000000000000001 00000400 00000000 00000000 00000003 eth0
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 0009a4db 00200200 lo
00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 0000a62c 80200001 lo
2001067c29f400000000000000000000 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 00300001 lo
2001067c29f400000000000000000050 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 0000000a 1a692b94 80200001 lo
fe800000000000000000000000000000 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 00300001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 0000602f 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00003c59 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 0000530e 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00005bbb 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00003fad 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00002953 80200001 lo
fe8000000000000000000000c30b9a61 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001 lo
fe80000000000000022590fffe006b52 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 0000541c 80200001 lo
ff020000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000002 01000001 eth0
ff02000000000000000000000000000d 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000003a 01000001 eth0
ff02000000000000000000000000000d 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000000b 01000001 k_sessesveits
ff02000000000000000000000000000d 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000000b 01000001 k_molven
ff020000000000000000000000010002 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000004 01000001 eth0
ff0200000000000000000001ff000020 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0
ff0200000000000000000001ff000029 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 0000000a 01000001 eth0
ff0200000000000000000001ff000030 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000004 01000001 eth0
ff0200000000000000000001ff000031 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0
ff0200000000000000000001ff000032 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000045 01000001 eth0
ff0200000000000000000001ff000057 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0
ff0200000000000000000001ff003004 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000001 01000001 eth0
ff0200000000000000000001ff003005 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000002 01000001 eth0
ff0200000000000000000001ff4793da 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000003 01000001 eth0
ff0200000000000000000001ff5945c2 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000000 00000003 01000001 eth0
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 eth0
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_sessesveits
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_trygve
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_wikene
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molven
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_magne
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_berge
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 k_molvenfinnoy
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 0009a4db 00200200 lo
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Sometimes things happen much quicker than you would love to.
From: JeffreyCHaber @ 2013-10-06 10:25 UTC (permalink / raw)
Dear Customer
Why missing moments with your loved ones when you have the solution at one click distance?
Never miss a moment again
http://translate.googleusercontent.com/translate_c?depth=1&hl=auto&sl=fr&url=www.google.ch&u=http://myonlinestore1.yolasite.com/shop&usg=ALkJrhiQ-uda4tZHsm2mYWAuq6KLfgZUuA
Best Regards,
^ permalink raw reply
* Re: Bug - regression - Via velocity interface coming up freezes kernel
From: Jamie Heilman @ 2013-10-06 8:19 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu
In-Reply-To: <CAFES+i+9Wk6GMo8jMPH4uAz0AFi16RCWaRjG2YOyjRiBnx7OVQ@mail.gmail.com>
FWIW, I encountered this same issue on my EPIA-SN with its onboard
VT6130, I bisected back to the same commit, and Francois's patch
against 3.11.4 also eliminated the warning for me. Hopefully a fix
is queued up for stable soon.
For the record the full trace was:
WARNING: CPU: 0 PID: 0 at kernel/softirq.c:159 _local_bh_enable_ip.isra.14+0x32/0x6e()
Modules linked in: quota_v2 quota_tree nfsd auth_rpcgss oid_registry exportfs nfs lockd fscache sunrpc xt_mark cls_fw sch_htb xt_nat iptable_nat nf_nat_ipv4 nf_nat ipt_REJECT xt_tcpudp xt_multiport iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_LOG xt_limit iptable_filter ip_tables x_tables dm_crypt dm_mod snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore psmouse via_rhine mii via_velocity evdev via_agp ioapic agpgart
CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.4 #1
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080014 06/01/2009
00000000 00000000 c1355d04 c125c0f9 c1355d34 c1024360 c12ecca6 00000000
00000000 c12ece5c 0000009f c1026769 c1026769 f5041cc0 c138cb2c f5ae3000
c1355d44 c10243f3 00000009 00000000 c1355d4c c1026769 c1355d54 c10267ad
Call Trace:
[<c125c0f9>] dump_stack+0x16/0x18
[<c1024360>] warn_slowpath_common+0x70/0x87
[<c1026769>] ? _local_bh_enable_ip.isra.14+0x32/0x6e
[<c1026769>] ? _local_bh_enable_ip.isra.14+0x32/0x6e
[<c10243f3>] warn_slowpath_null+0x1d/0x1f
[<c1026769>] _local_bh_enable_ip.isra.14+0x32/0x6e
[<c10267ad>] local_bh_enable+0x8/0xa
[<c120e15f>] neigh_lookup+0x95/0x9e
[<c124239a>] __neigh_lookup.constprop.16+0x1b/0x4e
[<c1242b3f>] arp_process+0x3ac/0x461
[<c1216860>] ? sch_direct_xmit+0x37/0xd9
[<c10267ad>] ? local_bh_enable+0x8/0xa
[<c1208ccd>] ? dev_queue_xmit+0x2aa/0x2b7
[<c1242cc2>] arp_rcv+0xc4/0x107
[<c1242714>] ? arp_xmit+0x18/0x4f
[<c1206c67>] __netif_receive_skb_core+0x366/0x39f
[<c1004f09>] ? text_poke_smp_batch+0x2a/0x2a
[<c1206cb1>] __netif_receive_skb+0x11/0x4d
[<c1004f09>] ? text_poke_smp_batch+0x2a/0x2a
[<c1207747>] netif_receive_skb+0x30/0x33
[<f84465aa>] velocity_rx_srv+0x229/0x304 [via_velocity]
[<f84466b6>] velocity_poll+0x31/0x7a [via_velocity]
[<c12078bb>] net_rx_action+0x69/0xe9
[<c1026a0b>] __do_softirq+0x87/0x12d
[<c1026b57>] irq_exit+0x36/0x6d
[<c1002c4e>] do_IRQ+0x74/0x87
[<c125ef73>] common_interrupt+0x33/0x38
[<c1006739>] ? default_idle+0x5/0x7
[<c1006a9d>] arch_cpu_idle+0x12/0x17
[<c1040a04>] cpu_startup_entry+0xbe/0x109
[<c1257758>] rest_init+0x57/0x59
[<c1394920>] start_kernel+0x2be/0x2c4
[<c1394494>] ? repair_env_string+0x51/0x51
[<c13942c3>] i386_start_kernel+0x79/0x7d
---[ end trace 96eca78d04cc6ac3 ]---
--
Jamie Heilman http://audible.transient.net/~jamie/
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Alexander Gordeev @ 2013-10-06 7:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ben Hutchings, linux-kernel, Bjorn Helgaas, Ralf Baechle,
Michael Ellerman, Martin Schwidefsky, Ingo Molnar, Tejun Heo,
Dan Williams, Andy King, Jon Mason, Matt Porter, linux-pci,
linux-mips, linuxppc-dev, linux390, linux-s390, x86, linux-ide,
iss_storagedev, linux-nvme, linux-rdma, netdev, e1000-devel,
linux-driver
In-Reply-To: <1381040386.645.143.camel@pasglop>
On Sun, Oct 06, 2013 at 05:19:46PM +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2013-10-06 at 08:02 +0200, Alexander Gordeev wrote:
> > In fact, in the current design to address the quota race decently the
> > drivers would have to protect the *loop* to prevent the quota change
> > between a pci_enable_msix() returned a positive number and the the next
> > call to pci_enable_msix() with that number. Is it doable?
>
> I am not advocating for the current design, simply saying that your
> proposal doesn't address this issue while Ben's does.
There is one major flaw in min-max approach - the generic MSI layer
will have to take decisions on exact number of MSIs to request, not
device drivers.
This will never work for all devices, because there might be specific
requirements which are not covered by the min-max. That is what Ben
described "...say, any even number within a certain range". Ben suggests
to leave the existing loop scheme to cover such devices, which I think is
not right.
What about introducing pci_lock_msi() and pci_unlock_msi() and let device
drivers care about their ranges and specifics in race-safe manner?
I do not call to introduce it right now (since it appears pSeries has not
been hitting the race for years) just as a possible alternative to Ben's
proposal.
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Benjamin Herrenschmidt @ 2013-10-06 6:19 UTC (permalink / raw)
To: Alexander Gordeev
Cc: Ben Hutchings, linux-kernel, Bjorn Helgaas, Ralf Baechle,
Michael Ellerman, Martin Schwidefsky, Ingo Molnar, Tejun Heo,
Dan Williams, Andy King, Jon Mason, Matt Porter, linux-pci,
linux-mips, linuxppc-dev, linux390, linux-s390, x86, linux-ide,
iss_storagedev, linux-nvme, linux-rdma, netdev, e1000-devel,
linux-driver
In-Reply-To: <20131006060243.GB28142@dhcp-26-207.brq.redhat.com>
On Sun, 2013-10-06 at 08:02 +0200, Alexander Gordeev wrote:
> On Sun, Oct 06, 2013 at 08:46:26AM +1100, Benjamin Herrenschmidt wrote:
> > On Sat, 2013-10-05 at 16:20 +0200, Alexander Gordeev wrote:
> > > So my point is - drivers should first obtain a number of MSIs they *can*
> > > get, then *derive* a number of MSIs the device is fine with and only then
> > > request that number. Not terribly different from memory or any other type
> > > of resource allocation ;)
> >
> > What if the limit is for a group of devices ? Your interface is racy in
> > that case, another driver could have eaten into the limit in between the
> > calls.
>
> Well, the another driver has had a better karma ;) But seriously, the
> current scheme with a loop is not race-safe wrt to any other type of
> resource which might exhaust. What makes the quota so special so we
> should care about it and should not care i.e. about lack of msi_desc's?
I'm not saying the current scheme is better but I prefer the option of
passing a min,max to the request function.
> Yeah, I know the quota might hit more likely. But why it is not addressed
> right now then? Not a single function in chains...
> rtas_msi_check_device() -> msi_quota_for_device() -> traverse_pci_devices()
> rtas_setup_msi_irqs() -> msi_quota_for_device() -> traverse_pci_devices()
> ...is race-safe. So if it has not been bothering anyone until now then
> no reason to start worrying now :)
>
> In fact, in the current design to address the quota race decently the
> drivers would have to protect the *loop* to prevent the quota change
> between a pci_enable_msix() returned a positive number and the the next
> call to pci_enable_msix() with that number. Is it doable?
I am not advocating for the current design, simply saying that your
proposal doesn't address this issue while Ben's does.
Cheers,
Ben.
> > Ben.
> >
> >
>
^ permalink raw reply
* Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern
From: Alexander Gordeev @ 2013-10-06 6:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ben Hutchings, linux-kernel, Bjorn Helgaas, Ralf Baechle,
Michael Ellerman, Martin Schwidefsky, Ingo Molnar, Tejun Heo,
Dan Williams, Andy King, Jon Mason, Matt Porter, linux-pci,
linux-mips, linuxppc-dev, linux390, linux-s390, x86, linux-ide,
iss_storagedev, linux-nvme, linux-rdma, netdev, e1000-devel,
linux-driver
In-Reply-To: <1381009586.645.141.camel@pasglop>
On Sun, Oct 06, 2013 at 08:46:26AM +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2013-10-05 at 16:20 +0200, Alexander Gordeev wrote:
> > So my point is - drivers should first obtain a number of MSIs they *can*
> > get, then *derive* a number of MSIs the device is fine with and only then
> > request that number. Not terribly different from memory or any other type
> > of resource allocation ;)
>
> What if the limit is for a group of devices ? Your interface is racy in
> that case, another driver could have eaten into the limit in between the
> calls.
Well, the another driver has had a better karma ;) But seriously, the
current scheme with a loop is not race-safe wrt to any other type of
resource which might exhaust. What makes the quota so special so we
should care about it and should not care i.e. about lack of msi_desc's?
Yeah, I know the quota might hit more likely. But why it is not addressed
right now then? Not a single function in chains...
rtas_msi_check_device() -> msi_quota_for_device() -> traverse_pci_devices()
rtas_setup_msi_irqs() -> msi_quota_for_device() -> traverse_pci_devices()
...is race-safe. So if it has not been bothering anyone until now then
no reason to start worrying now :)
In fact, in the current design to address the quota race decently the
drivers would have to protect the *loop* to prevent the quota change
between a pci_enable_msix() returned a positive number and the the next
call to pci_enable_msix() with that number. Is it doable?
> Ben.
>
>
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH] net: secure_seq: Move net_secret_init() definition into CONFIG_IPV6 if block
From: Olof Johansson @ 2013-10-06 5:25 UTC (permalink / raw)
To: David Miller
Cc: Fabio Estevam, edumazet, hannes, Network Development,
Fabio Estevam
In-Reply-To: <20131005.162752.155685316245760253.davem@davemloft.net>
On Sat, Oct 5, 2013 at 1:27 PM, David Miller <davem@davemloft.net> wrote:
> From: Fabio Estevam <festevam@gmail.com>
> Date: Sat, 5 Oct 2013 17:09:50 -0300
>
>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>
>> Commit 9a3bab6b05 (net: net_secret should not depend on TCP) introduced
>> the following build warning when CONFIG_IPV6 is not selected:
>>
>> net/core/secure_seq.c:17:13: warning: 'net_secret_init' defined but not used [-Wunused-function]
>>
>> Fix it by moving net_secret_init(void) inside the '#if IS_ENABLED(CONFIG_IPV6)'
>> block.
>>
>> Reported-by: Olof Johansson <olof@lixom.net>
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>
> seq_scale is used by secure_tcp_sequence_number, which is only protected
> by CONFIG_INET. I have no idea how you can get this build problem.
>
> And I cannot reproduce it here:
You get it if you have CONFIG_NET enabled, but CONFIG_INET off. We
seem to have a few defconfigs on arm that has that setting, likely
because they lack native network interfaces but need local unix
sockets. Or whatever. But that's how you hit it.
Steps to reproduce, even with ARCH=sparc:
make allnoconfig
edit .config, set CONFIG_NET=y
yes "" | make oldconfig
make
-Olof
^ permalink raw reply
* [PATCH] net: p54spi: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-10-06 5:04 UTC (permalink / raw)
To: chunkeey, linville
Cc: linux-wireless, netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/wireless/p54/p54spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 7fc46f2..de15171 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -636,7 +636,7 @@ static int p54spi_probe(struct spi_device *spi)
gpio_direction_input(p54spi_gpio_irq);
ret = request_irq(gpio_to_irq(p54spi_gpio_irq),
- p54spi_interrupt, IRQF_DISABLED, "p54spi",
+ p54spi_interrupt, 0, "p54spi",
priv->spi);
if (ret < 0) {
dev_err(&priv->spi->dev, "request_irq() failed");
--
1.8.1.2
^ permalink raw reply related
* [PATCH v1 3/3] mrf24j40: Use level-triggered interrupts
From: Alan Ott @ 2013-10-06 3:52 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov, David S. Miller,
david-1EggE+PRa6vk1uMJSBkQmQ
Cc: Alan Ott, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1381031544-2960-1-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
The mrf24j40 generates level interrupts. There are rare cases where it
appears that the interrupt line never gets de-asserted between interrupts,
causing interrupts to be lost, and causing a hung device from the driver's
perspective. Switching the driver to interpret these interrupts as
level-triggered fixes this issue.
Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
---
drivers/net/ieee802154/mrf24j40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
index c1bc688..0632d34 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -678,7 +678,7 @@ static int mrf24j40_probe(struct spi_device *spi)
ret = request_threaded_irq(spi->irq,
NULL,
mrf24j40_isr,
- IRQF_TRIGGER_FALLING|IRQF_ONESHOT,
+ IRQF_TRIGGER_LOW|IRQF_ONESHOT,
dev_name(&spi->dev),
devrec);
--
1.8.1.2
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH v1 2/3] mrf24j40: Use threaded IRQ handler
From: Alan Ott @ 2013-10-06 3:52 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov, David S. Miller,
david-1EggE+PRa6vk1uMJSBkQmQ
Cc: Alan Ott, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1381031544-2960-1-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
Eliminate all the workqueue and interrupt enable/disable.
Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
---
drivers/net/ieee802154/mrf24j40.c | 27 +++++++--------------------
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
index 66bb4ce..c1bc688 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -82,7 +82,6 @@ struct mrf24j40 {
struct mutex buffer_mutex; /* only used to protect buf */
struct completion tx_complete;
- struct work_struct irqwork;
u8 *buf; /* 3 bytes. Used for SPI single-register transfers. */
};
@@ -590,17 +589,6 @@ static struct ieee802154_ops mrf24j40_ops = {
static irqreturn_t mrf24j40_isr(int irq, void *data)
{
struct mrf24j40 *devrec = data;
-
- disable_irq_nosync(irq);
-
- schedule_work(&devrec->irqwork);
-
- return IRQ_HANDLED;
-}
-
-static void mrf24j40_isrwork(struct work_struct *work)
-{
- struct mrf24j40 *devrec = container_of(work, struct mrf24j40, irqwork);
u8 intstat;
int ret;
@@ -618,7 +606,7 @@ static void mrf24j40_isrwork(struct work_struct *work)
mrf24j40_handle_rx(devrec);
out:
- enable_irq(devrec->spi->irq);
+ return IRQ_HANDLED;
}
static int mrf24j40_probe(struct spi_device *spi)
@@ -642,7 +630,6 @@ static int mrf24j40_probe(struct spi_device *spi)
mutex_init(&devrec->buffer_mutex);
init_completion(&devrec->tx_complete);
- INIT_WORK(&devrec->irqwork, mrf24j40_isrwork);
devrec->spi = spi;
spi_set_drvdata(spi, devrec);
@@ -688,11 +675,12 @@ static int mrf24j40_probe(struct spi_device *spi)
val &= ~0x3; /* Clear RX mode (normal) */
write_short_reg(devrec, REG_RXMCR, val);
- ret = request_irq(spi->irq,
- mrf24j40_isr,
- IRQF_TRIGGER_FALLING,
- dev_name(&spi->dev),
- devrec);
+ ret = request_threaded_irq(spi->irq,
+ NULL,
+ mrf24j40_isr,
+ IRQF_TRIGGER_FALLING|IRQF_ONESHOT,
+ dev_name(&spi->dev),
+ devrec);
if (ret) {
dev_err(printdev(devrec), "Unable to get IRQ");
@@ -721,7 +709,6 @@ static int mrf24j40_remove(struct spi_device *spi)
dev_dbg(printdev(devrec), "remove\n");
free_irq(spi->irq, devrec);
- flush_work(&devrec->irqwork); /* TODO: Is this the right call? */
ieee802154_unregister_device(devrec->dev);
ieee802154_free_device(devrec->dev);
/* TODO: Will ieee802154_free_device() wait until ->xmit() is
--
1.8.1.2
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH v1 1/3] mrf24j40: Move INIT_COMPLETION() to before packet transmission
From: Alan Ott @ 2013-10-06 3:52 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov, David S. Miller,
david-1EggE+PRa6vk1uMJSBkQmQ
Cc: Alan Ott, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1381031544-2960-1-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
This avoids a race condition where complete(tx_complete) could be called
before tx_complete is initialized.
Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
---
drivers/net/ieee802154/mrf24j40.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
index 42e6dee..66bb4ce 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -344,6 +344,8 @@ static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb)
if (ret)
goto err;
+ INIT_COMPLETION(devrec->tx_complete);
+
/* Set TXNTRIG bit of TXNCON to send packet */
ret = read_short_reg(devrec, REG_TXNCON, &val);
if (ret)
@@ -354,8 +356,6 @@ static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb)
val |= 0x4;
write_short_reg(devrec, REG_TXNCON, val);
- INIT_COMPLETION(devrec->tx_complete);
-
/* Wait for the device to send the TX complete interrupt. */
ret = wait_for_completion_interruptible_timeout(
&devrec->tx_complete,
--
1.8.1.2
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH v1 0/3] Fix race conditions in mrf24j40 interrupts
From: Alan Ott @ 2013-10-06 3:52 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov, David S. Miller,
david-1EggE+PRa6vk1uMJSBkQmQ
Cc: Alan Ott, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1369188080-8904-1-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
After testing with the betas of this patchset, it's been rebased and is
ready for inclusion.
David Hauweele noticed that the mrf24j40 would hang arbitrarily after some
period of heavy traffic. Two race conditions were discovered, and the
driver was changed to use threaded interrupts, since the enable/disable of
interrupts in the driver has recently been a lighning rod whenever issues
arise related to interrupts (costing engineering time), and since threaded
interrupts are the right way to do it.
Alan Ott (3):
mrf24j40: Move INIT_COMPLETION() to before packet transmission
mrf24j40: Use threaded IRQ handler
mrf24j40: Use level-triggered interrupts
drivers/net/ieee802154/mrf24j40.c | 31 +++++++++----------------------
1 file changed, 9 insertions(+), 22 deletions(-)
--
1.8.1.2
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply
* [PATCH v2 2/2] 6lowpan: Sync default hardware address of lowpan links to their wpan
From: Alan Ott @ 2013-10-06 3:15 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov, David S. Miller
Cc: Alan Ott, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1381029319-6835-1-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
When a lowpan link to a wpan device is created, set the hardware address
of the lowpan link to that of the wpan device.
Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
---
net/ieee802154/6lowpan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 8f56b2b..ff41b4d 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1388,6 +1388,9 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
entry->ldev = dev;
+ /* Set the lowpan harware address to the wpan hardware address. */
+ memcpy(dev->dev_addr, real_dev->dev_addr, IEEE802154_ADDR_LEN);
+
mutex_lock(&lowpan_dev_info(dev)->dev_list_mtx);
INIT_LIST_HEAD(&entry->list);
list_add_tail(&entry->list, &lowpan_devices);
--
1.8.1.2
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH v2 1/2] 6lowpan: Only make 6lowpan links to IEEE802154 devices
From: Alan Ott @ 2013-10-06 3:15 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov, David S. Miller
Cc: Alan Ott, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1381029319-6835-1-git-send-email-alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
Refuse to create 6lowpan links if the actual hardware interface is
of any type other than ARPHRD_IEEE802154.
Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
Suggested-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/ieee802154/6lowpan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index c85e71e..8f56b2b 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1372,6 +1372,8 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
if (!real_dev)
return -ENODEV;
+ if (real_dev->type != ARPHRD_IEEE802154)
+ return -EINVAL;
lowpan_dev_info(dev)->real_dev = real_dev;
lowpan_dev_info(dev)->fragment_tag = 0;
--
1.8.1.2
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply related
* [PATCH v2 0/2] 6lowpan default hardware address
From: Alan Ott @ 2013-10-06 3:15 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov, David S. Miller
Cc: Alan Ott, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Alexander Aring suggested that devices desired to be linked to 6lowpan
be checked for actually being of type IEEE802154, since IEEE802154 devices
are all that are supported by 6lowpan at present.
Alan Ott (2):
6lowpan: Only make 6lowpan links to IEEE802154 devices
6lowpan: Sync default hardware address of lowpan links to their wpan
net/ieee802154/6lowpan.c | 5 +++++
1 file changed, 5 insertions(+)
--
1.8.1.2
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: Introduce support to lazy initialize mostly static keys v2
From: David Miller @ 2013-10-06 2:55 UTC (permalink / raw)
To: hannes; +Cc: netdev, linux-kernel
In-Reply-To: <1381015258-7667-1-git-send-email-hannes@stressinduktion.org>
Please in the future use "[PATCH 0/8] " as a subject prefix for
postings such as this one which introduces a patch set.
Thanks.
^ permalink raw reply
* [PATCH] eisa: standardize on eisa_register_driver like similar bus registrations
From: Matthew Whitehead @ 2013-10-06 2:35 UTC (permalink / raw)
To: netdev; +Cc: linux-scsi, Matthew Whitehead
The other buses (isa, pci, pnp, parport, usb, tty, etc) all use the convention
of ${BUSNAME}_register_driver. Rewrite the little remaining code that uses EISA
to follow this convention for easier readability.
This affects the EISA bus, SCSI, and networking subsystems so only one should
ultimately merge the patch if it is accepted.
Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
---
drivers/eisa/eisa-bus.c | 8 ++++----
drivers/net/ethernet/3com/3c509.c | 4 ++--
drivers/net/ethernet/3com/3c59x.c | 6 +++---
drivers/net/ethernet/dec/tulip/de4x5.c | 4 ++--
drivers/net/ethernet/hp/hp100.c | 6 +++---
drivers/net/fddi/defxx.c | 4 ++--
drivers/scsi/advansys.c | 6 +++---
drivers/scsi/aha1740.c | 4 ++--
drivers/scsi/aic7xxx/aic7770_osm.c | 4 ++--
drivers/scsi/sim710.c | 4 ++--
include/linux/eisa.h | 8 ++++----
11 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/eisa/eisa-bus.c b/drivers/eisa/eisa-bus.c
index 272a3ec..9fe589b 100644
--- a/drivers/eisa/eisa-bus.c
+++ b/drivers/eisa/eisa-bus.c
@@ -143,18 +143,18 @@ struct bus_type eisa_bus_type = {
};
EXPORT_SYMBOL(eisa_bus_type);
-int eisa_driver_register(struct eisa_driver *edrv)
+int eisa_register_driver(struct eisa_driver *edrv)
{
edrv->driver.bus = &eisa_bus_type;
return driver_register(&edrv->driver);
}
-EXPORT_SYMBOL(eisa_driver_register);
+EXPORT_SYMBOL(eisa_register_driver);
-void eisa_driver_unregister(struct eisa_driver *edrv)
+void eisa_unregister_driver(struct eisa_driver *edrv)
{
driver_unregister(&edrv->driver);
}
-EXPORT_SYMBOL(eisa_driver_unregister);
+EXPORT_SYMBOL(eisa_unregister_driver);
static ssize_t eisa_show_sig(struct device *dev, struct device_attribute *attr,
char *buf)
diff --git a/drivers/net/ethernet/3com/3c509.c b/drivers/net/ethernet/3com/3c509.c
index ede8daa..ddfc2f0 100644
--- a/drivers/net/ethernet/3com/3c509.c
+++ b/drivers/net/ethernet/3com/3c509.c
@@ -1417,7 +1417,7 @@ static int __init el3_init_module(void)
isa_registered = 1;
}
#ifdef CONFIG_EISA
- ret = eisa_driver_register(&el3_eisa_driver);
+ ret = eisa_register_driver(&el3_eisa_driver);
if (!ret)
eisa_registered = 1;
#endif
@@ -1447,7 +1447,7 @@ static void __exit el3_cleanup_module(void)
release_region(id_port, 1);
#ifdef CONFIG_EISA
if (eisa_registered)
- eisa_driver_unregister(&el3_eisa_driver);
+ eisa_unregister_driver(&el3_eisa_driver);
#endif
}
diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c
index ad5272b..df22872 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -976,12 +976,12 @@ static int __init vortex_eisa_init(void)
#ifdef CONFIG_EISA
int err;
- err = eisa_driver_register (&vortex_eisa_driver);
+ err = eisa_register_driver (&vortex_eisa_driver);
if (!err) {
/*
* Because of the way EISA bus is probed, we cannot assume
* any device have been found when we exit from
- * eisa_driver_register (the bus root driver may not be
+ * eisa_register_driver (the bus root driver may not be
* initialized yet). So we blindly assume something was
* found, and let the sysfs magic happened...
*/
@@ -3295,7 +3295,7 @@ static void __exit vortex_eisa_cleanup(void)
#ifdef CONFIG_EISA
/* Take care of the EISA devices */
- eisa_driver_unregister(&vortex_eisa_driver);
+ eisa_unregister_driver(&vortex_eisa_driver);
#endif
if (compaq_net_device) {
diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
index 263b92c..1df85a1 100644
--- a/drivers/net/ethernet/dec/tulip/de4x5.c
+++ b/drivers/net/ethernet/dec/tulip/de4x5.c
@@ -5570,7 +5570,7 @@ static int __init de4x5_module_init (void)
err = pci_register_driver(&de4x5_pci_driver);
#endif
#ifdef CONFIG_EISA
- err |= eisa_driver_register (&de4x5_eisa_driver);
+ err |= eisa_register_driver (&de4x5_eisa_driver);
#endif
return err;
@@ -5582,7 +5582,7 @@ static void __exit de4x5_module_exit (void)
pci_unregister_driver (&de4x5_pci_driver);
#endif
#ifdef CONFIG_EISA
- eisa_driver_unregister (&de4x5_eisa_driver);
+ eisa_unregister_driver (&de4x5_eisa_driver);
#endif
}
diff --git a/drivers/net/ethernet/hp/hp100.c b/drivers/net/ethernet/hp/hp100.c
index 91227d0..bf817ff 100644
--- a/drivers/net/ethernet/hp/hp100.c
+++ b/drivers/net/ethernet/hp/hp100.c
@@ -3030,7 +3030,7 @@ static int __init hp100_module_init(void)
if (err && err != -ENODEV)
goto out;
#ifdef CONFIG_EISA
- err = eisa_driver_register(&hp100_eisa_driver);
+ err = eisa_register_driver(&hp100_eisa_driver);
if (err && err != -ENODEV)
goto out2;
#endif
@@ -3043,7 +3043,7 @@ static int __init hp100_module_init(void)
return err;
out3:
#ifdef CONFIG_EISA
- eisa_driver_unregister (&hp100_eisa_driver);
+ eisa_unregister_driver (&hp100_eisa_driver);
out2:
#endif
hp100_isa_cleanup();
@@ -3055,7 +3055,7 @@ static void __exit hp100_module_exit(void)
{
hp100_isa_cleanup();
#ifdef CONFIG_EISA
- eisa_driver_unregister (&hp100_eisa_driver);
+ eisa_unregister_driver (&hp100_eisa_driver);
#endif
#ifdef CONFIG_PCI
pci_unregister_driver (&hp100_pci_driver);
diff --git a/drivers/net/fddi/defxx.c b/drivers/net/fddi/defxx.c
index 0b40e1c..01ce473 100644
--- a/drivers/net/fddi/defxx.c
+++ b/drivers/net/fddi/defxx.c
@@ -3713,7 +3713,7 @@ static int dfx_init(void)
status = pci_register_driver(&dfx_pci_driver);
if (!status)
- status = eisa_driver_register(&dfx_eisa_driver);
+ status = eisa_register_driver(&dfx_eisa_driver);
if (!status)
status = tc_register_driver(&dfx_tc_driver);
return status;
@@ -3722,7 +3722,7 @@ static int dfx_init(void)
static void dfx_cleanup(void)
{
tc_unregister_driver(&dfx_tc_driver);
- eisa_driver_unregister(&dfx_eisa_driver);
+ eisa_unregister_driver(&dfx_eisa_driver);
pci_unregister_driver(&dfx_pci_driver);
}
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index c67e401..17451e8 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -12307,7 +12307,7 @@ static int __init advansys_init(void)
if (error)
goto unregister_isa;
- error = eisa_driver_register(&advansys_eisa_driver);
+ error = eisa_register_driver(&advansys_eisa_driver);
if (error)
goto unregister_vlb;
@@ -12318,7 +12318,7 @@ static int __init advansys_init(void)
return 0;
unregister_eisa:
- eisa_driver_unregister(&advansys_eisa_driver);
+ eisa_unregister_driver(&advansys_eisa_driver);
unregister_vlb:
isa_unregister_driver(&advansys_vlb_driver);
unregister_isa:
@@ -12330,7 +12330,7 @@ static int __init advansys_init(void)
static void __exit advansys_exit(void)
{
pci_unregister_driver(&advansys_pci_driver);
- eisa_driver_unregister(&advansys_eisa_driver);
+ eisa_unregister_driver(&advansys_eisa_driver);
isa_unregister_driver(&advansys_vlb_driver);
isa_unregister_driver(&advansys_isa_driver);
}
diff --git a/drivers/scsi/aha1740.c b/drivers/scsi/aha1740.c
index 5f31017..5f6bfed 100644
--- a/drivers/scsi/aha1740.c
+++ b/drivers/scsi/aha1740.c
@@ -664,12 +664,12 @@ static struct eisa_driver aha1740_driver = {
static __init int aha1740_init (void)
{
- return eisa_driver_register (&aha1740_driver);
+ return eisa_register_driver (&aha1740_driver);
}
static __exit void aha1740_exit (void)
{
- eisa_driver_unregister (&aha1740_driver);
+ eisa_unregister_driver (&aha1740_driver);
}
module_init (aha1740_init);
diff --git a/drivers/scsi/aic7xxx/aic7770_osm.c b/drivers/scsi/aic7xxx/aic7770_osm.c
index 0cb8ef6..cbe99e4 100644
--- a/drivers/scsi/aic7xxx/aic7770_osm.c
+++ b/drivers/scsi/aic7xxx/aic7770_osm.c
@@ -146,11 +146,11 @@ static struct eisa_driver aic7770_driver = {
int
ahc_linux_eisa_init(void)
{
- return eisa_driver_register(&aic7770_driver);
+ return eisa_register_driver(&aic7770_driver);
}
void
ahc_linux_eisa_exit(void)
{
- eisa_driver_unregister(&aic7770_driver);
+ eisa_unregister_driver(&aic7770_driver);
}
diff --git a/drivers/scsi/sim710.c b/drivers/scsi/sim710.c
index 3b3b56f..d5c20cf 100644
--- a/drivers/scsi/sim710.c
+++ b/drivers/scsi/sim710.c
@@ -235,7 +235,7 @@ static int __init sim710_init(void)
#endif
#ifdef CONFIG_EISA
- err = eisa_driver_register(&sim710_eisa_driver);
+ err = eisa_register_driver(&sim710_eisa_driver);
#endif
/* FIXME: what we'd really like to return here is -ENODEV if
* no devices have actually been found. Instead, the err
@@ -248,7 +248,7 @@ static int __init sim710_init(void)
static void __exit sim710_exit(void)
{
#ifdef CONFIG_EISA
- eisa_driver_unregister(&sim710_eisa_driver);
+ eisa_unregister_driver(&sim710_eisa_driver);
#endif
}
diff --git a/include/linux/eisa.h b/include/linux/eisa.h
index 6925249..ab8bdb8 100644
--- a/include/linux/eisa.h
+++ b/include/linux/eisa.h
@@ -65,13 +65,13 @@ struct eisa_driver {
#ifdef CONFIG_EISA
extern struct bus_type eisa_bus_type;
-int eisa_driver_register (struct eisa_driver *edrv);
-void eisa_driver_unregister (struct eisa_driver *edrv);
+int eisa_register_driver (struct eisa_driver *edrv);
+void eisa_unregister_driver (struct eisa_driver *edrv);
#else /* !CONFIG_EISA */
-static inline int eisa_driver_register (struct eisa_driver *edrv) { return 0; }
-static inline void eisa_driver_unregister (struct eisa_driver *edrv) { }
+static inline int eisa_register_driver (struct eisa_driver *edrv) { return 0; }
+static inline void eisa_unregister_driver (struct eisa_driver *edrv) { }
#endif /* !CONFIG_EISA */
--
1.7.2.5
^ permalink raw reply related
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