lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-id: <46984CF0.8080700@intel.com> Date: Fri, 13 Jul 2007 21:11:28 -0700 From: "Kok, Auke" <auke-jan.h.kok@...el.com> To: David Fries <david@...es.net> Cc: NetDev <netdev@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [2.6 patch] eepro100 resume patch [adding netdev] David Fries wrote: > When I did a software suspend to disk then resumed the Intel network > card using eepro100 driver would be unable to transmit packets. I > tracked this down and found a register write after the print message > "DP83840 specific setup" which wasn't being executed when the system > was restored. This fix moves that write and another write which > forces the link speed and duplex. > > After doing this work and preparing the patch I checked out the > mailing list only to find a patch that removes the eepro100. I then > updated Kconfig, though I wonder why it didn't have a similar message > in it long time ago. > > I too had tried the e100 driver some time ago and it didn't work, That argument is pretty useless right now. Please *test* e100 and *report issues*. I recently did some very intensive suspend/resume testing (and fixes) on e100 and I have yet to hear of any problems with it since... that was 2.6.18 or so even. > eepro100 did and I've been using it so long that I've almost forgotten > about that. I just gave the e100 driver a try and I've been running > for about an hour now without any problems and it does resume after a > suspend to disk operation. > > Signed-off-by: David Fries <David@...es.net> I don't think I need to NAK this. I doubt that Jeff Garzik will apply this in the first place. eepro100 is on it's way out, so let's focus on what matters. Auke > Index: drivers/net/Kconfig > =================================================================== > RCS file: /home/david/kernel/k/spacedout/patches/linux/drivers/net/Attic/Kconfig,v > retrieving revision 1.1.2.1 > diff -u -r1.1.2.1 Kconfig > --- drivers/net/Kconfig 13 Jul 2007 23:16:36 -0000 1.1.2.1 > +++ drivers/net/Kconfig 13 Jul 2007 23:31:29 -0000 > @@ -1467,6 +1467,11 @@ > depends on NET_PCI && PCI > select MII > help > + ** Warning ** eepro100 (this driver) has been requested to be > + removed from the kernel source tree. Please use e100 and report > + any bugs as that is the driver that will be supported going > + forward. > + > If you have an Intel EtherExpress PRO/100 PCI network (Ethernet) > card, say Y and read the Ethernet-HOWTO, available from > <http://www.tldp.org/docs.html#howto>. > Index: drivers/net/eepro100.c > =================================================================== > RCS file: /home/david/kernel/k/spacedout/patches/linux/drivers/net/eepro100.c,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -u -r1.4 -r1.5 > --- drivers/net/eepro100.c 10 Jul 2007 23:56:54 -0000 1.4 > +++ drivers/net/eepro100.c 13 Jul 2007 22:10:16 -0000 1.5 > @@ -446,6 +446,7 @@ > unsigned short partner; /* Link partner caps. */ > struct mii_if_info mii_if; /* MII API hooks, info */ > u32 msg_enable; /* debug message level */ > + int option; /* Module options for this card */ > }; > > /* The parameters for a CmdConfigure operation. > @@ -717,6 +718,8 @@ > > /* we must initialize this early, for mdio_{read,write} */ > sp->regs = ioaddr; > + /* store override options for later use. */ > + sp->option = option; > > #if 1 || defined(kernel_bloat) > /* OK, this is pure kernel bloat. I don't like it when other drivers > @@ -743,20 +746,22 @@ > phys[(eeprom[7]>>8)&7]); > if (((eeprom[6]>>8) & 0x3f) == DP83840 > || ((eeprom[6]>>8) & 0x3f) == DP83840A) { > - int mdi_reg23 = mdio_read(dev, eeprom[6] & 0x1f, 23) | 0x0422; > + int mdi_reg23_orig = mdio_read(dev, eeprom[6] & 0x1f, 23); > + int mdi_reg23 = mdi_reg23_orig | 0x0422; > if (congenb) > mdi_reg23 |= 0x0100; > - printk(KERN_INFO" DP83840 specific setup, setting register 23 to %4.4x.\n", > - mdi_reg23); > - mdio_write(dev, eeprom[6] & 0x1f, 23, mdi_reg23); > + /* Print the message here, write in speedo_resume, which > + * is called both on module load and from > + * eepro100_resume. > + */ > + printk(KERN_INFO" DP83840 specific setup, setting register 23 to %4.4x, was %4.4x.\n", > + mdi_reg23, mdi_reg23_orig); > } > if ((option >= 0) && (option & 0x70)) { > + /* Print here, write in speedo_resume. */ > printk(KERN_INFO " Forcing %dMbs %s-duplex operation.\n", > (option & 0x20 ? 100 : 10), > (option & 0x10 ? "full" : "half")); > - mdio_write(dev, eeprom[6] & 0x1f, MII_BMCR, > - ((option & 0x20) ? 0x2000 : 0) | /* 100mbps? */ > - ((option & 0x10) ? 0x0100 : 0)); /* Full duplex? */ > } > > /* Perform a system self-test. */ > @@ -1050,6 +1055,24 @@ > struct speedo_private *sp = netdev_priv(dev); > void __iomem *ioaddr = sp->regs; > > + /* DP83840 specific setup, moved here from from speedo_found1 because > + * it needs to called after resume, ie suspend to disk. > + * 07-11-2007 David Fries <david@...es.net> > + */ > + if (((sp->phy[0]>>8) & 0x3f) == DP83840 > + || ((sp->phy[0]>>8) & 0x3f) == DP83840A) { > + int mdi_reg23 = mdio_read(dev, sp->phy[0] & 0x1f, 23) | 0x0422; > + if (congenb) > + mdi_reg23 |= 0x0100; > + mdio_write(dev, sp->phy[0] & 0x1f, 23, mdi_reg23); > + } > + if ((sp->option >= 0) && (sp->option & 0x70)) { > + mdio_write(dev, sp->phy[0] & 0x1f, MII_BMCR, > + ((sp->option & 0x20) ? 0x2000 : 0) | /* 100mbps? */ > + ((sp->option & 0x10) ? 0x0100 : 0)); /* Full duplex? */ > + } > + > + > /* Start with a Tx threshold of 256 (0x..20.... 8 byte units). */ > sp->tx_threshold = 0x01208000; > > > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists