Why doesn't ppc(4) check non-ENXIO failures during probe?

[John Baldwin]

On Monday, August 16, 2010 7:23:54 pm Garrett Cooper wrote:
> On Mon, Aug 16, 2010 at 1:19 PM, John Baldwin <jhb at 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.

-- 
John Baldwin