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

[Garrett Cooper]

On Tue, Aug 17, 2010 at 6:07 AM, John Baldwin <jhb at 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 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.

    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