summaryrefslogtreecommitdiffstats
path: root/sys/dev/aac
Commit message (Collapse)AuthorAgeFilesLines
* MFC r311305 (by asomers):mav2017-03-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Always null-terminate ccb_pathinq.(sim_vid|hba_vid|dev_name) The sim_vid, hba_vid, and dev_name fields of struct ccb_pathinq are fixed-length strings. AFAICT the only place they're read is in sbin/camcontrol/camcontrol.c, which assumes they'll be null-terminated. However, the kernel doesn't null-terminate them. A bunch of copy-pasted code uses strncpy to write them, and doesn't guarantee null-termination. For at least 4 drivers (mpr, mps, ciss, and hyperv), the hba_vid field actually overflows. You can see the result by doing "camcontrol negotiate da0 -v". This change null-terminates those fields everywhere they're set in the kernel. It also shortens a few strings to ensure they'll fit within the 16-character field. PR: 215474 Reported by: Coverity CID: 1009997 1010000 1010001 1010002 1010003 1010004 1010005 CID: 1331519 1010006 1215097 1010007 1288967 1010008 1306000 CID: 1211924 1010009 1010010 1010011 1010012 1010013 1010014 CID: 1147190 1010017 1010016 1010018 1216435 1010020 1010021 CID: 1010022 1009666 1018185 1010023 1010025 1010026 1010027 CID: 1010028 1010029 1010030 1010031 1010033 1018186 1018187 CID: 1010035 1010036 1010042 1010041 1010040 1010039
* sys/dev: minor spelling fixes.pfg2016-05-034-5/+5
| | | | Most affect comments, very few have user-visible effects.
* aacraid(4): Sanely copyin userland pointers and ensure that we don't getsbruno2016-04-191-4/+16
| | | | | | | | | | | | anything janky from a user. (cturt) aac(4): landergriffith+freebsdbugzilla@gmail.com pointed out that aacraid(4) had the same issue and handling of pointers, so let's change that too. PR: 206573 Submitted by: cturt@hardenedbsd.org Obtained from: HardenedBSD MFC after: 1 week
* Cleanup unnecessary semicolons from the kernel.pfg2016-04-101-1/+1
| | | | Found with devel/coccinelle.
* Remove taskqueue_enqueue_fast().jhb2016-03-011-1/+1
| | | | | | | | | | taskqueue_enqueue() was changed to support both fast and non-fast taskqueues 10 years ago in r154167. It has been a compat shim ever since. It's time for the compat shim to go. Submitted by: Howard Su <howard0su@gmail.com> Reviewed by: sephe Differential Revision: https://reviews.freebsd.org/D5131
* Migrate many bus_alloc_resource() calls to bus_alloc_resource_anywhere().jhibbits2016-02-271-2/+2
| | | | | | | | Most calls to bus_alloc_resource() use "anywhere" as the range, with a given count. Migrate these to use the new bus_alloc_resource_anywhere() API. Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D5370
* Remove MAXBSIZE use from drivers where it has nothing to do.mav2015-03-221-2/+2
| | | | | | | In some cases limits are just not needed, in others -- DFLTPHYS is the right constant to use instead. MFC after: 1 month
* Pull in r267961 and r267973 again. Fix for issues reported will follow.hselasky2014-06-281-1/+0
|
* Revert r267961, r267973:gjb2014-06-271-0/+1
| | | | | | | | | | These changes prevent sysctl(8) from returning proper output, such as: 1) no output from sysctl(8) 2) erroneously returning ENOMEM with tools like truss(1) or uname(1) truss: can not get etype: Cannot allocate memory
* Extend the meaning of the CTLFLAG_TUN flag to automatically check ifhselasky2014-06-271-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | there is an environment variable which shall initialize the SYSCTL during early boot. This works for all SYSCTL types both statically and dynamically created ones, except for the SYSCTL NODE type and SYSCTLs which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to be used in the case a tunable sysctl has a custom initialisation function allowing the sysctl to still be marked as a tunable. The kernel SYSCTL API is mostly the same, with a few exceptions for some special operations like iterating childrens of a static/extern SYSCTL node. This operation should probably be made into a factored out common macro, hence some device drivers use this. The reason for changing the SYSCTL API was the need for a SYSCTL parent OID pointer and not only the SYSCTL parent OID list pointer in order to quickly generate the sysctl path. The motivation behind this patch is to avoid parameter loading cludges inside the OFED driver subsystem. Instead of adding special code to the OFED driver subsystem to post-load tunables into dynamically created sysctls, we generalize this in the kernel. Other changes: - Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask" to "hw.pcic.intr_mask". - Removed redundant TUNABLE statements throughout the kernel. - Some minor code rewrites in connection to removing not needed TUNABLE statements. - Added a missing SYSCTL_DECL(). - Wrapped two very long lines. - Avoid malloc()/free() inside sysctl string handling, in case it is called to initialize a sysctl from a tunable, hence malloc()/free() is not ready when sysctls from the sysctl dataset are registered. - Bumped FreeBSD version to indicate SYSCTL API change. MFC after: 2 weeks Sponsored by: Mellanox Technologies
* Clear the data buffer length field when freeing a command structure so thatjhb2014-05-171-0/+1
| | | | | | | | | it doesn't leak through when the command structure is reused for a user command without a data buffer. PR: amd64/189668 Tested by: Pete Long <pete@nrth.org> MFC after: 1 week
* Update kernel inclusions of capability.h to use capsicum.h instead; somerwatson2014-03-161-1/+1
| | | | | | | | further refinement is required as some device drivers intended to be portable over FreeBSD versions rely on __FreeBSD_version to decide whether to include capability.h. MFC after: 3 weeks
* Free the MSI again on detach if allocated. Arguably, this code would bemarius2013-12-291-1/+3
| | | | | | | 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 MFC after: 3 days
* Fix undefined behavior: (1 << 31) is not defined as 1 is an int and thiseadler2013-11-301-1/+1
| | | | | | | | | | | | | shifts into the sign bit. Instead use (1U << 31) which gets the expected result. This fix is not ideal as it assumes a 32 bit int, but does fix the issue for most cases. A similar change was made in OpenBSD. Discussed with: -arch, rdivacky Reviewed by: cperciva
* Change the cap_rights_t type from uint64_t to a structure that we can extendpjd2013-09-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the future in a backward compatible (API and ABI) way. The cap_rights_t represents capability rights. We used to use one bit to represent one right, but we are running out of spare bits. Currently the new structure provides place for 114 rights (so 50 more than the previous cap_rights_t), but it is possible to grow the structure to hold at least 285 rights, although we can make it even larger if 285 rights won't be enough. The structure definition looks like this: struct cap_rights { uint64_t cr_rights[CAP_RIGHTS_VERSION + 2]; }; The initial CAP_RIGHTS_VERSION is 0. The top two bits in the first element of the cr_rights[] array contain total number of elements in the array - 2. This means if those two bits are equal to 0, we have 2 array elements. The top two bits in all remaining array elements should be 0. The next five bits in all array elements contain array index. Only one bit is used and bit position in this five-bits range defines array index. This means there can be at most five array elements in the future. To define new right the CAPRIGHT() macro must be used. The macro takes two arguments - an array index and a bit to set, eg. #define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL) We still support aliases that combine few rights, but the rights have to belong to the same array element, eg: #define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL) #define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL) #define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP) There is new API to manage the new cap_rights_t structure: cap_rights_t *cap_rights_init(cap_rights_t *rights, ...); void cap_rights_set(cap_rights_t *rights, ...); void cap_rights_clear(cap_rights_t *rights, ...); bool cap_rights_is_set(const cap_rights_t *rights, ...); bool cap_rights_is_valid(const cap_rights_t *rights); void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src); void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src); bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little); Capability rights to the cap_rights_init(), cap_rights_set(), cap_rights_clear() and cap_rights_is_set() functions are provided by separating them with commas, eg: cap_rights_t rights; cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT); There is no need to terminate the list of rights, as those functions are actually macros that take care of the termination, eg: #define cap_rights_set(rights, ...) \ __cap_rights_set((rights), __VA_ARGS__, 0ULL) void __cap_rights_set(cap_rights_t *rights, ...); Thanks to using one bit as an array index we can assert in those functions that there are no two rights belonging to different array elements provided together. For example this is illegal and will be detected, because CAP_LOOKUP belongs to element 0 and CAP_PDKILL to element 1: cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL); Providing several rights that belongs to the same array's element this way is correct, but is not advised. It should only be used for aliases definition. This commit also breaks compatibility with some existing Capsicum system calls, but I see no other way to do that. This should be fine as Capsicum is still experimental and this change is not going to 9.x. Sponsored by: The FreeBSD Foundation
* - Fix a bug in the MSI allocation logic so an MSI is also employed if amarius2013-08-061-21/+7
| | | | | | | | | | | 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). MFC after: 1 month
* As it turns out, MSIs are broken with 2820SA so introduce an AAC_FLAGS_NOMSImarius2013-08-062-40/+41
| | | | | | | | | | | | | | | | | 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 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] MFC after: 3 days
* Allow unmapped I/O via aacd(4). It shouldn't be too hard to add themarius2013-05-303-6/+13
| | | | | same support for aacp(4), I'm lacking the necessary hardware for testing, though.
* - Remove pointless returns.marius2013-05-304-20/+3
| | | | | | - Make cm_data a void pointer and cm_flags unsigned as appropriate. MFC after: 3 days
* MFprojects/camlock r248982:mav2013-04-141-1/+1
| | | | | | | | 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.
* Initialize count in order to appease clang.marius2013-03-011-0/+1
| | | | Submitted by: delphij
* - Make tables, device ID strings etc const. This includes #ifdef'ing 0marius2013-03-016-112/+110
| | | | | | | | | | | | | | | | | | | 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). MFC after: 1 month
* Reform the busdma API so that new types may be added without modifyingkib2013-02-121-19/+21
| | | | | | | | | | | | | | | | | | | | | 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 <freebsd-listen@fabiankeil.de>)
* Give panic format string to pacify clang warning.rdivacky2012-11-091-1/+1
|
* Some aac(4) adapters will always report that a direct access device isrstone2012-09-251-27/+48
| | | | | | | | | | | | | | | | | | offline in response to a INQUIRY command that does not retreive vital product data(I personally have observed the behaviour on an Adaptec 2405 and a 5805). Force the peripheral qualifier to "connected" so that upper layers correctly recognize that a disk is present. This bug was uncovered by r216236. Prior to that fix, aac(4) was accidentally clearing the peripheral qualifier for all inquiry commands. This fixes an issue where passthrough devices were not created for disks behind aac(4) controllers suffering from the bug. I have verified that if a disk is not present that we still properly detect that and not create the passthrough device. Sponsored by: Sandvine Incorporated MFC after: 1 week
* On BIO_ERROR, set bio_resid to stop losing data in the error case.sbruno2012-07-181-1/+3
| | | | | | Submitted by: Mark Johnston <markjdb@gmail.com> Reviewed by: scottl@freebsd.org MFC after: 2 weeks
* Remove variables which are initialized but never used thereaftereadler2012-07-071-3/+0
| | | | | | | reported by gcc46 warning Approved by: cperciva MFC after: 1 week
* Use bus_get_dma_tag() to inherit the PCI bus' 4G boundary constraint.jhb2012-03-071-1/+1
| | | | Tested by: emaste
* Revert r232260.emaste2012-02-281-2/+1
| | | | The problem is now fixed by a general workaround in r232267.
* Avoid transfers crossing a 4GB boundary, which can lead to dataemaste2012-02-281-1/+2
| | | | | | | | | | corruption. Thanks to scottl@ for the suggestion. This change will likely be revised after consideration of a general method to address this type of issue for other drivers. Sponsored by: Sandvine Incorporated MFC after: 3 days
* Add a sysctl to report the firmware build number.emaste2012-02-131-0/+9
| | | | | | | Some older firmware versions have issues that can be worked around by avoiding certain operations. Add a sysctl dev.aac.#.firmware_build to make it easy for scripts or userland tools to detect the firmware version.
* - There's no need to overwrite the default device method with the defaultmarius2011-11-221-3/+1
| | | | | | | | | | one. Interestingly, these are actually the default for quite some time (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9) since r52045) but even recently added device drivers do this unnecessarily. Discussed with: jhb, marcel - While at it, use DEVMETHOD_END. Discussed with: jhb - Also while at it, use __FBSDID.
* Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.ed2011-11-071-1/+1
| | | | | | The SYSCTL_NODE macro defines a list that stores all child-elements of that node. If there's no SYSCTL_DECL macro anywhere else, there's no reason why it shouldn't be static.
* Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs.ed2011-11-072-2/+2
| | | | This means that their use is restricted to a single C file.
* Merge from r225950:marius2011-10-131-9/+11
| | | | | | Set the sense residual properly. Reviewed by: ken
* Second-to-last commit implementing Capsicum capabilities in the FreeBSDrwatson2011-08-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | kernel for FreeBSD 9.0: Add a new capability mask argument to fget(9) and friends, allowing system call code to declare what capabilities are required when an integer file descriptor is converted into an in-kernel struct file *. With options CAPABILITIES compiled into the kernel, this enforces capability protection; without, this change is effectively a no-op. Some cases require special handling, such as mmap(2), which must preserve information about the maximum rights at the time of mapping in the memory map so that they can later be enforced in mprotect(2) -- this is done by narrowing the rights in the existing max_protection field used for similar purposes with file permissions. In namei(9), we assert that the code is not reached from within capability mode, as we're not yet ready to enforce namespace capabilities there. This will follow in a later commit. Update two capability names: CAP_EVENT and CAP_KEVENT become CAP_POST_KEVENT and CAP_POLL_KEVENT to more accurately indicate what they represent. Approved by: re (bz) Submitted by: jonathan Sponsored by: Google Inc
* - Fix races on detach handling of AAC_IFFLAGS_* maskattilio2011-06-102-14/+16
| | | | | | | | | | | | - Fix races on setting AAC_AIFFLAGS_ALLOCFIBS - Remove some unused AAC_IFFLAGS_* bits. Please note that the kthread still makes a difference between the total mask and AAC_AIFFLAGS_ALLOCFIBS because more flags may be added in the future to aifflags. Sponsored by: Sandvine Incorporated Reported and reviewed by: emaste MFC after: 2 weeks
* We can pass a format string and args to panic(), so instead of usingemaste2011-02-041-14/+8
| | | | | | | | printf() to output some information before a panic, just include that information in the panic. Submitted by: bde Reviewed by: bde
* Include driver name in panic string, to make it easier to find these shouldemaste2011-02-031-4/+4
| | | | the panic ever occur.
* Revert part of r173264. Both aac_ioctl_sendfib and aac_ioctl_send_raw_srbemaste2011-02-031-5/+1
| | | | | | | | | | make use of the aac_ioctl_event callback, if aac_alloc_command fails. This can end up in an infinite loop in the while loop in aac_release_command. Further investigation into the issue mentioned by Scott Long [1] will be necessary. [1] http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078740.html
* When masking direct and processor devices during an inquiry, properlyjhb2010-12-061-1/+2
| | | | | | | preserve the upper bits of the first data byte. Reviewed by: scottl MFC after: 1 week
* Previously, the aac driver did not handle enclosure management AIFs,emaste2010-09-294-0/+80
| | | | | | | which were raised during hot-swap events. Now such events trigger cam rescans, as is done in the mps driver. Submitted by: Mark Johnston <mjohnston at sandvine dot com>
* Use device_printf where possible, and otherwise at least include theemaste2010-09-163-7/+10
| | | | | | driver name in printf strings. Reported by: Mark Johnston
* Implement device unbusying via a cdevpriv destructor.attilio2010-09-161-15/+18
| | | | | | | | Suggested by: jhb Tested by: Mark Johnston <mjohnston at sandvine dot com> Reviewed by: emaste, jhb MFC after: 10 days X-MFC: r212661
* Fix bogus busying mechanism from cdevsw callbacks:attilio2010-09-152-12/+4
| | | | | | | | | | | | | | - D_TRACKCLOSE may be used there as d_close() are expected to match up d_open() calls - Replace the hand-crafted counter and flag with the device_busy()/device_unbusy() proper usage. Sponsored by: Sandvine Incorporated Reported by: Mark Johnston <mjohnston at sandvine dot com> Tested by: Mark Johnston Reviewed by: emaste MFC after: 10 days
* Add some enums and constants from Adaptec's latest driveremaste2010-09-151-1/+14
| | | | (build 17911).
* Avoid repeatedly spamming the console while a timed out command is waitingemaste2010-09-141-1/+6
| | | | | | | to complete. Instead, print one message after the timeout period expires, and one more when (if) the command eventually completes. MFC after: 1 month
* Use enums in the aac_command_status_table rather than duplicating the sameemaste2010-04-131-36/+36
| | | | | | values in two places. Suggested by: Garrett Cooper
* Sync some minor items with the upstream driver. Should have no functionalemaste2010-04-134-4/+8
| | | | change.
* Whitespace cleanup, in advance of next sync with Adaptec's driver. Noemaste2010-04-137-102/+102
| | | | functional change.
OpenPOWER on IntegriCloud