Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Aug 2002 23:52:24 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        new-bus@FreeBSD.org
Subject:   Re: ISA bus notes
Message-ID:  <20020830.235224.34542516.imp@bsdimp.com>
In-Reply-To: <XFMail.20020831011036.jhb@FreeBSD.org>
References:  <20020830.220723.10970697.imp@bsdimp.com> <XFMail.20020831011036.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <XFMail.20020831011036.jhb@FreeBSD.org>
            John Baldwin <jhb@FreeBSD.org> writes:
: Well, I think you are looking at it not quite from an OOP perspective.
: :)  Try using the same model of overriding bus drivers that I use
: with ACPI and the PCI bus.  Thus, instead of having the system try
: and know which kind of ISA bus to attach, you have three drivers for
: "isa":

That's what the probe routines are for (oh, I see below you grok that
too).  The system doesn't really know.  I just wrote the if to show
the order.  I wrote the driver names the way I did to make sure that
they were separate drivers and we didn't try to cobble it all into the
isa driver.

: - acpi_isa (called "isa" though) whose probe routine only
:   succeeds if it can read it's handle via ivars on itself.  In
:   all ACPI systems that I know of, we can handle this case fairly
:   easily by providing an ACPI PCI-ISA bridge driver that adds ivar
:   support for the child bus device like the ACPI PCI bus driver
:   does; probe routine returns 0 on success
: - pnp_isa (again, "isa") whose probe routine only succeeds if
:   PNPBIOS is detected.  This probe routine can return -100 or some
:   such.
: - isa (again, "isa") whose probe routine pretty much always succeeds
:   and returns -1000 or some such

Yup.  We're on the same page here.  Good detail catch.

: This way, ISA busses become the right "flavor" of an ISA bus via
: normal probe/attach methods (i.e. we let the probe routines choose
: what type of ISA bus to use).  I think we should leave the hint-device
: merging stuff until later as it requires to fix all the broken ISA
: drivers to get it right.

Actually, it doesn't require that we fix them.  In an ideal world we'd
only match on the HID (and not touch hardware) if a HID was provided,
but the more I've thought about it, the more I think that probing for
the device after matching the HID is OK.  If the device doesn't match
the HID, the probe will fail anyway without touching the hardware.
Touching hardware when we fail the probe is where we run into
trouble.  It is OK to touch the hardware if the probe routine returns
0 because no other hardware can attach to it.

The hints merging stuff could be done later, or by someone else.  It
would just be a modification of the isahint.c file, since I think that
it gets done at the right time.  The pnpisa driver is also a child of
the ISA bus with an identify routine, so that wouldn't be a special
case.  We'd have to make sure that the pnp driver's identify routine
was called before the isahint driver's identify routine.

I think that we could do that after calling bus_generic_attach() and
moving the isahint code into the isa (generic one) bus driver.  But
that relates back to your other question here about bus_generic_probe
vs bus_generic_attach :-).

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-new-bus" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020830.235224.34542516.imp>