Date: Thu, 05 Jun 2003 04:17:38 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "David P. Reese Jr." <daver@gomerbud.com> Cc: current@freebsd.org Subject: Re: viapropm doesnt like sys/dev/pci.c rev 1.214 Message-ID: <3EDF26D2.C93A93DF@mindspring.com> References: <20030602222009.A16160@armor.free.fr> <XFMail.20030603015436.conrads@cox.net> <20030603175430.GA4039@tombstone.localnet.gomerbud.com> <20030604072907.GA10742@tombstone.localnet.gomerbud.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"David P. Reese Jr." wrote: > > > A snip of code from sys/dev/pci/pci.c:pci_enable_io_method(): > > > > > > pci_set_command_bit(dev, child, bit); > > > command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); > > > if (command & bit) > > > return (0); > > > device_printf(child, "failed to enable %s mapping!\n", error); > > > return (ENXIO); > > > > > > Because the viapropm's command register bits will always read as zero, > > > this code will always fail when trying to enable port mapping. [ ... ] > > How about adding another flag to bus_alloc_resource() which would signal > that we are not to check the value of the command register after calling > pci_set_command_bit(). > > RF_WILLFAIL? > > After pci_enable_io_method() gets swallowed into pci_alloc_resource(), > this would be pretty easy because the flag would be in scope when we > check the value of the command register. > > I can do so this weekend if anyone thinks this is worthwhile. How about RF_DONTCHECK or RF_ALWAYSWORKS? It better implies what's happening here, since you're going to assume success in the face of diagnostics to the contrary. So instead of: if (flag) return (0); command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); if (command & bit) return (0); device_printf(child, "failed to enable %s mapping!\n", error); return (ENXIO); You do: command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); if ((command & bit) || flag) return (0); device_printf(child, "failed to enable %s mapping!\n", error); return (ENXIO); Yeah, I know the disctinction is subtle, but there migh be other PCI_READ_CONFIG() results later that people care about, besides just this one bit, which *do* work on some other chip with the same issue. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EDF26D2.C93A93DF>