src-test2/sys/dev/rp, branch release/9.2.0

Merge r254306:

2013-08-15T12:19:16Z

Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCI command register. The lazy BAR allocation code in FreeBSD sometimes disables this bit when it detects a range conflict, and will re-enable it on demand when a driver allocates the BAR. Thus, the bit is no longer a reliable indication of capability, and should not be checked. This results in the elimination of a lot of code from drivers, and also gives the opportunity to simplify a lot of drivers to use a helper API to set the busmaster enable bit. This changes fixes some recent reports of disk controllers and their associated drives/enclosures disappearing during boot. Submitted by: jhb Reviewed by: jfv, marius, adrian, achim Approved by: re

These checks against BUSY aren't needed: the newbus layer does this

2009-09-05T08:38:25Z

already with the appropriate locks held... There's no need to do it here, so just delete the checks.

Temporarily revert the new-bus locking for 8.0 release. It will be

2009-08-20T19:17:53Z

reintroduced after HEAD is reopened for commits by re@. Approved by: re (kib), attilio

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)

Last minute TTY API change: remove mutex argument from tty_alloc().

2009-05-29T06:41:23Z

I don't want people to override the mutex when allocating a TTY. It has to be there, to keep drivers like syscons happy. So I'm creating a tty_alloc_mutex() which can be used in those cases. tty_alloc_mutex() should eventually be removed. The advantage of this approach, is that we can just remove a function, without breaking the regular API in the future.

Start to convert this over to the new tty layer. These changes allow

2009-04-27T15:58:38Z

this driver to compile and limp along with the new layer. These changes do not deal with proper locking around access to the HW. This is only a starting point. I have not tested modem control but tip seems to work okay and I can send and receive characters which I needed for one of my -current boxes. I have not tied this driver back up to the build since I don't want people to think it is ready for prime time. If anyone else has some cycles to work on this feel free to! Also add support for a 16 port PCI interface I have at work. Glanced at by: ed

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

Initialize DWBuf[3].

2007-07-05T06:51:49Z

Approved by: re (rwatson, blanket)

Fix Rocketport so that it does not crash the system when a device pointer

2007-06-26T13:50:48Z

changes for example: (From Craig Leres): tip to a rocketport line run "/etc/rc.d/devfs restart" exit tip (wait for the system to reboot) Thanks to Robert Watson for poking me to fix this. PR: kern/109152 Approved by: imp (mentor) Approved by: re (kensmith) Reviewed by: jhb Submitted by: Craig Leres

- Make rp(4) 64-bit- and endian-clean as well as work on strict alignment

2006-11-20T12:59:27Z

archs. [1] - Instead of bus_space_{read,write}*(rman_get_bustag(), rman_get_bushandle()) use bus_{read,write}*() for efficiency. Reported by: Peter Losher [1] Tested on: i386, sparc64 MFC after: 2 weeks