I've been putting together pieces of the DH{UVQ}-11 driver, but I keep
getting a T_PTELEN trap (no vmspace in fault) whenever the driver is 
configured in the kernel.  It happens after the match routine has returned,
just after cpu0 at backplane0 is reported on the console.  Even if I #ifdef 
out all of the code in the match routine, and always return 0, I still
get the same trap.

The 4.4 auto-configuration is making me a little nuts.  :-)  I think the 
crux of the problem is that I'm not entirely certain how to structure the 
driver for auto-configuration.  Right now, it looks like this:

  struct dhu_softc {
    struct device dhu_device;
    .
    .
    .
  };

  int dhumatch __P((struct device *, void *, void *));
  void dhuattach __P((struct device *, struct device *, void *));
  
  struct cfdriver dhucd = {
    NULL, "dhu", dhumatch, dhuattach, DV_DULL, sizeof(struct dhu_softc)
  };

(very much like the DELQA driver).  However, some of the other uba drivers
are configured with both a struct cfdriver and a struct uba_driver -- is that
what I want?  In 4.3, I would have setup for autoconfiguration with something 
like
  
  struct uba_driver dhudriver = {
    dhuprobe, NULL, dhuattach, NULL, dhustd, "dhu", dhuinfo
  };
   
with dhuprobe doing very much the same thing that dhumatch is doing now
(force the device to interrupt, and see where the interrupt came from).

Also, I'm not exactly certain about the analogs for cvec and br in the
4.4 kernel -- how/where do I get that same functionality?

Any all advice/comments appreciated.

--Carl