linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luís Mendes" <luis.p.mendes@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>,
	Linux PCI <linux-pci@vger.kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Jason Cooper <jason@lakedaemon.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: Problem with PCIe enumeration of Google/Coral TPU Edge module on Linux
Date: Thu, 9 Apr 2020 16:25:40 +0100	[thread overview]
Message-ID: <CAEzXK1oCwx=w3S0ednwM2mJEEidqF3saEKu9OQP=i82y3Az0Aw@mail.gmail.com> (raw)
In-Reply-To: <CAEzXK1oU4KwatuXAjUwj5arZtdmDSgFsm2vn8DrAWCJu-v-r0g@mail.gmail.com>

Hi Bjorn,

I've good news. I've found the culprit and it is a pretty simple
issue, however the good solution is not obvious to me.
Can you help in finding the best way to patch this issue?

So first detailing the problem in file setup_bus.c there is this *if
condition* to ignore resources from classless devices and so
it is that this Google/Coral Edge TPU is a classless device with class 0xff:

static void __dev_sort_resources(struct pci_dev *dev, struct list_head *head)
{
    u16 class = dev->class >> 8;

       pci_info(dev, "%s\n", __func__);
    /* Don't touch classless devices or host bridges or IOAPICs */
    if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST)
        return;
   ....

So the one possible trivial, non generic, attempt that works is to do:
static void __dev_sort_resources(struct pci_dev *dev, struct list_head *head)
{
    u16 class = dev->class >> 8;

       pci_info(dev, "%s\n", __func__);
    /* Don't touch classless devices or host bridges or IOAPICs */
    if ((class == PCI_CLASS_NOT_DEFINED &&  !(dev->vendor == 0x1ac1 &&
dev->device==0x089a)) || class == PCI_CLASS_BRIDGE_HOST)
        return;
   ....

What is your suggestion to make the solution generic? Create a
whitelist? Remove this verification? I have no idea... nothing sounds
good to me...
01:00.0 Ethernet controller: Device 1ac1:089a (prog-if ff)
    Subsystem: Device 1ac1:089a
    Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
    Interrupt: pin A routed to IRQ 0
    Region 0: Memory at d0100000 (64-bit, prefetchable) [disabled] [size=16K]
    Region 2: Memory at d0000000 (64-bit, prefetchable) [disabled] [size=1M]
    Capabilities: <access denied>



Best regards.
Luís Mendes

On Thu, Apr 9, 2020 at 12:05 AM Luís Mendes <luis.p.mendes@gmail.com> wrote:
>
> Hi Bjorn,
>
> I have successfully setup a JTAG remote debug environment.
> And I found this:
> First call to __pci_bus_assign_resources visits 11ab:6828 -> SLOT 1,
> which in turn calls __pci_bus_assign_resources which visits device
> 1ac1:089a on that slot and calls:

  reply	other threads:[~2020-04-09 15:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-06 14:32 Problem with PCIe enumeration of Google/Coral TPU Edge module on Linux Luís Mendes
2020-03-06 21:47 ` Bjorn Helgaas
2020-03-07 12:11   ` Luís Mendes
2020-03-07 15:26     ` Luís Mendes
2020-03-07 21:38       ` Bjorn Helgaas
2020-03-08  5:51         ` Nicholas Johnson
2020-03-09 11:21           ` Luís Mendes
2020-03-11 14:20             ` Luís Mendes
2020-03-29 22:11               ` Luís Mendes
2020-03-30 19:49                 ` Bjorn Helgaas
2020-03-31 21:28                   ` Luís Mendes
2020-04-01 18:16                     ` Bjorn Helgaas
2020-04-01 21:20                       ` Luís Mendes
2020-04-01 21:55                         ` Luís Mendes
2020-04-01 23:31                         ` Bjorn Helgaas
2020-04-02 14:13                           ` Luís Mendes
2020-04-04  1:32                             ` Bjorn Helgaas
2020-04-04 21:39                               ` Luís Mendes
2020-04-08 23:05                                 ` Luís Mendes
2020-04-09 15:25                                   ` Luís Mendes [this message]
2020-04-09 15:29                                     ` Luís Mendes
2020-04-09 16:30                                     ` Bjorn Helgaas
2020-04-09 17:32                                       ` Luís Mendes
2020-04-09 18:08                                       ` Bjorn Helgaas
2020-04-09 20:07                                         ` Luís Mendes

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='CAEzXK1oCwx=w3S0ednwM2mJEEidqF3saEKu9OQP=i82y3Az0Aw@mail.gmail.com' \
    --to=luis.p.mendes@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=helgaas@kernel.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-pci@vger.kernel.org \
    --cc=nicholas.johnson-opensource@outlook.com.au \
    --cc=thomas.petazzoni@bootlin.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).