cvs commit: src/sys/dev/bce if_bcereg.h

[Scott Long]

Bruce Evans wrote:
> On Tue, 25 Apr 2006, Scott Long wrote:
> 
>> Warner Losh wrote:
>>
>>> The problem is that PAE's bus_size_t is a 32-bit quantity, when it
>>> should be a 64-bit quantity:
>>>
>>> #ifdef PAE
>>> typedef uint64_t bus_addr_t;
>>> #else
>>> typedef uint32_t bus_addr_t;
>>> #endif
>>> typedef uint32_t bus_size_t;
> 
> 
> No, it should be a 32-bit quantity like it is.
> 
>> The next problem is that the boundary argument of bus_dma_tag_create()
>> is a bus_size_t.  For all PCI Express devices, you need to be able to
>> stick a value of 0x100000000 (2^32) in here, have busdma do the right
>> thing with it, and not have the compiler complain.  I'm torn between
>> declaring that the boundary is actually an address and thus should be
>> declared as a bus_addr_t, and declaring that bus_size_t should be
>> 64-bits on PAE just like it is on real 64-bit platforms.  The right
> 
> 
> I think the boundary is sometimes an address, so it needs to always
> have the type of an address.  It's never exactly a size.
> 
>> answer is probably to do both.  This means a core API change to busdma
>> and therefore to 90% of the hardware drivers in the tree, so it's not
>> easy to justify MFC'ing it.  It can be mostly worked around now anyways.
>>
>> Does this sound accurate and/or reasonable?
> 
> 
> Supporting sizes >= 4G sounds unreasonable.  How can a single device
> need or even address so much space, even on 64-bit arches?  For vm,
> virtual memory is sort of a device, but even it is limited to 4G on
> 32-bit arches, and PAE on i386 isn't pessimized by using a larger than
> necessary vm_size_t.
> 
> Bruce

Ok, fair enough.

Scott