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>