x86 pci: Add option to not assign BAR's if not already assigned
in [Kernel]
|
Prev: x86 pci: Add option to not assign BAR's if not already assigned
Next: pci: check caps from sysfs file open to read device dependent config space
From: H. Peter Anvin on 28 May 2010 16:10 On 05/28/2010 10:10 AM, Mike Travis wrote: > > > H. Peter Anvin wrote: >> On 05/28/2010 09:53 AM, Mike Travis wrote: >>> Any further consideration for this patch, or has it been rejected? >> >> Well, it's really up to Jesse, but as far as I can see, this patch is a >> net loss of functionality and doesn't actually add anything. Without >> this patch, some resources that were not assigned by BIOS will be >> unreachable. With this patch, *all* resources that were not assigned by >> BIOS will be unreachable... >> >> -hpa >> > > Apparently you're missing the point of the patch? The patch is needed > because BIOS is purposely not assigning I/O BAR's to devices that won't > use them, freeing up the resource for devices that do need them. Where > is the "all" resources that are not reachable? > No, the patch isn't needed for those. Without your patch: - Devices assigned by BIOS remain assigned; - Devices not assigned by BIOS get assigned until address space exhausted. With your patch: - Devices assigned by BIOS remain assigned; - Devices not assigned by BIOS never get assigned at all. What am I missing here? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Travis on 31 May 2010 07:20 H. Peter Anvin wrote: > On 05/28/2010 10:10 AM, Mike Travis wrote: >> >> H. Peter Anvin wrote: >>> On 05/28/2010 09:53 AM, Mike Travis wrote: >>>> Any further consideration for this patch, or has it been rejected? >>> Well, it's really up to Jesse, but as far as I can see, this patch is a >>> net loss of functionality and doesn't actually add anything. Without >>> this patch, some resources that were not assigned by BIOS will be >>> unreachable. With this patch, *all* resources that were not assigned by >>> BIOS will be unreachable... >>> >>> -hpa >>> >> Apparently you're missing the point of the patch? The patch is needed >> because BIOS is purposely not assigning I/O BAR's to devices that won't >> use them, freeing up the resource for devices that do need them. Where >> is the "all" resources that are not reachable? >> > > No, the patch isn't needed for those. > > Without your patch: > > - Devices assigned by BIOS remain assigned; > - Devices not assigned by BIOS get assigned until address space > exhausted. > > With your patch: > > - Devices assigned by BIOS remain assigned; > - Devices not assigned by BIOS never get assigned at all. > > What am I missing here? > > -hpa > BIOS still assigns the MMIO BAR's so the devices are alive. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 31 May 2010 12:40 On 05/31/2010 04:12 AM, Mike Travis wrote: > > BIOS still assigns the MMIO BAR's so the devices are alive. OK, so it sounds like the *real* problem is our behavior on address space exhaustion: it is rather common that a driver will only use one BAR/address space, and sometimes can even choose which address space to use. The right thing would be to defer error until a particular BAR is requested by the device driver, but I'm not sure if our interfaces permits that (and I'm on my way to the airport right now so I can't check...) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 2 Jun 2010 03:40 On 06/01/2010 03:49 PM, Bjorn Helgaas wrote: >> >> BIOS still assigns the MMIO BAR's so the devices are alive. > > I'm sorry; I don't follow this. BIOS assigns MMIO BARs regardless > of whether we have your patch. > I'm assuming that that Mike is implying is that the allocation code runs out of I/O space and as a result shuts down the entire device. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 2 Jun 2010 11:50
On 06/02/2010 05:45 PM, Bjorn Helgaas wrote: > On Wednesday, June 02, 2010 01:31:18 am H. Peter Anvin wrote: >> On 06/01/2010 03:49 PM, Bjorn Helgaas wrote: >>>> >>>> BIOS still assigns the MMIO BAR's so the devices are alive. >>> >>> I'm sorry; I don't follow this. BIOS assigns MMIO BARs regardless >>> of whether we have your patch. >> >> I'm assuming that that Mike is implying is that the allocation code runs >> out of I/O space and as a result shuts down the entire device. > > Yeah, that's why I asked about a deeper problem. There's not really a > "shut down this device" flag, so the only way I can think of that we > might make a device completely unusable is if we release all the device > resources and then fail to reassign them. > > A concrete example, e.g., a dmesg log, would go a long ways toward > clarifying this. > That's what I thought, which I guess means my original question to Mike still stands... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |