netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <hermes@gibson.dropbear.id.au>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Dan Williams <dcbw@redhat.com>, netdev@oss.sgi.com, jgarzik@redhat.com
Subject: Re: [PATCH 2.6.10-rc1 7/15] wireless/orinoco: Update card reset/init code and add card-specific data structures
Date: Wed, 27 Oct 2004 14:00:10 +1000	[thread overview]
Message-ID: <20041027040010.GA1676@zax> (raw)
In-Reply-To: <417EA8D8.3060403@pobox.com>

On Tue, Oct 26, 2004 at 03:43:20PM -0400, Jeff Garzik wrote:
> Dan Williams wrote:
> >+/* Orinoco PCI specific data */
> >+struct orinoco_pci_card {
> >+	u32 pci_state[16];	/* PCI suspend/resume state */
> >+};
> 
> no need with GregKH's latest upstream changes

And recently removed from the for_linus branch.

> >-	printk(KERN_NOTICE "Reset done");
> > 	timeout = jiffies + (HERMES_PCI_COR_ONT * HZ / 1000);
> >-	while(time_before(jiffies, timeout)) {
> >-		printk(".");
> >+	while(time_before(jiffies, timeout))
> > 		mdelay(1);
> 
> the loop is non-sensical... at this point use msleep() or actually 
> mdelay() for the correct period, rather than looping on mdelay(1)

Oh, yes, that really shouldn't have survived this long.  Now fixed in
CVS (for_linus branch, merge to HEAD coming shortly).

> >@@ -199,61 +194,68 @@
> > 	u16 *pci_ioaddr = NULL;
> > 	unsigned long pci_iolen;
> > 	struct orinoco_private *priv = NULL;
> >+	struct orinoco_pci_card *card;
> > 	struct net_device *dev = NULL;
> > 
> > 	err = pci_enable_device(pdev);
> >-	if (err)
> >-		return -EIO;
> >+	if (err) {
> >+		printk(KERN_ERR PFX "Cannot enable PCI device\n");
> >+		return -err;
> >+	}
> 
> incorrect...  err is already negative.

Also now fixed in CVS.

> >@@ -325,6 +327,9 @@
> > 	
> > 	orinoco_unlock(priv, &flags);
> > 
> >+	pci_save_state(pdev, card->pci_state);
> >+	pci_set_power_state(pdev, 3);
> >+
> > 	return 0;
> > }
> > 
> >@@ -332,11 +337,15 @@
> > {
> > 	struct net_device *dev = pci_get_drvdata(pdev);
> > 	struct orinoco_private *priv = netdev_priv(dev);
> >+	struct orinoco_pci_card *card = priv->card;
> > 	unsigned long flags;
> > 	int err;
> > 
> > 	printk(KERN_DEBUG "%s: Orinoco-PCI waking up\n", dev->name);
> > 
> >+	pci_set_power_state(pdev, 0);
> >+	pci_restore_state(pdev, card->pci_state);
> >+
> > 	err = orinoco_reinit_firmware(dev);
> > 	if (err) {
> > 		printk(KERN_ERR "%s: Error %d re-initializing firmware on 
> > 		orinoco_pci_resume()\n",
> 
> These two don't build in the latest 2.6.x kernel.

This was fixed by Pavel in the last day or so.

> >@@ -332,6 +374,8 @@
> > 	.id_table	= orinoco_plx_pci_id_table,
> > 	.probe		= orinoco_plx_init_one,
> > 	.remove		= __devexit_p(orinoco_plx_remove_one),
> >+	.suspend	= 0,
> >+	.resume		= 0,
> > };
> 
> superfluous change

Removed from CVS.

> >+ * Do a soft reset of the card using the Configuration Option Register
> >+ */
> >+static int orinoco_tmd_cor_reset(struct orinoco_private *priv)
> >+{
> >+	hermes_t *hw = &priv->hw;
> >+	struct orinoco_tmd_card *card = priv->card;
> >+	u32 addr = card->tmd_io;
> >+	unsigned long timeout;
> >+	u16 reg;
> >+
> >+	outb(COR_VALUE | COR_RESET, addr);
> >+	mdelay(1);
> >+
> >+	outb(COR_VALUE, addr);
> >+	mdelay(1);
> 
> PCI posting bugs?

That I don't know.  Unfortunately a lot of these cards are rather
nasty and fragile, so I don't really want to mess with it.

> >+	/* Just in case, wait more until the card is no longer busy */
> >+	timeout = jiffies + (TMD_RESET_TIME * HZ / 1000);
> >+	reg = hermes_read_regn(hw, CMD);
> >+	while (time_before(jiffies, timeout) && (reg & HERMES_CMD_BUSY)) {
> >+		mdelay(1);
> >+		reg = hermes_read_regn(hw, CMD);
> >+	}
> 
> max delay without sleep way too long

Yes, yes it is.  However, we've had a lot of trouble with timeouts and
locking and sleeping in the driver.  On the grounds that the bad case
usually won't be hit, I'd rather not mess with that until someone has
a rather better insight on how to organize this stuff to ensure we
give the cards the delays they need, without the blocks-in-sleep.  I
don't have a TMD card myself, so I'm extra wary about changing it.

-- 
David Gibson			| For every complex problem there is a
david AT gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

  reply	other threads:[~2004-10-27  4:00 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-26 18:12 [PATCHES] wireless: Update in-kernel orinoco driver Dan Williams
2004-10-26 18:33 ` [PATCH 2.6.10-rc1 1/15] wireless/orinoco: Use msleep() instead of hardcoded schedule_timeout()s Dan Williams
2004-10-26 18:47   ` Christoph Hellwig
2004-10-26 19:35     ` Dan Williams
2004-10-26 19:42       ` Christoph Hellwig
2004-10-26 19:55         ` Dan Williams
2004-10-27  3:13           ` David Gibson
2004-10-27 13:11             ` Dan Williams
2004-10-28  1:42               ` David Gibson
2004-10-26 19:34   ` Jeff Garzik
2004-10-26 18:38 ` [PATCH 2.6.10-rc1 1/15] wireless/orinoco: use msleep() Dan Williams
2004-10-26 18:39 ` [PATCH 2.6.10-rc1 2/15] wireless/orinoco: fix up printk text Dan Williams
2004-10-26 18:43 ` [PATCH 2.6.10-rc1 3/15] wireless/orinoco: encapsulate direct hardware operations Dan Williams
2004-10-27  3:15   ` David Gibson
2004-10-26 18:45 ` [PATCH 2.6.10-rc1 4/15] wireless/orinoco: Update orinoco changelog and module parameters Dan Williams
2004-10-26 19:36   ` Jeff Garzik
2004-10-27  3:15   ` David Gibson
2004-10-26 18:47 ` [PATCH 2.6.10-rc1 5/15] wireless/orinoco: Update orinoco pcmcia driver's IRQ handling Dan Williams
2004-10-26 18:51 ` [PATCH 2.6.10-rc1 6/15] wireless/orinoco: New device data release function Dan Williams
2004-10-26 18:56 ` [PATCH 2.6.10-rc1 7/15] wireless/orinoco: Update card reset/init code and add card-specific data structures Dan Williams
2004-10-26 19:43   ` Jeff Garzik
2004-10-27  4:00     ` David Gibson [this message]
2004-10-26 19:04 ` R[PATCH 2.6.10-rc1 8/15] wireless/orinoco: Refactor spinlocks so we don't necessarily have to disable interrupts Dan Williams
2004-10-26 19:44   ` Jeff Garzik
2004-10-27  4:14     ` David Gibson
2004-10-26 19:07 ` [PATCH 2.6.10-rc1 9/15] wireless/orinoco: Remove dump_recs in preparation for a more flexible replacement Dan Williams
2004-10-26 19:13 ` [PATCH 2.6.10-rc1 10/15] wireless/orinoco: Use wireless handlers rather than ioctl()s Dan Williams
2004-10-26 19:18 ` [PATCH 2.6.10-rc1 11/15] wireless/orinoco: Clean up firmware version & capability detection Dan Williams
2004-10-26 19:20 ` [PATCH 2.6.10-rc1 12/15] wireless/orinoco: Use netif routines rather than keeping link state ourselves Dan Williams
2004-10-26 19:22 ` [PATCH 2.6.10-rc1 13/15] wireless/orinoco: RF monitor mode support Dan Williams
2004-10-26 19:24 ` [PATCH 2.6.10-rc1 14/15] wireless/orinoco: add minimal ethtool support Dan Williams
2004-10-26 19:46   ` Jeff Garzik
2004-10-27  4:01     ` David Gibson
2004-10-26 19:28 ` [PATCH 2.6.10-rc1 15/15] wireless/orinoco: Wireless scanning support Dan Williams
2004-10-26 19:33   ` Francois Romieu
2004-10-27  4:06     ` David Gibson
2004-10-27  2:05 ` [PATCHES] wireless: Update in-kernel orinoco driver David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041027040010.GA1676@zax \
    --to=hermes@gibson.dropbear.id.au \
    --cc=dcbw@redhat.com \
    --cc=jgarzik@pobox.com \
    --cc=jgarzik@redhat.com \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).