fix typos in comments, mainly s/extention/extension/ and s/sufficent/sufficient/

Merge thorpej-cfargs2.

branches: 1.26.8;
Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass along, just have a single call that
takes a variadic list of tag-value arguments.

Adjust all call sites:
- Simplify wherever possible; don't pass along arguments that aren't
actually needed.
- Don't be explicit about what interface attribute is attaching if
the device only has one. (More simplification.)
- Add a config_probe() function to be used in indirect configuiration
situations, making is visibly easier to see when indirect config is
in play, and allowing for future change in semantics. (As of now,
this is just a wrapper around config_match(), but that is an
implementation detail.)

Remove unnecessary or redundant interface attributes where they're not
needed.

There are currently 5 "cfargs" defined:
- CFARG_SUBMATCH (submatch function for direct config)
- CFARG_SEARCH (search function for indirect config)
- CFARG_IATTR (interface attribte)
- CFARG_LOCATORS (locators array)
- CFARG_DEVHANDLE (devhandle_t - wraps OFW, ACPI, etc. handles)

...and a sentinel value CFARG_EOL.

Add some extra sanity checking to ensure that interface attributes
aren't ambiguous.

Use CFARG_DEVHANDLE in MI FDT, OFW, and ACPI code, and macppc and shark
ports to associate those device handles with device_t instance. This
will trickle trough to more places over time (need back-end for pre-OFW
Sun OBP; any others?).

branches: 1.25.10;
Cleanup i2c bus acquire / release, centralizing all of the logic into
iic_acquire_bus() / iic_release_bus(). "acquire" and "release" hooks
no longer need to be provided by back-end controller drivers (only if
they need special handling, e.g. powering on the i2c controller).
This results in the removal of a bunch of rendundant code from each
back-end controller driver.

Assert that we are not in hard interrupt context in iic_acquire_bus(),
iic_exec(), and iic_release_bus().

branches: 1.24.18;
zero the i2c_attach_args structure before filling it in.
fixes occasional crashes in iic_attach().

branches: 1.23.6; 1.23.24;
Replace the xxx_acquire()/xxx_release() rwlocks with mutexes. There are
only RW_WRITERs for these, and no RW_READERs, so no need to incur the
extra overhead of allowing for both. As discussed on tech-kern.

For piixpm and ichsmb, the acquire/release protocol needs to be used,
even if the request is I2C_F_POLL'd (or if the device supports only
polled mode). Otherwise multiple requests can be running at the same
time, and they stomp on each other and create anomolous results.

Part 2 addresses my PR kern/45889

3 ACKs from releng

Use pci_aprint_devinfo(9) instead of pci_devinfo+aprint_{normal,naive}
where it looks straightforward, and pci_aprint_devinfo_fancy in a few
others where drivers want to supply their own device names instead
of the pcidevs generated one. More complicated cases, where names
are composed at runtime, are left alone for now. It certainly makes
sense to simplify the drivers here rather than inventing a catch-all API.
This should serve as as example for new drivers, and also ensure
consistent output in the AB_QUIET ("boot -q") case. Also, it avoids
excessive stack usage where drivers attach child devices because the
buffer for the device name is not kept on the local stack anymore.

branches: 1.21.8; 1.21.12;
Recognize additional SMBus controllers. From FreeBSD.

branches: 1.20.2; 1.20.4;
For multi-byte transfers, the bytes need to be written to or read from
consecutive data registers. Discovered while debugging sdtemp(4) driver
which does _only_ 16-bit transfers!

You can't use a BYTE protocol to read 16-bits worth of data from the
i2c bus. Discovered while debugging my sdtemp(4) driver.

struct device * -> device_t, no functional changes intended.

struct cfdata * -> cfdata_t, no functional changes intended.

branches: 1.16.2;
Update the i2c_exec() functions to handle quick_read/quick_write protocol.

Although interface routines i2c_smbus_*() exist, nothing in NetBSD actually
uses them yet.

branches: 1.15.2;
If we're doing a 2-byte read, return the entire 16-bit result.

branches: 1.14.4;
add comment why NULL handlers are sufficient.
requested and ok'd by jmcneill

