Date: Thu, 17 Jan 2013 14:10:34 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andre Albsmeier <Andre.Albsmeier@siemens.com> Cc: "freebsd-hardware@freebsd.org" <freebsd-hardware@freebsd.org> Subject: Re: ppc fails to attach to puc on 9.1-STABLE, 7.4-STABLE works Message-ID: <20130117134523.K1345@besplex.bde.org> In-Reply-To: <20130116163342.GA30733@bali> References: <20130110074052.GA8922@bali> <201301141502.58550.jhb@freebsd.org> <20130115154433.GA3459@bali> <201301151527.07227.jhb@freebsd.org> <20130116163342.GA30733@bali>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130117134523.K1345>