All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: "Sean O. Stalley" <sean.stalley@intel.com>
Cc: "David Daney" <ddaney.cavm@gmail.com>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Rafał Miłecki" <zajec5@gmail.com>,
	linux-api@vger.kernel.org, yinghai@kernel.org,
	rajatxjain@gmail.com, gong.chen@linux.intel.com,
	"David Daney" <david.daney@cavium.com>
Subject: Re: [PATCH v3 2/2] PCI: Add support for Enhanced Allocation devices
Date: Wed, 30 Sep 2015 16:01:19 -0700	[thread overview]
Message-ID: <560C69BF.6000205@caviumnetworks.com> (raw)
In-Reply-To: <20150930225011.GA4244@sean.stalley.intel.com>

On 09/30/2015 03:50 PM, Sean O. Stalley wrote:
> On Tue, Sep 29, 2015 at 04:53:20PM -0700, David Daney wrote:
>> On 09/29/2015 03:47 PM, Sean O. Stalley wrote:
>> [...]
>>>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>>>> index 6a9a111..7c60b16 100644
>>>>>> --- a/drivers/pci/pci.c
>>>>>> +++ b/drivers/pci/pci.c
>>>>>> @@ -2148,6 +2148,284 @@ void pci_pm_init(struct pci_dev *dev)
>>>>>>   	}
>>>>>>   }
>>>>>>
>>>>>> +static unsigned long pci_ea_set_flags(struct pci_dev *dev, u8 prop)
>>>>>> +{
>>>>>> +	unsigned long flags = IORESOURCE_PCI_FIXED | IORESOURCE_SIZEALIGN;
>>>>>
>>>>> Why did you add the IORESOURCE_SIZEALIGN flag? EA allows for unaligned resources.
>>>>
>>>> pci_bus_assign_resources() fails causing the devices to be unusable
>>>> if resource_alignment() returns zero.  The easiest fix for this was
>>>> to specify IORESOURCE_SIZEALIGN.
>>>>
>>>> An alternative would be to change the code in setup-bus.c so that
>>>> for IORESOURCE_PCI_FIXED resources, it didn't barf.
>>>
>>> I would do this alternative, but with a IORESOURCE_PCI_EA flag.
>>>
>>
>> I don't think we need IORESOURCE_PCI_EA.  If a resource is tagged as
>> IORESOURCE_PCI_FIXED that means that it cannot be changed, we
>> shouldn't care why it is fixed (due to an EA capability for
>> example).  We just need to gracefully handle IORESOURCE_PCI_FIXED in
>> the places where things currently go wrong.
>>
>> David Daney
>>
>
> I agree that we need to make sure fixed things stay fixed,
> regardless of if they are fixed by EA or something else.
>
> The question is: do we want to allow all fixed resources to be non-aligned, or just EA?

The alignment should only be important if a new address is being 
calculated for a BAR or behind the bridge memory/io region.  If the 
resource is fixed, I would almost say that "alignment" is an undefined 
concept.  So, in the places were we need special treatment for 
IORESOURCE_PCI_FIXED, I would argue that we shouldn't be use the 
resource alignment information.

David Daney

>
> -Sean
>

      reply	other threads:[~2015-09-30 23:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-29  0:10 [PATCH v3 0/2] PCI: Add support for PCI Enhanced Allocation "BARs" David Daney
2015-09-29  0:10 ` David Daney
2015-09-29  0:10 ` [PATCH v3 1/2] PCI: Add Enhanced Allocation register entries David Daney
2015-09-29  0:10 ` [PATCH v3 2/2] PCI: Add support for Enhanced Allocation devices David Daney
2015-09-29 19:27   ` Sean O. Stalley
     [not found]     ` <20150929192737.GA2517-KQ5zpJUXklQTH34CoL1+91DQ4js95KgL@public.gmane.org>
2015-09-29 20:25       ` David Daney
2015-09-29 20:25         ` David Daney
     [not found]         ` <560AF3D7.80908-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-09-29 22:47           ` Sean O. Stalley
2015-09-29 22:47             ` Sean O. Stalley
2015-09-29 23:53             ` David Daney
     [not found]               ` <560B2470.9080100-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2015-09-30 22:50                 ` Sean O. Stalley
2015-09-30 22:50                   ` Sean O. Stalley
2015-09-30 23:01                   ` David Daney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=560C69BF.6000205@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=bhelgaas@google.com \
    --cc=david.daney@cavium.com \
    --cc=ddaney.cavm@gmail.com \
    --cc=gong.chen@linux.intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=rajatxjain@gmail.com \
    --cc=sean.stalley@intel.com \
    --cc=yinghai@kernel.org \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.