eeh@netbsd.org writes:
	> Matt Thomas requested this functionality.  As far as I can tell,
	> you can only traverse the tree from child to parent, and cannot
	> go down.

	At worst you can do so by traversing the alldevs after your device
	struct.

	I suggest that this be left off until the time it's known to be
	needed.  It doesn't change API at all, and it seems a shame to
	significantly expand the device struct before it's known to actually
	have a concrete use.

If you want to change properties on your child devices after
they have attached, it's easier if you can simply traverse the
device tree.  However, since you get that information at attach
time, you can store it somewhere.

Getting to your siblings is another issue, but I don't really 
see an immediate application for that.


	> 	These are logically two different sets of flags.  They should be
	> 	separated.
	> 
	> Well, they are being passed in in the same `flags' field in
	> dev_setprop() and dev_getprop() so it would be better if they
	> don't conflict with one another.

	I believe the point is, different sets of flags should _not_ be
	#defined in the same set, _or_ passed together, _or_ stored together
	in e.g. structures.

	Why would it ever make sense to reserve a bit for PROP_WAIT in a
	property structure, for instance?

PROP_WAIT does not make sense on a property structure.  So
you want to pass 3-4 different `flag' parameters to these calls?

	> 	The goal here is to completely remove 'aux' right?  Well, if you do
	> 	that, why should we have to go through and edit large numbers of
	> 	drivers in the tree when it's time to do that?
	> 
	> The goal is to remove `aux' eventually, but if you don't
	> provide it to the dev_config*() routines, a parent bus
	> cannot have both old-style children and children that
	> have been converted.  Maybe we need three sets of functions:
	> old, transitional, and new.

	Three sets of functions is basically what i've been suggesting pretty
	much all along, yes.

O.K.  This is going to make things more complicated....

	> 	> attach.  The `child' parameter is passed down to config_search(9) and
	> 	> config_attach(9).
	> 
	> 	This seems right enough, except you need to have some mechanism by
	> 	which properties are made read-only, and that should be used by
	> 	config_found_smd() and dev_config_found().
	> 
	> I don't think that is necessary.  If you really need the properties
	> to be read-only, create a dummy device node and copy them all there.

	config_found calls multiple match routines to match a single device.
	If a single buggy match routine modifies the properties, it can screw
	up all subsequent match routines.

	As far as I'm concerned, this _is_ necessary, if only for that
	purpose.


	> 	> Locator data are attached to the `child' as properties, and the
	> 	> `aux' parameter is placed in its device private data field.  It is then
	> 	> passed to the probe routine as the `aux' parameter.  The child driver should
	> 	> cast the `aux' parameter to a `struct device *' and use it to query for
	> 	> properties.  If it needs access to the aux data, use of `DEVICE_PRIVATE()'
	> 	> on it will return the `aux' provided by the parent.
	> 
	> 	No.  New-style drivers should never be able to get to aux.
	> 
	> This allows you to attach a new-stile driver to an old-style
	> bus.  Or isn't that desired functionality?  Do you really need
	> to convert a bus and all the drivers that can attach to it all
	> at the same time?  Even if some of those are in MD code scattered
	> across a dozen architectures?

	Go back and read the thing i've suggested you implement.

	In short form, to answer your questions in order:

	(1) new style drivers should _not_ be able to attach to busses which
	haven't at least been converted for old+new compatibility.

	(2) no, you only need to convert the bus to old+new compatibility,
	then you can convert invididual drivers as need be.

	(3) That's irrelevant, because if you do it right (or even the way i
	suggested 8-) you can get seamless compatibility with existing
	drivers.

Given that, and that more bus drivers tend to be MD than
device drivers, if one port converts its bus drivers and
starts on the MI device drivers for a type of bus, but 
another port with the same bus does not, those MI drivers
will cease to work on the second port.  Do you really think
this behavior will be considered acceptable?

Eduardo