src/sys/dev/aac, branch release/10.1.0

MFC 266281:

2014-06-04T18:21:33Z

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

MFC: r260044

2014-04-25T21:24:33Z

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

MFC r258779,r258780,r258787,r258822:

2014-02-04T03:36:42Z

Fix undefined behavior: (1 << 31) is not defined as 1 is an int and this shifts into the sign bit. Instead use (1U << 31) which gets the expected result. Similar to the (1 << 31) case it is not defined to do (2 << 30). 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.

Change the cap_rights_t type from uint64_t to a structure that we can extend

2013-09-05T00:09:56Z

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 a

2013-08-06T19:14:02Z

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_NOMSI

2013-08-06T18:55:59Z

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 the

2013-05-30T00:22:07Z

same support for aacp(4), I'm lacking the necessary hardware for testing, though.

- Remove pointless returns.

2013-05-30T00:11:22Z

- Make cm_data a void pointer and cm_flags unsigned as appropriate. MFC after: 3 days

MFprojects/camlock r248982:

2013-04-14T09:55:48Z

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.

2013-03-01T22:09:08Z

Submitted by: delphij