add power management support

branches: 1.12.2; 1.12.4; 1.12.6;
Split device_t/softc.

branches: 1.11.6;
Fix the BARs on nForce 430, which failed to attach. Reported by
atsushi fukumoto in PR kern/37756.

branches: 1.10.4;
Newer nForce MCP SMBus devices use different PCI BARs than the old ones
(nForce 2/3/4).

nfsmb(4) is now properly working on newer MCPs, tested by wiz@ on MCP55:

nfsmbc0 at pci0 dev 1 function 1: NVIDIA nForce MCP55 SMBus Controller (rev. 0xa2)
nfsmb0 at nfsmbc0 SMBus 1
iic0 at nfsmb0: I2C bus
spdmem0 at iic0 addr 0x51
spdmem0: DDR2 SDRAM memory, data ECC, 1024MB, 667MHz, PC2-5300
spdmem0: 14 rows, 10 cols, 2 ranks, 4 banks/chip, 3.00ns cycle time
spdmem0: voltage SSTL 1.8V, refresh time 7.8us (self-refreshing)
nfsmb1 at nfsmbc0 SMBus 2
iic1 at nfsmb1: I2C bus

branches: 1.9.2;
Attach to NVIDIA MCP73 now that we have the PCI id.

Attach to more NVIDIA SMBus controllers.

branches: 1.7.2;
machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h

branches: 1.6.2; 1.6.6;
For SMBus, add the ability to enumerate devices on the bus.
This does NOT identify the devices, merely indicates the
presence of devices at certain addresses. Tested on ichsmb
and nfsmb - other SMBus devices will need to ensure the
proper bus type is set. (I2C_TYPE_SMBUS)

From Nicolas Joly, via Paul Goyette, in PR#36744.

branches: 1.5.2;
Use rwlock(9) rather than lockmgr(9).

Remove and insert null-line.
No parentheses are needed around the return value.

