> > > Could be, and I certainly don't know much about this code.  But
> > > it seems like the driver is being given reason to assume it has a
> > > working device when it doesn't really have one.  I assume the device
> > > is unusable without its interrupt, so shouldn't it fail at probe or
> > > attach time?
> >
> > Yes, it should.  It's not bright enough to do that yet.
> 'It' in the second case refers to the PCI irq allocation code I presume?

No, the UHCI driver. It makes a number of assumptions about the state of 
the controller, and fails (messily) when these aren't met.

> An irq that is 0 or 255 is invalid and should not be allocated to a PCI
> device. But speaking about rev1.32, how would you assign an interrupt as
> is stated in the log message for rev1.32?

That's platform-specific; in the PC case, we ask the BIOS for interrupt 
routing information.  On the Alpha, we know what the interrupt routing 
strategy is ourselves.

The bottom line is this; in your driver, ask for the resources that you 
need.  If you don't get them, you fail.  The PCI bus infrastructure is 
being worked on to improve your chances of getting these resources; it's 
not something that a driver writer should be worrying about per se.

... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to