> 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. > 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 ;).
