> On Tue, 17 Jun 1997, Martin Husemann wrote:
> 
> > Now my questions are: would you do the double probe/attach stuffe the
> > way I outlined it or would you belive a far less restrictive probe verifying
> > only the presence of the shared memory and some defined values which should
> > be there after reset, leaving all download stuff to the attach routine?
> 
> It would be better for for a non-invasive match (aka `probe') function to
> simply verify the existence of the card.  Remember that a card that is
> matched may not be attached, necessarily.

Right.  However, "what does it take to verify the existence of the
card?"

Simply having a memory in the right place and a couple of values being
set as their reset values may not be good enough, especially if
there's no 'signature' value.

It may be necessary to do a more complex probe to make sure that the
card is actually there.  You do _not_ want to err on the side of
inclusion; if the card is not there, you never want to match it
accidentally.

There's also the question of whether or not the driver will work, even
given the result of the simple probe.  For instance, a firmware or
hardware change which can be discovered only by the more invasive
probe may mean that the driver has no chance of working with the
board.  Or, it could be that somebody else has designed a board which
is programmed differently, but has a similar download interface, which
isn't and shouldn't be supported by the driver.

I'd say:

	(1) verify that things look as if the board is there, then

	(2) do the more invasive probe, to make _sure_ they're there.

Of course, you still have to redo any initialization at 'attach' time.


> If there is common code to nail down the location of the shared memory in
> I/O or memory space, put that into a separate function and use that in
> both the match and attach functions.

The same with code to do any more invasive probe.



chris