Leo Weppelman wrote:
> Julians question basically boils down to:
>     How do I obtain the (opaque!) tags in the console probe when
>     the bus is not yet probed.

Ah, but I didn't put it that succinctly! :)

> Some design issues:
>   - I don't want to scatter 'opaque' bus knowledge in different parts
>     of the system. Basically, this knowledge belongs in
>     .../<bus>/<bus>_machdep.c.

Agreed.

>   - maximum reuse of code (ie. the et_probe_card() function performing
>     a kind of pci-bus scan is bogus).

Yes.   Because the ET4000 card routines are mixed with the PCI code, I
started to unglue the ET4000 configure and probe parts.

>   - quiet and simple ;-)

Well, if you haven't found the console yet, you can't be noisy!  Simple
would be good too.  (Then I can understand it first go ;-)

> I was thinking to define an 'early_<bus>_scan()' function. As an
> argument, it should get a probe function. The 'early_<bus>_scan'
> function calls the probe function with a '<bus>_attach_args' argument.

Yes, this looks nice.  I notice that other drivers have a ...match() and
a ...attach() routine.  Does it make sense to have match() and attach()
routines, rather than a probe() routine?  That way, the driver code could
be the same as those for the 'normal' bus scans.  For example, if I wanted
my VME card as console, I just define it in the kernel config, otherwise
I get a TT video console and the VME card found later (and grf attached).
One snag is that you have more parameters to worry about.

Anyway, I shall go back to separating the functionality.  With any luck,
I'll have time this weekend and be able to look at the X server too.

J

-- 
    1024/55A5BC19        0F 3F 62 56 18 10 8B 84  43 8F F4 94 93 37 76 AA

S.E.P.