Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190214170028.27862-1-logang@deltatee.com> <20190304002351.GA26569@google.com>
 <3e45b4ab-e848-cf3b-624f-121ad58b0250@deltatee.com> <CAErSpo4U6Kys5OzPwfyFdbnJWfTZ-y0P830okf11BwfNv9Y82A@mail.gmail.com>
 <ac64ba0e-e86a-f7ae-775b-753f933f178f@deltatee.com>
In-Reply-To: <ac64ba0e-e86a-f7ae-775b-753f933f178f@deltatee.com>
From:   Bjorn Helgaas <bhelgaas@google.com>
Date:   Mon, 4 Mar 2019 14:29:22 -0600
Message-ID: <CAErSpo5icDM2VgYoLdEp8C-CV5XEMThABMA8RBq64grhRSkRWA@mail.gmail.com>
Subject: Re: [PATCH 1/2] PCI: Prevent 64-bit resources from being counted in
 32-bit bridge region
To:     Logan Gunthorpe <logang@deltatee.com>
Cc:     Bjorn Helgaas <helgaas@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux PCI <linux-pci@vger.kernel.org>,
        Kit Chow <kchow@gigaio.com>, Yinghai Lu <yinghai@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 4, 2019 at 2:21 PM Logan Gunthorpe <logang@deltatee.com> wrote:
> On 2019-03-04 1:11 p.m., Bjorn Helgaas wrote:
> > On Mon, Mar 4, 2019 at 1:21 PM Logan Gunthorpe <logang@deltatee.com> wrote:
> >> On 2019-03-03 5:23 p.m., Bjorn Helgaas wrote:
> >>> Sorry for the delay.  This code gives a headache.  I still remember
> >>> my headache from the last time we touched it.  Help me understand
> >>> what's going on here.
> >>
> >> Yes, this code gave me a headache debugging it too. And it's not the
> >> first time I've tried to figure out what's going on with it because it
> >> often just prints noisy messages that look like errors. I think I
> >> understand it better now but it's something that's a bit fleeting and
> >> easy to forget the details of. There may also be other solutions to this
> >> problem.
> >
> > Thanks for the explanation below.  I haven't worked through it yet, but I will.
> >
> > Obviously it would be far better than an explanation if we could
> > simplify the code (and the noisy messages) such that it didn't
> > *require* so much explanation.
>
> I agree, but reworking this code scares me and I suspect it was designed
> this way for a reason. I'm guessing there are a lot of corner cases and
> unusual bios issues this stuff works around. We might end up fixing a
> some cases and breaking a bunch of other cases.

Scares me too, which is one reason I haven't done anything about it.

I didn't mean to suggest that you should rework it for *this* issue.
I just keep hoping that we can chip away at teensy pieces and in ten
or twenty years maybe make some headway.

Bjorn