Mark Kettenis <[email protected]> wrote: > > From: "Theo de Raadt" <[email protected]> > > Date: Wed, 04 Sep 2019 07:43:18 -0600 > > > > Mark Kettenis <[email protected]> wrote: > > > > > > Date: Mon, 2 Sep 2019 16:49:56 +0200 > > > > From: Alexander Bluhm <[email protected]> > > > > > > I'm still looking into this issue. However: > > > > > > > OpenBSD 6.6-beta (GENERIC.MP) #276: Sun Sep 1 22:36:53 MDT 2019 > > > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > real mem = 6416760832 (6119MB) > > > > avail mem = 6209593344 (5921MB) > > > > mpath0 at root > > > > scsibus0 at mpath0: 256 targets > > > > mainbus0 at root > > > > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x99c00 (88 entries) > > > > bios0: vendor American Megatrends Inc. version "1.1b" date 03/04/2010 > > > > bios0: Supermicro X8DTH-i/6/iF/6F > > > > > > This happens to be one of the few systems that is blacklistted by > > > Linux. Still thinking about a better approach. > > > > > > I'd also like to point out that the following messages: > > > > > > > uhci0 at pci0 dev 26 function 0 "Intel 82801JI USB" rev 0x00: can't map > > > > i/o space > > > > uhci1 at pci0 dev 26 function 1 "Intel 82801JI USB" rev 0x00: can't map > > > > i/o space > > > > > > mean that uhci(4) didn't fully attach but that the driver's activate > > > function doesn't properly check that the registers are accessable. > > > > Speaking broadly, These "don't fully attach" drivers are a disturbing > > problem. > > > > It is a weakness in Torek's configuration subsystem that the probe/match > > routine cannot early-execute a complex detection and then pass the result > > to the attach routine. Pretty obvious how it came about, in sparc / OFW > > systems these kinds of "there but not there" conditions are impossible. > > > > In that world, a match function only looks at the parent-bus, not at > > child-device characteristics. > > > > Not being able to pass a partial result from match -> attach, means > > trying to setup-and-some-checking would require duplication of code in > > both match & attach functions. Since people don't want to duplicate > > code, they don't do so. They they allow the match to complete, and > > silently to finish the job correctly in attach. But having suceeded to > > match, the device is now in the device-tree and later code will call some > > of the methods.... > > > > Another possible approach would be that attach can return a failure, > > rather than void. If an attach function returns failure, remove it from > > the device tree, so that the methods are unreachable. Like an undo of > > the match. This would be a huge diff adjusting return conditions of all > > attach functions. > > For complex drivers, it is impossible to check everything up front.
By "up front" I assume you mean in probe. The 2nd approach isn't up front, it is in attach. Removing devices which failed to to complete attach would still be a valid approach. If the mapping cannot be solved, maybe the activate function can skip > > all work if sc->sc.sc_size is 0. > > So this is, IMHO, the only viable approach. I just wanted to trick > somebody else into doing the work ;). I think it is a valid shortcut. But I think changing the return signature of attach to "int" would be quite helpful.
