to move up the start address until the allocation succeeds. If the
alignment of the resource was 0, then the code would keep trying the same
request in an infinite loop and hang. Force the request to always move
start up by at least 1 byte each time through the loop.
for CBUS-PNP cards there) by default, as there are no amd64 and sparc64
machines with ISA slots and which therefore could make use of this code
known to exist. For sparc64 this additionally allows to get rid of the
compat shims for in{b,w,l}()/out{b,w,l}() etc and the associated hacks.
OK'ed by: imp, peter
primary vendor id for this device. The location is empty because ISA
doesn't give one a way to generally locate a card. PNP BIOS entries
do provide a way to locate cards, as do isa pnp cards. These
locations will be added as soon as the code to remember them is
written.
last in the list rather than first.
This makes the resouces print in the 4.x order rather than the 5.x order
(eg fdc0 at 0x3f0-0x3f5,0x3f7 is 4.x, but 0x3f7,0x3f0-0x3f5 is 5.x). This
also means that the pci code will once again print the resources in BAR
ascending order.
have seen in the isa pnp case where a resource buts up against
0xffffffff. This would only impact when the board was booted without
ACPI.
Submitted by: Ed Maste (freebsd-stable <20050103145720.GA90754@sandvine.com>)
MFC After: 5 days
- Factor out code common to all ISA bridge drivers attach methods into a
isab_attach() function.
- Rename the PCI-ISA bridge driver's attach function to pci_isab_attach()
and have it call isab_attach().
have to use it since all AMD64 machines are supposed to have acpi etc,
I'm using it during development so I can avoid the acpi code for now.
Yes, this is cheating.
homerolling our own version.
- Rename the enum for memsize from ISA_IVAR_MSIZE to ISA_IVAR_MEMSIZE
since using 'MSIZE' in the macro invocation of ISA_ACCESSOR() conflicts
with the 'MSIZE' kernel option. The accessor function is still
isa_get_msize().
the following bugs.
- When constructing a resource configuration, respect the order
in which resource descriptors are read, in order to establish
the correct mapping between the descriptors and configuration
registers.
"Plug and Play ISA Specification, Version 1.0a", Sec 4.6.1, May 5,
1994. "Clarifications to the Plug and Play ISA Specification,
Version 1.0a", Sec 6.2.1, Dec. 10, 1994.
- Do not ignore null (empty) descriptors; they are valid descriptors
acting as filler.
"Clarifications to the Plug and Play ISA Specification, Version 1.0a",
Sec 6.2.1.
- Correctly set up logical device configuration registers for null
resources.
"Clarifications to the Plug and Play ISA Specification, Version 1.0a"
- Handle null resources properly in the resource allocator for the
ISA bus.
instead, use the bus_print_child_* functions to display the error message.
Also, since this is more of a warning than an error, hide it behind
bootverbose.
Similarly, if isa_assign_resources() fails to allocate resources to a
device, use bus_print_child_header() instead of device_printf(), and
display the resources that could not be allocated if bootverbose is true.
Approved by: msmith
Help from: mdodd
- trying for a fit for a PnP configuration from a device
- soaking up resources from a configuration that were not allocated by
the driver
do not attempt to activate them. Only a device driver that is aware of
the nature of the resource and its suitability can be certain that
activating a resource, particularly a memory resource, is a safe thing
to do.
This was prompted by the discovery that many systems report all physical
memory through a PNP0c02 device; activating this resource maps all
physical memory into the kernel's virtual space, either blowing out the
kernel pagetable or in the worst case causing a panic in pmap_mapdev()
if the system has too much physical memory.
Authorised by: jkh
Reviewed by: dfr
and there may be a good reason for them being unallocated (eg. they're
nonsensical or not useful). The goal here is simply to reserve them
against accidental use by other code.
device_add_child_ordered(). 'ivars' may now be set using the
device_set_ivars() function.
This makes it easier for us to change how arbitrary data structures are
associated with a device_t. Eventually we won't be modifying device_t
to add additional pointers for ivars, softc data etc.
Despite my best efforts I've probably forgotten something so let me know
if this breaks anything. I've been running with this change for months
and its been quite involved actually isolating all the changes from
the rest of the local changes in my tree.
Reviewed by: peter, dfr
during autoconfig to support strange hardware (such as the Yamaha DS-1)
which implements 'legacy' ISA devices as well as a PCI device. This will
allow the PCI driver for the YMF724 to add the legacy devices to the ISA
bus and will allow the PnP system to automatically allocate the resources
for those devices.
resource_list_release. This removes the dependancy on the
layout of ivars.
* Move set_resource, get_resource and delete_resource from
isa_if.m to bus_if.m.
* Simplify driver code by providing wrappers to those methods:
bus_set_resource(dev, type, rid, start, count);
bus_get_resource(dev, type, rid, startp, countp);
bus_get_resource_start(dev, type, rid);
bus_get_resource_count(dev, type, rid);
bus_delete_resource(dev, type, rid);
* Delete isa_get_rsrc and use bus_get_resource_start instead.
* Fix a stupid typo in isa_alloc_resource reported by Takahashi
Yoshihiro <nyan@FreeBSD.org>.
* Print a diagnostic message if we can't assign resources to a PnP
device.
* Change device_print_prettyname() so that it doesn't print
"(no driver assigned)-1" for anonymous devices.
new system is integrated with the ISA bus code more cleanly and allows
the future addition of more enumerators such as PnPBIOS and ACPI.
This commit also enables the new pcm driver since it is somewhat tied to
the new PnP code.
- device_print_child() either lets the BUS_PRINT_CHILD
method produce the entire device announcement message or
it prints "foo0: not found\n"
Alter sys/kern/subr_bus.c:bus_generic_print_child() to take on
the previous behavior of device_print_child() (printing the
"foo0: <FooDevice 1.1>" bit of the announce message.)
Provide bus_print_child_header() and bus_print_child_footer()
to actually print the output for bus_generic_print_child().
These functions should be used whenever possible (unless you can
just use bus_generic_print_child())
The BUS_PRINT_CHILD method now returns int instead of void.
Modify everything else that defines or uses a BUS_PRINT_CHILD
method to comply with the above changes.
- Devices are 'on' a bus, not 'at' it.
- If a custom BUS_PRINT_CHILD method does the same thing
as bus_generic_print_child(), use bus_generic_print_child()
- Use device_get_nameunit() instead of both
device_get_name() and device_get_unit()
- All BUS_PRINT_CHILD methods return the number of
characters output.
Reviewed by: dfr, peter
easier to use and more flexible.
* Change BUS_ADD_CHILD to take an order argument instead of a place.
* Define a partial ordering for isa devices so that sensitive devices are
probed before non-sensitive ones.
* Re-work the resource allocation code to use helper functions in subr_bus.c.
* Add simple isa interface for manipulating the resource ranges which can be
allocated and remove the code from isa_write_ivar() which was previously
used for this purpose.
