LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <firstname.lastname@example.org>
To: "Luck, Tony" <email@example.com>
Cc: Alex Williamson <firstname.lastname@example.org>,
Jiang Liu <email@example.com>,
Bjorn Helgaas <firstname.lastname@example.org>,
"email@example.com" <firstname.lastname@example.org>, "Zheng, Lv" <email@example.com>,
Subject: Re: [PATCH] x86/PCI: Fully disable devices before releasing IRQ resource
Date: Thu, 12 Mar 2015 02:17:15 +0100 [thread overview]
Message-ID: <6862626.yP8c2o2fAj@vostro.rjw.lan> (raw)
On Wednesday, March 11, 2015 10:04:42 PM Luck, Tony wrote:
> >> Unfortunately there's a long standing comment in pci_device_remove():
> >> /*
> >> * We would love to complain here if pci_dev->is_enabled is set, that
> >> * the driver should have called pci_disable_device(), but the
> >> * unfortunate fact is there are too many odd BIOS and bridge setups
> >> * that don't like drivers doing that all of the time.
> >> * Oh well, we can dream of sane hardware when we sleep, no matter how
> >> * horrible the crap we have to deal with is when we are awake...
> >> */
> >> So, unless we can somehow ignore that comment, I suspect forcing the
> >> device to be disabled on driver remove, whether done from pci-core or
> >> from x86/pci, is going to cause all sorts of breakage. Are the
> >> expectations set by b4b55cda5874 really valid? It seems like something
> >> needs to be done to allow the IRQ to be automatically re-established on
> >> x86 regardless of the driver doing the right thing when releasing the
> >> device. We're still looking at a regression for v4.0 as a result of
> >> b4b55cda5874.
> > In which case we probably should revert commit b4b55cda5874 for the time being.
> > At least I'd be very nervous about any ad-hoc fixes at this stage of the cycle.
> The comment goes back to the dawn of "git" time ... not sure how much further
> Is this actually still an issue on modern systems? Maybe we need a black list
> or white list to separate the good from bad systems?
The answer to that is "We don't know" and in my not so humble opinion it is too
risky to try to find out at the end of the cycle.
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
next prev parent reply other threads:[~2015-03-12 0:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-05 21:06 Alex Williamson
2015-03-06 1:49 ` Jiang Liu
2015-03-06 3:51 ` Alex Williamson
2015-03-11 16:47 ` Alex Williamson
2015-03-11 22:04 ` Rafael J. Wysocki
2015-03-11 22:04 ` Luck, Tony
2015-03-12 1:17 ` Rafael J. Wysocki [this message]
2015-03-12 1:41 ` Jiang Liu
2015-03-12 16:08 ` Rafael J. Wysocki
2015-03-13 1:49 ` Jiang Liu
2015-03-13 2:06 ` [Bugfix] x86/PCI: Release PCI IRQ resource only if PCI device is disabled when unbinding Jiang Liu
2015-03-13 21:45 ` Rafael J. Wysocki
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH] x86/PCI: Fully disable devices before releasing IRQ resource' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).