On Fri, Jun 24, 2016 at 2:02 AM, Michael <macal...@netbsd.org> wrote: > Hello, > > On Thu, 23 Jun 2016 16:13:53 +0000 > Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> wrote: > >> Date: Thu, 23 Jun 2016 19:40:14 +0900 >> From: Masanobu SAITOH <msai...@execsw.org> >> >> As you know, the return value of device driver's attach function is >> void. >> I've thought that we should change it to int for many years. I believe I'm >> not the only person. >> >> Sounds plausible to me. Can you draft an example of a patch to a >> driver that would usefully use this? Something to demonstrate how >> many untested code paths we can eliminate by moving conditional logic >> about `device failed to attach' to autoconf instead of copying it in >> drivers. > > I dimly remember running into this issue - had to abort attach()ing for > some reason and leave a non-functional device_t hanging in the tree. > A good example would be cold graphics chips that we don't know how to > setup without firmware help ( That is, most of them. Many need things > like memory controller and clocks set up in ways that can not be > reliably probed. Clock chips tend to vary, video memory parameters are > hard coded by BIOS with no good way to even guess them etc. ) > Like a PCish graphics card with x86 firmware in something not-a-PC. > These will match() successfully ( since we only look for PCI IDs ) but > can't continue halfway through attach().
Ideally xxxattach() becomes re-startable and can return EAGAIN so autoconf(9) will call it when things are ready. If autoconf(9) keeps device tree as data, there is little point to have call-tree, like xxxattach -> config_found -> yyyattach -> config_find_* -> zzzattach. Instead autoconf(9) does tree traversal while keeping node states. xxxattach might be called again after sub-tree enumeration is done, if necessary.