All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Arjan van de Ven <arjanv@redhat.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: Resume enhancement: restore pci config space
Date: Tue, 01 Jun 2004 15:54:43 +0200	[thread overview]
Message-ID: <s5hllj7qt7g.wl@alsa2.suse.de> (raw)
In-Reply-To: <20040531133834.GA5834@devserv.devel.redhat.com>

At Mon, 31 May 2004 15:38:34 +0200,
Arjan van de Ven wrote:
> 
> [1  <text/plain; us-ascii (7bit)>]
> On Sun, May 30, 2004 at 08:40:31PM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > One can rightfully argue that the driver resume method should do this, and
> > > yes that is right. So the patch only does it for devices that don't have a
> > > resume method. Like the main PCI bridge on my testbox of which the bios so
> > > nicely forgets to restore the bus master bit during resume.. With this patch
> > > my testbox resumes just fine while it, well, wasn't all too happy as you can
> > > imagine without a busmaster pci bridge.
> > ...
> > > +/* 
> > > + * Default resume method for devices that have no driver provided resume,
> > > + * or not even a driver at all.
> > > + */
> > > +static void pci_default_resume(struct pci_dev *pci_dev)
> > > +{
> > 
> > Perhaps this should not be static so that drivers don't
> > need to duplicate this?
> 
> I wonder if that is useful, can you see cases where it would be?
> I mean, all it does is provide a default handler for places that don't have
> one. All this is info drivers already have, if a driver chooses to implement
> it's resume handler I think they can do better than this (and thus don't
> need this helper). But... if you can come up with a reasonable use I don't
> oppose it. I do like to see a sane user first though before adding this to
> the driver API...

well, most drivers need more or less the similar procedure like
pci_default_suspend/resume(): enable/disable the pci device, toggle
busmastering, and store/restore the pci status. 
if default callbacks are exported, the driver callbacks can be
simplified, such as

int xxx_suspend(struct pci_dev *dev, u32 state)
{
	// ... do h/w specific things
	return pci_default_suspend(dev, state);
}

int xxx_resume(struct pci_dev *dev)
{
	int err;
	if ((err = pci_default_resume(dev)) < 0)
		return err;
	// ... do h/w specific
}


but IMO, the jobs of pci_default_suspend/resume() should be applied
always after/before calling driver's suspend/resume callbacks.

can they break anything potentially?


--
Takashi Iwai <tiwai@suse.de>		ALSA Developer - www.alsa-project.org

  reply	other threads:[~2004-06-01 13:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-26 20:35 Resume enhancement: restore pci config space Arjan van de Ven
2004-05-26 22:39 ` Greg KH
2004-05-27  9:44 ` Takashi Iwai
2004-05-30 18:40 ` Pavel Machek
2004-05-31 13:38   ` Arjan van de Ven
2004-06-01 13:54     ` Takashi Iwai [this message]
2004-06-01 15:06       ` Arjan van de Ven
2004-06-01 15:26         ` Takashi Iwai
2004-06-01 15:38           ` Arjan van de Ven
2004-06-01 15:58             ` Takashi Iwai
2004-06-01 16:02             ` Pavel Machek
2004-06-01 16:18               ` Takashi Iwai
2004-05-31 16:38   ` Jan-Benedict Glaw
  -- strict thread matches above, loose matches on Subject: below --
2004-05-26 21:44 Nakajima, Jun

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=s5hllj7qt7g.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=arjanv@redhat.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.