[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE9FiQUeY-aocR=vwRUopuERJc0uUWKMwDafqLHo2baeVG7cKg@mail.gmail.com>
Date: Thu, 6 Aug 2015 16:32:30 -0700
From: Yinghai Lu <yinghai@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Subject: Re: [PATCH v3] PCI: Only enable IO window if supported
On Thu, Aug 6, 2015 at 9:18 AM, Guenter Roeck <linux@...ck-us.net> wrote:
> On 08/06/2015 08:58 AM, Yinghai Lu wrote:
> Ok, I admit that I am lost. Earlier it seemed that you were concerned about
> this case, where no io window is available or a bus doesn't support io,
> but a non-transparent child does. Now you seem to say that the
> non-transparent
> child would not be able to support IO either.
>
> For my education, can you list the possible options, and how you suggest
> to solve them ? I can see the following situations.
>
> - root supports IO, but has no io window assigned
> - root does not support IO and has or has not an IO window assigned
> - a bridge does not support IO
should have two cases:
1. root bus does not have io window exposed.
2. pci bridge io bar is not writable.
>
> For the transparent case, each of those should result in all children
> not even trying to assign an IO window, which is what we want,
> and what my patc set tries to do.
>
> How should those cases be handled for non-transparent bridges ?
for case 2: current upstream code, no warning for the bridge itself,
but have warning for devices under the bridge.
We only need to handle case 1, aka root bus does not have io port window.
What about your setup, is it case 1 or case 2?
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists