Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Aug 2010 12:56:20 -0700
From:      Garrett Cooper <yanegomi@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Why doesn't ppc(4) check non-ENXIO failures during probe?
Message-ID:  <AANLkTikfDDDnqo=8ozLp7WTJkHhUnCK4sL=ygiVJcc48@mail.gmail.com>
In-Reply-To: <201008170907.20593.jhb@freebsd.org>
References:  <AANLkTinMSdRh0T4aWpZ4gR%2BRogzHQS5Vz7f6O1_vozvo@mail.gmail.com> <201008161619.35740.jhb@freebsd.org> <AANLkTinpbFFqtSSuqq7p-v82H7riUkWyc8LJbzGi1ojs@mail.gmail.com> <201008170907.20593.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
>> >> =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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikfDDDnqo=8ozLp7WTJkHhUnCK4sL=ygiVJcc48>