Date: Mon, 24 Jun 2002 09:58:48 +0100 From: Doug Rabson <dfr@nlsystems.com> To: "M. Warner Losh" <imp@village.org>, arch@freebsd.org Subject: Re: It is time to admit that removable devices exist Message-ID: <200206240958.48240.dfr@nlsystems.com> In-Reply-To: <20020623.171200.96231110.imp@village.org> References: <20020623.171200.96231110.imp@village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 24 June 2002 12:12 am, M. Warner Losh wrote:
> Please find enclosed the beginnings of a patch to make removable
> devices better represented in the system. Right now all it adds is a
> mechanism by which client drivers can ask if the device is still
> really there or not.
>
> The new bus_if method would be "child_present". The default,
> implemented in the nexus, would return "yes." However, busses that
> can have their devices removed, and can have knowledge of such an
> event, are expected to override the bus_child_present method. In that
> method, they are expected to make the determination, by direct
> inspection of the hardware if possible, if the device is really there
> or not.
>
> child_present is expected to return 0 when the device is gone, and a
> -1 when the device is present. This also happens to be binary
> compatible with old releases since when you call a method that isn't
> in a device's method table, it return ENXIO. This is non-zero and is
> the most compatible thing you can return. Drivers that wish to cope
> on their own with systems too old to have this call can check for 0 or
> -1 directly and if not one of those two methods, they are free to
> adopt their own ad-hoc methods for dealing. I expect there to be no
> such drivers, but it never hurts to design for them. Most client
> drivers will check for =3D=3D 0 or !=3D 0.
>
> Why do we need this? Many device drivers do not properly deal with
> device gone conditions. When the device disappears, they either loop
> forever waiting for a bit to clear, or they have some kind of kludge
> that prevents this from happening (0xff is magic, limits on the number
> of loops, etc). It would be much cleaner if a device had a
> bus-independent way to ask these questions.
>
> I plan to implement this for both OLDCARD/NEWCARD soon, and also to
> MFC it into -stable since it is useful and also backwards compatible.
> It will likely be one of the last things that I do to OLDCARD.
>
> Comments?
In your implementation of bus_generic_child_present, you pass the origina=
l=20
device to the parent bus' child_present method. The idea of cascading the=
=20
request is a good one (e.g. the phy of a cardbus ethernet card is clearly=
not=20
present if the card itself isn't present). It might be better for the bus=
=20
implementation though if you pass the bus rather than the original child=20
device, e.g.:
int
+bus_generic_child_present(device_t bus, device_t child)
+{
+=09return (BUS_CHILD_PRESENT(device_get_parent(bus), bus));
+}
This would give the parent bus enough information to find the ivars etc. =
to=20
make a decision about whether 'bus' is still present.
--=20
Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com
=09=09=09=09=09Phone: +44 20 8348 6160
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206240958.48240.dfr>