branches: 1.3.4; 1.3.6;
s/uint32_t reg/pcireg_t reg/.
Check condition `!= 0'.

We wait for the clearness of the NFORCE_SMB_PROTOCOL as transfer completion.
And, the maximum is assumed to be 10msec. I think that the thing for which
it waits any further is dangerous for the system.

branches: 1.1.2; 1.1.4; 1.1.6;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.

Merge thorpej-cfargs2.

branches: 1.26.8;
Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass along, just have a single call that
takes a variadic list of tag-value arguments.

Adjust all call sites:
- Simplify wherever possible; don't pass along arguments that aren't
actually needed.
- Don't be explicit about what interface attribute is attaching if
the device only has one. (More simplification.)
- Add a config_probe() function to be used in indirect configuiration
situations, making is visibly easier to see when indirect config is
in play, and allowing for future change in semantics. (As of now,
this is just a wrapper around config_match(), but that is an
implementation detail.)

Remove unnecessary or redundant interface attributes where they're not
needed.

There are currently 5 "cfargs" defined:
- CFARG_SUBMATCH (submatch function for direct config)
- CFARG_SEARCH (search function for indirect config)
- CFARG_IATTR (interface attribte)
- CFARG_LOCATORS (locators array)
- CFARG_DEVHANDLE (devhandle_t - wraps OFW, ACPI, etc. handles)

...and a sentinel value CFARG_EOL.

Add some extra sanity checking to ensure that interface attributes
aren't ambiguous.

Use CFARG_DEVHANDLE in MI FDT, OFW, and ACPI code, and macppc and shark
ports to associate those device handles with device_t instance. This
will trickle trough to more places over time (need back-end for pre-OFW
Sun OBP; any others?).

branches: 1.25.10;
Cleanup i2c bus acquire / release, centralizing all of the logic into
iic_acquire_bus() / iic_release_bus(). "acquire" and "release" hooks
no longer need to be provided by back-end controller drivers (only if
they need special handling, e.g. powering on the i2c controller).
This results in the removal of a bunch of rendundant code from each
back-end controller driver.

Assert that we are not in hard interrupt context in iic_acquire_bus(),
iic_exec(), and iic_release_bus().

branches: 1.24.18;
zero the i2c_attach_args structure before filling it in.
fixes occasional crashes in iic_attach().

branches: 1.23.6; 1.23.24;
Replace the xxx_acquire()/xxx_release() rwlocks with mutexes. There are
only RW_WRITERs for these, and no RW_READERs, so no need to incur the
extra overhead of allowing for both. As discussed on tech-kern.

For piixpm and ichsmb, the acquire/release protocol needs to be used,
even if the request is I2C_F_POLL'd (or if the device supports only
polled mode). Otherwise multiple requests can be running at the same
time, and they stomp on each other and create anomolous results.

Part 2 addresses my PR kern/45889

3 ACKs from releng

Use pci_aprint_devinfo(9) instead of pci_devinfo+aprint_{normal,naive}
where it looks straightforward, and pci_aprint_devinfo_fancy in a few
others where drivers want to supply their own device names instead
of the pcidevs generated one. More complicated cases, where names
are composed at runtime, are left alone for now. It certainly makes
sense to simplify the drivers here rather than inventing a catch-all API.
This should serve as as example for new drivers, and also ensure
consistent output in the AB_QUIET ("boot -q") case. Also, it avoids
excessive stack usage where drivers attach child devices because the
buffer for the device name is not kept on the local stack anymore.

branches: 1.21.8; 1.21.12;
Recognize additional SMBus controllers. From FreeBSD.

branches: 1.20.2; 1.20.4;
For multi-byte transfers, the bytes need to be written to or read from
consecutive data registers. Discovered while debugging sdtemp(4) driver
which does _only_ 16-bit transfers!

You can't use a BYTE protocol to read 16-bits worth of data from the
i2c bus. Discovered while debugging my sdtemp(4) driver.

struct device * -> device_t, no functional changes intended.

struct cfdata * -> cfdata_t, no functional changes intended.

branches: 1.16.2;
Update the i2c_exec() functions to handle quick_read/quick_write protocol.

Although interface routines i2c_smbus_*() exist, nothing in NetBSD actually
uses them yet.

branches: 1.15.2;
If we're doing a 2-byte read, return the entire 16-bit result.

branches: 1.14.4;
add comment why NULL handlers are sufficient.
requested and ok'd by jmcneill

add power management support

branches: 1.12.2; 1.12.4; 1.12.6;
Split device_t/softc.

branches: 1.11.6;
Fix the BARs on nForce 430, which failed to attach. Reported by
atsushi fukumoto in PR kern/37756.

branches: 1.10.4;
Newer nForce MCP SMBus devices use different PCI BARs than the old ones
(nForce 2/3/4).

nfsmb(4) is now properly working on newer MCPs, tested by wiz@ on MCP55:

nfsmbc0 at pci0 dev 1 function 1: NVIDIA nForce MCP55 SMBus Controller (rev. 0xa2)
nfsmb0 at nfsmbc0 SMBus 1
iic0 at nfsmb0: I2C bus
spdmem0 at iic0 addr 0x51
spdmem0: DDR2 SDRAM memory, data ECC, 1024MB, 667MHz, PC2-5300
spdmem0: 14 rows, 10 cols, 2 ranks, 4 banks/chip, 3.00ns cycle time
spdmem0: voltage SSTL 1.8V, refresh time 7.8us (self-refreshing)
nfsmb1 at nfsmbc0 SMBus 2
iic1 at nfsmb1: I2C bus

branches: 1.9.2;
Attach to NVIDIA MCP73 now that we have the PCI id.

Attach to more NVIDIA SMBus controllers.

branches: 1.7.2;
machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h

branches: 1.6.2; 1.6.6;
For SMBus, add the ability to enumerate devices on the bus.
This does NOT identify the devices, merely indicates the
presence of devices at certain addresses. Tested on ichsmb
and nfsmb - other SMBus devices will need to ensure the
proper bus type is set. (I2C_TYPE_SMBUS)

From Nicolas Joly, via Paul Goyette, in PR#36744.

branches: 1.5.2;
Use rwlock(9) rather than lockmgr(9).

Remove and insert null-line.
No parentheses are needed around the return value.

branches: 1.3.4; 1.3.6;
s/uint32_t reg/pcireg_t reg/.
Check condition `!= 0'.

