Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2157880ybz; Thu, 23 Apr 2020 12:37:34 -0700 (PDT) X-Google-Smtp-Source: APiQypKlcKVi57IgH5ZgIrHRThWOnRAfO6eKr4ar6PeoQZXxCf0Drhbv86PMVz6cXwzlfCEXOKI9 X-Received: by 2002:aa7:d5d5:: with SMTP id d21mr4346687eds.160.1587670653873; Thu, 23 Apr 2020 12:37:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587670653; cv=none; d=google.com; s=arc-20160816; b=dlV4r/VAnHS1PvxydFnas0YizrCH3dTDqvR1uDU7V772BtXGdz07cqnYr8tJflFUkN CES3r4BHFhrf8V0otY4LprS2p6axVYnBqQwJ1hnOG3Hx+CkLcD5SFIK4HOIZN1MCE3cD Lj7bZMiSZFhuhE6igF6shVNrVR2OScYuLkT/E45XKcFiF/G8QM2ciQOtL/FHa+xDSY4e Bpey78x/f0FDDeh1Hcqjun88OdOUmUEDAR7pC13KhdeJ8t+YEiOmi4gcDb+grAnUQfb5 gLV9KBJejrlbAc9Sl6wcQHOhN5linoe6unDnNqoQafwUNYF9wkiP98YpXXigKDl8L0db 5+lQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LscwPz73Lt0pgGTl+o/FebA5dRZodM4/3xJx4XGRFWs=; b=TCBlI4ERHWIBQdHQUC2D0SSCUGIS4mggxtoICh+e+yZYPxse2oXg1K4fhS90W8HmDk PjcI5GS1pTehLqMN/YL0SQCy68e5p8gYQMr7Ul1c6Cyk+SCQR879ds/jE5CN9UsGULN9 SMrqyoOQeGj1KOrwtc9PnQ1R0ZjjwhP2n9lWFmy8ivj+yKnhXtuYZ8jFIt0iqgqGc8G+ WJ85YvekQvefm2audwzDUbh16RuHUdyOYrBJNU17cid8w5qmp5WivwTUhzvcdlrVfC57 PpCSYrv2K+OzkEM7KEYokZTQUfSk5Vwqb2er1cyImj9gPQqN0wSHlHjXIm0iVulCjVWm OE7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b="ZgjkI/0h"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w20si1698672ejq.91.2020.04.23.12.37.09; Thu, 23 Apr 2020 12:37:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b="ZgjkI/0h"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730179AbgDWSWl (ORCPT + 99 others); Thu, 23 Apr 2020 14:22:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730074AbgDWSWl (ORCPT ); Thu, 23 Apr 2020 14:22:41 -0400 Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1A4BC09B043 for ; Thu, 23 Apr 2020 11:22:40 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id u10so5548668lfo.8 for ; Thu, 23 Apr 2020 11:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LscwPz73Lt0pgGTl+o/FebA5dRZodM4/3xJx4XGRFWs=; b=ZgjkI/0hqXjrYL+1zMORXDCbPO/cbFMR+PA+1RlleHhrFArqqZqVDrF2naxr2O/nZ8 8DcrKKqA2CocQV8SGpC3aPyDpPzeFJT3QtO/W+6TFqOD/cqopRZBQi+Y/GW8PBeaNBp0 IcU9neWFV5iGS7i3ZNxhsiHXnEpr7As01GU3A= 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; bh=LscwPz73Lt0pgGTl+o/FebA5dRZodM4/3xJx4XGRFWs=; b=B3ofI5oMszXS10Pv91LU/XJzq8yOrSUlYaxDGP/PK2YsQV9TBpaY62dSr1BJYifIOK 4jTWYAnxfH7nJC96fwLH7cf8a9f58AhTsc6kYtW3/jU4t7BWC98djXHT97BuG7t3pHmF +gVjUglUPRKxvIt2/lSDKZUEx3nAraxhu5RzMtD99ThMTayCv8aBMFDPpi94b2SiJUdX FPVCVAOdrZwANuPBGkZoq8F1HFLQJsSsqVJqiAXUoZPD4khr17ezPZ7jpdaY84ePzOj1 KJ128vXFKP6LzynmLB87tByveM/gpCK2riJOxAWFxTbsn4wDxlbLwPrJRNhaEXblJrx7 c48A== X-Gm-Message-State: AGi0PubljOz1HbiFg0AdUXv5rsS18rBtulWKKyAstFptOy9ZXacqM7Gu itv93Tpsu2i+mTV0Ib3e/kPNbhNchqM= X-Received: by 2002:ac2:4859:: with SMTP id 25mr3263545lfy.59.1587666157504; Thu, 23 Apr 2020 11:22:37 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id d3sm2821991lfq.63.2020.04.23.11.22.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Apr 2020 11:22:36 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id g10so5508080lfj.13 for ; Thu, 23 Apr 2020 11:22:36 -0700 (PDT) X-Received: by 2002:a19:9109:: with SMTP id t9mr3320601lfd.10.1587666155908; Thu, 23 Apr 2020 11:22:35 -0700 (PDT) MIME-Version: 1.0 References: <20200423173955.GA193359@google.com> In-Reply-To: <20200423173955.GA193359@google.com> From: Linus Torvalds Date: Thu, 23 Apr 2020 11:22:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] PCI fixes for v5.7 To: Bjorn Helgaas Cc: linux-pci@vger.kernel.org, Linux Kernel Mailing List , Lorenzo Pieralisi , Rob Herring , Andrew Murray , =?UTF-8?B?THXDrXMgTWVuZGVz?= , Todd Poynor Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 23, 2020 at 10:40 AM Bjorn Helgaas 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