Re: Address of second TMSCP controller

[David Brownlee <abs%netbsd.org@localhost>]

On Sat, 30 Jan 2021 at 17:03, Johnny Billquist <bqt%update.uu.se@localhost> wrote:
>
> On 2021-01-30 16:13, Anders Magnusson wrote:
> > Den 2021-01-29 kl. 16:50, skrev David Brownlee:
> >> I think it would be reasonable for the uba bus in NetBSD to have an
> >> option to follow floating address assignment rules when probing for
> >> devices - it could probe for any defined devices without explicit csr
> >> addresses using the floating algorithm, and then try to attach any
> >> devices with csrs as a second pass.
> >>
> >> Of course, this is all assuming someone wanted to write the code :-p
> > IIRC we had a discussion about this quite some time ago.  It should be
> > rather straightforward to do it.
> > Don't remember where it ended up though.
>
> I also remember we had the discussion, and I can't really remember the
> conclusion either.
>
> However, just thinking about it right now, I sortof do not think it's
> that useful.
>
> For that, you should then essentially have a config that lists every
> device with wildcarding. And whenever people change any hardware
> configuration, all CSRs will have to be checked, and possibly a bunch
> changed.
>
> Would that be very useful?

I think it sounds close to ideal. GENERIC has one row for each device
of the form

  xx* at uba?

at autoconfig the kernel runs through the standard floating address
rules when probing devices and finds ~everything as VMS would

If you want to hardcode checking for devices at specific addresses you
use the current format a'la

  xx* at uba csr NNNNN

If you want to mix and match you just need to decide whether you run
to the end of the floating address rules first, then test for any
fixed csr entries, or run the fixed ones first and then run the
floating

> Well, of course, you don't actually need to have every controller listed
> with wildcarding in the config. You'd need to consider this autoprobing
> then, and trying to match up against what is configured. Still have the
> whole issue of any hardware change requiring CSR check and update.

Sorry - I think I may be missing something (my qbus/unibus fu is
somewhat limited :) - what would the hardware change issue be - on
boot the kernel could run through the floating address logic and
configure whatever it finds each time, starting from device number 0
in each case.

> Don't we also have something similar with MSCP? Or can we actually say
> ra* on mscpbus? unit * or something similar? Or don't we need to put a
> few more details in?
> Alternatively:
> ra0 on mscpbus? unit 0
> and so on, but then you might end up with quite a few entries in there,
> since we should atleast cover something like 16 units.

GENERIC has multiple wildcarded MSCP controllers and devices - eg, so

uda*         at uba? csr 0172150     # UDA50/RQDX?
uda*         at uba? csr 0160334
mscpbus* at uda?
ra*              at mscpbus? drive?

As ever a config can lock a device to show up at a specific id by
adding a hardcoded chain entries with fixed ids, though for GENERIC I
assume the best option is dynamically assigning everything so the
widest range of hardware options would Just Work, and we do not need
10,000 entries in /dev :)

David