summaryrefslogtreecommitdiffstats
path: root/sys/dev/amr
Commit message (Collapse)AuthorAgeFilesLines
* MFC r280347: Remove MAXBSIZE use from drivers where it has nothing to do.mav2015-04-211-5/+8
| | | | | In some cases limits are just not needed, in others -- DFLTPHYS is the right constant to use instead.
* Merge r263233 from HEAD to stable/10:rwatson2015-03-191-1/+1
| | | | | | | | | Update kernel inclusions of capability.h to use capsicum.h instead; some 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. Sponsored by: Google, Inc.
* 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
* Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCIscottl2013-08-121-22/+1
| | | | | | | | | | | | | | | | | 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 modifyingkib2013-02-121-4/+1
| | | | | | | | | | | | | | | | | | | | | 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>)
* Further adjust the workaround in r234501. Rounding all small requests upjhb2012-10-051-2/+8
| | | | | | | | | | | | | to 32k swamped the controller causing firmware hangs. Instead, round requests smaller than 64k up to the next power of 2 as a general rule. To handle the one known special case of a command that accepts a 12k buffer returning a 24k-ish reply, round requests between 8k and 16k up to 32k rather than 16k. The result is that commands less than 8k should now be rounded up to a smaller size (either 4k or 8k) rather than 32k. PR: kern/155658 Tested by: Andreas Longwitz MFC after: 1 week
* As a followup to r234501, ensure that the native ioctl path always allocatesjhb2012-09-191-6/+2
| | | | | | | | | a 4kb buffer if a request uses a buffer size of 0. (The Linux ioctl path already did this.) PR: kern/155658 Submitted by: Andreas Longwitz MFC after: 1 week
* Essentially revert r239912. The amr_periodic function hadn't been armed inscottl2012-08-313-40/+0
| | | | | over 10 years and was dead code; the previous revision exposed it as such to CLANG. The solution is to cull the whole thing.
* Use callout(9) rather than timeout(9). Note that the periodic timer injhb2012-08-303-4/+5
| | | | | amr(4) is never started, so this should be even more of a NOP than normal.
* The amr(4) firmware contains a rather dubious "feature" where itjhb2012-04-201-14/+31
| | | | | | | | | | | | | | | | | assumes for small buffers (< 64k) that the OS driver is actually using a buffer rounded up to the next power of 2. It also assumes that the buffer is at least 4k in size. Furthermore, there is at least one known instance of megarc sending a request with a 12k buffer where the firmware writes out a 24k-ish reply. To workaround the data corruption triggered by this "feature", ensure that buffers for user commands use a minimum size of 32k, and that buffers between 32k and 64k use a 64k buffer. PR: kern/155658 Submitted by: Andreas Longwitz longwitz incore de Reviewed by: scottl MFC after: 1 week
* Convert a number of drivers to obtaining their parent DMA tag from theirscottl2012-03-121-1/+1
| | | | PCI device attachment.
* Fix checks for error return from amr_sglist_map() and amr_ccb_map()kevlo2012-02-281-2/+2
|
* - 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 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.
* 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 clang warning on empty statement.mdf2010-07-281-2/+2
| | | | | Reviewed by: rdivacky, zml Approved by: zml (mentor)
* Remove extraneous semicolons, no functional changes.mbr2010-01-071-1/+1
| | | | | Submitted by: Marc Balmer <marc@msys.ch> MFC after: 1 week
* Remove spurious `)`brueffer2009-10-281-1/+1
| | | | | | PR: 137758 Submitted by: Henning Petersen <henning.petersen@t-online.de> MFC after: 1 week
* Revert previous commit and add myself to the list of people who shouldphk2009-09-081-1/+1
| | | | know better than to commit with a cat in the area.
* Add necessary include.phk2009-09-081-1/+1
|
* Temporarily revert the new-bus locking for 8.0 release. It will bejhb2009-08-201-21/+2
| | | | | | 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.attilio2009-08-021-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <giovanni dot trematerra at gmail dot com>, Brandon Gooch <jamesbrandongooch at gmail dot com> Sponsored by: Yahoo! Incorporated Approved by: re (ksmith)
* We no longer need to use d_thread_t, migrate to struct thread *.imp2009-05-202-6/+6
|
* Move the CAM passthrough code into a true module so that it doesn't have to bescottl2008-11-033-33/+58
| | | | | | compiled into the main AMR driver. It's code that is nice to have but not required for normal operation, and it is reported to cause problems for some people.
* Replace all calls to minor() with dev2unit().ed2008-09-271-2/+2
| | | | | | | | | | | | | | | 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
* While spin-waiting for the mailbox semaphore to update, do flushing reads ofscottl2008-07-201-1/+4
| | | | PCI bus so that we don't have to wait more than needed.
* Remove an errant definition for AMR_CONFIG_ENQ3_SOLICITED NOTIFY that wasscottl2008-02-061-1/+0
| | | | accidently reverted in the previous commit.
* Many improvements that have been collected over time:scottl2008-01-243-43/+146
| | | | | | - Improve error handling for load operations. - Fix a memory corruption bug when using certain linux management apps. - Allocate all commands up front to avoid OOM deadlocks later on.
* Rewrite the DMA code paths from being an impenitrable maze of special casesscottl2007-12-124-436/+260
| | | | | to a much saner and simplier unified code path. Along the way, fix various CAM nits and bugs so that the passthrough works correctly for all cases.
* Provide unqiue malloc types instead of using M_DEVBUF.scottl2007-12-022-26/+29
|
* Refactor completion handlers so that they can be combined into a singlescottl2007-12-021-76/+29
| | | | function. Add missing locking.
* Make a pass at style.9 compliancescottl2007-12-021-440/+477
|
* Fix a typo that was hidden by AMR_DEBUG.scottl2007-12-021-1/+1
|
* Fix printf format bugs that where hidden by AMR_DEBUG.scottl2007-12-021-3/+3
|
* Turn the CAM passthroug interface to AMR back ON. Adjust thescottl2007-11-282-80/+68
| | | | | | | | | T_DIRECT filtering so that disk drives can be attached via the pass driver. Add CAM locking. Don't mark CAM commands as SG64 since the hardware isn't designed to deal with 64-bit passthru commands. Hopefully the bounce buffer changes that were done for the management/ioctl interface are robust enough to handle this deficiency for CAM as well.
* Prepare for future integration between CAM and newbus. xpt_bus_registerscottl2007-06-171-1/+1
| | | | | | | now takes a device_t to be the parent of the bus that is being created. Most SIMs have been updated with a reasonable argument, but a few exceptions just pass NULL for now. This argument isn't used yet and the newbus integration likely won't be ready until after 7.0-RELEASE.
* Remove Giant from CAM. Drivers (SIMs) now register a mutex that CAM willscottl2007-04-151-0/+1
| | | | | | | | | | | use to synchornize and protect all data objects that are used for that SIM. Drivers that are not yet MPSAFE register Giant and operate as usual. RIght now, no drivers are MPSAFE, though a few will be changed in the coming week as this work settles down. The driver API has changed, so all CAM drivers will need to be recompiled. The userland API has not changed, so tools like camcontrol do not need to be recompiled.
* o break newbus api: add a new argument of type driver_filter_t topiso2007-02-231-1/+1
| | | | | | | | | | | | | bus_setup_intr() o add an int return code to all fast handlers o retire INTR_FAST/IH_FAST For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current Reviewed by: many Approved by: re@
* Add MODULE_DEPENDS for cam, pci, mca, eisa and isa where needed.mjacob2006-12-111-0/+2
| | | | | PR: 106543 MFC after: 3 days
* 2nd and final commit that moves us to CAM_NEW_TRAN_CODEmjacob2006-11-021-20/+0
| | | | | | as the default. Reviewed by multitudes.
* Implement BIO_FLUSH handling for da(4), amr(4), ata(4) and ataraid(4).pjd2006-10-312-11/+22
| | | | Sponsored by: home.pl
* The first of 3 major steps to move the CAM layer forward to usingmjacob2006-10-311-2/+32
| | | | | | | | | | | | | | | | | | | | | the CAM_NEW_TRAN_CODE that has been in the tree for some years now. This first step consists solely of adding to or correcting CAM_NEW_TRAN_CODE pieces in the kernel source tree such that a both a GENERIC (at least on i386) and a LINT build with CAM_NEW_TRAN_CODE as an option will compile correctly and run (at least with some the h/w I have). After a short settle time, the other pieces (making CAM_NEW_TRAN_CODE the default and updating libcam and camcontrol) will be brought in. This will be an incompatible change in that the size of structures related to XPT_PATH_INQ and XPT_{GET,SET}_TRAN_SETTINGS change in both size and content. However, basic system operation and basic system utilities work well enough with this change. Reviewed by: freebsd-scsi and specific stakeholders
* Chain the bus_dmamap_load() calls when mapping a command with a data CCBjhb2006-07-171-24/+42
| | | | | | | | | | | | instead of doing the first load with the BUS_DMA_NOWAIT flag. On 4.x with PAE and > 4gb of RAM this proved disastrous if there weren't enough bounce pages as amr_mapcmd() would return failure but the callback would later fire once enough bounce pages were available and would then overwrite another command's S/G list. MFC after: 3 days Submitted by: scottl (4.x version) Reviewed by: scottl (port from 4.x to HEAD)
* Make amr_linux work as a module by avoiding calling amr_linux_ioctl_intambrisko2006-05-033-127/+41
| | | | | | | | from the amr_linux. This simplifies the amr_linux shim and puts the smarts into amr.c. I tested this with 2 amr controllers in one box. It seems to work okay with them.
* Reduce the Linux ioctl range to what is needed. I didn't know whatambrisko2006-04-141-2/+2
| | | | I was doing when I first set the range up.
* After further review and discussion, partially revert the previous commit.scottl2006-04-083-20/+13
| | | | | | | | | | The real problem was that ioctl handlers needed to call amr_wait_command() with the list lock held. This not only solves the completion race, it also prevents bounce buffer corruption that could arise from amr_start() being called without the proper locks held. Discussed with: ps MFC After: 3 days
* Close a pesky race where after checking the BUSY flag in amr_wait_command,ps2006-04-083-6/+21
| | | | | | | | the completion of the command can occur before tsleep is called and the command ends up blocking forever since the wakeup has already been called. Submitted by: ups
* Check the return value of copyin() and return an error if it fails.jhb2006-02-231-2/+4
| | | | | | | Coverity ID: 839 Found by: Coverity Prevent MFC after: 1 week Reviewed by: ps, scottl
* Use void * for pointer rather than u_int8_t *, since it doesn'timp2006-02-041-5/+4
| | | | matter. Well it does for type punning warnings.
* Enable 64bit SGL's on PERC 4/DCps2006-02-021-1/+1
|
OpenPOWER on IntegriCloud