Izumi Tsutsui wrote:
> In article <44086142.4030400@netbsd.org>
> shige@NetBSD.org wrote:
>
>   
>> (for example, when we can only one (fixed) protocol on a psc device),
>> we need to reconsider a concept of implementing this driver,
>> and to detect kernel configuration errors.
>>     
>
> If we can assume all boards have static configuration on each PSC
> and we don't have to switch protocols at runtime, we can put info
> how each PSC is configured on the hardware via device properties
> in board specific init functions, and au*_match function can check
> the values.
>   
I like this idea.

I think we need to make autoconf.c device_register() be able to call
into some board-specific hook function.  Right now we don't have that.

In general, I do not believe that it is likely that you are going to
want to change the protocol for a PSC on a given board, or if you do,
its because its a debug board, and building a new kernel seems reasonable.

Actually, it would be nice to have support for properties in YAMON to be
able to override the generic board properties.  Then for development you
don't even need to build a new kernel if you change the hardware on a PSC.
> Or, if we can assume the firmware configures each PSC properly,
> we can read current settings from the PSC register in match function.
>   
We can't do that, because firmware doesn't do anything for them.

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191