Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 31 Mar 2022 08:11:19 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@orcam.me.uk>
To:     Bjorn Helgaas <helgaas@kernel.org>
cc:     Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PING^3][PATCH v2] PCI: Sanitise firmware BAR assignments behind a
 PCI-PCI bridge
In-Reply-To: <alpine.DEB.2.21.2203012338460.46819@angie.orcam.me.uk>
Message-ID: <alpine.DEB.2.21.2203310031210.44113@angie.orcam.me.uk>
References: <20220301231547.GA663097@bhelgaas> <alpine.DEB.2.21.2203012338460.46819@angie.orcam.me.uk>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Wed, 2 Mar 2022, Maciej W. Rozycki wrote:

> > > Fix an issue with the Tyan Tomcat IV S1564D system, the BIOS of which 
> > > does not assign PCI buses beyond #2, where our resource reallocation 
> > > code preserves the reset default of an I/O BAR assignment outside its 
> > > upstream PCI-to-PCI bridge's I/O forwarding range for device 06:08.0 in 
> > > this log:
> > 
> > Would you mind collecting the complete dmesg log before your patch?
> > It's hard to get the entire picture from snippets.
> 
>  Sure, here's the original log from at the time when I made the patch.  I 
> think it's as verbose as you can get; there's no way I could have used it 
> for the change description.
> 
>  Also I doubt it should matter, but if you need a fresh log instead from 
> 5.17, then I can make one too, but that will take a bit.  Let me know if 
> you need me to try anything else too.

 Ping for:
<https://lore.kernel.org/all/alpine.DEB.2.21.2202010150100.58572@angie.orcam.me.uk/>

Do you need any further information?

  Maciej