ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works

[Bruce Evans]

On Wed, 16 Jan 2013, Andre Albsmeier wrote:

> On Tue, 15-Jan-2013 at 21:27:07 +0100, John Baldwin wrote:
>> On Tuesday, January 15, 2013 10:44:33 am Andre Albsmeier wrote:
>>* ...
>>> I have no idea if this has ever worked before -- in FreeBSD-7 I
>>> also had to use the "do not use interrupt"-flag 0x20 in loader.conf
>>> or ppc wouldn't have attached...
>>>
>>> Which brings me back to the initial problem: Hints like
>>>
>>> hint.ppc.0.at=puc0
>>> hint.ppc.0.irq=""
>>> hint.ppc.0.flags=0x2F
>>>
>>> seems to be ignored in 9.1. While the interrupt thing seems
>>> to be fixed now, one possibly still wants to used the other
>>> flags. I have helped myself with this (ugly) patch to ppc
>>>
>>> --- ppc.c.ORI 2013-01-12 18:07:44.000000000 +0100
>>> +++ ppc.c       2013-01-12 18:07:24.000000000 +0100
>>> @@ -1729,6 +1729,11 @@
>>>         ppc->ppc_base = rman_get_start(ppc->res_ioport);
>>>
>>>         ppc->ppc_flags = device_get_flags(dev);
>>> +  if( ppc->ppc_flags == 0 ) {
>>> +    int tmp;
>>> +    if( resource_int_value( "ppc" , device_get_unit( dev ), "flags", &tmp)
>> == 0 )
>>> +      ppc->ppc_flags = tmp;
>>> +  }
>>>
>>>         if (!(ppc->ppc_flags & 0x20)) {
>>>                 ppc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ,
>>>
>>> in order to get at least the flags applied as it was the case
>>> before in FreeBSD-7. Unfortuantely, I have no idea how to fix
>>> that properly ;-(...
>>
>> This should not be needed for "flags".  Look for 'devflags' in
>> sys/kern/subr_bus.c.  The kernel always reads the current 'flags' hint during
>> device probe and stores them in dev->devflags and leaves them there after a
>> successful probe (so they should be seen by attach).  Specifically, note:
>>
>> 		/* Set the winning driver, devclass, and flags. */

So the flags interface is unusable before some driver "wins".

>> 		if (!child->devclass) {
>> 			result = device_set_devclass(child, best->driver->name);
>> 			if (result != 0)
>> 				return (result);
>> 		}
>> 		result = device_set_driver(child, best->driver);
>> 		if (result != 0)
>> 			return (result);
>> 		resource_int_value(best->driver->name, child->unit,
>> 		    "flags", &child->devflags);
>>
>> This 'devflags' variable is what device_get_flags() returns.  You should be
>> able to just place 'hint.ppc.0.flags=0x2f' in /boot/device.hints (note, no
>> other hints meaning no "at", etc.)
>
> Hmm, you are right. It now works even without my hackish patch.
>
> Apparently, the "flags" hints (indicating that no interrupt
> should be used) were not observed when I tried to use them to
> work around the bug (which you fixed now). But after a
> successful attach they are used and this is what's really
> important.

This leaves the layering/ordering bug that device flags are unusable
at probe time.  But ppc.c only initializes them in ppc_probe().  It
assigns them to ppc->ppc_flags and apparently depends on the whole
of *ppc living across probe/attach.  But it mainly uses the ppc_flags
part for the probe, where it is unusable.

resource_int_value() is still used a in a few drivers to find the flags.
Most of the uses are for low level console drivers, where the device
flags are unavailable because new-bus is unavailable.  The only new-bus-
level probe that uses this method seems to be nvram2env_probe().

Unstructured environment settings can work in drivers, but new-bus is
even further from being able to support this (by the definition of
"unstructured").  The driver just has to find them using a direct
method in the probe if they are needed in the probe.  Then there are
complications linking these with the new-bus part of the configuration.

Bruce