svn commit: r235007 - stable/9/sys/dev/pci

[Warner Losh]

On May 7, 2012, at 9:27 AM, John Baldwin wrote:

> On Friday, May 04, 2012 5:25:32 pm Warner Losh wrote:
>> 
>> On May 4, 2012, at 1:41 PM, Hans Petter Selasky wrote:
>> 
>>> On Friday 04 May 2012 19:18:56 Warner Losh wrote:
>>>> On May 4, 2012, at 10:26 AM, Hans Petter Selasky wrote:
>>>>> On Friday 04 May 2012 18:14:16 John Baldwin wrote:
>>>>>> On Friday, May 04, 2012 11:38:47 am Hans Petter Selasky wrote:
>>>>>>> Author: hselasky
>>>>>>> Date: Fri May  4 15:38:47 2012
>>>>>>> New Revision: 235007
>>>>>>> URL: http://svn.freebsd.org/changeset/base/235007
>>>>>>> 
>>>>>>> Log:
>>>>>>> MFC r233662, r233677 and r233678:
>>>>>>> 
>>>>>>> Writing zero to BAR actually does not disable it and
>>>>>>> it is even harmful as hselasky found out.  Historically,
>>>>>>> this code was originated from (OLDCARD) CardBus driver and later
>>>>>>> leaked into PCI driver when CardBus was newbus'ified and refactored
>>>>>>> with PCI driver. However, it is not really necessary even for
>>>>>>> CardBus.
>>>>>> 
>>>>>> FYI, I've got one bug report on HEAD where these changes broke a
>>>>>> machine's ATA controller.
>>>>> 
>>>>> Have you considered adding code to disable the I/O or memory range
>>>>> instead of writing 0 to the bar in this case?
>>>> 
>>>> I tried that once upon a time, but was problematical with some bridges 
> that
>>>> had BARs at non-standard locations that needed the I/O or MEM bit set in
>>>> order to work...
>>>> 
>>>> Warner
>>> 
>>> If the size of the bar is a few megabytes, then moving it to location 0 is 
>>> definitely wrong. Else it might work!
>> 
>> Only if the bridge passes the transactions for that memory to the PCI bus 
> for decoding.  The reason it worked for as long as it did was that we had 
> bridges that passed the memory cycles to DRAM for addresses near 0 and they 
> didn't make it onto the PCI bus.  Except in embedded systems, I fail to see 
> how that could have changed in the interim.  The physical layout of x86 has 
> actual memory at location 0 and it would be a big performance hit to push 
> those transactions onto the pci bus, so nobody in their right mind would do 
> that.
> 
> Not true.  During NEW_PCIB testing I at one point fat-fingered something such
> that I had an memory window on a PCI-PCI bridge claim address 0 and the boot
> promptly hung as soon as that register was written.

I'll grant that for bridges...  The code in question just does devices though...  Still, something we should avoid...

Warner