From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 17 19:56:22 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 DA6AF106564A; Tue, 17 Aug 2010 19:56:22 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 39BDC8FC14; Tue, 17 Aug 2010 19:56:21 +0000 (UTC) Received: by bwz20 with SMTP id 20so3780278bwz.13 for ; Tue, 17 Aug 2010 12:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zWn2trO2eZE+Fke/bOqFSMyco8gooIEd+iPv9aTUlyo=; b=Nmyf7wO76BNJBfX+bDoIva2E0aKbOqjTv2DGAWrZwJX9arjIjTqMllmRBoMEkYE8IM 98e+H6XcTigqwG4pLjXA/hXCjYBuF8uzGYNrG5SciTaqz6MugjnTDA3oLD4RjZdUzI7i t9TQwVKZyIxi7wQ7IHAAGhMbo/R6ZDpT1j9wI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pmWhrmQ2pHPLLr7SJ1icdWaheDVm1SxAyp/LTOb5Kfkofws672GXEZ2hiO58sFZ+Dy SgPLbF7YJ4v6yVkzAGz951jbZgVDeTleoNHCVXvfpt0RKDnwPG5htIUoWYO7p2vmIMtp SW8IqKSwhMSMyB1JP3Mb7QSJPIj6sZcy66zts= MIME-Version: 1.0 Received: by 10.204.21.135 with SMTP id j7mr4712233bkb.198.1282074981001; Tue, 17 Aug 2010 12:56:21 -0700 (PDT) Received: by 10.204.82.6 with HTTP; Tue, 17 Aug 2010 12:56:20 -0700 (PDT) In-Reply-To: <201008170907.20593.jhb@freebsd.org> References: <201008161619.35740.jhb@freebsd.org> <201008170907.20593.jhb@freebsd.org> Date: Tue, 17 Aug 2010 12:56:20 -0700 Message-ID: From: Garrett Cooper To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 17 Aug 2010 20:05:02 +0000 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 19:56:22 -0000 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: >> >> =A0 =A0 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. =A0ENXIO means that the dev= ice_t >> > being probed has an ISA PNP ID, but it does not match any of the IDs i= n the >> > list. =A0ENONET means that the device_t does not have an ISA ID at all= . =A0For 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 ID= s. > You have to realize that device_t objects on an ISA device come from thre= e > sources: > > =A01) "Builtin" devices are auto-enumerated via ACPI or PnP BIOS. =A0Any > =A0modern BIOS will do this for things like built in serial ports, ISA > =A0timers, PS/2 keyboard, etc. > > =A02) ISA PnP adapters in an ISA slot are enumerated via ISA PnP. > > =A03) 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). =A0ISA_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. =A0If none of the IDs match it returns ENXIO. > Thus for devices from 1) and 2) ISA_PNP_PROBE() returns either 0 or > ENXIO. =A0For 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. =A0In practice the loop you refer to never ru= ns > now as the default hints for ppc always specify a port and ppc adapters > from 1) always include the port resource. =A0That 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 devic= e > so you will not get a separate type 3) device. =A0For example, in the def= ault > hints uart0 specifies an I/O port of 0x3f8. =A0If 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 :). Thanks! -Garrett