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

[John Baldwin]

On Tuesday, August 17, 2010 3:56:20 pm Garrett Cooper wrote:
> 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 :).

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