Date: Tue, 17 Aug 2010 16:15:21 -0400 From: John Baldwin <jhb@freebsd.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Why doesn't ppc(4) check non-ENXIO failures during probe? Message-ID: <201008171615.21103.jhb@freebsd.org> In-Reply-To: <AANLkTikfDDDnqo=8ozLp7WTJkHhUnCK4sL=ygiVJcc48@mail.gmail.com> References: <AANLkTinMSdRh0T4aWpZ4gR%2BRogzHQS5Vz7f6O1_vozvo@mail.gmail.com> <201008170907.20593.jhb@freebsd.org> <AANLkTikfDDDnqo=8ozLp7WTJkHhUnCK4sL=ygiVJcc48@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, August 17, 2010 3:56:20 pm Garrett Cooper wrote: > On Tue, Aug 17, 2010 at 6:07 AM, John Baldwin <jhb@freebsd.org> wrote: > > On Monday, August 16, 2010 7:23:54 pm Garrett Cooper wrote: > >> On Mon, Aug 16, 2010 at 1:19 PM, John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008171615.21103.jhb>