We wait for the clearness of the NFORCE_SMB_PROTOCOL as transfer completion.
And, the maximum is assumed to be 10msec. I think that the thing for which
it waits any further is dangerous for the system.

branches: 1.1.2; 1.1.4; 1.1.6;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.

Merge thorpej-cfargs branch:

Simplify and make extensible the config_search() / config_found() /
config_attach() interfaces: rather than having different variants for
which arguments you want pass along, just have a single call that
takes a variadic list of tag-value arguments.

Adjust all call sites:
- Simplify wherever possible; don't pass along arguments that aren't
actually needed.
- Don't be explicit about what interface attribute is attaching if
the device only has one. (More simplification.)
- Add a config_probe() function to be used in indirect configuiration
situations, making is visibly easier to see when indirect config is
in play, and allowing for future change in semantics. (As of now,
this is just a wrapper around config_match(), but that is an
implementation detail.)

Remove unnecessary or redundant interface attributes where they're not
needed.

There are currently 5 "cfargs" defined:
- CFARG_SUBMATCH (submatch function for direct config)
- CFARG_SEARCH (search function for indirect config)
- CFARG_IATTR (interface attribte)
- CFARG_LOCATORS (locators array)
- CFARG_DEVHANDLE (devhandle_t - wraps OFW, ACPI, etc. handles)

...and a sentinel value CFARG_EOL.

Add some extra sanity checking to ensure that interface attributes
aren't ambiguous.

Use CFARG_DEVHANDLE in MI FDT, OFW, and ACPI code, and macppc and shark
ports to associate those device handles with device_t instance. This
will trickle trough to more places over time (need back-end for pre-OFW
Sun OBP; any others?).

branches: 1.25.10;
Cleanup i2c bus acquire / release, centralizing all of the logic into
iic_acquire_bus() / iic_release_bus(). "acquire" and "release" hooks
no longer need to be provided by back-end controller drivers (only if
they need special handling, e.g. powering on the i2c controller).
This results in the removal of a bunch of rendundant code from each
back-end controller driver.

Assert that we are not in hard interrupt context in iic_acquire_bus(),
iic_exec(), and iic_release_bus().

branches: 1.24.18;
zero the i2c_attach_args structure before filling it in.
fixes occasional crashes in iic_attach().

branches: 1.23.6; 1.23.24;
Replace the xxx_acquire()/xxx_release() rwlocks with mutexes. There are
only RW_WRITERs for these, and no RW_READERs, so no need to incur the
extra overhead of allowing for both. As discussed on tech-kern.

For piixpm and ichsmb, the acquire/release protocol needs to be used,
even if the request is I2C_F_POLL'd (or if the device supports only
polled mode). Otherwise multiple requests can be running at the same
time, and they stomp on each other and create anomolous results.

Part 2 addresses my PR kern/45889

3 ACKs from releng

Use pci_aprint_devinfo(9) instead of pci_devinfo+aprint_{normal,naive}
where it looks straightforward, and pci_aprint_devinfo_fancy in a few
others where drivers want to supply their own device names instead
of the pcidevs generated one. More complicated cases, where names
are composed at runtime, are left alone for now. It certainly makes
sense to simplify the drivers here rather than inventing a catch-all API.
This should serve as as example for new drivers, and also ensure
consistent output in the AB_QUIET ("boot -q") case. Also, it avoids
excessive stack usage where drivers attach child devices because the
buffer for the device name is not kept on the local stack anymore.

branches: 1.21.8; 1.21.12;
Recognize additional SMBus controllers. From FreeBSD.

branches: 1.20.2; 1.20.4;
For multi-byte transfers, the bytes need to be written to or read from
consecutive data registers. Discovered while debugging sdtemp(4) driver
which does _only_ 16-bit transfers!

You can't use a BYTE protocol to read 16-bits worth of data from the
i2c bus. Discovered while debugging my sdtemp(4) driver.

struct device * -> device_t, no functional changes intended.

