Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Jan 2009 10:41:37 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        nwhitehorn@freebsd.org, freebsd-arch@freebsd.org
Subject:   Re: Enumerable I2C busses
Message-ID:  <200901221041.38286.jhb@freebsd.org>
In-Reply-To: <20090121.162950.1552132922.imp@bsdimp.com>
References:  <200901211110.33961.jhb@freebsd.org> <200901211542.08461.jhb@freebsd.org> <20090121.162950.1552132922.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 21 January 2009 6:29:50 pm M. Warner Losh wrote:
> In message: <200901211542.08461.jhb@freebsd.org>
>             John Baldwin <jhb@FreeBSD.org> writes:
> : On Wednesday 21 January 2009 3:28:05 pm M. Warner Losh wrote:
> : > Right now, the only bug that I know about with the cardbus vs pci
> : > thing is that kldload doesn't necessarily probe/attach pci drivers on
> : > a cardbus bus.  Otherwise, it works perfectly.  This is the only
> : > reason that we have driver lines with cardbus attachments in the pci
> : > drivers at all...
> : 
> : That is the bug though. :)  I've looked at it and I think I know how to 
fix 
> : it, I just haven't gotten around to it.  I think device_probe_and_attach() 
> : needs to actually walk up the inheritance list of the current 'bus' 
driver, 
> : but only if all of the drivers for the current 'bus' failed to probe (or 
> : there are no drivers).
> 
> But why then does it work with the normal probe and only fail on the
> load?

I think it has to do with the fact that we attempt to store parents of 
devclasses and walk that tree, when instead we should probably walk the 
inheritance tree of the parent device's driver instead.

That is, instead of doing this:

	for (; dc; dc = dc->parent) {
	}

It should be something more like this:

	driver_t parent_driver;

	parent_driver = device_get_driver(bus);
	for (dc = driver_first_devclass(parent_driver); dc;
	    dc = driver_next_devclass(parent_driver, dc)) {
	}

driver_first_devclass() would be the devclass of the parent driver, and 
driver_next_devclass() (which may be all we really need) would have to 
iterate over the parent superclasses of 'parent_driver'.  It might be a bit 
tricky to do anything more than a very simple first-pass of depth-first 
though for the traversal.  Doing a full superclass traversal in a sane order 
(since kobj supports multiple inheritance) might prove very problematic.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901221041.38286.jhb>