From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 17 21:04:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A19710656A9 for ; Tue, 17 Aug 2010 21:04:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 55B598FC17 for ; Tue, 17 Aug 2010 21:04:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0296C46B09; Tue, 17 Aug 2010 17:04:27 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E0B668A03C; Tue, 17 Aug 2010 17:04:25 -0400 (EDT) From: John Baldwin To: Garrett Cooper Date: Tue, 17 Aug 2010 16:15:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201008170907.20593.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008171615.21103.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 17 Aug 2010 17:04:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: Why doesn't ppc(4) check non-ENXIO failures during probe? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 21:04:29 -0000 On Tuesday, August 17, 2010 3:56:20 pm Garrett Cooper wrote: > On Tue, Aug 17, 2010 at 6:07 AM, John Baldwin wrote: > > On Monday, August 16, 2010 7:23:54 pm Garrett Cooper wrote: > >> On Mon, Aug 16, 2010 at 1:19 PM, John Baldwin wrote: > >> > On Sunday, August 15, 2010 1:33:38 am Garrett Cooper wrote: > >> >> One thing that's puzzling me about the ppc(4) driver's ISA > >> >> routines is that it only checks to see whether or not the device has > >> >> an IO error: > >> > > >> > Your patch would break hinted ppc devices. ENXIO means that the device_t > >> > being probed has an ISA PNP ID, but it does not match any of the IDs in the > >> > list. ENONET means that the device_t does not have an ISA ID at all. For the > >> > isa bus that means it was explicitly created via a set of ppc.X hints. > >> > >> Just clarifying some things because I don't know all of the details. > >> > >> If a ISA based parallel port fails to probe with ENOENT, then it's > >> assumed that the configuration details are incorrect, and it should > >> reprobe the device with different configuration settings (irq, isa > >> port, etc) a max of BIOS_MAX_PPC times before it finally bails failing > >> to configure a device (ppc_probe in ppc.c)? What if all of the ISA > >> details in the device.hints file are bogus and the only detail that's > >> correct is in the puc driver, etc? Would it fail to connect the card > >> if it reached the BIOS_MAX_PPC ISA-related failure limit (see > >> ppc_probe again)? > > > > ISA_PNP_PROBE() does not talk to the hardware, it just compares device IDs. > > You have to realize that device_t objects on an ISA device come from three > > sources: > > > > 1) "Builtin" devices are auto-enumerated via ACPI or PnP BIOS. Any > > modern BIOS will do this for things like built in serial ports, ISA > > timers, PS/2 keyboard, etc. > > > > 2) ISA PnP adapters in an ISA slot are enumerated via ISA PnP. > > > > 3) Users indicate that specific ISA devices are present via hints. > > > > Devices from 1) and 2) have an assigned device ID (HID) and zero-or-more > > compatibility IDs (CID). ISA_PNP_PROBE() accepts a list of HID IDs and > > returns true (0) if the HID or any of the CIDs match any of the ids in > > the list that is passed in. If none of the IDs match it returns ENXIO. > > Thus for devices from 1) and 2) ISA_PNP_PROBE() returns either 0 or > > ENXIO. For devices from 3), ISA_PNP_PROBE() will always return ENOENT. > > > > Your change would break 3) since those devices would then never probe. > > > > ppc_probe() is called to verify that the hardware truly exists at the > > resources that are claimed. In practice the loop you refer to never runs > > now as the default hints for ppc always specify a port and ppc adapters > > from 1) always include the port resource. That loop should probably > > belong in an identify routine instead of in the probe routine anyway. > > It probably predates new-bus. > > > > The waters are slightly muddied further by the fact that if the resources > > specified in a hint match the resources from one of the devices found via > > 1) or 2), the device from 1) or 2) will actually subsume the hinted device > > so you will not get a separate type 3) device. For example, in the default > > hints uart0 specifies an I/O port of 0x3f8. If ACPI tells the OS about a > > COM1 serial port with the default I/O port (0x3f8), then the hints cause > > that device to be "named" uart0 and to use the flags from uart0 to enable > > the serial console, etc. > > So more or less it's for BIOSes with ISA that doesn't feature plug > and play (286s, 386s, some 486s?)? Just trying to fill in the gap :). Yes, it may perhaps still be useful for some x86 embedded systems, though it is doubtful that those would use a ppc(4) device perhaps. -- John Baldwin