From: Julia Lawall <julia.lawall@lip6.fr>
To: Grant Grundler <grantgrundler@gmail.com>
Cc: Grant Grundler <grundler@parisc-linux.org>,
"open list:TULIP NETWORK DRI..." <netdev@vger.kernel.org>
Subject: Re: question about tulip/winbond-840.c
Date: Thu, 2 Jan 2014 17:16:00 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.10.1401021641230.2088@hadrien> (raw)
In-Reply-To: <CAP6odjj2jPfgEBdHv+GGDhVaHt4KEm_DWCX3PdCxCjUbApWc8Q@mail.gmail.com>
On Thu, 2 Jan 2014, Grant Grundler wrote:
> On Thu, Jan 2, 2014 at 6:24 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> > I don't know if you want to bother about this, because it is very old code
> > and is apparently not hurting anyone, but I don't see the point of the
> > call to pci_enable_device in the function w840_resume.
>
> I believe the call to pci_enable_device is required:
> http://lxr.free-electrons.com/source/Documentation/PCI/pci.txt
>
>
> 254 3.1 Enable the PCI device
> 255 ~~~~~~~~~~~~~~~~~~~~~~~~~
> 256 Before touching any device registers, the driver needs to enable
> 257 the PCI device by calling pci_enable_device(). This will:
> 258 o wake up the device if it was in suspended state,
> 259 o allocate I/O and memory regions of the device (if BIOS did not),
> 260 o allocate an IRQ (if BIOS did not).
>
> > The driver had a
> > call to pci_enable_device in its probe function, but it contains no call
> > to pci_disable_device, unlike some other tulip drivers.
>
> I think the bug is the pci_disable_device is not called. The driver
> should call pci_disable_device in suspend function and on failure path
> in the resume function. I've never looked at this code before and I
> believe has existed before PCI API was "mature". That's probably why
> it's not using the API correctly.
>
> > Perhaps the call has a small functionality,
>
> Yes - assuming pci.txt isn't stale. :)
>
> > but it seems like it can at least never return
> > a value other than 0, because the result of
> > atomic_inc_return(&dev->enable_cnt) in pci_enable_device_flags should
> > be greater than 1.
>
> Off hand I don't recall..pci_enable_device used to setup alot more
> stuff including power state and many of those could fail.
It does set up more things. But it doesn't do much if the device has not
been disabled.
http://lxr.free-electrons.com/source/drivers/pci/pci.c#L1190
Looking across the entire Linux kernel, I see cases where there are
enables but no disables, and cases where there are disables and no
enables. So I wouldn't really know whether a change is needed.
julia
next prev parent reply other threads:[~2014-01-02 16:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-02 14:24 question about tulip/winbond-840.c Julia Lawall
2014-01-02 15:37 ` Grant Grundler
2014-01-02 16:16 ` Julia Lawall [this message]
2014-01-02 16:53 ` Grant Grundler
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=alpine.DEB.2.10.1401021641230.2088@hadrien \
--to=julia.lawall@lip6.fr \
--cc=grantgrundler@gmail.com \
--cc=grundler@parisc-linux.org \
--cc=netdev@vger.kernel.org \
/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