src/sys/dev/bktr, branch release/8.1.0

MFC revision 205781:

2010-04-14T16:37:34Z

Use standard types in preference to BSD types so that these header files can be used in applications compiled with only POSIX types visible.

MFC a number of changes from head for ISP (203478,203463,203444,202418,201758,

2010-02-11T18:34:06Z

201408,201325,200089,198822,197373,197372,197214,196162). Since one of those changes was a semicolon cleanup from somebody else, this touches a lot more.

MFC 196403: Temporarily revert the new-bus locking for 8.0 release.

2009-08-20T20:23:28Z

Approved by: re (kib)

Make the newbus subsystem Giant free by adding the new newbus sxlock.

2009-08-02T14:28:40Z

The newbus lock is responsible for protecting newbus internIal structures, device states and devclass flags. It is necessary to hold it when all such datas are accessed. For the other operations, softc locking should ensure enough protection to avoid races. Newbus lock is automatically held when virtual operations on the device and bus are invoked when loading the driver or when the suspend/resume take place. For other 'spourious' operations trying to access/modify the newbus topology, newbus lock needs to be automatically acquired and dropped. For the moment Giant is also acquired in some key point (modules subsystem) in order to avoid problems before the 8.0 release as module handlers could make assumptions about it. This Giant locking should go just after the release happens. Please keep in mind that the public interface can be expanded in order to provide more support, if there are really necessities at some point and also some bugs could arise as long as the patch needs a bit of further testing. Bump __FreeBSD_version in order to reflect the newbus lock introduction. Reviewed by: ed, hps, jhb, imp, mav, scottl No answer by: ariff, thompsa, yongari Tested by: pho, G. Trematerra , Brandon Gooch Sponsored by: Yahoo! Incorporated Approved by: re (ksmith)

Unbreak bktr(4).

2009-05-26T12:01:37Z

Free the memory correctly in the error case

2009-05-26T03:56:56Z

Submitted by: frtzkatz at yahoo.com Approved by: sam MFC after: 1 month

Replace all calls to minor() with dev2unit().

2008-09-27T08:51:18Z

After I removed all the unit2minor()/minor2unit() calls from the kernel yesterday, I realised calling minor() everywhere is quite confusing. Character devices now only have the ability to store a unit number, not a minor number. Remove the confusion by using dev2unit() everywhere. This commit could also be considered as a bug fix. A lot of drivers call minor(), while they should actually be calling dev2unit(). In -CURRENT this isn't a problem, but it turns out we never had any problem reports related to that issue in the past. I suspect not many people connect more than 256 pieces of the same hardware. Reviewed by: kib

Add locking to the various iicbus(4) bridge drivers:

2008-08-04T20:46:15Z

- Just grab Giant in the ixp425_iic(4) driver since this driver uses a shared address/data register window pair to access the actual I2C registers. None of the other ixp425 drivers lock access to these shared address/data registers yet and that would need to be done before this could use any meaningful locking. - Add locking to the interrupt handler and 'iicbus_reset' methods of the at91_twi(4) driver. - Add locking to the pcf(4) driver. Other pcf(4) fixes include: - Don't needlessly zero the softc. - Use bus_foo rather than bus_space_foo and remove bus space tag and handle from softc. - The lpbb(4) driver just grabs Giant for now. This will be refined later when ppbus(4) is locked. - As was done with smbus earlier, move the DRIVER_MODULE() lines to match the bus driver (either iicbus or iicbb) to the bridge driver into the bridge drivers. Tested by: sam (arm/ixp425)

Explicitly lock Giant in smbus_if methods in the bktr_i2c and iicsmb

2008-06-06T18:40:38Z

drivers for now. This can be replaced with driver locks when these drivers are locked.

Rename the kthread_xxx (e.g. kthread_create()) calls

2007-10-20T23:23:23Z

to kproc_xxx as they actually make whole processes. Thos makes way for us to add REAL kthread_create() and friends that actually make theads. it turns out that most of these calls actually end up being moved back to the thread version when it's added. but we need to make this cosmetic change first. I'd LOVE to do this rename in 7.0 so that we can eventually MFC the new kthread_xxx() calls.