FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F9.3.0 2014-06-04T18:32:41Z 2014-06-04T18:32:41Z John Baldwin jhb@FreeBSD.org 2014-06-04T18:32:41Z urn:sha1:368d87fb6724e26b80d7ee24cc3e3d868de0ca7d Clear the data buffer length field when freeing a command structure so that it doesn't leak through when the command structure is reused for a user command without a data buffer. PR: 189668 Approved by: re (delphij) 2014-04-25T21:24:53Z Marius Strobl marius@FreeBSD.org 2014-04-25T21:24:53Z urn:sha1:5875684a048d0cef2d0c6652d6174f96eefa7293 Free the MSI again on detach if allocated. Arguably, this code would be better off living in aac_pci.c, but it doesn't seem worth creating a aac_pci_detach() and it's also not the first PCI-specific bit in aac.c 2013-09-26T09:16:57Z Marius Strobl marius@FreeBSD.org 2013-09-26T09:16:57Z urn:sha1:5a8a1c7806279f37efe261196d190627956395f0 - Fix a bug in the MSI allocation logic so an MSI is also employed if a controller supports only a single message. I haven't seen such an adapter out in the wild, though, so this change likely is a NOP. While at it, further simplify the MSI allocation logic; there's no need to check the number of available messages on our own as pci_alloc_msi(9) will just fail if it can't provide us with the single message we want. - Nuke the unused softc of aacch(4). 2013-08-09T18:54:27Z Marius Strobl marius@FreeBSD.org 2013-08-09T18:54:27Z urn:sha1:30dae4bff7abaad4c54290108a4e3aa0eeb38ae2 As it turns out, MSIs are broken with 2820SA so introduce an AAC_FLAGS_NOMSI quirk and apply it to these controllers [1]. The same problem was reported for 2230S, in which case it wasn't actually clear whether the culprit is the controller or the mainboard, though. In order to be on the safe side, flag MSIs as being broken with the latter type of controller as well. Given that these are the only reports of MSI-related breakage with aac(4) so far and OSes like OpenSolaris unconditionally employ MSIs for all adapters of this family, however, it doesn't seem warranted to generally disable the use of MSIs in aac(4). While at it, simplify the MSI allocation logic a bit; there's no need to check for the presence of the MSI capability on our own as pci_alloc_msi(9) will just fail when these kind of interrupts are not available. Reported and tested by: David Boyd [1] 2013-07-08T15:54:38Z Alexander Motin mav@FreeBSD.org 2013-07-08T15:54:38Z urn:sha1:3e4e5885166ea909e8b4fb152427c50e5d311a22 Stop abusing xpt_periph in random plases that really have no periph related to CCB, for example, bus scanning. NULL value is fine in such cases and it is correctly logged in debug messages as "noperiph". If at some point we need some real XPT periphs (alike to pmpX now), quite likely they will be per-bus, and not a single global instance as xpt_periph now. 2013-06-18T15:02:53Z Marius Strobl marius@FreeBSD.org 2013-06-18T15:02:53Z urn:sha1:4c1234dd1507dbef24bf1c4be5de8a167329b257 Give panic format string to pacify clang warning. 2013-06-18T14:40:21Z Marius Strobl marius@FreeBSD.org 2013-06-18T14:40:21Z urn:sha1:6b971bf18c0259112b8fb07a5e36740f00b28312 Allow unmapped I/O via aacd(4). It shouldn't be too hard to add the same support for aacp(4), I'm lacking the necessary hardware for testing, though. 2013-06-18T00:36:53Z Scott Long scottl@FreeBSD.org 2013-06-18T00:36:53Z urn:sha1:039e422c063977ba9073fd2c93883dd8a5a36d48 have been in production at Netflix for several months with significant success. MFC r246713: Reform the busdma API so that new types may be added without modifying 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. MFC r249538: Some compilers issue a warning when wider integer is casted to narrow pointer. Supposedly shut down the warning by casting through uintptr_t. MFC r251479: Simplify the checking of flags for cam_periph_mapmem(). This gets rid of a lot of code redundancy and grossness at very minor expense. MFC r251837: MFC r251842: Add infrastructure for doing compatibility shims, as has been sorely needed for the last 10 years. Far too much of the internal API is exposed, and every small adjustment causes applications to stop working. To kick this off, bump the API version to 0x17 as should have been done with r246713, but add shims to compensate. Thanks to the shims, there should be no visible change in application behavior. Submitted by: kib, jeffr Approved by: kib Obtained from: Netflix 2013-06-09T12:46:41Z Marius Strobl marius@FreeBSD.org 2013-06-09T12:46:41Z urn:sha1:e67db56db92603fbef7f9d7a588a7320e78681de - Remove pointless returns. - Make cm_data a void pointer and cm_flags unsigned as appropriate. 2013-05-28T20:58:57Z Marius Strobl marius@FreeBSD.org 2013-05-28T20:58:57Z urn:sha1:f3b314829f8fdb1f61417e098b56dcf1dd03b576 - Make tables, device ID strings etc const. This includes #ifdef'ing 0 aac_command_status_table, which is actually unused since r111532. While at it, make aac_if a pointer to the now const interface tables instead of copying them over to the softc (this alone already reduces the size of aac.ko on amd64 by ~1 KiB). - Remove redundant softc members. - Use DEVMETHOD_END. - Use NULL instead of 0 for pointers. - Remove redundant bzero(9)'ing of the softc. - Use pci_enable_busmaster(9) instead of duplicating it. - Remove redundant checking for PCIM_CMD_MEMEN (resource allocation will just fail). - Canonicalize the error messages in case of resource allocation failures. - Add support for using MSI instead of INTx, controllable via the tunable hw.aac.enable_msi (defaulting to on).