svn commit: r198431 - head/sys/dev/pci

[John Baldwin]

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.

> > Note that the legacy support register stuff is part of the uhci/ohci/ 
> > ehci
> > specifications, and that the code to frob it has been part of the same
> > drivers since their inception.  If it had been an actual problem  
> > then it
> > would have been disabled back when USB was enabled for other  
> > architectures.
> 
> This is entirely besides the point...

It is not beside the point because the code was not just added, it is being 
moved.  Presumably the code will be removed from the host controller drivers 
shortly since it is no longer needed.  I repeat that if the code caused real 
problems it would not be present in the actual host controller drivers.

-- 
John Baldwin