* Re: [PATCH] [CAIF-RFC 2/8-v2] CAIF Protocol Stack
From: Stefano Babic @ 2009-10-12 9:28 UTC (permalink / raw)
To: sjur.brandeland
Cc: netdev, kim.xx.lilliestierna, christian.bejram, daniel.martensson
In-Reply-To: <1255095571-6501-3-git-send-email-sjur.brandeland@stericsson.com>
sjur.brandeland@stericsson.com wrote:
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
Hi Sjur,
> diff --git a/include/net/caif/generic/cfcnfg.h b/include/net/caif/generic/cfcnfg.h
> +/** Types of Physical Layers defined in CAIF Stack */
> +typedef enum _cfcnfg_phy_type_t {
> + CFPHYTYPE_UNKNOWN = 0,
> + CFPHYTYPE_SERIAL = 1, /*!< Serial Physical Interface */
> + CFPHYTYPE_SPI = 2, /*!< SPI Physical Interface */
> + CFPHYTYPE_MSL = 3, /*!< MSL Physical Interface */
> + CFPHYTYPE_SHM = 4, /*!< Shared Memory Physical Interface */
You actually removed the shared memory driver. Do you plan to insert it
again ?
> +/**
> + * Adds a Adaptation Layer to the CAIF Stack.
> + * The Adaptation Layer is where the interface to application or higher-level
> + * driver functionality is implemented.
> + * \image html AddVeiCaifConfig.jpg "Add an Adaptation layer to CAIF Stack."
There are references to pictures that are not provided.
> diff --git a/include/net/caif/generic/cfglue.h b/include/net/caif/generic/cfglue.h
[snip]
> +/* ASSERT */
> +#define cfglu_assert(exp) BUG_ON(!(exp))
I do not why, but even GENERIC_BUG is not defined for all architectures.
This means that BUG_ON is simply removed by the compiler and we get no
track if the assert fails.
It should be better to add at least an internal trace (adding for
example a CFLOG_FATAL call).
> diff --git a/include/net/caif/generic/cfshml.h b/include/net/caif/generic/cfshml.h
Is thif file probably obsolete ?
> diff --git a/include/net/caif/generic/cfspil.h b/include/net/caif/generic/cfspil.h
> +/** @page SPI PHY Layer description.
> + *
> + * SPI Physical layer is not implemented in GenCaif. The SPI PHY Layer
> + * is HW dependent. But the CFSPIL (Caif SPI Layer) provides support for
> + * implementing the SPI Layer Protocol.
Not sure I have understood. There is an abstraction layer for SPI in
kernel and some generic purpose functions are provided (spy_sync,
spi_async, etc.) that are HW independent. I know they provide only the
methods for the data transfer, but I have imagined that we need at this
point some kind of "caif_spi_device" that is able to talk with the caif
stack on one side and uses the functions in the SPI framework. In any
case, HW independent. Have I missed something ?
Stefano
--
stefano <stefano.babic@babic.homelinux.org>
GPG Key: 0x55814DDE
Fingerprint 4E85 2A66 4CBA 497A 2A7B D3BF 5973 F216 5581 4DDE
^ permalink raw reply
* Re: [PATCH 1/7] bnx2x: Refactor bnx2x_sp_post().
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: mchan; +Cc: netdev, michaelc, shmulikr, eilong
In-Reply-To: <1255218419-17320-1-git-send-email-mchan@broadcom.com>
All 7 patches applied, thanks Michael.
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <4AD1E169.6090705@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun, 11 Oct 2009 22:45:13 +0900
> ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
>
> Do not use bit-shift if relay_prefixlen == 0;
> relay_prefix << 32 does not result in 0.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [RESED PATCH net-next-2.6 2/3] ipv6 sit: Fix 6rd relay address.
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <4AD1E14D.6030903@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun, 11 Oct 2009 22:44:45 +0900
> ipv6 sit: Fix 6rd relay address.
>
> Relay's address should be extracted from real IPv6 address
> instead of configured prefix.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/3] ipv6 sit: Ensure to initialize 6rd parameters.
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <4AD1DE36.8070500@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun, 11 Oct 2009 22:31:34 +0900
> ipv6 sit: Ensure to initialize 6rd parameters.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied.
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: David Miller @ 2009-10-12 9:08 UTC (permalink / raw)
To: yoshfuji; +Cc: eric.dumazet, netdev
In-Reply-To: <1255337454.2878.7.camel@cirrhata.linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Mon, 12 Oct 2009 17:50:54 +0900
> Unfortunately, on x86 architecture (80286 and later at least),
> lower 5 bits (& 0x1f) are used for shift operation.
> Thus, 0xffffffffUL << 32 gives 0xffffffffUL.
Indeed, thanks for the explanation, I thought only right
shift mattered for this case of "shift count larger than
type".
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: YOSHIFUJI Hideaki @ 2009-10-12 9:03 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20091012.011802.119775755.davem@davemloft.net>
David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 12 Oct 2009 09:32:41 +0200
>
> > Sorry I dont get it
> >
> > u32 val = any_value ;
> > u32 relay_prefix = val & htonl(0xffffffffUL << 32) should give 0
> >
> > If not, something is broken and should be fixed.
>
> Indeed, it's "x >> 32" which is undefined and has to be done as
> something like "(x >> 31) >> 1" when performed on a u32 object.
>
> Yoshfuji is this patch really necessary?
Well, yes.
6rd allows 32 bit suffix (0 bit prefix).
--yoshfuji
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: YOSHIFUJI Hideaki @ 2009-10-12 8:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <4AD2DB99.3070208@gmail.com>
Eric Dumazet wrote:
> YOSHIFUJI Hideaki a écrit :
> > ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
> >
> > Do not use bit-shift if relay_prefixlen == 0;
> > relay_prefix << 32 does not result in 0.
> >
> > Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> > ---
> > net/ipv6/sit.c | 9 ++++++---
> > 1 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> > index 193d0c6..510d31f 100644
> > --- a/net/ipv6/sit.c
> > +++ b/net/ipv6/sit.c
> > @@ -1014,9 +1014,12 @@ ipip6_tunnel_ioctl (struct net_device *dev, struct ifreq *ifr, int cmd)
> > ip6rd.prefixlen);
> > if (!ipv6_addr_equal(&prefix, &ip6rd.prefix))
> > goto done;
> > - relay_prefix = ip6rd.relay_prefix &
> > - htonl(0xffffffffUL <<
> > - (32 - ip6rd.relay_prefixlen));
> > + if (ip6rd.relay_prefixlen)
> > + relay_prefix = ip6rd.relay_prefix &
> > + htonl(0xffffffffUL <<
> > + (32 - ip6rd.relay_prefixlen));
> > + else
> > + relay_prefix = 0;
> > if (relay_prefix != ip6rd.relay_prefix)
> > goto done;
> >
>
>
> Sorry I dont get it
>
> u32 val = any_value ;
> u32 relay_prefix = val & htonl(0xffffffffUL << 32) should give 0
>
> If not, something is broken and should be fixed.
Unfortunately, on x86 architecture (80286 and later at least),
lower 5 bits (& 0x1f) are used for shift operation.
Thus, 0xffffffffUL << 32 gives 0xffffffffUL.
--yoshfuji
^ permalink raw reply
* kernel mode pppoe ppp if + ifb + mirred redirect, ethernet packets in ifb?!
From: Denys Fedoryschenko @ 2009-10-12 8:43 UTC (permalink / raw)
To: netdev, hadi
Hi
I am using kernel mode pppoe, and while using mirred on ppp interfaces (to
shape users upstream) noticed very strange behaviour (and IMHO wrong)
$2 - ppp interface
tc filter add dev $2 parent ffff: protocol ip prio 10 u32 \
match u32 0 0 flowid 1:1 \
action mirred egress redirect dev ifb0"
If i do tcpdump on ppp interface i can see normal ip traffic
PPPoE_146 ~ # tcpdump -ni ppp6 -c 100
tcpdump: WARNING:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp6, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
11:36:16.541742 IP 172.16.131.221.2182 > 64.4.50.51.443: Flags [F.], seq
2636760792, ack 2812561777, win 64963, length 0
If i do tcpdump on ifb0 i will see PPPoE incapsulated traffic!
PPPoE_146 ~ # tcpdump -ni ifb0 -c 100
tcpdump: WARNING: ifb0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ifb0, link-type EN10MB (Ethernet), capture size 96 bytes
11:36:58.949727 PPPoE [ses 0x15] IP 172.16.98.22.2081 > 94.75.218.20.80:
Flags [S], seq 3205622298, win 65535, options [mss 1440,nop,nop,sackOK],
length 0
11:36:58.531473 PPPoE [ses 0xd] IP 172.16.98.14.16526 > 128.16.130.164.445:
Flags [S], seq 98566173, win 65535, options [mss 1440,nop,nop,sackOK], length
0
Is it expected that redirecting ppp interface, that supposed to be clean IP
traffic is becoming eth encapsulated traffic?
Probably some bad interaction with kernel mode pppoe?
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Tilman Schmidt @ 2009-10-12 8:28 UTC (permalink / raw)
To: Johannes Berg
Cc: Dave Young, linux-kernel, tglx, linux-wireless, David S. Miller,
linux-ppp, netdev, Paul Mackerras
In-Reply-To: <1255261251.4095.143.camel@johannes.local>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[CCing PPP people]
Am 11.10.2009 13:40 schrieb Johannes Berg:
> On Sun, 2009-10-11 at 13:18 +0200, Tilman Schmidt wrote:
>
>> Can you explain a bit more what that message is about?
>> I am encountering it in a completely different context
>> (PPP over ISDN) [...]
>
> Basically, calling netif_rx() with softirqs enabled.
AFAICS that would have to be the netif_rx() call in
ppp_receive_nonmp_frame() [drivers/net/ppp_generic.c#L1791],
called (via others) from the tasklet work function
ppp_sync_process() [drivers/net/ppp_synctty.c#L545].
Should that be changed to the
"if (in_interrupt()) netif_rx(skb) else netif_rx_ni(skb)"
stanza from the linux.kernel.wireless.general thread then?
Thanks,
Tilman
- --
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFK0ujIQ3+did9BuFsRAtGBAJ9rj2pyQZ75ZKTipLhpICqA3ZvTdQCdHQs/
RmdeOT3TuPZykXJxcHLJCzU=
=87DI
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] [CAIF-RFC 1/8-v2] CAIF Protocol Stack
From: David Miller @ 2009-10-12 8:20 UTC (permalink / raw)
To: stefano.babic
Cc: sjur.brandeland, netdev, kim.xx.lilliestierna, christian.bejram,
daniel.martensson
In-Reply-To: <4AD2E404.80704@babic.homelinux.org>
From: Stefano Babic <stefano.babic@babic.homelinux.org>
Date: Mon, 12 Oct 2009 10:08:36 +0200
> sjur.brandeland@stericsson.com wrote:
>> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>> @@ -0,0 +1,203 @@
>> +/*
>> + * Copyright (C) ST-Ericsson AB 2009
>> + *
>> + * CAIF Channel Configuration definitions.
>> + *
>> + * Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
>> + *
>> + * License terms: GNU General Public License (GPL), version 2.
>
> In the majority of linux drivers we find the following statements to set
> up the license terms :
>
> * 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.
But Linus has stated explicitly that Linux itself falls under
GPL v2 and only v2.
See COPYING at the top level of the kernel sources.
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: David Miller @ 2009-10-12 8:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: yoshfuji, netdev
In-Reply-To: <4AD2DB99.3070208@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 12 Oct 2009 09:32:41 +0200
> Sorry I dont get it
>
> u32 val = any_value ;
> u32 relay_prefix = val & htonl(0xffffffffUL << 32) should give 0
>
> If not, something is broken and should be fixed.
Indeed, it's "x >> 32" which is undefined and has to be done as
something like "(x >> 31) >> 1" when performed on a u32 object.
Yoshfuji is this patch really necessary?
^ permalink raw reply
* Re: [PATCH] [CAIF-RFC 1/8-v2] CAIF Protocol Stack
From: Stefano Babic @ 2009-10-12 8:08 UTC (permalink / raw)
To: sjur.brandeland
Cc: netdev, kim.xx.lilliestierna, christian.bejram, daniel.martensson
In-Reply-To: <1255095571-6501-2-git-send-email-sjur.brandeland@stericsson.com>
sjur.brandeland@stericsson.com wrote:
> From: Sjur Braendeland <sjur.brandeland@stericsson.com>
>
> Change-Id: I305056f116a11c31265f65ac0fe285e2b655dd54
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
> ---
> include/linux/caif/caif_config.h | 203 ++++++++++++++++++++++++++++++++++++++
> include/linux/caif/caif_ioctl.h | 113 +++++++++++++++++++++
> 2 files changed, 316 insertions(+), 0 deletions(-)
> create mode 100644 include/linux/caif/caif_config.h
> create mode 100644 include/linux/caif/caif_ioctl.h
>
> diff --git a/include/linux/caif/caif_config.h b/include/linux/caif/caif_config.h
> new file mode 100644
> index 0000000..6ea934b
> --- /dev/null
> +++ b/include/linux/caif/caif_config.h
> @@ -0,0 +1,203 @@
> +/*
> + * Copyright (C) ST-Ericsson AB 2009
> + *
> + * CAIF Channel Configuration definitions.
> + *
> + * Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
> + *
> + * License terms: GNU General Public License (GPL), version 2.
In the majority of linux drivers we find the following statements to set
up the license terms :
* 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.
> + * \b Documentation see STE Doc No: 155 19-CRH 109 913.
Probably you should remove this line as you already did in other places.
> diff --git a/include/linux/caif/caif_ioctl.h b/include/linux/caif/caif_ioctl.h
> +/* Use 'g' as magic number. 'g' is the first free letter in
> + * Documentation/ioctl-number.txt*/
The file is Documentation/ioctl/ioctl-number.txt
Stefano
--
stefano <stefano.babic@babic.homelinux.org>
GPG Key: 0x55814DDE
Fingerprint 4E85 2A66 4CBA 497A 2A7B D3BF 5973 F216 5581 4DDE
^ permalink raw reply
* Re: bisect results of MSI-X related panic (help!)
From: Tejun Heo @ 2009-10-12 7:52 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Frans Pop, Jesse Brandeburg, linux-kernel, netdev, Ingo Molnar,
hpa
In-Reply-To: <4807377b0910091724k2a332e90i9941971f6032663c@mail.gmail.com>
Jesse Brandeburg wrote:
> Kernel stack is corrupted in: ffffffff810b5b31
>
> I've built with a full debug kernel before this crash, so I did:
>
> (gdb) l *0xffffffff810b5b31
> 0xffffffff810b5b31 is in move_native_irq (kernel/irq/migration.c:67).
> 62 return;
> 63
> 64 desc->chip->mask(irq);
> 65 move_masked_irq(irq);
> 66 desc->chip->unmask(irq);
>>>> 67 }
> 68
> (gdb) l move_native_irq
> 54 void move_native_irq(int irq)
> 55 {
> 56 struct irq_desc *desc = irq_to_desc(irq);
> 57
> 58 if (likely(!(desc->status & IRQ_MOVE_PENDING)))
> 59 return;
> 60
> 61 if (unlikely(desc->status & IRQ_DISABLED))
> 62 return;
> 63
> 64 desc->chip->mask(irq);
> 65 move_masked_irq(irq);
> 66 desc->chip->unmask(irq);
> 67 }
>
> So, this seems very related to my panic, as it is likely that
> irqbalance or something else might try to move my interrupt from one
> core to another and this seems likely related, and the original issue
> as well as this one reproduce with LOTS of MSI-X vectors active.
>
> - I tried connecting after the panic with kgdboc, no connection
> - I tried kdump, but the same kernel I am using panics/hangs during
> boot right after udev during the kexec() kernel boot (should I try
> harder to get this working given it got so far?)
> - I have ftrace function tracer running but no way to get at the log
> post panic (wouldn't it be great if the kernel just dumped the ftrace
> log on __stack_chk_fail?)
>
> any other debugging tricks/ideas?
Hmm... stackprotector adds considerable amount of stack usage and it
could be you're seeing stack overflow which would also explain the
random crashes you've been seeing. Do you have DEBUG_STACKOVERFLOW
turned on? This is on x86_64, right?
--
tejun
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: Eric Dumazet @ 2009-10-12 7:32 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: davem, netdev
In-Reply-To: <4AD1E169.6090705@linux-ipv6.org>
YOSHIFUJI Hideaki a écrit :
> ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
>
> Do not use bit-shift if relay_prefixlen == 0;
> relay_prefix << 32 does not result in 0.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> ---
> net/ipv6/sit.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> index 193d0c6..510d31f 100644
> --- a/net/ipv6/sit.c
> +++ b/net/ipv6/sit.c
> @@ -1014,9 +1014,12 @@ ipip6_tunnel_ioctl (struct net_device *dev, struct ifreq *ifr, int cmd)
> ip6rd.prefixlen);
> if (!ipv6_addr_equal(&prefix, &ip6rd.prefix))
> goto done;
> - relay_prefix = ip6rd.relay_prefix &
> - htonl(0xffffffffUL <<
> - (32 - ip6rd.relay_prefixlen));
> + if (ip6rd.relay_prefixlen)
> + relay_prefix = ip6rd.relay_prefix &
> + htonl(0xffffffffUL <<
> + (32 - ip6rd.relay_prefixlen));
> + else
> + relay_prefix = 0;
> if (relay_prefix != ip6rd.relay_prefix)
> goto done;
>
Sorry I dont get it
u32 val = any_value ;
u32 relay_prefix = val & htonl(0xffffffffUL << 32) should give 0
If not, something is broken and should be fixed.
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Kurt Van Dijck @ 2009-10-12 7:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Matt Domsch, netdev, linux-hotplug, Narendra_K, jordan_hargrave
In-Reply-To: <20091010113219.3136fb8b@s6510>
On Sat, Oct 10, 2009 at 11:32:19AM -0700, Stephen Hemminger wrote:
> > On Fri, Oct 09, 2009 at 07:44:01PM -0700, Stephen Hemminger wrote:
[...]
>
> Why isn't the available through sysfs enough, if not why not
> add the necessary attributes there.
True. If sysfs is not sufficient, what exact naming scheme could be
applied that the chardev based naming could use?
>
[...]
Kurt
^ permalink raw reply
* [PATCHv3] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:39 UTC (permalink / raw)
To: davem; +Cc: netdev
Use resource_size_t for PCI resource remapping instead
of unsigned long. Physical addresses can exceed range of
long data type (e.g with PAE).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9b9eab1..7fc15e9 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -595,7 +595,8 @@ netxen_setup_pci_map(struct netxen_adapter *adapter)
void __iomem *mem_ptr2 = NULL;
void __iomem *db_ptr = NULL;
- unsigned long mem_base, mem_len, db_base, db_len = 0, pci_len0 = 0;
+ resource_size_t mem_base, db_base;
+ unsigned long mem_len, db_len = 0, pci_len0 = 0;
struct pci_dev *pdev = adapter->pdev;
int pci_func = adapter->ahw.pci_func;
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCHv2] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091011.232203.41690616.davem@davemloft.net>
Huh, okay I was impatient. I will make one more attempt to pass the test.
Thanks.
David Miller wrote:
> I think I'll just ignore your patches for a while until
> you start to be a little bit less careless.
>
> Thanks.
>
^ permalink raw reply
* Re: [net-next PATCH 0/8] qlge: Cleanup and additions for qlge.
From: David Miller @ 2009-10-12 6:26 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1255203310-18114-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Sat, 10 Oct 2009 12:35:02 -0700
>
> Cleanup and a couple of small performance tweeks for qlge.
All applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCHv2] netxen: fix pci bar mapping
From: David Miller @ 2009-10-12 6:22 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1255328031-17189-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 11 Oct 2009 23:13:51 -0700
> Use phys_addr_t data type for pci resource address
> instead of unsigned long. This fixes mapping of
> pci resources where resource addresses can be larger
> than word size (e.g. PAE).
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Lazy, you didn't update the commit log message to match the
change you made to the patch.
I think I'll just ignore your patches for a while until
you start to be a little bit less careless.
Thanks.
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Bryan Kadzban @ 2009-10-12 6:21 UTC (permalink / raw)
To: Greg KH
Cc: Matt Domsch, Stephen Hemminger, netdev, linux-hotplug, Narendra_K,
jordan_hargrave
In-Reply-To: <20091010211352.GC1927@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]
Greg KH wrote:
> On Sat, Oct 10, 2009 at 10:34:16AM -0700, Bryan Kadzban wrote:
>> Greg KH wrote:
>>> On Sat, Oct 10, 2009 at 07:47:32AM -0500, Matt Domsch wrote:
>>>> On Fri, Oct 09, 2009 at 10:23:08PM -0700, Greg KH wrote:
>>>>> On Fri, Oct 09, 2009 at 11:40:57PM -0500, Matt Domsch wrote:
>>>>>> The fundamental roadblock to this is that enumeration !=
>>>>>> naming, except that it is for network devices, and we keep
>>>>>> changing the enumeration order.
>>>>> No, the hardware changes the enumeration order, it places
>>>>> _no_ guarantees on what order stuff will be found in. So
>>>>> this is not the kernel changing, just to be clear.
>>>> Over time the kernel has changed its enumeration mechanisms,
>>>> and introduced parallelism into the process (which is a good
>>>> thing), which, from a user perspective, makes names
>>>> nondeterministic. Yes, fixing this up by hard-coding MAC
>>>> addresses after install has been the traditional mechanism to
>>>> address this. I think there's a better way.
>>> Ok, but that way can be done in userspace, without the need for
>>> this char device, right?
>> For the record -- when I tried to send a patch that did exactly
>> this (provided an option to use by-path persistence for network
>> drivers), it was rejected because "that doesn't work for USB".
>>
>> True, it doesn't. But by-mac (what we have today) doesn't work for
>> replacing motherboards in a random home system (that can't override
>> the MAC address in the BIOS), either.
>
> If you replace a motherboard, you honestly expect no configuration to
> be needed to be changed? If so, then don't use the MAC naming scheme
> for your systems.
What else is there? biosdevname doesn't work with this BIOS. It looks
like at least path_id has been updated to work with NICs now, so that
might work, with a bit of custom rule hacking.
Or at least, it won't work any more poorly than for disks, which seem to
work pretty well... :-)
>>> But this code is not a requirement to "solve" the fact that
>>> network devices can show up in different order, that problem can
>>> be solved as long as the user picks a single way to name the
>>> devices, using tools that are already present today in distros.
>> This code is not a requirement, no. But -- as you say -- it does
>> provide a halfway-decent way to assign multiple names to a NIC.
>> And that provides admins the choice to use a couple different
>> persistence schemes, depending on how they expect their hardware to
>> work.
>
> But the names need to then be resolved back to a "real" kernel name
> in order to do anything with that network connection, as the char
> devices are not real ones. So that adds an additional layer of
> complexity on all of the system configuration tools.
Yes, that is true -- and no, this change isn't perfect. But it lets me
have multiple "names" per interface, and have "names" that are longer
than IFNAMSIZ, though, which is why I like it.
(Now, if open() would return effectively a netlink socket bound to that
ifindex already, such that the program didn't need to fill in the
various ifindex fields for e.g. rtnetlink... but it's probably really
hard to do that, so this isn't a serious suggestion.)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* [PATCHv2] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:13 UTC (permalink / raw)
To: davem; +Cc: netdev
Use phys_addr_t data type for pci resource address
instead of unsigned long. This fixes mapping of
pci resources where resource addresses can be larger
than word size (e.g. PAE).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9b9eab1..7fc15e9 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -595,7 +595,8 @@ netxen_setup_pci_map(struct netxen_adapter *adapter)
void __iomem *mem_ptr2 = NULL;
void __iomem *db_ptr = NULL;
- unsigned long mem_base, mem_len, db_base, db_len = 0, pci_len0 = 0;
+ resource_size_t mem_base, db_base;
+ unsigned long mem_len, db_len = 0, pci_len0 = 0;
struct pci_dev *pdev = adapter->pdev;
int pci_func = adapter->ahw.pci_func;
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091011.230656.245420067.davem@davemloft.net>
Ok, I am resending the patch.
Thanks,
Dhananjay
David Miller wrote:
> From: Dhananjay Phadke <dhananjay@netxen.com>
> Date: Sun, 11 Oct 2009 19:43:22 -0700
>
>> Use phys_addr_t data type for pci resource address
>> instead of unsigned long. This fixes mapping of
>> pci resources where resource addresses can be larger
>> than word size (e.g. PAE).
>>
>> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
>
> The correct type to use is 'resource_size_t' not 'phys_addr_t'.
>
> Look at the "struct resource" member types in linux/ioport.h, that's
> what these pci_resource_start() et al. routines return.
>
> Please fix this up and resubmit.
^ permalink raw reply
* Re: [net-next PATCH 1/8] qlge: Remove explicit setting of PCI Dev CTL reg.
From: David Miller @ 2009-10-12 6:10 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, root
In-Reply-To: <1255203310-18114-2-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Sat, 10 Oct 2009 12:35:03 -0700
> From: root <root@localhost.localdomain>
Ron I'm fixing this up by hand as I go through these qlge patches, but
please fix your config to emit a correct From: line in your patches.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: David Miller @ 2009-10-12 6:07 UTC (permalink / raw)
To: eric.dumazet
Cc: tomasw, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky,
tomas.winkler, joe
In-Reply-To: <4AD18C06.8040002@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 11 Oct 2009 09:40:54 +0200
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e1da925..18244ad 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3654,6 +3654,7 @@ NETWORKING [GENERAL]
> M: "David S. Miller" <davem@davemloft.net>
> L: netdev@vger.kernel.org
> W: http://www.linuxfoundation.org/en/Net
> +W: http://patchwork.ozlabs.org/project/netdev/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
> S: Maintained
> F: net/
I've applied this, thanks Eric.
^ 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