struct cfdata * -> cfdata_t, no functional changes intended.

branches: 1.16.2;
Update the i2c_exec() functions to handle quick_read/quick_write protocol.

Although interface routines i2c_smbus_*() exist, nothing in NetBSD actually
uses them yet.

branches: 1.15.2;
If we're doing a 2-byte read, return the entire 16-bit result.

branches: 1.14.4;
add comment why NULL handlers are sufficient.
requested and ok'd by jmcneill

add power management support

branches: 1.12.2; 1.12.4; 1.12.6;
Split device_t/softc.

branches: 1.11.6;
Fix the BARs on nForce 430, which failed to attach. Reported by
atsushi fukumoto in PR kern/37756.

branches: 1.10.4;
Newer nForce MCP SMBus devices use different PCI BARs than the old ones
(nForce 2/3/4).

nfsmb(4) is now properly working on newer MCPs, tested by wiz@ on MCP55:

nfsmbc0 at pci0 dev 1 function 1: NVIDIA nForce MCP55 SMBus Controller (rev. 0xa2)
nfsmb0 at nfsmbc0 SMBus 1
iic0 at nfsmb0: I2C bus
spdmem0 at iic0 addr 0x51
spdmem0: DDR2 SDRAM memory, data ECC, 1024MB, 667MHz, PC2-5300
spdmem0: 14 rows, 10 cols, 2 ranks, 4 banks/chip, 3.00ns cycle time
spdmem0: voltage SSTL 1.8V, refresh time 7.8us (self-refreshing)
nfsmb1 at nfsmbc0 SMBus 2
iic1 at nfsmb1: I2C bus

branches: 1.9.2;
Attach to NVIDIA MCP73 now that we have the PCI id.

Attach to more NVIDIA SMBus controllers.

branches: 1.7.2;
machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h

branches: 1.6.2; 1.6.6;
For SMBus, add the ability to enumerate devices on the bus.
This does NOT identify the devices, merely indicates the
presence of devices at certain addresses. Tested on ichsmb
and nfsmb - other SMBus devices will need to ensure the
proper bus type is set. (I2C_TYPE_SMBUS)

From Nicolas Joly, via Paul Goyette, in PR#36744.

branches: 1.5.2;
Use rwlock(9) rather than lockmgr(9).

Remove and insert null-line.
No parentheses are needed around the return value.

