src/sys/dev/advansys, branch releng/10.2

MFC r280347: Remove MAXBSIZE use from drivers where it has nothing to do.

2015-04-21T11:27:50Z

In some cases limits are just not needed, in others -- DFLTPHYS is the right constant to use instead.

MFC r274819:

2014-12-21T03:06:11Z

Prevent overflow issues in timeout processing MFC r274852: Fix build with asr driver Sponsored by: Multiplay

MFC r259825:

2013-12-28T00:16:58Z

Remove unused static function adwccbstatus() from adw(4). Reviewed by: gibbs

Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCI

2013-08-12T23:30:01Z

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, achadd, achim MFC after: 1 day

Reform the busdma API so that new types may be added without modifying

2013-02-12T16:57:20Z

every architecture's busdma_machdep.c. It is done by unifying the bus_dmamap_load_buffer() routines so that they may be called from MI code. The MD busdma is then given a chance to do any final processing in the complete() callback. The cam changes unify the bus_dmamap_load* handling in cam drivers. The arm and mips implementations are updated to track virtual addresses for sync(). Previously this was done in a type specific way. Now it is done in a generic way by recording the list of virtuals in the map. Submitted by: jeff (sponsored by EMC/Isilon) Reviewed by: kan (previous version), scottl, mjacob (isp(4), no objections for target mode changes) Discussed with: ian (arm changes) Tested by: marius (sparc64), mips (jmallet), isci(4) on x86 (jharris), amd64 (Fabian Keil )

Add locking to the adw(4) driver and mark it MPSAFE.

2012-10-15T15:26:00Z

- Use device_printf() and device_get_nameunit() instead of adw_name(). - Remove use of explicit bus space handles and tags. - Use pci_enable_busmaster() rather than frobbing the PCI command register directly. - Use the softc provided by new-bus rather than allocating a new one. Tested by: no one

Add locking to adv(4) driver and mark it MPSAFE.

2012-10-12T21:31:44Z

- Disable the support for the second channel on twin-channel EISA cards as the current incarnation can't possibly work correctly (it hasn't worked since switching to new-bus where new-bus allocates the softc). If anyone bothers to test this again it can be fixed properly and brought back. - Use device_printf() and device_get_nameunit() instead of adv_name(). - Remove use of explicit bus space handles and tags. - Use PCI bus accessors and helper routines rather than accessing config registers directly. - Handle failures from adv_attach(). Tested by: no one (hope it works)

Final pass at having devices use their bus parent for dma tags. The

2012-03-12T19:29:35Z

remaining drivers that haven't been converted have various problems or complexities that will be dealt with later. This list includes: hptrr, hptmv, hpt27xx - device aggregation across multiple parents drm - want to talk to the maintainer first tsec, sec - Openfirmware devices, not sure if changes are warranted fatm - Done except for unused testing code usb - want to talk to the maintainer first ce, cp, ctau, cx - Significant driver changes needed to convey parent info There are also devices tucked into architecture subtrees that I'll leave for the respective maintainers to deal with.

Remove comments about creating DMA tags as children of the DMA tags of their

2012-03-12T19:29:32Z

parent bus where the code has now been modified to do so. Reviewed by: scottl

Convert a number of drivers to obtaining their parent DMA tag from their

2012-03-12T08:03:51Z

PCI device attachment.