* [PATCH 0/3 #2] avoid pci_find_device
From: Jiri Slaby @ 2006-05-26 0:07 UTC (permalink / raw)
To: Greg KH
Cc: Linux Kernel Mailing List, linux-pci, jgarzik, netdev, khali,
lm-sensors, stevel, source, mb, st3, linville
Hello,
there are some patches to avoid pci_find_device in drivers, next will come in
future.
Take #2.
It's against 2.6.17-rc4-mm3 tree.
01-i2c-scx200-acb-avoid-pci-find-device.patch
02-bcm43xx-avoid-pci-find-device.patch
03-gt96100eth-avoid-pci-find-device.patch
i2c/busses/scx200_acb.c | 9 ++++++---
net/gt96100eth.c | 10 +++++++---
net/wireless/bcm43xx/bcm43xx_main.c | 20 ++++++++++++++++----
3 files changed, 29 insertions(+), 10 deletions(-)
Thanks.
^ permalink raw reply
* Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
From: Jeff Garzik @ 2006-05-26 0:35 UTC (permalink / raw)
To: Jiri Slaby
Cc: Greg KH, Linux Kernel Mailing List, linux-pci, netdev, mb, st3,
linville
In-Reply-To: <20060526001053.D2349C7C58@atrey.karlin.mff.cuni.cz>
Jiri Slaby wrote:
> bcm43xx avoid pci_find_device
>
> Change pci_find_device to safer pci_get_device with support for more
> devices.
>
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
>
> ---
> commit 1d3b6caf027fe53351c645523587aeac40bc3e47
> tree ae37c86b633442cdf8a7a19ac287542724081c90
> parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
> author Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006 01:49:12 +0159
> committer Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006 01:49:12 +0159
>
> drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20 ++++++++++++++++----
> 1 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> index b488f77..56d2fc6 100644
> --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> @@ -2131,6 +2131,13 @@ out:
> return err;
> }
>
> +#ifdef CONFIG_BCM947XX
> +static struct pci_device_id bcm43xx_ids[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
> + { 0 }
> +};
> +#endif
> +
> static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
> {
> int res;
> @@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
> #ifdef CONFIG_BCM947XX
> if (bcm->pci_dev->bus->number == 0) {
> struct pci_dev *d = NULL;
> - /* FIXME: we will probably need more device IDs here... */
> - d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
> - if (d != NULL) {
> - bcm->irq = d->irq;
> + struct pci_device_id *id = bcm43xx_ids;
> + while (id->vendor) {
> + d = pci_get_device(id->vendor, id->device, NULL);
> + if (d != NULL) {
> + bcm->irq = d->irq;
> + pci_dev_put(d);
> + break;
You'll want to use pci_match_device() or pci_match_one_device()
[I forget which one]
Jeff
^ permalink raw reply
* Re: [PATCH 3/3] pci: gt96100eth avoid pci_find_device
From: Jeff Garzik @ 2006-05-26 0:37 UTC (permalink / raw)
To: Jiri Slaby
Cc: Greg KH, Linux Kernel Mailing List, linux-pci, netdev, stevel,
source
In-Reply-To: <20060526001155.4828DC7C5E@atrey.karlin.mff.cuni.cz>
Jiri Slaby wrote:
> gt96100eth avoid pci_find_device
>
> Change pci_find_device to safer pci_get_device.
>
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
>
> ---
> commit f656671e9da9d33bd7a2fb3f5c0d0f7009925698
> tree b92c808b6a9eecce58b0f7b0ffe1237631dbd65a
> parent 1d3b6caf027fe53351c645523587aeac40bc3e47
> author Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006 01:55:23 +0159
> committer Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006 01:55:23 +0159
>
> drivers/net/gt96100eth.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/gt96100eth.c b/drivers/net/gt96100eth.c
> index 2d24354..beac56d 100644
> --- a/drivers/net/gt96100eth.c
> +++ b/drivers/net/gt96100eth.c
> @@ -613,9 +613,9 @@ static int gt96100_init_module(void)
> /*
> * Stupid probe because this really isn't a PCI device
> */
> - if (!(pci = pci_find_device(PCI_VENDOR_ID_MARVELL,
> + if (!(pci = pci_get_device(PCI_VENDOR_ID_MARVELL,
> PCI_DEVICE_ID_MARVELL_GT96100, NULL)) &&
> - !(pci = pci_find_device(PCI_VENDOR_ID_MARVELL,
> + !(pci = pci_get_device(PCI_VENDOR_ID_MARVELL,
> PCI_DEVICE_ID_MARVELL_GT96100A, NULL))) {
> printk(KERN_ERR __FILE__ ": GT96100 not found!\n");
> return -ENODEV;
Seems OK to me, though you may wish to use a pci_device_id list with
pci_match_[one_]device() here too.
Jeff
^ permalink raw reply
* Re: [Bugme-new] [Bug 6610] New: dummy interface broadcast destination hardware address is not ff:ff:ff:ff:ff:ff
From: Herbert Xu @ 2006-05-26 0:43 UTC (permalink / raw)
To: David Miller; +Cc: akpm, bugme-daemon, netdev
In-Reply-To: <20060525.151602.102574435.davem@davemloft.net>
On Thu, May 25, 2006 at 03:16:02PM -0700, David Miller wrote:
>
> Perhaps RTN_BROADCAST should take precedence over IFF_NOARP
> (but not IFF_LOOPBACK)? I'm talking about the code in
> net/ipv4/arp.c that causes this behavior.
Sure, I don't see any harm in that.
However, I'm curious as to the purpose of all this. What application
is there for sending broadcasts through a dummy device with the
Ethernet broadcast address?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 6610] New: dummy interface broadcast destination hardware address is not ff:ff:ff:ff:ff:ff
From: David Miller @ 2006-05-26 1:18 UTC (permalink / raw)
To: herbert; +Cc: akpm, bugme-daemon, netdev
In-Reply-To: <20060526004324.GA762@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 26 May 2006 10:43:24 +1000
> On Thu, May 25, 2006 at 03:16:02PM -0700, David Miller wrote:
> >
> > Perhaps RTN_BROADCAST should take precedence over IFF_NOARP
> > (but not IFF_LOOPBACK)? I'm talking about the code in
> > net/ipv4/arp.c that causes this behavior.
>
> Sure, I don't see any harm in that.
>
> However, I'm curious as to the purpose of all this. What application
> is there for sending broadcasts through a dummy device with the
> Ethernet broadcast address?
Good point. dummy is just a black hole to point routes to
while your real connection is down.
Running tcpdump on it and having any kind of expectations
about broadcast addresses and whatnot is pointless.
^ permalink raw reply
* Re: ipv6 routing broken in 2.6.17-rc3,4
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-05-26 1:40 UTC (permalink / raw)
To: mroos; +Cc: pekkas, netdev, yoshfuji
In-Reply-To: <Pine.SOC.4.61.0605260219270.13718@math.ut.ee>
In article <Pine.SOC.4.61.0605260219270.13718@math.ut.ee> (at Fri, 26 May 2006 02:24:19 +0300 (EEST)), Meelis Roos <mroos@linux.ee> says:
>
> (To YOSHIFUJI Hideaki: this is about the
> http://comments.gmane.org/gmane.linux.network/35262 thread)
>
> Tracked it down to IPV6 merge at 2006-03-21:
> commit cd85f6e2f58282186ad720fc18482be228f0b972 is good (right before
> the bunch of patches)
> commit b00055aacdb172c05067612278ba27265fcd05ce is bad (right after the
> bunch of changes)
I guess rt6_select() is returning &ip6_null_entry and
the caller is finding next best route; e.g. default route.
Does this solve your problem?
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 0190e39..93eb33c 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -280,10 +280,12 @@ static int inline rt6_check_neigh(struct
{
struct neighbour *neigh = rt->rt6i_nexthop;
int m = 0;
- if (neigh) {
+ if (rt->rt6i_flags & RTF_NONEXTHOP)
+ m = 1;
+ else if (neigh) {
read_lock_bh(&neigh->lock);
if (neigh->nud_state & NUD_VALID)
- m = 1;
+ m = 2;
read_unlock_bh(&neigh->lock);
}
return m;
@@ -292,15 +294,18 @@ static int inline rt6_check_neigh(struct
static int rt6_score_route(struct rt6_info *rt, int oif,
int strict)
{
- int m = rt6_check_dev(rt, oif);
+ int m, n
+
+ m = rt6_check_dev(rt, oif);
if (!m && (strict & RT6_SELECT_F_IFACE))
return -1;
#ifdef CONFIG_IPV6_ROUTER_PREF
m |= IPV6_DECODE_PREF(IPV6_EXTRACT_PREF(rt->rt6i_flags)) << 2;
#endif
- if (rt6_check_neigh(rt))
+ n = rt6_check_neigh(rt);
+ if (n > 1)
m |= 16;
- else if (strict & RT6_SELECT_F_REACHABLE)
+ else if (!n && strict & RT6_SELECT_F_REACHABLE)
return -1;
return m;
}
^ permalink raw reply related
* Re: [PATCH 0/9] Resending NetXen 1G/10G NIC driver patch
From: Amit S. Kale @ 2006-05-26 5:46 UTC (permalink / raw)
To: Stephen Hemminger, Roland Dreier; +Cc: netdev, sanjeev, unmproj
In-Reply-To: <Pine.LNX.4.33.0605250339490.5844-100000@unmsrvr>
Stephen, Roland,
Thanks a lot for feedback.
We'll implement the minor changes rightaway and post an update. We are also
thinking about what's the best way to incorporate the data structure changes
you have suggested. Will post a reply on that too soon.
-Amit
On Thursday 25 May 2006 16:15, Linsys Contractor Amit S. Kale wrote:
> Hi,
>
> I'll be sending a NetXen (formerly Universal Network Machines) 1G/10G in
> subsequent emails. This is a revised version of the UNM driver posted
> earlier. We have tried to make changes as per the feedback received.
> We would like this driver to be inluded in mainline kernel.
> Kindly review it and feel free to get back to me for any further
> feedback/queries/comments.
>
> Thanks.
> -Amit
>
> Signed-off-by: Amit S. Kale <amitkale@unminc.com>
>
> Kconfig | 5
> Makefile | 1
> netxen/Makefile | 35 +
> netxen/netxen_nic.h | 950 +++++++++++++++++++++++++++++++
> netxen/netxen_nic_ethtool.c | 802 ++++++++++++++++++++++++++
> netxen/netxen_nic_hdr.h | 682 ++++++++++++++++++++++
> netxen/netxen_nic_hw.c | 1289
> +++++++++++++++++++++++++++++++++++++++++++ netxen/netxen_nic_hw.h |
> 339 +++++++++++
> netxen/netxen_nic_init.c | 1219
> ++++++++++++++++++++++++++++++++++++++++ netxen/netxen_nic_ioctl.h |
> 75 ++
> netxen/netxen_nic_isr.c | 428 ++++++++++++++
> netxen/netxen_nic_main.c | 1209
> ++++++++++++++++++++++++++++++++++++++++ netxen/netxen_nic_niu.c |
> 770 +++++++++++++++++++++++++
> netxen/netxen_nic_phan_reg.h | 195 ++++++
> 14 files changed, 7999 insertions(+)
^ permalink raw reply
* RE: [PATCH] TCP Veno module for kernel 2.6.16.13
From: Fu Cheng Peng, Franklin @ 2006-05-26 6:32 UTC (permalink / raw)
To: davem; +Cc: shemminger, baruch, jmorris, netdev, #ZHOU BIN#
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Friday, May 26, 2006 4:24 AM
>To: #ZHOU BIN#
>Cc: shemminger@osdl.org; baruch@ev-en.org; jmorris@namei.org;
netdev@vger.kernel.org
>Subject: Re: [PATCH] TCP Veno module for kernel 2.6.16.13
>
>
>From: "#ZHOU BIN#" <ZHOU0022@ntu.edu.sg>
>Date: Thu, 25 May 2006 16:30:48 +0800
>
>> Yes, I agree. Actually the main contribution of TCP Veno is not in
>> this AI phase. No matter the ABC is added or not, TCP Veno can always
>> improve the performance over wireless networks, according to our
>> tests.
>
>It seems to me that the wireless issue is seperate from congestion
control.
>
>The key is to identify "true loss" due to overflow of intermediate
router queues, vs. "false loss" which is due to
>temporary radio signal interference.
Quite agree
>
>This determination is a job for the loss detection in the generic ACK
processing code in tcp_input.c, not for a
>congestion control algorithm.
>The congestion control algorithm uses the "true loss" information to
make congestion control decisions.
That is right, TCP Veno has two parts: one contribution is the smart
detection of congestion loss and random loss, another contribution part
is how to use this information perform congestion control intelligently.
The original veno paper in IEEE JSAC 2003 and many verified work can be
accessed on http://www.ntu.edu.sg/home/ascpfu/veno/veno.html
>We already have code that tries to make this differentiation, in the
form of FRTO, and your techniques can likely be
>placed there as well.
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Phil Dibowitz @ 2006-05-26 6:48 UTC (permalink / raw)
To: Brian Haley; +Cc: hadi, netdev, David Miller, Jeff Garzik
In-Reply-To: <4474C5A7.2070703@hp.com>
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
Brian Haley wrote:
> jamal wrote:
>> On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote:
>>
>>> Right, I'm aware there are other ways of doing this - I've written
>>> scripts to
>>> record a hundreds of numbers, and then subtract them from each other.
>>> But
>>> those scripts are work arounds
>
> I don't have any problem with Phil's changes.
OK - well, I think the discussion is over now...
But for those that are interested, I've posted the patches (and I
cleaned up the ethtool patch), as well as a README and FAQ here:
http://phildev.net/linux/patches/
A handful of people have expressed interest to me off-list, so we'll see
how that interest pans out. But in the meantime, you can find the
latest-and-greatest version there.
--
Phil Dibowitz phil@ipom.com
Freeware and Technical Pages Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Be who you are and say what you feel, because those who mind don't
matter and those who matter don't mind."
- Dr. Seuss
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] ixgb: driver update to 1.0.104-k4
From: Jeff Garzik @ 2006-05-26 7:03 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev, Brandeburg, Jesse, Kok, Auke
In-Reply-To: <20060525202532.25618.58162.stgit@gitlost.site>
Kok, Auke wrote:
> Hi,
>
> This is another resend of patches sent earlier by Jeff Kirsher and
> completes the resend for 1.0.104-kX.
>
>
> Summary:
>
> [1] add performance enhancements to the buffer_info struct
> [2] implement copybreak
> [3] increment version to 1.0.104-k4
>
>
> These changes are available through git.
>
> git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 ixgb-1.0.104-k4
pulled
^ permalink raw reply
* Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
From: Meelis Roos @ 2006-05-26 7:11 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <4475FCFC.5000701@trash.net>
> Meelis, it would really help if you could try 2.6.16 and in case
> that doesn't work 2.6.15 to give an idea about whether this is a
> recent regression or an old problem. We had a number of changes
> in this area in the last two kernel versions that could be related.
Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out
remotely at the moment. Will see if I can find the boot cure - there
used to be a Motorola Powerstack-specific patch to make it boot that
Debian 2.6.18 and IIRC 2.6.12 packages included and that was integrated
somewhere later - maybe it's missing fom 2.6.15.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: ipv6 routing broken in 2.6.17-rc3,4
From: Meelis Roos @ 2006-05-26 8:35 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: pekkas, netdev
In-Reply-To: <20060526.104245.106225873.yoshfuji@linux-ipv6.org>
>>> (To YOSHIFUJI Hideaki: this is about the
>>> http://comments.gmane.org/gmane.linux.network/35262 thread)
> :
>> I guess rt6_select() is returning &ip6_null_entry and
>> the caller is finding next best route; e.g. default route.
>>
>> Does this solve your problem?
>
> Sorry, typo...
The unreachable route works now but LAN routing still does not work.
Locally generated ICMPv6 packets that should go to LAN interface still
go to tun6to4.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH v2] bridge: fix locking and memory leak in br_add_bridge
From: Jiri Benc @ 2006-05-26 9:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, NetDev
In-Reply-To: <20060525092331.54f14a57@dxpl.pdx.osdl.net>
On Thu, 25 May 2006 09:23:31 -0700, Stephen Hemminger wrote:
> + unregister_netdevice(dev);
> + err:
> rtnl_unlock();
> + if (ret)
> + free_netdev(dev);
> return ret;
I don't think this is correct. netdev_run_todo calls dev->destructor
which is set to free_netdev by br_dev_setup. So you're calling
free_netdev on already freed device.
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Andi Kleen @ 2006-05-26 9:46 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Brent Cook, Phil Dibowitz, David Miller, netdev
In-Reply-To: <4474BD52.6020604@garzik.org>
On Wednesday 24 May 2006 22:08, Jeff Garzik wrote:
> Brent Cook wrote:
> > Note that this is just clearing the hardware statistics on the interface, and
> > would not require any kind of atomic_increment addition for interfaces that
> > support that. It would be kind-of awkward to implement this on drivers that
> > increment stats in hardware though (lo, vlan, br, etc.) This also brings up
> > the question of resetting the stats for 'netstat -s'
>
> If you don't atomically clear the statistics, then you are leaving open
> a window where the stats could easily be corrupted, if the network
> interface is under load.
It could be handled by RCU with some moderately complex code
(clear and clear again after a RCU quiescent period)
But the real problem is that the user will always miss events during
the clear operation. That is why it is inherently racy.
An atomic user visible get-and-clear wouldn't have this problem, but it would be probably
nasty to implement lockless without risking livelock on a busy system. And
I also doubt it would have a nice user interface in the file system.
And really is it that hard to do a before-after diff? I don't think so.
>
> See... this opens doors to tons of complexity.
Agreed.
-Andi
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Andi Kleen @ 2006-05-26 9:43 UTC (permalink / raw)
To: Phil Dibowitz; +Cc: David Miller, netdev
In-Reply-To: <447412CA.50303@ipom.com>
On Wednesday 24 May 2006 10:01, Phil Dibowitz wrote:
> David Miller wrote:
> > Some time in the next few weeks, it is likely that the 2.6.18
> > merge window will open up shortly after a 2.6.17 release.
> >
> > So if you have major 2.6.18 submissions planned for the networking,
> > you need to start thinking about getting it to me now.
> >
> > There is a 2.6.18 tree up at:
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.18.git
> >
> > All it has right now is the I/O AT stuff at the moment, and I plan to
> > put Stephen Hemminger's LLC multicast/datagram changes in there as
> > well.
>
> David,
>
> I posted a patch for adding support for network device statistic
> resetting via ethtool. I saw no objections to it...
I think it's a bad idea because it's inherently racey
(I think I objected originally too)
Similar patches were rejected a couple of times over the years already.
> I'd like to get this into 2.6.18. It's self-contained, so it has little
> chance of breaking other things and adds a useful feature that I've seen
> a lot of requests for.
It's broken by design.
-Andi
^ permalink raw reply
* Re: [PATCH 3/4] myri10ge - Driver core
From: Ingo Oeser @ 2006-05-26 9:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Anton Blanchard, Brice Goglin, netdev, gallatin, linux-kernel
In-Reply-To: <1148543810.13249.265.camel@localhost.localdomain>
Hi there,
Benjamin Herrenschmidt wrote:
> On Wed, 2006-05-24 at 01:39 +1000, Anton Blanchard wrote:
>
> > > +#ifdef CONFIG_MTRR
> > > + mgp->mtrr = mtrr_add(mgp->iomem_base, mgp->board_span,
> > > + MTRR_TYPE_WRCOMB, 1);
> > > +#endif
> > ...
> > > + mgp->sram = ioremap(mgp->iomem_base, mgp->board_span);
> >
> > Not sure how we are meant to specify write through in drivers. Any ideas Ben?
>
> No proper interface exposed, he'll have to do an #ifdef powerpc here or
> such and use __ioremap with explicit page attributes. I have a hack to
> do that automatically for memory covered by prefetchable PCI BARs when
> mmap'ing from userland but not for kernel ioremap.
Stupid question: pci_iomap() is NOT what you are looking for, right?
Implementation is at the end of lib/iomap.c
Regards
Ingo Oeser
^ permalink raw reply
* Re: reminder, 2.6.18 window...
From: Andi Kleen @ 2006-05-26 9:52 UTC (permalink / raw)
To: Brent Cook; +Cc: Bill Fink, Jeff Garzik, phil, davem, netdev
In-Reply-To: <200605250805.38241.bcook@bpointsys.com>
> The current patch is fine if your hardware implements the required atomicity
> itself.
Near all do optionally, but it would make increasing the statistics a magnitude
more expensive.
Atomic operations don't come cheap on modern systems. And you would need
to change the fast path increments to atomic for this.
I suspect it could be done without atomics with some tricks (e.g. use a double
set of counters and switch on clear and use RCU), but it would make the whole
thing quite complex and still have more overhead in the fast path than
the current code.
-Andi
^ permalink raw reply
* Re: [PATCH 3/4] myri10ge - Driver core
From: Benjamin Herrenschmidt @ 2006-05-26 10:02 UTC (permalink / raw)
To: Ingo Oeser; +Cc: Anton Blanchard, Brice Goglin, netdev, gallatin, linux-kernel
In-Reply-To: <200605261149.18415.netdev@axxeo.de>
> > No proper interface exposed, he'll have to do an #ifdef powerpc here or
> > such and use __ioremap with explicit page attributes. I have a hack to
> > do that automatically for memory covered by prefetchable PCI BARs when
> > mmap'ing from userland but not for kernel ioremap.
>
> Stupid question: pci_iomap() is NOT what you are looking for, right?
>
> Implementation is at the end of lib/iomap.c
No, there is no difference there, pci_iomap won't help for passing in
platform specific page attributes for things like write combining.
Ben.
^ permalink raw reply
* Re: ipv6 routing broken in 2.6.17-rc3,4
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-05-26 10:08 UTC (permalink / raw)
To: mroos; +Cc: pekkas, netdev, yoshfuji
In-Reply-To: <Pine.SOC.4.61.0605261134250.18708@math.ut.ee>
In article <Pine.SOC.4.61.0605261134250.18708@math.ut.ee> (at Fri, 26 May 2006 11:35:53 +0300 (EEST)), Meelis Roos <mroos@linux.ee> says:
> The unreachable route works now but LAN routing still does not work.
> Locally generated ICMPv6 packets that should go to LAN interface still
> go to tun6to4.
Please try this.
----
[IPV6] ROUTE: Don't try less preferred routes for on-link routes.
In addition to the real on-link routes, NONEXTHOP routes
should be considered on-link.
Problem reported by Meelis Roos <mroos@linux.ee>.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 0190e39..8a77793 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -280,10 +280,13 @@ static int inline rt6_check_neigh(struct
{
struct neighbour *neigh = rt->rt6i_nexthop;
int m = 0;
- if (neigh) {
+ if (rt->rt6i_flags & RTF_NONEXTHOP ||
+ !(rt->rt6i_flags & RTF_GATEWAY))
+ m = 1;
+ else if (neigh) {
read_lock_bh(&neigh->lock);
if (neigh->nud_state & NUD_VALID)
- m = 1;
+ m = 2;
read_unlock_bh(&neigh->lock);
}
return m;
@@ -292,15 +295,18 @@ static int inline rt6_check_neigh(struct
static int rt6_score_route(struct rt6_info *rt, int oif,
int strict)
{
- int m = rt6_check_dev(rt, oif);
+ int m, n;
+
+ m = rt6_check_dev(rt, oif);
if (!m && (strict & RT6_SELECT_F_IFACE))
return -1;
#ifdef CONFIG_IPV6_ROUTER_PREF
m |= IPV6_DECODE_PREF(IPV6_EXTRACT_PREF(rt->rt6i_flags)) << 2;
#endif
- if (rt6_check_neigh(rt))
+ n = rt6_check_neigh(rt);
+ if (n > 1)
m |= 16;
- else if (strict & RT6_SELECT_F_REACHABLE)
+ else if (!n && strict & RT6_SELECT_F_REACHABLE)
return -1;
return m;
}
--yoshfuji
^ permalink raw reply related
* Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
From: Jiri Slaby @ 2006-05-26 10:20 UTC (permalink / raw)
To: Jeff Garzik
Cc: Greg KH, Linux Kernel Mailing List, linux-pci, netdev, mb, st3,
linville
In-Reply-To: <44764D4B.6050105@pobox.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeff Garzik napsal(a):
> Jiri Slaby wrote:
>> bcm43xx avoid pci_find_device
>>
>> Change pci_find_device to safer pci_get_device with support for more
>> devices.
>>
>> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
>>
>> ---
>> commit 1d3b6caf027fe53351c645523587aeac40bc3e47
>> tree ae37c86b633442cdf8a7a19ac287542724081c90
>> parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
>> author Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006 01:49:12
>> +0159
>> committer Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006
>> 01:49:12 +0159
>>
>> drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20 ++++++++++++++++----
>> 1 files changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> index b488f77..56d2fc6 100644
>> --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>> @@ -2131,6 +2131,13 @@ out:
>> return err;
>> }
>>
>> +#ifdef CONFIG_BCM947XX
>> +static struct pci_device_id bcm43xx_ids[] = {
>> + { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
>> + { 0 }
>> +};
>> +#endif
>> +
>> static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
>> {
>> int res;
>> @@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
>> #ifdef CONFIG_BCM947XX
>> if (bcm->pci_dev->bus->number == 0) {
>> struct pci_dev *d = NULL;
>> - /* FIXME: we will probably need more device IDs here... */
>> - d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
>> - if (d != NULL) {
>> - bcm->irq = d->irq;
>> + struct pci_device_id *id = bcm43xx_ids;
>> + while (id->vendor) {
>> + d = pci_get_device(id->vendor, id->device, NULL);
>> + if (d != NULL) {
>> + bcm->irq = d->irq;
>> + pci_dev_put(d);
>> + break;
>
> You'll want to use pci_match_device() or pci_match_one_device()
> [I forget which one]
Why? Matching is done by pci_get_device() or pci_get_subsys(), respectively.
[pci_match_device() is for matching dev <-> drv, you meant pci_match_one_device()]
thanks,
- --
Jiri Slaby www.fi.muni.cz/~xslaby
\_.-^-._ jirislaby@gmail.com _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEdtY+MsxVwznUen4RAkmFAJ9FFm6nCgnGCdZAcPqv2H99rBNMzwCeK3DA
nPBv8s+ldDrSOpin+mGdDdg=
=MBag
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
From: Jeff Garzik @ 2006-05-26 10:22 UTC (permalink / raw)
To: Jiri Slaby
Cc: Greg KH, Linux Kernel Mailing List, linux-pci, netdev, mb, st3,
linville
In-Reply-To: <4476D63E.8090207@gmail.com>
Jiri Slaby wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeff Garzik napsal(a):
>> Jiri Slaby wrote:
>>> bcm43xx avoid pci_find_device
>>>
>>> Change pci_find_device to safer pci_get_device with support for more
>>> devices.
>>>
>>> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
>>>
>>> ---
>>> commit 1d3b6caf027fe53351c645523587aeac40bc3e47
>>> tree ae37c86b633442cdf8a7a19ac287542724081c90
>>> parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
>>> author Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006 01:49:12
>>> +0159
>>> committer Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006
>>> 01:49:12 +0159
>>>
>>> drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20 ++++++++++++++++----
>>> 1 files changed, 16 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>> b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>> index b488f77..56d2fc6 100644
>>> --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>> @@ -2131,6 +2131,13 @@ out:
>>> return err;
>>> }
>>>
>>> +#ifdef CONFIG_BCM947XX
>>> +static struct pci_device_id bcm43xx_ids[] = {
>>> + { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
>>> + { 0 }
>>> +};
>>> +#endif
>>> +
>>> static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
>>> {
>>> int res;
>>> @@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
>>> #ifdef CONFIG_BCM947XX
>>> if (bcm->pci_dev->bus->number == 0) {
>>> struct pci_dev *d = NULL;
>>> - /* FIXME: we will probably need more device IDs here... */
>>> - d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
>>> - if (d != NULL) {
>>> - bcm->irq = d->irq;
>>> + struct pci_device_id *id = bcm43xx_ids;
>>> + while (id->vendor) {
>>> + d = pci_get_device(id->vendor, id->device, NULL);
>>> + if (d != NULL) {
>>> + bcm->irq = d->irq;
>>> + pci_dev_put(d);
>>> + break;
>> You'll want to use pci_match_device() or pci_match_one_device()
>> [I forget which one]
> Why? Matching is done by pci_get_device() or pci_get_subsys(), respectively.
> [pci_match_device() is for matching dev <-> drv, you meant pci_match_one_device()]
The FIXME says "we will probably need more device IDs here."
Thus, if you are touching this area, it would make sense to add the
capability to easily add a second (and third, fourth...) PCI ID. And
that means pci_match_one_device() and a pci_device_id table.
Jeff
^ permalink raw reply
* Re: [PATCH 3/4] myri10ge - Driver core
From: Jeff Garzik @ 2006-05-26 10:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Ingo Oeser, Anton Blanchard, Brice Goglin, netdev, gallatin,
linux-kernel
In-Reply-To: <1148637720.8089.145.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
>>> No proper interface exposed, he'll have to do an #ifdef powerpc here or
>>> such and use __ioremap with explicit page attributes. I have a hack to
>>> do that automatically for memory covered by prefetchable PCI BARs when
>>> mmap'ing from userland but not for kernel ioremap.
>> Stupid question: pci_iomap() is NOT what you are looking for, right?
>>
>> Implementation is at the end of lib/iomap.c
>
> No, there is no difference there, pci_iomap won't help for passing in
> platform specific page attributes for things like write combining.
Since we already have ioremap_nocache(), maybe adding ioremap_wcomb() is
appropriate?
Jeff
^ permalink raw reply
* Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
From: Jiri Slaby @ 2006-05-26 10:33 UTC (permalink / raw)
To: Jeff Garzik
Cc: Greg KH, Linux Kernel Mailing List, linux-pci, netdev, mb, st3,
linville
In-Reply-To: <4476D6EC.4060501@pobox.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeff Garzik napsal(a):
> Jiri Slaby wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Jeff Garzik napsal(a):
>>> Jiri Slaby wrote:
>>>> bcm43xx avoid pci_find_device
>>>>
>>>> Change pci_find_device to safer pci_get_device with support for more
>>>> devices.
>>>>
>>>> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
>>>>
>>>> ---
>>>> commit 1d3b6caf027fe53351c645523587aeac40bc3e47
>>>> tree ae37c86b633442cdf8a7a19ac287542724081c90
>>>> parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
>>>> author Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006 01:49:12
>>>> +0159
>>>> committer Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006
>>>> 01:49:12 +0159
>>>>
>>>> drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20
>>>> ++++++++++++++++----
>>>> 1 files changed, 16 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>>> b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>>> index b488f77..56d2fc6 100644
>>>> --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>>> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>>> @@ -2131,6 +2131,13 @@ out:
>>>> return err;
>>>> }
>>>>
>>>> +#ifdef CONFIG_BCM947XX
>>>> +static struct pci_device_id bcm43xx_ids[] = {
>>>> + { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
>>>> + { 0 }
>>>> +};
Table is here ^^^. You just add an entry, and that's it.
>>>> +#endif
>>>> +
>>>> static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
>>>> {
>>>> int res;
>>>> @@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
>>>> #ifdef CONFIG_BCM947XX
>>>> if (bcm->pci_dev->bus->number == 0) {
>>>> struct pci_dev *d = NULL;
>>>> - /* FIXME: we will probably need more device IDs here... */
>>>> - d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
>>>> - if (d != NULL) {
>>>> - bcm->irq = d->irq;
>>>> + struct pci_device_id *id = bcm43xx_ids;
>>>> + while (id->vendor) {
>>>> + d = pci_get_device(id->vendor, id->device, NULL);
>>>> + if (d != NULL) {
>>>> + bcm->irq = d->irq;
>>>> + pci_dev_put(d);
>>>> + break;
>>> You'll want to use pci_match_device() or pci_match_one_device()
>>> [I forget which one]
>> Why? Matching is done by pci_get_device() or pci_get_subsys(),
>> respectively.
>> [pci_match_device() is for matching dev <-> drv, you meant
>> pci_match_one_device()]
>
> The FIXME says "we will probably need more device IDs here."
Yup.
>
> Thus, if you are touching this area, it would make sense to add the
> capability to easily add a second (and third, fourth...) PCI ID. And
> that means pci_match_one_device() and a pci_device_id table.
But the while loop do the work: unless id->vendor != NULL, do the matching with
the current raw (id) of the table, then jump to the next raw (id++).
pci_get_device returns NULL if the device with id->vendor, id->device wasn't
found, then we try next raw, otherwise, we break the loop.
Implementations before and now do the same strangeness -- assume there is only
one device (?shouldn't matter?, since it is embedded).
cheers,
- --
Jiri Slaby www.fi.muni.cz/~xslaby
\_.-^-._ jirislaby@gmail.com _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEdtlbMsxVwznUen4RAo/OAJsHy6sED+a9QYmbcaGTMUjwSYm4vACgwfQL
GhmfbtwskPB3Dnvw8HfJzpE=
=+kxv
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
From: Jeff Garzik @ 2006-05-26 10:37 UTC (permalink / raw)
To: Jiri Slaby
Cc: Greg KH, Linux Kernel Mailing List, linux-pci, netdev, mb, st3,
linville
In-Reply-To: <4476D95B.5030601@gmail.com>
Jiri Slaby wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeff Garzik napsal(a):
>> Jiri Slaby wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Jeff Garzik napsal(a):
>>>> Jiri Slaby wrote:
>>>>> bcm43xx avoid pci_find_device
>>>>>
>>>>> Change pci_find_device to safer pci_get_device with support for more
>>>>> devices.
>>>>>
>>>>> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
>>>>>
>>>>> ---
>>>>> commit 1d3b6caf027fe53351c645523587aeac40bc3e47
>>>>> tree ae37c86b633442cdf8a7a19ac287542724081c90
>>>>> parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
>>>>> author Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006 01:49:12
>>>>> +0159
>>>>> committer Jiri Slaby <ku@bellona.localdomain> Fri, 26 May 2006
>>>>> 01:49:12 +0159
>>>>>
>>>>> drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20
>>>>> ++++++++++++++++----
>>>>> 1 files changed, 16 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>>>> b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>>>> index b488f77..56d2fc6 100644
>>>>> --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>>>> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
>>>>> @@ -2131,6 +2131,13 @@ out:
>>>>> return err;
>>>>> }
>>>>>
>>>>> +#ifdef CONFIG_BCM947XX
>>>>> +static struct pci_device_id bcm43xx_ids[] = {
>>>>> + { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
>>>>> + { 0 }
>>>>> +};
> Table is here ^^^. You just add an entry, and that's it.
>>>>> +#endif
>>>>> +
>>>>> static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
>>>>> {
>>>>> int res;
>>>>> @@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
>>>>> #ifdef CONFIG_BCM947XX
>>>>> if (bcm->pci_dev->bus->number == 0) {
>>>>> struct pci_dev *d = NULL;
>>>>> - /* FIXME: we will probably need more device IDs here... */
>>>>> - d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
>>>>> - if (d != NULL) {
>>>>> - bcm->irq = d->irq;
>>>>> + struct pci_device_id *id = bcm43xx_ids;
>>>>> + while (id->vendor) {
>>>>> + d = pci_get_device(id->vendor, id->device, NULL);
>>>>> + if (d != NULL) {
>>>>> + bcm->irq = d->irq;
>>>>> + pci_dev_put(d);
>>>>> + break;
>>>> You'll want to use pci_match_device() or pci_match_one_device()
>>>> [I forget which one]
>>> Why? Matching is done by pci_get_device() or pci_get_subsys(),
>>> respectively.
>>> [pci_match_device() is for matching dev <-> drv, you meant
>>> pci_match_one_device()]
>> The FIXME says "we will probably need more device IDs here."
> Yup.
>> Thus, if you are touching this area, it would make sense to add the
>> capability to easily add a second (and third, fourth...) PCI ID. And
>> that means pci_match_one_device() and a pci_device_id table.
> But the while loop do the work: unless id->vendor != NULL, do the matching with
> the current raw (id) of the table, then jump to the next raw (id++).
>
> pci_get_device returns NULL if the device with id->vendor, id->device wasn't
> found, then we try next raw, otherwise, we break the loop.
>
> Implementations before and now do the same strangeness -- assume there is only
> one device (?shouldn't matter?, since it is embedded).
The point is that you don't need to loop over the table,
pci_match_one_device() does that for you.
And this code, like the gt96100_eth code, is testing the existence of
certain platform devices, to be certain that it can proceed with certain
platform-specific duties.
Thus we don't care about matching multiple devices -- an unlikely case
-- but we do care about making the code as small as possible by calling
a standard PCI match function which searches through a list of PCI IDs.
Jeff
^ permalink raw reply
* Re: ipv6 routing broken in 2.6.17-rc3,4
From: Meelis Roos @ 2006-05-26 10:44 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: pekkas, netdev
In-Reply-To: <20060526.190856.33048221.yoshfuji@linux-ipv6.org>
>> The unreachable route works now but LAN routing still does not work.
>> Locally generated ICMPv6 packets that should go to LAN interface still
>> go to tun6to4.
>
> Please try this.
This works for both unreachable and LAN routes, thanks!
--
Meelis Roos (mroos@linux.ee)
^ 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