branches: 1.3.4; 1.3.6;
s/uint32_t reg/pcireg_t reg/.
Check condition `!= 0'.

We wait for the clearness of the NFORCE_SMB_PROTOCOL as transfer completion.
And, the maximum is assumed to be 10msec. I think that the thing for which
it waits any further is dangerous for the system.

branches: 1.1.2; 1.1.4; 1.1.6;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.

Cleanup i2c bus acquire / release, centralizing all of the logic into
iic_acquire_bus() / iic_release_bus(). "acquire" and "release" hooks
no longer need to be provided by back-end controller drivers (only if
they need special handling, e.g. powering on the i2c controller).
This results in the removal of a bunch of rendundant code from each
back-end controller driver.

Assert that we are not in hard interrupt context in iic_acquire_bus(),
iic_exec(), and iic_release_bus().

zero the i2c_attach_args structure before filling it in.
fixes occasional crashes in iic_attach().

branches: 1.23.6; 1.23.24;
Replace the xxx_acquire()/xxx_release() rwlocks with mutexes. There are
only RW_WRITERs for these, and no RW_READERs, so no need to incur the
extra overhead of allowing for both. As discussed on tech-kern.

For piixpm and ichsmb, the acquire/release protocol needs to be used,
even if the request is I2C_F_POLL'd (or if the device supports only
polled mode). Otherwise multiple requests can be running at the same
time, and they stomp on each other and create anomolous results.

Part 2 addresses my PR kern/45889

3 ACKs from releng

Use pci_aprint_devinfo(9) instead of pci_devinfo+aprint_{normal,naive}
where it looks straightforward, and pci_aprint_devinfo_fancy in a few
others where drivers want to supply their own device names instead
of the pcidevs generated one. More complicated cases, where names
are composed at runtime, are left alone for now. It certainly makes
sense to simplify the drivers here rather than inventing a catch-all API.
This should serve as as example for new drivers, and also ensure
consistent output in the AB_QUIET ("boot -q") case. Also, it avoids
excessive stack usage where drivers attach child devices because the
buffer for the device name is not kept on the local stack anymore.

branches: 1.21.8; 1.21.12;
Recognize additional SMBus controllers. From FreeBSD.

branches: 1.20.2; 1.20.4;
For multi-byte transfers, the bytes need to be written to or read from
consecutive data registers. Discovered while debugging sdtemp(4) driver
which does _only_ 16-bit transfers!

You can't use a BYTE protocol to read 16-bits worth of data from the
i2c bus. Discovered while debugging my sdtemp(4) driver.

struct device * -> device_t, no functional changes intended.

struct cfdata * -> cfdata_t, no functional changes intended.

branches: 1.16.2;
Update the i2c_exec() functions to handle quick_read/quick_write protocol.

Although interface routines i2c_smbus_*() exist, nothing in NetBSD actually
uses them yet.

branches: 1.15.2;
If we're doing a 2-byte read, return the entire 16-bit result.

branches: 1.14.4;
add comment why NULL handlers are sufficient.
requested and ok'd by jmcneill

add power management support

branches: 1.12.2; 1.12.4; 1.12.6;
Split device_t/softc.

branches: 1.11.6;
Fix the BARs on nForce 430, which failed to attach. Reported by
atsushi fukumoto in PR kern/37756.

branches: 1.10.4;
Newer nForce MCP SMBus devices use different PCI BARs than the old ones
(nForce 2/3/4).

nfsmb(4) is now properly working on newer MCPs, tested by wiz@ on MCP55:

nfsmbc0 at pci0 dev 1 function 1: NVIDIA nForce MCP55 SMBus Controller (rev. 0xa2)
nfsmb0 at nfsmbc0 SMBus 1
iic0 at nfsmb0: I2C bus
spdmem0 at iic0 addr 0x51
spdmem0: DDR2 SDRAM memory, data ECC, 1024MB, 667MHz, PC2-5300
spdmem0: 14 rows, 10 cols, 2 ranks, 4 banks/chip, 3.00ns cycle time
spdmem0: voltage SSTL 1.8V, refresh time 7.8us (self-refreshing)
nfsmb1 at nfsmbc0 SMBus 2
iic1 at nfsmb1: I2C bus

branches: 1.9.2;
Attach to NVIDIA MCP73 now that we have the PCI id.

Attach to more NVIDIA SMBus controllers.

branches: 1.7.2;
machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h

branches: 1.6.2; 1.6.6;
For SMBus, add the ability to enumerate devices on the bus.
This does NOT identify the devices, merely indicates the
presence of devices at certain addresses. Tested on ichsmb
and nfsmb - other SMBus devices will need to ensure the
proper bus type is set. (I2C_TYPE_SMBUS)

From Nicolas Joly, via Paul Goyette, in PR#36744.

branches: 1.5.2;
Use rwlock(9) rather than lockmgr(9).

Remove and insert null-line.
No parentheses are needed around the return value.

branches: 1.3.4; 1.3.6;
s/uint32_t reg/pcireg_t reg/.
Check condition `!= 0'.

We wait for the clearness of the NFORCE_SMB_PROTOCOL as transfer completion.
And, the maximum is assumed to be 10msec. I think that the thing for which
it waits any further is dangerous for the system.

branches: 1.1.2; 1.1.4; 1.1.6;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.

zero the i2c_attach_args structure before filling it in.
fixes occasional crashes in iic_attach().

branches: 1.23.24;
Replace the xxx_acquire()/xxx_release() rwlocks with mutexes. There are
only RW_WRITERs for these, and no RW_READERs, so no need to incur the
extra overhead of allowing for both. As discussed on tech-kern.

For piixpm and ichsmb, the acquire/release protocol needs to be used,
even if the request is I2C_F_POLL'd (or if the device supports only
polled mode). Otherwise multiple requests can be running at the same
time, and they stomp on each other and create anomolous results.

