A modern driver for a device will find out the bus-resource configuration without you having to tell it anything. It may even set the bus-resources in the hardware using PnP methods. Some drivers have more than one way to find out how their physical device is configured. In the worst case you must hard-code the bus-resources into the kernel (or a module) and recompile.
In the middle are cases such as where you run a program to give the bus-resource info to the driver or put the info in a configuration file. In some cases the driver may probe for the device at addresses where it suspects the device resides (but it will never find a PnP device if it hasn't been enabled by PnP methods). It may then try to test various IRQs to see which one works. It may or may not automatically do this.
In the modern case the driver should use PnP methods to find the device and how the bus-resources have been set by the BIOS, etc. but will not actually set them. It may also look at some of the "files" in the /proc directory.
One may need to "manually" tell a driver what bus-resources it should use. You give such bus-resources as a parameter to the kernel or to a loadable module. If the driver is built into the kernel, you pass the parameters to the kernel via the "boot-prompt". See The Boot-Prompt-HOWTO which describes some of the bus-resource and other parameters. Once you know what parameters to give to the kernel, one may put them into a boot loader configuration file. For example, put append="...". into the lilo.conf file and then use the lilo command to get this info into the lilo kernel loader.
If the driver is loaded as a module, in many cases the module will find the bus-resources needed and then set them in the device. In other cases (mostly for older PCs) you may need to give bus-resources as parameters to the module. Parameters to a module (including ones that automatically load) may be specified in /etc/modules.conf. There are usually tools used to modify this file which are distribution-dependent. Comments in this file should help regarding how to modify it. Also, any module your put in /etc/modules will get loaded along with its parameters.
While there is much non-uniformity about how drivers find out about bus-resources, the end goal is the same. If you're having problems with a driver you may need to look at the driver documentation (check the kernel documentation tree). Some brief examples of a few drivers is presented in the following sections:
For PCI serial ports (and for ISA PnP serial ports after 2.4 kernels) the serial driver detects the type of serial port and PnP configures it. Unfortunately, there may be some PCI serial ports that are not supported yet.
For the standard ISA serial port with very old older versions of the kernel and serial driver (not for multiport cards) the driver probes two standard addresses for serial ports. It doesn't probe for IRQs but it just assigns the "standard" IRQ to the first two serial ports. This could be wrong.
For anything else the configuration file for the setserial
program must be manually modified. See Serial-HOWTO for more
details. You use setserial to inform the driver of the IO address and
Setserial is often run from a start-up file. In newer versions there
is a /etc/serial.conf file (or /var/lib/setserial/autoconfig that you
"edit" by simply using the setserial command in the normal way and
what you set using setserial is saved in the serial.conf
configuration file. The serial.conf file should be consulted
when the setserial command runs from a start-up file. Your
distribution may or may not set this up for you.
There are two different ways to use setserial depending on the
options you give it. One use is used to manually tell the driver the
configuration. The other use is to probe at a given address and
report if a serial port exists there. It can also probe this address
and try to detect what IRQ is used for this port.
Even with modern kernels, setserial is sometimes needed if the driver fails to detect the serial port, or if you have very old hardware.