svn commit: r198431 - head/sys/dev/pci
Nathan Whitehorn
nwhitehorn at freebsd.org
Mon Oct 26 17:45:41 UTC 2009
John Baldwin wrote:
> On Monday 26 October 2009 12:32:48 pm Marcel Moolenaar wrote:
>
>> On Oct 26, 2009, at 5:37 AM, John Baldwin wrote:
>>
>>
>>>> Log:
>>>> BIOSes, buggy or otherwise, are i386 or amd64 specific.
>>>> Have the early USB takeover enabled for i386 and amd64
>>>> by default.
>>>> This also avoids a panic on PowerPC where the resource
>>>> isn't released properly and we find a busy resource
>>>> when the USB host controller wants to allocate it...
>>>>
>>
>>> Presumably such systems won't set the 'BIOS owned' bit in the their
>>> legacy
>>> support registers in which case these routines are NOPs (they just
>>> read the
>>> register, see the bit is clear, and exit). The resource bug sounds
>>> like a
>>> real one that should be fixed and would probably affect any x86
>>> systems who
>>> have USB disabled in the BIOS, so that should be fixed rather than
>>> papered
>>> over. Please revert.
>>>
>> *sigh*
>>
>> The change was made because 1) doing this as part of the PCI code is
>> unnecessary for non-PC HW, and 2) it's entirely untested on non-PC
>> HW and the gratuitous change can therefore only do harm -- he, guess
>> what, it did do harm.
>>
>> Unless people fix the resource stuff this change cannot be reverted.
>>
>> After the resource fix has gone in, I still object to this being
>> reverted on grounds of gratuitous code bloat. I say this with ARM,
>> MIPS and PowerPC/Book-E in mind.
>>
>
> You didn't remove anything, you merely toggled the setting of a variable.
> Code bloat is a non-argument in that case. Could you care to provide details
> on the resource issue you are encountering? I don't see any obvious resource
> leaks, etc. in the current set of changes.
>
>
The real problem in this case is that the
bus_(deactivate|release)_resource methods are not implemented on several
PCI bus drivers on PowerPC (e.g. uninorth, where this problem arose). Up
until now, I guess it has never mattered.
-Nathan
More information about the svn-src-head
mailing list