From: Linus Torvalds <torvalds@linux-foundation.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Rob Herring" <robh@kernel.org>,
"Andrew Murray" <amurray@thegoodpenguin.co.uk>,
"Luís Mendes" <luis.p.mendes@gmail.com>,
"Todd Poynor" <toddpoynor@google.com>
Subject: Re: [GIT PULL] PCI fixes for v5.7
Date: Thu, 23 Apr 2020 11:22:20 -0700 [thread overview]
Message-ID: <CAHk-=wj7f3HJxmhP_SKQoFwuSx-OQgvp41pbgJN7TtspQj=RUA@mail.gmail.com> (raw)
In-Reply-To: <20200423173955.GA193359@google.com>
On Thu, Apr 23, 2020 at 10:40 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> - Workaround Apex TPU class code issue that prevents resource
> assignment (Bjorn Helgaas)
Hmm.
I have no objections to that patch, but I do wonder if it might not be
better to try to actually assign the resource at enable_resource time?
Put another way: if I read the situation correctly, what happened is
that the hardware is broken and doesn't have the proper class code,
and so the resource is not initially assigned at all. But then the
driver matches on the device ID, and tries to use the device, and then
we get into trouble at pci_enable_resources().
But is there any reason we don't just at least try to do
pci_assign_resource() at that point? Yeah, because we didn't do it at
bus scanning, maybe there's no room for it, but that's what we do for
the PCI ROM resources (which I think we also don't claim by default)
when drivers ask to map them.
The pci/rom.c code does
/* assign the ROM an address if it doesn't have one */
if (res->parent == NULL && pci_assign_resource(pdev, PCI_ROM_RESOURCE))
return NULL;
could we perhaps do the same in enable_resource?
Your patch is obviously much better for an -rc kernel, so this is more
of a longer-term "wouldn't it be less fragile to ..." query.
Alternatively, maybe we should do resource assignment even for
PCI_CLASS_NOT_DEFINED?
Linus
next prev parent reply other threads:[~2020-04-23 18:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 17:39 [GIT PULL] PCI fixes for v5.7 Bjorn Helgaas
2020-04-23 18:22 ` Linus Torvalds [this message]
2020-04-24 3:23 ` Bjorn Helgaas
2020-04-24 3:55 ` Bjorn Helgaas
2020-04-24 17:21 ` Luís Mendes
2020-04-23 20:50 ` pr-tracker-bot
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='CAHk-=wj7f3HJxmhP_SKQoFwuSx-OQgvp41pbgJN7TtspQj=RUA@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=amurray@thegoodpenguin.co.uk \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=luis.p.mendes@gmail.com \
--cc=robh@kernel.org \
--cc=toddpoynor@google.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).