Part 2 addresses my PR kern/45889

3 ACKs from releng

Use pci_aprint_devinfo(9) instead of pci_devinfo+aprint_{normal,naive}
where it looks straightforward, and pci_aprint_devinfo_fancy in a few
others where drivers want to supply their own device names instead
of the pcidevs generated one. More complicated cases, where names
are composed at runtime, are left alone for now. It certainly makes
sense to simplify the drivers here rather than inventing a catch-all API.
This should serve as as example for new drivers, and also ensure
consistent output in the AB_QUIET ("boot -q") case. Also, it avoids
excessive stack usage where drivers attach child devices because the
buffer for the device name is not kept on the local stack anymore.

branches: 1.21.8; 1.21.12;
Recognize additional SMBus controllers. From FreeBSD.

branches: 1.20.2; 1.20.4;
For multi-byte transfers, the bytes need to be written to or read from
consecutive data registers. Discovered while debugging sdtemp(4) driver
which does _only_ 16-bit transfers!

You can't use a BYTE protocol to read 16-bits worth of data from the
i2c bus. Discovered while debugging my sdtemp(4) driver.

struct device * -> device_t, no functional changes intended.

struct cfdata * -> cfdata_t, no functional changes intended.

branches: 1.16.2;
Update the i2c_exec() functions to handle quick_read/quick_write protocol.

Although interface routines i2c_smbus_*() exist, nothing in NetBSD actually
uses them yet.

branches: 1.15.2;
If we're doing a 2-byte read, return the entire 16-bit result.

branches: 1.14.4;
add comment why NULL handlers are sufficient.
requested and ok'd by jmcneill

add power management support

branches: 1.12.2; 1.12.4; 1.12.6;
Split device_t/softc.

branches: 1.11.6;
Fix the BARs on nForce 430, which failed to attach. Reported by
atsushi fukumoto in PR kern/37756.

branches: 1.10.4;
Newer nForce MCP SMBus devices use different PCI BARs than the old ones
(nForce 2/3/4).

nfsmb(4) is now properly working on newer MCPs, tested by wiz@ on MCP55:

nfsmbc0 at pci0 dev 1 function 1: NVIDIA nForce MCP55 SMBus Controller (rev. 0xa2)
nfsmb0 at nfsmbc0 SMBus 1
iic0 at nfsmb0: I2C bus
spdmem0 at iic0 addr 0x51
spdmem0: DDR2 SDRAM memory, data ECC, 1024MB, 667MHz, PC2-5300
spdmem0: 14 rows, 10 cols, 2 ranks, 4 banks/chip, 3.00ns cycle time
spdmem0: voltage SSTL 1.8V, refresh time 7.8us (self-refreshing)
nfsmb1 at nfsmbc0 SMBus 2
iic1 at nfsmb1: I2C bus

branches: 1.9.2;
Attach to NVIDIA MCP73 now that we have the PCI id.

Attach to more NVIDIA SMBus controllers.

branches: 1.7.2;
machine/{bus,cpu,intr}.h -> sys/{bus,cpu,intr}.h

branches: 1.6.2; 1.6.6;
For SMBus, add the ability to enumerate devices on the bus.
This does NOT identify the devices, merely indicates the
presence of devices at certain addresses. Tested on ichsmb
and nfsmb - other SMBus devices will need to ensure the
proper bus type is set. (I2C_TYPE_SMBUS)

From Nicolas Joly, via Paul Goyette, in PR#36744.

branches: 1.5.2;
Use rwlock(9) rather than lockmgr(9).

Remove and insert null-line.
No parentheses are needed around the return value.

branches: 1.3.4; 1.3.6;
s/uint32_t reg/pcireg_t reg/.
Check condition `!= 0'.

We wait for the clearness of the NFORCE_SMB_PROTOCOL as transfer completion.
And, the maximum is assumed to be 10msec. I think that the thing for which
it waits any further is dangerous for the system.

branches: 1.1.2; 1.1.4; 1.1.6;
Add support for NVIDIA nForce 2/3/4 SMBus controller and SMBus driver.