From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Mark Einon <mark.einon@gmail.com>
Cc: Peter Hurley <peter@hurleysoftware.com>,
Alan Stern <stern@rowland.harvard.edu>,
linux1394-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH] firewire: Fix ohci free_irq() warning
Date: Sat, 2 Feb 2013 16:01:03 +0100 [thread overview]
Message-ID: <20130202160103.0ce1fc43@stein> (raw)
In-Reply-To: <CANK3SE2nsxLMUyANzsov4d86ow4v9NuzaZsS3XvjpQJOfYXYUQ@mail.gmail.com>
On Feb 01 Mark Einon wrote:
> On 1 February 2013 21:09, Peter Hurley <peter@hurleysoftware.com> wrote:
> >>>> On Jan 29 Alan Stern wrote:
> >>>>> Why does the pci_suspend routine call free_irq() at all? As far as I
> >>>>> know, it's not supposed to do that. Won't the device continue to use
> >>>>> the same IRQ after it is resumed?
As far as I can tell, it happened to be done that way as a side effect of
how the probe() and resume() methods share code. It has remained like
this since the initial implementation:
http://git.kernel.org/linus/2aef469a35a2
Still, at this point I would like to learn whether .suspend() followed
by .remove() is a valid order of sequence which drivers must support
before I prepare myself to get comfortable with a refactoring of
firewire-ohci's .probe()/.resume()/suspend()/remove(). Obviously, so far
my assumption was that a successful .suspend() can only ever be followed
by .resume().
> > I think what Alan means is that the suspend/resume code should just
> > mask/unmask interrupts at the OHCI controller, via the OHCI
> > IntEventClear/Set registers (naturally, saving the current mask and
> > restoring it on resume).
> >
> > Of course, there's a lot more to do with an OHCI controller -- as you
> > note. Like stopping running DMA contexts :) And restarting them on
> > resume.
> >
> > I'd do it, but I'm buried to my eyeballs in tty right now -- not fun. I
> > can _eventually_ do this as I need to address problems with the FW643
> > anyway at some point, but it's going to be a little while.
>
> Hi Peter,
>
> Ok, understood. I can certainly attempt a patch if I get time.
>
> >
> > In the meantime, I'm a little confused: you say you can't test this code
> > because you have no hardware; but then how'd you trip this bug?
>
> I can test the code in that I have a firewire port on my laptop, but
> haven't got anything to plug into the port.
> I assume that any large changes I make are quite capable of breaking
> something there...
This is a valid assumption. Some years ago I caused a regression in
stable kernel branches in exactly this way myself.
--
Stefan Richter
-=====-===-= --=- ---=-
http://arcgraph.de/sr/
next prev parent reply other threads:[~2013-02-02 15:01 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-28 22:09 [PATCH] firewire: Fix ohci free_irq() warning Mark Einon
2013-01-28 23:01 ` Stefan Richter
2013-01-29 12:44 ` Mark Einon
2013-01-29 16:04 ` Stefan Richter
2013-01-29 17:01 ` Alan Stern
2013-01-29 17:01 ` Alan Stern
2013-01-30 23:45 ` Mark Einon
2013-01-31 15:04 ` Alan Stern
2013-01-31 15:04 ` Alan Stern
2013-02-01 19:13 ` Mark Einon
2013-02-01 21:09 ` Peter Hurley
2013-02-01 21:14 ` Peter Hurley
2013-02-01 23:00 ` Mark Einon
2013-02-02 15:01 ` Stefan Richter [this message]
2013-02-02 15:16 ` Alan Stern
2013-02-02 15:16 ` Alan Stern
2013-02-02 15:30 ` Stefan Richter
2013-02-02 15:30 ` Stefan Richter
2013-01-30 23:43 ` Mark Einon
2013-02-02 14:24 ` Stefan Richter
2013-02-02 15:21 ` Alan Stern
2013-02-02 15:21 ` Alan Stern
2013-01-29 2:15 ` Greg KH
2013-02-01 19:50 ` [PATCH v2] " Mark Einon
2013-02-01 19:50 ` Mark Einon
2013-02-05 10:58 ` [PATCH v3] " Mark Einon
2013-02-05 10:58 ` Mark Einon
2013-02-17 8:41 ` Stefan Richter
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=20130202160103.0ce1fc43@stein \
--to=stefanr@s5r6.in-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=mark.einon@gmail.com \
--cc=peter@hurleysoftware.com \
--cc=stern@rowland.harvard.edu \
/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.