From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 936ECC2BA2B for ; Thu, 9 Apr 2020 15:29:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 64E122083E for ; Thu, 9 Apr 2020 15:29:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FOLHuxAy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728241AbgDIP3h (ORCPT ); Thu, 9 Apr 2020 11:29:37 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:34482 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728176AbgDIP3h (ORCPT ); Thu, 9 Apr 2020 11:29:37 -0400 Received: by mail-ed1-f67.google.com with SMTP id x62so245829ede.1 for ; Thu, 09 Apr 2020 08:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CfiEPinAvMSeTaqZujjBwW71izU09MCDUP6YwiiDajE=; b=FOLHuxAyIWaAzX6DrtolUKtVbd6zixjyTa54I2/4h4ngbWbr0k8gsSK1n1u6bFJ9O+ qUstiAUPu5Rckpck8utssBIxB+VsR1U2g7odBOXg4lOC0f2rJ+FOZoPb2AJQYOGzjKVQ DygyBP3jX5Lf0tniAxHi1gzRcZxDsHZYDj0dUa06HMHKT61dQSkyhXu378Mxhjbh7QmS pPwGxF78TguMPb5PiA+3R9kF7QyCLAaf0mbSi0DAjp8egh/dAyjmLktHwzbOjHSaKWmP NXFXG4liUN3xZm65vUOlicOuBYy6wyH5woBZNUJKgZkQSdDJLC7fEXQir3xd/UtUh93r LaGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CfiEPinAvMSeTaqZujjBwW71izU09MCDUP6YwiiDajE=; b=Z6uMB4fVOgkVYzoBzmkI08b/0YcBPgtMwBSkbhuCuw9VjrXr2sIW6U8bhBQT1K00c2 eC1ae32KHUX6LYolzLLEZehmtlQZgVPGDqiPnyMJxiV4v3FNF0h9TiwSEfMg8sY5I9oR br4Hihof89BIKUfn40Pcm5mDZUlpLNquyAuE6M6sf1SvUVY2rVicZfTPsdMiT24P4k7B ndBYtSXi66tiy2r8qovgjnDSwcoTRvQfT4KuAJ6Hy3tN3FTnguGtSFjXufUiwiu1fmb0 ZuAYP6hr+doZsCloitTTWeSPY+TBdRe3vdTsI5XmMaoaObJuuJkcB7o2LqheHi0NrKGH OF5Q== X-Gm-Message-State: AGi0PuboBDeGXKwjjWAnlNV44cIapYx1Gb9dQbZhER+ZD/JUEOKRJpna dy1aNBgclciiPxdBnpWuxmZq8UXA9p0zYDVKoBM= X-Google-Smtp-Source: APiQypKZQ8dSuTONmzl6FfCEzrcrf3PpCgKKd/2TnBGRUgGb+ykQQY4gryBAny5NJdJ1/JeEX0Rj75yE2osJbKOcLaw= X-Received: by 2002:a17:906:d7a2:: with SMTP id pk2mr1276086ejb.272.1586446174750; Thu, 09 Apr 2020 08:29:34 -0700 (PDT) MIME-Version: 1.0 References: <20200404013233.GA30614@google.com> In-Reply-To: From: =?UTF-8?B?THXDrXMgTWVuZGVz?= Date: Thu, 9 Apr 2020 16:29:23 +0100 Message-ID: Subject: Re: Problem with PCIe enumeration of Google/Coral TPU Edge module on Linux To: Bjorn Helgaas Cc: Nicholas Johnson , Linux PCI , Thomas Petazzoni , Jason Cooper , Benjamin Herrenschmidt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Regarding my previous email please ignore the that device is being detected as Ethernet controller I have forced class change by making dev->class=3D=3D0x020000, which also works. Which is also another option for possible a solution... On Thu, Apr 9, 2020 at 4:25 PM Lu=C3=ADs Mendes w= rote: > > 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 0x= ff: > > static void __dev_sort_resources(struct pci_dev *dev, struct list_head *h= ead) > { > u16 class =3D dev->class >> 8; > > pci_info(dev, "%s\n", __func__); > /* Don't touch classless devices or host bridges or IOAPICs */ > if (class =3D=3D PCI_CLASS_NOT_DEFINED || class =3D=3D PCI_CLASS_BRID= GE_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 *h= ead) > { > u16 class =3D dev->class >> 8; > > pci_info(dev, "%s\n", __func__); > /* Don't touch classless devices or host bridges or IOAPICs */ > if ((class =3D=3D PCI_CLASS_NOT_DEFINED && !(dev->vendor =3D=3D 0x1a= c1 && > dev->device=3D=3D0x089a)) || class =3D=3D 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=3Dfast >TAbort- > SERR- Interrupt: pin A routed to IRQ 0 > Region 0: Memory at d0100000 (64-bit, prefetchable) [disabled] [size= =3D16K] > Region 2: Memory at d0000000 (64-bit, prefetchable) [disabled] [size= =3D1M] > Capabilities: > > > > Best regards. > Lu=C3=ADs Mendes > > On Thu, Apr 9, 2020 at 12:05 AM Lu=C3=ADs Mendes 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: