On 23/04/07, Michael Lorenz <macallan@netbsd.org> wrote:
> Hi Joachim,
> [...]
> To make it usable anyway we'd have to enable it by hand, write some
> safe values into its BARs and figure out which interrupt to use.
> Finding he interrupt shouldn't be a problem - the bridge's
> interrupt-map should tell us, the code is already there. The rest is
> easy enough to do, I can write you such a patch if you want.
> [...]
> The problem with this - it's a gross hack that won't go into the
> official source tree. If you add new cards you may need to pick new
> addresses for the puc since OF - being unaware of this hack - may
> assign the ranges you picked to said new card and then things would
> blow up.

Hi Michael,
your efforts are greatly appreciated: gross hack or properly
engineered implementation, I'll take it :-)  I guess I'd just have to
be careful once I migrate to 4.0...

All things considered though, I guess in the future it may be useful
to have a mechanism for handling similar situations for macppc (and
possibly other OF PCI based architectures? sparc, for example?)
Perhaps one could set aside an address range (early during
initialisation) into which unconfigured cards get placed once NetBSD
detects a card for which it has a driver, but that has not been
enabled by OF.

BTW, I've dealt with Lava Computing's tech support before, they seem
pretty good.  I think that if this is a case where it's really them
that are messing up in some corner case of the PCI spec, they'd be
willing to at least file it as a bug to fix for future cards.  I'd
happily file a bug report once I figure out what I would need to tell
them :-)

Joe.