Re: e1000: backport ich9 support from 7.5.5 ?
On Fri, Jun 29, 2007 at 07:31:55PM -0700, Kok, Auke wrote: all the pci-express adapters that are supported are extremely similar: - they all support 2 queues - the register sets are (almost entirely) identical - there is minimal feature variance between 82571/2/3, esb2lan, ich8/9 The major differences between 82571/2/3, esb2lan and ich8/9 are PHY-based (4 different PHY's basically, one for 82571/2/3, one for esb2lan and 2 for ich8/9, excluding fiber and serdes here) and NVM/EEPROM. ich8 and 9 are consistent with 82571/2/3 - on-board nic's based on the 82571 design with different PHY's, and added features for the newer demands. A driver split here would be possible but not justified IMHO. Sounds like the perfect split to me. I'd suggest you rip out support for older hardware from your new driver and do the resulting simplification and post a new e1000e driver for this hardware, removing existing support from e1000 at the same time. Later you can do the feature flags and similar improvements to the old driver driver in an incremental fashion without the burden of having to keep up with new hardware. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000: backport ich9 support from 7.5.5 ?
On Fri, Jun 29, 2007 at 04:57:46PM -0700, Andrew Grover wrote: When I was at Intel, I heard a lot of the linux community won't let us split the driver. Oh well, guess we gotta keep lugging around all the old crap. So it was a (perhaps misunderstood) desire to make you guys happy that led to e1000 turning into a monster. Where exactly is that crap coming from? We've always told people to split drivers if things go to divergent and there's some interesting examples where the vendors has a monster driver and mainline has two nicely split ones (sk98lin vs skge and sky2 for example). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CIFS: make cifsd (more)
On Mon, Jun 25, 2007 at 05:25:00PM -0500, Steve French wrote: Jeff, Not seeing any objections to your revised approach (to not allowing signals for cifsd kernel thread), I just merged something similar to your patch to the cifs-2.6.git tree (also fixed some nearby lines that went past 80 columns). Ok, I'm back to this. As I said mixing force_sig with the kthread infrastructure is a bad idea. The proper short-term (aka 2.6.22) fix is to revert the kthread conversion for this particular thread. Just go back to what worked before. Now the right fix is a lot more complicated and involved: Stop using blocking recvmsg (or read) in kernel threads! If you look at what the other consumers of networking reads from kernel threads do is they either use tcp_read_sock and hooks into the sk_ callbacks which would be nice for high performance reads in cifs aswell, but probably not the demultiplexer thread, or they use MSG_DONTWAIT to avoid this problems and deal with the blocking behaviour on a higher level. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull from 'from_linus' branch
On Jun 29, 2007, at 6:06 AM, Jeff Garzik wrote: Kumar Gala wrote: Please pull from 'for_linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus to receive the following updates: drivers/net/gianfar.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Kumar Gala (1): gianfar: Fix typo bug introduced by move to udp_hdr() Why is net driver stuff no longer going through me? Fixes are regularly going upstream. Sorry about that, will push stuff through you in the future. I've sent Linus one off fixes in the past for post -rc issues. - k - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/21] r8169: merge with version 6.001.00 of Realtek's r8169 driver
Jeff Garzik [EMAIL PROTECTED] : Arjan van de Ven wrote: + pci_write_config_byte(tp-pci_dev, PCI_LATENCY_TIMER, 0x40); can you create a pci_set_latency_timer() for this please? [...] + if (tp-mac_version = RTL_GIGA_MAC_VER_06) + pci_write_config_byte(tp-pci_dev, PCI_CACHE_LINE_SIZE, 0x08); and something for this as well? Why? Nothing here seems generic to me. I.e. no need for pci_set_latency_timer(struct pci_dev *dev, u8 latency) neither pci_set_cache_line_size(struct pci_dev *dev, u8 size) ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/21] r8169: merge with version 6.001.00 of Realtek's r8169 driver
Francois Romieu wrote: Jeff Garzik [EMAIL PROTECTED] : Arjan van de Ven wrote: + pci_write_config_byte(tp-pci_dev, PCI_LATENCY_TIMER, 0x40); can you create a pci_set_latency_timer() for this please? [...] + if (tp-mac_version = RTL_GIGA_MAC_VER_06) + pci_write_config_byte(tp-pci_dev, PCI_CACHE_LINE_SIZE, 0x08); and something for this as well? Why? Nothing here seems generic to me. I.e. no need for pci_set_latency_timer(struct pci_dev *dev, u8 latency) neither pci_set_cache_line_size(struct pci_dev *dev, u8 size) ? Yeah. When it gets to be a one-line wrapper like that, I don't see much additional value in pci_set_cache_line_size() over pci_write_config_byte(,PCI_CACHE_LINE_SIZE,). Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CIFS: make cifsd (more)
On Sat, 30 Jun 2007 09:42:09 +0100 Christoph Hellwig [EMAIL PROTECTED] wrote: On Mon, Jun 25, 2007 at 05:25:00PM -0500, Steve French wrote: Jeff, Not seeing any objections to your revised approach (to not allowing signals for cifsd kernel thread), I just merged something similar to your patch to the cifs-2.6.git tree (also fixed some nearby lines that went past 80 columns). Ok, I'm back to this. As I said mixing force_sig with the kthread infrastructure is a bad idea. The proper short-term (aka 2.6.22) fix is to revert the kthread conversion for this particular thread. Just go back to what worked before. Could you clarify why this is? It looks like kthreads and signalling should be more or less orthogonal. Or is it just an issue of the complexity added when you mix signalling into kthreads? Note that the problem of insulation from userspace signals predates the conversion to using the kthreads interface for cifsd. So even if we revert the switch of the demultiplexer thread to kthreads in the near term, I'd like to keep the recent change to block all signals from userspace and use force_sig in lieu of send_sig. Does that sound reasonable? Now the right fix is a lot more complicated and involved: Stop using blocking recvmsg (or read) in kernel threads! If you look at what the other consumers of networking reads from kernel threads do is they either use tcp_read_sock and hooks into the sk_ callbacks which would be nice for high performance reads in cifs aswell, but probably not the demultiplexer thread, or they use MSG_DONTWAIT to avoid this problems and deal with the blocking behaviour on a higher level. -- Jeff Layton [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] b44: power down PHY when interface down
When the interface is down (or driver removed), the BroadCom 44xx card remains
powered on, and both its MAC and PHY is using up power.
This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
is halted, and does a partial chip reset turns off the activity LEDs too.
Applies to 2.6.22-rc6, or current git head.
Tested on a Broadcom BCM4401-B0 card, it saves ~0.5W (measured using powertop).
Signed-off-by: Torok Edwin [EMAIL PROTECTED]
---
b44.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 879a2ff..00d0f57 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -113,6 +113,8 @@ static void b44_init_rings(struct b44 *);
#define B44_FULL_RESET 1
#define B44_FULL_RESET_SKIP_PHY 2
#define B44_PARTIAL_RESET 3
+#define B44_CHIP_RESET_FULL 4
+#define B44_CHIP_RESET_PARTIAL 5
static void b44_init_hw(struct b44 *, int);
@@ -1283,7 +1285,7 @@ static void b44_clear_stats(struct b44 *bp)
}
/* bp-lock is held. */
-static void b44_chip_reset(struct b44 *bp)
+static void b44_chip_reset(struct b44 *bp, int reset_kind)
{
if (ssb_is_core_up(bp)) {
bw32(bp, B44_RCV_LAZY, 0);
@@ -1307,6 +1309,10 @@ static void b44_chip_reset(struct b44 *bp)
b44_clear_stats(bp);
+ if (reset_kind == B44_CHIP_RESET_PARTIAL)
+ return;/* don't enable PHY if we are doing a partial reset
+ , we are probably going to power down */
+
/* Make PHY accessible. */
bw32(bp, B44_MDIO_CTRL, (MDIO_CTRL_PREAMBLE |
(0x0d MDIO_CTRL_MAXF_MASK)));
@@ -1332,7 +1338,14 @@ static void b44_chip_reset(struct b44 *bp)
static void b44_halt(struct b44 *bp)
{
b44_disable_ints(bp);
- b44_chip_reset(bp);
+ /* reset PHY */
+ b44_phy_reset(bp);
+ /* power down PHY */
+ printk(KERN_INFO PFX %s: powering down PHY\n, bp-dev-name);
+ bw32(bp, B44_MAC_CTRL, MAC_CTRL_PHY_PDOWN);
+ /* now reset the chip, but without enabling the MACPHY
+* part of it. This has to be done _after_ we shut down the PHY */
+ b44_chip_reset(bp, B44_CHIP_RESET_PARTIAL);
}
/* bp-lock is held. */
@@ -1376,7 +1389,7 @@ static void b44_init_hw(struct b44 *bp, int reset_kind)
{
u32 val;
- b44_chip_reset(bp);
+ b44_chip_reset(bp, B44_CHIP_RESET_FULL);
if (reset_kind == B44_FULL_RESET) {
b44_phy_reset(bp);
b44_setup_phy(bp);
@@ -1430,7 +1443,7 @@ static int b44_open(struct net_device *dev)
err = request_irq(dev-irq, b44_interrupt, IRQF_SHARED, dev-name, dev);
if (unlikely(err 0)) {
- b44_chip_reset(bp);
+ b44_chip_reset(bp, B44_CHIP_RESET_PARTIAL);
b44_free_rings(bp);
b44_free_consistent(bp);
goto out;
@@ -2250,7 +2263,7 @@ static int __devinit b44_init_one(struct pci_dev *pdev,
/* Chip reset provides power to the b44 MAC PCI cores, which
* is necessary for MAC register access.
*/
- b44_chip_reset(bp);
+ b44_chip_reset(bp, B44_CHIP_RESET_FULL);
printk(KERN_INFO %s: Broadcom 4400 10/100BaseT Ethernet , dev-name);
for (i = 0; i 6; i++)
@@ -2284,6 +2297,7 @@ static void __devexit b44_remove_one(struct pci_dev *pdev)
free_netdev(dev);
pci_release_regions(pdev);
pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
pci_set_drvdata(pdev, NULL);
}
@@ -2312,6 +2326,7 @@ static int b44_suspend(struct pci_dev *pdev,
pm_message_t state)
b44_setup_wol(bp);
}
pci_disable_device(pdev);
+ pci_set_power_state(pdev, PCI_D3hot);
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: power down PHY when interface down
On Sat, Jun 30, 2007 at 02:47:35PM +0300, Török Edvin wrote: When the interface is down (or driver removed), the BroadCom 44xx card remains powered on, and both its MAC and PHY is using up power. This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface is halted, and does a partial chip reset turns off the activity LEDs too. Do you still get link beat detection when the phy is powered down? -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 2.2LK: Low link speed after suspend
Hello Francois! I have finally gotten round to updating the kernel on this workstation. It is now on 2.6.21.5 as downloaded from www.kernel.org, built for AMD64. Unfortunately, the problem is not gone. After suspend-to-disk and resume, link speed is 100. Unplugging and replugging the cable does not help. Unloading and reloading the driver module brings it back up to 1000. But now I should have a driver that supports mii_tool, right? Since I cannot seem to find this tool available for download, could you please give me a pointer, or mail me the source? Many thanks! regards, Peter - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CIFS: make cifsd (more)
The reason that cifs switched from wait_for_completion to the kthread call to cifs_demultiplex_thread in the first place is because without use of kthread it won't work with a linux-vserver. See the thread: http://marc.info/?l=linux-cifs-clientm=117552761703381w=2 If we take out the kthread call, we break those guys. I agree that using sk_callbacks is worth looking into - I only found ocfs2 and SunRPC (NFS) though that used it. Is there a better example though? The NFS socket handling code is huge (net/sunrpc/xprtsck.c) - something seems wrong when replacing a few lines of code with a new 1675 line file. There must be a better example of doing what you suggest... I am tempted to drop the socket timeout (which cifs sets to 7 seconds) to a smaller number and not use signals at all rather than add that much complexity On 6/30/07, Jeff Layton [EMAIL PROTECTED] wrote: On Sat, 30 Jun 2007 09:42:09 +0100 Christoph Hellwig [EMAIL PROTECTED] wrote: On Mon, Jun 25, 2007 at 05:25:00PM -0500, Steve French wrote: Jeff, Not seeing any objections to your revised approach (to not allowing signals for cifsd kernel thread), I just merged something similar to your patch to the cifs-2.6.git tree (also fixed some nearby lines that went past 80 columns). Ok, I'm back to this. As I said mixing force_sig with the kthread infrastructure is a bad idea. The proper short-term (aka 2.6.22) fix is to revert the kthread conversion for this particular thread. Just go back to what worked before. Could you clarify why this is? It looks like kthreads and signalling should be more or less orthogonal. Or is it just an issue of the complexity added when you mix signalling into kthreads? Note that the problem of insulation from userspace signals predates the conversion to using the kthreads interface for cifsd. So even if we revert the switch of the demultiplexer thread to kthreads in the near term, I'd like to keep the recent change to block all signals from userspace and use force_sig in lieu of send_sig. Does that sound reasonable? Now the right fix is a lot more complicated and involved: Stop using blocking recvmsg (or read) in kernel threads! If you look at what the other consumers of networking reads from kernel threads do is they either use tcp_read_sock and hooks into the sk_ callbacks which would be nice for high performance reads in cifs aswell, but probably not the demultiplexer thread, or they use MSG_DONTWAIT to avoid this problems and deal with the blocking behaviour on a higher level. -- Jeff Layton [EMAIL PROTECTED] -- Thanks, Steve - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 2.2LK: Low link speed after suspend
Peter Missel [EMAIL PROTECTED] : [...] It is now on 2.6.21.5 as downloaded from www.kernel.org, built for AMD64. Unfortunately, the problem is not gone. After suspend-to-disk and resume, link speed is 100. Unplugging and replugging the cable does not help. Unloading and reloading the driver module brings it back up to 1000. Ok. But now I should have a driver that supports mii_tool, right ? Yes. Since I cannot seem to find this tool available for download, could you please give me a pointer, or mail me the source? Oops, mii-tool is not included in the net-tool package by Suse. You can follow http://freshmeat.net/projects/mii-tool. /me digs in the pending bugs mailbox... Apparently there is no currently known version of the kernel/driver whose behavior would be different, right ? Can you try if it is enough to bring the link back to 1000 to: - ifconfig down/up the adapter - kick it with mii-tool Whatever the result, it would be nice to test the latest patchkit which will go into mainline (i.e. any of: http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/ ) The patch will not apply directly against 2.6.21.5. Is it an option for you to try 2.6.22-rc6 or are you stuck with 2.6.21.5 ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000: backport ich9 support from 7.5.5 ?
Kok, Auke wrote: Jeff Garzik wrote: Can knowledgeable people characterize the PCIe adapters somehow? Is that ICH8-era and later, or does it go back further than that? ich8 and 9 are consistent with 82571/2/3 - on-board nic's based on the 82571 design with different PHY's, and added features for the newer demands. A driver split here would be possible but not justified IMHO. if you want a quick view of features by chipset type, open the patch and search forward to /e1000_setup_flags/. I briefly looked over your new driver. I think it might benefit by moving common parts into one or more libraries (or modules) and have separate chip-specific drivers for 82540, 82541, 82542, 82543, 82571 etc. Put all the chip-specific bits in a chip-specific driver and have each driver call into the common (shared) code. The device probe/init/remove would be done by the chip-specific code, not the common code like it is now. When built as a module, the chip-specific parts and the common parts could be built as separate modules; modprobe would load the common parts automatically. Most of the code would be in the common part since these chips are very similar. Doing the above would lead naturally to a series of patches which will make it easier to review. When Intel release a new device variant in the future, it might be supported by a new, small driver rather than needing modifications to one big monolith. Also, the kernel would be loaded with only the code it needed to support the specific device(s) present. BTW, since you're doing a major update, would it be a good time to switch to phylib to manage your PHYs? -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] NET: [SCHED] Qdisc changes and sch_rr added for multiqueue
David Miller wrote: Now I get to pose a problem for everyone, prove to me how useful this new code is by showing me how it can be used to solve a reocurring problem in virtualized network drivers of which I've had to code one up recently, see my most recent blog entry at: http://vger.kernel.org/~davem/cgi-bin/blog.cgi/index.html Anyways the gist of the issue is (and this happens for Sun LDOMS networking, lguest, IBM iSeries, etc.) that we have a single virtualized network device. There is a port to the control node (which switches packets to the real network for the guest) and one port to each of the other guests. Each guest gets a unique MAC address. There is a queue per-port that can fill up. What all the drivers like this do right now is stop the queue if any of the per-port queues fill up, and that's why my sunvnet driver does right now as well. We can only thus wakeup the queue when all of the ports have some space. The ports (and thus the queues) are selected by destination MAC address. Each port has a remote MAC address, if there is an exact match with a port's remote MAC we'd use that port and thus that port's queue. If there is no exact match (some other node on the real network, broadcast, multicast, etc.) we want to use the control node's port and port queue. So the problem to solve is to make a way for drivers to do the queue selection before the generic queueing layer starts to try and push things to the driver. Perhaps a classifier in the driver or similar. That sounds like the only reasonable possibility if you really do want to use queues. Another possibility would be to not use a queue and make the hole thing unreliable and treat full rx rings of the guests as loss on the wire. Not sure if that makes any sense. I was thinking about adding a way for (multiqueue) drivers to use other default qdiscs than pfifo_fast so they can default to a multiband prio or something else that makes sense for them .. maybe a dev-qdisc_setup hook that is invoked from dev_activate. They would need to be able to add a default classifier for this to have any effect (the grand plan is to get rid of the horrible wme scheduler). Specialized classifiers like your dst MAC classifier and maybe even WME should then probably be built into the driver and don't register with the API, so they don't become globally visible. The solution to this problem generalizes to the other facility we want now, hashing the transmit queue by smp_processor_id() or similar. With that in place we can look at doing the TX locking per-queue too as is hinted at by the comments above the per-queue structure in the current net-2.6.23 tree. It would be great if we could finally get a working e1000 multiqueue patch so work in this area can actually be tested. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] NET: [SCHED] Qdisc changes and sch_rr added for multiqueue
It would be great if we could finally get a working e1000 multiqueue patch so work in this area can actually be tested. I'm actively working on this right now. I'm on vacation next week, but hopefully I can get something working before I leave OLS and post it. -PJ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CIFS: make cifsd (more)
[ Trimmed Cc: list ] On 6/30/07, Steve French [EMAIL PROTECTED] wrote: The reason that cifs switched from wait_for_completion to the kthread call to cifs_demultiplex_thread in the first place is because without use of kthread it won't work with a linux-vserver. See the thread: http://marc.info/?l=linux-cifs-clientm=117552761703381w=2 If we take out the kthread call, we break those guys. I agree that using sk_callbacks is worth looking into - I only found ocfs2 and SunRPC (NFS) though that used it. Is there a better example though? The NFS socket handling code is huge (net/sunrpc/xprtsck.c) - something seems wrong when replacing a few lines of code with a new 1675 line file. There must be a better example of doing what you suggest... You're correct. Right / elegant solutions are rarely (if ever?) complex and involved. Simplicity _is_ good. I see no point in converting 5 good lines of maintainable, readable, solid code with 1000 lines of kludge :-) just to work-around this kthreads limitation. But then, of course, the call is yours. I am tempted to drop the socket timeout (which cifs sets to 7 seconds) to a smaller number and not use signals at all rather than add that much complexity Timeout too low = CPU wastage = power wastage. [ Think laptop batteries, with say 5 cifsd kthreads waking up once every second ... ] Timeout too high = umount(2) hangs, annoys user, user takes drastic actions ... so think of some good magic number :-) I don't quite think of all these suggestions as solutions at all -- they are workarounds at best, IMHO (for kthread's limitation in dealing with kernel threads that want to block -- I still don't see any fundamental reasoning / logic behind why kthreads should be banned from doing blocking recv's -- if there is, please let me know too). Don't have much else to say than what I already have on the two threads discussing this. Satyam - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/21] r8169: merge with version 6.001.00 of Realtek's r8169 driver
On Sat, 2007-06-30 at 05:47 -0400, Jeff Garzik wrote: Francois Romieu wrote: Jeff Garzik [EMAIL PROTECTED] : Arjan van de Ven wrote: +pci_write_config_byte(tp-pci_dev, PCI_LATENCY_TIMER, 0x40); can you create a pci_set_latency_timer() for this please? [...] +if (tp-mac_version = RTL_GIGA_MAC_VER_06) +pci_write_config_byte(tp-pci_dev, PCI_CACHE_LINE_SIZE, 0x08); and something for this as well? Why? Nothing here seems generic to me. I.e. no need for pci_set_latency_timer(struct pci_dev *dev, u8 latency) neither pci_set_cache_line_size(struct pci_dev *dev, u8 size) ? Yeah. When it gets to be a one-line wrapper like that, I don't see much additional value in pci_set_cache_line_size() over pci_write_config_byte(,PCI_CACHE_LINE_SIZE,). but it isn't really a one line wrapper, since pci_set_cacheline_size() would need to compare against the system size as well, and reject if you try to set it smaller than that size that's a datacorruption issue. (which makes me wonder; is the driver trying to work around a hardware bug, or around behavior of early linux kernels that didn't set the cacheline size in pci_enable_mwi() ... ) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: power down PHY when interface down
Matthew Garrett wrote: On Sat, Jun 30, 2007 at 02:47:35PM +0300, Török Edvin wrote: When the interface is down (or driver removed), the BroadCom 44xx card remains powered on, and both its MAC and PHY is using up power. This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface is halted, and does a partial chip reset turns off the activity LEDs too. Do you still get link beat detection when the phy is powered down? does that matter? If the interface is down, nic drivers aren't expected to detect link... if userspace wants to find link status it should have the interface up. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multiqueue and virtualization WAS(Re: [PATCH 3/3] NET: [SCHED] Qdisc changes and sch_rr added for multiqueue
On Fri, 2007-29-06 at 21:35 -0700, David Miller wrote: Awesome, but let's concentrate on the client since I can actually implement and test anything we come up with :-) Ok, you need to clear one premise for me then ;- You said the model is for the guest/client to hook have a port to the host and one to each guest; i think this is the confusing part for me (and may have led to the switch discussion) because i have not seen this model used before. What i have seen before is that the host side connects the different guests. In such a scenario, on the guest is a single port that connects to the host - the host worries (lets forget the switch/bridge for a sec) about how to get packets from guestX to guestY pending consultation of access control details. What is the advantage of direct domain-domain connection? Is it a scalable? cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: power down PHY when interface down
On Sat, Jun 30, 2007 at 07:44:59AM -0700, Arjan van de Ven wrote: Matthew Garrett wrote: Do you still get link beat detection when the phy is powered down? does that matter? If the interface is down, nic drivers aren't expected to detect link... if userspace wants to find link status it should have the interface up. If that's the policy, why do we leave this up to individual drivers? Right now most of them let you make the query regardless of interface state. I'd agree that there's a need for a state where we power down as much as possible (even at the cost of functionality), but where possible it would also be nice to offer a state where the mac is powered down and the phy left up. If the existing semantics are confused then it would be nice to fix them, too. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Fri, 2007-29-06 at 16:56 +0200, Johannes Berg wrote:
+static void genl_unregister_mc_group(struct genl_multicast_group *grp)
+{
+ /*
+ * TODO: fix multicast group re-use by clearing the bit
+ * for this group in all genetlink sockets.
+ */
+ clear_bit(grp-id, mc_groups);
+ list_del(grp-list);
I think you need a
genl_ctrl_event(CTRL_CMD_DELMCAST_GRP, family);
here? You may need to save the mcast details before you delete.
+ NLA_PUT_U32(skb, CTRL_ATTR_MCAST_GRP_ID, grp-id);
+ NLA_PUT_STRING(skb, CTRL_ATTR_MCAST_GRP_NAME,
+grp-name);
+
Consider my earlier suggestion to use CTRL_ATTR_MCAST_GRP which has both
id and name in one struct.
Other than that - looking good.
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: power down PHY when interface down
On Sat, Jun 30, 2007 at 04:19:23PM +0100, Matthew Garrett wrote: I'd agree that there's a need for a state where we power down as much as possible (even at the cost of functionality), but where possible it would also be nice to offer a state where the mac is powered down and the phy left up. There are PHYs which can detect that someone's on the other end even when powered down.. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000: backport ich9 support from 7.5.5 ?
James Chapman wrote: Kok, Auke wrote: Jeff Garzik wrote: Can knowledgeable people characterize the PCIe adapters somehow? Is that ICH8-era and later, or does it go back further than that? ich8 and 9 are consistent with 82571/2/3 - on-board nic's based on the 82571 design with different PHY's, and added features for the newer demands. A driver split here would be possible but not justified IMHO. if you want a quick view of features by chipset type, open the patch and search forward to /e1000_setup_flags/. I briefly looked over your new driver. I think it might benefit by moving common parts into one or more libraries (or modules) and have separate chip-specific drivers for 82540, 82541, 82542, 82543, 82571 etc. Put all the chip-specific bits in a chip-specific driver and have each driver call into the common (shared) code. The device probe/init/remove would be done by the chip-specific code, not the common code like it is now. When built as a module, the chip-specific parts and the common parts could be built as separate modules; modprobe would load the common parts automatically. Most of the code would be in the common part since these chips are very similar. splitting beyond the obvious does not make any sense and will just add confusion. I'm not against a pcie/pre-pcie split or even going a step further and looking into using PHYlib as you suggest below, but we should really avoid trying to create an unmaintainable mess where we have to patch 7 drivers for each generic issue we find. Doing the above would lead naturally to a series of patches which will make it easier to review. When Intel release a new device variant in the future, it might be supported by a new, small driver rather than needing modifications to one big monolith. Also, the kernel would be loaded with only the code it needed to support the specific device(s) present. BTW, since you're doing a major update, would it be a good time to switch to phylib to manage your PHYs? well, PHYlib might help, so I'm not negative against doing that right now. It will be quite some work. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
PM policy, hotplug, power saving (was Re: [PATCH] b44: power down PHY when interface down)
Arjan van de Ven wrote: Matthew Garrett wrote: Do you still get link beat detection when the phy is powered down? does that matter? If the interface is down, nic drivers aren't expected to detect link... if userspace wants to find link status it should have the interface up. Definitely matters. Switch renegotiation can take a while, and you must take into account the common case of interface bouncing (immediate down, then up). Hoards actively complained the few times we experimented with this, because of e.g. DHCP's habit of bouncing the interface, which resulted in PHY power bouncing, which resulted in negotiation, which resulted in an excrutiating wait on various broken or stupid switches. Overall, this may be classed with other problems of a similar sort: we can power down a PHY, but that removes hotplug capability and extends partner/link negotiation time. Like SATA, we actually want to support BOTH -- active hotplug and PHY power-down -- and so this wanders into power management policy. Give me a knob, and we can program plenty of ethernet|SATA|USB|... drivers to power down the PHY and save power. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET]: Fix secondary unicast/multicast address count maintenance
Fix a bug introduced by the secondary unicast address patches.
[NET]: Fix secondary unicast/multicast address count maintenance
When a reference to an existing address is increased or decreased without
hitting zero, the address count is incorrectly adjusted.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 84de3fc644b2a98be30519225b088fa8856a8ce4
tree 1ae3a42ed15d68ec21707f72b42a406dad8ee606
parent e1749582c9c230fb2cc0292cf824b30b04f80ee6
author Patrick McHardy [EMAIL PROTECTED] Sat, 30 Jun 2007 17:23:23 +0200
committer Patrick McHardy [EMAIL PROTECTED] Sat, 30 Jun 2007 17:23:23 +0200
include/linux/netdevice.h |4 ++--
net/core/dev.c| 21 ++---
net/core/dev_mcast.c | 11 ---
3 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 2c0cc19..296a59b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1021,8 +1021,8 @@ extern intdev_unicast_add(struct
net_device *dev, void *addr, int alen);
extern int dev_mc_delete(struct net_device *dev, void *addr, int
alen, int all);
extern int dev_mc_add(struct net_device *dev, void *addr, int
alen, int newonly);
extern voiddev_mc_discard(struct net_device *dev);
-extern int __dev_addr_delete(struct dev_addr_list **list, void
*addr, int alen, int all);
-extern int __dev_addr_add(struct dev_addr_list **list, void *addr,
int alen, int newonly);
+extern int __dev_addr_delete(struct dev_addr_list **list, int
*count, void *addr, int alen, int all);
+extern int __dev_addr_add(struct dev_addr_list **list, int *count,
void *addr, int alen, int newonly);
extern void__dev_addr_discard(struct dev_addr_list **list);
extern voiddev_set_promiscuity(struct net_device *dev, int inc);
extern voiddev_set_allmulti(struct net_device *dev, int inc);
diff --git a/net/core/dev.c b/net/core/dev.c
index f453127..2ce5546 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2602,8 +2602,8 @@ void dev_set_rx_mode(struct net_device *dev)
netif_tx_unlock_bh(dev);
}
-int __dev_addr_delete(struct dev_addr_list **list, void *addr, int alen,
- int glbl)
+int __dev_addr_delete(struct dev_addr_list **list, int *count,
+ void *addr, int alen, int glbl)
{
struct dev_addr_list *da;
@@ -2621,13 +2621,15 @@ int __dev_addr_delete(struct dev_addr_list **list, void
*addr, int alen,
*list = da-next;
kfree(da);
+ (*count)--;
return 0;
}
}
return -ENOENT;
}
-int __dev_addr_add(struct dev_addr_list **list, void *addr, int alen, int glbl)
+int __dev_addr_add(struct dev_addr_list **list, int *count,
+ void *addr, int alen, int glbl)
{
struct dev_addr_list *da;
@@ -2654,6 +2656,7 @@ int __dev_addr_add(struct dev_addr_list **list, void
*addr, int alen, int glbl)
da-da_gusers = glbl ? 1 : 0;
da-next = *list;
*list = da;
+ (*count)++;
return 0;
}
@@ -2687,11 +2690,9 @@ int dev_unicast_delete(struct net_device *dev, void
*addr, int alen)
ASSERT_RTNL();
netif_tx_lock_bh(dev);
- err = __dev_addr_delete(dev-uc_list, addr, alen, 0);
- if (!err) {
- dev-uc_count--;
+ err = __dev_addr_delete(dev-uc_list, dev-uc_count, addr, alen, 0);
+ if (!err)
__dev_set_rx_mode(dev);
- }
netif_tx_unlock_bh(dev);
return err;
}
@@ -2713,11 +2714,9 @@ int dev_unicast_add(struct net_device *dev, void *addr,
int alen)
ASSERT_RTNL();
netif_tx_lock_bh(dev);
- err = __dev_addr_add(dev-uc_list, addr, alen, 0);
- if (!err) {
- dev-uc_count++;
+ err = __dev_addr_add(dev-uc_list, dev-uc_count, addr, alen, 0);
+ if (!err)
__dev_set_rx_mode(dev);
- }
netif_tx_unlock_bh(dev);
return err;
}
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 5cc9b44..aa38100 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -72,10 +72,9 @@ int dev_mc_delete(struct net_device *dev, void *addr, int
alen, int glbl)
int err;
netif_tx_lock_bh(dev);
- err = __dev_addr_delete(dev-mc_list, addr, alen, glbl);
+ err = __dev_addr_delete(dev-mc_list, dev-mc_count,
+ addr, alen, glbl);
if (!err) {
- dev-mc_count--;
-
/*
* We have altered the list, so the card
* loaded filter is now wrong. Fix it
@@ -96,11 +95,9 @@ int dev_mc_add(struct net_device *dev, void *addr, int alen,
int glbl)
int err;
netif_tx_lock_bh(dev);
- err = __dev_addr_add(dev-mc_list,
Re: PM policy, hotplug, power saving (was Re: [PATCH] b44: power down PHY when interface down)
On Sat, 30 Jun 2007 12:42:06 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Arjan van de Ven wrote: Matthew Garrett wrote: Do you still get link beat detection when the phy is powered down? does that matter? If the interface is down, nic drivers aren't expected to detect link... if userspace wants to find link status it should have the interface up. Definitely matters. Switch renegotiation can take a while, and you must take into account the common case of interface bouncing (immediate down, then up). Hoards actively complained the few times we experimented with this, because of e.g. DHCP's habit of bouncing the interface, which resulted in PHY power bouncing, which resulted in negotiation, which resulted in an excrutiating wait on various broken or stupid switches. Overall, this may be classed with other problems of a similar sort: we can power down a PHY, but that removes hotplug capability and extends partner/link negotiation time. Like SATA, we actually want to support BOTH -- active hotplug and PHY power-down -- and so this wanders into power management policy. Give me a knob, and we can program plenty of ethernet|SATA|USB|... drivers to power down the PHY and save power. Jeff We do have IFF_DORMANT, but almost no driver uses it. And most certainly, the common applications wouldn't know how to use it. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
PM policy, hotplug, power saving and WoL
On Sat, 30 Jun 2007, Jeff Garzik wrote: Like SATA, we actually want to support BOTH -- active hotplug and PHY power-down -- and so this wanders into power management policy. Give me a knob, and we can program plenty of ethernet|SATA|USB|... drivers to power down the PHY and save power. While at it, could we please fix our borked WOL interface requirements, so that the PHY is *never* to be powered down when WOL is active? This is another deficiency that userspace has to work around in halt(8)... If WOL is enabled and supported in a device, the kernel must never do anything that would cause that device to stop responding to WOL packets. OTOH, if WOL is disabled, it would be very very nice indeed to be able to tell the kernel that yes, it is to power down the PHY if it is not in use. Laptops appreciate it a lot, and so do the switches (which will know they don't have to forward any traffic over that port). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 2.2LK: Low link speed after suspend
Francois Romieu [EMAIL PROTECTED] : [...] The patch will not apply directly against 2.6.21.5. Is it an option for you to try 2.6.22-rc6 or are you stuck with 2.6.21.5 ? If you feel adventurous, you will find a compile-tested-only patchkit for 2.6.21.5 here: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21.5 or: http://www.fr.zoreil.com/people/francois/misc/20060630-2.6.21.5-r8169-test.patch The content should be almost the same as the 2.6.22-rc6 patchkit dated from 2007/06/28 (i.e. pending 2.6.23 merge). Time to go downtown. The lights are much brighter there. -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] NetXen: Updates and bug fixes for NetXen 1/10G driver
There's change of guard from NetXen side. I have reworked Mithlesh's original patches based on Michael's feedback. Will be sending out shortly. -- Dhananjay Phadke NetXen Inc. On 6/22/07, Mithlesh Thukral [EMAIL PROTECTED] wrote: Hi All, I will be sending updates for NetXen NIC 1/10 G Ethernet driver in the following emails. These are bug fixes and better interrupt handling schemes. All these patches have been test on x86 machines and PowerPC blades. Thanks, Mithlesh Thukral - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multiqueue and virtualization WAS(Re: [PATCH 3/3] NET: [SCHED] Qdisc changes and sch_rr added for multiqueue
From: jamal [EMAIL PROTECTED] Date: Sat, 30 Jun 2007 10:52:44 -0400 On Fri, 2007-29-06 at 21:35 -0700, David Miller wrote: Awesome, but let's concentrate on the client since I can actually implement and test anything we come up with :-) Ok, you need to clear one premise for me then ;- You said the model is for the guest/client to hook have a port to the host and one to each guest; i think this is the confusing part for me (and may have led to the switch discussion) because i have not seen this model used before. What i have seen before is that the host side connects the different guests. In such a scenario, on the guest is a single port that connects to the host - the host worries (lets forget the switch/bridge for a sec) about how to get packets from guestX to guestY pending consultation of access control details. What is the advantage of direct domain-domain connection? Is it a scalable? It's like twice as fast, since the switch doesn't have to copy the packet in, switch it, then the destination guest copies it into it's address space. There is approximately one copy for each hop you go over through these virtual devices. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET]: Fix secondary unicast/multicast address count maintenance
From: Patrick McHardy [EMAIL PROTECTED] Date: Sat, 30 Jun 2007 18:46:29 +0200 Fix a bug introduced by the secondary unicast address patches. Applied, thanks Patrick. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Handling set_mac_address in set_rx_mode
Patrick McHardy wrote: While adding support for secondary unicast addresses to 8021q and macvlan, I've tried keeping dev-dev_addr as global address on dev-uc_list and have drivers skip them to avoid having all dev_unicast_add users implement a state machine like this: [...] Something that is not entirely clear to me... This has zero impact on existing drivers, right? I would not fancy updating all drivers for a new MAC addr scheme... Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dm9601: Return 0 from bind() on success
Fixup dm9601_bind() so it returns 0 on success rather than just a positive
number, as otherwise usbnet doesn't init the status handler.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
drivers/net/usb/dm9601.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux-2.6.22-rc6/drivers/net/usb/dm9601.c
===
--- linux-2.6.22-rc6.orig/drivers/net/usb/dm9601.c
+++ linux-2.6.22-rc6/drivers/net/usb/dm9601.c
@@ -414,18 +414,16 @@
dev-mii.reg_num_mask = 0x1f;
/* reset */
- ret = dm_write_reg(dev, DM_NET_CTRL, 1);
+ dm_write_reg(dev, DM_NET_CTRL, 1);
udelay(20);
/* read MAC */
- ret = dm_read(dev, DM_PHY_ADDR, ETH_ALEN, dev-net-dev_addr);
- if (ret 0) {
+ if (dm_read(dev, DM_PHY_ADDR, ETH_ALEN, dev-net-dev_addr) 0) {
printk(KERN_ERR Error reading MAC address\n);
ret = -ENODEV;
goto out;
}
-
/* power up phy */
dm_write_reg(dev, DM_GPR_CTRL, 1);
dm_write_reg(dev, DM_GPR_DATA, 0);
--
Bye, Peter Korsgaard
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] NetXen: Bug fixes for multiport and blade adapters
Sending reworked patches based on Michael's feedback (originally sent by Mithlesh Thukral). These patches address interrupt mask issues on multiport adapters, as well as stability issues on powerpc blades. -- Dhananjay Phadke NetXen Inc. drivers/net/netxen/netxen_nic.h | 176 +++--- drivers/net/netxen/netxen_nic_hdr.h |2 + drivers/net/netxen/netxen_nic_hw.c | 33 -- drivers/net/netxen/netxen_nic_init.c | 56 ++ drivers/net/netxen/netxen_nic_main.c | 176 +++--- drivers/net/netxen/netxen_nic_phan_reg.h | 14 +++ 6 files changed, 341 insertions(+), 116 deletions(-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] NetXen: Fix issue of MSI not working correctly
NetXen driver uses PCI function 0 to provide the functionality of MSI.
The patch makes driver check the bus master bit for function 0 and
enable it after the card initialization.
Signed-off-by: Dhananjay Phadke[EMAIL PROTECTED]
Signed-off-by: Milan Bag [EMAIL PROTECTED]
Signed-off-by: Wen Xiong [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -336,11 +336,9 @@ netxen_nic_probe(struct pci_dev *pdev, c
if (pci_using_dac)
netdev-features |= NETIF_F_HIGHDMA;
- if (pci_enable_msi(pdev)) {
+ if (pci_enable_msi(pdev))
adapter-flags = ~NETXEN_NIC_MSI_ENABLED;
- printk(KERN_WARNING %s: unable to allocate MSI interrupt
- error\n, netxen_nic_driver_name);
- } else
+ else
adapter-flags |= NETXEN_NIC_MSI_ENABLED;
netdev-irq = pdev-irq;
@@ -355,13 +353,6 @@ netxen_nic_probe(struct pci_dev *pdev, c
/* initialize the adapter */
netxen_initialize_adapter_hw(adapter);
-#ifdef CONFIG_PPC
- if ((adapter-ahw.boardcfg.board_type ==
- NETXEN_BRDTYPE_P2_SB31_10G_IMEZ)
- (pci_func_id == 2))
- goto err_out_free_adapter;
-#endif /* CONFIG_PPC */
-
/*
* Adapter in our case is quad port so initialize it before
* initializing the ports
@@ -509,16 +500,22 @@ netxen_nic_probe(struct pci_dev *pdev, c
NETXEN_CAM_RAM(0x1fc)));
if (val == 0x) {
/* This is the first boot after power up */
+ netxen_nic_read_w0(adapter, NETXEN_PCIE_REG(0x4), val);
+ if (!(val 0x4)) {
+ val |= 0x4;
+ netxen_nic_write_w0(adapter, NETXEN_PCIE_REG(0x4), val);
+ netxen_nic_read_w0(adapter, NETXEN_PCIE_REG(0x4), val);
+ }
val = readl(NETXEN_CRB_NORMALIZE(adapter,
NETXEN_ROMUSB_GLB_SW_RESET));
printk(KERN_INFONetXen: read 0x%08x for reset reg.\n,val);
if (val != 0x8f) {
/* clear the register for future unloads/loads */
- writel(0, NETXEN_CRB_NORMALIZE(adapter,
- NETXEN_CAM_RAM(0x1fc)));
- printk(KERN_ERR ERROR in NetXen HW init sequence.\n);
- err = -ENODEV;
- goto err_out_free_dev;
+ writel(0, NETXEN_CRB_NORMALIZE(adapter,
+ NETXEN_CAM_RAM(0x1fc)));
+ printk(KERN_ERR ERROR in NetXen HW init
sequence.\n);
+ err = -ENODEV;
+ goto err_out_free_dev;
}
/* clear the register for future unloads/loads */
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] NetXen: Support per PCI-function interrupt mask registers
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.
Signed-off by: Dhananjay Phadke [EMAIL PROTECTED]
Signed-off by: Milan Bag [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic.h
@@ -937,6 +937,7 @@ struct netxen_adapter {
struct netxen_ring_ctx *ctx_desc;
struct pci_dev *ctx_desc_pdev;
dma_addr_t ctx_desc_phys_addr;
+ int intr_scheme;
int (*enable_phy_interrupts) (struct netxen_adapter *);
int (*disable_phy_interrupts) (struct netxen_adapter *);
void (*handle_phy_intr) (struct netxen_adapter *);
@@ -1080,37 +1081,102 @@ struct net_device_stats *netxen_nic_get_
static inline void netxen_nic_disable_int(struct netxen_adapter *adapter)
{
- /*
-* ISR_INT_MASK: Can be read from window 0 or 1.
-*/
- writel(0x7ff, PCI_OFFSET_SECOND_RANGE(adapter, ISR_INT_MASK));
+ uint32_tmask = 0x7ff;
+ int count = 0;
+ DPRINTK(1, INFO, Entered ISR Disable \n);
+
+ switch (adapter-portnum) {
+ case 0:
+ writel(0x0, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_0));
+ break;
+ case 1:
+ writel(0x0, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_1));
+ break;
+ case 2:
+ writel(0x0, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_2));
+ break;
+ case 3:
+ writel(0x0, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_3));
+ break;
+ }
+
+ if (adapter-intr_scheme != -1
+ adapter-intr_scheme != INTR_SCHEME_PERPORT) {
+ writel(mask,
+ (void *)(PCI_OFFSET_SECOND_RANGE(adapter,
ISR_INT_MASK)));
+ }
+
+ /* Window = 0 or 1 */
+ if (!(adapter-flags NETXEN_NIC_MSI_ENABLED)) {
+ do {
+ writel(0x, (void *)
+ (PCI_OFFSET_SECOND_RANGE(adapter,
ISR_INT_TARGET_STATUS)));
+ mask = readl((void *)
+ (pci_base_offset(adapter,
ISR_INT_VECTOR)));
+ } while (((mask 0x80) != 0) (++count 32));
+
+ if ((mask 0x80) != 0) {
+ printk(KERN_NOTICE Could not disable interrupt
completely\n);
+ }
+ }
+
+ DPRINTK(1, INFO, Done with Disable Int\n);
+
+ return;
}
static inline void netxen_nic_enable_int(struct netxen_adapter *adapter)
{
u32 mask;
- switch (adapter-ahw.board_type) {
- case NETXEN_NIC_GBE:
- mask = 0x77b;
+ DPRINTK(1, INFO, Entered ISR Enable \n);
+
+ if (adapter-intr_scheme != -1
+ adapter-intr_scheme != INTR_SCHEME_PERPORT) {
+ switch (adapter-ahw.board_type) {
+ case NETXEN_NIC_GBE:
+ mask = 0x77b;
+ break;
+ case NETXEN_NIC_XGBE:
+ mask = 0x77f;
+ break;
+ default:
+ mask = 0x7ff;
+ break;
+ }
+
+ writel(mask,
+ (void *)(PCI_OFFSET_SECOND_RANGE(adapter,
ISR_INT_MASK)));
+ }
+ switch (adapter-portnum) {
+ case 0:
+ writel(0x1, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_0));
+ break;
+ case 1:
+ writel(0x1, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_1));
break;
- case NETXEN_NIC_XGBE:
- mask = 0x77f;
+ case 2:
+ writel(0x1, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_2));
break;
- default:
- mask = 0x7ff;
+ case 3:
+ writel(0x1, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_3));
break;
}
- writel(mask, PCI_OFFSET_SECOND_RANGE(adapter, ISR_INT_MASK));
-
if (!(adapter-flags NETXEN_NIC_MSI_ENABLED)) {
mask = 0xbff;
- writel(0X0, NETXEN_CRB_NORMALIZE(adapter, CRB_INT_VECTOR));
- writel(mask, PCI_OFFSET_SECOND_RANGE(adapter,
-ISR_INT_TARGET_MASK));
+ if (adapter-intr_scheme != -1
+ adapter-intr_scheme != INTR_SCHEME_PERPORT) {
+ writel(0X0, NETXEN_CRB_NORMALIZE(adapter,
CRB_INT_VECTOR));
+ }
+ writel(mask,
+ (void *)(PCI_OFFSET_SECOND_RANGE(adapter,
ISR_INT_TARGET_MASK)));
}
+
+ DPRINTK(1, INFO, Done with enable Int\n);
[PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload
These changes allow driver close routine to be called during module unload,
to clean-up buffers and other software resources, flush queues etc. Also,
hardware is reset to pristine state.
Signed-off-by: Dhananjay Phadke [EMAIL PROTECTED]
Signed-off-by: Milan Bag [EMAIL PROTECTED]
Signed-off-by: Wen Xiong [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic.h
@@ -952,6 +952,24 @@ struct netxen_adapter {
int (*stop_port) (struct netxen_adapter *);
}; /* netxen_adapter structure */
+/*
+ * NetXen dma watchdog control structure
+ *
+ * Bit 0 : enabled = R/O: 1 watchdog active, 0 inactive
+ * Bit 1 : disable_request = 1 req disable dma watchdog
+ * Bit 2 : enable_request = 1 req enable dma watchdog
+ * Bit 3-31: unused
+ */
+
+#define netxen_set_dma_watchdog_disable_req(config_word) \
+ _netxen_set_bits(config_word, 1, 1, 1)
+#define netxen_set_dma_watchdog_enable_req(config_word) \
+ _netxen_set_bits(config_word, 2, 1, 1)
+#define netxen_get_dma_watchdog_enabled(config_word) \
+ ((config_word) 0x1)
+#define netxen_get_dma_watchdog_disabled(config_word) \
+ (((config_word) 1) 0x1)
+
/* Max number of xmit producer threads that can run simultaneously */
#defineMAX_XMIT_PRODUCERS 16
@@ -1031,8 +1049,8 @@ int netxen_nic_erase_pxe(struct netxen_a
/* Functions from netxen_nic_init.c */
void netxen_free_adapter_offload(struct netxen_adapter *adapter);
int netxen_initialize_adapter_offload(struct netxen_adapter *adapter);
-void netxen_phantom_init(struct netxen_adapter *adapter, int pegtune_val);
-void netxen_load_firmware(struct netxen_adapter *adapter);
+int netxen_phantom_init(struct netxen_adapter *adapter, int pegtune_val);
+int netxen_load_firmware(struct netxen_adapter *adapter);
int netxen_pinit_from_rom(struct netxen_adapter *adapter, int verbose);
int netxen_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp);
int netxen_rom_fast_read_words(struct netxen_adapter *adapter, int addr,
@@ -1230,6 +1248,62 @@ static inline void get_brd_name_by_type(
name = Unknown;
}
+static inline int
+dma_watchdog_shutdown_request(struct netxen_adapter *adapter)
+{
+ u32 ctrl;
+
+ /* check if already inactive */
+ if (netxen_nic_hw_read_wx(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl, 4))
+ printk(KERN_ERR failed to read dma watchdog status\n);
+
+ if (netxen_get_dma_watchdog_enabled(ctrl) == 0)
+ return 1;
+
+ /* Send the disable request */
+ netxen_set_dma_watchdog_disable_req(ctrl);
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl);
+
+ return 0;
+}
+
+static inline int
+dma_watchdog_shutdown_poll_result(struct netxen_adapter *adapter)
+{
+ u32 ctrl;
+
+ if (netxen_nic_hw_read_wx(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl, 4))
+ printk(KERN_ERR failed to read dma watchdog status\n);
+
+ return ((netxen_get_dma_watchdog_enabled(ctrl) == 0)
+ (netxen_get_dma_watchdog_disabled(ctrl) == 0));
+}
+
+static inline int
+dma_watchdog_wakeup(struct netxen_adapter *adapter)
+{
+ u32 ctrl;
+
+ if (netxen_nic_hw_read_wx(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl, 4))
+ printk(KERN_ERR failed to read dma watchdog status\n);
+
+ if (netxen_get_dma_watchdog_enabled(ctrl))
+ return 1;
+
+ /* send the wakeup request */
+ netxen_set_dma_watchdog_enable_req(ctrl);
+
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl);
+
+ return 0;
+}
+
+
int netxen_is_flash_supported(struct netxen_adapter *adapter);
int netxen_get_flash_mac_addr(struct netxen_adapter *adapter, u64 mac[]);
extern void netxen_change_ringparam(struct netxen_adapter *adapter);
Index: netdev-2.6/drivers/net/netxen/netxen_nic_hdr.h
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_hdr.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic_hdr.h
@@ -687,4 +687,6 @@ enum {
#define PCIE_MAX_MASTER_SPLIT (0x14048)
+#define NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL (0x14)
+
#endif /* __NETXEN_NIC_HDR_H_ */
Index: netdev-2.6/drivers/net/netxen/netxen_nic_hw.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_hw.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_hw.c
@@ -377,7 +377,7 @@ int netxen_nic_hw_resources(struct netxe
Re: e1000: backport ich9 support from 7.5.5 ?
Hi Auke, On Fri, 2007-06-29 at 12:51 -0700, Kok, Auke wrote: Jason Lunz wrote: On Fri, Jun 29, 2007 at 06:29:18PM +0100, Mark McLoughlin wrote: I understand there is some delay in getting e1000-7.5.5 into the upstream kernel given the major re-working of the chipset specific parts. I wonder would it be feasible in the meantime to backport the ich9 support and push it upstream? seconded - this driver reorg has been holding back support for the newest e1000 hardware since at least 2.6.20, and I haven't seen any indication that the 7.5.5 e1000 driver will even be added to 2.6.23. I disagree, we should not break the current e1000 driver in the kernel while there is a new driver coming up that introduces ich9 support without breaking (the old e1000) support for all other devices. This is why we want to drop a new version of the e1000 driver upstream instead, and put all newer devices in that driver. Clearly some major changes are happening around e1000, but the point I'm making is that ich9 support, in particular, doesn't need to be held hostage to these longer term changes. I think the backport shows that: - ich9 differs only very slightly from ich8, which is already supported upstream. The patch largely consists of: -if (hw-mac_type == e1000_ich8lan) +if (hw-mac_type == e1000_ich8lan || hw-mac_type == e1000_ich9lan) - adding ich9 support is very unlikely to affect support for any other chipsets Thanks, Mark. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: power down PHY when interface down
On Saturday 30 June 2007 13:47:35 Török Edvin wrote: When the interface is down (or driver removed), the BroadCom 44xx card remains powered on, and both its MAC and PHY is using up power. This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface is halted, and does a partial chip reset turns off the activity LEDs too. Applies to 2.6.22-rc6, or current git head. Tested on a Broadcom BCM4401-B0 card, it saves ~0.5W (measured using powertop). Hm, I was going to measure the real power advantage with a PCI-extender card. But my B44B0 card doesn't seem to work in that extender card. It works perfectly fine sticked directly into the motherboard, though, and other cards like a BCM4318 work in the extender, too. Not sure what this is. The extender has an application note about nonworking cards in the extender and a too big resistor on the board IDSEL pin being the cause of this. Maybe I can try with another machine tomorrow. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: power down PHY when interface down
On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote: When the interface is down (or driver removed), the BroadCom 44xx card remains powered on, and both its MAC and PHY is using up power. This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface is halted, and does a partial chip reset turns off the activity LEDs too. Applies to 2.6.22-rc6, or current git head. Tested on a Broadcom BCM4401-B0 card, it saves ~0.5W (measured using powertop). Hm, I was going to measure the real power advantage with a PCI-extender card. But my B44B0 card doesn't seem to work in that extender card. It works perfectly fine sticked directly into the motherboard, though, and other cards like a BCM4318 work in the extender, too. Not sure what this is. The extender has an application note about nonworking cards in the extender and a too big resistor on the board IDSEL pin being the cause of this. Does the card show up in lspci at all? IDSEL drive strength issues should only affect config space accesses. Does the extender board have a PCI-PCI bridge on it? (If not, there's not really any reason to resistively couple the IDSEL line to the host, since the host should take care of that.) Maybe I can try with another machine tomorrow. That would only make a difference if there is no PCI-PCI bridge on the extender board. If the extender resistively couples the host's IDSEL line, you might see different results on a different host bridge, since different host bridges can use different numbers of IDSEL stepping cycles. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] NetXen: Support per PCI-function interrupt mask registers
On Saturday 30 June 2007 22:38:46 [EMAIL PROTECTED] wrote:
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.
Signed-off by: Dhananjay Phadke [EMAIL PROTECTED]
Signed-off by: Milan Bag [EMAIL PROTECTED]
+ /* Window = 0 or 1 */
+ if (!(adapter-flags NETXEN_NIC_MSI_ENABLED)) {
+ do {
+ writel(0x, (void *)
+ (PCI_OFFSET_SECOND_RANGE(adapter,
ISR_INT_TARGET_STATUS)));
+ mask = readl((void *)
+ (pci_base_offset(adapter,
ISR_INT_VECTOR)));
I think you should add a small delay into this loop. Otherwise
it depends on the speed of the CPU (and chipset) how big the total
timeout (32) of the loop is. Could be too small on fast systems.
Something like:
if (!(mask 0x80))
break;
udelay(10);
} while (++count 32);
and drop the next line.
+ } while (((mask 0x80) != 0) (++count 32));
+
+ if ((mask 0x80) != 0) {
+ printk(KERN_NOTICE Could not disable interrupt
completely\n);
+ }
+ }
+
+ DPRINTK(1, INFO, Done with Disable Int\n);
+
+ return;
}
--
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload
On Saturday 30 June 2007 22:38:47 [EMAIL PROTECTED] wrote:
These changes allow driver close routine to be called during module unload,
to clean-up buffers and other software resources, flush queues etc. Also,
hardware is reset to pristine state.
Signed-off-by: Dhananjay Phadke [EMAIL PROTECTED]
Signed-off-by: Milan Bag [EMAIL PROTECTED]
Signed-off-by: Wen Xiong [EMAIL PROTECTED]
off = netxen_nic_pci_set_window(adapter, memaddr);
addr = pci_base_offset(adapter, off);
writel(data, addr);
+ do {
+ if (readl(addr) == data)
+ break;
+ msleep_interruptible(100);
If you use msleep_interruptible(), I'd say you should check for
the return value of that call and probably abort firmware
processing here if a signal interrupted us.
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ADDRESS, addr);
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ABYTE_CNT, 3);
@@ -856,10 +853,10 @@ int netxen_pinit_from_rom(struct netxen_
netxen_nic_pci_change_crbwindow(adapter, 1);
}
if (init_delay == 1) {
- ssleep(1);
+ ssleep(2);
Is it possible/desired to do some interruptible sleep here?
Two seconds uninterruptible sleep is probably a long time.
Even at init/boot.
Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -511,6 +511,8 @@ netxen_nic_probe(struct pci_dev *pdev, c
val |= 0x4;
netxen_nic_write_w0(adapter, NETXEN_PCIE_REG(0x4), val);
netxen_nic_read_w0(adapter, NETXEN_PCIE_REG(0x4), val);
+ if (!(val 0x4))
+ printk(KERN_ERR NetXen: bit set failed\n);
That's the award for the most useless error message. :P
Can you give the user a hint what this bit is about?
+ if (adapter-portnum == 0) {
+ if (init_firmware_done) {
+ dma_watchdog_shutdown_request(adapter);
+ msleep(100);
+ i = 100;
+ while ((dma_watchdog_shutdown_poll_result(adapter) !=
1) i) {
+ printk(KERN_INFO dma_watchdog_shutdown_poll
still in progress\n);
+ msleep(100);
+ i--;
+ }
+
+ if (i == 0) {
+ printk(KERN_ERR dma_watchdog_shutdown_request
failed\n);
+ return;
+ }
+
+ /* clear the register for future unloads/loads */
+ writel(0, NETXEN_CRB_NORMALIZE(adapter,
NETXEN_CAM_RAM(0x1fc)));
+ printk(KERN_INFO State: 0x%0x\n,
+ readl(NETXEN_CRB_NORMALIZE(adapter,
CRB_CMDPEG_STATE)));
+
+ /* leave the hw in the same state as reboot */
+ writel(0, NETXEN_CRB_NORMALIZE(adapter,
CRB_CMDPEG_STATE));
+ if (netxen_pinit_from_rom(adapter, 0))
+ return;
+ udelay(500);
I guess we can do msleep(1) here, too, instead of the huge delay,
although it's twice as long.
Though, I could live with a 500us delay, too, if that's desired.
The rest looks pretty good to me.
--
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: power down PHY when interface down
On Sunday 01 July 2007 00:03:01 Lennert Buytenhek wrote: On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote: When the interface is down (or driver removed), the BroadCom 44xx card remains powered on, and both its MAC and PHY is using up power. This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface is halted, and does a partial chip reset turns off the activity LEDs too. Applies to 2.6.22-rc6, or current git head. Tested on a Broadcom BCM4401-B0 card, it saves ~0.5W (measured using powertop). Hm, I was going to measure the real power advantage with a PCI-extender card. But my B44B0 card doesn't seem to work in that extender card. It works perfectly fine sticked directly into the motherboard, though, and other cards like a BCM4318 work in the extender, too. Not sure what this is. The extender has an application note about nonworking cards in the extender and a too big resistor on the board IDSEL pin being the cause of this. Does the card show up in lspci at all? No it doesn't. IDSEL drive strength issues should only affect config space accesses. Yeah. Does the extender board have a PCI-PCI bridge on it? (If not, there's not really any reason to resistively couple the IDSEL line to the host, since the host should take care of that.) There's no bridge. It just decouples all voltage lines, so you can drive it from external supply and/or measure voltages and current. On the PCB it looks like the the IDSEL line is rather directly routed to the host IDSEL. It just goes through one of the bus isolation chips. So I guess (just my guess) that this chip has some resistance and if the total resistance of the chip + the IDSEL resistor on the mainboard goes above some threshold it doesn't work anymore for some cards. In the application note they write about trouble for IDSEL resistors 51ohms. Maybe I can try with another machine tomorrow. That would only make a difference if there is no PCI-PCI bridge on the extender board. Well, they suggest it in the application note as a possible fix. ;) -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] b44: power down PHY when interface down
On Sun, Jul 01, 2007 at 12:24:40AM +0200, Michael Buesch wrote: Hm, I was going to measure the real power advantage with a PCI-extender card. But my B44B0 card doesn't seem to work in that extender card. It works perfectly fine sticked directly into the motherboard, though, and other cards like a BCM4318 work in the extender, too. Not sure what this is. The extender has an application note about nonworking cards in the extender and a too big resistor on the board IDSEL pin being the cause of this. Does the card show up in lspci at all? No it doesn't. Right, so it sounds like it might be this issue. Does the extender board have a PCI-PCI bridge on it? (If not, there's not really any reason to resistively couple the IDSEL line to the host, since the host should take care of that.) There's no bridge. It just decouples all voltage lines, so you can drive it from external supply and/or measure voltages and current. On the PCB it looks like the the IDSEL line is rather directly routed to the host IDSEL. It just goes through one of the bus isolation chips. So I guess (just my guess) that this chip has some resistance and if the total resistance of the chip + the IDSEL resistor on the mainboard goes above some threshold it doesn't work anymore for some cards. In the application note they write about trouble for IDSEL resistors 51ohms. More or less. You can't add the resistances like that, since the bus isolation chip buffers the IDSEL signal, but it is correct that if the host's IDSEL resistor is larger than a certain value, the combination of the resistive coupling of IDSEL plus the extra buffer in the isolator might be causing the IDSEL input on the 'guest' PCI board to assert too late (or not assert at all), causing config accesses to fail. (This also depends on the specific 'guest' PCI board used, as you noted, due to differing IDSEL trace lengths/capacitances and input pin capacitances on different PCI boards. Also, it might work at 33 MHz but not work at 66 MHz, etc.) If you feel adventurous, you could try to hack around this by figuring out which AD[31:16] line this PCI slot's IDSEL line is resistively coupled to (depends on the slot), and then adding another parallel resistor on the board itself to make the bus isolator's input buffer charge faster. Note that this does increase the load on that specific AD[] line, which might cause other funny effects. Maybe I can try with another machine tomorrow. That would only make a difference if there is no PCI-PCI bridge on the extender board. Well, they suggest it in the application note as a possible fix. ;) The bus isolation chip doesn't count as a PCI-PCI bridge. :) I'm just saying that you wouldn't see the issue you are seeing now if the extender board had a real PCI-PCI bridge on it, since in that case the type 0 config access to the guest PCI board would be generated by the bridge instead of by the host. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload
This stage is safe to bail out on signal. It's initializing about a hundred registers and trying to guaranty by retrying, so can get stretched too much on faulty h/w. -Dhananjay On 7/1/07, Jeff Garzik [EMAIL PROTECTED] wrote: While strictly this is true, I strongly urge the use of non-interruptible sleeps when used in hardware-related delays. Very rarely does one really want to care about signals for such cases. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RESEND [PATCH 0/3] NetXen: Bug fixes for multiport and blade adapters
Resending with changes suggested. -- Dhananjay Phadke NetXen Inc. drivers/net/netxen/netxen_nic.h | 177 +++--- drivers/net/netxen/netxen_nic_hdr.h |2 + drivers/net/netxen/netxen_nic_hw.c | 39 +-- drivers/net/netxen/netxen_nic_init.c | 64 +++ drivers/net/netxen/netxen_nic_main.c | 177 +++--- drivers/net/netxen/netxen_nic_phan_reg.h | 14 +++ 6 files changed, 357 insertions(+), 116 deletions(-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RESEND [PATCH 1/3] NetXen: Fix issue of MSI not working correctly
NetXen driver uses PCI function 0 to provide the functionality of MSI.
The patch makes driver check the bus master bit for function 0 and
enable it after the card initialization.
Signed-off-by: Dhananjay Phadke[EMAIL PROTECTED]
Signed-off-by: Milan Bag [EMAIL PROTECTED]
Signed-off-by: Wen Xiong [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -336,11 +336,9 @@ netxen_nic_probe(struct pci_dev *pdev, c
if (pci_using_dac)
netdev-features |= NETIF_F_HIGHDMA;
- if (pci_enable_msi(pdev)) {
+ if (pci_enable_msi(pdev))
adapter-flags = ~NETXEN_NIC_MSI_ENABLED;
- printk(KERN_WARNING %s: unable to allocate MSI interrupt
- error\n, netxen_nic_driver_name);
- } else
+ else
adapter-flags |= NETXEN_NIC_MSI_ENABLED;
netdev-irq = pdev-irq;
@@ -355,13 +353,6 @@ netxen_nic_probe(struct pci_dev *pdev, c
/* initialize the adapter */
netxen_initialize_adapter_hw(adapter);
-#ifdef CONFIG_PPC
- if ((adapter-ahw.boardcfg.board_type ==
- NETXEN_BRDTYPE_P2_SB31_10G_IMEZ)
- (pci_func_id == 2))
- goto err_out_free_adapter;
-#endif /* CONFIG_PPC */
-
/*
* Adapter in our case is quad port so initialize it before
* initializing the ports
@@ -509,16 +500,22 @@ netxen_nic_probe(struct pci_dev *pdev, c
NETXEN_CAM_RAM(0x1fc)));
if (val == 0x) {
/* This is the first boot after power up */
+ netxen_nic_read_w0(adapter, NETXEN_PCIE_REG(0x4), val);
+ if (!(val 0x4)) {
+ val |= 0x4;
+ netxen_nic_write_w0(adapter, NETXEN_PCIE_REG(0x4), val);
+ netxen_nic_read_w0(adapter, NETXEN_PCIE_REG(0x4), val);
+ }
val = readl(NETXEN_CRB_NORMALIZE(adapter,
NETXEN_ROMUSB_GLB_SW_RESET));
printk(KERN_INFONetXen: read 0x%08x for reset reg.\n,val);
if (val != 0x8f) {
/* clear the register for future unloads/loads */
- writel(0, NETXEN_CRB_NORMALIZE(adapter,
- NETXEN_CAM_RAM(0x1fc)));
- printk(KERN_ERR ERROR in NetXen HW init sequence.\n);
- err = -ENODEV;
- goto err_out_free_dev;
+ writel(0, NETXEN_CRB_NORMALIZE(adapter,
+ NETXEN_CAM_RAM(0x1fc)));
+ printk(KERN_ERR ERROR in NetXen HW init
sequence.\n);
+ err = -ENODEV;
+ goto err_out_free_dev;
}
/* clear the register for future unloads/loads */
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RESEND [PATCH 2/3] NetXen: Support per PCI-function interrupt mask registers
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix problems related to working of different ports in
multi Port card.
Signed-off by: Dhananjay Phadke [EMAIL PROTECTED]
Signed-off by: Milan Bag [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic.h
@@ -937,6 +937,7 @@ struct netxen_adapter {
struct netxen_ring_ctx *ctx_desc;
struct pci_dev *ctx_desc_pdev;
dma_addr_t ctx_desc_phys_addr;
+ int intr_scheme;
int (*enable_phy_interrupts) (struct netxen_adapter *);
int (*disable_phy_interrupts) (struct netxen_adapter *);
void (*handle_phy_intr) (struct netxen_adapter *);
@@ -1080,37 +1081,103 @@ struct net_device_stats *netxen_nic_get_
static inline void netxen_nic_disable_int(struct netxen_adapter *adapter)
{
- /*
-* ISR_INT_MASK: Can be read from window 0 or 1.
-*/
- writel(0x7ff, PCI_OFFSET_SECOND_RANGE(adapter, ISR_INT_MASK));
+ uint32_tmask = 0x7ff;
+ int count = 0;
+ DPRINTK(1, INFO, Entered ISR Disable \n);
+
+ switch (adapter-portnum) {
+ case 0:
+ writel(0x0, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_0));
+ break;
+ case 1:
+ writel(0x0, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_1));
+ break;
+ case 2:
+ writel(0x0, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_2));
+ break;
+ case 3:
+ writel(0x0, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_3));
+ break;
+ }
+
+ if (adapter-intr_scheme != -1
+ adapter-intr_scheme != INTR_SCHEME_PERPORT) {
+ writel(mask,
+ (void *)(PCI_OFFSET_SECOND_RANGE(adapter,
ISR_INT_MASK)));
+ }
+
+ /* Window = 0 or 1 */
+ if (!(adapter-flags NETXEN_NIC_MSI_ENABLED)) {
+ do {
+ writel(0x, (void *)
+ (PCI_OFFSET_SECOND_RANGE(adapter,
ISR_INT_TARGET_STATUS)));
+ mask = readl((void *)
+ (pci_base_offset(adapter,
ISR_INT_VECTOR)));
+ udelay(10);
+ } while (((mask 0x80) != 0) (++count 32));
+
+ if ((mask 0x80) != 0) {
+ printk(KERN_NOTICE Could not disable interrupt
completely\n);
+ }
+ }
+
+ DPRINTK(1, INFO, Done with Disable Int\n);
+
+ return;
}
static inline void netxen_nic_enable_int(struct netxen_adapter *adapter)
{
u32 mask;
- switch (adapter-ahw.board_type) {
- case NETXEN_NIC_GBE:
- mask = 0x77b;
+ DPRINTK(1, INFO, Entered ISR Enable \n);
+
+ if (adapter-intr_scheme != -1
+ adapter-intr_scheme != INTR_SCHEME_PERPORT) {
+ switch (adapter-ahw.board_type) {
+ case NETXEN_NIC_GBE:
+ mask = 0x77b;
+ break;
+ case NETXEN_NIC_XGBE:
+ mask = 0x77f;
+ break;
+ default:
+ mask = 0x7ff;
+ break;
+ }
+
+ writel(mask,
+ (void *)(PCI_OFFSET_SECOND_RANGE(adapter,
ISR_INT_MASK)));
+ }
+ switch (adapter-portnum) {
+ case 0:
+ writel(0x1, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_0));
+ break;
+ case 1:
+ writel(0x1, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_1));
break;
- case NETXEN_NIC_XGBE:
- mask = 0x77f;
+ case 2:
+ writel(0x1, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_2));
break;
- default:
- mask = 0x7ff;
+ case 3:
+ writel(0x1, NETXEN_CRB_NORMALIZE(adapter, CRB_SW_INT_MASK_3));
break;
}
- writel(mask, PCI_OFFSET_SECOND_RANGE(adapter, ISR_INT_MASK));
-
if (!(adapter-flags NETXEN_NIC_MSI_ENABLED)) {
mask = 0xbff;
- writel(0X0, NETXEN_CRB_NORMALIZE(adapter, CRB_INT_VECTOR));
- writel(mask, PCI_OFFSET_SECOND_RANGE(adapter,
-ISR_INT_TARGET_MASK));
+ if (adapter-intr_scheme != -1
+ adapter-intr_scheme != INTR_SCHEME_PERPORT) {
+ writel(0X0, NETXEN_CRB_NORMALIZE(adapter,
CRB_INT_VECTOR));
+ }
+ writel(mask,
+ (void *)(PCI_OFFSET_SECOND_RANGE(adapter,
ISR_INT_TARGET_MASK)));
}
+
+
RESEND [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload
These changes allow driver close routine to be called during module unload,
to clean-up buffers and other software resources, flush queues etc. Also,
hardware is reset to pristine state.
Signed-off-by: Dhananjay Phadke [EMAIL PROTECTED]
Signed-off-by: Milan Bag [EMAIL PROTECTED]
Signed-off-by: Wen Xiong [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic.h
@@ -952,6 +952,24 @@ struct netxen_adapter {
int (*stop_port) (struct netxen_adapter *);
}; /* netxen_adapter structure */
+/*
+ * NetXen dma watchdog control structure
+ *
+ * Bit 0 : enabled = R/O: 1 watchdog active, 0 inactive
+ * Bit 1 : disable_request = 1 req disable dma watchdog
+ * Bit 2 : enable_request = 1 req enable dma watchdog
+ * Bit 3-31: unused
+ */
+
+#define netxen_set_dma_watchdog_disable_req(config_word) \
+ _netxen_set_bits(config_word, 1, 1, 1)
+#define netxen_set_dma_watchdog_enable_req(config_word) \
+ _netxen_set_bits(config_word, 2, 1, 1)
+#define netxen_get_dma_watchdog_enabled(config_word) \
+ ((config_word) 0x1)
+#define netxen_get_dma_watchdog_disabled(config_word) \
+ (((config_word) 1) 0x1)
+
/* Max number of xmit producer threads that can run simultaneously */
#defineMAX_XMIT_PRODUCERS 16
@@ -1031,8 +1049,8 @@ int netxen_nic_erase_pxe(struct netxen_a
/* Functions from netxen_nic_init.c */
void netxen_free_adapter_offload(struct netxen_adapter *adapter);
int netxen_initialize_adapter_offload(struct netxen_adapter *adapter);
-void netxen_phantom_init(struct netxen_adapter *adapter, int pegtune_val);
-void netxen_load_firmware(struct netxen_adapter *adapter);
+int netxen_phantom_init(struct netxen_adapter *adapter, int pegtune_val);
+int netxen_load_firmware(struct netxen_adapter *adapter);
int netxen_pinit_from_rom(struct netxen_adapter *adapter, int verbose);
int netxen_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp);
int netxen_rom_fast_read_words(struct netxen_adapter *adapter, int addr,
@@ -1231,6 +1249,62 @@ static inline void get_brd_name_by_type(
name = Unknown;
}
+static inline int
+dma_watchdog_shutdown_request(struct netxen_adapter *adapter)
+{
+ u32 ctrl;
+
+ /* check if already inactive */
+ if (netxen_nic_hw_read_wx(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl, 4))
+ printk(KERN_ERR failed to read dma watchdog status\n);
+
+ if (netxen_get_dma_watchdog_enabled(ctrl) == 0)
+ return 1;
+
+ /* Send the disable request */
+ netxen_set_dma_watchdog_disable_req(ctrl);
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl);
+
+ return 0;
+}
+
+static inline int
+dma_watchdog_shutdown_poll_result(struct netxen_adapter *adapter)
+{
+ u32 ctrl;
+
+ if (netxen_nic_hw_read_wx(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl, 4))
+ printk(KERN_ERR failed to read dma watchdog status\n);
+
+ return ((netxen_get_dma_watchdog_enabled(ctrl) == 0)
+ (netxen_get_dma_watchdog_disabled(ctrl) == 0));
+}
+
+static inline int
+dma_watchdog_wakeup(struct netxen_adapter *adapter)
+{
+ u32 ctrl;
+
+ if (netxen_nic_hw_read_wx(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl, 4))
+ printk(KERN_ERR failed to read dma watchdog status\n);
+
+ if (netxen_get_dma_watchdog_enabled(ctrl))
+ return 1;
+
+ /* send the wakeup request */
+ netxen_set_dma_watchdog_enable_req(ctrl);
+
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_CAM_RAM(NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL), ctrl);
+
+ return 0;
+}
+
+
int netxen_is_flash_supported(struct netxen_adapter *adapter);
int netxen_get_flash_mac_addr(struct netxen_adapter *adapter, u64 mac[]);
extern void netxen_change_ringparam(struct netxen_adapter *adapter);
Index: netdev-2.6/drivers/net/netxen/netxen_nic_hdr.h
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_hdr.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic_hdr.h
@@ -687,4 +687,6 @@ enum {
#define PCIE_MAX_MASTER_SPLIT (0x14048)
+#define NETXEN_CAM_RAM_DMA_WATCHDOG_CTRL (0x14)
+
#endif /* __NETXEN_NIC_HDR_H_ */
Index: netdev-2.6/drivers/net/netxen/netxen_nic_hw.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_hw.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_hw.c
@@ -377,7 +377,7 @@ int netxen_nic_hw_resources(struct netxe
Re: [PATCH 3/3] NetXen: Graceful teardown of interface and hardware upon module unload
Dhananjay Phadke wrote: This stage is safe to bail out on signal. It's initializing about a hundred registers and trying to guaranty by retrying, so can get stretched too much on faulty h/w. This implies that you have -add- code to check for and handle signals at each delay point. Don't bother. Too much code bloat for negligable gain. It is better just to remove the _interruptible, for many reasons. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM policy, hotplug, power saving (was Re: [PATCH] b44: power down PHY when interface down)
On Jun 30, 2007, at 12:42:06, Jeff Garzik wrote: Definitely matters. Switch renegotiation can take a while, and you must take into account the common case of interface bouncing (immediate down, then up). Hoards actively complained the few times we experimented with this, because of e.g. DHCP's habit of bouncing the interface, which resulted in PHY power bouncing, which resulted in negotiation, which resulted in an excrutiating wait on various broken or stupid switches. Overall, this may be classed with other problems of a similar sort: we can power down a PHY, but that removes hotplug capability and extends partner/link negotiation time. Like SATA, we actually want to support BOTH -- active hotplug and PHY power-down -- and so this wanders into power management policy. Give me a knob, and we can program plenty of ethernet|SATA|USB|... drivers to power down the PHY and save power. With some buggy switches and other hardware you actually *want* to bounce the link to get them to properly renegotiate. I can also see wanting to power off and on a single-PoE-port NIC to restart whatever device is at the other end, although I don't know if any such devices exist. Currently the tg3 driver turns the PHY off and on during down/ up on a few of my systems, which I use to make a buggy no-name switch recognize STP changes properly. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
